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.

Decizii din /plan-ceo-review (2026-06-28, mod SELECTIVE EXPANSION):

• D6 (sanatate mereu-vizibila): cardurile-contor inlocuiesc bara de status, DAR sanatatea (worker viu? RAR accesibil? ultima autentificare) ramane intr-un strip mereu-vizibil, colorat, deasupra contoarelor (verde "declaratiile curg" / rosu "blocat: worker oprit / RAR inaccesibil"). Invariant: zero-silent-failures — semnalul critic NU se ingroapa sub volum. (Rafineaza D1.)
• D7 (operatie -> obs, fara regresie de mapare): la import, denumirea operatiei RAMANE in op_service (sursa pentru maparea op->cod) SI se COPIAZA in obs. obs e sink aditional, nu mutare; fluxul needs_mapping ramane neatins. (Rafineaza D5.)
• D8 (idempotenta obs): obs e EXCLUS din cheia de idempotenta (idempotency.py:98). Deci editarea obs NU schimba cheia si NU poate crea duplicate — corecteaza AC-ul gresit din US-005. prestatii ESTE in cheie (sortat dupa cod) — multi-select re-cheieaza randul (US-006).
• D9 (secventiere): 5.15 INAINTE de 5.14 (mapare LLM). Editorul manual defineste forma listei prestatii si UX-ul de confirmare; 5.14 umple codurile peste aceeasi forma.
• D10 (extinderi acceptate, SELECTIVE EXPANSION): toate 4 intra in scope — (a) salvare mapare din chip (US-009), (b) bulk-fix din lista (US-010), (c) require dinamic odometruInitial la chip R-ODO/I-ODO (US-007), (d) editare keyboard-first in form slim (US-007).

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_strip_sanatate_mereu_vizibil, test_strip_rosu_worker_oprit, test_trei_contoare_card, test_trimise_all_time_luna_azi, test_fara_bara_veche
• Acceptance criteria:
  • Strip de sanatate mereu-vizibil, DEASUPRA contoarelor (D6): o linie compacta colorata — verde "declaratiile curg" cand worker viu + RAR ok; rosu + text explicit cand worker oprit SAU RAR inaccesibil ("Blocat: worker oprit" / "Blocat: RAR inaccesibil"), cu ultima autentificare RAR. Glife accesibile ✓/✗ (nu doar culoare). Invariant zero-silent-failures: semnalul "declaratiile NU pleaca" e imposibil de ratat, NU ingropat sub volum.
  • Sub strip: 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. Sursa de timp: NU exista coloana sent_at; folosim status='sent' AND date(updated_at)=.... Justificare (verificat): un rand sent nu mai primeste scrieri ulterioare pana la purge-delete la +90z (purge_after se seteaza in ACEEASI scriere care marcheaza sent), deci updated_at == momentul trimiterii pentru randurile sent -> fara migrare de coloana (respecta Non-Goal). Daca pe viitor apar scrieri post-sent, reevalueaza o coloana sent_at dedicata.
  • Navigarea existenta (Trimiteri/Mapari + badge needs_mapping) se pastreaza. Click pe contorul De corectat deep-link-eaza in lista filtrata pe blocate (?status= existent din 5.x), nu intr-o pagina noua.
  • 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). obs e EXCLUS din cheia de idempotenta (idempotency.py:98) — deci editarea DOAR a obs NU schimba cheia si NU poate crea duplicat (D8). NU recalcula/forta cheia pe baza obs. (Corecteaza formularea anterioara.)
  • La import (D7): denumirea operatiei RAMANE in op_service (sursa pentru maparea op->cod); daca fisierul NU are coloana Observatii, denumirea operatiei se COPIAZA (nu se muta) si in obs; daca are coloana Observatii, se pastreaza textul ei. Format de concatenare definit (denumiri separate prin "; "). Fluxul needs_mapping ramane neatins.
