Pornind de la bug-urile găsite în walkthrough-ul tău (mașina apare la Atelier dar nu la Constatare, nu are mecanic și nu poate fi alocat, coada de recepție neclară, formular de recepție incomplet) — am tras de fir până la cauza-rădăcină în cod. Concluzia: o singură cauză explică majoritatea defectelor de „apare aici dar nu acolo", iar aceeași cauză e și sursa senzației de „greu/încărcat". Documentul propune soluții, fiecare cu o matrice de decizie ponderată. Doar cercetare — fără implementare.
Metodă 3 investigații în cod (surse de date · formular recepție · logică de rol & teste)Țintă LaFix v5 (demo) → port în produs (server/ + frontend/)Stare propuneri + matrice de decizie · aștept green-light
00 Sumar executiv
Un singur defect structural explică aproape tot
Bug-urile par separate, dar 4 din 5 vin din același loc: platforma ține faza unei mașini în două modele paralele care nu se sincronizează. Restul sunt goluri de captură la recepție și un punct orb în teste. Iar greutatea percepută a UI-ului are aceeași sursă: aceleași mașini afișate pe multe suprafețe care nu sunt de acord între ele.
#
Constatare
Sev.
Cauza-rădăcină
02
Mașina apare la Atelier dar nu la Constatare (și invers, între ecrane)
Critic
Atelier citește vehicles.faza; Constatarea citește assessments. Recepția creează doar vehicles, niciodată assessments.
03
Mașina nouă nu are mecanic și nu poate fi alocat
Critic
Vehiculul creat la recepție are mecanic:null și fără assessment nu există unde să atașezi alocarea.
04
„Coadă recepție" — neclar ce așteaptă fiecare; rolul șef vede încă mașina preluată
Mare
Filtrul e corect tehnic, dar semantica (ce înseamnă „în coadă" / „preluată") nu e comunicată în UI.
05
Recepție fără km · VIN · categorie problemă · delegat firmă; categoria nu se mai auto-setează și nici nu se poate alege
Mare
Câmpurile nu există în formular; categoria e capturată doar pe WhatsApp și pierdută la creare; câmpurile de daună sunt colectate dar ignorate de reducer.
06
Testele nu prind bug-uri de rol/flux — rulează tot ca „owner"
Critic
Niciun scenariu nu intră în rolul responsabil al fazei; zero aserții cross-pagină / cross-rol. Exact de asta a supraviețuit bug-ul de recepție.
07
UI perceput „greu/încărcat"
Mediu
Aceleași mașini pe Atelier + 6 pagini de fază (liste paralele) + benzi KPI pe fiecare ecran.
Firul roșu: dacă unifici sursa de adevăr a fazei (02/03), repari și inconsistențele și decongestionezi UI-ul (07) — paginile de fază devin lentile peste aceeași sursă, nu liste care se contrazic.
01 Harta surselor de adevăr
Fiecare ecran citește din altă parte
Din ce sursă de stare își construiește fiecare pagină lista. Verde = aliniat cu faza vehiculului. Roșu = sursă proprie care poate diverge.
Atelier
vehicles.faza (toate fazele)
✓ sursa de referință
Constatare
assessments (NU vehicles)
✗ diverge — cere assessment
Recepție · coadă
receptions + excludere advansate
✓ filtrul e corect
Ofertare
offers + vehicles faza=ofertare
✓ aliniat
Aprovizionare
vehicles faza=aprov. + parts
✓ aliniat
Execuție
vehicles faza∈{aprov,servisare}
✓ aliniat (+ filtru rol)
Finalizare
vehicles faza=finalizare
✓ aliniat
6 din 7 ecrane derivă din vehicles.faza. Singura excepție e Constatarea, care citește din assessments — un al doilea model, populat doar de datele-sămânță, niciodată de recepțiile reale. De aici toată divergența.
Când creezi o recepție, reducer-ul scrie un vehicles (cu faza:"receptie") și un receptions — dar niciodată un assessments. Când avansezi mașina în „constatare", se schimbă doar vehicles.faza. Atelier (care citește vehicles) o arată în banda Constatare; pagina Constatare (care citește assessments) n-o vede. Și pentru că nu există assessment, nu există unde să atașezi mecanicul → „nu pot asocia mecanic".
De ce reparația anterioară n-a ținut: am corectat simptomul (mașina rămânea în coada de recepție) marcând recepția „preluată" la avansare. Dar cauza — lipsa unui assessment — a rămas, și a reapărut pe alt ecran. O reparație la nivel de simptom, nu de model.
Cum facem ca toate ecranele să fie de acord asupra fazei + sub-stării unei mașini?
Criterii (pondere): Consistență ×3 · Aliniere model BE ×3 · Efort ×2 (mic=bun) · Risc regresie ×2 · Claritate dev ×2
Opțiune
Consist.
BE
Efort
Risc
Claritate
Total
A · Patch defensivfiecare pagină citește vehicles.faza ca fallback când lipsește assessment
3
1
5
3
2
31
B · Sincronizare la dispatchADD_RECEPTION + ADVANCE creează/actualizează automat assessment-ul, într-un singur loc
5
3
4
4
4
49
C · Dosar vehicul unicun obiect per mașină (faza + sub-stări + mecanic + constatare/ofertă/piese ca sub-obiecte); paginile = lentile filtrate
5
5
2
3
5
51
A = despairB = dilemăC = sinergie
Recomandare:B acum (deblochează demo-ul cu o singură schimbare în reducer — recepția/avansarea creează assessment-ul, deci mecanicul devine alocabil și mașina apare peste tot), C la port (în BE, „dosarul vehicul" unic e modelul curat — exact ce-ți trebuie pentru match-ul mecanic↔mașină). B și C dau scoruri foarte apropiate; diferența e doar momentul: B nu blochează demo-ul, C e ținta de producție.
03 Alocarea mecanicului Critic
„Nu are mecanic și nu pot asocia"
Acesta nu e un bug separat — e fața vizibilă a #02. Vehiculul creat la recepție pleacă cu mecanic:null, iar alocarea (Constatare → „Alocare") operează pe assessments, care nu există pentru mașina ta. Soluția B din #02 îl rezolvă automat: assessment-ul creat la recepție are câmpurile de alocare, deci „Alocare" funcționează.
De ce contează pentru BE: match-ul mecanic↔mașină (cerința ta) are nevoie de un punct unic unde stau categoria problemei (vezi #05) + specializarea mecanicului + faza. Dosarul-vehicul (C) e exact acel punct.
Pe lângă alocarea manuală: odată ce categoria e capturată corect, Gogu poate propune mecanicul potrivit (🤖, cu „de ce?"), iar șeful confirmă — aliniat cu regula „AI sugerează, omul decide".
Evidență: data-reducer.jsx ADD_RECEPTION creează vehicle cu mecanic:null, fără assessment; constatare.jsx alocarea operează pe assessments.
04 Semantica cozii de recepție Mare
„Ce reprezintă coada de recepție?"
Tehnic, filtrul e corect: o mașină dispare din coadă când recepția devine „preluată". Problema e de comunicare — coada amestecă, fără să spună, mașini în stări diferite, iar tu nu poți ști „la o privire" ce ai de pregătit. Și starea „de primit" vs „preluat" nu e evidentă.
Ce e o recepție „în coadă", de fapt: o cerere de intrare care încă nu a fost preluată fizic — poate fi (a) programare telefonică ce urmează să sosească, (b) mesaj WhatsApp de transformat în recepție, (c) walk-in prezent la birou. Sunt 3 lucruri diferite, cu pregătire diferită, afișate identic.
Propunere (afișare, nu cod nou) finisaj
Sub-grupare cu etichetă „așteaptă: …" — Așteaptă sosirea (programări) · De preluat din WhatsApp · La birou acum. Fiecare card spune explicit ce blochează preluarea.
Stare fizică vizibilă — chip „De primit" → „Preluat" pe card (vocabularul există deja: programata→preluata), ca să se vadă la o privire ce e în service.
După preluare → dispare din coadă (deja corect) și apare în Constatare (după ce #02 e reparat).
05 Captură la recepție Mare
Formularul de recepție e incomplet
Lipsesc câmpuri esențiale pentru BE și pentru deciziile de mai târziu. Unele date sunt chiar extrase de Gogu (km, VIN) dar afișate doar read-only, nu capturate; categoria e capturată pe WhatsApp dar pierdută la creare; câmpurile de daună sunt colectate dar ignorate de reducer.
Câmp
Stare azi
Necesar pentru
Kilometraj
lipsă în formular (extras de Gogu, doar read-only)
istoric, recomandări revizie, deviz
VIN / serie șasiu
lipsă în formular
identificare unică, comandă piese corecte
Categorie problemă
nu se auto-setează, nu e selectabilă (există doar pe WhatsApp, hardcodat „frâne" în fișă)
match mecanic↔mașină (BE), rutare, statistici
Tip client (delegat firmă)
dispărut — recepția forțează „Persoană fizică"
facturare juridică, delegat, date firmă
Câmpuri daună (asigurator/dosar/franșiză)
colectate dar ignorate de reducer
dosar daună, plată asigurător
Stare „preluată"
funcționează (programata→preluata)
—
Cum setăm categoria problemei (necesară pentru match-ul mecanic↔mașină)?
A · Doar select manualoperatorul alege din listă de fiecare dată
3
2
5
3
29
B · Doar auto (Gogu)derivată din textul problemei, fără override
3
5
1
2
27
C · HibridGogu propune (🤖 + conf%), operatorul confirmă/schimbă din listă
5
4
5
5
48
A = despairB = dilemăC = sinergie
Recomandare: C (hibrid). Gogu pre-completează categoria din textul reclamat, marcată 🤖 cu procent de încredere și „de ce?", dar e un select editabil — exact ce aveai înainte + afordanță onestă. Categoria se salvează în recepție/dosar și ajunge în BE pentru alocare.
Evidență: flow-ui.jsx (formular ~67) · pages-more.jsx (fișă Gogu ~579, „frâne" hardcodat) · data-reducer.jsx (payload ADD_RECEPTION fără km/vin/categorie/tip client; daună ignorată) · flows.jsx (selector tip client există doar la „Client nou" ~72).
06 Logica de rol netestată Critic
De ce au scăpat bug-urile: testez totul ca „owner"
Ai dreptate complet. Suita E2E rulează aproape tot ca owner (care vede toate ecranele) și comută pe client doar pentru portal. Niciun scenariu nu intră în rolul responsabil al fazei (consilier/mecanic/șef/magazie) ca să verifice că omul care trebuie să facă operațiunea chiar o vede și o poate face. Și nu există nicio aserție cross-pagină sau cross-rol. De asta a trecut bug-ul de recepție: nimic nu verifică „aceeași mașină, aceeași fază, pe orice ecran și pentru rolul corect".
Gol în acoperire
Ce ar fi prins
Rulare în rolul real al fazei
„mecanicul nu vede mașina la Constatare" / „nu poate aloca"
Invariant cross-pagină (aceeași mașină pe toate ecranele afectate)
„apare la Atelier dar nu la Constatare"
Părăsire stare (după avansare, pleacă din ecranul vechi)
„rămâne în coada de recepție după preluare"
Gating pe rol (rolul greșit NU poate acționa)
butoane de acțiune ne-restricționate pe rol
Livrare notificare pe rol
notificarea ajunge la rolul țintă, nu la altcineva
Cum facem „tester role" mai complet și infiltrat, ca să prindă astfel de bug-uri?
Criterii (pondere): Acoperire bug-uri ×3 · Mentenabilitate ×2 · Efort ×2 (mic=bun) · Valoare ca regresie ×3
Opțiune
Acoperire
Menten.
Efort
Regresie
Total
A · Aserții ad-hocadaug câteva verificări pe ici-colo
2
2
5
2
26
B · Scenarii per-rolfiecare fază rulată în rolul responsabil, cu verificarea că vede ce trebuie
4
3
3
4
40
C · Matrice de integritate fluxper tranziție: rolul corect poate · rolurile greșite nu · mașina apare/dispare pe TOATE paginile · notificarea ajunge la rolul țintă + invariant „o mașină, o fază peste tot"
5
4
2
5
47
A = despairB = dilemăC = sinergie
Recomandare: C. Un strat nou în harness care, după fiecare avansare de fază, comută în rolul responsabil și verifică invariantul „aceeași mașină, aceeași fază, pe toate ecranele afectate + alocabilă de cine trebuie + invizibilă cui nu trebuie". Asta e exact „testerul infiltrat" pe care îl ceri — și ar fi prins toate bug-urile din acest raport.
Evidență: lafix-e2e-demo.mjs (toate scenariile pornesc ca owner; doar portal=client; assertSeen e single-screen) · constatare.jsx / pages-core.jsx (primesc role dar nu îl folosesc la gating).
07 Greutatea percepută Mediu
Cum percep eu „încărcat și greoi" — și ce-l decongestionează
Sincer: platforma e puternică dar densă. Cea mai mare sursă de greutate nu sunt culorile sau spațierea — e redundanța structurală: aceeași mașină trăiește pe Atelier și pe 6 pagini de fază, fiecare cu propria listă, plus o bandă KPI „Biroul tău" pe fiecare ecran. Multe suprafețe care arată date suprapuse și uneori se contrazic (vezi #02). Vestea bună: dacă unifici sursa de adevăr, decongestionarea vine aproape gratis.
Suprafețe duplicate de fază — Atelier (board cu toate fazele) + cele 6 pagini de fază (Recepție · Constatare · Ofertare · Aprovizionare · Execuție · Finalizare), fiecare cu lista ei. Aceeași mașină apare pe board și pe pagina fazei curente — minim 2 locuri, în tranziții chiar 3. Cât timp toate ar citi din aceeași sursă ar fi doar redundanță; pentru că citesc din modele diferite (#02), suprapunerea se transformă în contradicție — detaliat mai jos.
Bandă KPI pe fiecare pagină — „Biroul tău" concurează cu lista de lucru pentru atenție.
Formular de recepție lung — 3 moduri + 8 câmpuri stivuite într-un singur ecran.
Două feluri de duplicare — și de ce doar una e cu adevărat un defect
Nu orice repetiție e o eroare. Aceeași mașină ajunge în mai multe locuri din două motive complet diferite — și doar unul trebuie reparat:
Suprapunere proiectată — board-ul Atelier e vederea de ansamblu (toate fazele, dintr-o privire), iar pagina de fază e suprafața de lucru a rolului responsabil. Că mașina apare în ambele e voit; costul real e doar atenția împărțită și senzația de „prea multe locuri". Asta o reduci prin ierarhie vizuală, nu prin ștergere.
Contradicție accidentală — pentru că suprafețele nu citesc din aceeași sursă (Atelier din vehicles.faza, Constatarea din assessments — vezi #02), nu se mai suprapun curat: una pune mașina într-o fază, alta n-o arată deloc. Aici „suprapus" devine „se contrazice", iar utilizatorul nu mai știe pe cine să creadă. Asta nu se rezolvă cosmetic — e o problemă de model.
Concret, pentru o singură mașină avansată în Constatare printr-o recepție reală, iată ce vede utilizatorul pe fiecare suprafață — același vehicul, șapte ecrane:
Suprafață
Citește din
Ce vede utilizatorul
Verdict
Atelier (board)
vehicles.faza
Mașina, în banda „Constatare"
✓ corect
Constatare (pagină)
assessments
Nimic — nu există assessment pentru ea
✗ se contrazice cu Atelier
Alocare mecanic (din Constatare)
assessments
Niciun loc unde să atașezi mecanicul
✗ blocaj — vezi #03
Recepție · coadă
receptions (fără avansate)
Nimic — a fost deja avansată
✓ corect
Ofertare · Aprovizionare · Execuție · Finalizare
vehicles.faza
Nimic — nu e încă în fazele lor
✓ corect
Din 7 suprafețe, 6 sunt de acord. Singura care ar trebui să arate mașina — pagina Constatare — e exact cea care n-o vede. „Suprapus" devine „se contrazice" fix în punctul care contează.
De ce decongestionarea vine „aproape gratis": dacă paginile de fază devin lentile filtrate peste o singură sursă (opțiunea C, vezi #02), două lucruri se întâmplă din aceeași schimbare. Unu — contradicțiile dispar prin construcție: nu mai există un al doilea model care să difere, deci nimic nu se mai poate contrazice. Doi — poți decide conștient pe câte suprafețe apare o mașină, fără să ții manual sincronizate liste paralele; ce rămâne e suprapunere voită, nu accidentală. Nu plătești de două ori: efortul care repară clasa de bug-uri din #02 e același care subțiază UI-ul. De-aici „gratis".
Citire: redundanța structurală (aceeași mașină în mai multe locuri) apasă mult mai tare decât culorile sau spațierea — și e singura reparată de fond doar de opțiunea C. KPI/topbar/formular sunt câștiguri ieftine din A/B.
Stânga (acum): aceeași mașină trăiește pe board și pe fiecare listă de fază, peste o bandă KPI și un topbar plin → încărcare mare. Dreapta (C): Atelier devine sursa canonică, paginile de fază devin lentile filtrate peste ea, KPI se colapsează, topbar se strânge → decongestionarea vine aproape gratis și clasa de bug-uri „apare aici dar nu acolo" (#02) dispare.
B · Disclosure progresivKPI colapsabile, formular recepție în pași, topbar cu „mai multe"
4
5
3
2
34
C · Restructurare în jurul unei singure surseAtelier = board-ul canonic; paginile de fază = lentile filtrate peste aceeași sursă, nu liste paralele; fiecare ecran un singur job
5
4
2
5
45
A = despairB = dilemăC = sinergie
Recomandare: C ca direcție, cu câștigurile rapide din B pe parcurs. C decongestionează și elimină clasa de bug-uri din #02 (o singură sursă → nimic nu se mai contrazice). B (KPI colapsabile, recepție în pași) sunt câștiguri ieftine de făcut imediat. A singur nu rezolvă cauza.
Despre ideea de drag-and-drop pe Programare (coloană cu mașini de programat, în dreapta): e utilă, dar adaugă greutate exact unde vrem s-o reducem. Recomand s-o tratăm ca îmbunătățire după decongestionare (C/B) — și, dacă o facem, ca o lentilă peste aceeași sursă (mașinile „de programat" = vehicule fără slot), nu ca încă o listă separată.
07b Wireframe-uri · opțiunea C
O sursă, multe lentile — cum arată restructurarea
Opțiunea câștigătoare (C, scor 45) elimină structural clasa de bug-uri #02 — nu o peticește. Direcția în patru cadre: conceptul, board-ul canonic și două lentile. Sunt wireframe-uri (fidelitate redusă, copy real); culorile și spațierea s-ar alinia la design-system-ul v5 la implementare.
Modelul de navigare ales
Filtre in-place pe o singură rută/atelier — nu pagini separate per fază. O bară de lentile persistentă, cu contoare live, îngustează board-ul la o singură bandă și schimbă jobul, fără să navighezi și fără să încarci altă sursă. O rută proprie per lentilă ar reintroduce exact senzația de „altă pagină = altă listă" care a născut #02; o singură rută face imposibilă existența unei a doua liste.
Conceptul. Toate cele șase lentile pornesc din același array vehicles[]; contorul fiecărei lentile = vehicles.filter(v=>v.faza===k).length, aceeași formulă ca pe board → paritate garantată. constatare/ofertă/piese devin fațete atașate vehiculului. Modelul vechi cu trei liste paralele — sursa bug-ului #02 — e eliminat.
Board-ul canonic (Atelier). O singură rută, o bară de lentile persistentă cu contoare live. Cardul are o bandă de fațete (Constatare / Ofertă / Piese) — golul „—" este job de făcut, nu o dispariție. Niciun KPI deasupra, nicio listă paralelă: tot ce se vede e vehicles.filter peste aceeași colecție.
Lentila Constatare. Lista = vehicles.filter(v=>v.faza==='constatare'), nu state.assessments. Mașina venită de la recepție fără fațetă apare obligatoriu, cu „Constatare neîncepută → Alocă mecanic" (scrie pe vehicul) — bug-urile #02 și #03 devin imposibile. Sub-stările sunt un segment în interiorul unei singure benzi; panoul deschide fațeta Constatare a aceluiași vehicul.
Lentila Aprovizionare. Orientată pe vehicul; piesele sunt imbricate sub operații (niciodată listă plată), cu stepper forward-only: În stoc → Comandată → Livrată → Predată mecanicului. „Trimite în Execuție" se activează doar când toate piesele sunt livrate. Nu mai citește state.parts ca listă de top.
Patru decizii rămase
Decizie
Recomandare
Split vs colaps pe desktop lat board plin + panou de fază, sau o singură bandă lățită?
Colaps implicit (protejează „un singur job"); split ca opțiune doar pe ecran lat.
„Predată" — 6 sau 7 lentile azi e status, nu faza
6 lentile aliniate la PIPELINE; „Predate" ca vedere-arhivă terminală, nu lentilă de flux.
Permisiuni per-rol magazia vede doar Aprovizionare
Ascunde lentilele/fațetele interzise (nu le dezactiva); mută matricea rol-fază în condiționale de lentilă/fațetă.
Redirect URL-uri vechi /constatari · /ofertare · /piese
Devin ?lentila=… pe /atelier, cu redirect pentru bookmark-urile vechi.
Despre aceste cadre. Generate din assets/optiunea-c/mocks.html prin frontend/scripts/generate-optiunea-c-mocks.mjs (Playwright, 2× DPR) — regenerabile idempotent. Câștigurile rapide din opțiunea B (KPI colapsabile, formular recepție în pași, topbar „mai multe") sunt deja livrate; C rămâne direcția pentru decongestionarea de fond.
07c Raport de decizie · bara de lentile pe paginile de fază
Mai are sens rândul LENTILE când faza e deja aleasă din meniu?
Întrebarea patronului (4 iul.): „mai are sens să văd bara de lentile dacă oricum sunt în Aprovizionare? și se vede în stânga în meniu ce am ales". Raportul de mai jos analizează redundanța, propune trei opțiuni cu machete și le punctează în trei matrice. Stare: ✅ echipa a ales opțiunea A („Scoatem bara") — implementată pe 4 iul. 2026. Meniul e singura navigare între faze, contorul stă în subtitlu, Atelierul își păstrează lentilele. Testele E2E nu atingeau bara, deci schimbarea e sigură tehnic.
Diagnoza: ce dublează bara și ce aduce unic
Funcție
Meniul din stânga
Bara de lentile
Verdict
Destinațiile (fazele)
✅ toate, filtrate pe rol
✅ toate
duplicat
Contor per fază
✅ insigne (Ofertare 3)
✅ în chip
duplicat
Faza curentă evidențiată
✅ element activ
✅ chip activ
duplicat
Întoarcerea la tabloul „Toate"
❌ (Atelier e alt element)
✅
unic — dar acoperit de breadcrumb-ul „‹ Toate fazele"
Ordinea fazelor (sens de conductă)
⚠️ listă verticală
✅ secvență orizontală
unic
Nuanță importantă: pe Atelier aceeași bară are alt rol — chips-urile filtrează tabloul pe loc (lentile adevărate). Problema există doar pe paginile de fază deschise din meniu, unde chips-urile navighează — adică dublează meniul.
Cele trei opțiuni, în machete
C · Cum e azi. Aceleași destinații și aceleași contoare apar de două ori la 300px distanță. Rândul LENTILE consumă un rând întreg de spațiu vertical pe fiecare pagină de fază.
A · Scoatem bara (recomandat). Meniul rămâne singura navigare între faze; „‹ Toate fazele" acoperă întoarcerea la tablou; contorul stă în subtitlu. Câștig imediat: încă un rând de conținut vizibil. Atelierul își păstrează lentilele (acolo filtrează, nu duplică).
B · Mini-fir de flux. Chips-urile devin un fir discret de puncte cu contoare — păstrezi sensul de conductă și saltul rapid, fără aspect de a doua navigare. Cost: un element vizual nou, unic în aplicație, de întreținut.
Matricea principală — criterii ponderate
Criteriu
Pondere
A · Scoatem
B · Mini-fir
C · Cum e
Claritate navigație (o singură sursă de adevăr)
25%
5
4
2
Conștiența fluxului (poziție + volume în conductă)
20%
2
5
4
Spațiu vertical câștigat
15%
5
4
2
Viteza de salt între faze
15%
3
4
5
Omogenitate cu ecosistemul
15%
5
3
3
Efort & risc de implementare
10%
5
2
5
Total ponderat
4,10
3,95
3,30
Punctaje argumentate: la viteza de salt A ia 3, nu 1 — meniul e tot un singur clic, pierzi doar apropierea de conținut. La conștiența fluxului A ia 2 — insignele din meniu dau volumele, dar pierd ordinea orizontală. La omogenitate B ia 3 — introduce o „specie vizuală" nouă, exact ce am eliminat în rundele 9–10.
Matricea pe roluri — cine pierde, cine câștigă
Rol
Folosește paginile de fază…
A
B
C
Șef atelier
intens, sare des între faze
−mic (saltul mută în meniu) / +claritate
+păstrează secvența
± status quo
Consilier
Recepție · Ofertare · Finalizare
+spațiu, −nimic real
±
−zgomot
Mecanic / Vopsitor
doar Execuția
+mult (bara e zgomot pur)
±
−zgomot pur
Patron
survolează tot
± (are Atelier + Rapoarte)
+conductă vizibilă
±
Matricea de risc
Risc
A · Scoatem
B · Mini-fir
C · Cum e
Regresii E2E
zero (bara nu e atinsă de teste)
mic (element nou)
zero
Obiceiuri de utilizator rupte
mic (obiceiuri neformate)
mic
—
Datorie de design pe termen lung
zero
mediu (element unic de întreținut)
mare (redundanța rămâne în orice captură și decizie viitoare)
Reversibilitate
totală (un rând condiționat)
medie
—
Sensibilitate & recomandare
Singura pondere care răstoarnă concluzia: dacă conștiența fluxului urcă la 30% („vreau ca oricine, pe orice ecran de fază, să simtă conducta cu volumele ei"), B trece pe primul loc (4,25 vs 3,90). Cele două opțiuni nu se exclud în timp: principiul „unelte la momentul potrivit" spune să nu construim B speculativ — A acum, iar dacă după o săptămână de folosire lipsește firul conductei, B se construiește curat peste A, proiectat de la zero.
Recomandare: A acum, B în buzunar. A câștigă matricea principală, are risc zero și reversibilitate totală, elimină complet confuzia semnalată și e coerentă cu direcția rundelor 9–11: o singură sursă de adevăr pe funcție (navigarea = meniul · filtrarea = lentilele din Atelier · poziția = breadcrumb + titlu). Stare: ✅ decis A — implementat (bara scoasă din Constatare · Ofertare · Aprovizionare; Atelierul păstrează lentilele). Machetele se regenerează idempotent din assets/lentile-faza/mocks.html prin frontend/scripts/generate-lentile-mocks.mjs.
08 Prioritizare & recomandare
Ce aș face, în ce ordine
Ordonat după raport valoare/risc. Nimic din asta nu e implementat — aștept să alegi ce dau drumul.
#
Acțiune
Rezolvă
Efort
Recomandare
1
Sincronizare assessment la recepție/avansare (#02 opțiunea B)
mașina apare peste tot · mecanic alocabil (#02, #03)
mic
acum
2
Captură recepție: km, VIN, categorie hibridă (🤖+select), tip client (delegat firmă), persistare daună (#05)
date pentru BE + alocare
mediu
acum
3
Strat de teste „integritate flux pe rol" (#06 opțiunea C)
prinde regresiile de mai sus + viitoare
mediu
acum (împreună cu 1–2)
4
Claritate coadă recepție (sub-grupare „așteaptă: …" + stare fizică) (#04)
„la o privire știu ce am de pregătit"
mic
curând
5
Câștiguri rapide UX (KPI colapsabile, recepție în pași) (#07-B)
greutate percepută
mic-mediu
curând
6
Restructurare „o singură sursă" (#02-C + #07-C) — la port în BE
cauza-rădăcină + decongestionare structurală
mare
la port
7
Programare drag-and-drop (ca lentilă)
confort planificare
mediu
după declutter
Pachetul pe care l-aș da drumul primul: 1 + 2 + 3 împreună — repară bug-urile critice și pun plasa de siguranță care le ține reparate. Spune-mi „dă drumul" și le implementez (cu testele de integritate care chiar comută în roluri), apoi continuăm cu 4–5. Restructurarea mare (6) o ținem pentru port, ca decizie conștientă.
09 Backlog UX prioritizat
Ce mai putem decongestiona — sweep complet, toate ecranele
Rezultatul unui audit UX pe întreaga aplicație (cinci clustere de ecrane + un audit dedicat de setări & configurări). Tot ce e deja livrat anterior (KPI colapsabile, recepție în pași, topbar „mai multe", board-ul cu lentile, unificarea #02) e exclus.
✅ Aplicat integral. Întregul backlog de mai jos a fost implementat în prototipul LaFix v5 (quick-wins, big bets, setări & configurări) și verificat în browser + suita E2E. Tabelele rămân ca jurnal al deciziilor; nu mai sunt „de făcut".
✅ Runda „Testare manuală V5" (2 iul. 2026) — aplicată integral. Constatările din testarea manuală a patronului au fost rezolvate ca clase, nu ca simptome: cerințele de fază din Flux Operativ se aplică acum LIVE în Recepție și Finalizare (foto obligatorii, talon, QC — cu gate real pe avans, fără ocolire); categorii problemă multi-select editabile în fișă și în fluxul manual; adresă de facturare capturată la recepție (fișă → client → factură); căutare client existent la recepția manuală; conversația WhatsApp e derivată din starea reală a mașinii (problema reclamată, faza, oferta), derulabilă, cu trimitere funcțională și status ✓/✓✓; numărătoarea „Oferte" pe client e coerentă cu faza (fără „2 oferte" fără constatare); acord GDPR + proces-verbal de predare + plată — semnabile/achitabile și de la distanță, prin link în portalul clientului; navigarea după „Deschide constatare" e conștientă de rol; grila „Biroul tău" împachetează dens (golurile se umplu). Scenariu E2E nou: linkuri-portal.
✅ Runda „Măturare de descoperire" (2 iul. 2026, auto-QA) — aplicată integral. Audit automat pe toate combinațiile rol × ecran (55 de pagini, capturi + 4 recenzori) după modelul de testare al patronului; 30 de defecte reparate ca clase: coerența numerelor (pastilele din Ofertare împart exact „Toate"; Execuție separă „în execuție · la constatare"; Aprovizionare, Programare, Contabilitate, Facturare, Stoc, Echipă, Portal — toate numerotările spun adevărul despre ce e pe ecran), orientare (titlul paginii = elementul de meniu; bara laterală are semn de derulare + explicații pe insigne; etichetele statice de fază nu mai arată a legături; avertisment „suprapunere" pe programări dublate pe aceeași stație), curățenie de limbă (Split→Împarte/Suprapus, Reminder→Memento, Discount→Reducere, Master/Mid→Maestru/Calfă, „Menu"→„Nelu", pluralul „~1 lună", panoul de reguli al fluxului integral în română) și proveniență (LTV, frecvența de revenire — explicate la survol). Verificat: E2E 229/229 + 38/38, re-audit 55/55 curat cu rolurile aplicate corect.
Semnale transversale încredere mare
Ridicate independent de mai mulți auditori — deci reale, nu de gust.
Salvare / persistență inconsistentă — unele configurări salvează automat, altele se pierd la navigare (Model Fluxuri, persona & sarcinile Asistentului). Niciun model mental unitar.
Ecrane duplicate — matricea RBAC trăiește în Roluri ȘI Sarcini; configul Asistentului în Asistent AI ȘI Sarcini; Model Fluxuri are două definiții (una moartă, coliziune pe window).
Afordanțe „false" — câmpuri de căutare inerte (onSearch no-op pe 8 ecrane), „Conectează WhatsApp" ca toggle fals, tooltip-uri doar-pe-hover pe suprafețe touch (Portal).
Provenance „de ce?" lipsește pe valori calculate / AI peste tot (piese recomandate, categorii WhatsApp, notificări, bonus, LTV, TVA).
Quick-wins impact mare · efort mic
Ecran
Propunere
Impact
Efort
Constatare, Ofertare & 5 ecrane admin
Câmpurile „Caută…" sunt inerte — leagă-le de listă (item-ele sunt deja la îndemână) sau scoate-le până sunt funcționale (onSearch no-op pe 8 locuri).
mare
S
Constatare (decizie)
Două butoane identice „Adaugă la Constatare" → „+ Adaugă constatare" (defecte) vs „+ Adaugă operațiune" — unul adaugă greșit tipul.
Subtitlu de scop pe fiecare pagină de bani + de-duplică KPI „de încasat" la un singur proprietar.
mediu
S
Big bets impact mare · efort mai mare
Ecran
Propunere
Efort
Roluri / Sarcini / Asistent
O singură matrice RBAC persistată (Roluri = sursă), Sarcini doar rezumat read-only; configul Gogu doar în Asistent AI.
M
Recepție · Fișă
Câmpurile pre-completate de AI fie editabile real (contract dirty→saving→saved), fie text simplu etichetă/valoare; cele 7 badge-uri „✦ auto" → un singur „✦ pre-completat din talon · de ce?".
M
Execuție Service (tabletă)
Bara „Blocat / Termină Lucrarea" lipită jos (sticky footer) — acțiunea cea mai frecventă, mereu la un tap („mâini unsuroase").
M
Shell (wayfinding)
Promovează breadcrumb-ul „Atelier ▸ fază" în Toolbar-ul comun + fiecare SlideOver cu Esc-to-close + header consistent.
L
Model Fluxuri
Șterge pagina SLA moartă (coliziune window) + persistă fluxul + confirm pe politicile cu risc.
M
Catalog tematic
Afordanțe — elimină controalele false / inerte
Ecran
Propunere
Impact
Efort
Recepție · Fișă
Valori AI read-only deghizate în input-uri → editabile sau text simplu.
mare
M
Auto la Schimb
Mâner de redimensionare (ew-resize) pentru durata închirierii (1–7 zile).
mediu
M
Relații Clienți
„Legat de acest client" cu valori fantomă → leagă de date reale, „niciuna" când e gol.
mediu
M
Constatare
Toggle „Fă intern" arată ca etichetă statică → switch clar / „🔒 Intern" text simplu.
mic
S
Transparență & provenance — fiecare valoare calculată/AI cu „de ce?"
Ecran
Propunere
Impact
Efort
Aprovizionare · Piese
„de ce?" per rând pe piesa „✦ recomandat" — scor preț / termen / garanție / marjă față de alternative.
mediu
M
WhatsApp (drawer)
Pastilă cu nr. detectat + client rezolvat + „de ce?" pe categorie (cuvinte-cheie + scor).
mediu
M
NotifBell
Chip de rol + grupare pe rol + provenance „declanșat de: predare B-127-LFX".
mediu
M
Integrări
Status real (ok / sincronizare / eroare / token expiră) + last-sync + erorile sus.
mediu
M
Densitate & decongestie
Ecran
Propunere
Impact
Efort
Ofertare
Status repetat de 3× pe card → scoate rollup-ul, buton etichetat „Trimite" / „Marchează aprobată".
mediu
S
Atelier
Legendă pentru glifele de fațete (✓ gata · • în lucru · ! de făcut) + mută linia platform/since în panou.
mediu
M
Relații Clienți
Sortează necitite + ITP-imminent sus; badge necitit legat de o sursă reală.
mediu
M
Consistență — dedup + extrage controale comune
Ecran
Propunere
Impact
Efort
6 ecrane-listă
Un singur FilterChips + sort pe Seg peste tot — aceeași acțiune mentală arată la fel.
mediu
M
Bonus (lei) vs restul (€)
Etichetă de unitate pe cardul Bonus + un singur fmtMoney(value, currency).
mediu
S
Execuție Service
Un singur ServiceVehCard (constatare + execuție au azi 2 vocabulare).
mediu
M
Sidebar colapsat
Un singur model de rail pentru toate rolurile (azi diferă pe rol).
mediu
M
Flux & accesibilitatea acțiunii
Ecran
Propunere
Impact
Efort
WhatsApp (drawer)
Acțiunea primară după categorie (problemă → „Creează recepție"; confirmare → „Deschide în Programări").
mediu
S
Programare
Drag direct al unui bloc (orizontal = altă zi, vertical = altă oră), reutilizând logica din Auto la Schimb.
mare
M
Configurare Rapoarte
Mută toggle-urile în Rapoarte („Personalizează panoul") sau mini-preview live.
mediu
M
FAB global
Afordanță ▾ + condu cu create-uri secundare când pagina expune deja primarul.
mediu
M
NotifBell
Rândul = peek-in-place (marchează citit); navigarea pe „Deschide ▸" explicit.
mic
S
LocationPicker
Icon-only implicit; pastila etichetată doar pe ruta Stoc · Gestiune (singura pe care o scopează).
mediu
S
Setări & Configurări audit dedicat
Salvare & feedback — locul unde se pierd date
Ecran
Propunere
Impact
Efort
Model Fluxuri
Editor complet pe useState pur — „Gata" pierde tot. Persistă flow+policies + bară „Salvează / Renunță".
mare
M
Asistent AI / Sarcini
Persona + task-uri dispar la navigare (doar numele are „Salvează"). Persistă + auto-save uniform cu un singur „Salvat ✓".
mare
M
Setări · Program
Modifică programul live, fără toast/buton — o bifă greșită schimbă tăcut sloturile. Bară „Salvează" pe murdar.
mare
M
Roluri
Auto-save real, dar anunțat doar într-un AICard jos → indicator persistent „Salvat automat ✓".
mediu
S
Configurare Rapoarte
Toggle tăcut → contor live „Panoul are N casete" + bifă „Salvat".
mic
S
Siguranță — configurări periculoase
Ecran
Propunere
Impact
Efort
Fluxuri
Politicile cu risc mare („Owner forțează gate", „Preț preferențial / portiță") se aprind cu un tap → confirm la activare + grup „Cu risc — auditate".
mare
S
Roluri
„Resetează" șterge instant toate rolurile custom + matricea → confirm.
mediu
S
Fluxuri
„Adaugă fază" inserează o fază no-op în afara taxonomiei de 6 → ascunde sub „fază personalizată (avansat)" cu avertisment.
mediu
M
IA / descoperire & afordanțe oneste
Ecran
Propunere
Impact
Efort
Setări (hub)
O pagină-poartă grupată (Operare · Comunicare · Echipă & roluri · Asistent · Audit) + mereu afișează tab-bar-ul chiar în mod only=.
mare
M
Audit
Interval de timp (Azi / 7z / 30z) + „Exportă (CSV)" + dată absolută la hover pe timestamp.
mediu
M
WhatsApp
„Conectează" e un toggle fals → SlideOver cu pașii reali (număr / cod), apoi marchează conectat.
mediu
M
WhatsApp
Toggle-uri dependente se sting fără motiv → stare „blocat" + „Disponibil după conectarea WhatsApp".
Task-urile Gogu fără provenance → popover „ce face" (declanșator → acțiune → ecran) + 🤖 + „decizia ta rămâne finală".
mediu
M
Roluri vs Sarcini / Asistent
Dedup la o singură sursă (în spiritul #02) — vezi „Big bets".
mediu
M
Copy (DEX)
„widget" → „casetă" (deja folosit în Rapoarte, inconsistent în WorkDesk); „checklist-ul" → „lista de cerințe".
mic
S
Fluxuri
Câmp SLA-țintă (zile) în drawer (promis în subtitlu, lipsește) + drag-handle ca la WorkDesk.
mediu
M
Setări · Program
Chip-delta pe capacitate („−18 sloturi/săpt. față de acum") + scoate slot/zi din hidden.
mediu
S
Cum a fost produs: sweep UX pe 5 clustere de ecrane (flux operativ · relații & programare · administrativ · shell/navigație/WorkDesk · sistem de design) + un audit dedicat de setări & configurări, sintetizate și deduplicate. Stare: ✅ aplicat integral — fiecare propunere de mai sus e implementată în prototip și verificată (browser + E2E).
Stare la închiderea ciclului v5 5 iul. 2026
✅ Închis în rundele 5–16.
Bara de lentile scoasă de pe paginile de fază (decizia §07c, opțiunea A) — meniul e singura navigare; Atelierul păstrează lentilele.
FAB mutat în șina de meniu, cu etichete în frază („Caută la furnizori", „Adaugă casetă").
Vederi separate pe clasă de rol: pad-ul de decizie la șef/consilier/patron; executanții (mecanic + vopsitor) pe vederea de lucru; șeful — supraveghetor la Execuție.
Porți config-driven cu dovezi pe toate cele 6 faze („Termină" la Constatare cere pozele; „Portiță patron" auditată).
Impersonare pe toți executanții („Vezi platforma ca", listă pe două coloane, fără derulare).
O singură navigare și în Configurare (bara de taburi scoasă — R16).
Matricea de notificări rol × categorie completă și găsibilă (Configurare → „Notificări & WhatsApp" + scurtătura „Cine primește ce?" din clopoțel).
Deschis pentru fluxul următor.
Opțiunea B „mini-fir de flux" (din §07c) rămâne în buzunar — se montează doar dacă echipa o cere.
Birourile KPI pe rol: cod scris dar nemontat — decizie de produs, nu tehnică.
Excepția documentată LfModal pentru scanerul de coduri (singura suprafață care rămâne modală alături de semnare/plată).
Portarea în produs (H3) — abia după acordul a 3 clienți; ADR-urile se scriu întâi.
Întreținerea bazei E2E noi (suita extinsă de scenarii de integritate + tururi) ca prag de regresie al prototipului.
![Diagramă concept: o sursă canonică vehicles[] din care pornesc toate lentilele; fațete per vehicul; modelul vechi cu liste paralele eliminat](assets/optiunea-c/frame-1-concept.png)
