romfast-website/prd-restructurare-site.md

PRD — Restructurare Website Romfast

Data: 2026-06-26 Autor: sesiune Claude Code (pe baza analiza-pagini-website.md) Status: Draft pentru revizuire Sursă: analiza-pagini-website.md (inventar + scorare 26 pagini)

---

0. Context și constrângeri tehnice

• Repo: /workspace/romfast-website/ (git, branch main)
• Stack: HTML static + Tailwind CSS (CDN) + Flowbite (CDN) + Lucide Icons (CDN). Fără build process — se editează direct HTML-ul.
• CSS: professional-theme.css (variabile de culoare + componente custom). JS: professional-theme.js (dark mode, mobile menu, init Lucide, scroll animations).
• Referința de design: index.html — homepage recent reproiectat = standardul vizual al site-ului.
• Navigarea e duplicată manual în fiecare pagină (nu există templating). Orice schimbare de meniu se aplică în toate fișierele HTML.
• Deploy: rsync spre a2hosting fără --delete → fișierele șterse din repo rămân pe prod până la ștergere manuală pe server. ⇒ orice „ștergere" trebuie dublată de ștergere manuală pe server sau de un redirect.
• Scope: doar site-ul principal (/, /menu/, /roa/). efactura-generator/ nu intră.

Constatare tehnică (verificată în repo, corectează o presupunere din analiză)

Paginile considerate „layout vechi" (roa-facturare, roa-situatii-financiare, roa-comenzi-clienti, roa-contracte-clienti, roa-gestiune) deja includ professional-theme.css și nav-ul nou. Problema nu e CSS-ul, ci structura body-ului: au buton „Înapoi" (history.back()) în loc de hero + carduri + CTA. ⇒ Efortul de aducere la standard este mediu (rescriere structură internă), nu rescriere de la zero.

---

1. Obiective

1. Lean: reducere de la 26 → ~14-15 pagini active (4 pagini Servicii → 1; ștergere desprenoi + chatbot; 3 module ROA înglobate — comenzi, situații, aplicatii-specifice; contractele rămân program distinct), fără pierderea informației importante.
2. Conversie clară: fiecare pagină de produs duce spre Contact / cerere ofertă cu CTA consistent (Demo + telefon/Contact), max 2 CTA-uri per pagină.
3. Zero redundanță: eliminarea suprapunerilor (analiza↔implementare, alteservicii↔implementare, aplicatii-erp↔homepage).
4. Consistență vizuală 100%: toate paginile la standardul index.html — același hero pattern, carduri, tipografie, footer și navigare.
5. Fără verbose inutil: texte concise, bullet-uri, exemple concrete în loc de beneficii generice.
6. Igienă tehnică: tool-urile interne (chatbot Maria) scoase din indexare/navigare; statistici neverificabile eliminate.

Non-obiective

• Nu introducem CMS / templating (rămâne HTML static).
• Nu atingem efactura-generator/.
• Nu schimbăm paleta de culori sau professional-theme.css (decât dacă o pagină rescrisă cere o componentă nouă reutilizabilă).

---

2. Pagini de șters

Pagină	Motiv	Ce facem cu linkurile	Acțiune pe prod
chatbot.html	Prototip „Cezar", API pe tunel ngrok instabil, depășit de Maria	Nu e în nav (verificat); doar ștergere fișier	Ștergere fizică (repo + manual pe server)
menu/desprenoi.html	Slabă ca dovadă socială; pasajele utile mutate în homepage (decizia D2)	Scoate „Despre noi" din nav în toate paginile	Ștergere fizică (repo + manual pe server)
menu/analiza.html	Consolidat în noua pagină unică menu/servicii.html (vezi §3)	Înlocuit de linkul „Servicii" în nav	Ștergere fizică (repo + manual pe server)
menu/implementare.html	Consolidat în menu/servicii.html	Înlocuit de „Servicii" în nav	Ștergere fizică (repo + manual pe server)
menu/roa-suport-tehnic.html	Consolidat în menu/servicii.html (secțiunea Suport + .exe)	Înlocuit de „Servicii" în nav	Ștergere fizică (repo + manual pe server)
menu/alteservicii.html	100% redundant; ce e util intră în menu/servicii.html	Înlocuit de „Servicii" în nav	Ștergere fizică (repo + manual pe server)

Decizie D1 (luată): ștergere fizică. Fișierele se șterg din repo. Fiindcă rsync-ul nu folosește --delete, ele trebuie șterse și manual pe prod după deploy:

# pe a2hosting (ssh -p 7822 romfastr@nl1-ss18.a2hosting.com)
rm -f ~/public_html/chatbot.html
rm -f ~/public_html/menu/desprenoi.html
rm -f ~/public_html/menu/analiza.html
rm -f ~/public_html/menu/implementare.html
rm -f ~/public_html/menu/roa-suport-tehnic.html
rm -f ~/public_html/menu/alteservicii.html

Se acceptă pierderea oricărui backlink/SEO existent (nu se lasă stub-redirect).

