# Handoff — S4 runda 1 (PAGE3 doar afisare), predare pe prag de context

Sesiune intrerupta la prag de context (`monitorizare-context.md`). Stare **stabila si consistenta**
(text = binar), dar cu schele de diagnostic inca in cod — de scos inainte de livrare.

## 1. Ce am modificat, unde, si write-back-ul

Toate in `COMUN` (cross-proiect).

- **`COMUN\programe\ofacturare_editare.prg`** — **write-back N/A (e `.prg`, nu `.vcx`, se ruleaza direct)**.
  Antet actualizat (linia cu `*!* helpere...`) + doua functii noi, adaugate la coada fisierului:
  - `IncarcaVanzareNota(tnCod, tnNract, tcSerieAct, tdDataAct)` — gaseste randul din `VANZARI`
    corespunzator notei curente, in cursorul `tvanz`.
  - `IncarcaArticoleFactura(tnIdVanzare)` — incarca liniile active din `VANZARI_DETALII` (+ denumire
    articol/gestiune/valuta) in cursorul `tvd`.
  Fisier ASCII (fara diacritice), editat direct cu Edit tool — fara riscul de corupere cp1252.

- **`COMUN\clase\omodificari.vc2`** (clasa `frm_modific2024`) — **text si binar SINCRONIZATE**,
  ambele includ inca **cod de diagnostic care trebuie scos**:
  - PAGE3 nou pe `pgfArticole` (`PageCount=3`, `PAGE3.Caption="Articole factura"`) — linia cu
    `PageCount = 3, ;` in blocul `ADD OBJECT 'pgfArticole'`.
  - Grid nou `pgfArticole.PAGE3.grdArticoleFactura` (13 coloane, `RecordSource="tvd"`,
    `ReadOnly=.T.` la nivel de grid si pe fiecare `Text1`), plus intrarile `OBJECTDATA`
    corespunzatoare (cautabile dupa `grdArticoleFactura`).
  - Proprietati noi pe clasa: `lAreArticoleVanzari`, `nIdVanzare`, `nTipVanzare` (in blocul
    `*<PropValue>`, cautabile dupa `lareaarticolevanzari`/`nidvanzare`/`ntipvanzare`).
  - `Load()`: placeholder `CREATE CURSOR tvd (...)` daca nu e deja deschis — **necesar**, altfel
    grid-ul incearca `USE tvd` la constructie si pica pe dialog nativ "Open" (vezi sectiunea 4).
  - `Show()`: bloc nou (cautabil dupa `This.lAreArticoleVanzari`) care apeleaza
    `IncarcaVanzareNota`/`IncarcaArticoleFactura` si comuta `pgfArticole.PageCount` intre 2 si 3.
  - **DE SCOS inainte de livrare**: 5 linii `STRTOFILE(...'diag_class.txt'...)` inserate ca
    checkpoint-uri de depanare in `Init()` (3 linii: inceput, dupa `DoDefault()`, sfarsit) si
    `Load()` (2 linii: inceput, sfarsit) — cautabile dupa `diag_class`. Nu au efect functional
    (doar scriu intr-un fisier de log), dar nu trebuie sa ramana in cod livrat.
  - **Fidelity check txt2vcx: OK** la ultimul write-back (cel CU liniile de diagnostic inca in el).
    `.vcx`/`.vct` au mtime 12:10, exact dupa acel write-back — deci **binarul reflecta exact
    `.vc2`-ul curent**, inclusiv diagnosticul.

### Backup-uri pe disc (`COMUN\clase\`)

| Fisier | Continut |
|---|---|
| `omodificari.vc2.pre_s4runda1.bak` | Originalul, dinaintea oricarei modificari S4 |
| `omodificari.vc2.pre_diag.bak` | Versiunea mea **curata** (fara cele 5 linii de diagnostic) — **asta e sursa de folosit pentru versiunea finala** |
| `omodificari.vc2.mine_s4_full.bak` | Identic cu `pre_diag.bak` (copie facuta in timpul unui test de izolare) |
| `omodificari.vcx.mine_s4.bak` / `omodificari.vct.mine_s4.bak` | **Binarul** corespunzator lui `pre_diag.bak`, copiat direct (fara compilare) — restaurare instantanee |

