romfast/comun
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
837b455687b74afa791bc3374fdf802928f5cb23
comun/docs/reguli_lucru.md
Marius Mutu c599a9c053 sync SVN r17979
2026-08-06 00:34:35 +03:00

7.8 KiB
Raw Blame History

Reguli de lucru agent (comune proiectelor ROA VFP)

  1. 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 pe COMUN — ca sa ajungi la review cu rezultatele testelor, nu cu o propunere netestata; daca nu merge, revii cu git checkout pe 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 cu powershell -File COMUN\utile\curatenie.ps1 (-DryRun listeaza 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.
  2. Comentarii in cod: minime, strict functionale, descriu comportamentul CURENT (ca si cum ar fi scris asa de la inceput) — o linie de regula, 2-3 doar pentru metode cu contract nebanal (parametri, cursor asteptat/lasat deschis, pozitionare la iesire). Istoricul modificarilor sta DOAR in ANTETUL fisierului (niciodata inline) — la fel in .prg si in PL/SQL Oracle. INTERZIS in comentariu: nume de agent ("claude"), referinte la propuneri/decizii/etape (docs/propuneri_*.md, "M2", "T3", "dec.6", "runda27", "E7", "D-H2"), 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.
  3. 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. Completeaza inventar-comun.md la orice descoperire/creare de element comun nedocumentat.
  4. Testare headless (fara IDE): vfp9.exe -A -T "<script.prg>" <param> din PowerShell. Mediu, sabloane, capcane, depanare: depanare_testare_vfp.md.
  5. Editare .vcx/.scx pe text (cache, cp1252 byte-safe, fidelity-check): flux-editare-vfp-text.md. Cautare in binare: cautare_vcx_vct.md. Versiunile .??2 sunt instantanee, pot fi mai vechi decat binarul — verifica mtime inainte de concluzii; continutul real e in .PJX.
  6. 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.
  7. Conventii obligatorii, de citit cand atingi zona respectiva:
    • editezi fisiere cu octeti cp1252 - .vc2/.sc2, dar si .prg (ex. programe\ocautare.prg, unde s-urile cu virgula din masina/si contul/transa sunt octetul 0xBA) -> 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 BD nu spune ce caracter s-a pierdut - toate diacriticele devin la fel; ia octetul corect per pozitie din svn cat <fisier> (necorupt) inainte sa inlocuiesti - o inlocuire oarba cu 0xBA strica a/t cu 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;
    • GO pe un Recno() capturat/primit ca parametru -> conventie_go_recno.md;
    • ALTER TABLE pe cursorul intors de goExecutor.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.
  8. 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.
  9. 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.md anunta pragul la fiecare mesaj.
  10. 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.
  11. La final de lucrare/cercetare: propune actualizarea documentatiei — COMUN\docs\ daca e comun tuturor aplicatiilor, docs\ al proiectului daca e specific (plus inventar-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).
  12. 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 din monitorizare-context.md (marker la 30 de zile).