Anexa B - Template-uri

Unsprezece template-uri și exerciții de copiat și lipit. Toate sunt puncte de plecare; adaptează-le pentru echipa ta.

Template-urile B.1 și B.2 rămân integral în engleză: sunt artefacte pe care le consumă agentul, iar prompturile se scriu în engleză.

B.1 Promptul de architecture review¶

Analyze the architecture of this codebase. Produce a structured architecture review document covering:

Repository and scope: [repository, affected areas and exclusions]
Business domain: [known domain and owner who can correct inferences]
Authorization: read-only investigation by default; other actions only [explicit scope]
Time budget: [bounded first pass]
Evidence available: [code, tests, docs, runtime access]
Evidence unavailable: [production state, advisories, business decisions, other gaps]
Commit reviewed: [actual git SHA; state dirty/untracked files separately]
Human review owner: [name/role]

1. Purpose. What does this service do? Who uses it? What business problem does it solve?
2. Top-level structure. Major modules, packages, or folders. One paragraph per major component.
3. Data model. Primary entities, relationships, persistence. Cite specific files and line numbers.
4. Request flows. For the three most important external entry points, trace from entry to persistence. Cite files and lines at each step.
5. Cross-cutting concerns. Authentication, authorization, logging, error handling, configuration. Where do they live?
6. Dependencies. External services, databases, message brokers, third-party APIs.
7. Test posture. Test structure, coverage, gaps.
8. Build and deployment. Cite the configuration files.
9. Risks and unknowns. Fragile code, inconsistent conventions, deprecated dependencies, unresolved patterns.

Cite specific files and line numbers throughout. Separate observed code facts,
inferred business purpose, and unverified operational claims. Configuration is not
proof of production behavior. State ambiguity and unavailable evidence. Suggest
conventions for human review; do not implement them without authorization.

B.2 Scheletul AGENTS.md¶

Acesta e un schelet ilustrativ pentru un proiect Java/Spring. Înlocuiește numele, datele incidentelor, comenzile și restricțiile din exemple cu fapte verificate ale proiectului; incidentele din exemplu nu sunt relatări despre repository-ul tău.

Template-ul rămâne în engleză pentru agent. Folosește numele și regulile de încărcare ale harness-ului: AGENTS.md sau CLAUDE.md, cu import explicit dacă ai nevoie de ambele. Pornește cu un fișier scurt. Folosește circa 200 de linii ca reper pentru reducerea conținutului, nu ca țintă sau limită universală. Linia de precedență clarifică relația cu cererea și skill-urile, în limitele instrucțiunilor cu prioritate mai mare ale agentului; nu înlocuiește controalele de securitate.

# AGENTS.md

Precedence: in a conflict, the task prompt wins over this file; this file wins over any skill.

## Forbidden patterns
- Never construct SQL by string concatenation. Use bound parameters. (Reason: SQL injection.)
- Never roll your own cryptography. Use the team's approved crypto wrapper. (Reason: AES-CBC with hardcoded IV shipped to production in 2024; we are not doing that again.)
- Never modify migration history. Migrations are append-only.

## Mistake journal
- 2026-03-03: agent generated JPQL query that bypassed the multi-tenant filter. Fix: queries extend MultiTenantQueryBuilder, which enforces tenant filtering. Evidence: <commit or incident link>

## Conventions
- Constructor injection only, not field injection.
- In this project's persistence services, use transactions where consistency requires them; use @Transactional(readOnly = true) for appropriate reads and explicit write transactions for mutations. Follow the reviewed service example; this is not a universal Spring restriction.

## Build and test
- Build: mvn clean verify
- Run tests: mvn test

## Where the map lives
- Repository layout and module map: docs/architecture.md (read before touching an unfamiliar module)

## Domain glossary
- "Customer" = end user. "Counterparty" = corporate client.
- "Transfer" = intra-bank or inter-bank. "Wire" = inter-bank only.

B.3 Checklist-ul buclei în șase faze (one-pager)¶

Funcțiile rămân; cât documentezi, delegi sau ceri aprobare depinde de task și de risc.

RESEARCH
  Citește contextul relevant și clarifică ce schimbă rezultatul.
  Câteva rânduri pot ajunge; 2-4 pagini sunt un exemplu pentru un feature complex.
PLAN
  Schimbare mică și clară: execuție directă, cu o verificare relevantă.
  Neclaritate sau dependențe: plan scurt cu rezultate, ordine și verificări.
  Risc mare: criterii explicite, gate-uri umane și review aprofundat.
  Pașii de 2-5 minute sunt o opțiune pentru muncă mecanică, nu o cotă.
