Skill-ul bono-handoff

Pasul 5, după prototip: cum se predă un ecran la inginerie ca să nu mai fie reconstruit. Draft v0.1, cu template, amendamente la bono-prd și exemplul „De plată”.

Fișierele stau în retreat-q3-2026/skills/bono-handoff/. Nu sunt instalate nicăieri. Pagina le pune la un loc, în ordinea în care se citesc.

Skill-ul

Bono Handoff — Pas 5 din 5

DRAFT v0.1 · 19 sep 2026 · propus de BGN + Claude · de validat cu Prodi și Chris.

Obiectiv: la finalul acestui pas, un coleg care nu a fost în nicio sesiune de produs poate implementa ecranul fără să întrebe „de unde vine cifra asta?”. Handoff-ul nu descrie ecranul. Handoff-ul spune, pentru fiecare lucru de pe ecran, de unde vine, cine îl dă, cât de vechi poate fi și ce se întâmplă când lipsește.

De ce există pasul: la Dublin, PRD-ul și prototipul erau la standard, dar fiecare cifră purta un tag de sistem („[SAGA→NUCLEU]”), nu un contract. Inginerie a reconstruit 60 de rânduri de „circuit al apei”. Toate 60 aveau goluri. Un handoff bun face golurile vizibile înainte de cod, nu după.

Precondiții

• PRD funcțional actualizat după prototip (bono-prd, secțiunea „După prototip”).
• Prototip publicat pe subdomeniul de test, la zi cu ultima iterație.
• Numele owner-ului tehnic care primește lucrarea și al contabilului care verifică cifrele. Fără aceste două nume nu începe pasul.

Principii

1. Un handoff = contracte, nu descrieri. Descrierea e în PRD. Pixelii sunt în prototip și în DS. Aici intră doar ce leagă ecranul de restul sistemului.
2. Tag-ul de sistem nu e contract. „Din Nucleu” nu e acceptat. Se acceptă: sistem + câmp (cont contabil, coloană, nume de fișier, endpoint) + transport + owner + cadență. Ce nu se știe se scrie [CONFIRM], cu nume și termen.
3. Zero arhitectură. Faze, brokeri, dimensionare, „cine deține ce” nu sunt decizii de produs. Merg ca întrebări pentru CTO, într-o anexă.
4. Zero pixeli. Un detaliu vizual care e regulă de produs (IBAN fără spații, dată dd.Mmm.yy) intră ca cerință, nu ca CSS.
5. „Gata” îl verifică altcineva decât autorul. Un contabil, pe o firmă sintetică, nu owner-ul de produs pe chat.
6. Se predă citind împreună, nu trimițând un link.

Pas 0 — Inventarul ecranului

Din prototip, extrage tot ce e pe ecran în trei liste. Nu interpreta, doar enumeră.

• Cifre și texte de date: orice număr, dată, status, nume, listă (fiecare coloană a unei liste e o cifră).
• Acțiuni: orice buton, link, gest care schimbă ceva în afara ecranului.
• Condiții de afișare: orice element care apare sau dispare după o regulă („dacă nu are angajați”, „dacă e pe micro”).

Numără-le și scrie totalul în antet. La Dublin, „De plată” singur are 5 categorii × 4 câmpuri + 1 KPI + istoric = peste 25 de cifre. Dacă inventarul are sub 10 rânduri pentru un ecran de date, probabil lipsește ceva.

Pas 1 — Tabelul surselor (un rând per cifră)

Reguli pentru coloane:

• Câmp / cont / fișier: numele exact. Pentru SAGA: contul contabil sau câmpul din XML. Pentru un API: endpoint + câmp din răspuns. Pentru un document citit de Iris: tipul de document + câmpul extras.
• Transport: API · fișier · citire directă din DB · robot UI · manual. Un singur cuvânt.
• Owner: numele omului care răspunde de existența datei la cadența promisă. Nu „echipa”, nu „IT”.
• Cadență: cât de veche poate fi cifra când o vede clientul. „La închiderea lunii”, „zilnic 06:00”, „la eveniment (sub 1 min)”. Aceasta e regula de prospețime pe care ecranul trebuie să o afișeze sau să o respecte.
• Dacă lipsește: ce vede clientul când sursa nu a livrat. Niciodată „—” fără text.

Un rând cu două sau mai multe [CONFIRM] se mută și în tabelul de presupuneri (Pas 5).

Pas 2 — Tabelul acțiunilor (un rând per acțiune)

