Verificarea muncii cu check-work

Ce face

check-work pornește o verificare separată a muncii făcute în sesiune. Verificatorul reconstruiește cererea utilizatorului, urmărește ce a executat agentul, inspectează starea curentă și decide dacă rezultatul chiar acoperă cerința.

Verdictul final este unul dintre:

VERDICT: PASS

sau

VERDICT: FAIL

Nu este un rezumat mai frumos al aceleiași povești. Este o verificare adversarială: ce s-a cerut, ce s-a făcut, ce s-a promis dar nu s-a executat, ce a eșuat, ce lipsește și ce dovadă există acum.

All guides

Când îmi folosește

Folosește check-work când vrei să verifici că o livrare este completă, nu doar plauzibilă.

E potrivit pentru:

• modificări de cod, bugfix-uri și refactorizări;
• schimbări de configurare, CI, manifest, infrastructură sau fișiere asemănătoare codului;
• review-uri de securitate, arhitectură, performanță sau corectitudine;
• task-uri operaționale, cum ar fi pornirea unui job, deploy-ul sau crearea unei resurse;
• cercetare, diagnosticare sau analiză de cauză;
• întrebări tehnice unde răspunsul trebuie verificat contra surselor reale;
• sesiuni lungi cu follow-up-uri, corecții și mai multe livrabile.

Poți da și o zonă de focus. Atunci verificatorul citește contextul complet, dar verdictul este calibrat pe acea zonă. Exemplu: auth logic and JWT handling.

Cum îl invoc / declanșez

Invocarea canonică este:

/check-work [focus area]

Trigger-ele documentate sunt:

check work, verify changes, self-verify, /check-work, /check, /verify, /self-verify.

Focus area este opțională:

/check-work build and tests

/verify config changes

/self-verify auth logic

Există două moduri:

Same-turn: dacă verificarea este cerută împreună cu un task, agentul trebuie să termine task-ul complet înainte să pornească verificarea.

Standalone: dacă trimiți doar /check-work sau un alias, verificarea începe pe munca deja făcută în sesiunea curentă sau anterioară disponibilă în context.

Exemplu practic

Ai cerut o modificare într-un proiect: fix pentru o eroare, actualizare de configurare și rularea testelor. După ce agentul spune că a terminat, rulezi:

/check-work

Verificatorul transformă cererea într-un checklist concret. Apoi reconstruiește acțiunile: ce tool-uri au fost folosite, ce comenzi au rulat, ce a eșuat, ce a fost amânat către utilizator și ce a fost doar afirmat.

Dacă a existat cod, verificatorul citește modificările, fișierele relevante și contextul din jur. Pentru proiecte cu instrucțiuni de build sau test, verifică instrucțiunile relevante din repo și rulează comenzile configurate: build, teste, linters sau type-checkers, după caz. Poate concepe și verificări proprii: scripturi mici, comenzi de probă, apeluri locale sau verificări de stare.

Pentru task-uri operaționale, verifică rezultatul real: jobul există, resursa a fost creată, comanda a avut efect, statusul este cel așteptat. Pentru Q&A sau cercetare, verifică răspunsul contra materialului sursă. Proxy-urile nu ajung. Un build verde nu dovedește că cerința a fost acoperită.

Output / unde aterizează

Output-ul este un raport structurat în sesiune, nu un dashboard public separat.

Raportul include, după caz:

• checklist-ul cerințelor;
• urmă de acțiuni și rezultate;
• sumar de diff sau scope de cod;
• evaluare pe corectitudine, adecvare, exces și edge cases;
• rezultate exacte pentru build, teste și linters;
• probleme găsite, cu dovezi și sugestii de remediere.

La final trebuie să apară exact:

VERDICT: PASS

sau

VERDICT: FAIL

La PASS, verificatorul explică ce a confirmat și pe ce dovezi. La FAIL, indică ce este rupt, ce lipsește sau ce trebuie schimbat. Agentul principal repară problemele și reia verificarea, până trece sau până la maximum 3 încercări.

Limite / gotchas

check-work nu înlocuiește munca corectă. O expune când nu există.

Dacă nu apare un verdict clar, rezultatul se tratează ca eșec. Dacă build-ul este stricat sau testele relevante eșuează, verdictul este FAIL.

Pentru task-uri fără cod, faza de code review se sare. Pentru orice implică cod, configurare de tip cod, CI, manifest, infrastructură sau analiză de cod, verificarea trebuie să citească modificările și să ruleze verificările relevante când sunt configurate.

Verificatorul are aceeași limită de autorizare ca agentul: nu trebuie să inventeze acces, să pretindă statusuri neverificate sau să folosească secrete necerute. Dacă o resursă externă nu poate fi verificată, raportul trebuie să spună asta. „Pare bine” rămâne o cauză de incident, nu o dovadă.