---

3. Pagini de merge / înglobat

Sursă → destinație, cu conținutul exact de salvat:

Sursă	Destinație	Conținut de păstrat	Ce se elimină
roa/roa-comenzi-clienti.html	secțiune în roa/roa-facturare.html (după rescriere)	fluxul comenzi → facturare	layout vechi, buton „Înapoi", text generic
roa/roa-situatii-financiare.html	subsecțiune „Raportare financiară" în roa/roa-financiar-contabilitate.html	formule definite de utilizator, bilanț + P/P	layout vechi, „Înapoi"
roa/roa-aplicatii-specifice.html	secțiune „Capacități tehnice" în roa/aplicatii-erp.html	listele de capacități (Configurator, Raportare, Securitate, Mobile/Web)	CTA-uri duplicate

3a. Pagină nouă consolidată: menu/servicii.html

Decizie client: cele 4 pagini din meniul „Servicii" se comasează într-o singură pagină menu/servicii.html, în standardul vizual index.html (hero + secțiuni + CTA). Dropdown-ul „Servicii" dispare; în nav rămâne un singur link „Servicii".

Sursă	Devine secțiune în servicii.html	Conținut de păstrat	Ce se elimină
menu/analiza.html	Intro: „De ce ERP / De ce ROA"	cele 4 pain points (motive adopție ERP)	sidebar redundant, download-uri duplicate
menu/implementare.html	„Cum implementăm"	mesajul de proces structurat, comprimat la 4-5 pași vizuali (Analiză → Setup → Migrare date → Training → Go-Live & Suport)	matricea de responsabilități cu documente (detaliu contractual, valoare ~0 pentru prospect), cei 8 pași detaliați
menu/roa-suport-tehnic.html	„Suport tehnic"	metoda de suport (canale, buletine lunare, backup Oracle), mențiunea contractului, download Romfast Suport (.exe)	redundanțe; CTA „Solicită Contract" → „Contact Suport"
menu/alteservicii.html	(doar dacă există ceva unic) eventual 1-2 bullet-uri	nimic dacă e 100% redundant	toată pagina