• 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 — rescrie logica single-prestatii[0] de azi: cod_prestatie_curent la routes.py:977-982 + injectia la 1146-1164/1288-1324 presupun UN cod; multi-select cere pre-fill din lista intreaga + scriere pe toti itemii), app/api/v1/import_router.py (/editeaza, idem), app/mapping.py (NEATINS — deja accepta lista), app/validation.py (fiecare cod in nomenclator), tests/test_web_corectie*.py, tests/test_mapping*.py (~6 fisiere). Nota: mapping.py e neatins, dar call-site-urile din handler-e cer un rewrite real (nu "fara schimbare de logica").
• 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, inlocuind selectul unic. NU reconstrui lista cu itemi goi: handler-ele de azi injecteaza codul DOAR in prestatii[0] (routes.py:1146-1164, 1288-1324) — multi-select le rescrie ca: pastreaza itemii existenti cu cod_op_service/denumire (invariant D7) si seteaza/adauga cod_prestatie pe ei. idPrezentare:null se adauga in payload.py la construirea payload-ului, NU in itemul intern.
  • Pereche operatie<->cod definita: cand exista operatii (cod_op_service), fiecare cod-chip se ataseaza unei operatii (1 operatie -> 1 cod, ca azi, dar acum N operatii -> N coduri); cand NU exista operatie (cod direct, ex. corectie pura), chip-urile sunt coduri libere intr-o lista fara op_service. Aceasta pereche e ce consuma US-009 (salvare mapare op->cod).
  • 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).
  • Coduri duplicate (acelasi cod adaugat de 2x) -> deduplicate inainte de persistare (cheia sorteaza deja dupa identitate, dar lista persistata nu trebuie sa contina duplicate).
  • 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).
  • Require dinamic odometruInitial (D10c): cand lista de chips contine R-ODO sau I-ODO, formularul DEZVALUIE si cere odometru_initial (contract §payload), previne 400 RAR si un drum needs_data. Cand niciun chip R-ODO/I-ODO -> campul ramane optional/ascuns.
  • Editare keyboard-first (D10d): in picker, Enter adauga chip-ul selectat; sageti navigheaza optiunile; Esc inchide modalul; focus-ul revine logic dupa adaugare/stergere.
  • Stilizare fidela mockup-ului pe toate temele; tinte 44px pe mobil; a11y (label-uri, aria, anunt de chip adaugat/sters pentru screen-reader).
  • Suprafata JS reala (nota de efort): chips add/remove client-side + picker navigabil cu tastatura + management focus + reveal conditional odometruInitial = JS ne-trivial intr-un app HTMX/minimal-JS. Fallback fara JS: picker = <select> simplu (server valideaza R-ODO->odo, deci no-JS da needs_data corect, nu date gresite) — multi-select se degradeaza la un cod/submit.
• Verificare E2E: browser — editare trimitere needs_data: schimb VIN + scriu Observatii + adaug 2 coduri RAR (chips, cu tastatura) + adaug R-ODO (apare odometruInitial) + sterg un chip -> 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 (componente noi pe TOATE temele; slim list desktop+mobil)
• Acceptance criteria:
  • pytest -q -m "not live" verde (fara regresii fata de baseline).
  • Test de tema robust, nu esantion: un test parametrizat verifica fiecare token critic (--card2, --line2, --accent, --ok, --err) e DEFINIT in TOATE cele 7+1 stari (light/dark/petrol/grafit/cobalt/cupru/hartie/Auto). Ancorare pe SENTINEL CSS (nu felii fixe [idx:idx+N]) — vezi regresia false-green din ROADMAP 5.13.
  • E2E Playwright pe 390/820/1280, pe un dark (grafit) + un light (hartie) + petrol (verificare ca temele vechi nu au regresat): strip sanatate, dashboard contoare, lista slim cu filtre/paginare/bulk, formular slim cu chips, fara overflow orizontal.

US-009: Salvare mapare din chip (compounding cu fluxul de mapare)

Ca operator vreau ca atunci cand adaug un cod RAR la o operatie sa-l pot salva ca regula pentru ca data viitoare operatia sa se auto-rezolve, fara sa re-mapez manual.

