roafacturare/docs/cercetare/handoff_test_writeback.md

Handoff — test real write-back buton=1 (do_editare_factura)

Predare la prag de context, conform Regula zero din CLAUDE.md. Fara analiza noua aici, doar starea.

CORECTIE IMPORTANTA fata de ce stie team-lead acum

Team-lead a verificat baza INAINTE de ultima rulare si a raportat "id_vanzare=1048 e neatins, nimic de curatat". Nu mai e adevarat - intre timp corectia LOCAL -> PRIVATE a fost aplicata SI rulata, iar testul a reusit complet, cu COMMIT real, de doua ori. Documentul id_vanzare=1048 a fost modificat legitim, exact cum era scopul aprobat de Marius:

• cod a trecut 1140886 -> 1140893 (TEST 1, salvare fara modificari) -> 1140894 (TEST 2, cu explicatia unui rand ACT modificata: "NOTA 1" -> "NOTA 1 (test writeback)").
• Cod-ul curent activ in baza pentru acest document este 1140894, nu 1140886.
• Randurile vechi (cod=1140886 si cod=1140893) raman in ACT/RUL cu STERS=1 - asta e comportamentul normal, prin design (vezi "Fapte stabilite" din docs\progres.md).
• VANZARI.total_cu_tva/total_fara_tva/total_tva/id_fact/sters au ramas neschimbate, verificat si din log VFP si independent prin sqlplus dupa rulare.
• VANZARI_DETALII a ramas neatins (verificat, cum era de asteptat pe aceasta cale).

Raport complet deja scris: docs\cercetare\rec_test_writeback.md (tabel cu cele 5 verificari pe ambele teste, PASS pe toate, plus istoricul celor 2 incidente si cum s-au rezolvat). Rezultatul a fost deja trimis catre team-lead prin mesaj ("PASS complet pe ambele teste, commit real confirmat independent") - posibil incrucisat cu mesajul lui de STOP.

1. Starea fisierului de test

COMUN\utile\Teste\editare_factura\test_writeback_buton1.prg (ultima modificare azi, 08.08.2026).

• Corectia LOCAL -> PRIVATE (linia ~133, acum ~149-153): DA, APLICATA. Declararea curenta:

  PRIVATE pnAn, pnLuna, lnCod, lnIdFact
  LOCAL lnSters, llEProforma
  LOCAL lnIdSet, lnIdFactD, lnSucces, llGasitRand
  

  (restul variabilelor de test raman LOCAL, corect - nu sunt folosite ca bind ? in SQL).
• frm_modific2024 e ocolit COMPLET (nu se mai instantiaza deloc) - s-a blocat de doua ori headless (a se vedea sectiunea 3) si s-a decis cu team-lead sa fie scos din harness. buton=1 e fortat direct in cod, inainte_de_do_termin NU se executa. Thisform.do_deschide_tranzactie/do_inchide_tranzactie sunt reproduse inline in fisier (MyDeschideTranzactie/MyInchideTranzactie, copiate dupa _frm_base.vc2:252-302).
• PUBLIC gcMockUltimMesaj, gnMockUltimTip + logare goExecutor.cEroare dupa fiecare pas: DA, adaugate (procedura LogMockSiEroare, apelata dupa fiecare OSCRIE_IN_FISIERE si dupa finalizeaza_modificare_nota).
• Logare granulara [chk] inainte/dupa fiecare sub-pas din ramura buton=1: DA, adaugata.
• Fisierul e in stare FINALA, functionala - nu mai necesita nicio corectie pentru scopul cerut. Orice rulare viitoare pe acest script trebuie sa citeasca cod-ul curent din VANZARI (nu presupune 1140886), pentru ca scriptul insusi face asta (interogheaza VANZARI la inceputul fiecarui apel al procedurii test_editare_writeback).

2. Comanda exacta de rulare