EXECUTE
  Agentul principal poate executa singur. Deleagă muncă amplă, independentă și
  bine delimitată când beneficiul acoperă pornirea și transferul de context.
  Un singur scriitor pe zonele care se suprapun; dependențele se execută în ordine.
  Termină munca autorizată; fără confirmări repetate pentru acțiuni reversibile.
  Respectă scopul și permisiunile. Clarifică doar deciziile care depășesc mandatul
  sau schimbă material rezultatul. Consemnează deciziile importante.
REVIEW
  Verifică intenția, corectitudinea de business și calitatea implementării.
  Reviewer independent cu context proaspăt dacă riscul, modelul sau rezultatele
  îl justifică; nu automat doi agenți în secvență.
  Păstrează evaluările independente fără verdictele anterioare.
  Acceptă sau respinge constatări cu dovezi; urmărește defecte utile și fals pozitive.
  Oprește repararea când nu mai rămâne o problemă importantă; altă rundă cere dovezi noi.
VERIFY
  Rulează verificările relevante. Pentru bug-uri de comportament, test de regresie
  unde e fezabil. Nu inventa teste permanente pentru editări fără impact relevant.
  Nu slăbi testele sau CI-ul ca să obții verde; schimbările legitime se autorizează
  și se revizuiesc. Explică eșecul înainte de fix.
  Teste held-out, istoric sigilat și egress oprit: pentru evaluări controlate sau
  cerințe ridicate de asigurare, nu implicit pentru fiecare PR.
  Raportează dovezile și limitele. Nu repeta o suită validă fără un motiv nou.
SHIP
  Commit și PR structurate; revieweri conform CODEOWNERS; procesul normal al echipei.
  Păstrează aprobările umane, de securitate și de livrare cerute de proiect.
  Notează responsabilul/ordinea de release, compatibilitatea, semnalul de succes,
  declanșatorul intervenției, recuperarea și observația înainte de predarea în producție.

B.4 Fișa de punctare a kill signals¶

CONDIȚIILE TASK-ULUI - completează înainte de punctare
  Comportamentul/modulul/mediul propus: ______
  Responsabil calificat pentru evaluare: ______
  Greșeala cu consecințe importante și dovezile care ar expune-o: ______
  Acțiuni permise, aprobare necesară, deployment și recuperare: ______
Ceva lipsește sau e necunoscut? Restrânge munca afectată la investigație sau
pregătire supravegheată până rezolvi. Un repository verde nu autorizează singur un task.

SEMNALE DE PREGĂTIRE - 0 lacună absentă / 0.5 parțială / 1 substanțială / ? necunoscut
Pentru fiecare, notează dovezi, responsabil și acțiunea următoare. Nu transforma ? în 0.

1 Verificare insuficientă
  0    rezultate/eșecuri importante asertate; rulări fiabile; eșecuri înțelese
  0.5  câteva check-uri relevante, cu lacune delimitate și numite
  1    check-uri absente sau nefiabile nu expun greșelile cu consecințe importante
  ?    comportament sau aserțiuni neinvestigate; coverage-ul singur nu decide
2 Fără documentație
  0    explicație și decizii actuale pentru comportamentul afectat
  0.5  explicație utilizabilă cu lacune numite
  1    comportamentul/deciziile necesare nu sunt disponibile
3 Cuplare strânsă
  0    contracte clare și efecte înțelese ale schimbării
  0.5  câteva efecte între module, cu puncte de separare cunoscute
  1    efectele nu pot fi delimitate fără investigație mai amplă
4 Reguli de business împrăștiate
  0    responsabil/sursă canonică pentru regulile relevante
  0.5  reguli duplicate cu reconciliere cunoscută
  1    reguli contradictorii fără autoritate cunoscută
5 Constrângeri de reglementare
  0    aprobări și dovezi necesare susținute de un workflow stabilit
  0.5  task-ul cere pregătire suplimentară pentru aprobare/dovezi
  1    calea necesară de aprobare sau dovezi nu e disponibilă
6 Echipa nu poate evalua output-ul
  0    reviewer calificat disponibil pentru domeniul afectat
  0.5  expertiză disponibilă, dar handoff fragil
  1    niciun evaluator calificat: condiție neîndeplinită indiferent de total
7 Potrivirea model-context
  0    modelul folosește contextul oferit pe task-uri reprezentative și delimitate
  0.5  lacune cunoscute cer documentație sau supraveghere suplimentară
  1    neînțelegeri importante persistă în munca propusă
