Celý systém pod tlakem

# Úkol pro coding agenta: Celý systém pod tlakem

Stack: Java. Režim: s vedením.
Cíl: Sestavit test odolnosti (chaos test) celého onboardingu a podle něj určit, které obrany ještě chybí.

## 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 až po výplatu; chybějící obrany ukáže harness. Pokud tok chybí, nejdřív založ minimální tok v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Existující integrační/e2e testy onboardingu.
- Možnosti vkládání chyb: co při skládání systému bere čas, timery, náhodu a síť; tudy vlož poruchy a virtuální čas jako volitelné parametry (výchozí chování beze změny).
- Metriky: fronty, DLQ, stáří zpráv.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní testovací infrastrukturu (virtuální čas, PRNG, fake broker), 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í

Při všech poruchách najednou se obrany doplňují (Outbox, retry a DLQ, Inbox a idempotence, sekvence korelace, Saga) a žádná nestačí sama; se všemi proces doběhne konzistentně, jen pomaleji. Příklad: profil „duplicita“ (služba dokumentů zapíše smlouvu, odpověď se ztratí) najde dvě smlouvy pro jednu žádost.

## Konkrétní úkol

Technická specifika (Java): JUnit + Toxiproxy/Testcontainers nebo fake broker s injektovanými chybami.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: tabulka selhání × obrana × invariant. Ztráta: konzument chvíli neodebírá. Duplicita: doručení 2×, ztracené potvrzení publikace, ztracená odpověď po zápisu. Pořadí: zpráva jednomu konzumentovi přijde po další. Offline: služba, broker nebo prohlížeč. Pomalá služba: odpověď po timeoutu klienta, zápis proběhne.
2. Test harness s injektovanými chybami a pevným seedem: profil = jeden druh selhání, vlastní PRNG pro každý druh poruchy i jitter, po doběhu snímek světa (tabulky služeb, log brokeru, čtecí modely, stav procesu).
3. Invarianty po doběhu jako čisté funkce snímku (zdroj pravdy = tabulky služeb a log brokeru): dokončená žádost má právě jeden účet, jednu smlouvu a jednu výplatu, zamítnutá ani vrácená nic otevřeného; čtecí modely = zdroj pravdy; nic nevisí. Měř i vedlejší účinky (volání navíc, opakování, DLQ).
4. Spusť harness pro každý profil se seedy 1–10 a vypiš tabulku: profil × invariant, první seed porušení, chybějící obrana.
5. Oprav jednu mezeru: nejčastější porušení s obchodním dopadem, které jde opravit bez změny cizích testů. Zbytek zapiš do backlogu.

Na co si dát pozor:
- Test, který padá jednou za sto běhů, je horší než žádný: pevný seed a více seedů.
- Dočasnou mutací obrany ověř, že harness porušení opravdu najde.
- Cizí test citlivý na skutečný čas může padat už na výchozím stavu: neměň ho a uveď ho 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ž

- Test je reprodukovatelný: dva běhy se stejným seedem dají stejný otisk; seed je v názvu testu.
- Invarianty jsou explicitní (v kódu i v README).
- Otevřená rizika jsou v README, každé s testem; opravená mezera má test, který před opravou padal.
- 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: Celý systém pod tlakem

Stack: Java. Režim: challenge.
Cíl: Sestavit test odolnosti (chaos test) celého onboardingu a podle něj určit, které obrany ještě chybí.

## 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 až po výplatu; chybějící obrany ukáže harness. Pokud tok chybí, nejdřív založ minimální tok v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Existující integrační/e2e testy onboardingu.
- Možnosti vkládání chyb: co při skládání systému bere čas, timery, náhodu a síť; tudy vlož poruchy a virtuální čas jako volitelné parametry (výchozí chování beze změny).
- Metriky: fronty, DLQ, stáří zpráv.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní testovací infrastrukturu (virtuální čas, PRNG, fake broker), 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í

Při všech poruchách najednou se obrany doplňují (Outbox, retry a DLQ, Inbox a idempotence, sekvence korelace, Saga) a žádná nestačí sama; se všemi proces doběhne konzistentně, jen pomaleji. Příklad: profil „duplicita“ (služba dokumentů zapíše smlouvu, odpověď se ztratí) najde dvě smlouvy pro jednu žádost.

## Zadání (Challenge)

Napiš reprodukovatelný chaos test onboardingu s invarianty po doběhu a ukaž, které selhání ještě nejsou ošetřena.

Technická specifika (Java): JUnit + Toxiproxy/Testcontainers nebo fake broker s injektovanými chybami.

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 je reprodukovatelný: dva běhy se stejným seedem dají stejný otisk; seed je v názvu testu.
- Invarianty jsou explicitní (v kódu i v README).
- Otevřená rizika jsou v README, každé s testem; opravená mezera má test, který před opravou padal.
- 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: Celý systém pod tlakem

Stack: C#. Režim: s vedením.
Cíl: Sestavit test odolnosti (chaos test) celého onboardingu a podle něj určit, které obrany ještě chybí.

