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.