rar-autopass/docs/prd/prd-5.15-propagare-design-dashboard-editare.md

# PRD 5.15 — Propagare design landing in aplicatie (dashboard compact + editare slim, VIN unic, prestatii multi-select)

**Stare**: draft

> Proces complet: `docs/ROADMAP.md` §5. Contract RAR (sursa de adevar): `docs/api-rar-contract.md`.
> Sistemul de design al landing-ului: `app/web/templates/landing.html` (commit 41aa385), `DESIGN.md`.
> Starea trece: `draft -> aprobat -> in-executie -> verify-pass -> inchis`.

## 1. Obiectiv

Propagam sistemul de design al landing-ului comercial (carduri/liste/formulare compacte,
slim, si cele 4 teme grafit/cobalt/cupru/hartie) in aplicatia reala. Concret: dashboard-ul
Acasa primeste cardurile-contor + lista de trimiteri slim din mockup-ul hero, iar formularul
de editare trimitere primeste designul compact din mockup-ul "prestatie noua", cu **un singur
camp VIN**, **Observatii** ca text liber pentru operatiile de service si **prestatii ca chips
multi-select** de coduri RAR. Userul a cerut explicit replicarea acestor doua mockup-uri pentru
ca ii place cat de compacte/slim sunt.

Decizii de produs confirmate cu userul (poarta de aprobare a acestui PRD):
- **D1**: cardurile-contor INLOCUIESC bara de status actuala (`_status.html`); pastram doar
  indicatorii de sanatate worker/RAR intr-o forma compacta.
- **D2**: temele sunt ADITIVE — pastram light/dark/petrol + Auto SI adaugam cele 4 din landing
  (grafit/cobalt/cupru/hartie). Selectorul ciclic le parcurge pe toate. (grafit ~ dark si
  hartie ~ light raman optiuni separate, la cererea userului.)
- **D3**: prestatiile sunt chips reale multi-select — utilizatorul poate adauga mai multe coduri
  din nomenclatorul RAR si poate sterge oricare; se trimite lista `prestatii` completa (RAR
  accepta lista `{codPrestatie, idPrezentare:null}` — `docs/api-rar-contract.md` §payload).
- **D4** (contor Trimise): cardul "Trimise" arata trei valori temporale — **all-time** (principal)
  + **luna asta** + **azi** (secundar). Necesita extinderea numaratorilor cu `sent_today`/`sent_month`.
- **D5** (Observatii = operatii service): in API-ul RAR, campul `obs` e DE FAPT denumirea operatiilor
  din service. Deci `obs` = text liber cu operatiile efectuate; la import, daca fisierul nu are
  coloana Observatii, **concatenam denumirea operatiei de service in `obs`**. `obs` ramane in
  `payload_json` (camp din contractul RAR), fara coloana noua.

Fapte verificate care fundamenteaza scope-ul (nu presupuneri):
- `vin` la RAR e **un singur camp** (17 car., MAJUSCULE, fara O/I/Q) — cerinta "fara 2 campuri
  VIN" e deja respectata azi (`_form_editare.html` are un singur `vin`); ramane sa NU regresam.
- `prestatii` e deja **lista** in modelul intern (`mapping.resolve_prestatii(prestatii: list[dict])`)
  si in contractul RAR — multi-select nu cere model nou, ci editor nou.
- `obs` exista deja ca alias de coloana la import (`import_router.py:71` — Observatii/Obs/Mentiuni/Note)
  si ca text liber optional in contractul RAR (`obs`); azi NU e editabil in formular.

## 2. Non-Goals (anti scope-creep)

- Fara modificari pe backend-ul de trimitere: worker, masina de stari, idempotenta-logica
  (`build_key`), reconciliere, contract RAR. Recalcularea idempotentei la editare foloseste
  mecanismul EXISTENT (ca la 3.5/5.10), nu unul nou.
