rules-frontendlisted

## Positioning This is the **frontend counterpart** to `rules-architecture`: a terse measuring stick, not a tutorial. It states *what* a Jardis frontend must hold true across **every** UI stack (the same five concerns recur whatever the framework). The concrete stack — its idioms, state-update primitives, router, test runner — is **not** here; it arrives via the review assignment. Argue a finding against these rules **plus** the injected stack, never from framework lore. Mirrors the backend stance: behaviour and boundaries are constitutional; the implementation vehicle is replaceable. ## Scope Applies to any frontend built on or alongside Jardis — the internal Builder UI and customer apps alike. A reviewer measures a **plan** or a **component** against §1–§5; §6 points outward. The five concerns are the whole surface — if a finding fits none of them, question whether it is a frontend-architecture finding at all. ### 1. Component boundaries - One component = **one responsibility**. "And" in its description → split. - **Presentational vs. container** kept distinct: view components render props + emit events; data-fetching, navigation, and domain logic live above them, not inside a leaf. - **Data flows down, events flow up.** No component reaches into a parent's or sibling's internals; no shared mutable global as a back-channel. - **No business/domain logic in the view layer.** A presentational component must be reusable in isolation, with no hidden dependency on app state.