Regula: fiecare acțiune se termină într-un motor extern sau e locală. Dacă nu poți numi motorul, acțiunea nu e gata de implementare.

Pas 3 — Cerințe cu criterii de acceptare

Grupează rândurile din Pas 1 și 2 în cerințe. Fiecare cerință are ID (REQ-<ECRAN>-NN) și cel puțin două criterii de acceptare care se pot verifica pe firma sintetică fără să întrebi autorul.

REQ-DP-02  Cinci categorii de obligații, fiecare cu sumă, scadență, stare.
  AC1  Pe firma sintetică „Micro-TVA-1” apar exact 5 rânduri, cu sumele din balanța lunii august.
  AC2  Scadența legală care cade în weekend se afișează pe prima zi lucrătoare.
  AC3  Taxele pe salarii apar ca un rând cu două detalii de plată (cont unic + CAM).

Un criteriu de acceptare bun începe cu o stare cunoscută („pe firma X, în luna Y”) și se termină cu un rezultat observabil pe ecran. „Funcționează corect” nu e criteriu.

Pas 4 — Stările obligatorii

Pentru fiecare ecran, patru stări scrise în text, cu ce vede clientul și ce spune Bono:

1. Empty: firmă nouă, fără lună închisă, fără documente.
2. Loading: ce apare în primele secunde. Fără „Vă rugăm așteptați”.
3. Eroare de sursă: sistemul-sursă nu a livrat la cadență. Cifra veche cu vechimea afișată, sau cifra ascunsă cu explicație. Se decide per cifră, nu global.
4. Cont restricționat: abonament suspendat, împuternicire expirată, firmă radiată. Ce rămâne vizibil.

Dacă prototipul nu are una din stări desenată, se scrie textul aici și se marchează „nedesenat”. Nu se blochează handoff-ul pe desen.

Pas 5 — Presupunerile [CONFIRM]

Toate necunoscutele într-un singur tabel. Formatul e al lui Prodi (search-lucene-spec.md).

Regula: documentul nu e predat cât timp coloana „Răspuns” are rânduri goale. Owner-ul de produs urmărește răspunsurile. Termenul implicit e 3 zile lucrătoare.

Pas 6 — Întrebări pentru CTO (anexă)

Tot ce ține de arhitectură și a apărut pe parcurs se scrie ca întrebare, nu ca decizie:

• „Obligațiile se citesc din Nucleu sau direct din exportul SAGA? Produsul are nevoie doar de cadența «la închiderea lunii».”
• „Tabelul de conturi de trezorerie per județ: îl ține Nucleu sau Dublin? Produsul are nevoie de un singur stăpân.”

Fiecare întrebare spune ce are nevoie produsul, nu cum să se facă.

Pas 7 — Definiția lui „gata”

O propoziție, cu trei nume:

Ecranul e gata când firma sintetică <nume>, cu luna <luna> închisă în SAGA de <Alex>, afișează toate rândurile din REQ-uri, iar <Raluca> confirmă fiecare cifră contra balanței, fără intervenția lui <owner produs>.

Firma sintetică se descrie în handoff: regim fiscal, TVA da/nu, angajați, câte facturi, câte cheltuieli, ce documente încărcate, ce extras. Dacă firma nu există încă, crearea ei e primul task de implementare, nu ultimul.

Pas 8 — Sesiunea de citire

• 60 de minute, în aceeași zi cu predarea, owner produs + owner tehnic. Contabilul pentru primele 20 de minute, pe tabelul surselor.
• Se citește rând cu rând. Fiecare rând primește ✅ (înțeles și fezabil) · ❓ (întrebare) · ✗ (nu așa).
• Fiecare ❓ devine rând în tabelul [CONFIRM] cu nume și termen. Fiecare ✗ se rezolvă pe loc sau devine întrebare pentru CTO.
• Handoff-ul e predat când nu mai există ❓. Data predării se scrie în antet.
• Nu se trimite link „citește când ai timp”. Nu se predă în DM.

Output

Un fișier handoff-<modul>-<ecran>.md per ecran, sau handoff-<modul>.md cu o secțiune per ecran dacă modulul are sub 5 ecrane. Max 2 pagini per ecran. Structura e în HANDOFF-TEMPLATE.md, în același folder. Antetul e obligatoriu și real:

