diff --git a/docs/handoff_etapa2_convertor.md b/docs/handoff_etapa2_convertor.md
index b53a2b8..a5b1e4f 100644
--- a/docs/handoff_etapa2_convertor.md
+++ b/docs/handoff_etapa2_convertor.md
@@ -27,7 +27,8 @@ Actualizat 21.09.2026, la finalul executiei. Versiunea anterioara a acestui fisi
 | `date/`, `iesiri/`, `sablon/` | intrari de la client / xlsx-uri generate / sablonul ROA |
 
 Commit-uri: `15bb26a` (plan + etalon), `f23b336` (contract), `ba4cbbf` (citire-xlsx + mapare),
-`6b37d37` (citire-fdb), `82511c8` (integrare), plus commit-ul final de regresie.
+`6b37d37` (citire-fdb), `82511c8` (integrare), `0d0b3e2` (regresie - poarta finala),
+`9a83e36` (mutarea in `date/`, `iesiri/`, `sablon/`).
 
 ## 2. Portile care au trecut, si ce dovedesc
 
@@ -70,15 +71,38 @@ raportasera "GATA" corect dupa criteriile lor.
 **nu** listeaza `5121`, `5124`, `5311`, pe care le trateaza. Confirma decizia din plan: Oracle e
 consultativ. Detaliile in `docs/decizii_import.md`.
 
-## 6. Ce ramane pentru mai tarziu
+## 6. Ce urmeaza - de aici incepe sesiunea urmatoare
 
-- o baza `.FDB` **reala** + exportul ei de balanta, ca sa se reruleze poarta pe date cu analitice
-  si cu volum;
-- portul **4296** al acestui proiect nu e inca trecut in tabelul din
-  `D:\ROA\ROACONT\COMUN\docs\opencode_agenti_orchestrare.md` (COMUN cere aprobare inainte de commit);
-- `docs/plan_solduri2roa.md` descrie inca etapele 1-6; nu a fost rescris dupa etapa 2.
+In ordinea in care le-as face:
 
-## 7. Starea pe disc
+1. **Proba pe un client real** - singurul lucru care mai conteaza acum. Cere unui client cu SAGA
+   noua copia bazei (`docs/procedura_copie_fdb_client.md`) **si** exportul lui de balanta pe
+   aceeasi luna. Ruleaza poarta cititoarelor pe datele lui: daca cele doua CSV-uri coincid pe o
+   firma cu analitice si cu volum, cititorul FDB inceteaza sa mai fie "verificat partial". Daca
+   nu coincid, diferenta este livrabilul - nu se ajusteaza nimic ca sa treaca.
+2. **Al doilea import real, capat-la-capat**, pe o firma noua: `extrage.py` -> corectii in
+   `corectii_<FIRMA>.xlsx` -> `genereaza.py` -> import in ROACONT. Asta exerseaza pasul de mapare
+   pe date pe care nu le-a vazut nimeni si e primul test adevarat al lui `.TOATE`/`.RESTUL`.
+3. **Pasul 5b (cautarea pe ANAF)** devine inutil pe drumul FDB, unde codul fiscal e real.
+   Verifica pe date reale si, daca se confirma, scoate-l din flux pentru sursa Firebird.
+4. Marunt, cand se nimereste: portul **4296** nu e trecut in tabelul din
+   `D:\ROA\ROACONT\COMUN\docs\opencode_agenti_orchestrare.md` (COMUN cere aprobare
+   inainte de commit).
+
+**Nu incepe** prin a reface cercetarea sau a redeschide deciziile din sectiunea 5 a planului:
+sunt platite si validate. Daca ceva pare gresit, cere dovada, nu reinvestiga.
+
+## 7. Riscuri asumate, nu uitate
+
+- **Firebird prin retea** nu merge cu parola implicita: la un client care nu poate trimite
+  fisierul, cere credentiale. Nu e rezolvat, e ocolit prin copia locala.
+- **Un singur analitic cu sold pe latura opusa** (`5121.01` la MASTER, -20.80 D) trece azi
+  prin regula de la `decizii_import.md` pct. 15. E validat in productie pe un caz; al doilea
+  client il va pune la incercare.
+- `docs/verificare_*.md` din git sunt cele ale importurilor validate; rularile noi scriu in
+  `iesiri/` si nu le ating.
+
+## 8. Starea pe disc
 
 Totul comis si impins pe `origin/main`. Nimic periculos: niciun proces ramas viu (serverul opencode
 de pe 4296 a fost oprit), `D:\ROA\ROACONT`, `D:\SAGA250909` si `saga2roa*` neatinse, baza firmei de
@@ -89,7 +113,7 @@ Fisierele `iesiri/init_FUNDATIA_2025_12.xlsx` si `iesiri/init_MASTER_2025_12.xls
 disc dar nu in git; sunt necesare doar daca vrei sa **regenerezi** etalonul
 (`py tests\anonimizeaza_etalon.py`, care le citeste din `iesiri/`).
 
-## 8. Cum rulezi acum unealta
+## 9. Cum rulezi acum unealta
 
 ```
 py extrage.py --fisier "date\IBB 31.12.2025.pdf" --firma FUNDATIA --an 2025 --luna 12
