Proiectul care ține minte

Articolul precedent s-a încheiat cu uneltele pe masă: vocabularul, metoda de a formula cererea, lecțiile celor două tool-uri construite până acum, ritmul de documentare și materia primă publicată de ANAF. Și cu un principiu, „nu cere aplicația, cere planul”.

Am promis că trecem la conversația de planificare. Între timp mi-am dat seama că sărisem o întrebare, și că e una care decide dacă seria are cum să funcționeze.

Nu am spus unde se poartă conversația aceea.

Întrebarea pe care nu am pus-o

Un proiect care se întinde pe mai multe săptămâni are o proprietate incomodă: în săptămâna a șaptea trebuie să știi de ce ai decis, în săptămâna a doua, ca aplicația să citească fișierul într-un anumit fel. Nu „aproximativ de ce”. Exact.

Într-o fereastră obișnuită de chat, informația asta nu există. Fiecare conversație pornește de la zero, iar tu reîncarci de fiecare dată schema, lista testelor, regulile de lucru și contextul deciziilor luate. La a treia repetare renunți și explici pe scurt. La a cincea nu mai explici deloc, iar asistentul începe să propună lucruri care contrazic ce ați hotărât împreună acum o lună.

Nu e o problemă de model. E o problemă de spațiu de lucru.

Articolul acesta o rezolvă și nu trece mai departe. Nu conține plan mode, nu conține promptul de planificare, nu conține cod, și nu conține nici alegerea arhitecturii aplicației. Aceea rămâne, integral, pentru conversația de planificare. Altfel ne-am contrazice singuri pe tema articolului precedent.

Unde lucrăm, spus de la început

Din experiența de până acum, două instrumente merită luate în calcul serios, și pe amândouă le-am folosit efectiv: ChatGPT Work și Claude Cowork. Fac aceleași lucruri esențiale pentru ce urmează: proiecte cu instrucțiuni permanente, acces la un folder local de pe calculator și, sub același nume la amândouă, un mod de planificare separat de execuție. Merită observată convergența: doi producători diferiți au ajuns, independent, la concluzia că etapa de dinaintea codului trebuie să fie un mod distinct, nu o formulare norocoasă a utilizatorului.

Alegerea nu e, de obicei, a ta. Dacă firma a aprobat deja unul dintre ele, acela e răspunsul, iar dacă vine la pachet cu un plan de tip enterprise, partea cea mai incomodă a discuției e ca și închisă: contractul acoperă exact ce, pe un cont personal, rămâne în sarcina ta, adică regimul datelor care intră în instrument.

Dacă îl duci pe cont propriu, alege-l pe cel cu care ești deja familiarizat. Diferențele de capabilitate contează mai puțin decât viteza cu care te miști prin interfață, iar costul e comparabil oricum: un plan individual cu plată e undeva la 20-25 de euro pe lună, cu tot cu TVA, la oricare dintre ele. E un ordin de mărime, nu o cifră de citat: prețurile diferă pe țară și pe monedă și se schimbă, deci se verifică la sursă înainte de plată.

Pentru comparație, singura care mi se pare relevantă: în articolul despre soluțiile de pe piață, cel mai ieftin abonament dedicat de verificare SAF-T era 990 de lei pe an. Ordinul de mărime e comparabil, cu diferența că abonamentul de asistent rămâne util și după ce proiectul acesta se termină.

Varianta gratuită nu e o opțiune aici, și e mai bine spus de la început decât descoperit în a treia săptămână. Pe gratuit primești răspunsuri de la modelele de intrare, limite de utilizare foarte strânse și pauze impuse exact când ai prins ritm. Iar lucrurile de care depinde tot ce urmează, adică proiectele cu instrucțiuni permanente și folderul conectat, nu există acolo deloc.

Mai există și alte soluții, unele bune. Vorbim despre acestea două fiindcă sunt cele pe care le-am testat noi, iar restul seriei trebuie să fie reproductibil pas cu pas, nu descris din auzite.

De aici înainte mergem pe Claude, versiunea desktop, modulul Cowork. Nu pentru că ar fi singura combinație care funcționează, ci pentru că altfel fiecare pas ar trebui scris în două variante, iar seria ar deveni de două ori mai lungă și pe jumătate la fel de utilă. Cine lucrează pe cealaltă va regăsi aceleași noțiuni sub alte nume. Configurația exactă, ca să poți reproduce pașii:

Ce face un proiect, de fapt

Aici e miezul articolului, și e partea pe care merită s-o citești chiar dacă nu te interesează SAF-T deloc.

Un proiect nu e un folder cu fișiere și nu e o conversație mai lungă. E un container care ține laolaltă patru lucruri:

