Document Service: pořadí doručení

# Úkol pro coding agenta: Document Service: pořadí doručení

Stack: Java. Režim: s vedením.
Cíl: Ošetřit doručení mimo pořadí ve čtecím modelu stavu žádosti a v procesu Document Service (úvěrová smlouva) pomocí sekvenčního čísla v rámci korelace.

## 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á broker a tok zpráv žádosti s `correlationId`. Pokud ne, nejdřív založ minimální broker v paměti a tok odeslání → riziko → schválení → účet.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde projekce nebo handler předpokládá pořadí událostí. Chybí-li Document Service jako konzument, navrhni ho: smlouvu vytvoří, až má odeslání žádosti, schválení a `MortgageAccountOpened`.
- Zda zprávy nesou sekvenci/verzi streamu a correlationId.
- Možnosti brokeru: partition key / session pro zachování pořadí.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (broker klient, outbox, retry), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji.

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

Broker negarantuje pořadí: projekce, která aplikuje zprávy, jak přišly, „couvne“ nebo ztratí údaj. Zpráva toku nese sekvenci v rámci korelace (první 1, navazující o 1 víc než příčina); předčasnou konzument odloží, duplicitu zahodí. Pravda je ve zdroji zpráv, projekci jde přestavět. Příklad: schválení (3) přijde před rizikem (2); bez řazení stav žádosti ztratí skóre.

## Konkrétní úkol

Technická specifika (Java): Kafka: partition key = applicationId; jinde buffer v tabulce projekce.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: kde pořadí opravdu záleží (po agregátu / korelaci) a kde ne.
2. Přidej `sequence` (pořadí v toku žádosti) do integračních zpráv. Nesmí-li kontrakt dostat pole, dej ji do hlavičky zprávy; zprávu bez ní zpracuj dál.
3. Projekce i proces: událost s nižším číslem než očekávaným zahodit, s vyšším odložit, shodné aplikovat. Proces s vedlejším účinkem posune stav až po úspěšném účinku; rebuild účinek neopakuje.
4. Timeout bufferu odvozený z doby opakování producenta: po lhůtě alarm a doplnění zprávy ze zdroje; mezeru nepřeskakuj.
5. Test: všechna pořadí zpráv jedné žádosti (s duplicitami, dvě žádosti prokládaně) dávají stejný konečný stav; aspoň jeden test bez řazení selže.

Na co si dát pozor:
- Klíč partition drží pořadí jen v tématu; tok přes víc témat řadí konzument.
- Konzument řazený podle sekvence odebírá všechna témata toku, jinak čeká navždy.

## 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ž

- Test všech pořadí (s duplicitami) a test, který bez řazení selže.
- Duplicity se neaplikují dvakrát; účinek procesu proběhne jednou.
- Existuje příkaz pro rebuild (endpoint nebo CLI).
- 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: Document Service: pořadí doručení

Stack: Java. Režim: challenge.
Cíl: Ošetřit doručení mimo pořadí ve čtecím modelu stavu žádosti a v procesu Document Service (úvěrová smlouva) pomocí sekvenčního čísla v rámci korelace.

## 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á broker a tok zpráv žádosti s `correlationId`. Pokud ne, nejdřív založ minimální broker v paměti a tok odeslání → riziko → schválení → účet.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde projekce nebo handler předpokládá pořadí událostí. Chybí-li Document Service jako konzument, navrhni ho: smlouvu vytvoří, až má odeslání žádosti, schválení a `MortgageAccountOpened`.
- Zda zprávy nesou sekvenci/verzi streamu a correlationId.
- Možnosti brokeru: partition key / session pro zachování pořadí.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (broker klient, outbox, retry), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji.

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

Broker negarantuje pořadí: projekce, která aplikuje zprávy, jak přišly, „couvne“ nebo ztratí údaj. Zpráva toku nese sekvenci v rámci korelace (první 1, navazující o 1 víc než příčina); předčasnou konzument odloží, duplicitu zahodí. Pravda je ve zdroji zpráv, projekci jde přestavět. Příklad: schválení (3) přijde před rizikem (2); bez řazení stav žádosti ztratí skóre.

## Zadání (Challenge)

Zajisti, aby čtecí model nezávisel na pořadí doručení událostí, a umožni jeho přestavbu z event store.

Technická specifika (Java): Kafka: partition key = applicationId; jinde buffer v tabulce projekce.

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ž

- Test všech pořadí (s duplicitami) a test, který bez řazení selže.
- Duplicity se neaplikují dvakrát; účinek procesu proběhne jednou.
- Existuje příkaz pro rebuild (endpoint nebo CLI).
- 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: Document Service: pořadí doručení