Structura paginii servicii.html: Hero („Implementare & Suport ROA") → De ce ERP (4 pain points) → Cum implementăm (4-5 pași) → Suport tehnic post-implementare (+ .exe) → CTA (Programează demo / Contact).

Efect asupra homepage-ului (D3 = ancore, decizie luată): lista de module din index.html (liniile ~150-222) se păstrează, dar linkurile modulelor înglobate trec pe ancore către pagina gazdă:

Rând homepage	Link nou
Comenzi clienți	roa/roa-facturare.html#comenzi (ancoră — secțiune în facturare)
Situații financiare	roa/roa-financiar-contabilitate.html#raportare (ancoră)
Aplicații specifice	roa/aplicatii-erp.html#capacitati (ancoră — secțiune în hub)
Contracte clienți și furnizori	roa/roa-contracte-clienti.html (rămâne pagină proprie — program distinct, vezi §4)

Implementare: fiecare secțiune gazdă primește un id (<section id="comenzi">, id="raportare", id="capacitati">) ca ancora să funcționeze.

---

4. Pagini de rescris (structură + conținut)

Pagină	Prioritate	Ce se schimbă	Ce se păstrează	Ce se elimină
roa/roa-facturare.html	Înaltă	Rescriere structură la pattern nou (hero + avantaje + flux + CTA); accent pe e-Factura (diferențiator 2025); înglobează doar comenzi clienți ca secțiune (id="comenzi")	integrările cu alte module	buton „Înapoi", layout fără hero
roa/roa-contracte-clienti.html	Medie	Program distinct (clienți + furnizori) — rămâne pagină proprie; rescriere la pattern nou (hero + avantaje + CTA); retitlare „Contracte clienți și furnizori"; flux Contracte→Facturare→Contabilitate vizualizat	cele 7 atribute de contract, fluxul spre facturare	buton „Înapoi", layout vechi, conținut limitat doar la clienți
roa/roa-financiar-contabilitate.html	Medie	Taie ~50% text → bullet-uri; adaugă subsecțiune Raportare financiară (din situatii-financiare); exemple concrete în loc de „Eficiență Operațională" generic	500+ formule, cele 7 secțiuni	avantaje generice, text dens
roa/roa-gestiune.html	Medie	Combină 7 avantaje + 10 facilități → max 6 bullet-uri; pattern nou; scoate „Înapoi"	300+ formule, tipuri documente (NIR, bonuri, facturi)	detalii integrare (redundante cu contabilitate)
menu/desprenoi.html	Joasă	Decizie D2 (luată): ștergere fizică + mutarea pasajelor utile în homepage (intro despre Romfast SRL — vezi §5, index.html). Pagina nu se rescrie.	povestea companiei (1991 Constanța, Oracle/Microsoft) → mutată în homepage	pagina întreagă (după extragerea pasajelor); 3 CTA-uri duplicate

---

5. Pagini de optimizat (modificări punctuale, fără rescriere)

Pagină	Modificări
index.html	1) Păstrează secțiunea download suport (Romfast Suport + Ammyy, ~liniile 237-241) pe homepage — decizie client: clienții sunt direcționați să descarce programul de suport de pe homepage. 2) Adaugă intro despre Romfast SRL înainte de modulele ERP, folosind pasajele recuperate din desprenoi.html (fondată 1991 Constanța, partener Oracle, Microsoft Certified, 30+ ani) — vezi decizia D2. 3) Actualizează lista module după merge-uri (vezi §3). 4) Actualizează nav: „Servicii" devine link simplu spre menu/servicii.html (fără dropdown).
roa/cum-arata-roa.html	Adaugă 1-2 fraze context sub fiecare screenshot (ce face utilizatorul / ce câștigă). Fă vizibil numărul de telefon.
roa/roa-service-auto.html	Temperează limbajul urgent (scoate majuscule din CTA „ACUM!"). Restul e model de referință — păstrează.
roa/roa-horeca.html	Înlocuiește cele 3 beneficii generice cu 1-2 fraze specifice HORECA (ex: recepție → factură → înregistrare contabilă automată).
roa/roa-proiecte-devize.html	Elimină statisticile neverificabile (70%/95%/500+). Reduce de la 5 → 2 CTA-uri.
roa/roa-imobilizari.html	Colapsează 4 subsecțiuni (Funcțiuni/Facilități/Beneficii/Integrare) → 2 (Ce face + Cum se integrează). Adaugă exemplu calcul amortizare.
menu/angajari.html	Reduce radical: 3 fraze + email + link spre contact. Scoate cele 3 carduri goale (Inovație/Echipă/Dezvoltare). Sau listează poziții reale.
chatbot_maria.html + chatbot_maria2.html	Adaugă <meta name="robots" content="noindex">; confirmă că nu sunt în nav; (opțional) stabilizează API host (nu ngrok). Rămân ca tool intern.

---

6. Navigare propusă

Nav actual (din index.html): Prima pagina · Despre noi · ROA · Cum arată ROA · [Servicii ▾: Analiza · Implementare · Suport tehnic · Alte servicii] · Cine folosește ROA · Angajari · Contact

Nav propus: Prima pagina · ROA ▾ · Cum arată ROA · Servicii · Cine folosește ROA · Angajări · Contact

Detaliu:

Prima pagina
ROA ▾
  ├── Toate aplicațiile (aplicatii-erp.html — hub)
  ├── Financiar & Contabilitate
  ├── Gestiune
  ├── Facturare & e-Factura
  ├── Imobilizări
  ├── HORECA
  ├── Service Auto
  └── Proiecte & Devize
Cum arată ROA
Servicii            (link simplu → menu/servicii.html; fără dropdown)
Cine folosește ROA  (referinte.html — argument de vânzare puternic, ținut vizibil)
Angajări
Contact  (CTA)

Eliminate din nav: dropdown-ul „Servicii" întreg (Analiza, Implementare, Suport tehnic, Alte servicii) → înlocuit cu un singur link „Servicii" spre pagina consolidată; Despre noi (pagina ștearsă — D2; conținutul trece în homepage).

Atenție: nav-ul se editează manual în toate fișierele rămase (varianta desktop + varianta mobile în fiecare). Recomandare de proces: definește blocul nav final o dată, apoi propagă-l identic.

---

7. Ordinea de implementare (impact mare / efort mic întâi)

Etapa 1 — Quick wins (efort mic, fără risc de conținut):

1. Scoate analiza și alteservicii din nav (toate paginile); adaugă noindex pe chatbot_maria*.
2. Adaugă download-urile suport și pe roa-suport-tehnic.html (rămân și pe homepage).
3. Elimină statisticile neverificabile din roa-proiecte-devize + reduce CTA-urile.
4. Temperează limbajul din roa-service-auto.

Etapa 2 — Pagina consolidată „Servicii" + ștergeri: 5. Creează menu/servicii.html (pattern nou) prin comasarea: analiza (pain points) + implementare (4-5 pași) + suport tehnic (+ .exe) + alteservicii (vezi §3a). 6. Recuperează pasajele din desprenoi.html → intro homepage. 7. Înlocuiește dropdown-ul „Servicii" cu link simplu spre servicii.html; scoate „Despre noi" din nav. 8. Șterge fișierele: analiza, implementare, roa-suport-tehnic, alteservicii, desprenoi, chatbot. 9. Rulează comenzile rm pe prod (vezi §2) după deploy.

Etapa 3 — Merge module ROA (efort mediu): 10. Rescrie roa-facturare (pattern nou + e-Factura) și înglobează comenzi clienți ca secțiune (id="comenzi"). 11. Rescrie roa-contracte-clienti la pattern nou (program distinct: clienți + furnizori) — rămâne pagină proprie. 12. Înglobează situatii-financiare în financiar-contabilitate (id="raportare"). 13. Înglobează aplicatii-specifice în aplicatii-erp (id="capacitati"). 14. Actualizează linkurile-ancoră din homepage + nav după merge-uri (vezi §3).

Etapa 4 — Rescrieri/optimizări de conținut: 15. Simplifică roa-gestiune, roa-imobilizari, roa-financiar-contabilitate. 16. Optimizează cum-arata-roa, roa-horeca, angajari.

Etapa 5 — Finalizare nav + QA vizual + deploy: 17. Propagă nav-ul final identic în toate paginile. 18. QA vizual în browser pe fiecare pagină, light + dark (vezi §11) — temă unitară, lizibilitate containere, fără artefacte; remediază pe loc ce nu trece. 19. QA linkuri (zero 404 intern), apoi rsync deploy + ștergeri manuale pe prod.

---

8. Cerință transversală — consistență vizuală

Aplicabilă oricărei pagini rescrise/restructurate/optimizate:

• Hero pattern identic cu homepage: gradient navbar, heading mare, subheading, 1-2 CTA-uri.
• Carduri, culori, tipografie exclusiv din professional-theme.css (fără stiluri inline ad-hoc).
• Footer și navigare identice cu homepage.
• Paginile cu structură veche (roa-facturare, roa-situatii-financiare, roa-comenzi-clienti, roa-contracte-clienti, roa-gestiune) sunt explicit non-conforme și trebuie aduse la standard — eliminat butonul „Înapoi"/history.back(), înlocuit cu CTA real.
• Max 2 CTA-uri per pagină, consistent: Programează demo + telefon/Contact.

---

9. Decizii

#	Decizie	Status	Rezultat
D1	Pagini șterse — fizic sau stub-redirect?	✅ Luată	Ștergere fizică (repo + manual pe prod, vezi §2). Fără stub.
D2	desprenoi.html	✅ Luată	Ștergere + mutarea pasajelor (1991 Constanța, Oracle/Microsoft) în homepage (§5). Scoasă din nav.
D3	Module merge-uite — ancoră sau dispar din homepage?	✅ Luată	Ancore. Rândurile rămân pe homepage cu linkuri-ancoră spre pagina gazdă (comenzi→facturare#comenzi, situații→financiar#raportare, aplicatii-specifice→aplicatii-erp#capacitati).
D5	Contracte clienți și furnizori	✅ Luată	Program distinct — roa-contracte-clienti.html NU se înglobează în facturare; rămâne pagină proprie, rescrisă la pattern nou, retitlată „Contracte clienți și furnizori" (clienți + furnizori).
D4	aplicatii-erp.html	✅ Luată	Rămâne ca hub — gazdă pentru module + secțiunea „Capacități tehnice" (din aplicatii-specifice). Linkul „ROA" din nav duce aici.

---

10. Criterii de acceptanță

Cantitative:

• Număr pagini active: ≤ 15 (de la 26).
• Meniul „Servicii" e un singur link (menu/servicii.html), fără dropdown.
• Linkurile-ancoră din homepage funcționează (comenzi→facturare#comenzi, situații→financiar#raportare, aplicatii-specifice→aplicatii-erp#capacitati).
• roa-contracte-clienti e pagină proprie, layout nou, titlu „Contracte clienți și furnizori".
• Zero linkuri interne rupte (404) — verificat cu crawl local.
• Nicio pagină de produs cu buton „Înapoi"/history.back() ca singur CTA.
• Max 2 CTA-uri per pagină de produs.
• Zero statistici neverificabile (70%/95%/500+ etc.) fără sursă.

Calitative:

• Toate paginile folosesc hero + footer + nav identice cu index.html.
• Nav identic propagat în toate fișierele (desktop + mobile).
• analiza, implementare, roa-suport-tehnic, alteservicii, desprenoi, chatbot șterse din repo și de pe prod; absente din nav.
• chatbot_maria* cu noindex, absente din nav.
• menu/servicii.html conține toate 4 secțiunile (De ce ERP / Implementare / Suport / + util din alte servicii).
• Download Romfast Suport (.exe) prezent pe homepage (păstrat intenționat) și în secțiunea Suport din servicii.html.
• Homepage are intro despre Romfast SRL înainte de module.
• e-Factura prezentă vizibil pe roa-facturare.

Deploy:

• rsync rulat; fișierele șterse din repo eliminate manual și de pe prod.
• Smoke test pe prod: homepage, contact, 2-3 pagini ROA, un redirect.

Verificare vizuală în browser (vezi §11 — obligatoriu înainte de „done"):

• Toate paginile rămase trec checklist-ul de QA vizual din §11, în light și dark mode.

---

11. Verificare în browser (QA vizual)

Niciun „done" fără verificare reală în browser. Se rulează pe fiecare pagină rămasă după modificări, în light mode și dark mode, la cel puțin 2 lățimi (desktop ~1280px și mobil ~390px).

Cum se rulează

# server local din rădăcina repo-ului
python3 -m http.server 8000
# apoi verificare automată prin Playwright MCP (browser_navigate + browser_take_screenshot
# pentru fiecare URL, în ambele teme), cu inspecție vizuală a capturilor.

Lista de pagini de verificat (post-restructurare): index, roa/aplicatii-erp, roa/cum-arata-roa, roa/roa-financiar-contabilitate, roa/roa-gestiune, roa/roa-facturare, roa/roa-contracte-clienti, roa/roa-imobilizari, roa/roa-horeca, roa/roa-service-auto, roa/roa-proiecte-devize, menu/servicii, menu/referinte, menu/contact, menu/angajari, menu/politica-confidentialitate.

Checklist per pagină

1. Se încarcă fără erori — pagina randează complet; zero erori în consolă; zero request-uri 404 (CSS/JS/imagini); iconițele Lucide apar (nu rămân <i data-lucide> neînlocuite).
2. Temă unitară — hero, carduri, butoane, tipografie și footer arată identic cu index.html. Nicio pagină nu iese din paleta professional-theme.css.
3. Lizibilitate dark + light — în ambele moduri, textul din toate containerele (carduri, hero, tabele, footer) are contrast suficient și se citește — fără text închis pe fundal închis sau text deschis pe fundal deschis. Atenție specială la carduri și secțiuni cu fundal colorat.
4. Containere consistente — nu rămân containere/secțiuni cu stiluri vechi sau ad-hoc (alt radius, altă umbră, altă culoare de fundal, alt padding) față de componentele standard. Toate cardurile dintr-o pagină arată la fel.
5. Fără artefacte rămase — nicio imagine ruptă (icon „broken image"), nicio imagine/logo rămas din designul vechi care strică tema, niciun bloc de stil inline orfan, niciun buton „Înapoi"/history.back(), niciun element gol sau placeholder vizibil.
6. Comutare temă — toggle-ul dark/light din professional-theme.js funcționează pe pagină și nu lasă elemente „blocate" pe tema anterioară.
7. Responsive — la 390px nav-ul mobil funcționează, nu apare scroll orizontal, cardurile se rearanjează corect.

Tratarea problemelor

Orice abatere găsită se remediază pe loc (aducere la professional-theme.css), apoi se re-verifică pagina. Capturile înainte/după pot fi păstrate ca dovadă. O pagină nu se consideră finalizată până nu trece toate cele 7 puncte în ambele teme.

---

PRD generat pe baza analiza-pagini-website.md. Pentru implementare, urmează ordinea din §7; verificarea vizuală din §11 e obligatorie înainte de deploy (Etapa 5).

---

GSTACK REVIEW REPORT — /autoplan

Pipeline: CEO → Design → Eng (DX skipped — marketing site, no developer surface). Voices: Claude subagent (independent) + Codex. Codex hit its usage limit (reset Jul 18) → all phases run subagent-only. Decisions auto-resolved with the 6 principles; taste/strategic calls surfaced at the final gate.

Phase 1 — CEO Review (Strategy & Scope)

0A. Premise challenge

Premisă (din PRD)	Verdict	Notă
„26→15 pagini = site mai bun" (leanness e obiectivul)	⚠️ Parțial	Leanness e igienă, nu pârghia de conversie B2B. Conversia ERB e blocată de încredere, dovadă socială, captură de lead — nu de curățenia nav. referinte.html (9 clienți reali) e cel mai puternic activ și primește o singură linie.
„Ștergere fizică fără redirect e acceptabilă" (D1)	❌ Infirmată tehnic	Motivul invocat — „rsync nu folosește --delete" — confundă sync-ul de fișiere cu redirect-urile. .htaccess EXISTĂ deja pe server (conține ErrorDocument 404). Un Redirect 301 per URL șters = ~10 linii, gratis, păstrează SEO/backlink.
„Nu avem date de trafic" → analiză pur editorială	⚠️ Risc	Se șterg/merge pagini fără să știm care rankează. Google Search Console (30 min) ar fi infirmat parte din decizii.

0B. Ce există deja (leverage map)

• professional-theme.css / professional-theme.js — sistem de design complet, reutilizat (bun, DRY).
• index.html — referință vizuală (hero/carduri/footer), pattern de copiat.
• 404.html + .htaccess (ErrorDocument 404) — infrastructură de eroare deja prezentă.
• sitemap.xml — listează toate paginile vizate de ștergere/merge (desprenoi, alteservicii, analiza, implementare, roa-situatii-financiare, roa-comenzi-clienti, roa-aplicatii-specifice). Trebuie actualizat post-restructurare, altfel Google crawl-uiește 404-uri.

0C. Dream-state delta

CURENT: 26 pagini, temă inconsistentă, fără captură de lead. → ACEST PLAN: ~15 pagini, temă unitară, CTA consistente. → IDEAL 12 LUNI: mașină de conversie cu formular de cerere ofertă calificat (industrie/dimensiune/modul), 2-3 case studies din referinte, dovadă deasupra fold-ului pe fiecare pagină produs, SEO păstrat. Delta: planul rezolvă consistența vizuală, dar NU captura de lead și NU proof-ul — rămân pentru un PRD ulterior.

0D. Scope decisions

• NU în scope (corect deferat): efactura-generator, paletă culori, CMS/templating.
• NU în scope (lacună strategică — deferat în TODOS): formular de captură lead pe paginile produs; case studies din referinte; benchmark competitiv. Acestea sunt pârghia reală de conversie, dar depășesc un PRD de „restructurare".
• În blast radius, sub 1 zi — auto-aprobat (P2): redirect 301 în .htaccess + actualizare sitemap.xml. Sunt în raza directă a ștergerilor și costă ~30 min.

CEO consensus (single voice — Codex indisponibil)

Dimensiune	Claude	Codex	Consens
1. Premise valide?	⚠️ NU (D1 + leanness)	N/A	Flag (single critical)
2. Problema corectă?	⚠️ Parțial (lipsește lead capture)	N/A	Flag
3. Calibrare scope?	✅ Da pentru restructurare	N/A	OK
4. Alternative explorate?	❌ 301 vs delete nedezbătut	N/A	Flag
5. Riscuri conversie?	⚠️ Fără mecanism lead	N/A	Flag (deferat)
6. Traiectorie 6 luni?	❌ Regret SEO (e-Factura)	N/A	Flag

Constatare critică unică (flag regardless): ștergerea fizică fără 301 (D1) torpilează rankingul long-tail — inclusiv URL-uri pe termeni 2025 fierbinți (e-Factura). Fix near-zero (.htaccess deja există).

Premise gate — rezultat (confirmat de client)

• D1 confirmat (rămâne): ștergere fizică, fără redirect 301. Motivare client: paginile șterse nu au vizitatori și nu conțin nimic valoros → pierderea SEO e irelevantă. Contestația CEO se închide: clientul are datele de utilizare pe care modelul nu le avea.
  • Singura igienă reținută (eng): scoate URL-urile șterse din sitemap.xml (evită erori 404 în Search Console). Cost ~5 min, nelegat de valoarea SEO.
• Nou requirement transversal (confirmat de client — pârghia reală de conversie): restructurarea trebuie să scoată activ în față dovada socială și diferențiatorul, nu doar să reducă paginile:
  1. Dovadă socială: referinte.html (9 clienți reali, vechime mare) ținut vizibil în nav („Cine folosește ROA") + cârlig pe homepage spre el.
  2. Istoric/credibilitate: intro Romfast SRL pe homepage (1991 Constanța, Oracle/Microsoft, 30+ ani) — vezi §5.
  3. Diferențiator-cheie: mesaj explicit „ROA face automatizări și integrări la comandă, spre deosebire de programele de masă pentru mii de utilizatori" — pe homepage (intro) și ca frază pe paginile produs/servicii. Acesta e argumentul de vânzare central, nu leanness-ul.

Acest requirement NU înlocuiește restructurarea — o completează. Lead-capture cu formular calificat + CRM rămâne deferat (TODOS), dar dovada socială + diferențiatorul intră în acest plan.

Phase 2 — Design Review (single voice — Codex indisponibil)

Plan-ul e despre pagini ce nu există încă, deci review pe specificația de design, nu pe pixeli.

#	Finding	Sev	Fix (auto-aprobat)
D-F6	Ancorele cross-page aterizează sub navbar-ul sticky. professional-theme.js leagă smooth-scroll doar pentru # same-page (block:'start', offset 0); linkurile homepage→...#comenzi sunt jump-uri native care ocolesc JS. Nu există scroll-padding-top nicăieri → heading-ul secțiunii rămâne ascuns sub navbar (~90px).	🔴 CRITIC (pt. feature ancore)	html{scroll-padding-top:96px;} în professional-theme.css. O linie, obligatoriu înainte de feature-ul de ancore.
D-F1	servicii.html n-are slot pentru diferențiator/proof — ordinea (De ce ERP→Implementare→Suport) vinde „de ce orice ERP", nu „de ce ROA".	🟠 HIGH	Inserează bloc „De ce ROA (nu un ERP de masă)" după „De ce ERP" + strip proof (2-3 referințe) deasupra CTA-ului final. Aliniat cu requirement-ul client.
D-F7	Dovada socială sub-specificată vs cererea explicită a clientului — planul adaugă doar istoric (1991), fără artefact de proof (logo strip / citate vechime) deasupra fold-ului.	🟠 HIGH	Componentă proof pe homepage (după hero) + pe servicii + pagini-cheie. Tratează cei 9 clienți din referinte ca conținut reutilizabil, nu doar link nav.
D-F3	„hero + cards + CTA" sub-specificat → drift. Nu spune ce clase să refolosească.	🟠 HIGH	Mandatează clasele existente (.feature-card, .module-grid, .professional-card); interzice Tailwind/hex ad-hoc. Cei 4-5 pași = listă numerotată, nu grid neuniform.
D-F4	Dark-mode contrast pe carduri colorate. professional-theme.css remapează doar bg-*-50/anumite griuri în main; orice card nou cu bg-*-100/600/gradient/hex inline se sparge în dark.	🟠 HIGH	Regulă: carduri colorate doar prin utilitare documentate; QA §11 testează fiecare card nou, nu doar cele remapate.
D-F2	Ancorele aterizează mid-page fără „you are here".	🟡 MED	.eyebrow cu numele paginii-părinte + 1 frază intro pe fiecare sub-secțiune gazdă.
D-F8	Nav duplicat în 27 fișiere (desktop+mobile), fără mecanism de paritate.	🟠 HIGH	Vezi Eng-F1 (verificare grep gating).

Design consensus (single voice): ordinea/cleanup-ul sunt solide; cele 3 puncte cu pârghie mare (D-F6 ancore vor eșua vizibil, D-F7 proof = cererea reală a clientului, D-F3/F4 disciplină componente/dark) sunt tratate ca afterthought. D-F6 și D-F7 trebuie rezolvate înainte de implementare.

Phase 3 — Eng Review (single voice — Codex indisponibil)

Verificat în repo.

#	Finding	Sev	Fix (auto-aprobat)
E-F2	Asimetrie deploy/delete. rsync fără --delete; rm pe prod e manual, după deploy. Uitat/parțial → pagini șterse rămân live (zombies orfane), fără eroare.	🔴 CRITIC	Verifier post-deploy: for u in chatbot menu/desprenoi menu/analiza menu/implementare menu/roa-suport-tehnic menu/alteservicii; do curl -so/dev/null -w "%{http_code} $u\n" https://www.romfast.ro/$u.html; done → toate 404. În §10.
E-F3	Integritate ancore. Confirmat: paginile gazdă au 0 anchor-uri id="comenzi/raportare/capacitati". „Crawl linkuri" din §10 NU verifică fragmentul # — doar că .html există. id greșit/lipsă = jump mort silențios.	🔴 CRITIC	Assert per ancoră: grep -q 'id="comenzi"' roa/roa-facturare.html (×3). Inserează id-urile (§7 pași 10/12/13) înainte de relink homepage (pas 14).
E-F1	Propagare nav zero-drift. 27 fișiere × (desktop+mobile) ≈ 50 puncte de editare manuală. „Define once, propagate" e advisory.	🟠 HIGH	Bloc nav delimitat <!--NAV-START-->…<!--NAV-END--> + verifier gating: grep -rlE 'desprenoi|analiza.html|alteservicii|implementare.html|roa-suport-tehnic' --include=*.html . → gol pe fișierele rămase. Include 404.html (are nav).
E-F5	Pierdere conținut la merge. Sursele sunt non-triviale; §3/§3a spun ce să păstrezi dar n-au gate pre-delete. Risc: .exe/Ammyy, pasajul 1991, formulele user-defined dispar silențios la rm.	🟠 HIGH	Înainte de orice delete: checklist de artefacte „load-bearing" (href download, telefon, copy distinctiv) + grep fiecare în destinație. Nu șterge sursa până nu trece grep.
E-F4	sitemap.xml nu se actualizează — listează toate cele 7 URL-uri șterse/merge.	🟠 HIGH	Scoate cele 7 URL-uri + bump lastmod. În §7 Etapa 5 + §10. (Igienă confirmată la premise gate.)
E-F6	Lacune QA §11: lipsesc (a) check fragment ancoră, (b) check prod-404, (c) 404.html+chatbot_maria* absente din lista QA deși au nav, (d) scope crawl nedefinit (include href-urile din nav mobil).	🟡 MED	Adaugă cele 4 în §11.
E-F7	Ordering: gate delete-urile pe E-F5 (verificare conținut).	🟡 MED	Mută verificarea conținut înaintea ștergerilor. (Corecție review: afirmația că roa-imobilizari are buton „Înapoi" e FALSĂ — doar 3 pagini au history.back(): facturare, comenzi-clienti, contracte-clienti, toate deja la rescriere.)

Eng consensus (single voice): logica editorială e corectă; stratul de verificare e veriga slabă — fiecare gate care contează (delete pe prod, fragmente ancoră, sitemap, extracție conținut) e proză ne-scriptată. CRITIC: E-F2, E-F3.

Eng consensus table

Dimensiune	Claude	Codex	Consens
1. Arhitectură (static) sănătoasă?	✅ Da	N/A	OK
2. Acoperire verificare/QA?	❌ Lipsesc gate-uri (ancore/prod/sitemap/conținut)	N/A	Flag
3. Riscuri „performanță" (N/A static)	✅ N/A	N/A	OK
4. „Securitate" (N/A marketing)	✅ N/A	N/A	OK
5. Căi de eroare (deploy/delete)?	❌ Asimetrie rsync, fără verifier	N/A	Flag (CRITIC)
6. Risc deployment gestionabil?	⚠️ Da, cu verifier-ele de mai sus	N/A	Flag

Decision Audit Trail

#	Fază	Decizie	Clasificare	Principiu	Rezultat
1	CEO	D1 redirect 301 vs ștergere fizică	Premise gate (user)	—	Client decide: ștergere fizică, fără redirect (paginile n-au trafic). Se reține doar pruning sitemap.
2	CEO	Lead-capture/proof în scope?	Premise gate (user)	—	Client: dovada socială + diferențiator IN scope; formular+CRM deferat.
3	CEO	Benchmark competitiv	Mechanical	P3	Deferat TODOS — nu blochează restructurarea.
4	Design	scroll-padding-top pt ancore (D-F6)	Mechanical	P1/P5	Auto: adaugă html{scroll-padding-top:96px}. Bug clar.
5	Design	Bloc diferențiator + proof în servicii/homepage (D-F1/F7)	Taste→mandat client	P1	Auto-aprobat: cerut explicit de client. Forma exactă (logo vs citate) = notă la gate.
6	Design	Mandatează clase componente, interzice ad-hoc (D-F3/F4)	Mechanical	P5/P4	Auto: refolosește .feature-card/.module-grid; QA fiecare card nou în dark.
7	Eng	Verifier prod-404 post-deploy (E-F2)	Mechanical	P1	Auto: curl check în §10.
8	Eng	Assert fragmente ancoră + ordinea id-înainte-de-relink (E-F3)	Mechanical	P1	Auto: grep id= ×3 înainte de relink.
9	Eng	Nav block delimitat + grep verifier (E-F1/D-F8)	Mechanical	P5	Auto: gating grep pe 27 fișiere incl. 404.html.
10	Eng	Gate pre-delete pe extracție conținut (E-F5)	Mechanical	P1	Auto: grep artefacte în destinație înainte de rm.
11	Eng	Prune sitemap.xml (E-F4)	Mechanical	P2	Auto: scoate 7 URL-uri (igienă confirmată la gate).
12	Eng	Extinde QA §11 (E-F6)	Mechanical	P1	Auto: +fragment, +prod-404, +404.html/chatbot_maria, +scope crawl.

Cross-phase themes

• Stratul de verificare e veriga slabă — apare în Design (D-F8 nav drift) ȘI Eng (E-F1/F2/F3): planul descrie ce să faci, dar gate-urile (prod-delete, fragmente ancoră, paritate nav, conținut) sunt proză, nu comenzi. Semnal de încredere înalt → scriptează-le.
• Ancore = single point of visible failure — Design (aterizare sub navbar) + Eng (id-uri inexistente) lovesc același feature din unghiuri diferite. Rezolvă ambele înainte de a livra relink-urile homepage.

Implementation Tasks (adăugate de review, peste §7)

• (P1) CSS — html{scroll-padding-top:96px;} în professional-theme.css (D-F6). Înainte de orice relink ancoră.
• (P1) servicii.html + homepage — bloc „De ce ROA (automatizări/integrări la comandă vs software de masă)" + strip dovadă socială (2-3 referințe) deasupra CTA (D-F1/F7, requirement client).
• (P1) Eng gate — verifier nav: grep -rlE 'desprenoi|analiza.html|alteservicii|implementare.html|roa-suport-tehnic' --include=*.html . = gol (incl. 404.html) după propagare (E-F1).
• (P1) Eng gate — assert id="comenzi|raportare|capacitati" în paginile gazdă înainte de relink homepage (E-F3).
• (P1) Eng gate — extracție artefacte load-bearing (.exe/Ammyy href, telefon, pasaj 1991, formule) + grep în destinație înainte de rm sursă (E-F5).
• (P2) Deploy — verifier prod-404 (curl ×6) după rm manual (E-F2); prune 7 URL-uri din sitemap.xml (E-F4).
• (P2) QA — extinde §11: fragment ancoră, prod-404, +404.html/chatbot_maria în listă, scope crawl include nav mobil (E-F6).
• (P2) Design — .eyebrow „parte din X" pe sub-secțiunile ancorate (D-F2); mandatează clase componente, QA dark pe fiecare card nou (D-F3/F4).

Deferat în TODOS

• Formular cerere ofertă calificat (industrie/dimensiune/modul) + integrare CRM/email — pârghia de conversie, dar PRD separat.
• 2-3 case studies scrise din referinte (peste logo strip-ul din acest plan).
• Benchmark competitiv vs ERP-uri de masă (sprijină mesajul diferențiator).

Final gate — decizii client

• Formă dovadă socială: doar citate + vechime (ex. „Client din 2003 · 21 ani"), fără logo-uri — mai sigur legal, construit din conținutul existent referinte.html. Se aplică în blocul proof de pe homepage + servicii + pagini-cheie.
• Status: APROBAT (doar plan) — implementarea NU începe acum; pornește la decizia clientului, urmând ordinea §7 + task-urile de review. Primul pas la implementare: html{scroll-padding-top:96px} înainte de orice relink ancoră.