## Handoff: <modul> · <ecran>
Versiune: <n> · Data: <data reală a ultimei modificări> · PRD: <cale + secțiune> · Prototip: <URL>
Owner produs: <nume> · Owner tehnic: <nume> · Verifică cifrele: <nume contabil>
Citit împreună: <data> · Rânduri ❓ rămase: 0
Inventar: <n> cifre · <n> acțiuni · <n> condiții

Nu scrie handoff-ul în chat. Generează fișierul și prezintă-l.

Ce NU intră

• Jurnalul deciziilor. Rămâne al autorului, publicat separat, marcat „istorie, nu spec”.
• Culori, grile, fonturi, durate de animație. Sunt în prototip și în DS.
• Faze de livrare, estimări, arhitectură. Sunt ale owner-ului tehnic, după citire.
• Research, comparații cu competitori, argumente. Sunt în PRD.
• Copy-ul final al textelor. Se marchează „provizoriu” dacă nu e validat pe voce.

Validare înainte de predare

• Fiecare cifră din inventar are un rând în tabelul surselor.
• Niciun rând nu are sistem fără câmp. Golurile sunt [CONFIRM] cu nume și termen.
• Fiecare acțiune are sistem-țintă și comportament la eșec.
• Fiecare REQ are cel puțin două criterii verificabile pe firma sintetică.
• Cele patru stări sunt scrise pentru fiecare ecran.
• Definiția lui „gata” are trei nume și o firmă sintetică descrisă.
• Antetul are data reală, nu data primei versiuni.
• Zero paragrafe despre arhitectură în corp. Zero valori CSS.

Metrica skill-ului

La 30 de zile după predare, owner-ul tehnic numără rândurile din tabelul surselor care s-au dovedit false sau incomplete în implementare. Sub 20% = handoff bun. La Dublin, fără acest pas, cifra a fost 100% (60 din 60).

Relația cu ceilalți pași

• bono-product-flow: devine 5 pași. Pasul 4 (prototip) se închide cu „Prototipul e validat? Trecem la handoff?”.
• bono-prd: secțiunea „După prototip” nu mai cere „interacțiuni, hover, layout” în PRD. Pixelii rămân în prototip. În schimb, PRD-ul primește mai devreme trei lucruri care azi apar abia la handoff (vezi AMENDAMENTE-BONO-PRD.md).
• Bruce v3: ruta „UI-heavy” nu sare peste contracte. Un shell care nu calculează nimic e format numai din contracte.
• Contractul de date per flux (planul AI Native v2): tabelul surselor din acest skill e același lucru, văzut dinspre ecran. Când contractul fluxului există, handoff-ul îl citează în loc să-l rescrie.

Pasul următor

„Handoff-ul e citit și nu mai are ❓. Owner-ul tehnic scrie planul de implementare. Owner-ul de produs rămâne disponibil pentru [CONFIRM]-urile noi din primele 30 de zile.”

Template-ul de handoff

Handoff: <modul> · <ecran>

Versiune: 1 · Data: <zz.Lll.aa> · PRD: <cale> §<n> · Prototip: <URL> Owner produs: <nume> · Owner tehnic: <nume> · Verifică cifrele: <nume contabil> Citit împreună: <data sau „nu încă”> · Rânduri ❓ rămase: <n> Inventar: <n> cifre · <n> acțiuni · <n> condiții de afișare

Problema

<O propoziție, în cuvintele clientului. Din PRD.>

Non-goals

• <ce nu face ecranul, cu motivul>

1. Surse (un rând per cifră)

2. Acțiuni (un rând per acțiune)

3. Condiții de afișare

4. Cerințe

REQ-XX-01  <o propoziție>
  AC1  Pe firma sintetică <nume>, <stare> → <rezultat observabil>.
  AC2  ...

5. Stări

• Empty: <ce vede clientul, ce spune Bono>
• Loading: <...>
• Eroare de sursă: <per cifră: vechime afișată sau cifră ascunsă + text>
• Cont restricționat: <ce rămâne vizibil>

6. Presupuneri de confirmat

7. Întrebări pentru CTO

• <ce are nevoie produsul, nu cum se face>

8. Definiția lui „gata”

Ecranul e gata când firma sintetică <nume>, cu <luna> închisă în SAGA de <nume>, afișează toate rândurile din REQ-uri, iar <nume contabil> confirmă fiecare cifră contra <sursa de adevăr>, fără intervenția owner-ului de produs.

Firma sintetică: regim <micro/profit> · TVA <da/nu> · <n> angajați · <n> facturi emise · <n> cheltuieli · documente încărcate: <listă> · extras: <luna>.