- Fara migrare de schema decat daca strict necesar. `obs` si `prestatii` traiesc in
  `submissions.payload_json` (de confirmat la US-005) — fara coloane noi daca payload-ul le poarta.
- Fara stergerea functionalitatii listei de trimiteri: filtre (data/vehicul/stare), paginare,
  bulk-delete pe randuri blocate, click->detaliu raman; se schimba DOAR aspectul randului (slim).
- Fara schimbarea regulilor de mapare operatie->cod sau a validarii nomenclatorului RAR
  (`mapping.py`, `validation.py` raman ca atare; doar callsite-urile de editare le folosesc cu lista).
- Fara redesign al landing-ului (deja livrat in 5.x); aici doar IMPORTAM stilul lui in app.

## 3. Stories atomice

> Backend + UI pentru acelasi comportament = 2 stories. `base.html` e fisier FIERBINTE
> (serializat intre valuri — un singur autor pe val). Toate UI verificate pe un esantion de teme (o tema luminoasa + una intunecata).

### US-001: Teme aditive (light/dark/petrol + grafit/cobalt/cupru/hartie) + tokeni `--card2`/`--line2`
**Ca** operator de service **vreau** aceleasi teme ca pe landing **pentru ca** aplicatia sa para
acelasi produs, coerent vizual.

- **Depinde de**: —
- **Fisiere**: `app/web/templates/base.html`, `DESIGN.md`, `tests/test_tema.py` (~3 fisiere)
- **Test intai (RED)**: `tests/test_tema.py` — `test_cele_4_teme_definite`, `test_tokeni_card2_line2_in_toate_temele`, `test_anti_fouc_4_stari`, `test_migrare_localStorage_legacy`
- **Acceptance criteria**:
  - [ ] Pastram temele EXISTENTE light/dark/petrol si ADAUGAM 4 teme noi grafit/cobalt/cupru/hartie,
        definite prin token-urile EXISTENTE (`--bg/--card/--ink/--muted/--line/--ok/--warn/--err/--accent`)
        + DOUA noi `--card2` (fundal input/contor) si `--line2` (separator subtire). `--card2`/`--line2`
        primesc valori si in light/dark/petrol (fallback rezonabil). Maparea landing->app pentru cele 4
        noi: `--text->--ink`, `--sub->--muted`, `--okt->--ok`, `--errt->--err`, `--infot->--accent`.
  - [ ] Selectorul ciclic parcurge TOATE: light -> dark -> petrol -> grafit -> cobalt -> cupru ->
        hartie -> Auto, afiseaza eticheta temei curente, persistenta `localStorage` (D2).
  - [ ] "Auto" pastrat: urmeaza `prefers-color-scheme`, rezolva la dark/grafit sau light/hartie
        (decizie minora: Auto -> dark + hartie pentru light, sau dark/grafit — aliniaza cu I2).
  - [ ] Script anti-FOUC in `<head>` seteaza `data-theme` sincron pre-paint pentru toate starile;
        valoare necunoscuta -> Auto, fara blink. Valorile vechi raman valide (nu se mapeaza fortat).
  - [ ] Contrast AA pentru text principal in toate temele (light + hartie sunt cele luminoase).
  - [ ] `DESIGN.md` actualizat: sectiunea cromatica + selector tema reflecta toate temele.
- **Verificare E2E**: browser pe `/` (dashboard logat) — ciclare prin toate temele, persistenta la
  refresh, fara FOUC; toate temele selectabile.

### US-002: Componente de design slim in `base.html` (CSS, fara consumatori inca)
**Ca** dezvoltator **vreau** clase reutilizabile pentru carduri-contor, lista slim, campuri slim si
chips **pentru ca** dashboard-ul si formularul sa le consume DRY, identic cu mockup-ul.

