# 04 — Event-sourcing: šta jeste, šta nije

# Event-sourcing — razbijanje zablude

## Šta JESTE (i zrelo je)
Pravi **event-driven messaging**: `events.db` sa correlation_id / causation_id / idempotency_key UNIQUE / retry state-machine, i **pravi transactional outbox** (outboxWrite unutar MC transakcije + relayOutbox). Svjesno rješenje dual-write problema koje 90% timova ne uradi kako treba. **Pohvala stoji.**

## Šta NIJE
Ovo **NIJE event sourcing**:
- Source-of-truth je mutable `tasks` CRUD tabela
- `replay()` re-isporučuje side-efekte, NE rekonstruiše stanje iz događaja
- `task_history` (67k redova) je audit changelog, ne event log
- `causation_id` je **0% popunjen** — uzročni lanac postoji kao kolona ali je prazan
- 4 "event surface" (evidence_ledger / mc_history / hivemind / checkpoints) su nezavisni audit logovi VAN busa

## Zabluda koju treba razbiti
**"Trebamo li preći na pravi event-sourcing?" → NE.** Task je obična state-mašina (open→started→ready→done). Full event-sourcing nad tim = čisti over-engineering — isti metafora-driven nagon koji je proizveo **HexaDB** (bee/6×19 metafora ugurana u DB bez geo-potrebe). Ne pravite drugi HexaDB od event-store-a.

## Gdje JEDINO vrijedi formalizovati
Orkestracijske **odluke** — zašto je agent rutirao ovamo, šta je MEHANIK presudio, koji model, koji verdikt. Te odluke provući kroz **postojeći** bus sa popunjenim correlation_id + causation_id → deterministički replay "zašto je sistem ovo odlučio". Zlato za debug halucinacija i audit. **Ne diraj task-state, ulanči odluke.**

## Najveći data-rizik
Nekontrolisani dual-write na ~10 izvora istine bez reconciliation sloja. Konkretno **fire-and-forget MC→Planka** (greška se tiho guta) + ne-idempotentni append logovi. Lijek: provući SVE side-efekte (uklj. Planka) kroz postojeći outbox + periodični reconciliation job. **Imate napola — dovršite, ne gradite novo.**