# 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-27 — 5.13 IMPLEMENTAT + VERIFY PASS (asteapta confirmare commit). Responsive compact (mobil/tableta) + sistem de butoane + design.md, prin agent team (lead orchestreaza, NU scrie cod; teammates Sonnet pe valuri cu fisiere disjuncte; `base.html` serializat ca fisier fierbinte). Wave 0 BLOCANT (cauza probabila a revert-ului anterior, prinsa de eng review): cele 2 teste responsive feliau ferestre fixe `[idx:idx+5000]` de la PRIMUL `@media (max-width:767px)` -> rescrierea cardului impingea regulile (`min-height:0`/`100vw`) peste fereastra si pica fals; refacut sa ancoreze pe un SENTINEL CSS (`SENTINEL-TESTE-MOBIL`) + slice pana la sfarsitul `` (ar fi terminat elementul ``), cauza probabila a revert-ului anterior. Wave 1: FIX P0 break vertical (`min-width:120px` eliminat -> card stivuit), sistem butoane `.btn-secondary/.btn-ghost/.btn-danger/.btn-sm` + `.act/.act-save/.act-del` + macro `act_btn` (aria-label invariant) + `icon()` Lucide, stepper `.stepper-track`/`.stepper-collapsed`, cardificare <=1024px (zero `repeat(2`), versiune ascunsa mobil, sticky-bar compacta. Wave 2: `_stepper.html` rescris, `_mapari.html` icon-btn->act_btn (4 butoane), `_submissions.html` guard „Eroare/Eroare" pill-only + linie meta `actualizat`. Wave 3: `test_web_mapari_actiuni.py` -> `.act` (superseda 5.10) + 5 teste responsive noi + fix `test_web_import_stepper.py` (`facut`->`is-done`). VERIFY context curat: **992 passed, 1 deselected (live)** + E2E browser Playwright 390/820/1280 (mobil fara break vertical, tableta o coloana, desktop tabel neschimbat, wizard slim pe o linie). Bulk-select declarat desktop-only by design (checkbox ascuns mobil). Backend trimitere + schema NEATINSE (pur CSS + markup: 6 template-uri + design.md + 2 teste). Debt: timp relativ ramane absolut; SVG inline (sprite = optimizare viitoare). PRD: [prd-5.13](prd/prd-5.13-responsive-compact.md) | | 5.12 | Editare unificata in modal (preview = acelasi formular ca Trimiteri, scoate editarea inline rupta + eroarea htmx `htmx-internal-data`) + calendar `` pe data prestatiei + cont cu companie/email/CUI obligatorii (`accounts.email` + gate activare) + mapare cu antet+prima inregistrare + un singur Salveaza pe operatii + preview compact fara coloana „Verificat?" + responsive tableta/mobil (header fara suprapuneri) | TODO | | Nascut din dogfooding first-run E2E (Playwright pe `exemple/prezentari_test.csv`, 2026-06-26): reprodus modul de editare inline colapsat pe verticala (`tr.preview-edit` in `table-layout:fixed`) + `TypeError htmx-internal-data` la Anuleaza; data prestatie doar text; toate conturile cu `cui=NULL` + conturi CLI/teste fara email; mapare coloane fara cap de tabel/valori; N butoane Salveaza pe operatii; coloana „Verificat?" neclara; pe tableta/mobil header-ul se suprapune (grila desktop fara breakpoint 768–1024). 8 stories (3 valuri). Decizii user (AskUserQuestion 2026-06-26): calendar = `` nativ; email canonic pe `accounts` (model A); coloana „Verificat?" scoasa (gate `needs_review` mutat in modal). Backend trimitere NEATINS; singura schema = `accounts.email` (migrare defensiva). PRD: [prd-5.12](prd/prd-5.12-editare-modal-cont-obligatoriu-import.md) | ### 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.