- **Depinde de**: US-001 (foloseste `--card2`/`--line2`)
- **Fisiere**: `app/web/templates/base.html`, `DESIGN.md`, `tests/test_web_responsive.py` (~3 fisiere)
- **Test intai (RED)**: `tests/test_web_responsive.py` — `test_clasa_contor_card`, `test_clasa_lista_slim`, `test_clasa_camp_slim`, `test_clasa_chips`
- **Acceptance criteria**:
  - [ ] `.contor-card` (sau nume aliniat conventiei): cifra mare bold + eticheta mica muted, fundal
        `--card2`, bordura `--line`, radius 8px, padding 10-12px; variante de culoare a cifrei prin
        `.s-*` existente (verde/accent/rosu).
  - [ ] `.lista-trimiteri-slim` cu rand `.trimitere-slim`: stanga = VIN mono (linia 1) + operatie·ora
        muted (linia 2, 11px); dreapta = pill de stare; separator `--line2`; padding 10-14px.
        Randul ramane clickabil (rol button) si pastreaza tinta 44px pe mobil.
  - [ ] Varianta slim de camp formular: label 11px muted deasupra, input ~30px inaltime, fundal
        `--card2`, mono pentru VIN/odometru/nr; integrata in macro-ul `camp` din `_macros.html`
        printr-un flag (`slim=True`), fara a rupe randarea actuala (default neschimbat).
  - [ ] `.chips` + `.chip` (cu buton `×` de stergere) pentru prestatii multi-select; accesibil
        (buton real cu `aria-label`), stilat ca in mockup (accent 18%, font 10-11px).
  - [ ] Zero regresie vizuala pe componentele existente (`.card/.pill/.act/.tabel-trimiteri`).
- **Verificare E2E**: pagina de proba/sandbox sau direct in US-003/004/007; vizual pe un esantion de teme + 390/1280.

### US-003: Dashboard Acasa — carduri-contor inlocuiesc bara de status
**Ca** operator **vreau** cele 3 carduri-contor compacte (Trimise / In coada / De corectat)
**pentru ca** sa vad starea dintr-o privire, ca in mockup.

- **Depinde de**: US-002
- **Fisiere**: `app/web/templates/_status.html`, `app/web/templates/_acasa.html`,
  `app/web/routes.py` (`_status_counts` extins cu `sent_today`/`sent_month`), `tests/test_web_status.py`,
  `tests/test_web_dashboard.py` (~5 fisiere)
- **Test intai (RED)**: `tests/test_web_status.py` — `test_trei_contoare_card`, `test_trimise_all_time_luna_azi`, `test_sanatate_compacta_worker_rar`, `test_fara_bara_veche`
- **Acceptance criteria**:
  - [ ] Antetul Acasa = card "Trimiteri RAR AUTOPASS" cu 3 contoare slim: **In coada** (queued, accent),
        **Trimise** (sent, verde), **De corectat** (blocate = needs_data + needs_mapping + error, rosu).
  - [ ] Cardul **Trimise** afiseaza trei valori temporale (D4): all-time (cifra principala) + "luna asta"
        + "azi" (sub-linie secundara). `_status_counts` extins cu `sent_today`/`sent_month` (filtru pe
        `updated_at`/data trimitere; scoped pe cont), restul contoarelor din numaratoarea existenta.
  - [ ] Indicatorii de sanatate worker/RAR + ultima autentificare RAR raman, intr-o forma compacta
        (pill/glif), nu bara cu 2 randuri ca azi; pastreaza glifele accesibile ✓/✗ (nu doar culoare).
  - [ ] Navigarea existenta (Trimiteri/Mapari + badge needs_mapping) se pastreaza.
  - [ ] Scoped pe cont; poll-ul existent (`/_fragments/status`) randeaza noul antet fara a pierde tab-ul.
  - [ ] Responsive: cele 3 contoare pe un rand pe desktop, stivuite/2-pe-rand pe mobil, fara overflow.
- **Verificare E2E**: browser pe `/` — contoare corecte vs date din DB, sanatate worker mort/viu,
  poll pastreaza starea.