**Pasul urmator recomandat**: `Copy-Item omodificari.vc2.pre_diag.bak -> omodificari.vc2`,
`Copy-Item omodificari.vcx.mine_s4.bak -> omodificari.vcx` (+ `.vct`) — restaurare **instantanee**
(fara `txt2vcx`) la versiunea curata cu PAGE3 functional, fara schela de diagnostic. Verifica dupa
aceea cu un `diff` ca `omodificari.vc2` chiar nu mai contine `diag_class`.

## 2. Ce mai ramane din runda 1

Din sectiunea E / runda 1 a planului (A.2 PageCount + A.3 detectie + B.1 incarcare + B.2 marcaje):

- **A.2 (PageCount)** — FACUT, testat static (fidelity OK), **netestat live pe formular** (vezi
  sectiunea 3 — blocaj de mediu, nu s-a ajuns sa vad `PageCount` pe formularul instantiat real).
- **A.3 (detectie)** — FACUT, testat **direct** (fara UI) cu rezultate PASS pe date reale (sectiunea
  3). Deviaza de la recomandarea planului (cauta si de ce, sectiunea 4).
- **B.1 (incarcare cursoare)** — FACUT, testat direct, PASS.
- **B.2 (marcaje stare linii)** — **NU e in scope runda 1** (grid-ul e strict readonly, fara
  editare — marcajele `_modificat`/`sters`/`id_vanzare_det=0` sunt pentru runda 2). Nu e inceput.

**Ce lipseste efectiv**: verificarea end-to-end ca, pe formularul REAL (`Createobject('frm_modific2024')`
+ `.Show()`), `PageCount` chiar ajunge 3 pe o factura si 2 pe o nota fara `VANZARI` — blocata de
problema de mediu din sectiunea 3. Codul e scris si compilat curat; ramane doar confirmarea live.

## 3. Ce am testat, cu ce rezultat

Suita: `COMUN\utile\Teste\editare_factura\test_page3_articole.prg` (headless, `vfp9.exe -A -T`,
conexiune reala `MARIUSM_AUTO`). Log: `test_page3_articole_log.txt` in acelasi folder.

**PASS, pe date reale, testat direct (apel functie, fara formular)**:
- `cod=1140888` → `IncarcaVanzareNota` gaseste `id_vanzare=1050`, `tip=1`; `IncarcaArticoleFactura`
  incarca 4 linii — coincide exact cu baza de regresie din `progres.md` (`TOTAL_CU_TVA=1924.59`).
- `cod=1140885` → gaseste `id_vanzare=1047`, `tip=-12` (nu e factura, e alt tip de document) —
  confirma ca detectia functioneaza pe **orice** tip din `VANZARI`, nu doar facturi (decizia 19).
- `cod=1125486` (an=2008, luna=2, notă contabila fara nicio legatura cu `VANZARI`) → 0 randuri
  gasite — cazul negativ cerut de criteriul de "gata" al rundei.
- **Coliziune pe `cod=1139934`** (patru randuri active in `VANZARI`, acelasi cod): filtrul compus
  (cod+nract+serie_act+data_act) gaseste EXACT randul cerut (`nract=375/SSS` → `id_vanzare=882`) si
  NU gaseste nimic pentru un `nract` fara corespondent (`nract=13`) — vezi sectiunea 4, e important.

**NETESTAT live (formular real)**: `verifica_pagecount_form` (in acelasi fisier de test) instantiaza
`frm_modific2024` exact ca `do_editare_factura` (`Createobject`+`Show`) si verifica `PageCount` —
**se blocheaza intr-un dialog nativ VFP "View Parameter"** in timpul `Createobject`, inainte sa
apuce sa ruleze vreo linie din `Show()`. Vezi sectiunea 4 pentru diagnosticul facut si o pista noua,
neexplorata inca, primita de la team-lead.

**`test_baseline_isolation.prg`** (in acelasi folder) — **fisier temporar de diagnostic, se poate
sterge** dupa ce cineva confirma diagnosticul de mai jos independent; nu face parte din suita
finala (antetul lui o spune explicit). L-am folosit ca sa demonstrez ca **binarul ORIGINAL (dinainte
de S4) NU are acest blocaj** in acelasi mediu de test (`PageCount=2`, `done`, fara dialog) — deci
problema e din diff-ul meu, nu un gol preexistent de mediu.

## 4. Descoperiri care nu trebuie pierdute

### `VANZARI.COD` NU e unic — dovedit pe date, nu presupus

Contrar recomandarii A.3 din plan ("`SELECT ... FROM vanzari WHERE cod = tact.cod`"), am verificat
direct pe `MARIUSM_AUTO`:
- Indexul `IDX_VANZARI_04` e pe `(STERS, COD)` si e **NONUNIQUE** — schema insasi nu garanteaza
  unicitate.
