Builder nabizi jen to, co jde zavolat

V nabidce kroku byly vsechny sluzby katalogu, i ty, ke kterym firma nema
napojeni. Slo tedy vybrat Raynet CRM bez konektoru a postavit strom, ktery pri
prvnim behu spadne na chybejicich udajich - a to se pozna az za tyden, kdyz
prijde prvni ostra udalost.

Nabizi se sluzba, ktera je obecna, nebo k ni firma ma napojeni. Obecne jsou ty,
co se bez konektoru obejdou: webhook, casovac, rucni spusteni, formular,
incident, ticket, HTTP, transformace, pauza a log. Priznak general uz existoval,
jen ho nikdo nepouzil na filtrovani nabidky.

Katalog se kvuli tomu nefiltruje, jen se oznacuje: GET /api/dashboard/services
prida ke kazde sluzbe connected. Sluzba z odpovedi nemizi, protoze log ticketu
a detail akce podle katalogu prekladaji ID operaci na jmena - kdyby zmizela,
zustalo by v uz zapsanem radku hole ID. Filtruje az builder. Pod nabidkou je
veta, kolik sluzeb ceka na napojeni, aby to nevypadalo, ze neexistuji.

Soukroma sluzba uz neni videt cizi firme. canSeeService vracelo spravci
platformy true driv, nez se vubec podivalo na viditelnost, takze zakazkova
integrace omezena na jednoho klienta se ukazovala i po prepnuti do jine firmy
a spravce si ji mohl vybrat do jeji automatizace. Nove rozhoduje firma, ne
clovek: kdyz je vybrana, plati jeji seznam, bez ni spravce platformy spravuje
katalog a vidi vsechno. Zaroven se konecne pouziva tenantHasService, tedy
zpristupneni sluzby firme pres nastaveni - dosud to bylo pole, ktere nikdo
necetl.

Overeno na bezici instanci: Polstryn SAP je pro tnt_logitrans v katalogu, pro
tnt_automia uz ne, a to i pro spravce platformy. V nabidce builderu pro
tnt_automia zbylo deset obecnych sluzeb plus iDoklad, na ktery firma napojeni
ma.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

documentation/99-zmeny.md

@@ -2,6 +2,47 @@
 
 Nejnovejsi nahore.
 
+## 2026-09-02 - Builder nabizi jen to, co jde zavolat
+
+V nabidce kroku byly vsechny sluzby katalogu, i ty, ke kterym firma nema
+napojeni. Slo tedy vybrat Raynet CRM bez konektoru a postavit strom, ktery pri
+prvnim behu spadne na chybejicich udajich - a to se pozna az za tyden, kdyz
+prijde prvni ostra udalost.
+
+### Pravidlo
+
+Nabizi se sluzba, ktera je **obecna, nebo k ni firma ma napojeni**.
+
+Obecne jsou ty, co se bez konektoru obejdou: webhook, casovac, rucni spusteni,
+formular, incident, ticket, HTTP, transformace, pauza a zapis do logu. Ma to uz
+priznak `general`, jen ho nikdo nepouzil na filtrovani nabidky.
+
+### Katalog se nefiltruje, jen se oznacuje
+
+`GET /api/dashboard/services` prida ke kazde sluzbe `connected`, tedy jestli
+k ni firma ma aspon jedno napojeni. Sluzba z odpovedi **nemizi**: log ticketu
+a detail akce podle katalogu prekladaji ID operaci na jmena, a kdyby zmizela,
+zustalo by v uz zapsanem radku hole ID. Filtruje az builder.
+
+Aby nabidka nevypadala jako cely katalog, je pod ni veta, kolik sluzeb ceka na
+napojeni. Bez ni to vypada, ze sluzba neexistuje, misto ze k ni chybi udaje.
+
+### Soukroma sluzba uz neni videt cizi firme
+
+`canSeeService` vracelo spravci platformy `true` driv, nez se vubec podivalo na
+viditelnost sluzby. Zakazkova integrace omezena na jednoho klienta se tak
+ukazovala i po prepnuti do jine firmy - spravce si ji mohl vybrat do jeji
+automatizace.
+
+**Rozhoduje firma, ne clovek.** Kdyz je firma vybrana, plati jeji seznam; bez
+vybrane firmy spravce platformy spravuje katalog a vidi vsechno. Zaroven se
+konecne pouziva `tenantHasService`, tedy zpristupneni sluzby firme pres
+nastaveni - dosud to bylo pole, ktere nikdo necetl.
+
+Overeno: Polstryn SAP je pro `tnt_logitrans` v katalogu, pro `tnt_automia` uz
+ne, a to i pro spravce platformy. V nabidce builderu pro `tnt_automia` zbylo
+deset obecnych sluzeb plus iDoklad, na ktery firma napojeni ma.
+
 ## 2026-09-02 - Tickety maji zalozky, fronta umi prirazovat
 
 Seznam ticketu mel dva prepinace, "Moje tickety" a "Ve fronte", schovane mezi