### US-004: Lista de trimiteri — rand slim (VIN + operatie·ora + pill)
**Ca** operator **vreau** lista de trimiteri in stil slim ca in mockup **pentru ca** e mai compacta
si mai usor de scanat, pastrand filtrele si actiunile.

- **Depinde de**: US-002
- **Fisiere**: `app/web/templates/_submissions.html`, `app/web/templates/_coada.html` (filtre raman),
  `tests/test_web_submissions.py`, `tests/test_web_responsive.py` (~4 fisiere)
- **Test intai (RED)**: `tests/test_web_submissions.py` — `test_rand_slim_vin_operatie_pill`, `test_filtre_paginare_pastrate`, `test_bulk_doar_blocate`, `test_click_deschide_detaliu`
- **Acceptance criteria**:
  - [ ] Fiecare rand: stanga VIN mono scurt (`vin_scurt`) linia 1 + operatie + ora/data muted linia 2;
        dreapta pill de stare (`stare_css`/`stare_scurt`). Nr. inmatriculare, data completa si nr.
        prezentare RAR raman accesibile (linie meta discreta si/sau in modalul de detaliu).
  - [ ] Filtre (data/vehicul/stare — `_coada.html`), paginarea numerotata si bulk-delete pe randuri
        blocate (checkbox doar pe `gestionabil`) raman FUNCTIONALE.
  - [ ] Click pe rand deschide `/_fragments/trimitere/{id}` in modal (neschimbat).
  - [ ] Slim layout consistent desktop si <=1024px (cardurile responsive existente nu regreseaza).
  - [ ] Pill-urile de stare folosesc maparea din `labels.py` (zero etichete noi).
- **Verificare E2E**: browser — filtrare + paginare + click detaliu + bulk pe blocate, pe 4 teme,
  pe 390/820/1280.

### US-005: Backend — `obs` (Observatii) editabil si persistat
**Ca** operator **vreau** sa editez Observatiile (operatiile de service in text liber) **pentru ca**
sa corectez/completez ce s-a facut, separat de codurile RAR.

- **Depinde de**: —
- **Fisiere**: `app/web/routes.py` (`/trimitere/{id}/corecteaza`),
  `app/api/v1/import_router.py` (`/_import/{id}/rand/{row}/editeaza`, `EDIT_FIELDS`),
  `app/validation.py` (obs optional), `app/payload_view.py` (echo obs),
  `tests/test_web_corectie*.py`, `tests/test_import_review.py` (~6 fisiere)
- **Test intai (RED)**: `tests/test_web_corectie_obs.py` — `test_obs_editabil_persistat_corecteaza`, `test_obs_persistat_preview_editeaza`, `test_obs_optional_gol_ok`, `test_import_concateneaza_operatie_in_obs`
- **Acceptance criteria**:
  - [ ] `obs` traieste in `payload_json` (camp `obs` din contractul RAR); fara coloana noua / migrare (D5).
  - [ ] `obs` adaugat in `EDIT_FIELDS`; `corecteaza` si `editeaza` (preview) accepta si persista `obs`.
  - [ ] `obs` optional (text liber, fara validare de continut, doar trim); apare in `payload_view`.
  - [ ] `obs` se include in payload-ul trimis la RAR (camp `obs`) — fara a schimba celelalte campuri;
        idempotenta se recalculeaza ca la orice editare (mecanism existent).
  - [ ] **La import**, daca fisierul NU are coloana Observatii, denumirea operatiei de service se
        CONCATENEAZA in `obs` (D5: `obs` = operatiile efectuate); daca are coloana Observatii, se
        pastreaza textul ei. Format de concatenare definit (ex. denumiri separate prin "; ").
- **Verificare E2E**: `POST /trimitere/{id}/corecteaza` cu `obs` -> persistat -> vizibil in detaliu;
  optional proba live RAR ca `obs` apare in FINALIZATA.

### US-006: Backend — prestatii multi-cod (lista) la editare/corectie
**Ca** operator **vreau** sa adaug/sterg mai multe coduri RAR pe o trimitere **pentru ca** o
comanda poate avea mai multe prestatii, asa cum accepta RAR.

