# Handoff — stergerea lui progres.md (ultimul pas al curateniei)

Scris 20.08.2026, dupa r18027. Sesiunea principala a trecut de pragul de context (254k).
**Numai stare, fara analize noi.**

## Nimic nu e intr-o stare periculoasa

- **Totul e comis si pushed.** SVN `r18026` (lucrarea) si `r18027` (curatenia). Git: proiect
  `3ddcbc0`, COMUN `58d4c4a`, ambele la zi cu origin. `git status` curat in ambele repo-uri.
- Niciun fisier editat fara write-back. `vfp9.exe` nu ruleaza. Nicio tranzactie deschisa.
- `roafacturare.PJT`/`.PJX`/`.exe` raman modificate din sesiunea de VFP a lui Marius: **nu se comit**.

## Ce a cerut Marius, si unde s-a oprit

> "cred ca poti sa stergi si progres.md daca nu mai indica catre modificari active"

**Premisa e corecta**, verificat: `progres.md` nu mai descrie lucrari active. #6, #7 si #8 sunt
inchise; starea lui #13 sta in `handoff_13_formular_unificat.md`, care **nu** il refera
(0 trimiteri; la fel `plan_13` si `plan_10`).

**Ce lipseste ca sa se poata sterge** — sase trimiteri vii de rescris:

| fisier | trimiteri | ce spune |
|---|---|---|
| `docs\plan_index.md` | **3** | "Planul a fost sters la curatenie; istoricul e in `progres.md`" — randurile #8, #6, #7 |
| `docs\plan_11_integrare_politici_preturi.md` | 1 | |
| `docs\plan_12_nomenclator_ca_lista_preturi.md` | 1 | |
| **`COMUN\docs\reguli_lucru.md`** | 1 | **cross-proiect** — fisier partajat de toata suita ROA |

Ultima e motivul pentru care lucrarea nu e banala: `COMUN` e dublu-versionat (SVN + git propriu,
`gitea.romfast.ro:romfast/comun.git`) si orice modificare acolo atinge toate produsele ROA.

## Ce are de facut sesiunea urmatoare

1. Decide cu Marius **unde se muta rolul de arhiva**: fie se renunta la promisiune (istoricul
   ramane doar in git, `3ddcbc0` si mai vechi), fie trimiterile arata catre revizia SVN/commit-ul
   git in loc de fisier.
2. Rescrie cele 6 trimiteri de mai sus in acord cu decizia.
3. Sterge `docs\progres.md` (e sub SVN — `svn delete`, nu doar `rm`).
4. Commit in **doua repo-uri**: SVN pe `docs\` + `COMUN\docs\reguli_lucru.md`, apoi `roa_sync.bat`.
   Verifica separat repo-ul git al lui `COMUN`.
5. Sterge si acest handoff, odata ce pasul e incheiat.

## Starea curenta a documentatiei

`docs\` are **10 fisiere** + `docs\cercetare\` cu **63**:

- planurile deschise/amanate: `plan_13` (**urmatorul la rand**, locul 1 in index), `plan_12`,
  `plan_11`, `plan_10`, `plan_index.md`;
- materialul lui #13: `handoff_13_formular_unificat.md`, `mockup_13_formular_unificat.html`,
  `S1_inventar_campuri_formular_unificat.md`;
- `conventii_mediu_oracle.md` (netrackat in SVN, doar git);
- `progres.md` — subiectul acestui handoff.

**Capcana de nume, deja platita**: `cercetare\s8_incarcare_document.md`, `s8b_rutarea_scrierii.md`
si `audit_vanzari_creare_modificare_stergere.md` NU tin de planul #8 — sunt story-uri ale lui
**#13**. Criteriul de stergere in `cercetare\` a fost referinta, nu numele: **#13 se sprijina pe
folder cu 86 de trimiteri**, deci nu se poate sterge in bloc.

## Reziduu acceptat, nu defect

`progres.md` pastreaza 39 de trimiteri catre fisiere sterse, plus 5 mentiuni in proza in
`plan_13`, `cercetare\handoff_s4_runda1.md`, `cercetare\rec_s4_runda1.md` si
`cercetare\rec_cale_vanzari_detalii.md`. Sunt istorice, se rezolva din git — aceeasi situatie ca la
curatenia planului #8. Daca `progres.md` dispare, dispar si cele 39.

## Defect deschis, raportat si nereparat (decizia lui Marius)

Sincronizarea articole-rulaje nu recalculeaza `valoarev`/`valtvav` pe randul `trul`; ele ajung
invechite in Oracle (`RUL`). `VALOAREVCTVA` nu e coloana in `RUL` — ramane invechit doar pe ecran,
pana la reincarcarea notei. Back-fill-ul de la reincarcare are garda `WHERE EMPTY(NVL(...,0))`,
deci prinde doar zerourile. Lantul complet, cu `fisier:linie`, era in `docs\raport_r7_sincronizare.md`,
sters la curatenie — se recupereaza din git (`5b52cb3`), iar rezumatul a ramas in `progres.md`.