# Default Rules (Reference Only) ## Important This file is **not the active rule set for this refactor branch**. Active working rules are defined in: - `.clinerules/refactor-branch-rules.md` - `context/refactor-branch-charter.md` - `context/newappeal-refactor-guardrails.md` Do not load this file by default. --- ## Purpose This file provides general repository-wide guidance and may be referenced when needed for broader context. --- ## Repository Mission Deliver safe, accessible, bilingual (EN/CY), and reliable public-service functionality without regressing core journeys. --- ## General Priorities 1. Safety and security of user data 2. Stability of public-facing journeys 3. Accessibility and bilingual parity 4. Maintainability of code 5. Controlled, safe delivery --- ## General Coding Guidance - Follow existing repo patterns - Keep page-level logic thin - Move reusable logic into `components/`, `actions/`, or `lib/` - Avoid broad refactors in feature or bugfix work - Prefer small, focused changes --- ## Architecture Guardrails (General) - Do not bypass auth/session handling - Do not weaken security controls - Preserve relay request integrity - Maintain EN/CY route parity - Keep Redux hydration/persistence stable --- ## Validation Expectations (General) - linting must pass - user-facing changes must be verified - accessibility and EN/CY checks required - sensitive flows require negative-path checks --- ## When To Use This File Only reference this file when: - broader repository rules are required - behaviour conflicts are unclear - no branch-specific guidance exists --- ## Summary This file is background guidance only. For this refactor branch: - follow branch-specific rules first - prioritise behaviour preservation - keep context minimal and focused ## Branching Guidance (Reference) Branching depends on work type: - BAU work typically branches from `SIPS-Development` - refactor-stream work for the new appeal flow uses `refactor` as the base branch Follow branch-specific rules first.