• instrucțiunile, adică regulile care se aplică automat fiecărei conversații din proiect: ton, format, ce e permis și ce nu;
• contextul, adică un folder local de pe calculatorul tău, la care asistentul are acces, plus alte surse de referință aduse prin conectori;
• istoricul, adică discuțiile purtate pe tema respectivă, care rămân acolo;
• memoria, adică ce a reținut asistentul din lucrul de până acum.

Sună administrativ. Consecințele practice nu sunt deloc administrative.

Nu mai reîncarci contextul. Schema oficială, lista celor 33 de teste, nomenclatorul, toate stau în folder. Asistentul le consultă când are nevoie, fără să i le mai atașezi. Ai scris o dată că testele se iau din documentul ANAF și nu din memoria modelului, iar regula se aplică singură, în conversația de azi și în cea de peste șase săptămâni.

Nu mai copiezi din chat. Asistentul citește și scrie direct în folderul conectat. Rapoartele apar acolo unde le vrei, nu într-o fereastră din care le muți manual. E o diferență care pare mică până când o faci de treizeci de ori.

Regulile nu se erodează. Într-un chat obișnuit, o regulă spusă în mesajul al treilea se pierde până la al patruzecilea. Într-un proiect, e citită de la început de fiecare dată.

Ai un loc unde se adună deciziile. Nu doar codul, ci și de ce arată așa. Pentru un contabil, argumentul nu are nevoie de traducere: e diferența dintre a lucra pe un dosar și a lucra pe foi volante.

Un lucru care merită menționat, pentru că e genul de detaliu care liniștește pe cineva care dă prima dată acces la fișierele lui: asistentul poate citi și scrie doar în folderele pe care le-ai conectat explicit, iar înainte să șteargă definitiv un fișier cere permisiune.

Instrucțiunile se așază pe trei niveluri, de la general la particular. Cele globale se aplică în orice lucrezi. Cele de proiect se aplică doar acolo. Cele de organizație sunt setate de administrator, la conturile de firmă. Nu se bat cap în cap, se adaugă.

Cele două fișiere care fac diferența

Peste instrucțiunile din interfață vin două fișiere care stau chiar în proiect. Merită înțeleasă distincția dintre ele, pentru că e curată și ușor de ținut minte:

CLAUDE.md e ce scrii tu. MEMORY.md e ce reține Claude.

Unul e regulamentul. Celălalt e jurnalul de lucru.

CLAUDE.md, regulamentul

Un fișier text simplu, în rădăcina folderului de lucru sau în subfolderul .claude. Conține instrucțiunile și regulile permanente ale proiectului, iar asistentul îl citește la începutul fiecărei sesiuni.

Documentația oficială e neașteptat de directă în privința felului în care se scrie:

• sub 200 de rânduri. Fișierele mai lungi consumă context și scad aderența, adică exact opusul a ce vrei;
• concret, nu general. „Rulează testele înainte de livrare” bate „testează bine”;
• structurat, cu titluri și liste, nu paragrafe dense;
• fără contradicții. Dacă două reguli se bat cap în cap, e la alegerea modelului pe care o urmează. Se recitește periodic și se scot regulile expirate.

Criteriul cel mai util de adăugare, tot din documentație: scrie în CLAUDE.md ce altfel ai reexplica. Dacă ai corectat același lucru a doua oară, dacă ai tastat aceeași clarificare pe care o tastaseși și sesiunea trecută, acolo e locul ei.

Ce intră în fișierul proiectului nostru. Aici se închide un cerc deschis în articolul precedent, unde am scris că cele trei precauții devin clauze de proiect. Iată unde ajung, concret:

• cele trei reguli: fișierul real nu iese din calculator, enunțul testelor se ia din documentul ANAF și nu din memoria modelului, calibrarea se face pe o lună deja depusă și acceptată;
• guardrail-ul, formulat pozitiv: dacă informația nu se află în documentele din folderul de surse, scrie exact „Nu rezultă din textele furnizate”;
• structura folderului, ca asistentul să știe de unde citește și unde scrie;
• convențiile: limba, formatul rapoartelor, cum se numesc fișierele.

Avantajul față de instrucțiunile din interfață merită spus limpede: fișierul stă în folder. Îl vezi, îl deschizi cu orice editor, îl trimiți unui coleg, îl păstrezi când schimbi calculatorul. Instrucțiunile din interfață trăiesc în cont. Fișierul trăiește în proiect.

