Synchronní začátek

# Úkol pro coding agenta: Synchronní začátek

Stack: Java. Režim: s vedením.
Cíl: Zmapovat synchronní tok kalkulačky a zjistit, kde se ztrácí historie a kde vzniká časová vazba. Zatím se nic nepřepisuje.

## 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).

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kontroler/endpoint, který ukládá výpočet, a vrstvu persistence (entita, repozitář, tabulka, případně IndexedDB).
- Všechna místa, kde se při odeslání žádosti volají jiné služby synchronně (HTTP/gRPC klienti).
- Kde se při UPDATE (nebo `put` v IndexedDB) přepisuje předchozí hodnota (příjem, cena, sazba).
- Které z těchto částí v projektu existují a které chybí, včetně brokeru, outboxu, retry, timeoutu a idempotence. Nic z toho teď nepiš.

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

Kalkulačka začíná jako CRUD: API přepíše řádek v databázi a volající čeká na všechny služby v řetězci. Cena: UPDATE smaže historii a jedna offline služba shodí celé odeslání (časová vazba). Příklad: po dvou uloženích (příjem 80 000 → 95 000 Kč) zůstane jen 95 000 a nikde není, kdo a kdy ho změnil. Když je při odeslání výplatní služba offline, volání selže, ale služby před ní už data zapsaly; opakované odeslání může založit duplicitní záznamy (např. druhý účet).

## Konkrétní úkol

Technická specifika (Java): Spring MVC kontroler a `@Transactional` service; výpadek simuluj mockem klienta (MockWebServer/WireMock).

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: nakresli sekvenci volání od UI po databázi a vypiš, kolik synchronních skoků má odeslání žádosti.
2. Ověř tři případy, kdy se ztratí informace: přepsaný příjem, přepsaná sazba zadaná uživatelem, kdo/kdy změnu udělal.
3. Napiš test, který zafixuje současné chování (characterization test): uložení dvou změn za sebou vrátí jen poslední hodnotu.
4. Napiš test, který simuluje výpadek poslední služby v řetězci (služba neběží; služba vrací 5xx) a ověří, co zůstane zapsané v předchozích službách, v jakém stavu zůstane žádost a co udělá opakované odeslání.
5. Shrň nálezy do krátkého dokumentu v `docs/` a navrhni, kde by vznikl event stream. Nic neimplementuj.

Na co si dát pozor:
- Nezaměňuj „test prošel“ s „chování je správné“: zachycuješ stávající stav, ne ideál.
- Částečný výpadek zahrnuje i kroky, které už zapsaly data.
- Characterization testy pojmenuj `*.characterization.test.*`; pozdější záměrná změna chování je smí upravit nebo nahradit.
- Služba, která neodpovídá, test bez timeoutu zasekne: zapiš to jako nález, netestuj.

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

- Existují characterization testy pro přepisování stavu a pro částečný výpadek řetězce.
- Dokument popisuje nálezy a návrh dalšího kroku.
- Produkční kód je beze změny.
- 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: Synchronní začátek

Stack: Java. Režim: challenge.
Cíl: Zmapovat synchronní tok kalkulačky a zjistit, kde se ztrácí historie a kde vzniká časová vazba. Zatím se nic nepřepisuje.

## 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).

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kontroler/endpoint, který ukládá výpočet, a vrstvu persistence (entita, repozitář, tabulka, případně IndexedDB).
- Všechna místa, kde se při odeslání žádosti volají jiné služby synchronně (HTTP/gRPC klienti).
- Kde se při UPDATE (nebo `put` v IndexedDB) přepisuje předchozí hodnota (příjem, cena, sazba).
- Které z těchto částí v projektu existují a které chybí, včetně brokeru, outboxu, retry, timeoutu a idempotence. Nic z toho teď nepiš.

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

Kalkulačka začíná jako CRUD: API přepíše řádek v databázi a volající čeká na všechny služby v řetězci. Cena: UPDATE smaže historii a jedna offline služba shodí celé odeslání (časová vazba). Příklad: po dvou uloženích (příjem 80 000 → 95 000 Kč) zůstane jen 95 000 a nikde není, kdo a kdy ho změnil. Když je při odeslání výplatní služba offline, volání selže, ale služby před ní už data zapsaly; opakované odeslání může založit duplicitní záznamy (např. druhý účet).

## Zadání (Challenge)

Zdokumentuj tok uložení a odeslání žádosti, zafixuj ho testy a prokaž, kde se ztrácí historie a kde je řetězec křehký. Bez změny produkčního kódu.

Technická specifika (Java): Spring MVC kontroler a `@Transactional` service; výpadek simuluj mockem klienta (MockWebServer/WireMock).

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ž

- Existují characterization testy pro přepisování stavu a pro částečný výpadek řetězce.
- Dokument popisuje nálezy a návrh dalšího kroku.
- Produkční kód je beze změny.
- 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: Synchronní začátek

