Disbursement: offline služba a backlog

# Úkol pro coding agenta: Disbursement: offline služba a backlog

Stack: Java. Režim: s vedením.
Cíl: Zajistit, aby výpadek služby výplaty (neběží, nebo odpovídá pozdě) nezpůsobil ztrátu požadavku ani dvojí výplatu po jejím návratu.

## 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í tok žádosti až po smlouvu. Pokud je výplata jen synchronní volání, nejdřív založ minimální krok: zpráva o smlouvě (`LoanContractGenerated`) → konzument výplat → služba → `DisbursementScheduled`.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Jak se zprávy pro službu výplat perzistují (broker, fronta), kde jsou timeouty a jak dlouhý výpadek přežije politika opakování.
- Zda je výplata chráněna obchodním klíčem (applicationId) nebo idempotency key.
- Monitoring: kdo se dozví o rostoucí frontě.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (retry, limit rychlosti, sledování fronty), 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í

Offline služba výplat po návratu zpracuje backlog, který broker držel. Past: odesílatel po timeoutu pošle požadavek znovu; bez idempotentního příjemce se po návratu vyplatí dvakrát. Každý pokus proto nese stejný idempotency key. Příklad: pokus vyprší, služba ho přesto zapíše; opakování se stejným klíčem dostane původní výplatu (`200`), ne druhou.

## Konkrétní úkol

Technická specifika (Java): Unikátní index na `(application_id, step)`, listener s omezenou konkurencí.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: nakresli, co se děje při 30 s výpadku (fronta, timeout, opakování).
2. Zaveď idempotency key `<applicationId>:<krok procesu>` (např. `…:disbursement`) s unikátním omezením ve službě výplat, v jedné transakci s výplatou. Volání bez klíče beze změny.
3. Jedna politika na jednom místě (timeout pokusu, backoff, doba opakování, limit rychlosti, práh alarmu), v testech zkrácená. Neúspěšný pokus loguj jako provozní událost (druh selhání, další pokus nebo DLQ).
4. Alarm na stáří nejstarší zprávy ve frontě: práh delší než pokus s nejdelším backoffem, kratší než doba do DLQ.
5. Integrační test: offline → požadavek, který služba zpracuje až po timeoutu klienta → online → právě jedna výplata. Kontrola: bez klíče dvě výplaty.

Na co si dát pozor:
- Timeout kratší než běžná doba zpracování vyrábí duplicity sám.
- Při návratu služby backlog všechny zpracuje naráz: limituj rychlost, i pro opakování.
- Broker v paměti neochrání před výpadkem konzumenta; uveď to v závěru.

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

- Integrační test s výpadkem a pozdě zpracovaným požadavkem; kontrolní test bez klíče.
- Unikátní omezení na idempotency key ve službě výplat.
- Alarm na stáří fronty a limit rychlosti.
- 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: Disbursement: offline služba a backlog

Stack: Java. Režim: challenge.
Cíl: Zajistit, aby výpadek služby výplaty (neběží, nebo odpovídá pozdě) nezpůsobil ztrátu požadavku ani dvojí výplatu po jejím návratu.

## 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í tok žádosti až po smlouvu. Pokud je výplata jen synchronní volání, nejdřív založ minimální krok: zpráva o smlouvě (`LoanContractGenerated`) → konzument výplat → služba → `DisbursementScheduled`.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Jak se zprávy pro službu výplat perzistují (broker, fronta), kde jsou timeouty a jak dlouhý výpadek přežije politika opakování.
- Zda je výplata chráněna obchodním klíčem (applicationId) nebo idempotency key.
- Monitoring: kdo se dozví o rostoucí frontě.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (retry, limit rychlosti, sledování fronty), 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í

Offline služba výplat po návratu zpracuje backlog, který broker držel. Past: odesílatel po timeoutu pošle požadavek znovu; bez idempotentního příjemce se po návratu vyplatí dvakrát. Každý pokus proto nese stejný idempotency key. Příklad: pokus vyprší, služba ho přesto zapíše; opakování se stejným klíčem dostane původní výplatu (`200`), ne druhou.

## Zadání (Challenge)

Prokaž testem, že po výpadku služby výplat a opakování požadavku vznikne právě jedna výplata.

Technická specifika (Java): Unikátní index na `(application_id, step)`, listener s omezenou konkurencí.

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ž

- Integrační test s výpadkem a pozdě zpracovaným požadavkem; kontrolní test bez klíče.
- Unikátní omezení na idempotency key ve službě výplat.
- Alarm na stáří fronty a limit rychlosti.
- 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: Disbursement: offline služba a backlog