Stack: C#. Režim: s vedením.
Cíl: Ošetřit doručení mimo pořadí ve čtecím modelu stavu žádosti a v procesu Document Service (úvěrová smlouva) pomocí sekvenčního čísla v rámci korelace.

## 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á broker a tok zpráv žádosti s `correlationId`. Pokud ne, nejdřív založ minimální broker v paměti a tok odeslání → riziko → schválení → účet.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde projekce nebo handler předpokládá pořadí událostí. Chybí-li Document Service jako konzument, navrhni ho: smlouvu vytvoří, až má odeslání žádosti, schválení a `MortgageAccountOpened`.
- Zda zprávy nesou sekvenci/verzi streamu a correlationId.
- Možnosti brokeru: partition key / session pro zachování pořadí.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (broker klient, outbox, retry), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji.

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

Broker negarantuje pořadí: projekce, která aplikuje zprávy, jak přišly, „couvne“ nebo ztratí údaj. Zpráva toku nese sekvenci v rámci korelace (první 1, navazující o 1 víc než příčina); předčasnou konzument odloží, duplicitu zahodí. Pravda je ve zdroji zpráv, projekci jde přestavět. Příklad: schválení (3) přijde před rizikem (2); bez řazení stav žádosti ztratí skóre.

## Konkrétní úkol