8 Viteza schimbării
  0    versiuni-țintă și compatibilitate înțelese
  0.5  limitele migrării sunt cunoscute, dar cer grijă
  1    ținte în schimbare sau compatibilitate nerezolvată

Fără necunoscute, adună și rotunjește jumătățile în sus. Euristică, nu scor de siguranță:
  0-1 VERDE puține lacune / 2-3 GALBEN pregătire substanțială / 4+ ROȘU pregătire amplă
Condițiile task-ului au prioritate față de culoare. Investighează necunoscutele întâi.
Următorul task permis: ______  Restricție: ______  Responsabil/check/dată: ______

B.5 Calendarul de adopție în 90 de zile (one-pager)¶

ÎNAINTE SĂ ÎNCEPI
  Serviciu/cont aprobate: ______  Repository-uri/date permise: ______
  Responsabil și reviewer calificat: ______
  Controale/recuperare inițiale verificate: ______  Limită de cheltuieli: ______
  Baseline, eșantion de task-uri comparabile și criterii de oprire/extindere: ______
CHAMPION
  Săptămâna 1      instalează agentul; architecture review (B.1) pe un codebase familiar; dă-i commit
  Săptămâna 2      verifică instrucțiunile (B.2); adaugă doar ce cere pilotul
  Săptămânile 3-4  funcțiile din B.3 pe trei feature-uri; proces potrivit fiecăruia
  Luna 2           trei feature-uri medii; atrage alți ingineri în faze individuale
  Luna 3           predă rolul unui succesor; AGENTS.md e al echipei
LEAD
  Săptămâna 1      clasifică top 5 proiecte după cele 8 kill signals (B.4)
  Săptămânile 2-4  pentru fiecare culoare, scrie ce ar trebui să se schimbe ca să muți un proiect
  De la început    notează timpul de ceas și uman efectiv, calitatea, review/rework și toate costurile
  Luna 3           prezintă rezultate oneste
MANAGER
  De la început    confirmă eligibilitatea/bugetul; evaluează rezultate fără cote de PR-uri individuale
  Zilele 61-67     preia hand-off-ul; verifică dacă metricile din dashboard sunt reale
  Zilele 68-74     închide decizia seat-vs-enterprise (Anexa A)
  Zilele 75-81     verifică extinderea și guvernanța recurentă; aprobarea inițială a fost înainte de pilot
  Zilele 82-90     raportează observații, costuri și limite; decide extindere/schimbare/oprire

Reutilizează fișa de măsurare; datele sunt exemple, nu un calendar obligatoriu de extindere. Ponderea PR-urilor atinse de agent măsoară adopția, nu rezultatul.

Arcul grassroots pentru echipele care nu au toate cele trei roluri: Capitolul 9. Anexa A completează o comparație ipotetică de cost; nu înlocui efortul sau banii economisiți cu cycle time-ul PR-urilor.

B.6 Contractul buclei exterioare (one-pager)¶

Înainte de orice rulare nesupravegheată, completează fiecare linie. O linie goală înseamnă că bucla nu e gata.

MUNCA
  Queue: ______ (în repo; câte o unitate mică, similară, reversibilă per element)
  Eligibilitate: fiecare unitate îndeplinește condițiile din B.4; verificabilă independent
  și recuperabilă în controalele rulării nesupravegheate. Un scor verde nu ajunge.
CONDIȚIA DE OPRIRE (evaluabilă de mașină; bucla se oprește singură)
  Done când: ______ (queue gol / suita verde / N unități gata de review)
  Buget: max ______ tokeni sau $______ sau ______ iterații sau ______ ore - ce se atinge primul,
  impus de ceva ce bucla nu poate ocoli (un avertisment de consum nu e un buget)
  Regula de eșec: aceeași unitate eșuează de două ori -> sari peste ea și marchează-o; trei unități sărite -> oprește tot
FIECARE ITERAȚIE
  Context proaspăt; starea se citește din queue + jurnalul din repo
  Înainte de retry sau reluare: reconciliază commit-ul, scrierile încheiate,
  procesele care rulează, apelurile externe și consumul; operațiunile importante
  trebuie să poată fi repetate fără efecte nedorite
  O unitate per iterație; termină-o sau notează în jurnal de ce nu - nimic aplicat pe jumătate
  Gate: ______ (teste / lint / typecheck / build), impus prin verificări obligatorii protejate
  Protejează schimbările evaluatorului, configurației și regulilor de politică de
  aprobarea unilaterală a agentului. Marker-ele de done avansează doar după ce trec
  verificările de încredere; raportul agentului singur nu e gate-ul de acceptare.
