Fronta a worker: webhook odpovi hned, praci udelaji workeri

Webhook uz nic nevykonava v requestu. Zapise udalost do fronty a odpovi 202
do jednotek milisekund; strom vykona worker na pozadi. Za konektory nerucime,
takze cekat na cizi sluzbu v requestu znamena ztracet udalosti pri timeoutu.

Fronta ma opakovani s rostouci prodlevou (30 s, 2 min, 10 min, hodina),
spravedlive poradi po firmach (jedna firma s tisicem udalosti nezablokuje
ostatni), navrat zaseknutych behu po restartu a uklid hotovych. Marna chyba
se neopakuje - chybejici skript za minutu existovat nezacne.

Tri druhy spoustecu: push (webhook), vnitrni udalost (vznik a zmena ticketu)
a pull, tedy pravidelne dotazovani u sluzeb bez webhooku (posta, zpravy).
Planovac jen rekne "je cas", samotny dotaz je prvni krok stromu, takze ma
zaznam v logu a opakuje se pri chybe jako cokoliv jineho.

Kontrakt tela webhooku: kazdy parametr ma cestu (data.order.id,
errors.0.message), takze jde napojit i odesilatel s vnorenym modelem.
U adresy je metoda, ukazka tela a kopiruje se cela adresa vcetne domeny.

Vnitrni kroky, ktere sahaji do naseho uloziste: ticket/upsert (zaloz nebo
dopln podle externiho ID), assign-least-busy, assign-by-external, set-type,
set-stage, add-tags, set-status, incident/create, flow/pause a flow/log.

Faze ticketu jako treti osa vedle stavu a stitku. Stav je zivotni cyklus
a pocitaji se z nej statistiky, faze je workflow daneho typu a muze byt jen
jedna, takze se na ni da spolehnout v podmince.

ID z cizich aplikaci u resitele: voicebot posle voicebotId a ticket skonci
u toho, komu patri. Vazba je na jednom miste, ne v kazde automatizaci.

Kazda chyba zaklada incident se dvema urovnemi: impact cte klient a je
srozumitelny, detail cte admin a je v nem cely beh, ktery krok selhal, cele
hlaseni a data na vstupu. Detail vidi jen spravce platformy.

Ochrana proti smycce: automatizace navazana na zmenu ticketu ticket meni,
cimz se spousti znovu - pri vyvoji to server polozilo. Resi to oznaceni behu
pres AsyncLocalStorage a strop peti behu na jeden ticket za minutu.

Upozorneni pri prideleni prace vcetne cisla u zalozky Tickety. Zivy dashboard:
dlazdice nad nasimi daty na udalost, data z konektoru podle ttlSec s moznosti
vynutit nacteni znovu.

Opraveno: path a intervalSec u spoustece se pri ulozeni zahazovaly; nad
seznamem neslo pouzit contains, takze na stitky neslo postavit podminku;
novejsi vystup kroku ted prekryje starsi misto hlaseni konfliktu.

Overeno dvema scenari proti bezicimu serveru, 34 kontrol: firma se skladem,
expedici a IT, a hovory z voicebota (callSid do externiho ID, status do faze,
prirazeni podle voicebotId, tri zpravy = jeden ticket se tremi udalostmi).

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

documentation/99-zmeny.md

@@ -2,6 +2,73 @@
 
 Nejnovejsi nahore.
 
