Navrh pristupneho portalu a srovnani vzorove automatizace s instanci

Dve veci, obe bez zmeny chovani aplikace.

Navrh (documentation/25-navrh-pristupny-portal.md):

Vzniklo z otazky, jak portal priblizit cloveku, ktery ho nikdy nevidel.
Odpoved se rozpadla na pet veci, ktere spolu souvisi vic, nez to vypada:

- prehled ukazuje jen cisla, zadna slovesa. Vsech sest widgetu ve vychozi sade
  jsou statistiky a seznamy. Navrh pridava "Moje tickety", "Fronta bez
  resitele", "Co potrebujete udelat" a "Zaciname". Prvni dva jsou skoro zadarmo,
  builtinSources uz ten mechanismus maji
- formulare nemaji spolecnou vrstvu. inputClass je nadefinovany na 13 mistech
  a rozesel se do peti ruznych vzhledu, Field je napsany trikrat. V ui/ neni
  zadny formularovy prvek. Blokuje to widget akci, protoze NewTicketDialog je
  ten modal a formular z nej vytahnout nejde
- hledani neumi to jedine, k cemu je. Klientsky filtr nehleda v obsahu, ve
  vlastnich polich ani v externim ID, takze hovor podle callSid se dohledat
  neda. Navrh je modal s kriterii, protoze ticket nema pevnou sadu poli
- viditelnost ticketu se neda omezit. Pohled tenant dostane kazdy, kdo do firmy
  patri, mine je dobrovolny filtr a ne strop. Navrh vede viditelnost pres
  clenstvi (priznak na firme, priznak u kazde skupiny), ne pres role - role jsou
  na celou firmu a neumi rict "v jedne sekci vidim vse, v druhe svoje"
- uloziste neprezije nasazeni, coz podpira bod o hledani

Dve veci, ktere stoji za zapamatovani, i kdyby se navrh nikdy nedodelal:
strop viditelnosti nepatri do hledani, ale do cteni ticketu (cesty k ticketum
jsou tri a dve z nich filtruji tickets primo), a pohled a strop nejsou totez.

Ctyri otevrene otazky jsou v zaveru navrhu.

Vzorova automatizace (src/data/automationStore.ts):

seedRealAutomations drzelo starsi podobu stromu nez ta, ktera na instanci
opravdu bezi. Protoze data neprezivaji redeploy, je tenhle seed jedine misto,
kde nastaveni prezije nasazeni - kdyz se rozejde, znamena to po kazdem nasazeni
stavet strom rucne znovu.

Opsano z bezici instance: spoustec ma sest parametru misto tri (pribylo result,
rating a data), krok upsert pise do obsahu {{voicebotId}}, {{data}} a stav bere
z {{result}}, a za nim je podminka nad vysledkem - cokoliv krome "Chybějící
informace" ticket zavre, jinak jde na servicedesk s vysokou prioritou.

Overeno lokalnim startem s vlastnim DATA_DIR: automatizace se nasype, ma ctyri
kroky stejne jako instance, je zapnuta a nema zadny nedodelek.

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

documentation/99-zmeny.md

@@ -2,6 +2,59 @@
 
 Nejnovejsi nahore.
 
+## 2026-09-02 - Navrh: pristupny portal a viditelnost
+
+Novy [25-navrh-pristupny-portal.md](25-navrh-pristupny-portal.md). Je to navrh,
+ne popis stavu, nic z nej zatim neni naprogramovane.
+
+Vzniklo to z otazky, jak portal priblizit cloveku, ktery ho nikdy nevidel.
+Odpoved se rozpadla na pet veci, ktere spolu souvisi vic, nez to vypada:
+
+- **prehled ukazuje jen cisla, zadna slovesa.** Vsech sest widgetu ve vychozi
+  sade jsou statistiky a seznamy. Navrh pridava "Moje tickety", "Fronta bez
+  resitele", "Co potrebujete udelat" a "Zaciname"
+- **formulare nemaji spolecnou vrstvu.** `inputClass` je nadefinovany na 13
+  mistech a rozesel se do peti ruznych vzhledu, `Field` je napsany trikrat.
+  V `components/ui/` neni zadny formularovy prvek
+- **hledani neumi to jedine, k cemu je.** Klientsky filtr nehleda v obsahu,
+  ve vlastnich polich ani v externim ID, takze hovor podle `callSid` se dohledat
+  neda. Navrh je modal s kriterii, protoze ticket nema pevnou sadu poli
+- **viditelnost ticketu se neda omezit.** Pohled `tenant` dostane kazdy, kdo do
+  firmy patri, `mine` je dobrovolny filtr a ne strop. Navrh vede viditelnost
+  pres clenstvi (priznak na firme, priznak u kazde skupiny), ne pres role -
+  role jsou na celou firmu a neumi rict "v jedne sekci vidim vse, v druhe svoje"
+- **uloziste neprezije nasazeni.** Overeno v praxi: po dnesnim nasazeni zustaly
+  ve firme dva tickety, predtim jich byly tisice
+
+Dve veci, ktere stoji za zapamatovani, i kdyby se navrh nikdy nedodelal:
+
+1. **Strop viditelnosti nepatri do hledani, ale do cteni ticketu.** Cesty
+   k ticketum jsou dnes tri (`listTickets`, `getWorkload`, `getAgentStats`)
+   a dve z nich filtruji `tickets` primo. Kdyby strop resilo jen hledani,
+   obejde se widgetem nebo souhrnem.
+2. **Pohled a strop nejsou totez.** Pohled je co chci videt, strop je co vubec
+   smim videt. Dnes existuje jen pohled a klientovi se veri.
+
+Ctyri otevrene otazky jsou v zaveru navrhu: co znamena "moje" pro strop, jak se
+strop potka s helpdeskem, jestli hledat i v udalostech a kdo smi viditelnost
+nastavovat.
+
+## 2026-09-02 - Vzorova automatizace srovnana s bezici instanci
+
+`seedRealAutomations` v `src/data/automationStore.ts` drzelo starsi podobu stromu
+nez ta, ktera na instanci opravdu bezi. Protoze data neprezivaji redeploy, je
+tenhle seed jedine misto, kde nastaveni prezije nasazeni - a kdyz se rozejde,
+znamena to po kazdem nasazeni stavet strom rucne znovu.
+
+Opsano z bezici instance: spoustec ma sest parametru misto tri (pribylo `result`,
+`rating` a `data`, vsechny s cestou do `data`), krok "Zalozit nebo doplnit ticket"
+pise do obsahu `{{voicebotId}}, {{data}}` a stav bere z `{{result}}`, a za nim je
+podminka nad vysledkem: cokoliv krome "Chybějící informace" ticket zavre, jinak
+jde na servicedesk s vysokou prioritou.
+
+Pravidlo, ktere z toho plyne a je i v komentari u funkce: **kdyz se strom na
+instanci zmeni, patri ta zmena sem.** Jinak ji dalsi nasazeni zahodi.
+
 ## 2026-09-02 - Zalozit NEBO DOPLNIT ticket: doplneni konecne doplnuje
 
 Automatizace mela v kroku "Zalozit nebo doplnit ticket" pole Obsah nastavene na