• Depinde de: US-006, US-007
• Fisiere: app/web/templates/_form_editare.html, app/web/routes.py (reuse save_mapping + reresolve_account — fara logica noua), tests/test_web_mapare_din_chip.py (~3 fisiere)
• Test intai (RED): tests/test_web_mapare_din_chip.py — test_salveaza_regula_din_chip, test_reresolve_deblocheaza_frate, test_optional_nu_forteaza
• Acceptance criteria:
  • Cand operatia (op_service) e cunoscuta si userul adauga un cod RAR prin chip, apare optiunea "salveaza ca regula op->cod"; la confirmare reuse EXACT save_mapping + reresolve_account (acelasi mecanism ca maparea inline din 5.7), scoped pe cont + CSRF.
  • Re-rezolvarea deblocheaza si alte submission-uri needs_mapping cu aceeasi operatie (pe batch_id).
  • Optional: daca userul nu vrea sa salveze, editarea ramane one-off (fara regula). Se compune cu 5.14 (auto-maparea umple, salvarea din chip ramane fallback-ul uman).
• Verificare E2E: adaug cod la operatie nemapata + salveaza regula -> al doilea rand cu aceeasi operatie se rezolva automat.

US-010: Bulk-fix din lista (selectie multipla -> actiune unica)

Ca operator vreau sa corectez mai multe randuri blocate dintr-o data pentru ca la 2-20 de corectat/zi nu vreau sa intru in fiecare individual.

