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

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.
Rescrie cele 6 trimiteri de mai sus in acord cu decizia.
Sterge docs\progres.md (e sub SVN — svn delete, nu doar rm).
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.
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.

3.9 KiB Raw Blame History