## 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 až po výplatu; chybějící obrany ukáže harness. Pokud tok chybí, nejdřív založ minimální tok v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Existující integrační/e2e testy onboardingu.
- Možnosti vkládání chyb: co při skládání systému bere čas, timery, náhodu a síť; tudy vlož poruchy a virtuální čas jako volitelné parametry (výchozí chování beze změny).
- Metriky: fronty, DLQ, stáří zpráv.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní testovací infrastrukturu (virtuální čas, PRNG, fake broker), 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í

Při všech poruchách najednou se obrany doplňují (Outbox, retry a DLQ, Inbox a idempotence, sekvence korelace, Saga) a žádná nestačí sama; se všemi proces doběhne konzistentně, jen pomaleji. Příklad: profil „duplicita“ (služba dokumentů zapíše smlouvu, odpověď se ztratí) najde dvě smlouvy pro jednu žádost.

## Konkrétní úkol

Technická specifika (C#): xUnit + testovací harness brokeru (např. MassTransit test harness) s injektovanými chybami.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: tabulka selhání × obrana × invariant. Ztráta: konzument chvíli neodebírá. Duplicita: doručení 2×, ztracené potvrzení publikace, ztracená odpověď po zápisu. Pořadí: zpráva jednomu konzumentovi přijde po další. Offline: služba, broker nebo prohlížeč. Pomalá služba: odpověď po timeoutu klienta, zápis proběhne.
2. Test harness s injektovanými chybami a pevným seedem: profil = jeden druh selhání, vlastní PRNG pro každý druh poruchy i jitter, po doběhu snímek světa (tabulky služeb, log brokeru, čtecí modely, stav procesu).
3. Invarianty po doběhu jako čisté funkce snímku (zdroj pravdy = tabulky služeb a log brokeru): dokončená žádost má právě jeden účet, jednu smlouvu a jednu výplatu, zamítnutá ani vrácená nic otevřeného; čtecí modely = zdroj pravdy; nic nevisí. Měř i vedlejší účinky (volání navíc, opakování, DLQ).
4. Spusť harness pro každý profil se seedy 1–10 a vypiš tabulku: profil × invariant, první seed porušení, chybějící obrana.
5. Oprav jednu mezeru: nejčastější porušení s obchodním dopadem, které jde opravit bez změny cizích testů. Zbytek zapiš do backlogu.

Na co si dát pozor:
- Test, který padá jednou za sto běhů, je horší než žádný: pevný seed a více seedů.
- Dočasnou mutací obrany ověř, že harness porušení opravdu najde.
- Cizí test citlivý na skutečný čas může padat už na výchozím stavu: neměň ho a uveď ho 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ž

- Test je reprodukovatelný: dva běhy se stejným seedem dají stejný otisk; seed je v názvu testu.
- Invarianty jsou explicitní (v kódu i v README).
- Otevřená rizika jsou v README, každé s testem; opravená mezera má test, který před opravou padal.
- 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: Celý systém pod tlakem

Stack: C#. Režim: challenge.
Cíl: Sestavit test odolnosti (chaos test) celého onboardingu a podle něj určit, které obrany ještě chybí.

## 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 až po výplatu; chybějící obrany ukáže harness. Pokud tok chybí, nejdřív založ minimální tok v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Existující integrační/e2e testy onboardingu.
- Možnosti vkládání chyb: co při skládání systému bere čas, timery, náhodu a síť; tudy vlož poruchy a virtuální čas jako volitelné parametry (výchozí chování beze změny).
- Metriky: fronty, DLQ, stáří zpráv.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní testovací infrastrukturu (virtuální čas, PRNG, fake broker), 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í

Při všech poruchách najednou se obrany doplňují (Outbox, retry a DLQ, Inbox a idempotence, sekvence korelace, Saga) a žádná nestačí sama; se všemi proces doběhne konzistentně, jen pomaleji. Příklad: profil „duplicita“ (služba dokumentů zapíše smlouvu, odpověď se ztratí) najde dvě smlouvy pro jednu žádost.

## Zadání (Challenge)

Napiš reprodukovatelný chaos test onboardingu s invarianty po doběhu a ukaž, které selhání ještě nejsou ošetřena.

Technická specifika (C#): xUnit + testovací harness brokeru (např. MassTransit test harness) s injektovanými chybami.

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 je reprodukovatelný: dva běhy se stejným seedem dají stejný otisk; seed je v názvu testu.
- Invarianty jsou explicitní (v kódu i v README).
- Otevřená rizika jsou v README, každé s testem; opravená mezera má test, který před opravou padal.
- 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: Celý systém pod tlakem

Stack: Web (HTML/JS nebo stack aplikace). Režim: s vedením.
Cíl: Sestavit test odolnosti (chaos test) celého onboardingu a podle něj určit, které obrany ještě chybí.

## 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 až po výplatu; chybějící obrany ukáže harness. Pokud tok chybí, nejdřív založ minimální tok v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Existující integrační/e2e testy onboardingu.
- Možnosti vkládání chyb: co při skládání systému bere čas, timery, náhodu a síť; tudy vlož poruchy a virtuální čas jako volitelné parametry (výchozí chování beze změny).
- Metriky: fronty, DLQ, stáří zpráv.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní testovací infrastrukturu (virtuální čas, PRNG, fake broker), 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í

Při všech poruchách najednou se obrany doplňují (Outbox, retry a DLQ, Inbox a idempotence, sekvence korelace, Saga) a žádná nestačí sama; se všemi proces doběhne konzistentně, jen pomaleji. Příklad: profil „duplicita“ (služba dokumentů zapíše smlouvu, odpověď se ztratí) najde dvě smlouvy pro jednu žádost.

## Konkrétní úkol

Technická specifika (Web (HTML/JS nebo stack aplikace)): Vitest s deterministickým PRNG (seed) a fake časem: hodiny a časovač posouvá jen harness. Běh je celý v jednom procesu bez sítě (API, HTTP handlery služeb, broker v paměti); fake timery nad skutečným HTTP reprodukovatelné nejsou.

Postupuj po krocích. Po bodu 1 (plán) napiš, co zjistíš a co navrhuješ, a počkej na potvrzení:
1. Plán: tabulka selhání × obrana × invariant. Ztráta: konzument chvíli neodebírá. Duplicita: doručení 2×, ztracené potvrzení publikace, ztracená odpověď po zápisu. Pořadí: zpráva jednomu konzumentovi přijde po další. Offline: služba, broker nebo prohlížeč. Pomalá služba: odpověď po timeoutu klienta, zápis proběhne.
2. Test harness s injektovanými chybami a pevným seedem: profil = jeden druh selhání, vlastní PRNG pro každý druh poruchy i jitter, po doběhu snímek světa (tabulky služeb, log brokeru, čtecí modely, stav procesu).
3. Invarianty po doběhu jako čisté funkce snímku (zdroj pravdy = tabulky služeb a log brokeru): dokončená žádost má právě jeden účet, jednu smlouvu a jednu výplatu, zamítnutá ani vrácená nic otevřeného; čtecí modely = zdroj pravdy; nic nevisí. Měř i vedlejší účinky (volání navíc, opakování, DLQ).
4. Spusť harness pro každý profil se seedy 1–10 a vypiš tabulku: profil × invariant, první seed porušení, chybějící obrana.
5. Oprav jednu mezeru: nejčastější porušení s obchodním dopadem, které jde opravit bez změny cizích testů. Zbytek zapiš do backlogu.

Na co si dát pozor:
- Test, který padá jednou za sto běhů, je horší než žádný: pevný seed a více seedů.
- Dočasnou mutací obrany ověř, že harness porušení opravdu najde.
- Cizí test citlivý na skutečný čas může padat už na výchozím stavu: neměň ho a uveď ho 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ž

- Test je reprodukovatelný: dva běhy se stejným seedem dají stejný otisk; seed je v názvu testu.
- Invarianty jsou explicitní (v kódu i v README).
- Otevřená rizika jsou v README, každé s testem; opravená mezera má test, který před opravou padal.
- 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: Celý systém pod tlakem

Stack: Web (HTML/JS nebo stack aplikace). Režim: challenge.
Cíl: Sestavit test odolnosti (chaos test) celého onboardingu a podle něj určit, které obrany ještě chybí.

## 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 až po výplatu; chybějící obrany ukáže harness. Pokud tok chybí, nejdřív založ minimální tok v paměti.

Nejdřív čti, nic neměň. Najdi a stručně shrň:
- Existující integrační/e2e testy onboardingu.
- Možnosti vkládání chyb: co při skládání systému bere čas, timery, náhodu a síť; tudy vlož poruchy a virtuální čas jako volitelné parametry (výchozí chování beze změny).
- Metriky: fronty, DLQ, stáří zpráv.
- Které z těchto částí už v projektu existují a které chybí. Než napíšeš vlastní testovací infrastrukturu (virtuální čas, PRNG, fake broker), 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í

Při všech poruchách najednou se obrany doplňují (Outbox, retry a DLQ, Inbox a idempotence, sekvence korelace, Saga) a žádná nestačí sama; se všemi proces doběhne konzistentně, jen pomaleji. Příklad: profil „duplicita“ (služba dokumentů zapíše smlouvu, odpověď se ztratí) najde dvě smlouvy pro jednu žádost.

## Zadání (Challenge)

Napiš reprodukovatelný chaos test onboardingu s invarianty po doběhu a ukaž, které selhání ještě nejsou ošetřena.

Technická specifika (Web (HTML/JS nebo stack aplikace)): Vitest s deterministickým PRNG (seed) a fake časem: hodiny a časovač posouvá jen harness. Běh je celý v jednom procesu bez sítě (API, HTTP handlery služeb, broker v paměti); fake timery nad skutečným HTTP reprodukovatelné nejsou.

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 je reprodukovatelný: dva běhy se stejným seedem dají stejný otisk; seed je v názvu testu.
- Invarianty jsou explicitní (v kódu i v README).
- Otevřená rizika jsou v README, každé s testem; opravená mezera má test, který před opravou padal.
- 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