Stack: C#. Režim: s vedením.
Cíl: Zmapovat synchronní tok kalkulačky a zjistit, kde se ztrácí historie a kde vzniká časová vazba. Zatím se nic nepřepisuje.

## 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).

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kontroler/endpoint, který ukládá výpočet, a vrstvu persistence (entita, repozitář, tabulka, případně IndexedDB).
- Všechna místa, kde se při odeslání žádosti volají jiné služby synchronně (HTTP/gRPC klienti).
- Kde se při UPDATE (nebo `put` v IndexedDB) přepisuje předchozí hodnota (příjem, cena, sazba).
- Které z těchto částí v projektu existují a které chybí, včetně brokeru, outboxu, retry, timeoutu a idempotence. Nic z toho teď nepiš.

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

Kalkulačka začíná jako CRUD: API přepíše řádek v databázi a volající čeká na všechny služby v řetězci. Cena: UPDATE smaže historii a jedna offline služba shodí celé odeslání (časová vazba). Příklad: po dvou uloženích (příjem 80 000 → 95 000 Kč) zůstane jen 95 000 a nikde není, kdo a kdy ho změnil. Když je při odeslání výplatní služba offline, volání selže, ale služby před ní už data zapsaly; opakované odeslání může založit duplicitní záznamy (např. druhý účet).

## Konkrétní úkol

