96 lines
2.0 KiB
Markdown
96 lines
2.0 KiB
Markdown
# 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.
|