"Exportul e reparat, mai trebuie verificat" - și aici se încheie lucrul. A doua zi deschideți proiectul și nu mai știți ce fișiere s-au modificat, pe ce versiune ați verificat exportul și unde s-a oprit verificarea.
Pentru a continua fără să reluați investigația, etapa următoare are nevoie de rezultatul salvat, informațiile despre verificări și următorul pas concret. Să urmărim o astfel de predare pentru o singură sarcină: o poate gestiona o sesiune, mai mulți executanți sau chiar dumneavoastră, în două reprize.
Predați un rezultat pe care îl puteți deschide
Exportul în CSV al listei de cumpărături nu funcționează corect. Cerința: exportul include doar rândurile afișate și le păstrează ordinea. Pentru o listă goală, s-a convenit să rămână rândul cu antetul, fără rânduri de date. Formatul coloanelor și separatorul nu trebuie schimbate.
În loc de "reparat, mai trebuie verificat", lăsăm o înregistrare care vă ajută să găsiți modificările și să continuați lucrul. Hash-urile și rezultatele de mai jos sunt ipotetice: acesta este un exemplu didactic, nu rezultatul unor rulări reale.
HANDOFF
Scop: CSV-ul conține doar rândurile afișate, în ordinea lor curentă.
Versiunea de intrare: commit-ul de bază 4f1c2ab.
Starea predată: commit-ul 9d3e740 din branch-ul fix-export, fără modificări suplimentare.
Rezultat: src/export-csv.js - exportul preia lista după filtrare și sortare.
Verificat manual pe 9d3e740: înregistrările inițiale A, B, C; pe ecran C, A;
în CSV, rândurile de date C, A; înregistrarea B lipsește. Antetul nu se numără ca înregistrare.
Neverificat: lista goală; modul "doar cele nefinalizate".
Decizie: nu schimbăm formatul coloanelor și separatorul.
Pasul următor: sesiunea principală verifică cele două scenarii rămase.
Starea sarcinii în ansamblu: verificarea nu este încheiată.Literele reprezintă trei înregistrări din listă. Scenariul verifică două lucruri deodată: înregistrarea ascunsă B nu a ajuns în export, iar ordinea C, A corespunde ecranului. Nu e suficient să obțineți două rânduri dintr-o listă care are doar două: același rezultat ar apărea și la un export fără filtrare.
Puteți salva înregistrarea în HANDOFF.md sau o puteți adăuga la documentul existent al sarcinii. Nu există un standard obligatoriu pentru câmpuri. Important este ca următorul executant să poată deschide înregistrarea împreună cu fișierele necesare, chiar dacă nu are acces la conversația anterioară.
Dacă verificarea a fost făcută printr-o comandă, notați comanda, rezultatul efectiv și versiunea codului. "12 din 12 au trecut" nu explică ce comportament a fost verificat. Pentru un scenariu manual, sunt necesare datele inițiale, acțiunea și observația, ca în exemplul de mai sus.
E practic să-i cereți lui Claude Code o primă variantă: "Pregătește predarea pe baza fișierelor curente și a verificărilor efectuate. Separă faptele de presupuneri. Notează ce stare a fost verificată, ce a rămas și de unde trebuie continuat. Nu declara reușite verificările care nu au fost efectuate". Înainte să o folosiți, comparați versiunea cu fișierele, iar rezultatele cu notele verificărilor manuale sau cu ieșirea comenzilor.
Stabiliți condițiile de intrare și ieșire
Predarea e utilă atunci când etapa următoare poate stabili dacă informațiile primite sunt suficiente. Pentru sarcina noastră, putem descrie asta în trei rânduri.
| Etapă | Intrare | Ieșire | Criteriu de acceptare |
|---|---|---|---|
| Clarificare | Cerința și fișierele curente | Cauza erorii, cu trimitere la cod, și comportamentul așteptat | S-a stabilit ce rânduri se exportă, în ce ordine și ce se întâmplă când lista este goală |
| Modificare | Comportamentul convenit și versiunea de intrare | Modificarea exportului și nota despre verificarea locală | Starea salvată este disponibilă, fișierele modificate sunt numite, iar ce s-a verificat este separat de ce nu s-a verificat |
| Verificare | Starea predată și scenariile | Observații pentru fiecare scenariu, limitări și constatări | Rezultatele se referă la versiunea predată; fiecare scenariu are un rezultat, iar constatările indică pasul următor |
Coloana din dreapta e cea mai importantă. La trecerea la verificare, ea răspunde la întrebarea "putem începe verificarea?". Chiar și o modificare descrisă complet se poate dovedi greșită. Iar o verificare încheiată poate semnala o eroare care trebuie reparată: un raport util nu trebuie neapărat să anunțe un succes.
Dacă versiunea nu este precizată, stabiliți mai întâi starea curentă a fișierelor. O puteți verifica, dar nu puteți aplica la ea un raport vechi fără să le comparați. Etapele nu au nevoie de agenți și documente separate: o sarcină mică le poate parcurge pe toate trei într-o singură sesiune, cu o singură notă.
Salvați starea acceptată
Într-o predare, e ușor să confundați trei lucruri diferite:
- starea salvată a codului - o versiune concretă care poate fi restaurată;
- nota despre progres - ce s-a făcut, ce s-a verificat și ce s-a convenit;
- acceptarea rezultatului - decizia că ceea ce s-a făcut este suficient pentru scopul stabilit.
Un commit indică fișierele salvate în el. Dar dacă după commit au rămas modificări suplimentare, referința nu mai descrie întreaga stare predată: și acele modificări trebuie salvate și menționate separat, inclusiv fișierele noi. Când predați un set de modificări, indicați și versiunea inițială față de care le analizați. O referință doar la branch nu ajunge: acesta continuă să se schimbe.
Imaginați-vă: în notă este indicat 9d3e740, dar fișierul de export a fost deja modificat după acel commit. Destinatarul recunoaște hash-ul, însă va lucra cu alt cod. Mai întâi află ce s-a schimbat. Dacă modificarea a afectat selecția sau ordinea rândurilor, verificarea anterioară C, A nu confirmă comportamentul curent. Dacă s-a schimbat doar textul unui comentariu, asta nu e, de la sine, un motiv să repetați scenariul.
Nu e necesar să faceți commit după fiecare pas sau să adunați într-un singur commit modificările dumneavoastră și pe ale altora. Important este ca starea predată să existe complet și să fie accesibilă destinatarului; regulile proiectului stabilesc cum se salvează. Dacă fișierele nu sunt acolo, verificați mai întâi versiunea salvată. Dacă modificările nu au fost salvate nicăieri, o simplă notă nu le poate recupera.
Reluarea conversației nu readuce, de la sine, fișierele la versiunea descrisă. Nici instantaneele modificărilor din Claude Code nu includ toate schimbările: modificările făcute prin Bash nu sunt urmărite, iar restaurarea schimbărilor altor executanți are limitări. De aceea, predarea se bazează pe fișierele salvate și pe versiunea lor. Mai multe detalii: Checkpointing.
Identificați cauza opririi
"Nu a mers" poate însemna cel puțin trei situații diferite.
Rularea locală a fost întreruptă. Comanda nu s-a încheiat sau verificarea s-a oprit la jumătate. Aflați mai întâi ce a apucat să se execute și ce s-a modificat. Dacă problema a fost rezolvată, iar repetarea nu va dubla o acțiune deja făcută, puteți relua pasul neterminat. Pentru exemplul nostru, stabilim o singură încercare suplimentară; dacă se întrerupe și aceasta, notăm cauza opririi și ce trebuie făcut pentru a continua. Limita depinde de operație, iar repetarea la nesfârșit nu va clarifica nimic.
Comportamentul așteptat nu este clar. De exemplu, executantul nu știe ce rânduri trebuie considerate afișate atunci când filtrul este activat. Mai întâi consultă cerința consemnată. Dacă aceasta nu oferă răspunsul, formulează o întrebare pentru persoana responsabilă de cerință. Corecția poate continua după ce sosește răspunsul; repetarea rulării nu îl poate înlocui.
Un fapt nou infirmă decizia luată. S-a aflat că CSV-ul este citit de un alt program. După clarificări, s-a convenit asupra unui set diferit de coloane, iar cerința privind ordinea a fost eliminată. Lucrul revine la etapa de clarificare: trebuie consemnat noul criteriu și revizuite modificarea și verificările care depind de el. Scenariul verificat anterior poate rămâne util, dar nu mai confirmă întreaga sarcină actualizată.
Aici, revenirea duce la clarificare, deoarece s-a schimbat decizia inițială. Dacă cerința a rămas aceeași, iar eroarea a fost găsită în implementare, e suficient să reveniți la etapa de modificare. Se revizuiesc rezultatele care depind de decizia afectată.
Reluați lucrul din punctul actual
Când reluați lucrul, parcurgeți cinci pași:
- citiți integral nota de predare, inclusiv ce nu a fost verificat;
- comparați starea predată cu fișierele disponibile și cu modificările suplimentare;
- aflați rezultatul operației întrerupte, dacă a existat una;
- stabiliți care rezultate anterioare mai sunt valabile;
- efectuați următorul pas neterminat și actualizați înregistrarea.
Să revenim la exemplul inițial, în care cerințele nu s-au schimbat. Sesiunea următoare a deschis nota de predare și a verificat starea: commit-ul 9d3e740 este disponibil, nu există modificări suplimentare, iar datele și condițiile verificării sunt aceleași. Scenariul C, A este deja încheiat, iar rezultatul lui rămâne valabil. Nu e nevoie să scrieți din nou corecția.
Acum, destinatarul verifică lista goală. Conform cerinței, în CSV trebuie să rămână rândul cu antetul, fără date. În continuarea acestui exemplu didactic, exact acesta a fost rezultatul. E suficient să adăugați rezultatul în notă și să înlocuiți pasul rămas:
Verificat manual pe 9d3e740: exportul listei goale conține doar antetul.
Scenariul C, A verificat anterior rămâne valabil.
Neverificat: modul "doar cele nefinalizate".
Pasul următor: sesiunea principală verifică acest mod.
Starea sarcinii în ansamblu: verificarea nu este încheiată.Nota de predare s-a schimbat odată cu lucrul. Unul dintre cele două scenarii rămase a fost verificat, iar celălalt rămâne vizibil în notă. Un rezultat parțial nu atinge scopul inițial; mutarea verificării într-o altă sarcină necesită o decizie separată privind schimbarea domeniului sarcinii.
Dacă rularea a fost întreruptă, poate fi necesar să reluați scenariul întrerupt de la început: nu orice instrument știe să continue de la mijloc. Verificările încheiate anterior rămân valabile cât timp codul, datele de intrare și condițiile lor sunt actuale.
Se poate ca operația să fi fost executată chiar dacă nu a sosit un răspuns despre rezultat. Înainte să repetați trimiterea datelor, publicarea sau scrierea într-un fișier, aflați dacă acțiunea a avut deja loc. Locul de execuție nu garantează nimic: și o comandă locală poate adăuga aceleași date a doua oară. Cât timp rezultatul nu este cunoscut, repetarea nu trebuie să înlocuiască verificarea stării.
Cine pregătește predarea
Claude Code poate aduna faptele, verifica informațiile de intrare ale etapei următoare și efectua pasul deja convenit. Dumneavoastră verificați dacă nota corespunde fișierelor și rezultatelor rulărilor. Cerințele discutabile și schimbarea domeniului sarcinii sunt decise de o persoană sau de responsabilul desemnat; în procesul nostru, acceptarea finală îi revine tot unei persoane.
Versiunea salvată ajută la continuarea lucrului, dar nu extinde drepturile executantului. Dacă i s-a cerut să verifice exportul, existența unui punct de restaurare nu îi dă voie să schimbe și formatul coloanelor. Limitele sarcinii rămân valabile și după predare.
GO TO FULL VERSION