Technická specifika (C#): Service Bus sessions nebo partition key; jinde buffer v tabulce projekce.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: kde pořadí opravdu záleží (po agregátu / korelaci) a kde ne.
2. Přidej `sequence` (pořadí v toku žádosti) do integračních zpráv. Nesmí-li kontrakt dostat pole, dej ji do hlavičky zprávy; zprávu bez ní zpracuj dál.
3. Projekce i proces: událost s nižším číslem než očekávaným zahodit, s vyšším odložit, shodné aplikovat. Proces s vedlejším účinkem posune stav až po úspěšném účinku; rebuild účinek neopakuje.
4. Timeout bufferu odvozený z doby opakování producenta: po lhůtě alarm a doplnění zprávy ze zdroje; mezeru nepřeskakuj.
5. Test: všechna pořadí zpráv jedné žádosti (s duplicitami, dvě žádosti prokládaně) dávají stejný konečný stav; aspoň jeden test bez řazení selže.

Na co si dát pozor:
- Klíč partition drží pořadí jen v tématu; tok přes víc témat řadí konzument.
- Konzument řazený podle sekvence odebírá všechna témata toku, jinak čeká navždy.

## 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ž

- Test všech pořadí (s duplicitami) a test, který bez řazení selže.
- Duplicity se neaplikují dvakrát; účinek procesu proběhne jednou.
- Existuje příkaz pro rebuild (endpoint nebo CLI).
- 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: Document Service: pořadí doručení

Stack: C#. Režim: challenge.
Cíl: Ošetřit doručení mimo pořadí ve čtecím modelu stavu žádosti a v procesu Document Service (úvěrová smlouva) pomocí sekvenčního čísla v rámci korelace.

## 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á broker a tok zpráv žádosti s `correlationId`. Pokud ne, nejdřív založ minimální broker v paměti a tok odeslání → riziko → schválení → účet.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde projekce nebo handler předpokládá pořadí událostí. Chybí-li Document Service jako konzument, navrhni ho: smlouvu vytvoří, až má odeslání žádosti, schválení a `MortgageAccountOpened`.
- Zda zprávy nesou sekvenci/verzi streamu a correlationId.
- Možnosti brokeru: partition key / session pro zachování pořadí.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (broker klient, outbox, retry), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji.

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

Broker negarantuje pořadí: projekce, která aplikuje zprávy, jak přišly, „couvne“ nebo ztratí údaj. Zpráva toku nese sekvenci v rámci korelace (první 1, navazující o 1 víc než příčina); předčasnou konzument odloží, duplicitu zahodí. Pravda je ve zdroji zpráv, projekci jde přestavět. Příklad: schválení (3) přijde před rizikem (2); bez řazení stav žádosti ztratí skóre.

## Zadání (Challenge)

Zajisti, aby čtecí model nezávisel na pořadí doručení událostí, a umožni jeho přestavbu z event store.

Technická specifika (C#): Service Bus sessions nebo partition key; jinde buffer v tabulce projekce.

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ž

- Test všech pořadí (s duplicitami) a test, který bez řazení selže.
- Duplicity se neaplikují dvakrát; účinek procesu proběhne jednou.
- Existuje příkaz pro rebuild (endpoint nebo CLI).
- 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: Document Service: pořadí doručení

Stack: Web (HTML/JS nebo stack aplikace). Režim: s vedením.
Cíl: Ošetřit doručení mimo pořadí ve čtecím modelu stavu žádosti a v procesu Document Service (úvěrová smlouva) pomocí sekvenčního čísla v rámci korelace.

## 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á broker a tok zpráv žádosti s `correlationId`. Pokud ne, nejdřív založ minimální broker v paměti a tok odeslání → riziko → schválení → účet.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde projekce nebo handler předpokládá pořadí událostí. Chybí-li Document Service jako konzument, navrhni ho: smlouvu vytvoří, až má odeslání žádosti, schválení a `MortgageAccountOpened`.
- Zda zprávy nesou sekvenci/verzi streamu a correlationId.
- Možnosti brokeru: partition key / session pro zachování pořadí.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (broker klient, outbox, retry), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji.

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

Broker negarantuje pořadí: projekce, která aplikuje zprávy, jak přišly, „couvne“ nebo ztratí údaj. Zpráva toku nese sekvenci v rámci korelace (první 1, navazující o 1 víc než příčina); předčasnou konzument odloží, duplicitu zahodí. Pravda je ve zdroji zpráv, projekci jde přestavět. Příklad: schválení (3) přijde před rizikem (2); bez řazení stav žádosti ztratí skóre.

## Konkrétní úkol

Technická specifika (Web (HTML/JS nebo stack aplikace)): Buffer v paměti/IndexedDB a čistá funkce `applyInOrder(events)` otestovaná na permutacích; zdroj pro rebuild je log brokeru nebo úložiště zpráv.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: kde pořadí opravdu záleží (po agregátu / korelaci) a kde ne.
2. Přidej `sequence` (pořadí v toku žádosti) do integračních zpráv. Nesmí-li kontrakt dostat pole, dej ji do hlavičky zprávy; zprávu bez ní zpracuj dál.
3. Projekce i proces: událost s nižším číslem než očekávaným zahodit, s vyšším odložit, shodné aplikovat. Proces s vedlejším účinkem posune stav až po úspěšném účinku; rebuild účinek neopakuje.
4. Timeout bufferu odvozený z doby opakování producenta: po lhůtě alarm a doplnění zprávy ze zdroje; mezeru nepřeskakuj.
5. Test: všechna pořadí zpráv jedné žádosti (s duplicitami, dvě žádosti prokládaně) dávají stejný konečný stav; aspoň jeden test bez řazení selže.

Na co si dát pozor:
- Klíč partition drží pořadí jen v tématu; tok přes víc témat řadí konzument.
- Konzument řazený podle sekvence odebírá všechna témata toku, jinak čeká navždy.

## 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ž

- Test všech pořadí (s duplicitami) a test, který bez řazení selže.
- Duplicity se neaplikují dvakrát; účinek procesu proběhne jednou.
- Existuje příkaz pro rebuild (endpoint nebo CLI).
- 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: Document Service: pořadí doručení

Stack: Web (HTML/JS nebo stack aplikace). Režim: challenge.
Cíl: Ošetřit doručení mimo pořadí ve čtecím modelu stavu žádosti a v procesu Document Service (úvěrová smlouva) pomocí sekvenčního čísla v rámci korelace.

## 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á broker a tok zpráv žádosti s `correlationId`. Pokud ne, nejdřív založ minimální broker v paměti a tok odeslání → riziko → schválení → účet.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kde projekce nebo handler předpokládá pořadí událostí. Chybí-li Document Service jako konzument, navrhni ho: smlouvu vytvoří, až má odeslání žádosti, schválení a `MortgageAccountOpened`.
- Zda zprávy nesou sekvenci/verzi streamu a correlationId.
- Možnosti brokeru: partition key / session pro zachování pořadí.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (broker klient, outbox, retry), ověř, jestli ji projekt nebo organizace nemá jako hotovou knihovnu, a použij ji.

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

Broker negarantuje pořadí: projekce, která aplikuje zprávy, jak přišly, „couvne“ nebo ztratí údaj. Zpráva toku nese sekvenci v rámci korelace (první 1, navazující o 1 víc než příčina); předčasnou konzument odloží, duplicitu zahodí. Pravda je ve zdroji zpráv, projekci jde přestavět. Příklad: schválení (3) přijde před rizikem (2); bez řazení stav žádosti ztratí skóre.

## Zadání (Challenge)

Zajisti, aby čtecí model nezávisel na pořadí doručení událostí, a umožni jeho přestavbu z event store.

Technická specifika (Web (HTML/JS nebo stack aplikace)): Buffer v paměti/IndexedDB a čistá funkce `applyInOrder(events)` otestovaná na permutacích; zdroj pro rebuild je log brokeru nebo úložiště zpráv.

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ž

- Test všech pořadí (s duplicitami) a test, který bez řazení selže.
- Duplicity se neaplikují dvakrát; účinek procesu proběhne jednou.
- Existuje příkaz pro rebuild (endpoint nebo CLI).
- 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