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/04-api.md

@@ -36,6 +36,9 @@ Vyzaduji `Authorization: Bearer <token>`:
 | GET    | `/api/dashboard/intake`                             |
 | POST   | `/api/dashboard/intake/regenerate`                  |
 | GET    | `/api/dashboard/settings/actions/:id/scope`         |
+| GET    | `/api/dashboard/notifications`                      |
+| POST   | `/api/dashboard/notifications/read`                 |
+| GET    | `/api/dashboard/runs`                               |
 | GET    | `/api/dashboard/tickets`                            |
 | GET    | `/api/dashboard/tickets/workload`                   |
 | GET    | `/api/dashboard/tickets/:id`                        |
@@ -227,6 +230,21 @@ tentyz klic.
 Neznamy `typeId` se zahodi a zaloguje, ticket vznikne bez typu. Odmitnout celou
 udalost kvuli jednomu poli by znamenalo ztratu dat.
 
+## Fronta behu
+
+Popis je v [20-fronta-a-runtime.md](20-fronta-a-runtime.md).
+
+`POST /webhook/:token` vraci **202**, ne 200: data jsme prevzali a strom se
+vykona na pozadi. Vysledek se hleda v `GET /api/dashboard/runs` nebo v logu
+ticketu. Cekat na cizi sluzbu v requestu nejde - za jeji rychlost nerucime
+a odesilateli by vyprsel timeout.
+
+`GET /webhook/:token` vraci **kontrakt**: co se v tele ceka, na jakych cestach
+a ukazku. Bez toho by musel ten, kdo webhook zapojuje, hadat.
+
+`GET /api/dashboard/runs` ma u kazdeho behu cele chybove hlaseni, pocet pokusu
+a kdy se to zkusi znovu.
+
 ## Prava a navigace
 
 `GET /api/dashboard/access` vraci `permissions` (efektivni prava po slouceni