Cum se face un proiect

Contract, research, plan, implementare, demo; zece reguli; firma sintetică pe care se demonstrează

Bono azi

Prodi: „când există PRD și proiectare, execuția merge în 3–4 zile"; și „PRD-ul e o mică iluzie că am terminat analiza". Auditul Dublin: 60 de rânduri de „circuit al apei", toate cu goluri, pentru că fiecare cifră purta un tag de sistem, nu un contract. Chris: „nu pot da mai departe un PRD scris de Claude pe care nu l-am citit." Teo: „nicio planificare nu a avut buffer de testare."

Și fără loc de demonstrat: Alexandra, „construim un puzzle, doar că nu avem imaginea puzzle-ului"; Prodi, „nu poți să spui Dublin e gata că se afișează taxele; trebuie să vină taxele din SAGA, prin robot, până în Dublin." Testele se fac pe firmele interne sau nu se fac; prototipul Dublin are cifre hardcodate. Fără o firmă de test, „gata" rămâne părerea autorului.

Cei cinci pași

Fiecare pas produce un fișier în repo: docs/contracts/, docs/research/, docs/plans/. Un plan urcat deschide automat un PR către Prodi; acolo se prinde o abatere de arhitectură, nu după ce codul e scris. Dacă agentul livrează mult sub 60%, nu se repară codul; se întoarce la plan sau la research.

Estimarea în trei surse. Owner-ul estimează din propriul plan. Claude estimează independent, din contract și plan. Prodi validează după ce vede ambele; cifra lui e referința. Prodi dă și un scor de complexitate 1–5, care nu se schimbă pe parcurs. Dacă planul trece de dublul estimării, problema nu e clară și proiectul se oprește.

