Regole di Business - Web Frontend

Questo documento elenca le regole di business fondamentali del dominio Web Frontend, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sulla costruzione di interfacce web performanti e accessibili.

---

BR-001 - Ogni Componente ha responsabilità singola e stato esplicito

Codice: BR-001 Nome: Un Componente incapsula una responsabilità UI coesa con stato dichiarato Descrizione: Ogni componente ha un'unica responsabilità di presentazione e gestisce uno StatoApplicativo esplicito tramite reattività. Lo stato non è mutato direttamente ma aggiornato in modo controllato, così che il rendering rifletta sempre lo stato corrente. Motivazione: Garantire prevedibilità del rendering e riusabilità dei componenti. Priorità: ALTA Attori: Frontend Developer Tracciabilità: glossary "Componente", "Reattività", "Web Component"; state-machines/componente-lifecycle.md.

---

BR-002 - L'accessibilità è un requisito, non un'aggiunta

Codice: BR-002 Nome: Ogni Componente interattivo soddisfa i criteri WCAG applicabili Descrizione: I componenti usano HTML semantico, ruoli e attributi ARIA corretti, sono navigabili da tastiera e mantengono un contrasto adeguato. Una A11yAnnotation documenta i requisiti di accessibilità; una violazione rilevata è un difetto da correggere. Motivazione: Garantire l'uso del prodotto a tutti gli utenti, incluse le tecnologie assistive. Priorità: ALTA Attori: Frontend Developer, UX Designer, Screen Reader Violazione: AccessibilityViolationRilevata; il componente non è considerato completo. Tracciabilità: glossary "Accessibilità (a11y)", "ARIA", "Progressive Enhancement"; events/domain-events.md.

---

BR-003 - Il budget di performance è rispettato

Codice: BR-003 Nome: Il caricamento rispetta i Core Web Vitals e il budget di bundle Descrizione: Le pagine rispettano soglie di LCP, CLS e INP e un budget di dimensione dell'AssetBundle. Tecniche come lazy loading, code splitting e tree shaking riducono il payload; il superamento del budget genera un allarme. Motivazione: Garantire un'esperienza veloce e stabile, cruciale per UX e SEO. Priorità: ALTA Attori: Frontend Developer, Browser Violazione: PerformanceBudgetSuperato; ottimizzazione richiesta prima del rilascio. Tracciabilità: glossary "Core Web Vitals", "Largest Contentful Paint (LCP)", "Cumulative Layout Shift (CLS)", "Interaction to Next Paint (INP)", "Lazy Loading", "Tree Shaking".

---

BR-004 - Il rendering server-side preserva l'idratazione corretta

Codice: BR-004 Nome: Il markup SSR e quello client coincidono per un'idratazione senza mismatch Descrizione: Quando si usa Server-Side Rendering, il markup generato sul server deve coincidere con quello che il client produrrebbe, così che l'Hydration non causi flicker o mismatch. Le API solo-browser sono usate solo dopo l'idratazione. Motivazione: Evitare layout shift, errori di idratazione e regressioni di performance. Priorità: ALTA Attori: Frontend Developer, Browser Tracciabilità: glossary "Server-Side Rendering (SSR)", "Hydration", "Client-Side Rendering (CSR)", "Critical Rendering Path".

---

BR-005 - La navigazione tra route è prevedibile e accessibile

Codice: BR-005 Nome: Ogni RouteAngular gestisce caricamento, errore e focus in modo coerente Descrizione: La navigazione tra route mostra stati di caricamento espliciti, gestisce gli errori senza rompere l'applicazione e ripristina il focus per gli utenti da tastiera/screen reader. Le route possono essere lazy-loaded per ridurre il bundle iniziale. Motivazione: Garantire un'esperienza di navigazione fluida e accessibile. Priorità: MEDIA Attori: Frontend Developer, Screen Reader Tracciabilità: glossary "Single-Page Application (SPA)", "Lazy Loading"; events/domain-events.md evento RouteNavigata.

---

BR-006 - Il contenuto è indicizzabile e ha metadati SEO corretti

Codice: BR-006 Nome: Ogni pagina espone SEOMetadata coerenti e contenuto indicizzabile Descrizione: Le pagine forniscono title, description, canonical, dati strutturati e, dove serve, contenuto renderizzato lato server per l'indicizzazione. I metadati riflettono il contenuto reale della pagina e sono univoci per route. Motivazione: Garantire visibilità nei motori di ricerca e corretta condivisione social. Priorità: MEDIA Attori: Frontend Developer, UX Designer Tracciabilità: glossary "Server-Side Rendering (SSR)", "Static Site Generation (SSG)"; BR-004.

---

BR-007 - Il CSS è prevedibile e isolato per componente

Codice: BR-007 Nome: Gli stili di un Componente non perturbano gli altri Descrizione: Gli stili sono isolati per componente (scoping, Shadow DOM o convenzioni) per evitare leakage e conflitti di specificità. Il layout usa strumenti moderni (Flexbox, Grid) e proprietà personalizzate per la coerenza del design. Motivazione: Prevenire regressioni visive da effetti collaterali del CSS globale. Priorità: MEDIA Attori: Frontend Developer, UX Designer Tracciabilità: glossary "Shadow DOM", "Specificità", "CSS Grid", "Flexbox", "Proprietà personalizzate CSS", "Design Token".

---

BR-008 - L'input dell'utente è validato e protetto da XSS

Codice: BR-008 Nome: Il contenuto dinamico è sanificato prima di entrare nel DOM Descrizione: I dati dinamici riflessi nell'interfaccia sono codificati per il contesto e mai inseriti come HTML grezzo non fidato. L'input dell'utente è validato lato client come supporto, mentre la validazione autorevole resta lato server. Motivazione: Prevenire il cross-site scripting (XSS) e la corruzione dell'interfaccia. Priorità: CRITICA Attori: Frontend Developer, Browser Tracciabilità: glossary "DOM", "Virtual DOM"; OWASP XSS Prevention.