- **Depinde de**: —
- **Fisiere**: `app/web/routes.py` (`/corecteaza`, `/repune`),
  `app/api/v1/import_router.py` (`/editeaza`), `app/mapping.py` (folosit cu lista — fara schimbare
  de logica), `app/validation.py` (fiecare cod in nomenclator), `tests/test_web_corectie*.py`,
  `tests/test_mapping*.py` (~6 fisiere)
- **Test intai (RED)**: `tests/test_web_corectie_prestatii.py` — `test_mai_multe_coduri_acceptate`, `test_cod_invalid_respins`, `test_lista_goala_needs_mapping`, `test_idempotency_recalculat`, `test_odometru_initial_conditionat_R_ODO`
- **Acceptance criteria**:
  - [ ] Handler-ele de editare accepta o LISTA de `cod_prestatie` (mai multe valori), inlocuind
        selectul unic; reconstruiesc `prestatii` ca `[{cod_prestatie, idPrezentare:null}, ...]`.
  - [ ] Fiecare cod e validat fata de nomenclator (`valid_codes`); cod necunoscut -> respins cu
        mesaj (NU se trimite raw — invariant ORA-12899 din CLAUDE.md/contract).
  - [ ] Lista goala de coduri -> ramane `needs_mapping` (nu se trimite fara cod).
  - [ ] Recalcul idempotenta dupa editare (mecanism existent), cu prinderea coliziunii ca azi.
  - [ ] Se pastreaza regula `odometruInitial` obligatoriu cand lista contine `R-ODO`/`I-ODO`
        (contract §payload) — validare existenta, doar verificata pe lista.
- **Verificare E2E**: `POST /corecteaza` cu 2 coduri valide -> `queued` cu `prestatii` de lungime 2;
  cu un cod invalid -> respins; optional live RAR cu 2 prestatii -> FINALIZATA.

### US-007: UI — formular editare slim (VIN unic, Observatii, chips prestatii)
**Ca** operator **vreau** formularul de editare in design slim cu chips de prestatii **pentru ca**
e compact si imi arata clar codurile RAR si observatiile, ca in mockup.

- **Depinde de**: US-002, US-005, US-006
- **Fisiere**: `app/web/templates/_form_editare.html`, `app/web/templates/_macros.html`,
  `app/web/templates/_trimitere_detaliu.html`, `app/web/templates/_editare_preview_modal.html`,
  `tests/test_web_preview_edit.py`, `tests/test_web_detaliu*.py` (~6 fisiere)
- **Test intai (RED)**: `tests/test_web_form_editare_slim.py` — `test_un_singur_vin`, `test_camp_observatii_prezent`, `test_chips_multi_select_prestatii`, `test_adauga_sterge_chip`, `test_form_slim_in_ambele_modale`
- **Acceptance criteria**:
  - [ ] Formularul foloseste varianta slim de camp (US-002): VIN, Data prestatiei, Nr. inmatriculare,
        Observatii (textarea), prestatii (chips), Odometru — un SINGUR camp VIN (fara "Confirma VIN").
  - [ ] Observatii = textarea liber, legat de `obs` (US-005).
  - [ ] Prestatii = chips multi-select: fiecare cod ca chip cu `×`; un picker (dropdown din
        nomenclator) adauga un cod nou; lista se trimite ca `cod_prestatie` multiplu (US-006).
  - [ ] Acelasi `_form_editare.html` slujeste ambele modale (detaliu `/corecteaza` si preview
        `/editeaza`), fara duplicare; degradare fara JS rezonabila (chips ca lista, picker = select).
  - [ ] Stilizare fidela mockup-ului pe cele 4 teme; tinte 44px pe mobil; a11y (label-uri, aria).
- **Verificare E2E**: browser — editare trimitere needs_data: schimb VIN + scriu Observatii + adaug
  2 coduri RAR (chips) + sterg unul -> salvare -> persistat; identic in preview import.

