Files
Robert Bond 0de9268255 Merged PR 2242: Refactor: New Appeal flow structural cleanup (Slices 1–8, no behaviour change)
## Summary

This PR merges the completed new-appeal refactor stream (Slices 1–8) into SIPS-Development.

This refactor was executed in controlled slices with regression validation at each step.

## Scope

Structural and readability improvements only:
- XML/form derivation extraction
- payload and file helper extraction
- side-effect facade introduction
- BuildSection and BuildCheckSection decomposition
- BuildCheckRow formatter map refactor
- nested prop boundary cleanup
- start-flow cleanup (CreateCase / AboutYou)

## Behaviour

No intended behavioural changes.

The following were explicitly preserved:
- S78 journey behaviour
- payload shapes and field names/ids
- HASCAS mapping logic
- appellant/agent branching
- validation rules and messages
- redirect/query parameters (`lpa`, `apt`, `id`)
- navigation and side-effect sequencing
- EN/CY output parity

## Validation

Full regression has been performed on:
- start flow (CreateCase / AboutYou)
- save and resume flows
- file upload handling
- check answers rendering
- submit/finalisation sequence
- confirmation flow
- CRM insertion path
- EN/CY parity

Additional checks:
- docsOffline branch behaviour
- completion and partial-save email paths
- negative-path validation scenarios
- lint (warnings baseline unchanged)

## Risk

Low:
- changes are structural only
- no business logic changes
- no contract changes

## Rollback

Safe rollback via reverting this merge commit.

## Notes

This refactor reduces coupling and prepares the new-appeal flow for future appeal-type expansion.

Related work items: #22570, #22576, #22577, #22583, #22586, #22587, #22588, #22590
2026-04-13 13:09:12 +00:00
..

Memory Bank Operating Protocol

Purpose

Capture durable engineering knowledge for PEDW FrontEnd so AI agents and humans make consistent, safe decisions over time.

When to Update

Update memory-bank entries when any of the following occur:

  1. A non-trivial architectural or implementation decision is made.
  2. A recurring pattern is introduced or standardized.
  3. A pitfall/incident/root cause is discovered.
  4. A release introduces meaningful behavior/risk changes.
  5. Open questions block safe delivery.

Who Updates

  • AI agent: must add or amend entries for non-trivial changes completed during a task.
  • Human engineer/reviewer: validates or amends entries during PR review.
  • Tech lead/owner: resolves open questions and marks decisions as accepted/superseded.

Required Metadata (for every new entry)

  • date: YYYY-MM-DD
  • author: agent name or person
  • scope: files/routes/features affected
  • type: decision | pattern | pitfall | change | question | glossary
  • rationale: why this matters
  • impact: user/system/security/i18n/a11y implications
  • status: proposed | accepted | superseded | open | resolved

Entry Quality Rules

  • Keep entries concise and specific to this repository.
  • Link to concrete files/paths where possible.
  • Do not include secrets, tokens, personal data, or sensitive payload examples.
  • If uncertain, record assumptions explicitly and add to open-questions.md.