- `cod=1139934` are **4 randuri active** (`STERS=0`) in `VANZARI`, cu `TIP`/`NUMAR_ACT` diferite
  (375/SSS, 24/PF, 25/PF, 26/PF). `cod=1139555` are 2 randuri cu `TIP` diferit (43 si 1).
- Filtrarea suplimentara pe `NUMAR_ACT`+`SERIE_ACT`+`DATA_ACT` (toate disponibile pe cursorul `tact`
  ca `nract`/`serie_act`/`dataact`, din `vact_tot`) rezolva ambiguitatea: `(COD, NUMAR_ACT,
  SERIE_ACT, DATA_ACT)` verificat **fara nicio dublura** pe toata tabela `VANZARI`.
- `ID_FACT` (alternativa mentionata in `progres.md` — "toate legaturile trec prin ID_FACT sau
  ID_VANZARE, niciodata prin cod") **nu e utilizabil ca filtru unic aici**: e `NULL` pe o fractie
  mare de randuri chiar si pentru facturi normale (`tip=1`: 58 din 183 `NULL`; `tip=51`: 58 din 74
  `NULL`), deci n-ar gasi avizele/tipurile fara facturare clasica — ar incalca decizia 19.

**Concluzie aplicata in cod**: `IncarcaVanzareNota` filtreaza pe cele 4 coloane compuse, nu doar pe
`cod`. Aceasta e o **corectie de fond fata de A.3 din plan**, nu o improvizatie — sectiunea C.1 din
`plan_06_s4_proiectare.md` ar trebui sa mentioneze asta daca cineva o rescrie.

### Blocaj "View Parameter" la `Createobject('frm_modific2024')` — cauza NECONFIRMATA

Simptom: procesul `vfp9.exe` ramane blocat (CPU~0, Responding=True) intr-un dialog nativ **"View
Parameter"** exact in timpul liniei `Createobject([frm_modific2024], lnIdSet)`, inainte sa ajunga
la orice linie din `Show()` — confirmat cu checkpoint-uri `STRTOFILE` in `Init()`/`Load()` (niciunul
nu s-a scris, deci blocajul e chiar mai devreme decat `Load()`, sau checkpoint-urile nu s-au atins
din alt motiv neexplicat).

**Exclus cu dovezi** (nu pierde timp re-verificand):
- **Nu e cursorul `tvd` lipsa** — am incercat atat placeholder in `Load()`, cat si pre-creare in
  scriptul de test inainte de `Createobject`; blocajul a persistat identic.
- **Nu e un gol de mediu preexistent** — binarul ORIGINAL (`omodificari.vcx.mine_s4.bak` restaurat
  temporar) ruleaza curat in ACELASI mediu de test (`test_baseline_isolation.prg`, `PageCount=2`,
  fara dialog). Deci e ceva din diff-ul meu.
- **Un blocaj anterior, diferit** (`File 'crsjtvatemp.dbf' does not exist`, dialog "Open") era
  intr-adevar preexistent — cerut de `Column63` din `grdRulaje` (PAGE1, cod netusat de mine),
  rezolvat in scriptul de test cu `update_jtva_coloane("", "crsJtvaTemp", 0)` inainte de
  `Createobject` (nu in clasa — e o lipsa de mediu de test, nu de productie: in productie,
  `crsJtvaTemp` e populat pe alte cai inainte sa ajunga un utilizator la acest formular).
- Am citit `_pageframe.Init()` (`_baza.vc2:514-523`, itereaza `For i = 1 To PageCount` si cheama
  `tradu(.Caption)`) ca prim suspect — **`tradu()` (`oproceduri_comune.prg:1746`) e confirmat
  inofensiv** (doar `STRTRAN` pe diacritice, fara Oracle/View). Nu e cauza, dar ramane singurul cod
  DEPENDENT de `PageCount` gasit prin cautare in `_baza.vc2`/`_frm_base.vc2`/`_grd_base.vc2`.
- Am cautat "CREATE SQL VIEW" / `USE ... VIA` in toata ierarhia de clase (`omodificari`, `_baza`,
  `_frm_base`, `_grd_base`, `gridextras`) — **zero rezultate**. Niciun view local gasit static.

**Pista noua, neexplorata** (primita de la team-lead, nu verificata de mine inca): dialogul "View
Parameter" apare tipic cand o variabila referita prin `?variabila` (SQL passthrough) sau intr-un
view parametrizat e declarata `LOCAL` in loc de `PRIVATE` intr-un harness de test — `LOCAL` nu e
vizibil in rutinele apelate. Exemplu citat: `do_editare_factura` declara
`Private pnAn, pnLuna, lnCod, lnIdFact, lnIdVanzare` (`ofacturare_comun.vc2:3742`). **Nu am apucat
sa verific** daca `test_page3_articole.prg` foloseste `LOCAL` unde codul original ar cere `PRIVATE`
undeva in lantul `IncarcaCursoareModificareNota`/`Createobject` — e primul lucru de incercat inainte
de a relua sapatul cu `EnumWindows`/`PrintWindow` (costisitor, ~15 cicluri de test in aceasta
sesiune doar pentru asta).

## 5. Capcane de mediu platite in aceasta sesiune

- **Sterge intotdeauna `.fxp`-ul vechi inainte de fiecare rulare de test** — m-a pacalit o data:
  am editat `.prg`-ul dar am uitat sa sterg `.fxp`, iar VFP a rulat tacut codul VECHI compilat,
  dand rezultate inconsistente intre rulari identice in aparenta. Simptom: log-ul arata alt
  comportament decat sursa curenta ar trebui sa produca.
- **FoxBin2Prg NU pastreaza ordinea textuala la scriere-citire (roundtrip)** pentru ADD OBJECT
  multiple si proprietati custom — le REGENEREAZA in ordine proprie (alfabetica pentru
  coloane/obiecte fii, alta regula neclara pentru proprietati custom simple — `nidvanzare` a iesit
  INAINTEA lui `nid_set`, desi `_` < `v` in ASCII). Fidelity-check-ul compara text-sursa cu
  text-regenerat, deci **orice ordine "naturala" (alfabetica presupusa de mine) poate pica fidelity**.
  Solutie aplicata: dupa primul fidelity FAIL, am adoptat ca sursa noua textul regenerat din
  `<staging>\verify\*.vc2` (e deja in forma canonica), nu am incercat sa ghicesc ordinea corecta.
  Confirma exact indicatia din `flux-editare-vfp-text.md`.
- **`InputMask` cu literal (nu `get_mask(...)`)** trebuie **ghilimeluit** (`"9.99"`), nu bar (`9.99`)
  — altfel VFP il interpreteaza numeric, nu ca string de format. Prins abia la inspectia manuala a
  textului regenerat, fidelity-check-ul NU l-a semnalat separat (a picat impreuna cu reordonarea).
- **Grid nou cu `RecordSource` pe un cursor care nu exista inca la constructia formularului** →
  VFP incearca `USE <recordsource>` ca fisier fizic si arata dialogul nativ "Open" daca nu-l
  gaseste pe disc — exact acelasi tipar deja documentat in clasa pentru `saft_taxtable`/
  `saft_mecanisme_plati` (`Load()`, verificat `If !Used(...)` inainte de orice altceva). Solutia
  e aceeasi: placeholder gol creat in `Load()`, INAINTE ca framework-ul sa construiasca grid-urile.
- **Query-uri Oracle multiple rulate manual (sqlplus) au fost esentiale** pentru validarea empirica
  a filtrului compus pe `VANZARI` — nu s-ar fi descoperit coliziunea pe `cod` doar din cod static.

## 6. Ce recomand pentru urmatorul agent

1. Restaureaza versiunea curata (sectiunea 1, pasul recomandat) — 2 copieri de fisier, fara
   compilare, verifica cu `grep diag_class` ca a disparut.
2. Incearca pista `LOCAL`/`PRIVATE` din sectiunea 4 pe `test_page3_articole.prg` inainte de orice
   alta depanare GUI.
3. Daca se rezolva: reruleaza `test_page3_articole.prg` complet, confirma PASS pe toate cazurile
   (inclusiv `verifica_pagecount_form`), sterge `test_baseline_isolation.prg` + `.fxp` + log-ul lui,
   scrie diff-ul (diff aplicat (sters), `git diff --no-index <bak> <editat>`) si
   raportul (`docs\cercetare\rec_s4_runda1.md`) cerute initial de team-lead.
4. Daca team-lead sau alt agent scrie capcana "View Parameter / LOCAL vs PRIVATE" in
   `testare-ui-vfp.md`, nu o duplica — team-lead a intrebat explicit cine o scrie.