• Depinde de: US-004, US-006
• Fisiere: app/web/templates/_submissions.html, app/web/routes.py (reuse infra bulk existenta din _submissions + submissions_admin), tests/test_web_bulk_fix.py (~3 fisiere)
• Test intai (RED): tests/test_web_bulk_fix.py — test_bulk_remapeaza_selectie, test_bulk_doar_blocate, test_bulk_scoped_cont
• Acceptance criteria:
  • Pe randurile blocate (checkbox existent pe gestionabil), o actiune bulk noua: aplica un cod RAR / o remapare la toata selectia intr-o singura cerere (reuse forma #bulk-trimiteri).
  • Scoped pe cont (404-before-409 ca la bulk-delete); doar randuri blocate eligibile.
  • Fiecare rand re-validat + idempotenta recalculata individual (un cod invalid pe un rand nu pica tot lotul — sumar "N reusite, M esuate" ca la salvarea mapcoloane D#12).
• Verificare E2E: selectez 3 randuri needs_mapping + aplic un cod -> toate 3 -> queued.
• 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.
• Premisa mobil nevalidata (din TODOS 5.13, CEO F1): valoarea slim/compact pe mobil presupune utilizare reala pe mobil. Daca device-mix-ul e ~95% desktop, partea responsive e efort irosit. Mitigare: nu blocheaza (designul e bun si pe desktop), dar confirma analytics inainte de a investi in rafinari mobil viitoare.
• 7 teme = suprafata de test/intretinere pe fisierul cel mai fierbinte: fiecare componenta noua trebuie corecta in 7+1 stari. Istoricul (5.13) arata ca testele de tema au dat false-green o data. Mitigare: US-008 cere test parametrizat ancorat pe SENTINEL (nu felii fixe); deduparea grafitdark / hartielight ramana optiune de simplificare (reziduala, non-blocanta).
• Secventiere cu 5.14 (D9): 5.15 defineste forma listei prestatii; daca 5.14 (mapare LLM) porneste in paralel, sincronizeaza forma listei. Mitigare: 5.15 INAINTE de 5.14.

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 grafitdark / hartielight 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 + strip sanatate + lista (consuma US-002; disjuncte) ||
       [US-005] [US-006]        backend obs + prestatii (fisiere backend; in paralel cu UI)
Val 4: [US-007]                 formular slim cu chips (dupa US-002+US-005+US-006)
Val 5: [US-009] [US-010]        salvare mapare din chip || bulk-fix (dupa US-006/007 resp. US-004)
Val 6: [US-008]                 regresie + E2E final (dupa toate)

Secventiere fata de alte PRD-uri (D9): 5.15 INAINTE de 5.14 (mapare LLM) — 5.15 fixeaza forma listei prestatii si UX-ul de confirmare; 5.14 umple codurile peste aceeasi forma.

---

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.

---

GSTACK REVIEW REPORT

Review: /plan-ceo-review — 2026-06-28. Mod: SELECTIVE EXPANSION. Model: claude (opus). Abordare aleasa de user: tot PRD-ul (8 stories) + 4 extinderi acceptate -> 10 stories.

Pasaj	Status	Constatari materiale
Audit sistem	OK	base.html cel mai fierbinte fisier (31x/30z); 5.15 = a 5-a iteratie pe acelasi UI (smell recurent); 5.14 in flight pe acelasi seam
S1 Arhitectura	OK	Fara componente noi; fara migrare; rollback = revert template. Concentrare de risc pe base.html, nu coupling
S2 Eroare/Rescue	2 GAP	(a) coduri duplicate in chips nedefinit -> US-006 dedupe; (b) cod necunoscut: invariant ORA-12899 pastrat
S4 Edge cases	1 GAP HIGH	R-ODO/I-ODO cere odometruInitial; formularul nu il forta -> US-007 require dinamic (D10c)
S2/Idempotenta	1 FIX	obs EXCLUS din cheie (idempotency.py:98) -> AC US-005 corectat (D8); prestatii in cheie -> re-cheiere OK
S6 Test	1 GAP	7 teme x componente pe fisier fierbinte; "esantion" prea lax -> US-008 test parametrizat ancorat pe SENTINEL
S8/S11 Trust	1 HIGH	carduri-contor ascundeau sanatatea -> strip mereu-vizibil deasupra contoarelor (D6)
S9 Deploy	OK	Fara migrare; doar sent_today/sent_month (scoped). Rollback ieftin
S10 Trajectorie	1 DECIZIE	secventiere 5.15 inainte de 5.14 (D9)
S11 Design/UX	OK + 4 EXT	strip trust; extinderi: salvare mapare din chip, bulk-fix, require dinamic odo, keyboard-first

Decizii incorporate (D6-D10): strip sanatate mereu-vizibil (D6); operatie ramane in op_service + copiata in obs (D7); obs exclus din idempotenta, AC corectat (D8); 5.15 inainte de 5.14 (D9); cele 4 extinderi acceptate (D10) -> US-007 imbogatit + US-009 (salvare mapare din chip) + US-010 (bulk-fix).

Risc rezidual notat (non-blocant): premisa "utilizare mobil reala" nevalidata (TODOS 5.13 F1); 7 teme = suprafata de test pe fisier fierbinte (deduparea grafitdark/hartielight ramana optiune).

Spec-review loop (reviewer independent, context curat) — scor 7/10, verdict ISSUES -> remediat:

• #1 HIGH (contradictie): US-006 spunea "reconstruieste prestatii ca itemi goi {cod_prestatie}", ceea ce ar fi sters cod_op_service/denumire -> rupea D7 si US-009. Remediat: US-006 pastreaza itemii existenti, seteaza doar cod_prestatie; pereche operatie<->cod definita; idPrezentare se adauga in payload.py, nu in itemul intern.
• #2 MEDIUM: sent_today/sent_month nu aveau sursa de timp (nu exista sent_at). Remediat: US-003 foloseste status='sent' AND date(updated_at) cu justificare (randul sent nu mai e scris pana la purge la +90z) -> fara migrare.
• #3 MEDIUM: US-006 subestima rewrite-ul handler-elor (logica single-prestatii[0]). Remediat: Fisierele US-006 numesc liniile exacte de rescris.
• #5/#6 LOW: suprafata JS reala (US-007) + tinta de click "De corectat" (US-003). Remediat (note adaugate).
• #4 LOW (scope): US-009/US-010 sunt adiacente FUNCTIONALE (din SELECTIVE EXPANSION), dincolo de obiectivul pur de propagare design. Acceptat constient (alegerea userului); ramane optiunea de a le scoate intr-un PRD separat daca propagarea design e ce e urgent.

VERDICT: APROBAT cu modificari incorporate (+remedieri spec-review). Scope: 10 stories / 6 valuri. Fara CODEX/cross-model in aceasta rulare (review uni-model). Gata de executie dupa confirmarea userului.

NO UNRESOLVED DECISIONS