$testPrg = 'D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_writeback_buton1.prg'
Start-Process 'C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9.exe' -ArgumentList '-A','-T',"`"$testPrg`"" -PassThru

Log: D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_writeback_buton1_log.txt (suprascris de la zero la fiecare rulare - STRTOFILE(..., lcLog) fara ,1 pe prima linie).

Inainte de orice rulare: verifica sa nu existe deja un vfp9.exe activ (Get-CimInstance Win32_Process -Filter "Name='vfp9.exe'") si sterge .FXP/.ERR/log vechi din acelasi folder.

3. Ce s-a stabilit deja (nu se reia)

• Prima varianta a testului instantia frm_modific2024 (modeless, WindowType=0, ca in test_page3_articole.prg) - s-a blocat de doua ori, headless, fara nicio linie de eroare in log: prima data pe un dialog nativ Windows "Open" (#32770, confirmat prin EnumWindows/GetWindowText pe procesul viu), a doua oara (dupa ce s-a scos frm_modific2024 si inainte de corectia PRIVATE) pe un dialog nativ VFP "View Parameter" ("Enter the value for pnLuna"), confirmat de captura de ecran trimisa de Marius si de EnumWindows local.
• Ipoteza "backupset" (clasa BackupXML, oproceduri_comune.prg:3685-3987) respinsa: foloseste doar CREATE CURSOR/Cursortoxml/Delete File, niciun USE pe tabela lipsa; si oricum prima rulare (cea cu -1) trecuse deja prin acelasi cod fara sa se blocheze.
• Cauza reala a dialogului "View Parameter": pnAn/pnLuna erau declarate LOCAL in harness, in loc de PRIVATE ca in codul real (ofacturare_comun.vc2:3742). PRIVATE le face vizibile in josul stivei de apel, unde goExecutor.oExecuta rezolva bind-urile ?pnLuna/?pnAn din apelul catre pack_contafin.finalizeaza_modificare_nota. Cu LOCAL, VFP nu le gasea si deschidea dialogul nativ de introducere manuala - niciodata catchabil prin ON ERROR/TRY/mock de amessagebox (nu e un AMESSAGEBOX, e un mecanism VFP intern).
• Dupa corectie (PRIVATE), ambele teste au trecut curat, cu COMMIT real - vezi "CORECTIE IMPORTANTA" de mai sus si docs\cercetare\rec_test_writeback.md pentru tabelul complet.
• Inainte de corectie, o rulare intermediara aratase OSCRIE_IN_FISIERE(2,.T.,.T.) => -1 (esec curat, cu ROLLBACK, fara nicio scriere) - acel -1 nu s-a mai reprodus dupa corectia PRIVATE (ambele OSCRIE_IN_FISIERE au intors 1 in rularea finala). Motivul exact al lui -1 din acea rulare intermediara ramane neexplicat definitiv (posibil efect secundar al aceleiasi probleme de scope, posibil altceva) - nu mai e relevant, testul final a trecut, dar daca reapare vreodata pe alt document, gcMockUltimMesaj/goExecutor.cEroare sunt deja logate dupa fiecare pas.

4. Ce e interzis (neschimbat)

• Nu mock-ui OSCRIE_IN_FISIERE.
• Nu modifica codul aplicatiei (ofacturare_comun.vc2, oscrie_in_fisiere.prg, omodificari.vc2 etc.) - niciun bug de aplicatie n-a fost gasit, toate problemele au fost in harness.
• Nu folosi cod=1140888 / cod=1140885 (baze de regresie ale test_incarca_cursoare.prg).
• Nu rula git_sync.ps1 si nu atinge omodificari.vc2/.vcx (alt agent lucreaza in paralel pe PAGE3, task separat).

5. Starea datelor - vezi CORECTIA de la inceputul fisierului

Pe scurt: id_vanzare=1048 a fost editat legitim de doua ori prin testul aprobat. cod curent = 1140894. Nimic de reparat sau de facut rollback - e rezultatul dorit al testului. Daca se doreste un test suplimentar pe alt document, se alege un cod/id_vanzare nou (nu 1140886/1140888/ 1140885).

6. Fisiere temporare

Nimic de sters in working copy. test_writeback_buton1.FXP si test_writeback_buton1_log.txt din COMUN\utile\Teste\editare_factura\ sunt artefacte normale, in acelasi tipar cu test_incarca_cursoare.FXP/test_page3_articole.FXP deja existente in acel folder (folder de teste, neurmarit ca binare in git). Fisierele de diagnostic SQL folosite pentru verificarea independenta au fost in scratchpad-ul de sesiune (C:\Users\...\Temp\claude\...\scratchpad\), in afara working copy - nu necesita curatare de catre urmatorul agent.

Un fisier test_baseline_isolation.prg/.FXP/_log.txt exista in acelasi folder, creat inainte de aceasta sesiune si NU de agentul curent - probabil al agentului paralel de pe alta sarcina; nu l-am atins.