### US-008: Teste de regresie + E2E final pe cele 4 teme
**Ca** dezvoltator **vreau** acoperire si o trecere E2E completa **pentru ca** redesign-ul atinge
fisiere fierbinti (base.html) si nu vreau regresii pe teme/liste/formular.

- **Depinde de**: US-003, US-004, US-007
- **Fisiere**: `tests/test_web_responsive.py`, `tests/test_tema.py`, `tests/test_web_submissions.py`
  (~3 fisiere)
- **Test intai (RED)**: completare scenarii lipsa (4 teme x componente noi; slim list desktop+mobil)
- **Acceptance criteria**:
  - [ ] `pytest -q -m "not live"` verde (fara regresii fata de baseline).
  - [ ] E2E Playwright pe 390/820/1280, pe light/dark/petrol + cele 4 noi (esantion: grafit + hartie): dashboard contoare,
        lista slim cu filtre/paginare/bulk, formular slim cu chips, fara overflow orizontal.
- **Verificare E2E**: rulare completa documentata in Raportul VERIFY.

## 4. Riscuri

- **base.html fisier fierbinte**: US-001/US-002 il ating amandoua + US-003/004/007 il citesc.
  Serializeaza pe valuri (un singur autor pe val pe base.html), ca la 5.12/5.13.
- **Migrare teme legacy**: useri cu `localStorage.theme` = light/dark/petrol. Mitigare: maparea
  grafioasa din US-001 (light->hartie, dark->grafit, petrol->grafit) + test dedicat.
- **Restyle lista = pierdere de functii**: filtre/paginare/bulk pot fi sparte de schimbarea de
  markup. Mitigare: US-004 are AC explicite pentru pastrarea lor + teste lock.
- **Idempotenta la prestatii multiple**: schimbarea listei schimba cheia canonica. Mitigare:
  refolosim mecanismul existent de recalcul + prindere coliziune (3.5/5.10), zero logica noua.
- **Densitate vizuala pe mobil**: randul slim cu 2 linii + pill poate aglomera. Mitigare: tinte
  44px + verificare 390px in US-004/008.

## 5. Intrebari deschise

> Toate intrebarile au fost REZOLVATE cu userul (vezi D1-D5 §1). Pastrate aici ca istoric al deciziei.

- **I1 — contor Trimise** [REZOLVAT]: arata all-time + luna asta + azi (D4). `_status_counts` extins.
- **I2 — teme** [REZOLVAT]: aditiv — light/dark/petrol + Auto + grafit/cobalt/cupru/hartie (D2).
- **I3 — stocare obs** [REZOLVAT]: in `payload_json`, fara coloana noua (D5).
- **I4 — operatii la import -> obs** [REZOLVAT]: concatenam denumirea operatiei in `obs` cand
  fisierul nu are coloana Observatii (D5).
- Reziduale minore (de decis la executie, non-blocante): formatul exact de concatenare a denumirilor
  in `obs`; rezolvarea "Auto" la light vs hartie; eventuala deduplicare grafit~dark / hartie~light
  in eticheta selectorului.

## 6. Valuri de executie (graful de dependente)

```
Val 1: [US-001]                 base.html teme + tokeni (autor unic pe base.html)
Val 2: [US-002]                 base.html componente (dupa US-001, autor unic pe base.html)
Val 3: [US-003] [US-004]        dashboard + lista (consuma US-002; fisiere disjuncte) ||
       [US-005] [US-006]        backend obs + prestatii (fisiere backend; pot rula in paralel cu UI)
Val 4: [US-007]                 formular slim (dupa US-002+US-005+US-006)
Val 5: [US-008]                 regresie + E2E final
```

---

## Raport VERIFY

> Completat de subagentul verificator (context curat) in faza VERIFY — vezi ROADMAP §5.6.
> PASS/FAIL per criteriu, cu dovezi (output pytest citat, E2E pe RAR test). Lipseste pana la VERIFY.