Technická specifika (C#): ASP.NET Core controller a EF Core `DbContext`; výpadek simuluj `HttpMessageHandler` stubem.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: nakresli sekvenci volání od UI po databázi a vypiš, kolik synchronních skoků má odeslání žádosti.
2. Ověř tři případy, kdy se ztratí informace: přepsaný příjem, přepsaná sazba zadaná uživatelem, kdo/kdy změnu udělal.
3. Napiš test, který zafixuje současné chování (characterization test): uložení dvou změn za sebou vrátí jen poslední hodnotu.
4. Napiš test, který simuluje výpadek poslední služby v řetězci (služba neběží; služba vrací 5xx) a ověří, co zůstane zapsané v předchozích službách, v jakém stavu zůstane žádost a co udělá opakované odeslání.
5. Shrň nálezy do krátkého dokumentu v `docs/` a navrhni, kde by vznikl event stream. Nic neimplementuj.

Na co si dát pozor:
- Nezaměňuj „test prošel“ s „chování je správné“: zachycuješ stávající stav, ne ideál.
- Částečný výpadek zahrnuje i kroky, které už zapsaly data.
- Characterization testy pojmenuj `*.characterization.test.*`; pozdější záměrná změna chování je smí upravit nebo nahradit.
- Služba, která neodpovídá, test bez timeoutu zasekne: zapiš to jako nález, netestuj.

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

- Existují characterization testy pro přepisování stavu a pro částečný výpadek řetězce.
- Dokument popisuje nálezy a návrh dalšího kroku.
- Produkční kód je beze změny.
- 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: Synchronní začátek

Stack: C#. Režim: challenge.
Cíl: Zmapovat synchronní tok kalkulačky a zjistit, kde se ztrácí historie a kde vzniká časová vazba. Zatím se nic nepřepisuje.

## 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).

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kontroler/endpoint, který ukládá výpočet, a vrstvu persistence (entita, repozitář, tabulka, případně IndexedDB).
- Všechna místa, kde se při odeslání žádosti volají jiné služby synchronně (HTTP/gRPC klienti).
- Kde se při UPDATE (nebo `put` v IndexedDB) přepisuje předchozí hodnota (příjem, cena, sazba).
- Které z těchto částí v projektu existují a které chybí, včetně brokeru, outboxu, retry, timeoutu a idempotence. Nic z toho teď nepiš.

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

Kalkulačka začíná jako CRUD: API přepíše řádek v databázi a volající čeká na všechny služby v řetězci. Cena: UPDATE smaže historii a jedna offline služba shodí celé odeslání (časová vazba). Příklad: po dvou uloženích (příjem 80 000 → 95 000 Kč) zůstane jen 95 000 a nikde není, kdo a kdy ho změnil. Když je při odeslání výplatní služba offline, volání selže, ale služby před ní už data zapsaly; opakované odeslání může založit duplicitní záznamy (např. druhý účet).

## Zadání (Challenge)

Zdokumentuj tok uložení a odeslání žádosti, zafixuj ho testy a prokaž, kde se ztrácí historie a kde je řetězec křehký. Bez změny produkčního kódu.

Technická specifika (C#): ASP.NET Core controller a EF Core `DbContext`; výpadek simuluj `HttpMessageHandler` stubem.

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ž

- Existují characterization testy pro přepisování stavu a pro částečný výpadek řetězce.
- Dokument popisuje nálezy a návrh dalšího kroku.
- Produkční kód je beze změny.
- 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: Synchronní začátek

Stack: Web (HTML/JS nebo stack aplikace). Režim: s vedením.
Cíl: Zmapovat synchronní tok kalkulačky a zjistit, kde se ztrácí historie a kde vzniká časová vazba. Zatím se nic nepřepisuje.

## 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).

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kontroler/endpoint, který ukládá výpočet, a vrstvu persistence (entita, repozitář, tabulka, případně IndexedDB).
- Všechna místa, kde se při odeslání žádosti volají jiné služby synchronně (HTTP/gRPC klienti).
- Kde se při UPDATE (nebo `put` v IndexedDB) přepisuje předchozí hodnota (příjem, cena, sazba).
- Které z těchto částí v projektu existují a které chybí, včetně brokeru, outboxu, retry, timeoutu a idempotence. Nic z toho teď nepiš.

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

Kalkulačka začíná jako CRUD: API přepíše řádek v databázi a volající čeká na všechny služby v řetězci. Cena: UPDATE smaže historii a jedna offline služba shodí celé odeslání (časová vazba). Příklad: po dvou uloženích (příjem 80 000 → 95 000 Kč) zůstane jen 95 000 a nikde není, kdo a kdy ho změnil. Když je při odeslání výplatní služba offline, volání selže, ale služby před ní už data zapsaly; opakované odeslání může založit duplicitní záznamy (např. druhý účet).

## Konkrétní úkol

Technická specifika (Web (HTML/JS nebo stack aplikace)): Najdi `fetch`/`axios` volání z formuláře kalkulačky a sleduj je až tam, kde se volají další služby. Výpadek simuluj tam, kde řetězec běží (na backendu zastavená služba nebo dvojník klienta přes `vi.fn()`); MSW jen, když ho projekt už má.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: nakresli sekvenci volání od UI po databázi a vypiš, kolik synchronních skoků má odeslání žádosti.
2. Ověř tři případy, kdy se ztratí informace: přepsaný příjem, přepsaná sazba zadaná uživatelem, kdo/kdy změnu udělal.
3. Napiš test, který zafixuje současné chování (characterization test): uložení dvou změn za sebou vrátí jen poslední hodnotu.
4. Napiš test, který simuluje výpadek poslední služby v řetězci (služba neběží; služba vrací 5xx) a ověří, co zůstane zapsané v předchozích službách, v jakém stavu zůstane žádost a co udělá opakované odeslání.
5. Shrň nálezy do krátkého dokumentu v `docs/` a navrhni, kde by vznikl event stream. Nic neimplementuj.

Na co si dát pozor:
- Nezaměňuj „test prošel“ s „chování je správné“: zachycuješ stávající stav, ne ideál.
- Částečný výpadek zahrnuje i kroky, které už zapsaly data.
- Characterization testy pojmenuj `*.characterization.test.*`; pozdější záměrná změna chování je smí upravit nebo nahradit.
- Služba, která neodpovídá, test bez timeoutu zasekne: zapiš to jako nález, netestuj.

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

- Existují characterization testy pro přepisování stavu a pro částečný výpadek řetězce.
- Dokument popisuje nálezy a návrh dalšího kroku.
- Produkční kód je beze změny.
- 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: Synchronní začátek

Stack: Web (HTML/JS nebo stack aplikace). Režim: challenge.
Cíl: Zmapovat synchronní tok kalkulačky a zjistit, kde se ztrácí historie a kde vzniká časová vazba. Zatím se nic nepřepisuje.

## 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).

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Kontroler/endpoint, který ukládá výpočet, a vrstvu persistence (entita, repozitář, tabulka, případně IndexedDB).
- Všechna místa, kde se při odeslání žádosti volají jiné služby synchronně (HTTP/gRPC klienti).
- Kde se při UPDATE (nebo `put` v IndexedDB) přepisuje předchozí hodnota (příjem, cena, sazba).
- Které z těchto částí v projektu existují a které chybí, včetně brokeru, outboxu, retry, timeoutu a idempotence. Nic z toho teď nepiš.

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

Kalkulačka začíná jako CRUD: API přepíše řádek v databázi a volající čeká na všechny služby v řetězci. Cena: UPDATE smaže historii a jedna offline služba shodí celé odeslání (časová vazba). Příklad: po dvou uloženích (příjem 80 000 → 95 000 Kč) zůstane jen 95 000 a nikde není, kdo a kdy ho změnil. Když je při odeslání výplatní služba offline, volání selže, ale služby před ní už data zapsaly; opakované odeslání může založit duplicitní záznamy (např. druhý účet).

## Zadání (Challenge)

Zdokumentuj tok uložení a odeslání žádosti, zafixuj ho testy a prokaž, kde se ztrácí historie a kde je řetězec křehký. Bez změny produkčního kódu.

Technická specifika (Web (HTML/JS nebo stack aplikace)): Najdi `fetch`/`axios` volání z formuláře kalkulačky a sleduj je až tam, kde se volají další služby. Výpadek simuluj tam, kde řetězec běží (na backendu zastavená služba nebo dvojník klienta přes `vi.fn()`); MSW jen, když ho projekt už má.

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ž

- Existují characterization testy pro přepisování stavu a pro částečný výpadek řetězce.
- Dokument popisuje nálezy a návrh dalšího kroku.
- Produkční kód je beze změny.
- 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