Numele diferă de la un furnizor la altul. La OpenAI, agentul de programare citește AGENTS.md, care nu e formatul unui singur producător, ci un standard deschis, aflat sub Agentic AI Foundation din Linux Foundation și adoptat de peste douăzeci și cinci de unelte. Gemini CLI citește implicit GEMINI.md, dar poate fi configurat să citească tot AGENTS.md. Conținutul e același ca natură, adică regulile permanente ale proiectului. Recomandarea practică pentru cine folosește mai multe instrumente e un singur fișier ca sursă de adevăr, cu celelalte configurate să trimită la el. Două fișiere întreținute în paralel devin, inevitabil, două seturi de reguli care se contrazic, iar diferența de rezultat nu se mai explică.

MEMORY.md, jurnalul

Al doilea fișier nu îl scrii tu. Îl scrie asistentul, singur, pe măsură ce lucrați.

Sunt notițe pe care și le ia despre patru lucruri: cine ești și cum lucrezi, corecturile pe care i le-ai dat și abordările pe care i le-ai confirmat, mersul proiectului cu deciziile și termenele lui, și unde se află informația din afara proiectului.

Mecanismul e simplu și eficient. MEMORY.md e un index, câte un rând per notiță, și se încarcă la începutul fiecărei conversații. Detaliile stau în fișiere separate, pe teme, pe care asistentul le deschide doar când are nevoie de ele. Așa poate ține minte mult fără să plătească de fiecare dată contextul a tot ce știe, adică fără să provoace exact degradarea descrisă la context rot.

Ce nu salvează, tot din documentație: lucrurile pe care le poate deduce singur din fișiere, și lucrurile pe care CLAUDE.md le spune deja. Nu dublează.

Totul e text simplu, pe care îl poți citi, edita sau șterge direct din folder. În varianta de linie de comandă există și comenzi dedicate, /memory pentru fișierele de memorie și /context pentru ce s-a încărcat efectiv în sesiunea curentă. În interfața desktop, verificarea cea mai sigură rămâne tot cea directă: deschizi fișierul și îl citești.

De ce contează pentru noi. În săptămâna a șaptea, întrebarea „de ce am ales varianta asta” are un răspuns scris. Nu se reconstruiește din memorie și nu se reia discuția de la zero. E chiar problema de la care a pornit articolul.

Skills: procedurile scrise o dată

A treia piesă. Un skill e un fișier de instrucțiuni prin care asistentul duce la capăt o sarcină anume, în mod repetabil. Stă într-un folder propriu, cu un fișier SKILL.md înăuntru, plus, dacă e cazul, scripturi și fișiere auxiliare.

Partea elegantă, care rezolvă o problemă reală: din SKILL.md se încarcă la pornire doar numele și descrierea. Corpul se încarcă abia când skill-ul e chemat. Poți avea douăzeci de proceduri scrise în detaliu fără să plătești contextul niciuneia până nu o folosești.

Regula de separare între cele trei mecanisme, care merită reținută:

Pentru proiectul nostru, skill-ul evident e procedura de adăugare a unui test de consistență: citește enunțul din documentul ANAF, scrie verificarea, rulează pe luna de calibrare, compară rezultatul cu fișierul real, raportează diferențele. Se scrie o dată. Se folosește de 33 de ori. E exemplul care justifică noțiunea mai bine decât orice definiție.

Cum arată folderul proiectului nostru

SAFT-D406\
├─ CLAUDE.md         regulile permanente ale proiectului
├─ .claude\
│  └─ skills\        procedurile repetabile
├─ surse\            schema oficiala, definitiile, cele 33 de teste, nomenclatorul
├─ calibrare\        luna deja depusa si acceptata
├─ app\              aplicatia, pe masura ce se construieste
└─ rapoarte\         iesirile

Un detaliu mărunt care costă o oră când îl descoperi singur: fără diacritice în numele folderelor. Sparg scripturile și comenzile de consolă pe Windows. Textul dinăuntru se scrie normal, cu diacritice complete. Numele de fișiere și foldere, nu.

Structura asta nu e inventată pentru articol. Proiectul în care se scriu chiar articolele de pe site arată la fel: un fișier de reguli în rădăcină, o memorie a proiectului, skill-uri pentru sarcinile care se repetă, și câte un folder per articol cu documentarea și draftul înăuntru.

Laptopul de companie

Până aici am presupus că poți instala ce vrei pe calculatorul tău. Pe un laptop de companie, de multe ori nu poți, iar asta schimbă lucrurile.

Există două scenarii, și merită să știi în care ești înainte să plătești un abonament.

Scenariul deschis. Ai drepturi pe calculator. Asistentul primește un folder și lucrează în el: creează fișiere, folosește instrumente instalate, testează, corectează. Bucla de la „scrie codul” la „rulează-l și spune-mi ce a ieșit” se închide fără tine. Tu verifici rezultatul, nu execuți pașii.

