roafacturare/docs/cercetare/handoff_propr_custom.md

Predare — deblocarea proprietatilor custom pe frm_modific2024

Bloc de lucru TERMINAT CU SUCCES (nu la prag de context — predare la incheierea blocului, conform Regula zero).

Concluzie

Ipoteza principala ("FoxBin2Prg Prg2Bin nu poate crea proprietati noi intr-un .vcx") e INFIRMATA, cu dovada directa (test izolat, mai jos). Cauza reala era alta, si s-a reparat.

Cauza reala, cu dovada

Proprietatile noi (larearticolevanzari, nidvanzare, ntipvanzare) fusesera adaugate de agentul anterior doar in blocul *<PropValue> (valorile), dar lipseau din *<DefinedPropArrayMethod> (lista *p: care inregistreaza o proprietate custom ca membru real al clasei). Fara intrarea *p:, Prg2Bin scrie linia de valoare, dar VFP n-o materializeaza ca proprietate pe obiect — de-asta PEMSTATUS intorcea .F. desi valoarea aparea in text si supravietuia fidelity-check-ului (fidelity-ul verifica doar ca textul regenerat == textul editat, nu ca proprietatea exista pe obiect).

Regula era deja documentata pentru metode in COMUN\docs\flux-editare-vfp-text.md:76-78 ("Metoda noua de clasa cere *m: nume in *<DefinedPropArrayMethod>; fara ea, ... o arunca tacut") — se aplica identic si proprietatilor (*p:), doar ca nu era scrisa explicit acolo. De adaugat separat in acel fisier (nu am facut-o eu, e in afara sarcinii primite).

Testul izolat care a transat ipoteza

Nu am atins omodificari pentru test. Am copiat COMUN\clase\_pf_base.vcx/.vct/.vc2 (clasa _pfbase, fara nicio importanta) intr-un folder complet izolat in scratchpad, am adaugat text-only o proprietate noua (ltestpropnoua) cu intrare *p: corecta, write-back cu txt2vcx.ps1 (proiect izolat, nu ProjectRoot real), apoi CREATEOBJECT + PEMSTATUS:

PEMSTATUS(ltestpropnoua)=DA  valoare=.T.

Confirma ca fluxul text->bin poate crea proprietati noi, cand sunt inregistrate corect.

Bonus gasit tot in acest test: FoxBin2Prg foloseste o colatie unde _ sorteaza dupa literele obisnuite (nu ordine ASCII simpla pe litere mici) — nidvanzare < nid_set alfabetic pentru tool, desi '_' (0x5F) < 'v' (0x76) in ASCII brut pe litere mici. Confirmat printr-un al doilea test izolat: am scris *p: nid_set inaintea lui *p: nidvanzare (ordine ASCII) — fidelity check a picat cu exact acest motiv; textul canonic din <staging>\verify\ a aratat ordinea corecta, nidvanzare inaintea lui nid_set. Coincide cu ordinea deja existenta, corecta, din *<PropValue>-ul real al lui frm_modific2024. De adaugat in flux-editare-vfp-text.md / foxbin2prg\CLAUDE.md ca nota separata (nu am facut-o, in afara sarcinii primite).

Ce am schimbat in omodificari.vc2/.vcx/.vct

COMUN\clase\omodificari.vc2, clasa frm_modific2024 (:6375-15856), blocul *<DefinedPropArrayMethod> — 3 linii *p: noi, in ordine alfabetica (colatia tool-ului):

• *p: larearticolevanzari — linia 6804 (inainte de lavertizatexigibilizare)
• *p: nidvanzare — linia 6811 (inainte de nid_set)
• *p: ntipvanzare — linia 6818 (dupa ntaxcode)

Blocul *<PropValue> nu a fost atins — valorile erau deja acolo, deja in ordinea corecta, de la agentul anterior.

Write-back real cu txt2vcx.ps1 -AllowComun — fidelity check OK. Backup pastrat: COMUN\clase\omodificari.vc2.pre_proprietati_custom.bak (starea dinainte de aceasta reparatie, distinct de .pre_s4runda1.bak mai vechi).

Capcana pe care am picat-o si am reparat-o singura: prima incercare a folosit $lines.IndexOf(text_exact) ca sa gasesc pozitia liniilor *p: tinta — a gasit o potrivire falsa mult mai devreme in fisier (alta clasa cu proprietati cu nume asemanator), inserand 3 linii in locul gresit. Am restaurat din backup inainte de a rula orice write-back cu starea gresita, am refacut editarea cu index-uri de linie verificate explicit (assert pe continutul exact al liniei), si abia apoi am scris pe disc. Fisierul de pe disc e curat, o singura editare corecta.

Verificare finala — PASS complet

test_page3_articole.prg sub watchdog_vfp.ps1 -AutoDismiss: exit 0, 0 dialoguri.

cod=1140888: PageCount = 3 (asteptat 3), lAreArticoleVanzari = .T. (asteptat .T.), nIdVanzare = 1050 -> PASS
cod=1125486: PageCount = 2 (asteptat 2), lAreArticoleVanzari = .F. (asteptat .F.)                    -> PASS

Toate celelalte asertii din suita (verifica_vanzare_nota x3, verifica_coliziune_cod) tot PASS, neschimbate. PEMSTATUS(loForm,'lAreArticoleVanzari',5) si PEMSTATUS(loForm,'nIdVanzare',5) acum .T. (erau .F. la predarea anterioara).

Starea la predare

• Fara commit git/SVN. svn status pe COMUN arata M pe omodificari.vcx/.VCT (write-back real); .vc2 e I (ignorat de SVN, urmarit doar de comun.git).
• comun.git status arata omodificari.vc2 modificat — diff-ul cumuleaza toata munca necomisa de azi pe S4 runda 1 (PAGE3, grid, cele 3 proprietati), nu doar reparatia mea; nimic neasteptat.
• Fara tranzactii Oracle deschise — testul de verificare face doar SELECT-uri prin goExecutor, zero scriere.
• Niciun proces vfp9.exe ramas viu (verificat, Get-Process vfp9 gol).
• Scratch-ul de test izolat (_pf_base.vcx copiat) a ramas doar in C:\Users\...\scratchpad\testproj\ — in afara working copy, nu necesita curatare.

Ce ramane (in afara sarcinii primite azi)

Pasii 3-5 din docs\progres.md sectiunea „#6, S4 runda 1": scoaterea liniilor [BISECT]/[DIAG] din test, stergerea test_baseline_isolation.prg (concluzia lui e nula, vezi handoff anterior), scrierea docs\diff_s4_runda1_page3.patch + docs\cercetare\rec_s4_runda1.md, actualizarea COMUN\docs\testare-ui-vfp.md cu cele trei capcane noi (DO...WITH prin referinta, SET PATH ROACONT, watchdog fara input real) plus cele doua descoperite acum (*p: obligatoriu si pentru proprietati, colatia cu _ dupa litere) — raman pentru runda urmatoare.