sync SVN r18004/r18007: #6 editare factura emisa - pagina de articole

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

docs/reguli_lucru.md

@@ -12,13 +12,20 @@
    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.
+2. 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 `.sql`
+   si 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 din `docs/` ("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` /
@@ -46,6 +53,20 @@
    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.oExecute` intoarce succes/insucces
+     (`CT_SUCCES`/`CT_INSUCCES`), NU numarul de randuri — o garda `If lnSucces > 0` citita 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.
 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`) ->