@@ -99,9 +123,10 @@ py genereaza.py --firma FUNDATIA --an 2025 --luna 12
 Implicit `extrage.py` scrie in `date/`, iar `genereaza.py` citeste din `date/` si scrie in
 `iesiri/` (`--dir` / `--dir-iesire` le schimba). Sablonul e in `sablon/`.
 
-**Capcana de nume**: balanta firmei MASTER se numeste `balanta_MASTERJOB.csv`, nu
-`balanta_MASTER.csv`, deci pentru ea trebuie dat explicit
-`--balanta date\balanta_MASTERJOB.csv`. Eroarea e clara, nu tacuta.
+Numele intermediarului urmeaza intotdeauna `--firma`: `date/balanta_<FIRMA>.csv`. Firma se
+cheama in acte MASTERJOB, dar peste tot in unealta si in ROA e `MASTER`, deci balanta ei e
+`date/balanta_MASTER.csv` (redenumita 21.09.2026; inainte era `balanta_MASTERJOB.csv` si
+cerea `--balanta` explicit).
 
 Sursa se deduce din extensie (`.pdf`, `.xls`/`.xlsx`, `.fdb`); o extensie necunoscuta da eroare.
 Pentru Firebird, da calea catre o **copie** a bazei, niciodata baza vie a clientului.
diff --git a/docs/plan_solduri2roa.md b/docs/plan_solduri2roa.md
index 0592f7f..2b9216e 100644
--- a/docs/plan_solduri2roa.md
+++ b/docs/plan_solduri2roa.md
@@ -63,8 +63,15 @@ Pasul e obligatoriu, nu optional: partenerii intra in xlsx cu cod fiscal provizo
 `git init`, commit, push pe `gitea.romfast.ro:romfast/solduri2roa.git` (push-to-create).
 Se comit: scripturile, `docs\`, CSV-urile si xlsx-urile generate. PDF-urile: da (sunt sursa, 30 KB).
 
-## Pasul 2 (dupa import) - convertorul reutilizabil
-Generalizarea etapelor 1 + 4 intr-un singur script cu parametri (firma, an, luna, sursa PDF sau
-xlsx SAGA), cu regulile din `decizii_import.md` scoase intr-un fisier de configurare
-(conturi cu parteneri, maparea analiticelor). Nu se porneste inainte ca cele doua importuri sa
-fie validate in ROA.
+## Pasul 2 (dupa import) - convertorul reutilizabil: **TERMINAT 21.09.2026**
+
+Planul detaliat: `plan_etapa2_convertor.md`. Starea de final si ce nu e dovedit:
+`handoff_etapa2_convertor.md` - **acela e documentul de citit, nu acesta.**
+
+Livrat: `extrage.py` / `genereaza.py` cu parametri, trei cititoare (PDF, foaie SAGA, Firebird),
+pasul de mapare cu corectii, `config/conturi_parteneri.csv`, 33 de teste.
+Poarta finala: fluxul nou, pornit de la PDF-urile originale, reproduce identic xlsx-urile
+importate in ROACONT.
+
+Etapele 1-6 de mai sus raman ca istoric al primului import; caile s-au schimbat de atunci
+(`date/`, `iesiri/`, `sablon/`).
diff --git a/tests/test_regresie.py b/tests/test_regresie.py
index e08a8f9..adc912d 100644
--- a/tests/test_regresie.py
+++ b/tests/test_regresie.py
@@ -32,7 +32,7 @@ GOLDEN = TESTS / "golden"
 
 FIRME = [
     ("FUNDATIA", "balanta_FUNDATIA.csv", "golden_FUNDATIA_2025_12.xlsx"),
-    ("MASTER", "balanta_MASTERJOB.csv", "golden_MASTER_2025_12.xlsx"),
+    ("MASTER", "balanta_MASTER.csv", "golden_MASTER_2025_12.xlsx"),
 ]
 
 MAX_DIFERENTE_RAPORTATE = 20
diff --git a/tests/test_regresie_capat_la_capat.py b/tests/test_regresie_capat_la_capat.py
index 5056333..bb3fae1 100644
--- a/tests/test_regresie_capat_la_capat.py
+++ b/tests/test_regresie_capat_la_capat.py
@@ -12,7 +12,7 @@ reguli si ACEIASI tabela ca tests/anonimizeaza_etalon.py si se compara cu
 tests/golden/ pe VALORI DE CELULA, nu pe hash de fisier.
 
 Asocierea PDF -> firma nu se presupune: fiecare balanta extrasa se compara cu
-balanta de referinta din date/ (balanta_FUNDATIA.csv / balanta_MASTERJOB.csv),
+balanta de referinta din date/ (balanta_FUNDATIA.csv / balanta_MASTER.csv),
 care e cea folosita la constructia etalonului.
 
 Daca iesirea difera de etalon, etalonul are dreptate: se raporteaza, nu se ajusteaza.
@@ -51,7 +51,7 @@ MAX_DIFERENTE_RAPORTATE = 20
 FIRME = [
     ("FUNDATIA", "IBB 31.12.2025.pdf", "balanta_FUNDATIA.csv",
      "golden_FUNDATIA_2025_12.xlsx"),
-    ("MASTER", "MJC 31.12.2025.pdf", "balanta_MASTERJOB.csv",
+    ("MASTER", "MJC 31.12.2025.pdf", "balanta_MASTER.csv",
      "golden_MASTER_2025_12.xlsx"),
 ]