Saga / Process Manager

# Úkol pro coding agenta: Saga / Process Manager

Stack: Java. Režim: s vedením.
Cíl: Zavést Process Manager pro onboarding hypotéky se stavem, timeouty a kompenzací.

## Kontext existujícího kódu

Pracuješ v existujícím projektu (Java backend (typicky Java 21, Spring Boot, JPA nebo JDBC). Použij build nástroj a styl, který projekt už má (Maven/Gradle, JUnit 5).).
Doména: hypoteční kalkulačka, která se postupně mění v event-driven systém (kalkulačka, rizika, schvalování, identita, účet, dokumenty, výplata).
Předpoklad: projekt má asynchronní onboarding přes broker (identita → účet → smlouva → výplata). Pokud ne, nejdřív založ minimální tok těchto kroků v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde dnes onboarding koordinuje jeden velký service/handler, nebo zda jde o choreografii. Synchronní handler s veřejným API neměň.
- Které kroky jsou vratné a čím (kompenzační akce). Chybějící navrhni jako idempotentní endpoint.
- Úložiště pro stav procesu.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (process manager, saga), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji. Když chybí, navrhni ji v plánu.

## Očekávané chování

Onboarding jde přes víc služeb a nejde obalit jednou transakcí. Process Manager (Saga) drží stav per žádost, vydává příkazy a reaguje na výsledky; krok, který nedoběhne do lhůty, zopakuje. Když krok selže natrvalo, rollback nejde: PM vrátí hotové vratné kroky a pro nevratné založí úkol pro člověka. Příklad: výplata selže (limit, AML); PM vydá příkaz zavřít účet (výsledek `MortgageAccountClosed`), na vydanou smlouvu založí úkol a po jeho vyřízení proces skončí `compensated`.

## Konkrétní úkol

Technická specifika (Java): Spring State Machine/Temporal/Axon Saga, pokud je v organizaci; jinak stavová tabulka + handler.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: tabulka kroků (spouštěč, dokončení, timeout × pokusy, kompenzace) a přechodů. Konečné stavy: dokončeno, zamítnuto, selhalo, `compensated`, ruční zásah.
2. Process Manager: perzistovaný stav per žádost (tabulka s verzí), reaguje na události, vydává příkazy (opakuj krok, kompenzuj, založ úkol) až po uložení stavu.
3. Každý krok má timeout a politiku opakování; timeout pokusu delší než doba, po kterou pracovník opakuje sám. Krok selže až po posledním pokusu PM; zpráva v DLQ selhání procesu není.
4. Kompenzace pro vratné kroky (zavřít účet) podle id žádosti a ruční zásah pro nevratné (smlouva, výplata). Po zastavení procesu pracovníci krok žádosti přeskočí.
5. Test: každý krok selže → proces skončí v definovaném stavu; kompenzace selže → ruční zásah.

Na co si dát pozor:
- Saga není distribuovaná transakce: mezi kroky je nekonzistence viditelná a pozdní výsledek může dorazit i po kompenzaci.
- Kompenzace také může selhat.

## Co nesmíš měnit

- Stávající veřejné API a chování endpointů kalkulačky, které teď funguje.
- Databázové schéma stávajících tabulek (nové tabulky/migrace jsou v pořádku, přejmenování a mazání ne).
- Cizí testy, seed data a existující hodnoty. Když je změna nutná, dej ji do samostatného commitu a uveď ji. Pokud změna tvaru události nebo nový konzument nutně mění existující test, uprav ho v samostatném commitu a v závěru uveď proč.
- Veřejné kontrakty (API, schémata událostí) bez zpětné kompatibility.

## Hotovo, když

- Tabulka přechodů a test pro selhání každého kroku.
- Stav procesu přežije restart (test: nová instance nad stejným úložištěm pokračuje).
- Kompenzace jsou idempotentní; po zastavení procesu se další kroky neprovedou.
- JUnit 5 testy ve stávající struktuře `src/test/java` projdou build nástrojem projektu.
- V závěru uveď: co jsi změnil, co jsi předpokládal, co zbývá.

# Úkol pro coding agenta: Saga / Process Manager

Stack: Java. Režim: challenge.
Cíl: Zavést Process Manager pro onboarding hypotéky se stavem, timeouty a kompenzací.

## Kontext existujícího kódu