IZOLARE
  Copie de lucru și branch dedicate, niciodată branch-ul default
  Acoperire tool/sandbox verificată; fără credențiale de producție; testează rutele de rețea/DNS
REVIEW-UL DE DIMINEAȚĂ (pragul minim de review uman)
  Fiecare PR e citit pentru corectitudine de business și potrivire arhitecturală
  Verificarea de kill înainte de relansare: diff-uri care oscilează? buget consumat, dar queue-ul nu e mai scurt?
  același eșec a treia oară? gate-ul a fost atins? Orice „da” -> nu relansa. Citește jurnalul,
  repară întâi cauza.

B.7 Igiena contextului (one-pager)¶

ÎNCĂRCARE
  Doar context relevant pentru task. Pointere, nu payload-uri: numește fișierele,
  nu le lipi.
SESIUNE
  Păstrează deciziile, constrângerile, progresul și dovezile necesare reluării în
  formatul potrivit proiectului. Fără documente sau commit-uri de dragul procesului.
SEMNE DE INVESTIGAT când agentul
  răspunde din nou la o întrebare rezolvată deja; citează o versiune învechită a
  unui fișier pe care l-a editat; uită o constrângere pe care o respecta; se
  degradează târziu într-o sesiune lungă.
ATUNCI
  Verifică starea reală, cerințele contradictorii, sursele învechite și accesul lipsă.
  Corectează cauza. Dacă deriva continuă, reia într-o sesiune curată, cu starea necesară.
  Fă commit după practica repo-ului.
COMPACTARE (trateaz-o ca pe un handoff)
  Compară strategiile suportate de mascare/rezumare după rezultate și consum. Istoricul
  e append-only pe Fable 5.1: repornește, nu edita. Rezumarea poate omite sau deforma
  detalii; salvează durabil deciziile, constrângerile și dovezile indispensabile.
  Dă-i compactorului o listă de păstrat: planul, întrebările deschise, devierile,
  comenzile care au mers. Nu presupune că detaliile din afara listei vor supraviețui;
  verifică handoff-ul înainte să continui.

Exemplu complet de handoff, un checkpoint sintetic de exercițiu, nu logul unei sesiuni reale:

Obiectiv: adaugă Wire priority păstrând răspunsurile v1 și comportamentul de retry.
Decizii acceptate: patru valori enum; absent/null => NORMAL; doar URGENT intră în queue;
  refuză crearea urgentă când queue-ul e indisponibil; audit priority ales; replay o dată.
Revizie curentă: snapshot didactic wire-v1; nu se pretinde un SHA de commit Git.
Fișiere schimbate: wire.py, defective.py, tests.py, verify.py, README.md; baseline.py păstrat.
Nerezolvat: durabilitate/atomicitate reală de queue și compatibilitatea consumatorilor din producție.
Abordare eșuată: aserțiunea de existență a evenimentului trecea când priority lipsea.
Check-uri rulate: slab-verde, corectat-roșu așteptat, suită reparată verde prin verify.py.
Următorul pas: reviewer calificat inspectează dovezile de acceptare și ipotezele de release;
  aceste teste de model nu autorizează deployment în producție.

B.8 Ordinea de citire a unui diff de agent (one-pager)¶

1 ÎNAINTE DE COD
  Diff-stat-ul raportat la cerere sau plan. Cere explicații pentru fișierele neașteptate.
2 ÎNTÂI TESTELE
  Citește ce afirmă, nu dacă trec. Un test scris pornind de la cod va fi de acord
  cu codul; aserțiunea trebuie să vină din intenție.
3 GRANIȚE
  Verifică regulile scrise ale echipei (pattern-urile interzise din AGENTS.md,
  convențiile de strat). O trecere de graniță arată curat într-un stil fluent.
4 NUME NOI
  Dă grep pe fiecare API, funcție sau cheie de config pe care n-o recunoști. Zero
  rezultate: numele s-ar putea să nu existe.
5 LINIE CU LINIE
  Abia acum, pentru corectitudine de business și potrivire arhitecturală. Folosește
  constatările verificărilor automate dacă le-ai rulat; nu presupune că au prins tot.