+## 2026-08-13 - fronta, worker a spoustece
+
+Popis v [20-fronta-a-runtime.md](20-fronta-a-runtime.md).
+
+### Zmeneno zasadne
+
+- **Webhook uz nic nevykonava v requestu.** Zapise udalost do fronty a odpovi
+  202 do jednotek milisekund. Strom vykona worker na pozadi. Za konektory
+  nerucime, takze cekat na cizi sluzbu v requestu znamena ztracet udalosti.
+
+### Pridano
+
+- `runtime/queue.ts`: fronta behu v ulozisti. Opakovani s rostouci prodlevou
+  (30 s, 2 min, 10 min, hodina), spravedlive poradi po firmach, navrat
+  zaseknutych behu po restartu, uklid hotovych.
+- `runtime/worker.ts`: bere praci z fronty, ctyri behy naraz.
+- `runtime/triggers.ts`: tri druhy spoustecu. Push (webhook), vnitrni udalost
+  (vznik a zmena ticketu) a **pull, tedy pravidelne dotazovani** u sluzeb,
+  ktere webhooky nemaji - posta, zpravy. Planovac jen rekne "je cas", samotny
+  dotaz je prvni krok stromu.
+- **Kontrakt tela webhooku.** Kazdy parametr ma cestu (`data.order.id`,
+  `errors.0.message`), takze jde napojit i odesilatel s vnorenym modelem.
+  U adresy je videt metoda, ukazka tela podle parametru a kopiruje se cela
+  adresa vcetne domeny.
+- Vnitrni kroky: `ticket/upsert` (zaloz nebo doplň podle externiho ID),
+  `assign-least-busy`, `assign-by-external`, `set-type`, `set-stage`,
+  `add-tags`, `set-status`, `incident/create`, `flow/pause`, `flow/log`.
+- **Faze ticketu** (`stage`) jako treti osa vedle stavu a stitku. Stav je
+  zivotni cyklus a pocitaji se z nej statistiky, faze je workflow daneho typu
+  a muze byt jen jedna, takze se na ni da spolehnout v podmince.
+- **ID z cizich aplikaci u resitele** (`externalIds`). Voicebot posle
+  `voicebotId` a ticket skonci u toho, komu patri. Vazba je na jednom miste,
+  ne v kazde automatizaci.
+- **Upozorneni**: komu prijde ticket, ten to vidi hned, vcetne cisla u zalozky.
+- **Incident z kazde chyby** se dvema urovnemi: `impact` cte klient a je
+  srozumitelny, `detail` cte admin a je v nem cely beh, ktery krok selhal,
+  cele hlaseni a data na vstupu. `detail` se vraci jen spravci platformy.
+- **Ochrana proti smycce.** Automatizace navazana na zmenu ticketu ticket
+  meni, cimz se spousti znovu - pri vyvoji to server polozilo. Resi to
+  oznaceni behu (`AsyncLocalStorage`) a strop peti behu na ticket za minutu.
+- Zivy dashboard: dlazdice nad nasimi daty se prekresli na udalost, data
+  z konektoru drzi server podle `ttlSec` a jde vynutit nacteni znovu.
+
+### Opraveno
+
+- `path` a `intervalSec` u spoustece se pri ulozeni zahazovaly, takze kontrakt
+  webhooku nefungoval.
+- Nad seznamem neslo pouzit `contains`, takze na stitky neslo postavit
+  podminku. Prave na tom stoji prideleni prace.
+- Novejsi vystup kroku ted prekryje starsi se stejnym jmenem. Driv to builder
+  hlasil jako konflikt i tam, kde zadny nebyl.
+- Marna chyba (chybejici skript, neexistujici skupina) se uz neopakuje petkrat.
+
+### Overeno
+
+Dva scenare proti bezicimu serveru, 34 kontrol celkem:
+
+1. **Firma se skladem, expedici a IT.** Webhook odpovedel za 12 ms, worker
+   zalozil ticket, dal mu typ a stitek, druha automatizace ho podle typu
+   a stitku predala nejvolnejsimu ze skladu. Druha objednavka sla jinemu
+   cloveku. Chyba z prevodniku dokladu prisla vnorenou cestou, skoncila u IT
+   a zalozila incident.
+2. **Hovory z voicebota.** Telo `{callSid, status, voicebotId}`: callSid do
+   externiho ID, status do faze, prirazeni podle voicebotId. Tri zpravy
+   o tomtez hovoru daly **jeden ticket** se tremi udalostmi. Neznamy voicebot
+   neskoncil tise - je videt ve fronte i jako incident.
+
 ## 2026-08-13 - runtime, prokliky z widgetu a kapacitni rozbor
 
 ### Pridano