# AutoPass — Roadmap & Proces de Dezvoltare > **Sursa unica de progres + procesul de lucru.** O sesiune noua are nevoie doar de promptul: > *"Citeste docs/ROADMAP.md si continua roadmap-ul [optional: livrabila X.Y]."* > Sesiunea isi detecteaza singura faza (§5.7), planifica SAU executa, verifica si inchide — > cu doua porti umane: aprobarea PRD-ului si confirmarea commit-ului. > > Contractul RAR (sursa de adevar de contract) = `docs/api-rar-contract.md`. Acolo unde un plan > difera de contract, **contractul are dreptate**. > > Status fara emoji (preferinta proiect): **TODO** neinceput · **WIP** in lucru · **DONE** gata · > **BLOCAT** blocat de o dependenta · **AMANAT** deferat/taiat cu motiv. --- ## 1. Context Gateway central care declara prestatiile de service-auto la **RAR AUTOPASS** (Legea 142/2023, OM 210/2024), portat din clasa Visual FoxPro `RarAutoPass` (ROAAUTO). Stack: **Python/FastAPI + SQLite (WAL) + httpx + Jinja2/HTMX**. Un container (API) + un proces separat (worker). Doua canale de intrare, ambele **LIVE pe endpoint-ul de test RAR**: - **Treapta 1** — canal API (`POST /v1/prezentari`) pentru ROAAUTO / soft propriu. - **Treapta 2** — import xlsx/csv + mapare coloane + UI web (HTMX) pentru service-uri non-ROA. --- ## 2. Arhitectura (rezumat) ``` Canal API (ROAAUTO) ─┐ Upload web (xlsx/csv) ─┴─▶ Gateway FastAPI ─▶ validare → mapare op→cod → enqueue (PII criptat) │ ▼ WORKER (proces separat): claim atomic → login RAR → postPrezentare → retry │ Dashboard (Jinja2+HTMX) ◀───────┴── monitorizare live RAR + coada + editor mapari + audit CSV ``` Reguli de contract (detalii in `docs/api-rar-contract.md`): `FINALIZATA` e terminal la RAR (fara anulare/corectie prin API); idempotency = hash de continut server-side; JWT TTL = 30h. --- ## 3. Stadiu Implementare (dashboard) > **Singurul loc din document care se modifica pe parcurs.** Detaliile NU intra aici — stau in > PRD-uri (`docs/prd/prd-X.Y-*.md`), linkate in coloana Detalii. La fiecare livrabila terminata: > schimba statusul + data + linkul PRD si actualizeaza "Ultima actualizare". **Ultima actualizare**: 2026-06-22 — 5.2 LIVRAT (Endpoint dry-run `POST /v1/prezentari/valideaza`: valideaza payload + mapare si intoarce verdictul real — `status_estimat` queued/needs_data/needs_mapping + erori `[{field,message}]` + coduri nemapate + prestatii rezolvate — FARA enqueue, FARA creds, zero scriere DB). 1 story TDD. Cheia de design: helper pur partajat `classify_prezentare` folosit de AMBELE rute, ca dry-run-ul sa nu poata diverge de trimiterea reala (invariant de corectitudine); `create_prezentari` refactorizat pe el cu comportament identic. Scope minim per decizie user: doar validare+mapare (fara idempotency/duplicat, `idempotency.py` neatins), hub `/integrare` amanat ca follow-up (descoperibilitate). VERIFY context curat PASS (577 teste; E2E API cu cele 3 verdicte + COUNT(*)=0 dupa dry-run + fara leak creds in raspuns; regresia de aur verde; live RAR `FINALIZATA` neprobat — lipsa creds key, endpoint read-only nu atinge worker/coada/schema). `/code-review` high: 0 findings (refactor faithful, mutable-default Pydantic-safe, import local necesar anti-circular). PRD: [prd-5.2](prd/prd-5.2-dryrun-valideaza.md). | ISTORIC: 5.1 LIVRAT (Hub de integrare `/integrare`: exemple cod multi-limbaj + retetar VFP cu 2 dialecte + `GET /v1/ping` readiness + export Postman/OpenAPI + "Testeaza conexiunea"). 4 stories in 2 valuri (Val 1 = US-001/US-002/US-004 paralel pe fisiere disjuncte via Agent team; Val 2 = US-003 UI). Atentie operationala: US-003 a rulat intr-un worktree branched din ultimul commit (FARA modificarile necomise ale US-004 din working-tree) si la "copiere manuala" a SUPRASCRIS `routes.py`, stergand ruta `POST /integrare/test-cheie` (8 teste 404) — reparat prin re-aplicarea rutei de catre autorul US-004 pe `routes.py` curent. Lectie: stories care ating acelasi fisier in valuri diferite + worktree = clobber daca worktree-ul nu vede working-tree-ul; foloseste fisiere disjuncte SAU merge atent de catre lead. VERIFY context curat PASS (568 teste) + E2E browser Playwright (deep-link server-side, IA pe 2 niveluri, VFP cu 3 niveluri de tab comuta corect, copy, htmx test-cheie → fragment eroare, 0 erori consola) + enqueue live (`POST /v1/prezentari` → queued); live RAR `FINALIZATA` NEPROBAT in sesiune (lipsa `AUTOPASS_CREDS_KEY`/creds RAR test) — risc minim, backend trimitere NEATINS. `/code-review` high a prins 4 bug-uri reale (toate in suprafata noua, reparate + lock-uite cu teste): snippet C# JSON multi-linie nevalid (CS1010), snippet VFP `json.dumps(indent=0)` inca cu newline-uri → string literal rupt in ambele dialecte, snippet Node `node:buffer` nu exporta FormData → TypeError, script `_integrare.html` ne-scoped acumuland event-listeneri pe tab-bar-ul principal la fiecare swap htmx (scoped pe `#integrare-section`). Notat ca cleanup viitor (nereparat): `_render_integrare` dubleaza SQL `are_creds`/`are_cheie`, `ping` cu 2 conexiuni DB + `account_for_key` de 2 ori, `_campuri_obligatorii` necache-uit, panouri limbaj copy-paste (candidat macro Jinja2). Backend trimitere (worker/masina stari/idempotenta/mapping) si schema NEATINSE. PRD: [prd-5.1](prd/prd-5.1-hub-integrare.md). | ISTORIC: 3.6 INCHIS (editare celule in preview + Acasa unificata). CLOSE: `/code-review` high a prins 1 bug real (decriptare `override_json` neprotejata de try/except in ambele cai de preview — 500 pe tot batch-ul la rotatie cheie Fernet vs. `raw_json` care degrada gratios), reparat in `import_router.preview_import` + `routes._web_compute_preview`; duplicarea `_override_of`/canonicalize notata ca cleanup viitor. 523 teste pass. 7 stories in 3 valuri, executate de 2 echipe in paralel (TeamCreate) pe fisiere disjuncte (core: routes/import/templates; mapari: `_mapari.html`) + US-007 secvential. Livrate: tab "Trimiteri" eliminat→sectiune "Trimiterile tale" sub upload pe Acasa (US-003); upload bara slim accentuata cu hero la first-run (US-004); editare de celule in preview prin `import_rows.override_json` (Approach B, Fernet, patch canonic aplicat ULTIMUL in `_resolve_row_for_preview`+`commit_import` — completeaza inclusiv coloane ABSENTE din fisier), mutatie pura cu status rederivat (US-001); buton Editeaza pe rand cu swap pe `
`, empty-state CTA, export `.cardlink`, doar tokens. US-004 `POST /integrare/test-cheie` (`account_for_key` direct, scoped sesiune, no-echo). VERIFY: 568 teste + E2E browser (Playwright: VFP 3 niveluri comuta, htmx test-cheie → fragment eroare, 0 erori consola) + enqueue live; live RAR neprobat (lipsa creds key). `/code-review` high: 4 bug-uri reale reparate (C#/VFP snippet JSON multi-linie nevalid, Node `node:buffer` fara FormData, script ne-scoped acumuland listeneri). Backend trimitere NEATINS. PRD: [prd-5.1](prd/prd-5.1-hub-integrare.md) |
| 5.2 | Endpoint dry-run `POST /v1/prezentari/valideaza` — valideaza payload + mapare, intoarce erorile reale FARA enqueue | DONE | 2026-06-22 | 1 story (US-001), un worker TDD. Helper pur partajat `classify_prezentare` (mapping.py) folosit de AMBELE rute → garanteaza ca dry-run-ul da acelasi verdict ca trimiterea reala (invariant de corectitudine, nu doar DRY); `create_prezentari` refactorizat pe el (comportament identic, test_api.py verde). Ruta read-only: `{results:[{index,valid,status_estimat,erori,nemapate,prestatii_rezolvate}]}`, `rar_credentials` optional+ignorat, zero scriere DB, scope prin `resolve_account_id`. Doar validare+mapare (FARA idempotency/duplicat — decizie user; `idempotency.py` neatins) + hub `/integrare` amanat. VERIFY context curat PASS (577 teste; E2E API: queued/needs_data/needs_mapping + COUNT(*)=0 dupa dry-run, fara leak creds; regresia de aur `POST /v1/prezentari`→queued verde; live RAR neprobat — lipsa `AUTOPASS_CREDS_KEY`/creds test, endpoint read-only nu atinge worker/coada). `/code-review` high: 0 findings. PRD: [prd-5.2](prd/prd-5.2-dryrun-valideaza.md) |
| 5.3 | Light/Dark mode — toggle in header, persistat (cookie/localStorage); CSS deja pe variabile `:root` | TODO | | efort mic, cerut explicit |
| 5.4 | Erori pe 3 niveluri (problema + cauza + fix) pe API si UI | TODO | | DX: fight uncertainty; reduce suportul |
### Etapa 4 — Deprioritizat (post Etapa 5, daca apare nevoia din uz real)
| # | Livrabila | Status | Data | Detalii |
|---|-----------|--------|------|---------|
| 4.1 | Mapare AI / conector MCP (sugestie peste fuzzy) | AMANAT | | deprioritizat 2026-06-22 in favoarea ergonomiei/integrarii (Etapa 5) |
| 4.2 | Editare/anulare prezentari trimise | BLOCAT | | `FINALIZATA` terminal la RAR — fara flux API; corectia = suport RAR |
### Amanat / taiat (cu motiv)
| Livrabila | Status | Motiv |
|-----------|--------|-------|
| Drop-fisier SFTP / email-to-import | AMANAT | Valideaza intai upload-ul manual (wedge-ul real), apoi re-evalueaza |
| Contor volum + prag freemium | AMANAT | Metrici de pret inainte sa existe useri; trivial de adaugat post-validare |
| Billing complet (Stripe etc.) | AMANAT | Dupa validarea pragului de volum |
---
## 4. Open questions / riscuri acceptate
- **Un cont = un agent RAR sau mai multi** — afecteaza maparea creds in UI + filtrarea monitorizarii.
Relevant pentru Etapa 3.
- **Valori reale `sistemReparat`** — azi se trimite `"null"`; ce alte valori accepta RAR ramane de probat.
- **R4 (acceptat constient):** creds RAR durabile-at-rest (Treapta 2) → la scurgerea cheii Fernet toate
parolele sunt decriptabile (vs. doar in-flight pe canalul API). Mitigare: rotatie cheie + redactare loguri.
---
## 5. Proces de implementare
### 5.1 Principii
1. **PLAN separat de EXECUTE/VERIFY, pe sesiuni distincte.** Planificarea consuma mult context
(model puternic) si produce **PRD-ul** ca artefact de predare. Executia reia intr-o **sesiune noua**
bazat doar pe PRD — nu pe transcriptul planificarii. **Starea persista in PRD**, nu in conversatie.
2. **TDD ca contract:** testul scris ÎNAINTE = forma executabila a criteriilor de acceptare. Un worker
cu test rosu clar nu poate declara fals victoria — testul decide.
3. **Story atomic = unitate de paralelizare SI de rollback:** un story = un commit logic = un worker =
un test-suite verde.
4. **VERIFY in context curat:** un subagent dedicat care primeste DOAR PRD-ul + instructiunile §5.6,
NU transcriptul executiei (altfel mosteneste partinirea de confirmare a celui care a implementat).
5. **Single writer:** doar sesiunea lead scrie in PRD, ROADMAP si git. Workerii scriu doar cod si teste.
6. **E2E pe canalul real:** un flux se verifica prin canalul lui (upload web prin browser, API prin
`POST /v1/prezentari`), nu doar prin apel intern. RAR test = endpoint real.
### 5.2 Cele 4 faze (separabile pe sesiuni)
```
SESIUNE A (Opus/Fable) SESIUNE B (lead + agent team Sonnet)
┌─────────────────────┐ ┌──────────────────────────────────────────────────┐
│ FAZA 1: PLAN │ PRD │ FAZA 2: EXECUTE FAZA 3: VERIFY FAZA 4: CLOSE │
│ citeste ROADMAP+cod │ aprobat │ TeamCreate + subagent context /code-review │
│ scrie PRD (stories │ ───────▶ │ workeri Sonnet curat: pytest + writeback dash │
│ atomice + teste) │ (in PRD) │ TDD per story E2E RAR test propune commit │
│ plan-reviews gstack │ │ lead bifeaza PRD raport in PRD │
│ ▼ POARTA UMANA │ │ ▼ POARTA UMANA │
│ aprobare PRD │ │ confirmare commit│
└─────────────────────┘ └──────────────────────────────────────────────────┘
```
PLAN poate rula singur intr-o sesiune (scump, model puternic) si se opreste la poarta de aprobare.
EXECUTE → VERIFY → CLOSE reiau intr-o sesiune noua din PRD-ul aprobat. Pot fi si inlantuite in
aceeasi sesiune daca vrei — starea din PRD le face reluabile oricum.
### 5.3 PRD per livrabila
- **1 PRD per livrabila** din dashboard: `docs/prd/prd-X.Y-.md` (skill `/prd`).
- Prima linie dupa titlu: `**Stare**: draft` (vezi §5.7 pentru tranzitii).
- Contine obligatoriu: obiectiv, **Non-Goals** (anti scope-creep), stories atomice (§5.4),
riscuri, intrebari deschise (rezolvate cu utilizatorul ÎNAINTE de executie), graful de valuri.
- PRD-ul **nu repeta** strategia/contractul — le linkeaza (`docs/api-rar-contract.md`, acest ROADMAP).
- **Review-uri de plan** (aplicate IN PRD inainte de cod): `/plan-ceo-review` (valoare/scope) +
`/plan-eng-review` (fezabilitate/teste) — obligatorii; `/plan-design-review` — doar daca atinge UI.
### 5.4 Story atomic (template)
```markdown
### US-003:
**Ca** **vreau** **pentru ca** .
- **Depinde de**: US-001
- **Fisiere**: `app/.py`, `app/web/templates/.html` (~N fisiere)
- **Test intai (RED)**: `tests/test_.py` — `test_`, `test_`
- **Acceptance criteria**:
- [ ]
- [ ]
- **Verificare E2E**:
```
Testul de atomicitate: (a) poate un Sonnet sa-l termine intr-o singura sesiune, cu teste, fara sa
intrebe nimic? daca nu → sparge-l. (b) lasa sistemul **functional** daca e ultimul story? (c) `Fisiere`
+ `Depinde de` complete (decid ce se paralelizeaza). (d) backend + UI pentru acelasi comportament = **2 stories**.
### 5.5 Executie — agent team (lead orchestreaza, NU scrie cod)
- `TeamCreate` creeaza echipa + lista de task-uri partajata; `Agent` cu `team_name` + `name` +
`model: sonnet` spawneaza **teammates adresabili**. Lead-ul ii coordoneaza prin `SendMessage`
(clarificari/re-directionare la cald, fara re-spawn) si `TaskUpdate` (atribuire/inchidere task).
- **Valuri (waves):** lead-ul grupeaza stories pe graful de dependente. Val 1 = stories fara
`Depinde de` si fara fisiere comune → teammates paraleli. Val 2 = deblocate de Val 1. Etc.
- **Reguli hard:** max 2-3 teammates simultan (server dev + SQLite partajate); **fisiere comune = nu
paralel** (sau `isolation: worktree` + merge de catre lead); teammates **nu** comit, nu scriu in
PRD/ROADMAP, nu pornesc/opresc servere, nu rezolva ambiguitati singuri (escaladeaza la lead).
- **Raport teammate** (prin `SendMessage`): test RED citat → implementare → test GREEN citat →
fisiere atinse → abateri; apoi `TaskUpdate` → `completed`.
- Dupa fiecare val: lead-ul ruleaza regresia (`python3 -m pytest -q`) si bifeaza stories in PRD.
- Livrabile mici pot rula **fara TeamCreate** (un singur worker sau lead direct) — dar PRD-ul,
verificarea in context curat si writeback-ul raman obligatorii.
### 5.6 VERIFY (subagent cu context curat)
Lead-ul spawneaza un subagent dedicat care primeste DOAR PRD-ul + aceste instructiuni, NU transcriptul:
> Esti verificator independent pentru livrabila {X.Y} (PRD: `docs/prd/prd-{X.Y}-.md`).
> Citeste PRD-ul; NU porni de la premisa ca implementarea e corecta.
> 1. Suita: `python3 -m pytest -q` — verde (citeaza output-ul).
> 2. Criteriile de acceptare ale fiecarui story din PRD.
> 3. E2E pe canalul atins: UI web → `./start.sh test both --send`, browser pe `http://localhost:8000/`
> (Playwright MCP sau `/browse`), fluxul din PRD; canal API → `POST /v1/prezentari` pe RAR test.
> 4. **Regresia de aur:** fluxul existent nu are voie sa se strice — `POST /v1/prezentari` (sau
> import → commit) → worker → `FINALIZATA` la RAR test, vizibil in dashboard (`./start.sh test finalizate`).
> 5. Raport PASS/FAIL per criteriu cu dovezi. FAIL-urile NU le repari (`/qa-only`, nu `/qa`) — le documentezi.
Lead-ul scrie raportul in PRD ca `## Raport VERIFY`. Toate PASS → CLOSE. Exista FAIL → inapoi la
EXECUTE (stories de fix), apoi VERIFY din nou cu subagent NOU.
### 5.7 Bootstrap sesiune (detectie faza din starea PRD)
Starea persista in PRD (prima linie dupa titlu), actualizata de lead la fiecare tranzitie:
`**Stare**: draft → aprobat → in-executie → verify-pass → inchis`. Asta face procesul reluabil
din orice sesiune noua — starea e in fisiere, nu in conversatie.
| Stare gasita | Faza de pornire |
|---|---|
| nu exista `docs/prd/prd-{X.Y}-*.md` | PLAN |
| PRD `**Stare**: draft` | PLAN (reia stories/review-uri) |
| PRD `**Stare**: aprobat` / `in-executie`, stories nebifate | EXECUTE |
| toate stories bifate, fara `## Raport VERIFY` cu PASS | VERIFY |
| `## Raport VERIFY` = PASS | CLOSE |
| PRD `**Stare**: inchis` | livrabila gata — alege urmatoarea din dashboard |
La bootstrap: daca utilizatorul a numit `{X.Y}`, aceea e; altfel prima `WIP` din dashboard, apoi
prima `TODO` in ordinea etapelor. **Confirma alegerea cu utilizatorul** — singura intrebare permisa la start.
### 5.8 CLOSE + porti umane
1. `/code-review` pe diff-ul livrabilei. Probleme → fix acum (worker) sau story nou (inapoi in PRD).
2. **Writeback:** in §3 dashboard — status `DONE` + data + link PRD; actualizeaza "Ultima actualizare".
PRD: `**Stare**: inchis`.
3. **POARTA UMANA:** propune commit-ul (mesaj conventional commits, fara emoji; vezi git rules) si
ASTEAPTA confirmarea explicita — niciodata commit automat.
### 5.9 Anti-patterns (opreste-te daca observi)
| Anti-pattern | Corectia |
|---|---|
| Teammate "termina" fara output de test citat | Raportul e invalid — cere dovezi prin `SendMessage` |
| Test scris DUPA implementare ca formalitate | Nu e TDD — testul e contractul; refa bucla |
| Lead-ul scrie cod "ca e mai rapid" | Pierde orchestrarea; spawn teammate chiar si pt un fix mic |
| Stories paralele care ating acelasi fisier | Re-planifica valurile sau worktree + merge de catre lead |
| PRD modificat in executie fara re-review | Schimbare de scope → inapoi la PLAN |
| Lead verifica singur, fara subagent VERIFY | Partinire de confirmare — VERIFY cere context proaspat |
| Continua peste poarta umana | Aprobarea PRD si confirmarea commit sunt ale utilizatorului — opreste-te |
---
## 6. Skill-uri in proces
| Faza | Skill | Rol |
|------|-------|-----|
| PLAN | `/prd` | genereaza PRD-ul (`docs/prd/prd-X.Y-.md`) |
| PLAN | `/plan-ceo-review`, `/plan-eng-review`, `/plan-design-review` | review de plan (primele 2 obligatorii; design doar UI) |
| EXECUTE | `/investigate` | bug neinteles raportat de worker — root cause, nu patch orb |
| VERIFY | `/browse`, `/qa-only` | browser headless / QA doar-raport (nu repara — pastreaza independenta) |
| CLOSE | `/code-review` | review pe diff-ul livrabilei |
| oricand | `/learn` | salveaza gotcha-uri in `.claude/rules/` (nu in acest doc) |
---
## 7. Intretinere
Acest document se actualizeaza la **schimbari de proces** (nu per livrabila) si la **dashboard**
(la fiecare livrabila terminata — §3). Lectiile operationale (gotchas, pattern-uri descoperite in
executie) merg in `.claude/rules/` via `/learn`, nu aici.