VERIFICARE OPȚIONALĂ A ÎNȚELEGERII
  Pentru muncă nefamiliară sau cu consecințe importante, întreabă despre edge case-uri,
  ownership și moduri de eșec dacă review-ul obișnuit nu a stabilit înțelegerea.
  Lămurește ce lipsește înainte de aprobare.

B.9 Checklist-ul de evaluare a modelelor, harness-urilor și skill-urilor (one-pager)¶

Rulează-l după schimbări de model, harness sau skill și când rezultatele se înrăutățesc. Nu e al nouălea kill signal: verifici dacă workflow-ul mai ajută în configurația curentă. Migrarea la alt model cere și verificările de compatibilitate de mai jos.

BASELINE
  Alege task-uri reprezentative și fixează criteriile de acceptare înainte de rulări.
  Include și cazuri în care skill-ul nu ar trebui să se declanșeze.
  Notează modelele folosite efectiv (nu doar eticheta din selector când rutarea
  e activă), effort-ul, versiunile harness-ului/workflow-ului, suprafața de
  autentificare și planul, commit-ul de pornire, permisiunile și starea memoriei
  persistente. Sesiunile proaspete pornesc din stări salvate echivalente.
COMPARAȚIE
  Compară configurația curentă și cea propusă pe task-uri similare; documentează
  ce s-a schimbat. Pentru un skill sau plugin opțional, compară execuția nativă
  cu el activat/dezactivat pe fiecare model: același effort, commit, aceleași
  permisiuni și criterii, sesiuni proaspete. Repetă suficient ca să vezi variația;
  nu alege doar cea mai bună rulare.
MĂSURĂTORI
  Corectitudine, cerințe îndeplinite și regresii, nu doar respectarea procesului.
  Consum total facturat, inclusiv cache și subagenți; timp de ceas, review uman
  și rework.
  Mai multe tool call-uri sau tokeni nu sunt automat mai multă valoare ori aceeași
  creștere procentuală a facturii.
PROMPTURI ȘI FIȘIERE DE INSTRUCȚIUNI
  Citește ghidul modelului. Retestează regulile imperative, delegarea și prompturile
  de verificare; încearcă să retragi instrucțiunile redundante, păstrând constrângerile
  locale și controalele de securitate. Verifică trigger-ele și prescripțiile excesive
  din skill-uri. Verifică descoperirea și prioritatea instrucțiunilor (B.2);
  nu presupune că AGENTS.md sau CLAUDE.md se încarcă identic în alt client.
  Confirmă când intră în vigoare o editare: Codex își construiește lanțul de
  instrucțiuni la pornire, deci repornește-l ca să le reîncarce.
COMPATIBILITATE LA MIGRARE
  Elimină parametrii API respinși de noul model; verifică formatele de output suportate.
  Unde există controale de effort, compară nivelurile după task sau fază; numele nu se
  transferă între modele. Păstrează setarea curentă ca baseline de comparație.
  Retestează schemele de tool-uri custom, inclusiv decodarea strictă unde e suportată;
  verifică limitele schemelor și numără tool-urile vizibile. Verifică cerințele clientului
  pentru istoric și compactare, apoi compară rezultatele, folosirea cache-ului și costul facturat.
DECIZIE
  Păstrează, simplifică, limitează la anumite task-uri sau la invocare manuală ori
  dezactivează workflow-ul opțional, după beneficiul observat. Notează versiunile și
  limitele comparației. Păstrează un fallback testat pentru un model retras din
  planul tău. Dacă rezultatele continuă să scadă, revino la semnalele din
  Capitolul 8.

B.10 Checklist-ul de verificare a plugin-urilor¶

Marketplace-ul e o suprafață de supply chain, ca npm. Verifică fiecare plugin așa cum verifici o dependență.

MAINTAINER
  Activ în ultimele 90 de zile? Mai mult de un maintainer? Un palmares real?
SUPRAFAȚA DE PERMISIUNI
  Ce tool-uri, hook-uri, căi de fișiere și apeluri de rețea adaugă? Cererile
  largi au nevoie de o justificare. Adnotările MCP (read-only, destructive) sunt
  afirmații, nu controale; ai încredere în ele doar cât ai în server.
REVIEW-UL DE COD ȘI DE WORKFLOW
  Inspectează versiunea instalată: instrucțiuni, trigger-e, hook-uri, scripturi și
  dependențe. Alege profunzimea review-ului după suprafață și risc, nu după un
  buget fix de douăzeci de minute. Evită instalările duplicate neintenționate.
BENEFICIU
  Compară on/off cu agentul nativ după B.9. Numele plugin-ului sau o verificare
  veche nu validează automat o versiune nouă. Păstrează-l unde ajută la rezultate.
