ofacturare_editare.prg (nou): helpere comune - garda eFactura, cursoarele notei si ale rulajelor, randul de vanzare corespunzator notei si liniile de articole citite din view-ul VVANZARI_ARTICOLE. omodificari.vc2 (frm_modific2024): pagina noua de articole ale facturii, deocamdata doar afisare. Apare numai cand ofacturare_editare.prg e inregistrat si documentul are rand in VANZARI; in ROACONT si ROAGEST, unde fisierul nu e incarcat, pagina lipseste si registrul jurnal ramane neatins. Randul de vanzare al notei se cauta pe toate tripletele distincte (nract, serie_act, dataact) din nota, pentru ca primul rand poate fi o incasare. ofacturare_comun.vc2 (frm_facturi): do_editare_factura si butonul aferent, dupa modelul lui do_sterge, cu garzile de luna inchisa, luna curenta, document sters, referinte si eFactura. docs: comentariile se scriu strict necesar, si in cod si in scripturile de migrare - fara referinte la planuri, stories, decizii sau erori, istoricul doar in antetul fisierului. Plus regula zero (predarea contextului), capcanele de la testarea headless si completari pe fluxul text -> binar. utile/Teste: suita de regresie pentru editarea facturii si harness-ul watchdog (nu sunt in SVN, unde utile/Teste e ignorat). .gitignore ignora si capturile PNG si watchdog_out/, ramase din rulari. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
9.5 KiB
9.5 KiB
Reguli de lucru agent (comune proiectelor ROA VFP)
- Modificari de cod: diff ca FISIER
docs\diff_runda<N>_<subiect>.patch(git diff --no-index <baseline.bak> <editat>), nu in terminal. COMMIT-ul e singurul pas care asteapta aprobarea patch-ului. Write-back-ul in binar (txt2vcx) si testele se fac IMEDIAT dupa editarea.vc2/.sc2, fara sa astepti raspunsul — inclusiv peCOMUN— ca sa ajungi la review cu rezultatele testelor, nu cu o propunere netestata; daca nu merge, revii cugit checkoutpe binare (.vcx+.vct) sau cu write-back din*.pre_runda*.bak. Patch-urile (in .gitignore,docs/diff_runda*.patch) nu se comit niciodata, raman local. Curatenia de dinainte de commit NU se face pe cap de agent, ci cupowershell -File COMUN\utile\curatenie.ps1(-DryRunlisteaza fara sa stearga): patch-uri, handoff-uri/planuri de runda,*.pre_runda*.bak,.bak-urile din cache-ul text si artefactele de test (screenshots*,uisync*,.fxp,.err, loguri). Sterge doar fisiere neurmarite de git — cele tracked sunt sarite. - Comentarii in cod SI in scripturile de migrare
.sql: minime, strict functionale, descriu comportamentul CURENT (ca si cum ar fi scris asa de la inceput). Doar daca e cazul — un comentariu se scrie acolo unde explica o ramura sau un filtru care nu se citeste singur, ca sa se inteleaga codul; unde codul e limpede, nu se comenteaza. O linie de regula, 2-3 doar pentru metode cu contract nebanal (parametri, cursor asteptat/lasat deschis, pozitionare la iesire), 4-5 in antetul unui script de migrare (ce e obiectul si ce contract are). Istoricul modificarilor sta DOAR in ANTETUL fisierului (niciodata inline) — la fel in.prg, in.sqlsi in PL/SQL Oracle. INTERZIS in comentariu: nume de agent ("claude"), referinte la planuri, stories, propuneri, decizii, etape sau erori (docs/plan_*.md,docs/propuneri_*.md, "#6", "S4", "M2", "T3", "dec.6", "runda27", "E7", "D-H2"), trimiteri la rapoartele dindocs/("vezi raportul, sectiunea ..."), justificarea alegerii facute (de ce numele acesta, de ce s-a respins varianta cealalta), istoricul modificarii ("inlocuieste...", "nu mai depinde de...", "mutat din..."), date si autori pe cod nou. Comentarii vechi in stil jurnal nu se rescriu din oficiu — doar cand blocul e oricum atins sau la cerere explicita. Antet: o singura intrare CUMULATIVA per functionalitate (*!* DD.MM.YYYY/*!* autor/*!* ce face, 1-2 fraze) — la revenire se rescrie intrarea, nu se adauga alta; autorul e cine semneaza livrarea (ex.marius.mutu), niciodata agent. Doar comportamentul final — fara revizii/runde/patch-uri/corectii. La rezolvari de erori: fara comentarii. Explicatiile merg in docs/ sau in mesajul de commit, nu in cod. Changelog (changelog_<aplicatie>.txt): strictul necesar, pe limba utilizatorului, non-tehnic — 1-3 fraze/intrare, fara detalii de implementare, fara enumerarea locurilor atinse. Cat timp lucrarea n-a ajuns la utilizatori, erorile introduse si corectate in interior NU se mentioneaza — intrarea descrie functionalitatea finala,:nou:/:modificare:;:eroare:doar pentru erori care au fost in productie. - Modificari minime si SCOPED: doar ce s-a cerut, doar pe cazul cu problema, fara refactorizari
din oficiu. Cauta intai ce exista (
inventar-comun.md) si refoloseste; daca lipseste ceva, propune COMPLETAREA unei functii/tabele/view comune, nu o varianta paralela. 80/20: solutia cea mai simpla care rezolva cazul real. Completeazainventar-comun.mdla orice descoperire/creare de element comun nedocumentat. - Testare headless (fara IDE):
vfp9.exe -A -T "<script.prg>" <param>din PowerShell. Mediu, sabloane, capcane, depanare:depanare_testare_vfp.md. - Editare .vcx/.scx pe text (cache, cp1252 byte-safe, fidelity-check):
flux-editare-vfp-text.md. Cautare in binare:cautare_vcx_vct.md. Versiunile.??2sunt instantanee, pot fi mai vechi decat binarul — verifica mtime inainte de concluzii; continutul real e in.PJX. - Delegare: implementarile, testele, verificarile si cercetarile se dau unor subagenti Sonnet in
background (lane-uri paralele); sesiunea principala doar orchestreaza si verifica, ca sa nu i
se umple contextul. Misiuni lungi: subagenti proaspeti per sarcina (max ~200-250k
tokens/subagent), nu unul singur cu context acumulat; handoff compact pe disc:
orchestrare-subagenti.md. Verificarea a ce se intoarce — pentru executie delegarea merge, pentru concluzii nu:- citeste contractul functiei apelate, nu-l presupune. Un raport care descrie corect
structura codului poate gresi sensul: ex.
goExecutor.oExecuteintoarce succes/insucces (CT_SUCCES/CT_INSUCCES), NU numarul de randuri — o gardaIf lnSucces > 0citita ca "are randuri" a produs un bug inexistent, raportat ca blocant. Deschide functia. - fix ingust, nu supra-constructie. Cand premisa se corecteaza, corectia se restrange: mecanismele noi introduse "ca sa fie sigur" diverg de la codul-sablon si blocheaza refolosirea lui in alta parte.
- "zero cazuri in date" nu dovedeste nimic pe scheme cu date de test; raspunsul vine din cod. Si invers: o potrivire de cifre pe 1-2 documente nu e o regula.
- cere raportul sa separe "testat" de "analizat static", si ce n-a putut fi acoperit. Un agent care nu e intrebat explicit va prezenta amandoua la fel.
- spune-i ca poate infirma briefingul. Altfel implementeaza corectia ceruta chiar cand a descoperit ca nu e nevoie de ea.
- citeste contractul functiei apelate, nu-l presupune. Un raport care descrie corect
structura codului poate gresi sensul: ex.
- Conventii obligatorii, de citit cand atingi zona respectiva:
- editezi fisiere cu octeti cp1252 -
.vc2/.sc2, dar si.prg(ex.programe\ocautare.prg, undes-urile cu virgula dinmasina/si contul/transasunt octetul0xBA) ->conventie_encoding_cp1252.md. Orice write cu un tool ce nu scrie cp1252 nativ (Edit/Write) corupe caracterele >= 0x80 din TOT fisierul (0xBA->EF BF BD), chiar la o singura linie schimbata, si o repeta la FIECARE scriere — editeaza tot ce ai de editat, verifica byte-level si repara o singura data DUPA ultima scriere. Verificare:perl -ne 'print "$.\n" if /[\x80-\xFF]/' <fisier>; reparare (pt.0xBA):perl -e 'binmode(STDIN);binmode(STDOUT);local $/;$_=<STDIN>;s/\xEF\xBF\xBD/\xBA/g;print' < f > f.tmp.EF BF BDnu spune ce caracter s-a pierdut - toate diacriticele devin la fel; ia octetul corect per pozitie dinsvn cat <fisier>(necorupt) inainte sa inlocuiesti - o inlocuire oarba cu0xBAstricaa/tcu caciula (0xE3,0xFE) din alte fisiere; - adaugi/rearanjezi controale pe formulare sau coloane in grid ->
conventie_ux_formulare.md; - grid needitabil pe formular cu 2+ grid-uri ->
capcana_grid_controlsource.md; - adaugi o coloana intr-un grid deja livrat (ordinea din clasa e neutralizata de
preferintele salvate per utilizator) ->
capcana_grid_preferinte_utilizator.md; GOpe unRecno()capturat/primit ca parametru ->conventie_go_recno.md;ALTER TABLEpe cursorul intors degoExecutor.oExecute()->conventie_goexecutor_alter_table.md;- testare UI / prin MCP ->
testare-ui-vfp.md,testare-vfp-mcp.md; - garzi pe valori NULL din Oracle ->
conventie_null_vfp.md; - export date din Oracle ->
oracle_export.md; - actualizarea ROA nu se finalizeaza (job update, PACK_UPDATE) ->
depanare-pack-update.md; - modifici schema Oracle (tabele/view-uri/pachete) ->
scripturi-migrare-db.md.
- editezi fisiere cu octeti cp1252 -
- Eroare raportata de utilizator: nu analiza statica indelungata — scrie intai un test care o reproduce pe fluxul real; el da cauza si confirma remedierea. Analiza statica doar cat sa stii ce sa pui in test.
- Context sesiune principala: la peste 250k salveaza contextul intr-un handoff pe disc, il
predai unei sesiuni noi si te opresti. Limita maxima absoluta: 275k. Nu estima - masoara:
hook-ul din
monitorizare-context.mdanunta pragul la fiecare mesaj. - Fisier de progres MASTER per proiect (
docs\progres.md): la zi pe tot parcursul, nu doar la predare — stare curenta, facut/testat, ipoteze excluse (cu dovada), ce urmeaza, fisiere atinse, comenzi de rulat. O sesiune noua porneste de acolo, fara sa reia investigatia. E ajutor de predare, nu documentatie: dupa commit, cu toate sarcinile terminate, se sterge. - La final de lucrare/cercetare: propune actualizarea documentatiei —
COMUN\docs\daca e comun tuturor aplicatiilor,docs\al proiectului daca e specific (plusinventar-comun.md, regula 3). Doar relevant si reutilizabil (80/20): flux ascuns, capcana, procedura/tabela cheie — nu tot ce ai atins, nu verbose. Cateva randuri; propui, nu scrii din oficiu. O notita = regula + strictul de context ca sa fie aplicabila: fara cazul particular in care ai gasit-o, fara simptomele lantului de erori, fara ce se deduce din cod (cititorul stie deja). - Revizuire periodica a documentatiei (
COMUN\docs\,docs\al proiectului, inclusiv acest fisier): compacteaza pastrand semantica — taie ce se deduce din cod, exemplele repetate, istoricul, tot ce nu mai schimba o decizie. Scopul: docs + reguli sa ocupe cat mai putin context la incarcare. Propui rezultatul, nu rescrii din oficiu; nu pierzi nicio regula/capcana, doar cuvintele in plus. Fisierele de reguli/conventii se completeaza doar cu ce e super-util, simplu si concis. Cadenta o da hook-ul dinmonitorizare-context.md(marker la 30 de zile).