9. Rabbit holes

• <situații cunoscute ca fiind grele, lăsate deliberat în afara MVP-ului>

Ce mutăm mai devreme, în PRD

Ce mutăm mai devreme, în PRD

DRAFT · 19 sep 2026. Handoff-ul repară predarea. Dar o parte din goluri se pot închide mai devreme, în bono-prd, când owner-ul încă discută cu Claude fiecare ecran. Lista de mai jos e ce am găsit în auditul Dublin și în transcripturile retreatului. Sigur mai sunt.

În secțiunea „Ecrane detaliate” din bono-prd, per ecran

Azi: actor, job, informații, acțiune principală, stări. Se adaugă:

1. Sursa fiecărei informații. Nu sistemul, ci sistemul + câmpul. Când owner-ul nu știe, scrie [CONFIRM: cine]. Asta e schimbarea cea mai mare: la Dublin, „informații pe ecran” era o listă de nume de cifre, fără proveniență. Prodi: „PRD-ul e o iluzie că am terminat analiza”.
2. Prospețimea. Cât de veche poate fi cifra când o vede clientul. Această întrebare a ridicat „tema mare” la Dublin abia pe 25 aug, după 9 ecrane.
3. Ce vede clientul când sursa lipsește. Per cifră, nu per ecran.
4. Ce cerem clientului pe acest ecran. Lista exactă (document, confirmare, context). Regula Bono e „aprobare, nu introducere”. Dacă lista e goală, se scrie „nimic”.
5. Cele patru stări scrise în text, nu „stări: normal, empty, error dacă relevant”. Empty, loading, eroare de sursă, cont restricționat sunt mereu relevante.

Secțiuni noi în PRD

1. Owner tehnic și contabil verificator, numiți în antetul PRD-ului, nu la handoff. Fără owner tehnic, PRD-ul nu trece de reconciliere.
2. Definiția lui „gata” per ecran, cu firma sintetică. Bono Way o cere la Specify. Bono-prd nu o cere deloc.
3. Presupuneri [CONFIRM] ca tabel viu, din prima zi. La sfârșit, tabelul se mută în handoff.
4. Ce se întâmplă când clientul greșește. Anulare, corecție, dublură, poză greșită. Cine repară și ce spune Bono. Azi apare doar la „state machine, dacă relevant”.
5. Întrebări pentru CTO, ca anexă separată de PRD. Arhitectura nu intră în corpul PRD-ului semnat de produs. Regula lui BGN pentru surse externe („diff + OK înainte de scriere”) se aplică și aici.

Ce scoatem din bono-prd

• Din „După prototip — PRD update”: „interacțiuni (hover, popup, validări)”, „layout decisions (grid, coloane, carduri)”, „culori per status”. Acestea rămân în prototip și în DS. În PRD rămân doar regulile de produs descoperite din vizualizare, scrise ca reguli, nu ca CSS.
• Fraza „Acesta e PRD-ul final care se predă la development”. PRD-ul nu se predă. Handoff-ul se predă.

În bono-product-flow

• Pas 4 se închide cu „Prototipul e validat? Trecem la handoff?”.
• Pas 5 — Handoff → bono-handoff: simplă 1 h · medie 2–3 h · profundă o zi. Citirea împreună e inclusă.
• Regula nouă: „Un PRD fără owner tehnic numit nu trece de Pas 3.”

În Bruce v3

• Ruta „UI-heavy” nu mai sare peste contracte. Testul: „ecranul afișează cifre pe care nu le calculează el?” Dacă da, contractele sunt obligatorii, indiferent cât de simplu pare ecranul.

Exemplu: Dublin · De plată

Handoff: Dublin · De plată

Exemplu de lucru, scris numai din ce există azi în PRD-ul Dublin (funcțional 25 aug + jurnal). Golurile sunt marcate [CONFIRM]. Nu e validat cu nimeni.

Versiune: 0 · Data: 19.Sep.26 · PRD: Dublin/dublin-prd-functional.md §6 · Prototip: dublin.bgn.ro/de-plata Owner produs: BGN · Owner tehnic: [CONFIRM] (Prodi a estimat „2–3 săpt. tot Dublin”) · Verifică cifrele: Raluca [CONFIRM] Citit împreună: nu încă · Rânduri ❓ rămase: 14 Inventar: 27 cifre · 3 acțiuni · 4 condiții de afișare

Problema