DISCIPLINA DE UPDATE
  Fixează versiunea; fără auto-update. Citește diff-ul, rulează testele, livrează
  bump-ul ca pe o schimbare trecută prin review.
BLAST RADIUS
  În interiorul sandbox-ului e mărginit; un hook pe mașina developerului, în
  afara lui, nu e mărginit de nimic. Preferă varianta mărginită; altfel ridică
  ștacheta la tot ce e mai sus.

B.11 Exerciții¶

Exercițiile testează judecata, nu numărul de documente. Capitolele 2, 7 și 8 adaugă o fișă de control reproductibilă, o hartă de arhitectură revizuită și o fișă de pregătire a task-ului. Pachetul Wire oferă exemple executabile și răspunsuri explicate mai amplu.

Capitolul 1 - Ce este un agent

1. Inspectează doi coding agents open source: „Găsește context, tool-uri, Permisiuni / Sandbox, skill-uri, plugin-uri, MCP, Memory, Effort și subagenți. Citează fișierul/modulul care le implementează sau raportează absent/extern/necunoscut. Distinge afirmațiile documentate de comportamentul observat.”
2. Compară dovezile. Împachetarea diferită și capabilitățile absente sunt constatări valide; nu forța implementarea să se potrivească framework-ului.

Capitolul 6 - AGENTS.md și contextul

1. Alege un repository al cărui fișier de instrucțiuni e gol, învechit sau scris de cineva care a plecat.
2. Inspectează instrucțiunile existente și un modul relevant. Întreabă ce convenții neintuitive, comenzi sau capcane i-ar scăpa altfel unui agent; verifică răspunsul în cod și cu un coleg care cunoaște proiectul.
3. Schițează doar completările utile pornind de la B.2. Pune linkuri către documentele detaliate în loc să copiezi harta repository-ului; evită best practice-urile generice.
4. Compară o sarcină reprezentativă cu și fără fișierul propus, în sesiuni proaspete, de la același commit și cu aceleași criterii de acceptare. Compară rezultatele, efortul de review și consumul, nu doar cât de convingător sună răspunsul.
5. Dă-l unui coleg care n-a mai lucrat în repo; unde se încurcă el, acolo e următoarea ta modificare.

Capitolul 4 - Cât workflow merită task-ul

1. Alege un task mic și clar, unul cu dependențe și unul riscant sau nefamiliar. Definește criteriile înainte de rulare.
2. Compară agentul nativ cu un workflow opțional, după B.9; include un caz în care skill-ul ar trebui să rămână inactiv.
3. Notează calitatea, regresiile, consumul facturat cu cache și subagenți, timpul uman, rework-ul și timpul de ceas. Păstrează doar structura care își justifică costul; nu generaliza dintr-un singur rezultat.

Găsește eroarea de dependență

Plan propus: rulează simultan workerii de rutare, API și audit; lasă-i să aleagă fiecare reprezentarea priority; stabilește recordul/default-ul după aceea. Ce trebuie schimbat?

Răspuns: stabilește reprezentarea comună, default-urile și politica de eșec înaintea implementării dependente. Apoi folosește etape care respectă dependențele sau un singur implementator, un singur scriitor pe zonele suprapuse și un check de integrare. Explorarea independentă poate propune alternative mai devreme; nu poate impune tacit contracte contradictorii.

Găsește aserțiunea insuficientă

Criteriul de acceptare cere priority ales în eveniment. Testul verifică doar un eveniment, tipul și ID-ul wire-ului. Ce poate rămâne greșit?

Răspuns: priority poate lipsi sau poate fi incorect. Verifică valoarea față de input-ul ales, demonstrează eșecul pe defect, apoi repară și rerulează. Exercită toate valorile ca să excluzi un fix hardcodat. Și egalitatea exactă a evenimentului poate fi validă dacă o cere contractul acceptat.

Alege dimensiunea workflow-ului

Compară un typo în textul de ajutor, un câmp priority care traversează stocare/API/audit/rutare și un algoritm de ledger nefamiliar, fără reviewer calificat.

Răspuns: typo-ul cere inspecție directă, editare, verificare focalizată și livrare obișnuită. Schimbarea priority cere decizii explicite, dependențe ordonate, dovezi pentru eșec/retry și predare către producție. Restrânge schimbarea ledger-ului până stabilești evaluarea și verificarea. Artefacte și numere de agenți alternative sunt acceptabile când acoperă deciziile și controalele.