frontend-policylisted

# Frontend Architecture Policy ## Activation Scope - Apply whenever the task involves UI components, client-side state, data fetching, or frontend structure. - Owns component design, reuse thresholds, client-side caching, and optimistic UI. Input validation rules live in validation-policy; global architecture rules live in core-engineering-policy; server-side caching lives in backend-policy. --- ## Frontend Structure - Build reusable UI components instead of page-specific implementations. - Use composition and props for variants instead of duplication. - Avoid one-off components when a reusable abstraction is possible. - Separate presentation, state, and side effects; keep data fetching out of pure render logic. --- ## Component Reuse (Mandatory) - ALWAYS reuse a single base component and drive its behavior with props; NEVER create separate components for variants of the same element. - One component per UI primitive (Input, Button, Modal, Select, ...). Variants and behaviors are configuration of that one component, not new components. - The base component encapsulates all variant logic internally; callers only pass props. ### Input Example (one Input component, behavior via props) - A single Input component must support every input behavior through configuration, not separate components. - The behavior lives INSIDE the Input component, switched by its `type`/`variant` props: - type "password": renders a show/hide eye toggle inside the field. - type "phone": ren