Pracuješ v existujícím projektu (Java backend (typicky Java 21, Spring Boot, JPA nebo JDBC). Použij build nástroj a styl, který projekt už má (Maven/Gradle, JUnit 5).).
Doména: hypoteční kalkulačka, která se postupně mění v event-driven systém (kalkulačka, rizika, schvalování, identita, účet, dokumenty, výplata).
Předpoklad: projekt má asynchronní onboarding přes broker (identita → účet → smlouva → výplata). Pokud ne, nejdřív založ minimální tok těchto kroků v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde dnes onboarding koordinuje jeden velký service/handler, nebo zda jde o choreografii. Synchronní handler s veřejným API neměň.
- Které kroky jsou vratné a čím (kompenzační akce). Chybějící navrhni jako idempotentní endpoint.
- Úložiště pro stav procesu.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (process manager, saga), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji. Když chybí, navrhni ji v plánu.

## Očekávané chování

Onboarding jde přes víc služeb a nejde obalit jednou transakcí. Process Manager (Saga) drží stav per žádost, vydává příkazy a reaguje na výsledky; krok, který nedoběhne do lhůty, zopakuje. Když krok selže natrvalo, rollback nejde: PM vrátí hotové vratné kroky a pro nevratné založí úkol pro člověka. Příklad: výplata selže (limit, AML); PM vydá příkaz zavřít účet (výsledek `MortgageAccountClosed`), na vydanou smlouvu založí úkol a po jeho vyřízení proces skončí `compensated`.

## Zadání (Challenge)

Zaveď Process Manager pro onboarding hypotéky a zajisti, aby selhání libovolného kroku skončilo v konzistentním stavu.

Technická specifika (Java): Spring State Machine/Temporal/Axon Saga, pokud je v organizaci; jinak stavová tabulka + handler.

Postup si zvol sám. Pasti v tomto tématu nejsou vypsané: najdi je (souběh, opakované doručení, pořadí, selhání uprostřed) a ke každé napiš test, který by ji odhalil. Na konci vypiš, jaké pasti jsi našel a které jsi vědomě nechal otevřené.

## Co nesmíš měnit

- Stávající veřejné API a chování endpointů kalkulačky, které teď funguje.
- Databázové schéma stávajících tabulek (nové tabulky/migrace jsou v pořádku, přejmenování a mazání ne).
- Cizí testy, seed data a existující hodnoty. Když je změna nutná, dej ji do samostatného commitu a uveď ji. Pokud změna tvaru události nebo nový konzument nutně mění existující test, uprav ho v samostatném commitu a v závěru uveď proč.
- Veřejné kontrakty (API, schémata událostí) bez zpětné kompatibility.

## Hotovo, když

- Tabulka přechodů a test pro selhání každého kroku.
- Stav procesu přežije restart (test: nová instance nad stejným úložištěm pokračuje).
- Kompenzace jsou idempotentní; po zastavení procesu se další kroky neprovedou.
- JUnit 5 testy ve stávající struktuře `src/test/java` projdou build nástrojem projektu.
- V závěru uveď: co jsi změnil, co jsi předpokládal, co zbývá.

# Úkol pro coding agenta: Saga / Process Manager

Stack: C#. Režim: s vedením.
Cíl: Zavést Process Manager pro onboarding hypotéky se stavem, timeouty a kompenzací.

## Kontext existujícího kódu

