Customer Identity: retry a DLQ

# Úkol pro coding agenta: Customer Identity: retry a DLQ

Stack: Java. Režim: s vedením.
Cíl: Přidat retry s exponenciálním backoffem a DLQ pro konzumenta událostí a umět zprávu z DLQ znovu přehrát.

## 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 s konzumenty a událost `MortgageApproved`. Pokud ne, nejdřív založ minimální broker v paměti a tuto událost.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Konzumenta zpráv Customer Identity (odebírá `MortgageApproved`, ověří totožnost u služby identity) a jeho dnešní zacházení s chybou (ack/nack). Pokud neexistuje, navrhni ho v plánu.
- Konfiguraci brokeru: retry, DLQ, max pokusy.
- Existující sdílené knihovny pro retry (např. `p-retry`, `cockatiel`; v .NET Polly) v projektu/organizaci.
- 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í

Služba identity může dočasně selhat; bez opakování se zpráva ztratí a proces visí. Retry s backoffem (pauzy 0,6 / 1,2 / 2,4 s) dá službě čas: zotaví-li se za 4 s, zpráva projde. Otrávená zpráva (vždy selže) skončí v DLQ a provoz ji po opravě vrátí redrivem. Příklad: odpověď 503 jednou → projde 2. pokus; 422 → rovnou DLQ.

## Konkrétní úkol

Technická specifika (Java): Spring Retry/Resilience4j nebo nativní retry+DLQ brokeru (Kafka `DefaultErrorHandler` + `DeadLetterPublishingRecoverer`).

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: které chyby jsou dočasné (retry) a které trvalé (rovnou DLQ).
2. Použij existující retry mechanismus projektu/brokeru, nepiš smyčku v handleru. Když žádný není, doplň do konzumenta brokeru opakované doručení zprávy po zpoždění a uveď to.
3. Backoff s jitterem a limit pokusů, po něm DLQ s hlavičkami: důvod, text chyby, počet pokusů, konzument.
4. Operační nástroj pro redrive (příkaz nebo endpoint): doručí zprávu jen konzumentovi, kterému selhala, ne zpět do tématu. Ochrana před nekonečnou smyčkou: zprávu nejde vrátit dvakrát, limit redrivů.
5. Testy (falešná služba s poruchou na povel, falešný časovač): dočasná chyba projde po 2. pokusu; trvalá chyba skončí v DLQ; redrive po opravě projde.

Na co si dát pozor:
- Retry bez idempotence vyrobí duplicity (řeší je idempotentní příjemce s Inboxem).
- Retry bouře: všichni opakují naráz, bez jitteru zahltí službu.

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

- Tři testy: dočasná chyba, trvalá chyba, redrive.
- DLQ nese důvod a počet pokusů.
- V handleru konzumenta není vlastní retry smyčka (retry příkazů se netýká).
- 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: Customer Identity: retry a DLQ

Stack: Java. Režim: challenge.
Cíl: Přidat retry s exponenciálním backoffem a DLQ pro konzumenta událostí a umět zprávu z DLQ znovu přehrát.

## 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 s konzumenty a událost `MortgageApproved`. Pokud ne, nejdřív založ minimální broker v paměti a tuto událost.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Konzumenta zpráv Customer Identity (odebírá `MortgageApproved`, ověří totožnost u služby identity) a jeho dnešní zacházení s chybou (ack/nack). Pokud neexistuje, navrhni ho v plánu.
- Konfiguraci brokeru: retry, DLQ, max pokusy.
- Existující sdílené knihovny pro retry (např. `p-retry`, `cockatiel`; v .NET Polly) v projektu/organizaci.
- 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í

Služba identity může dočasně selhat; bez opakování se zpráva ztratí a proces visí. Retry s backoffem (pauzy 0,6 / 1,2 / 2,4 s) dá službě čas: zotaví-li se za 4 s, zpráva projde. Otrávená zpráva (vždy selže) skončí v DLQ a provoz ji po opravě vrátí redrivem. Příklad: odpověď 503 jednou → projde 2. pokus; 422 → rovnou DLQ.

## Zadání (Challenge)

Zajisti, aby dočasné selhání konzumenta CustomerIdentityCreationRequested nevedlo ke ztrátě zprávy a trvalé selhání skončilo v DLQ s možností redrive.

Technická specifika (Java): Spring Retry/Resilience4j nebo nativní retry+DLQ brokeru (Kafka `DefaultErrorHandler` + `DeadLetterPublishingRecoverer`).

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ž

- Tři testy: dočasná chyba, trvalá chyba, redrive.
- DLQ nese důvod a počet pokusů.
- V handleru konzumenta není vlastní retry smyčka (retry příkazů se netýká).
- 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: Customer Identity: retry a DLQ

