Business Rules - Web Frontend

This document lists the fundamental business rules of the Web Frontend domain, identified with a unique BR-NNN code. Each rule is technology-independent and describes an invariant constraint on building performant and accessible web interfaces.

---

BR-001 - Every Component has a single responsibility and explicit state

Code: BR-001 Name: A Component encapsulates a cohesive UI responsibility with declared state Description: Every component has a single presentation responsibility and manages an explicit ApplicationState through reactivity. State is not mutated directly but updated in a controlled way, so the rendering always reflects the current state. Motivation: Guarantee rendering predictability and component reusability. Priority: HIGH Actors: Frontend Developer Traceability: glossary "Component", "Reactivity", "Web Component"; state-machines/component-lifecycle.md.

---

BR-002 - Accessibility is a requirement, not an add-on

Code: BR-002 Name: Every interactive Component meets the applicable WCAG criteria Description: Components use semantic HTML, correct ARIA roles and attributes, are keyboard-navigable and maintain adequate contrast. An A11yAnnotation documents the accessibility requirements; a detected violation is a defect to fix. Motivation: Guarantee product use for all users, including assistive technologies. Priority: HIGH Actors: Frontend Developer, UX Designer, Screen Reader Violation: AccessibilityViolationDetected; the component is not considered complete. Traceability: glossary "Accessibility (a11y)", "ARIA", "Progressive Enhancement"; events/domain-events.md.

---

BR-003 - The performance budget is respected

Code: BR-003 Name: Loading respects the Core Web Vitals and the bundle budget Description: Pages respect LCP, CLS and INP thresholds and an AssetBundle size budget. Techniques such as lazy loading, code splitting and tree shaking reduce the payload; exceeding the budget raises an alarm. Motivation: Guarantee a fast and stable experience, crucial for UX and SEO. Priority: HIGH Actors: Frontend Developer, Browser Violation: PerformanceBudgetExceeded; optimisation required before release. Traceability: glossary "Core Web Vitals", "Largest Contentful Paint (LCP)", "Cumulative Layout Shift (CLS)", "Interaction to Next Paint (INP)", "Lazy Loading", "Tree Shaking".

---

BR-004 - Server-side rendering preserves correct hydration

Code: BR-004 Name: SSR and client markup match for a mismatch-free hydration Description: When using Server-Side Rendering, the markup generated on the server must match what the client would produce, so that Hydration does not cause flicker or mismatch. Browser-only APIs are used only after hydration. Motivation: Avoid layout shift, hydration errors and performance regressions. Priority: HIGH Actors: Frontend Developer, Browser Traceability: glossary "Server-Side Rendering (SSR)", "Hydration", "Client-Side Rendering (CSR)", "Critical Rendering Path".

---

Code: BR-005 Name: Every AppRoute handles loading, error and focus consistently Description: Navigation between routes shows explicit loading states, handles errors without breaking the application and restores focus for keyboard/screen-reader users. Routes may be lazy-loaded to reduce the initial bundle. Motivation: Guarantee a smooth and accessible navigation experience. Priority: MEDIUM Actors: Frontend Developer, Screen Reader Traceability: glossary "Single-Page Application (SPA)", "Lazy Loading"; events/domain-events.md event RouteNavigated.

---

BR-006 - Content is indexable and has correct SEO metadata

Code: BR-006 Name: Every page exposes consistent SEOMetadata and indexable content Description: Pages provide title, description, canonical, structured data and, where needed, server-rendered content for indexing. The metadata reflects the page's real content and is unique per route. Motivation: Guarantee search-engine visibility and correct social sharing. Priority: MEDIUM Actors: Frontend Developer, UX Designer Traceability: glossary "Server-Side Rendering (SSR)", "Static Site Generation (SSG)"; BR-004.

---

BR-007 - CSS is predictable and isolated per component

Code: BR-007 Name: A Component's styles do not perturb others Description: Styles are isolated per component (scoping, Shadow DOM or conventions) to avoid leakage and specificity conflicts. Layout uses modern tools (Flexbox, Grid) and custom properties for design consistency. Motivation: Prevent visual regressions from global CSS side effects. Priority: MEDIUM Actors: Frontend Developer, UX Designer Traceability: glossary "Shadow DOM", "Specificity", "CSS Grid", "Flexbox", "CSS Custom Properties", "Design Token".

---

BR-008 - User input is validated and protected against XSS

Code: BR-008 Name: Dynamic content is sanitised before entering the DOM Description: Dynamic data reflected in the interface is encoded for its context and never inserted as untrusted raw HTML. User input is validated client-side as a support, while authoritative validation stays server-side. Motivation: Prevent cross-site scripting (XSS) and interface corruption. Priority: CRITICAL Actors: Frontend Developer, Browser Traceability: glossary "DOM", "Virtual DOM"; OWASP XSS Prevention.

Knowledge Domain Database - Web Frontend