Log rekne co zpusobilo jakou zmenu, prevzeti ticketu a pozvanky

Nalezeno na bezicim serveru: TK-4946 mel 177 udalosti a 620 radku logu,
pritom se skoro nic nestalo. Zmereno proti fronte: ve stejnem okne vzniklo
presne tolik behu, kolik prislo udalosti (22 a 22), kazdy s jednim pokusem.
Fronta nenasobi nic, odesilatel poslal 177 POSTu. Nase vina byla, ze to
z historie neslo poznat.

- Data udalosti se ukladaji. Kdyz krok nema vlastni, ulozi se to, cim beh
  zacal - u webhooku prijate telo. Prazdna udalost je horsi nez zadna.
- Shodna udalost se pocita (repeats, lastAt), nezaklada dalsi radek. Ticket
  se pritom nemeni, takze duplikat nerozblika dashboard ani nespusti
  automatizaci na zmenu ticketu. Zahodit ji nejde, jinak by nikdo nezjistil,
  ze proti nam neco tluce.
- Zmeny se radi pod udalost, ktera je zpusobila, a u udalosti stoji jmeno
  automatizace. Log se cte jako "prislo tohle -> zmenilo to tohle".
- Poznamka o stavu jen kdyz se stav zmenil. "z in-progress na in-progress"
  u kazde zpravy byl zdroj tech 620 radku.
- runsToday konecne znamena dnes: behy po dnech, k tomu vcera a celkem.
  Dosud to byl citac od zalozeni automatizace, jen se jmenoval "dnes".

Vedle toho prace, o kterou slo predtim:
- Prevzeti ticketu ze skupiny (POST /tickets/:id/claim) a krok Predat skupine
  s prepinacem automatickeho prideleni nejvolnejsimu.
- Pozvanky do firmy: odkaz s nahodnym kodem, heslo si nastavi pozvany.
- Resitele, skupiny a pozvanky presunuty z Nastaveni do zalozky Lide, cleny
  skupiny se vybiraji klikanim.
- Ctyri AI znaky, ktere zbyvaly v kodu, pryc.

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

documentation/06-tickety.md

@@ -80,6 +80,47 @@ Kazdy resitel ma `capacity`, tedy pocet nevyrizenych ticketu, ktery je pro nej
 jeste zdrava zatez. Neni to limit, nic se podle nej neodmita - jen se v prehledu
 oznaci, kdo je nad ni.
 
+## Fronta skupiny a prevzeti
+
+Ticket nemusi mit resitele hned. Muze lezet **u skupiny** a cekat, az si ho
+nekdo vezme - `POST /tickets/:id/claim`. Kdo je ve skupine, si ho vezme sam,
+prace se nerozdava shora.
+
+Proc obojí vedle sebe:
+
+| Situace | Co se hodi |
+| --- | --- |
+| havarie, musi to nekdo hned resit | automat prideli nejvolnejsimu |
+| bezny dotaz, lidi maji ruzne dny | necha se ve fronte skupiny |
+
+Proto je prepinac **Priradit rovnou nejvolnejsimu** na kroku automatizace
+(`ticket/assign-group`), ne na skupine: tataz skupina potrebuje obe chovani,
+jen u jineho typu prace.
+
+Vzit si ticket, ktery uz nekdo resi, neni prevzeti, ale prehozeni. Chce to pravo
+`ticket.assign.others` a jde to jen pres prirazeni, ne pres prevzeti.
+
+## Pozvanky do firmy
+
+`src/data/invites.ts`
+
+Novy clovek se do firmy dostane odkazem s nahodnym kodem, ne tim, ze mu nekdo
+zalozi ucet a posle heslo. Duvody:
+
+- **heslo nikdy nikam neposilame.** Kdo si ho nastavi sam za odkazem, ma ho jen
+  on,
+- pozvanka **vyprsi** (tyden) a da se zrusit, ucet ne,
+- kdo uz ucet ma, se jen pripoji k dalsi firme misto zakladani druheho - ale
+  musi zadat svoje heslo, jinak by kdokoliv s odkazem pripojil cizi adresu ke
+  sve firme.
+
+U pozvanky se rovnou rekne, jake role clovek dostane a jestli z nej ma byt
+i **resitel**. Uzivatel a resitel nejsou totez, viz vyse - proto se to pta
+misto hadani.
+
+Sprava je v zalozce **Lide**, ne v nastaveni: pozvat kolegu je bezna denni
+prace.
+
 ## Prehled nad firmou
 
 `GET /api/dashboard/tickets/workload` vraci pres cely tym: kolik ma kdo
@@ -123,6 +164,42 @@ do korene a zaloguje - ztratit radek logu je horsi nez ho ukazat spatne zanoreny
 Komentare jsou taky zaznamy logu (`kind: 'note'`). Diky tomu je vsechno na jedne
 casove ose a nemusi se nikde skladat dohromady dva ruzne seznamy.
 
+## Opakovana udalost
+
+Odesilatele umi poslat stejnou zpravu i osmdesatkrat za minutu. Kdyz prijde
+**presne totez co posledne** (stejny typ, zdroj, popisek a stejna data), nezaklada
+se dalsi radek: pricte se k pocitadlu u te predchozi.
+
+| Co se stane | Proc |
+| --- | --- |
+| `repeats` +1, `lastAt` = ted | osmdesat radku znamena, ze v historii nikdo nic nenajde |
+| ticket se **nemeni** | jinak by duplikat rozblikal dashboard a spustil automatizaci na zmenu ticketu |
+| do logu se nezapisuje nic | log ma ukazovat zmeny, ne to, ze se nezmenilo nic |
+| udalost se **nezahazuje** | bez pocitadla by nikdo nezjistil, ze proti nam neco tluce ve smycce |
+
+Porovnava se jen s posledni udalosti. "Objednavka pripravena" muze legitimne
+prijit znovu za hodinu, kdyz se mezitim stalo neco jineho - to je novy fakt.
+
+## Co je v logu videt
+
+Log se cte jako **prislo tohle a zpusobilo to tuhle zmenu**. Zmeny, ktere udela
+beh automatizace, se radi pod jeho radek udalosti (`parentId`), takze nejde
+zamenit, co zpusobilo co:
+
+```
+Prijata udalost: stav completed (automatizace TEST)      13:13:27
+  stav in-progress -> completed                          13:13:27
+  stitky +hovor                                          13:13:27
+Prijata udalost: stav completed   22x beze zmeny         13:13:34
+```
+
+U udalosti stoji, **kdo ji prinesl**. Prvni otazka nad zmenenym ticketem je
+"kdo mi do toho sahl" a odpoved `webhook` na ni neodpovida.
+
+Data udalosti se ukladaji cela. Kdyz krok nema vlastni, ulozi se to, cim beh
+zacal - u webhooku prijate telo. Prazdna udalost je horsi nez zadna: tvari se,
+ze se neco stalo, a nerekne co.
+
 ## Konektor Tickety
 
 Kategorie `servicedesk`, driv byl pod Nastroji. Ma obe strany: