Jak předávat práci mezi fázemi procesu

"Export je opravený, zbývá ho ověřit" - a tím práce skončila. Druhý den otevřete projekt a nevíte, které soubory se změnily, na jaké verzi se export prohlížel ani kde se ověřování zastavilo.

Abyste mohli pokračovat bez opakovaného zkoumání, další fáze potřebuje uložený výsledek, informace o ověřeních a nejbližší krok. Ukážeme si to na jednom úkolu: může na něm pracovat jedna relace, několik řešitelů nebo vy sami na dvakrát.

Předejte výsledek, který lze otevřít

V seznamu nákupů nefunguje export do CSV. Požadavek: export obsahuje jen zobrazené řádky a zachovává jejich pořadí. U prázdného seznamu jsme se dohodli ponechat řádek záhlaví bez datových řádků. Formát sloupců ani oddělovač měnit nemusíte.

Místo "opraveno, zbývá ověřit" zanecháme záznam, podle kterého lze najít změny a pokračovat v práci. Hashy a výsledky níže jsou smyšlené: jde o výukový příklad, žádné skutečné běhy za nimi nejsou.

HANDOFF
Cíl: CSV obsahuje jen zobrazené řádky v jejich aktuálním pořadí.
Vstupní verze: výchozí commit 4f1c2ab.
Předaný stav: commit 9d3e740 ve větvi fix-export, žádné další úpravy.
Výsledek: src/export-csv.js - export načítá seznam po filtrování a řazení.
Ruční ověření na 9d3e740: původní záznamy A, B, C; na obrazovce C, A;
  v CSV jsou datové řádky C, A, záznam B chybí. Záhlaví nepočítáme jako záznam.
Neověřeno: prázdný seznam; režim "jen nedokončené".
Rozhodnutí: formát sloupců ani oddělovač neměníme.
Další krok: hlavní relace ověří dva zbývající scénáře.
Stav celého úkolu: ověřování není dokončeno.

Písmena zastupují tři záznamy v seznamu. Scénář ověřuje dvě vlastnosti najednou: skrytý záznam B se do exportu nedostal a pořadí C, A odpovídá obrazovce. Nestačí jen získat dva řádky ze seznamu, ve kterém jsou pouze dva - takový výsledek by měl i export bez filtrování.

Záznam můžete uložit do souboru HANDOFF.md nebo ho doplnit do existujícího dokumentu k úkolu. Žádný povinný standard pro pole není. Důležité je, aby další řešitel mohl záznam otevřít spolu s potřebnými soubory, i když nemá přístup k předchozí konverzaci.

Pokud se ověřovalo příkazem, uveďte ho spolu se skutečným výsledkem a verzí kódu. "12 z 12 prošlo" nevysvětluje, jaké chování se ověřovalo. U ručního scénáře jsou potřeba vstupní data, provedená akce a pozorovaný výsledek jako v příkladu výše.

Stanovte podmínky vstupu a výstupu

Předání je užitečné, když další fáze ví, zda má dost informací. U našeho úkolu to lze popsat třemi řádky.

Rozhodující je pravý sloupec. Při přechodu k ověřování odpovídá na otázku "můžeme začít ověřovat?". I podrobně popsaná úprava může být chybná. A i dokončené ověření může vrátit chybu k opravě: použitelný report nemusí hlásit úspěch.

Pokud verze chybí, nejprve zjistěte aktuální stav souborů. Ověřit ho můžete, ale starý report na něj bez porovnání nepřenášejte. Jednotlivé fáze nevyžadují samostatné agenty ani dokumenty: menší úkol může projít všemi třemi v jedné relaci s jedinou poznámkou.

Zachovejte schválený stav

Při předávání se snadno smíchají tři různé věci:

• uložený stav kódu - konkrétní verze, kterou lze obnovit;
• poznámka o průběhu práce - co se udělalo, ověřilo a dohodlo;
• přijetí výsledku - rozhodnutí, že výsledek stačí ke splnění cíle.

Commit ukazuje soubory, které obsahuje. Pokud po něm zůstaly další změny, odkaz už nepopisuje celý předávaný stav: tyto úpravy je také potřeba uložit a uvést zvlášť, včetně nových souborů. Při předání sady změn uveďte i výchozí verzi, vůči které je posuzujete. Samotný odkaz na větev nestačí, protože větev se dál mění.

Představte si, že záznam uvádí 9d3e740, ale soubor s exportem byl po něm ještě upraven. Příjemce vidí známý hash, ale pracuje s jiným kódem. Nejprve zjistí, co se změnilo. Pokud úprava zasáhla výběr nebo pořadí řádků, dřívější ověření C, A už nepotvrzuje aktuální chování. Pokud se změnil jen text komentáře, samo o sobě to není důvod scénář opakovat.

Není nutné vytvářet commit po každém kroku ani spojovat vlastní úpravy s cizími do jednoho commitu. Důležité je, aby celý předávaný stav existoval a příjemce k němu měl přístup; způsob ukládání určují pravidla projektu. Pokud soubory chybí, nejprve zkontrolujte uloženou verzi. Když změny nejsou uložené nikde, samotná poznámka je nevrátí.

Obnovení konverzace samo o sobě nevrátí soubory do popsané verze. Snímky změn v Claude Code také nezachycují všechno: úpravy přes Bash se nesledují a obnova změn jiných řešitelů má omezení. Předání proto vychází z uložených souborů a jejich verze. Více: Checkpointing.

Zjistěte, proč se práce zastavila

"Nepovedlo se" může znamenat nejméně tři různé situace.

Místní běh se přerušil. Příkaz neskončil nebo se ověřování zastavilo uprostřed. Nejdřív zjistěte, co se stihlo provést a změnit. Pokud je příčina odstraněná a opakováním se již provedená akce nezdvojí, můžete nedokončený krok spustit znovu. V našem příkladu počítáme s jedním opakováním; pokud se přeruší i to, zaznamenáme důvod a co je potřeba k pokračování. Limit závisí na operaci a nekonečné opakování nic nevysvětlí.

Očekávané chování není jasné. Řešitel například neví, které řádky se mají při zapnutém filtru považovat za zobrazené. Nejprve se podívá na zaznamenaný požadavek. Pokud v něm odpověď není, zeptá se osoby odpovědné za požadavek. V opravě lze pokračovat až po odpovědi; opětovné spuštění ji nenahradí.

Nový fakt vyvrátil přijaté rozhodnutí. Ukázalo se, že CSV čte jiný program. Po upřesnění jsme odsouhlasili jiné sloupce a požadavek na pořadí zrušili. Práce se vrací k upřesnění: je potřeba zaznamenat nové kritérium a znovu posoudit úpravu i ověření, které na něm závisí. Dřívější scénář může být stále užitečný, ale už nepotvrzuje celý aktualizovaný úkol.

Tady se práce vrací k upřesnění, protože se změnilo původní rozhodnutí. Pokud požadavek zůstal stejný a chyba se našla v implementaci, stačí se vrátit ke změně. Znovu se posuzují výsledky, které závisí na dotčeném rozhodnutí.

Pokračujte od aktuálního místa

Při pokračování projděte těchto pět kroků:

1. přečtěte si celé předání, včetně neověřených věcí;
2. porovnejte předaný stav s dostupnými soubory a dalšími změnami;
3. zjistěte výsledek přerušené operace, pokud k nějaké došlo;
4. určete, které dřívější výsledky stále platí;
5. proveďte nejbližší nedokončený krok a aktualizujte záznam.

Vraťme se k původnímu příkladu, kde se požadavky nezměnily. Další relace otevřela předání a ověřila stav: commit 9d3e740 je dostupný, žádné další úpravy nejsou, data i podmínky ověřování zůstaly stejné. Scénář C, A už je dokončený a jeho výsledek stále platí. Opravu není potřeba psát znovu.

Příjemce teď ověří prázdný seznam. Podle požadavku má v CSV zůstat řádek záhlaví bez dat. V našem výukovém pokračování to dopadlo právě tak. Do záznamu stačí doplnit výsledek a nahradit zbývající krok:

Ruční ověření na 9d3e740: export prázdného seznamu obsahuje jen záhlaví.
Dříve ověřený scénář C, A stále platí.
Neověřeno: režim "jen nedokončené".
Další krok: hlavní relace ověří tento režim.
Stav celého úkolu: ověřování není dokončeno.

Předání se měnilo spolu s prací. Jeden ze dvou zbývajících scénářů je hotový, druhý zůstává v záznamu vidět. Částečný výsledek neuzavírá původní cíl; přesun ověřování do jiného úkolu vyžaduje samostatné rozhodnutí o změně rozsahu.

Pokud se běh přerušil, může být potřeba spustit scénář znovu od začátku: ne každý nástroj umí pokračovat uprostřed. Dříve dokončená ověření zůstávají platná, dokud jsou jejich kód, vstupní data i podmínky aktuální.

Kdo připravuje předání

Claude Code může shromáždit fakta, ověřit vstup další fáze a provést už odsouhlasený krok. Vy kontrolujete, zda záznam odpovídá souborům a výsledkům běhů. O sporných požadavcích a změně rozsahu rozhoduje člověk nebo pověřená osoba; v našem procesu výsledek nakonec schvaluje člověk.

Uložená verze pomůže v práci pokračovat, ale nerozšiřuje oprávnění toho, kdo na ní pracuje. Pokud má ověřit export, dostupný bod obnovy mu nedává svolení zároveň měnit formát sloupců. Hranice úkolu platí i po předání.