Handoff-ul de la produs la inginerie. Când un flux are ecrane, între prototip și contract intră un pas: un rând per cifră (sistem + câmp + transport + owner + cadență + „dacă lipsește"), un rând per acțiune, patru stări obligatorii (empty, loading, eroare de sursă, cont restricționat), presupunerile [CONFIRM] cu cine confirmă și până când. Zero arhitectură, zero pixeli. Se predă citind împreună, 60 de minute, nu trimițând un link; gata când nu mai există ❓. Skill-ul bono-handoff există ca draft.

Review și deploy. SuperBoris raportează, nu modifică. Un coleg, reviewer-ul principal al lunii, răspunde în sub 24 de ore. Prodi doar când PR-ul atinge model de date, integrare nouă, contract de API sau o decizie scumpă. Deploy-ul e automatizat și îl face owner-ul. Ce nu e gata joi așteaptă săptămâna următoare; fără weekenduri eroice. Bug-urile se rezolvă sau se închid în cinci zile; fără backlog.

Termenul se mută înainte. Când owner-ul vede că nu ajunge la dată, mută data înainte de a trece de ea, cu motiv scris. Cine mută după întârziere nu intră în predictibilitate. E singurul comportament pe care îl sărbătorim explicit.

Firma sintetică: pe ce se demonstrează

O firmă sintetică e o firmă care nu există, dar arată exact ca una reală: CUI, facturi emise, bonuri fotografiate strâmb, un salariat, un extras cu comisioane, luni închise în SAGA. Pe ea se arată fiecare flux joi, pe ea se testează fiecare agent, pe ea se verifică fiecare contract. Nu se testează niciodată pe date reale.

Modelul e al lui Integral (postul „There's no fixture for a company", iulie 2026), și nu e „câteva firme de test". E un generator care creează o firmă nouă pentru fiecare rulare și o aruncă după. De ce nu ajunge o singură firmă: starea unei firme e un drum, nu un punct, iar o firmă e într-o singură stare la un moment dat; agenții citesc tot istoricul, deci firma modificată pentru un scenariu strică celelalte; un incident din producție se reproduce doar pe o firmă recreată curat. Cum face Integral o firmă: alegi starea-țintă și volumul; generatorul inventează nume, formă juridică, conturi, tranzacții, facturi PDF; totul intră prin API-urile produsului, marcat „date de test", nimic direct în baza de date; istoricul se construiește la creare (lunile vechi reconciliate, luna trecută aproape gata, luna curentă deschisă); datele sunt intenționat murdare; agenții pornesc de la același eveniment ca în producție, cu trace ID. OCR-ul real nu se rulează în suită; se injectează extrageri sintetice.

Drumul Bono, în trei pași, pentru că nu avem nici platforma, nici API-uri peste tot, iar SAGA se alimentează prin robot:

1. Octombrie: o firmă făcută de mână. „Micro-TVA-1": SRL micro, plătitoare de TVA, un angajat, cinci facturi și zece cheltuieli pe lună, august închis în SAGA. Alex, cu Cristi pe contabilitate. Fișa firmei în repo: regim, TVA, angajați, volum, documente, extras, luni închise. Fișa e lista parametrilor generatorului de mai târziu.
2. Noiembrie: generatorul v1. Un script care creează o firmă în Facturare, Salarizare și Nucleu prin API-urile lor, din parametrii fișei, cu istoric pe trei luni și date murdare; robotul o duce în SAGA. Cristi e owner, din scaunul de produs, cum a făcut PM-ul lui Integral; Alex implementează; Prodi decide flag-ul de test și API-urile. Trece prin cei cinci pași ca orice flux.
3. Din decembrie: firme de unică folosință. Demo-ul de joi rulează pe o firmă generată în aceeași zi. Fiecare incident din producție devine o firmă de regresie cu rezultat așteptat.

Trei reguli din prima zi: firmele sintetice sunt marcate ca date de test în fiecare sistem, cu un flag, nu cu o convenție de nume; nimic nu se scrie direct în baza de date; OCR-ul lui Iris se testează separat.

Firma sintetică e locul unde echipa lucrează împreună fără să se întâlnească: Vlad vede dacă factura a ajuns în SAGA, Alex dacă robotul a importat, Cristi dacă taxele sunt cele din balanță, Prodi dacă Dublin citește din contract, Octav dacă ecranul arată datele reale. Toți pe aceeași firmă, joi la 16:00.

Cele zece reguli

1. Un flux are un owner cap-coadă și un al doilea om.
2. Deciziile greu de întors: doi oameni, în scris, niciodată pe DM; „concluzia e că facem asta" se spune explicit.
3. Nimic fără plan aprobat; niciun plan fără criterii de acceptare, contract de date și firmă sintetică.
4. Întrebările despre date primesc răspuns în aceeași zi de la contabilul de serviciu.
5. Cifrele care ajung la client vin din surse structurate și trec prin bifa unui contabil.
6. Codul intră doar prin PR; review automat pe cod, uman pe plan.
7. Sign-off în 48 h sau delegat cu nume; aprobarea planului în 2 zile.
8. Guardian-ul primește toate întreruperile.
9. Un bug repetat produce un test sau o firmă sintetică de regresie.
10. Documente de maximum două pagini, un cititor; măsurăm ce se livrează joi și cifra critică.

Ce facem

1. Primul contract scris cu șablonul, pe fluxul 4 (salarii). Owner: Alex, cu Cristi. Gata: aprobat de Prodi și de un contabil. Până pe 3 octombrie.
2. „Micro-TVA-1" creată de mână în SAGA, Facturare și Salarizare, cu august închis. Owner: Alex, cu Cristi. Gata: fișa în repo; contabilul de serviciu a confirmat balanța. Până pe 3 octombrie.
3. Primul demo de joi pe Micro-TVA-1, cu fluxul 4. Owner: Alex. Joi 8 octombrie.
4. docs/contracts/, docs/research/, docs/plans/ în fiecare repo activ, cu CODEOWNERS pe docs/plans/ → Prodi. Owner: Prodi. Până pe 9 octombrie.
5. Handoff-ul pe „De plată" din Dublin, ca exemplu. Owner: Octav cu Bogdan; citit împreună cu Prodi. Până pe 9 octombrie.
6. SuperBoris rulat pe fiecare PR, în CI. Owner: Prodi. Până pe 17 octombrie.
7. Deploy automatizat pe repo-urile active. Owner: Prodi. Până pe 17 octombrie.
8. Cele zece reguli puse în CLAUDE.md-ul fiecărui repo activ. Owner: Prodi. Până pe 17 octombrie.
9. Flag-ul de „date de test" în Facturare, Salarizare, Nucleu, Dublin. Owner: Prodi. Gata: nicio firmă sintetică într-un raport real. Până pe 17 octombrie.
10. Contractul generatorului v1 (31 octombrie) și generatorul livrat (30 noiembrie). Owner: Cristi ca PO, Alex implementează. Gata: demo-ul de joi pe o firmă generată în aceeași zi.

Ce nu facem: nu scriem PRD-uri de 40 de pagini; nu predăm prin link; nu deschidem un flux fără contract; nu testăm pe clienți reali; nu scriem firme direct în baza de date.

De validat de Bogdan: regula 6 păstrează un coleg la treapta a doua până cresc cei patru mid; generatorul în noiembrie, nu în Q1; Cristi ca owner al generatorului.

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