Stack: C#. Režim: s vedením.
Cíl: Zajistit, aby výpadek služby výplaty (neběží, nebo odpovídá pozdě) nezpůsobil ztrátu požadavku ani dvojí výplatu po jejím návratu.

## 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í tok žádosti až po smlouvu. Pokud je výplata jen synchronní volání, nejdřív založ minimální krok: zpráva o smlouvě (`LoanContractGenerated`) → konzument výplat → služba → `DisbursementScheduled`.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Jak se zprávy pro službu výplat perzistují (broker, fronta), kde jsou timeouty a jak dlouhý výpadek přežije politika opakování.
- Zda je výplata chráněna obchodním klíčem (applicationId) nebo idempotency key.
- Monitoring: kdo se dozví o rostoucí frontě.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (retry, limit rychlosti, sledování fronty), 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í

Offline služba výplat po návratu zpracuje backlog, který broker držel. Past: odesílatel po timeoutu pošle požadavek znovu; bez idempotentního příjemce se po návratu vyplatí dvakrát. Každý pokus proto nese stejný idempotency key. Příklad: pokus vyprší, služba ho přesto zapíše; opakování se stejným klíčem dostane původní výplatu (`200`), ne druhou.

## Konkrétní úkol

Technická specifika (C#): Unikátní index, consumer s `PrefetchCount`/`ConcurrentMessageLimit`.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: nakresli, co se děje při 30 s výpadku (fronta, timeout, opakování).
2. Zaveď idempotency key `<applicationId>:<krok procesu>` (např. `…:disbursement`) s unikátním omezením ve službě výplat, v jedné transakci s výplatou. Volání bez klíče beze změny.
3. Jedna politika na jednom místě (timeout pokusu, backoff, doba opakování, limit rychlosti, práh alarmu), v testech zkrácená. Neúspěšný pokus loguj jako provozní událost (druh selhání, další pokus nebo DLQ).
4. Alarm na stáří nejstarší zprávy ve frontě: práh delší než pokus s nejdelším backoffem, kratší než doba do DLQ.
5. Integrační test: offline → požadavek, který služba zpracuje až po timeoutu klienta → online → právě jedna výplata. Kontrola: bez klíče dvě výplaty.

Na co si dát pozor:
- Timeout kratší než běžná doba zpracování vyrábí duplicity sám.
- Při návratu služby backlog všechny zpracuje naráz: limituj rychlost, i pro opakování.
- Broker v paměti neochrání před výpadkem konzumenta; uveď to v závěru.

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

- Integrační test s výpadkem a pozdě zpracovaným požadavkem; kontrolní test bez klíče.
- Unikátní omezení na idempotency key ve službě výplat.
- Alarm na stáří fronty a limit rychlosti.
- 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: Disbursement: offline služba a backlog

Stack: C#. Režim: challenge.
Cíl: Zajistit, aby výpadek služby výplaty (neběží, nebo odpovídá pozdě) nezpůsobil ztrátu požadavku ani dvojí výplatu po jejím návratu.

## 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í tok žádosti až po smlouvu. Pokud je výplata jen synchronní volání, nejdřív založ minimální krok: zpráva o smlouvě (`LoanContractGenerated`) → konzument výplat → služba → `DisbursementScheduled`.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Jak se zprávy pro službu výplat perzistují (broker, fronta), kde jsou timeouty a jak dlouhý výpadek přežije politika opakování.
- Zda je výplata chráněna obchodním klíčem (applicationId) nebo idempotency key.
- Monitoring: kdo se dozví o rostoucí frontě.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (retry, limit rychlosti, sledování fronty), 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í

Offline služba výplat po návratu zpracuje backlog, který broker držel. Past: odesílatel po timeoutu pošle požadavek znovu; bez idempotentního příjemce se po návratu vyplatí dvakrát. Každý pokus proto nese stejný idempotency key. Příklad: pokus vyprší, služba ho přesto zapíše; opakování se stejným klíčem dostane původní výplatu (`200`), ne druhou.

## Zadání (Challenge)

Prokaž testem, že po výpadku služby výplat a opakování požadavku vznikne právě jedna výplata.

Technická specifika (C#): Unikátní index, consumer s `PrefetchCount`/`ConcurrentMessageLimit`.

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ž

- Integrační test s výpadkem a pozdě zpracovaným požadavkem; kontrolní test bez klíče.
- Unikátní omezení na idempotency key ve službě výplat.
- Alarm na stáří fronty a limit rychlosti.
- 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: Disbursement: offline služba a backlog

Stack: Web (HTML/JS nebo stack aplikace). Režim: s vedením.
Cíl: Zajistit, aby výpadek služby výplaty (neběží, nebo odpovídá pozdě) nezpůsobil ztrátu požadavku ani dvojí výplatu po jejím návratu.

## 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í tok žádosti až po smlouvu. Pokud je výplata jen synchronní volání, nejdřív založ minimální krok: zpráva o smlouvě (`LoanContractGenerated`) → konzument výplat → služba → `DisbursementScheduled`.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Jak se zprávy pro službu výplat perzistují (broker, fronta), kde jsou timeouty a jak dlouhý výpadek přežije politika opakování.
- Zda je výplata chráněna obchodním klíčem (applicationId) nebo idempotency key.
- Monitoring: kdo se dozví o rostoucí frontě.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (retry, limit rychlosti, sledování fronty), 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í

Offline služba výplat po návratu zpracuje backlog, který broker držel. Past: odesílatel po timeoutu pošle požadavek znovu; bez idempotentního příjemce se po návratu vyplatí dvakrát. Každý pokus proto nese stejný idempotency key. Příklad: pokus vyprší, služba ho přesto zapíše; opakování se stejným klíčem dostane původní výplatu (`200`), ne druhou.

## Konkrétní úkol

Technická specifika (Web (HTML/JS nebo stack aplikace)): S backendem konzument výplat na serveru a UI jen čte stav „výplata čeká“; bez backendu fronta v IndexedDB. Příkaz nikdy neopakuj bez idempotency key.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: nakresli, co se děje při 30 s výpadku (fronta, timeout, opakování).
2. Zaveď idempotency key `<applicationId>:<krok procesu>` (např. `…:disbursement`) s unikátním omezením ve službě výplat, v jedné transakci s výplatou. Volání bez klíče beze změny.
3. Jedna politika na jednom místě (timeout pokusu, backoff, doba opakování, limit rychlosti, práh alarmu), v testech zkrácená. Neúspěšný pokus loguj jako provozní událost (druh selhání, další pokus nebo DLQ).
4. Alarm na stáří nejstarší zprávy ve frontě: práh delší než pokus s nejdelším backoffem, kratší než doba do DLQ.
5. Integrační test: offline → požadavek, který služba zpracuje až po timeoutu klienta → online → právě jedna výplata. Kontrola: bez klíče dvě výplaty.

Na co si dát pozor:
- Timeout kratší než běžná doba zpracování vyrábí duplicity sám.
- Při návratu služby backlog všechny zpracuje naráz: limituj rychlost, i pro opakování.
- Broker v paměti neochrání před výpadkem konzumenta; uveď to v závěru.

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

- Integrační test s výpadkem a pozdě zpracovaným požadavkem; kontrolní test bez klíče.
- Unikátní omezení na idempotency key ve službě výplat.
- Alarm na stáří fronty a limit rychlosti.
- 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: Disbursement: offline služba a backlog

Stack: Web (HTML/JS nebo stack aplikace). Režim: challenge.
Cíl: Zajistit, aby výpadek služby výplaty (neběží, nebo odpovídá pozdě) nezpůsobil ztrátu požadavku ani dvojí výplatu po jejím návratu.

## 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í tok žádosti až po smlouvu. Pokud je výplata jen synchronní volání, nejdřív založ minimální krok: zpráva o smlouvě (`LoanContractGenerated`) → konzument výplat → služba → `DisbursementScheduled`.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Jak se zprávy pro službu výplat perzistují (broker, fronta), kde jsou timeouty a jak dlouhý výpadek přežije politika opakování.
- Zda je výplata chráněna obchodním klíčem (applicationId) nebo idempotency key.
- Monitoring: kdo se dozví o rostoucí frontě.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní infrastrukturu (retry, limit rychlosti, sledování fronty), 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í

Offline služba výplat po návratu zpracuje backlog, který broker držel. Past: odesílatel po timeoutu pošle požadavek znovu; bez idempotentního příjemce se po návratu vyplatí dvakrát. Každý pokus proto nese stejný idempotency key. Příklad: pokus vyprší, služba ho přesto zapíše; opakování se stejným klíčem dostane původní výplatu (`200`), ne druhou.

## Zadání (Challenge)

Prokaž testem, že po výpadku služby výplat a opakování požadavku vznikne právě jedna výplata.

Technická specifika (Web (HTML/JS nebo stack aplikace)): S backendem konzument výplat na serveru a UI jen čte stav „výplata čeká“; bez backendu fronta v IndexedDB. Příkaz nikdy neopakuj bez idempotency key.

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ž

- Integrační test s výpadkem a pozdě zpracovaným požadavkem; kontrolní test bez klíče.
- Unikátní omezení na idempotency key ve službě výplat.
- Alarm na stáří fronty a limit rychlosti.
- 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