„Cât am de plătit, până când, și dă-mi tot ce-mi trebuie ca să plătesc în 30 de secunde.” (jurnal, 22 iul)

Non-goals

• Fără plată din Dublin (card → ANAF e în analiză legală).
• Fără calcul fiscal în Dublin. Dublin afișează, nu calculează.
• Fără CASS pe dividende (obligația persoanei, nu a firmei).

1. Surse

2. Acțiuni

3. Condiții de afișare

4. Cerințe

REQ-DP-01  KPI „De plată acum” = suma rândurilor scadente neplătite afișate.
  AC1  Pe firma sintetică „Micro-TVA-1”, luna aug închisă: KPI = Σ rândurilor de pe ecran, la ban.
  AC2  Firma sintetică „Nouă-0”, fără lună închisă: KPI lipsește, apare „Situația lunii nu e închisă încă”.

REQ-DP-02  Cinci categorii de obligații, fiecare cu sumă, scadență, stare.
  AC1  „Micro-TVA-1” afișează exact TVA, salarii, micro, locale; dividende lipsește (nu s-au distribuit).
  AC2  Scadența 25 care cade sâmbătă se afișează luni 27.
  AC3  Salariile apar ca un rând cu două seturi de detalii de plată (cont unic + CAM).

REQ-DP-03  Detaliile de plată se copiază gata de lipit în aplicația băncii.
  AC1  IBAN copiat fără spații.
  AC2  Suma copiată în format „8740,00”.
  AC3  Detaliile copiate = „<tip> <perioadă> · CUI <cui>”.

REQ-DP-04  „Plătit” apare numai după potrivirea cu extrasul.
  AC1  Înainte de încărcarea extrasului, rândul e „De plată” + „Așteptăm extrasul lunii aug”.
  AC2  După extrasul care conține plata, rândul trece în „Plătit” cu data plății din extras.

REQ-DP-05  Impozitele locale fără decizie cer decizia, nu o inventează.
  AC1  Fără decizie: „Așteptăm decizia de impunere” + buton de încărcare.
  AC2  După procesare Iris: sumă, rate, primărie pe rând.
  AC3  Dacă Iris nu poate citi decizia: rândul rămâne „Așteptăm decizia”, sarcină în De făcut „Poza nu se citește. Mai încearcă o dată.”  [CONFIRM ton + cine intervine]

5. Stări

• Empty: firmă nouă, nicio lună închisă. Cardul dark spune „Prima situație apare după închiderea lunii <L>.” Fără rânduri. Fără KPI.
• Loading: scheletul cardului dark și al listei, sub 1 s. Text: „Se încarcă…”.
• Eroare de sursă: luna trebuia închisă și nu e. Rândurile lunii precedente rămân, cu „Situația din <L-1>” în eyebrow. [CONFIRM] termen maxim de propagare SAGA → ecran.
• Cont restricționat: abonament suspendat. Rândurile rămân vizibile, „Copiază” funcționează, upload dezactivat. [CONFIRM] cu BGN.

6. Presupuneri de confirmat

7. Întrebări pentru CTO

• Obligațiile se citesc din Nucleu sau direct din exportul SAGA? Produsul are nevoie doar de cadența „la închiderea lunii” și de un singur loc de citire.
• Tabelul de conturi de trezorerie: un singur stăpân. Care?
• Reconcilierea plăților cu extrasul: e în Nucleu sau lângă el? Produsul are nevoie de „Plătit” + data, atât.

8. Definiția lui „gata”

Ecranul e gata când firma sintetică „Micro-TVA-1”, cu luna august închisă în SAGA de Alex, afișează TVA, salarii, micro și locale cu sumele din balanță, iar Raluca confirmă fiecare cifră contra balanței, fără intervenția lui BGN.

Firma sintetică „Micro-TVA-1”: micro 1% · plătitoare TVA lunar · 1 angajat · 6 facturi emise în aug · 9 cheltuieli · decizie de impunere încărcată · extras aug încărcat, cu plata TVA din iulie.

9. Rabbit holes

• Stingerea parțială a unei taxe.
• Regim schimbat în cursul anului (micro → profit).
• Firmă cu sedii în mai multe județe (mai multe primării).
• „Plătește taxele” din Dublin (legal, ConsAudit).

The Bono Way · v2 · Planul de lansare · 19 septembrie 2026 · pregătit de Claude pentru Bogdan; capitolele se rescriu de owner-ii lor. Sursa: repo „Bono Waiy", Markdown.