Scenariul restrictiv. Laptop administrat de IT. Nu ai drepturi de administrator, politica poate bloca instalările, iar aplicațiile permise sunt o listă scurtă și explicită.

Restricțiile nu sunt un capriciu și nu se ocolesc. Sunt răspunsul la un risc real, iar contabilul e tocmai omul care lucrează cu datele cele mai sensibile din firmă. Instalarea unui asistent AI pe un laptop de companie fără aprobare are un nume, e chiar un termen din glosarul articolului precedent: shadow AI.

Company Portal, locul unde afli în două minute

Probabil ai pe bara de activități o aplicație numită Company Portal, afișată pe un Windows în română ca Portal firmă. Denumirea englezească e cea care contează în discuția cu IT-ul, fiindcă aceea apare în documentație. Face parte din sistemul prin care compania își administrează calculatoarele. Prin ea accesezi în siguranță resursele organizației, îți înscrii dispozitivul și, partea care ne interesează, instalezi aplicațiile pe care IT-ul le-a aprobat deja.

E primul lucru de verificat, înainte de orice abonament. Deschizi Company Portal, te uiți în lista de aplicații disponibile și afli imediat dacă asistentul pe care voiai să-l folosești e deja acolo. Dacă e, discuția s-a încheiat: îl instalezi și ai și acordul organizației.

Dacă nu e, ai două variante oneste. Ceri IT-ului să îl evalueze, sau lucrezi pe un calculator personal, fără date reale ale firmei. A treia variantă nu există.

O cerere către IT are șanse mult mai mari dacă spune patru lucruri, în trei rânduri: ce aplicație, pentru ce sarcină, ce date atinge și ce date nu atinge. „Aș vrea să instalez X” nu e o cerere, e o dorință.

Nu toate firmele folosesc același sistem de administrare, deci s-ar putea să găsești altă denumire. Principiul rămâne: undeva există o listă de aplicații preaprobate, și merită căutată înainte să ceri.

Pentru restul seriei presupunem scenariul restrictiv, din motivul cel mai simplu: dacă pașii funcționează în condiții restrânse, funcționează și în condiții largi. Invers nu e adevărat. Cine are laptopul liber va parcurge aceiași pași mai repede.

Vocabularul de construcție

Cincisprezece termeni care apar din momentul în care asistentul începe să propună soluții tehnice. Sunt, aproape toți, despre ce ai voie să instalezi și să rulezi, deci exact lista pe care o cauți în Company Portal sau o pui într-o cerere către IT.

Ca și în articolul precedent, denumirea duce la arhiva de termeni, iar descrierea de aici e cât să știi despre ce e vorba.

Ultimii trei se leagă direct de lecțiile tool-ului precedent, despre care am scris în articolul anterior: ce se schimbă în timp merge în fișierul de configurare, nu în cod, unde ar deveni hardcoding, iar fiecare operație se scrie în jurnal, pentru că „a apărut o eroare” nu e un mesaj, e o ridicare din umeri.

Checklistul

De bifat înainte de articolul următor. E prima dată în seria asta când ai efectiv ce face, nu doar ce citi.

• am parcurs lista de unelte din articolul precedent și știu ce am deja pe masă;
• am verificat în Company Portal ce asistenți sunt aprobați de IT;
• știu dacă am sau nu drepturi de instalare pe calculatorul de lucru;
• am un plan cu plată, care include lucrul în proiecte și folder conectat;
• am instalat aplicația desktop;
• am creat proiectul dedicat și i-am scris instrucțiunile;
• am creat folderul de lucru, cu subfolderele din capitolul 6, fără diacritice în nume;
• am conectat folderul la proiect;
• am scris CLAUDE.md, cu cele trei reguli și cu guardrail-ul;
• am pus în surse\ schema oficială, fișierul cu definiții și lista celor 33 de teste;
• am pus în calibrare\ o lună deja depusă și acceptată;
• am pornit sau am reluat AI Journal.

Dacă ai bifat tot, ai un spațiu de lucru care ține minte. Restul seriei stă pe el.

Ce urmează

Săptămâna viitoare deschidem, în sfârșit, conversația de planificare. Promptul se publică integral, așa cum a fost scris, cu tot cu cele trei rânduri care îi cer asistentului să pună întrebări înainte să înceapă. Publicăm și întrebările pe care le pune, și răspunsurile date, pentru că acolo se vede diferența dintre metoda asta și o cerere directă.

La finalul ei iese o specificație. Din ea, în articolul de după, iese primul cod care deschide efectiv un fișier D406.

Uneltele erau pe masă de dimineață. De acum au și unde să stea.