Pracuješ v existujícím projektu (C# backend (.NET, ASP.NET Core, EF Core nebo Dapper). Použij solution, styl a DI konvence, které projekt už má (xUnit/NUnit).).
Doména: hypoteční kalkulačka, která se postupně mění v event-driven systém (kalkulačka, rizika, schvalování, identita, účet, dokumenty, výplata).
Předpoklad: projekt má asynchronní onboarding přes broker (identita → účet → smlouva → výplata). Pokud ne, nejdřív založ minimální tok těchto kroků v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde dnes onboarding koordinuje jeden velký service/handler, nebo zda jde o choreografii. Synchronní handler s veřejným API neměň.
- Které kroky jsou vratné a čím (kompenzační akce). Chybějící navrhni jako idempotentní endpoint.
- Úložiště pro stav procesu.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (process manager, saga), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji. Když chybí, navrhni ji v plánu.

## Očekávané chování

Onboarding jde přes víc služeb a nejde obalit jednou transakcí. Process Manager (Saga) drží stav per žádost, vydává příkazy a reaguje na výsledky; krok, který nedoběhne do lhůty, zopakuje. Když krok selže natrvalo, rollback nejde: PM vrátí hotové vratné kroky a pro nevratné založí úkol pro člověka. Příklad: výplata selže (limit, AML); PM vydá příkaz zavřít účet (výsledek `MortgageAccountClosed`), na vydanou smlouvu založí úkol a po jeho vyřízení proces skončí `compensated`.

## Konkrétní úkol

Technická specifika (C#): MassTransit Saga/NServiceBus/Durable Functions, pokud je v organizaci; jinak stavová tabulka + handler.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: tabulka kroků (spouštěč, dokončení, timeout × pokusy, kompenzace) a přechodů. Konečné stavy: dokončeno, zamítnuto, selhalo, `compensated`, ruční zásah.
2. Process Manager: perzistovaný stav per žádost (tabulka s verzí), reaguje na události, vydává příkazy (opakuj krok, kompenzuj, založ úkol) až po uložení stavu.
3. Každý krok má timeout a politiku opakování; timeout pokusu delší než doba, po kterou pracovník opakuje sám. Krok selže až po posledním pokusu PM; zpráva v DLQ selhání procesu není.
4. Kompenzace pro vratné kroky (zavřít účet) podle id žádosti a ruční zásah pro nevratné (smlouva, výplata). Po zastavení procesu pracovníci krok žádosti přeskočí.
5. Test: každý krok selže → proces skončí v definovaném stavu; kompenzace selže → ruční zásah.

Na co si dát pozor:
- Saga není distribuovaná transakce: mezi kroky je nekonzistence viditelná a pozdní výsledek může dorazit i po kompenzaci.
- Kompenzace také může selhat.

## Co nesmíš měnit

- Stávající veřejné API a chování endpointů kalkulačky, které teď funguje.
- Databázové schéma stávajících tabulek (nové tabulky/migrace jsou v pořádku, přejmenování a mazání ne).
- Cizí testy, seed data a existující hodnoty. Když je změna nutná, dej ji do samostatného commitu a uveď ji. Pokud změna tvaru události nebo nový konzument nutně mění existující test, uprav ho v samostatném commitu a v závěru uveď proč.
- Veřejné kontrakty (API, schémata událostí) bez zpětné kompatibility.

## Hotovo, když

- Tabulka přechodů a test pro selhání každého kroku.
- Stav procesu přežije restart (test: nová instance nad stejným úložištěm pokračuje).
- Kompenzace jsou idempotentní; po zastavení procesu se další kroky neprovedou.
- Testy ve stávajícím testovacím projektu projdou (`dotnet test`).
- V závěru uveď: co jsi změnil, co jsi předpokládal, co zbývá.

# Úkol pro coding agenta: Saga / Process Manager

Stack: C#. Režim: challenge.
Cíl: Zavést Process Manager pro onboarding hypotéky se stavem, timeouty a kompenzací.

## Kontext existujícího kódu

Pracuješ v existujícím projektu (C# backend (.NET, ASP.NET Core, EF Core nebo Dapper). Použij solution, styl a DI konvence, které projekt už má (xUnit/NUnit).).
Doména: hypoteční kalkulačka, která se postupně mění v event-driven systém (kalkulačka, rizika, schvalování, identita, účet, dokumenty, výplata).
Předpoklad: projekt má asynchronní onboarding přes broker (identita → účet → smlouva → výplata). Pokud ne, nejdřív založ minimální tok těchto kroků v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde dnes onboarding koordinuje jeden velký service/handler, nebo zda jde o choreografii. Synchronní handler s veřejným API neměň.
- Které kroky jsou vratné a čím (kompenzační akce). Chybějící navrhni jako idempotentní endpoint.
- Úložiště pro stav procesu.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (process manager, saga), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji. Když chybí, navrhni ji v plánu.

## Očekávané chování

Onboarding jde přes víc služeb a nejde obalit jednou transakcí. Process Manager (Saga) drží stav per žádost, vydává příkazy a reaguje na výsledky; krok, který nedoběhne do lhůty, zopakuje. Když krok selže natrvalo, rollback nejde: PM vrátí hotové vratné kroky a pro nevratné založí úkol pro člověka. Příklad: výplata selže (limit, AML); PM vydá příkaz zavřít účet (výsledek `MortgageAccountClosed`), na vydanou smlouvu založí úkol a po jeho vyřízení proces skončí `compensated`.

## Zadání (Challenge)

Zaveď Process Manager pro onboarding hypotéky a zajisti, aby selhání libovolného kroku skončilo v konzistentním stavu.

Technická specifika (C#): MassTransit Saga/NServiceBus/Durable Functions, pokud je v organizaci; jinak stavová tabulka + handler.

Postup si zvol sám. Pasti v tomto tématu nejsou vypsané: najdi je (souběh, opakované doručení, pořadí, selhání uprostřed) a ke každé napiš test, který by ji odhalil. Na konci vypiš, jaké pasti jsi našel a které jsi vědomě nechal otevřené.

## Co nesmíš měnit

- Stávající veřejné API a chování endpointů kalkulačky, které teď funguje.
- Databázové schéma stávajících tabulek (nové tabulky/migrace jsou v pořádku, přejmenování a mazání ne).
- Cizí testy, seed data a existující hodnoty. Když je změna nutná, dej ji do samostatného commitu a uveď ji. Pokud změna tvaru události nebo nový konzument nutně mění existující test, uprav ho v samostatném commitu a v závěru uveď proč.
- Veřejné kontrakty (API, schémata událostí) bez zpětné kompatibility.

## Hotovo, když

- Tabulka přechodů a test pro selhání každého kroku.
- Stav procesu přežije restart (test: nová instance nad stejným úložištěm pokračuje).
- Kompenzace jsou idempotentní; po zastavení procesu se další kroky neprovedou.
- Testy ve stávajícím testovacím projektu projdou (`dotnet test`).
- V závěru uveď: co jsi změnil, co jsi předpokládal, co zbývá.

# Úkol pro coding agenta: Saga / Process Manager

Stack: Web (HTML/JS nebo stack aplikace). Režim: s vedením.
Cíl: Zavést Process Manager pro onboarding hypotéky se stavem, timeouty a kompenzací.

## Kontext existujícího kódu

Pracuješ v existujícím projektu (webová aplikace: frontend v prohlížeči, případně s vlastním backendem. Když má projekt backend, patří event store, broker a služby na backend a body o endpointech a tabulkách se týkají jeho. Když backend nemá, použij IndexedDB v prohlížeči a v testech `fake-indexeddb`. Framework a test runner projektu zachovej; nové závislosti přidávej jen s odůvodněním.).
Doména: hypoteční kalkulačka, která se postupně mění v event-driven systém (kalkulačka, rizika, schvalování, identita, účet, dokumenty, výplata).
Předpoklad: projekt má asynchronní onboarding přes broker (identita → účet → smlouva → výplata). Pokud ne, nejdřív založ minimální tok těchto kroků v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde dnes onboarding koordinuje jeden velký service/handler, nebo zda jde o choreografii. Synchronní handler s veřejným API neměň.
- Které kroky jsou vratné a čím (kompenzační akce). Chybějící navrhni jako idempotentní endpoint.
- Úložiště pro stav procesu.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (process manager, saga), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji. Když chybí, navrhni ji v plánu.

## Očekávané chování

Onboarding jde přes víc služeb a nejde obalit jednou transakcí. Process Manager (Saga) drží stav per žádost, vydává příkazy a reaguje na výsledky; krok, který nedoběhne do lhůty, zopakuje. Když krok selže natrvalo, rollback nejde: PM vrátí hotové vratné kroky a pro nevratné založí úkol pro člověka. Příklad: výplata selže (limit, AML); PM vydá příkaz zavřít účet (výsledek `MortgageAccountClosed`), na vydanou smlouvu založí úkol a po jeho vyřízení proces skončí `compensated`.

## Konkrétní úkol

Technická specifika (Web (HTML/JS nebo stack aplikace)): Orchestrace a trvalý stav na serveru; UI jen čte stav a zobrazí ho jako stavový automat (xstate, smí-li projekt přidat závislost; jinak čistá funkce).

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: tabulka kroků (spouštěč, dokončení, timeout × pokusy, kompenzace) a přechodů. Konečné stavy: dokončeno, zamítnuto, selhalo, `compensated`, ruční zásah.
2. Process Manager: perzistovaný stav per žádost (tabulka s verzí), reaguje na události, vydává příkazy (opakuj krok, kompenzuj, založ úkol) až po uložení stavu.
3. Každý krok má timeout a politiku opakování; timeout pokusu delší než doba, po kterou pracovník opakuje sám. Krok selže až po posledním pokusu PM; zpráva v DLQ selhání procesu není.
4. Kompenzace pro vratné kroky (zavřít účet) podle id žádosti a ruční zásah pro nevratné (smlouva, výplata). Po zastavení procesu pracovníci krok žádosti přeskočí.
5. Test: každý krok selže → proces skončí v definovaném stavu; kompenzace selže → ruční zásah.

Na co si dát pozor:
- Saga není distribuovaná transakce: mezi kroky je nekonzistence viditelná a pozdní výsledek může dorazit i po kompenzaci.
- Kompenzace také může selhat.

## Co nesmíš měnit

- Stávající veřejné API a chování endpointů kalkulačky, které teď funguje.
- Databázové schéma stávajících tabulek (nové tabulky/migrace jsou v pořádku, přejmenování a mazání ne).
- Cizí testy, seed data a existující hodnoty. Když je změna nutná, dej ji do samostatného commitu a uveď ji. Pokud změna tvaru události nebo nový konzument nutně mění existující test, uprav ho v samostatném commitu a v závěru uveď proč.
- Veřejné kontrakty (API, schémata událostí) bez zpětné kompatibility.

## Hotovo, když

- Tabulka přechodů a test pro selhání každého kroku.
- Stav procesu přežije restart (test: nová instance nad stejným úložištěm pokračuje).
- Kompenzace jsou idempotentní; po zastavení procesu se další kroky neprovedou.
- Testy projdou stávajícím test runnerem; lint a build projdou, pokud je projekt má.
- V závěru uveď: co jsi změnil, co jsi předpokládal, co zbývá.

# Úkol pro coding agenta: Saga / Process Manager

Stack: Web (HTML/JS nebo stack aplikace). Režim: challenge.
Cíl: Zavést Process Manager pro onboarding hypotéky se stavem, timeouty a kompenzací.

## Kontext existujícího kódu

Pracuješ v existujícím projektu (webová aplikace: frontend v prohlížeči, případně s vlastním backendem. Když má projekt backend, patří event store, broker a služby na backend a body o endpointech a tabulkách se týkají jeho. Když backend nemá, použij IndexedDB v prohlížeči a v testech `fake-indexeddb`. Framework a test runner projektu zachovej; nové závislosti přidávej jen s odůvodněním.).
Doména: hypoteční kalkulačka, která se postupně mění v event-driven systém (kalkulačka, rizika, schvalování, identita, účet, dokumenty, výplata).
Předpoklad: projekt má asynchronní onboarding přes broker (identita → účet → smlouva → výplata). Pokud ne, nejdřív založ minimální tok těchto kroků v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde dnes onboarding koordinuje jeden velký service/handler, nebo zda jde o choreografii. Synchronní handler s veřejným API neměň.
- Které kroky jsou vratné a čím (kompenzační akce). Chybějící navrhni jako idempotentní endpoint.
- Úložiště pro stav procesu.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (process manager, saga), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji. Když chybí, navrhni ji v plánu.

## Očekávané chování

Onboarding jde přes víc služeb a nejde obalit jednou transakcí. Process Manager (Saga) drží stav per žádost, vydává příkazy a reaguje na výsledky; krok, který nedoběhne do lhůty, zopakuje. Když krok selže natrvalo, rollback nejde: PM vrátí hotové vratné kroky a pro nevratné založí úkol pro člověka. Příklad: výplata selže (limit, AML); PM vydá příkaz zavřít účet (výsledek `MortgageAccountClosed`), na vydanou smlouvu založí úkol a po jeho vyřízení proces skončí `compensated`.

## Zadání (Challenge)

Zaveď Process Manager pro onboarding hypotéky a zajisti, aby selhání libovolného kroku skončilo v konzistentním stavu.

Technická specifika (Web (HTML/JS nebo stack aplikace)): Orchestrace a trvalý stav na serveru; UI jen čte stav a zobrazí ho jako stavový automat (xstate, smí-li projekt přidat závislost; jinak čistá funkce).

Postup si zvol sám. Pasti v tomto tématu nejsou vypsané: najdi je (souběh, opakované doručení, pořadí, selhání uprostřed) a ke každé napiš test, který by ji odhalil. Na konci vypiš, jaké pasti jsi našel a které jsi vědomě nechal otevřené.

## Co nesmíš měnit

- Stávající veřejné API a chování endpointů kalkulačky, které teď funguje.
- Databázové schéma stávajících tabulek (nové tabulky/migrace jsou v pořádku, přejmenování a mazání ne).
- Cizí testy, seed data a existující hodnoty. Když je změna nutná, dej ji do samostatného commitu a uveď ji. Pokud změna tvaru události nebo nový konzument nutně mění existující test, uprav ho v samostatném commitu a v závěru uveď proč.
- Veřejné kontrakty (API, schémata událostí) bez zpětné kompatibility.

## Hotovo, když

- Tabulka přechodů a test pro selhání každého kroku.
- Stav procesu přežije restart (test: nová instance nad stejným úložištěm pokračuje).
- Kompenzace jsou idempotentní; po zastavení procesu se další kroky neprovedou.
- Testy projdou stávajícím test runnerem; lint a build projdou, pokud je projekt má.
- V závěru uveď: co jsi změnil, co jsi předpokládal, co zbývá.

Kopírovat prompt