Files
jobtrackingapp/docs/redesign/FUNCTIONAL_GUARDRAILS.md
T
cesnimda 1bbbd05ed5
CI and Deploy / test (push) Failing after 34s
CI and Deploy / deploy (push) Has been skipped
docs(redesign): record product brief and phased audit handoff
2026-09-09 18:21:48 +02:00

2.8 KiB

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.