cesnimda
112 lines
2.8 KiB
Markdown
112 lines
2.8 KiB
Markdown
# Functional Guardrails
|
|
|
|
## Purpose
|
|
|
|
The redesign must preserve existing functionality while allowing the UX and frontend architecture to change substantially.
|
|
|
|
## Rule 1 — Inventory before redesign
|
|
|
|
Before major implementation work begins, create an explicit inventory of:
|
|
|
|
- routes,
|
|
- pages,
|
|
- dialogs,
|
|
- forms,
|
|
- workflows,
|
|
- API calls,
|
|
- state transitions,
|
|
- authentication flows,
|
|
- localisation behaviour,
|
|
- permissions,
|
|
- user settings,
|
|
- admin capabilities,
|
|
- document workflows,
|
|
- AI actions,
|
|
- mobile/responsive behaviour,
|
|
- tests.
|
|
|
|
## Rule 2 — No silent feature removal
|
|
|
|
A feature discovered during the inventory must not disappear merely because it does not fit the new design.
|
|
|
|
It must be one of:
|
|
|
|
- preserved,
|
|
- relocated,
|
|
- merged into another workflow,
|
|
- intentionally deprecated with an explicit documented decision.
|
|
|
|
## Rule 3 — Protect backend contracts
|
|
|
|
Do not change backend/API contracts purely to make frontend work easier unless there is a clear architectural reason.
|
|
|
|
Any required contract change must be documented and tested.
|
|
|
|
## Rule 4 — Add regression protection
|
|
|
|
Before replacing high-risk UI flows, add or strengthen tests around their functional behaviour.
|
|
|
|
Prioritise:
|
|
|
|
- authentication,
|
|
- registration,
|
|
- Career Profile,
|
|
- job creation/import/edit/status,
|
|
- CV creation/edit/export,
|
|
- document relationships,
|
|
- AI review/apply flow,
|
|
- localisation,
|
|
- permissions/admin boundaries.
|
|
|
|
## Rule 5 — Preserve user data
|
|
|
|
Frontend redesign work must not change the meaning or ownership of stored user data without an explicit migration.
|
|
|
|
## Rule 6 — Career Profile remains canonical
|
|
|
|
Any redesign of CV/application flows must preserve the distinction between:
|
|
|
|
- Career Profile source data,
|
|
- CV-specific overrides,
|
|
- generated output.
|
|
|
|
## Rule 7 — AI cannot bypass review
|
|
|
|
No redesign may introduce an AI action that silently writes career claims into user data.
|
|
|
|
## Rule 8 — Maintain localisation
|
|
|
|
New components and screens must support both English and Norwegian.
|
|
|
|
Do not hard-code user-facing strings in new components if the current architecture supports localisation.
|
|
|
|
## Rule 9 — Maintain access controls
|
|
|
|
Admin-only features must remain permission-gated.
|
|
|
|
User-level dashboard customisation and job/document data must remain tenant/user scoped.
|
|
|
|
## Rule 10 — Visual QA is part of completion
|
|
|
|
A feature is not complete when tests pass but the responsive UI is broken.
|
|
|
|
Each migrated area should be inspected in:
|
|
|
|
- light mode,
|
|
- dark mode,
|
|
- desktop,
|
|
- mobile,
|
|
- English,
|
|
- Norwegian.
|
|
|
|
## Pre-redesign checkpoint
|
|
|
|
Before full redesign implementation:
|
|
|
|
1. Finish current functional work.
|
|
2. Run tests.
|
|
3. Resolve known critical regressions.
|
|
4. Commit a stable baseline.
|
|
5. Create a tag or branch checkpoint such as `pre-ui-redesign`.
|
|
6. Create a redesign branch such as `feature/ui-redesign`.
|