Stack: C#. Režim: s vedením.
Cíl: Přidat retry s exponenciálním backoffem a DLQ pro konzumenta událostí a umět zprávu z DLQ znovu přehrát.

## 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 s konzumenty a událost `MortgageApproved`. Pokud ne, nejdřív založ minimální broker v paměti a tuto událost.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Konzumenta zpráv Customer Identity (odebírá `MortgageApproved`, ověří totožnost u služby identity) a jeho dnešní zacházení s chybou (ack/nack). Pokud neexistuje, navrhni ho v plánu.
- Konfiguraci brokeru: retry, DLQ, max pokusy.
- Existující sdílené knihovny pro retry (např. `p-retry`, `cockatiel`; v .NET Polly) v projektu/organizaci.
- 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í

Služba identity může dočasně selhat; bez opakování se zpráva ztratí a proces visí. Retry s backoffem (pauzy 0,6 / 1,2 / 2,4 s) dá službě čas: zotaví-li se za 4 s, zpráva projde. Otrávená zpráva (vždy selže) skončí v DLQ a provoz ji po opravě vrátí redrivem. Příklad: odpověď 503 jednou → projde 2. pokus; 422 → rovnou DLQ.

## Konkrétní úkol

Technická specifika (C#): Retry/DLQ vrstvy messaging knihovny projektu (MassTransit/NServiceBus/Service Bus) nebo Polly.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: které chyby jsou dočasné (retry) a které trvalé (rovnou DLQ).
2. Použij existující retry mechanismus projektu/brokeru, nepiš smyčku v handleru. Když žádný není, doplň do konzumenta brokeru opakované doručení zprávy po zpoždění a uveď to.
3. Backoff s jitterem a limit pokusů, po něm DLQ s hlavičkami: důvod, text chyby, počet pokusů, konzument.
4. Operační nástroj pro redrive (příkaz nebo endpoint): doručí zprávu jen konzumentovi, kterému selhala, ne zpět do tématu. Ochrana před nekonečnou smyčkou: zprávu nejde vrátit dvakrát, limit redrivů.
5. Testy (falešná služba s poruchou na povel, falešný časovač): dočasná chyba projde po 2. pokusu; trvalá chyba skončí v DLQ; redrive po opravě projde.

Na co si dát pozor:
- Retry bez idempotence vyrobí duplicity (řeší je idempotentní příjemce s Inboxem).
- Retry bouře: všichni opakují naráz, bez jitteru zahltí službu.

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

- Tři testy: dočasná chyba, trvalá chyba, redrive.
- DLQ nese důvod a počet pokusů.
- V handleru konzumenta není vlastní retry smyčka (retry příkazů se netýká).
- 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: Customer Identity: retry a DLQ

Stack: C#. Režim: challenge.
Cíl: Přidat retry s exponenciálním backoffem a DLQ pro konzumenta událostí a umět zprávu z DLQ znovu přehrát.

## 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 s konzumenty a událost `MortgageApproved`. Pokud ne, nejdřív založ minimální broker v paměti a tuto událost.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Konzumenta zpráv Customer Identity (odebírá `MortgageApproved`, ověří totožnost u služby identity) a jeho dnešní zacházení s chybou (ack/nack). Pokud neexistuje, navrhni ho v plánu.
- Konfiguraci brokeru: retry, DLQ, max pokusy.
- Existující sdílené knihovny pro retry (např. `p-retry`, `cockatiel`; v .NET Polly) v projektu/organizaci.
- 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í

Služba identity může dočasně selhat; bez opakování se zpráva ztratí a proces visí. Retry s backoffem (pauzy 0,6 / 1,2 / 2,4 s) dá službě čas: zotaví-li se za 4 s, zpráva projde. Otrávená zpráva (vždy selže) skončí v DLQ a provoz ji po opravě vrátí redrivem. Příklad: odpověď 503 jednou → projde 2. pokus; 422 → rovnou DLQ.

## Zadání (Challenge)

Zajisti, aby dočasné selhání konzumenta CustomerIdentityCreationRequested nevedlo ke ztrátě zprávy a trvalé selhání skončilo v DLQ s možností redrive.

Technická specifika (C#): Retry/DLQ vrstvy messaging knihovny projektu (MassTransit/NServiceBus/Service Bus) nebo Polly.

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ž

- Tři testy: dočasná chyba, trvalá chyba, redrive.
- DLQ nese důvod a počet pokusů.
- V handleru konzumenta není vlastní retry smyčka (retry příkazů se netýká).
- 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: Customer Identity: retry a DLQ

Stack: Web (HTML/JS nebo stack aplikace). Režim: s vedením.
Cíl: Přidat retry s exponenciálním backoffem a DLQ pro konzumenta událostí a umět zprávu z DLQ znovu přehrát.

## 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 s konzumenty a událost `MortgageApproved`. Pokud ne, nejdřív založ minimální broker v paměti a tuto událost.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Konzumenta zpráv Customer Identity (odebírá `MortgageApproved`, ověří totožnost u služby identity) a jeho dnešní zacházení s chybou (ack/nack). Pokud neexistuje, navrhni ho v plánu.
- Konfiguraci brokeru: retry, DLQ, max pokusy.
- Existující sdílené knihovny pro retry (např. `p-retry`, `cockatiel`; v .NET Polly) v projektu/organizaci.
- 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í

Služba identity může dočasně selhat; bez opakování se zpráva ztratí a proces visí. Retry s backoffem (pauzy 0,6 / 1,2 / 2,4 s) dá službě čas: zotaví-li se za 4 s, zpráva projde. Otrávená zpráva (vždy selže) skončí v DLQ a provoz ji po opravě vrátí redrivem. Příklad: odpověď 503 jednou → projde 2. pokus; 422 → rovnou DLQ.

## Konkrétní úkol

Technická specifika (Web (HTML/JS nebo stack aplikace)): S backendem použij jeho brokera a DLQ; bez backendu opakování s backoffem a fronta selhání v IndexedDB.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: které chyby jsou dočasné (retry) a které trvalé (rovnou DLQ).
2. Použij existující retry mechanismus projektu/brokeru, nepiš smyčku v handleru. Když žádný není, doplň do konzumenta brokeru opakované doručení zprávy po zpoždění a uveď to.
3. Backoff s jitterem a limit pokusů, po něm DLQ s hlavičkami: důvod, text chyby, počet pokusů, konzument.
4. Operační nástroj pro redrive (příkaz nebo endpoint): doručí zprávu jen konzumentovi, kterému selhala, ne zpět do tématu. Ochrana před nekonečnou smyčkou: zprávu nejde vrátit dvakrát, limit redrivů.
5. Testy (falešná služba s poruchou na povel, falešný časovač): dočasná chyba projde po 2. pokusu; trvalá chyba skončí v DLQ; redrive po opravě projde.

Na co si dát pozor:
- Retry bez idempotence vyrobí duplicity (řeší je idempotentní příjemce s Inboxem).
- Retry bouře: všichni opakují naráz, bez jitteru zahltí službu.

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

- Tři testy: dočasná chyba, trvalá chyba, redrive.
- DLQ nese důvod a počet pokusů.
- V handleru konzumenta není vlastní retry smyčka (retry příkazů se netýká).
- 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: Customer Identity: retry a DLQ

Stack: Web (HTML/JS nebo stack aplikace). Režim: challenge.
Cíl: Přidat retry s exponenciálním backoffem a DLQ pro konzumenta událostí a umět zprávu z DLQ znovu přehrát.

## 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 s konzumenty a událost `MortgageApproved`. Pokud ne, nejdřív založ minimální broker v paměti a tuto událost.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Konzumenta zpráv Customer Identity (odebírá `MortgageApproved`, ověří totožnost u služby identity) a jeho dnešní zacházení s chybou (ack/nack). Pokud neexistuje, navrhni ho v plánu.
- Konfiguraci brokeru: retry, DLQ, max pokusy.
- Existující sdílené knihovny pro retry (např. `p-retry`, `cockatiel`; v .NET Polly) v projektu/organizaci.
- 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í

Služba identity může dočasně selhat; bez opakování se zpráva ztratí a proces visí. Retry s backoffem (pauzy 0,6 / 1,2 / 2,4 s) dá službě čas: zotaví-li se za 4 s, zpráva projde. Otrávená zpráva (vždy selže) skončí v DLQ a provoz ji po opravě vrátí redrivem. Příklad: odpověď 503 jednou → projde 2. pokus; 422 → rovnou DLQ.

## Zadání (Challenge)

Zajisti, aby dočasné selhání konzumenta CustomerIdentityCreationRequested nevedlo ke ztrátě zprávy a trvalé selhání skončilo v DLQ s možností redrive.

Technická specifika (Web (HTML/JS nebo stack aplikace)): S backendem použij jeho brokera a DLQ; bez backendu opakování s backoffem a fronta selhání v IndexedDB.

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ž

- Tři testy: dočasná chyba, trvalá chyba, redrive.
- DLQ nese důvod a počet pokusů.
- V handleru konzumenta není vlastní retry smyčka (retry příkazů se netýká).
- 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