3efaafdb72e2f4252fabad85c2d30a9ba6151e76
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Robert Bond
|
c39e4bcc9a |
Merged PR 2375: update representation policy
## Summary Introduces a new `representation-policy` domain boundary and incrementally extracts low-risk representation entry policy logic while preserving existing behaviour. This PR intentionally stops before extracting ROW and Advert entry rules because characterization uncovered behavioural differences between consumers that require a separate business decision. ## What Changed Added: ```text lib/domain/representation-policy/ ``` Including: - `resolveRepresentationWindow(...)` - `isRepresentationWindowOpen(...)` - `isRepresentationWindowClosed(...)` - `canShowRepresentationButtonForAppealType(...)` - `canStartHouseholderRepresentation(...)` - `canStartCpoRepresentation(...)` Updated consumers: ```text components/case/summary/utils/representationEntry.js components/search/repsonresults.js ``` ## Extracted Behaviour ### Representation Window Calculation Centralised shared representation window logic and adopted it in both consumers. ### Appeal Type Entry Gating Centralised excluded appeal-type logic while preserving existing behaviour. ### Householder Rule Centralised Householder (`846040004`) entry rule. Preserved behaviour: ```text Householder representations can only be started by LPAs. ``` ### CPO Rule Centralised CPO (`846040019`) entry rule. Preserved behaviour using: ```text pinswg_startdate pinswg_statementduedate ``` No fallback date broadening introduced. ## Characterization Added ### ROW (`846040015`) Documented: - hearing vs non-hearing behaviour - specialist-process field behaviour - date gating - appeal-type coercion behaviour ### Advert (`846040018`) Documented: - LPA/non-LPA behaviour - specialist-process behaviour - appeal-type coercion behaviour ## Important Findings ### ROW Divergence Summary and Search consumers currently behave differently when only: ```text pinswg_speacialistcaseprocess ``` exists. ### Advert Divergence Summary and Search consumers currently use different specialist-process resolution paths. ### CRM Compatibility Both fields remain in production use and must be preserved: ```text pinswg_specialistcaseprocess pinswg_speacialistcaseprocess ``` ## Documentation Added: ```text lib/domain/representation-policy/README.md ``` Documenting: - ownership - non-goals - CRM compatibility requirements - ROW divergence - Advert divergence - future extraction constraints ## Validation Executed during the slice series: ```bash node tests/phase22/representation-window.test.cjs node tests/phase22/representation-appeal-type-entry-gating.test.cjs node tests/phase22/representation-householder-entry-rule.test.cjs node tests/phase22/representation-cpo-entry-rule.test.cjs node tests/phase22/representation-row-entry-rule.test.cjs node tests/phase22/representation-advert-entry-rule.test.cjs npm run lint ``` All passing. ## Out of Scope No changes to: - submission/finalisation - uploads - dashboards - CRM/OData queries - API routes - Redux state - translations - blocked-message rendering - CTA l... |
||
|
Robert Bond
|
37a81522d5 |
Merged PR 2260: refactor(representations): complete slice-based refactor of representations flow
## Representations Refactor — Behaviour-Preserving Structural Improvements This PR delivers a full refactor of the representations flow, improving structure, readability, and maintainability while preserving all existing behaviour. The work was completed using a controlled, slice-based approach with strict guardrails and regression validation at each step. No changes have been made to user journeys, payloads, routing, or EN/CY behaviour. The result is a cleaner, more maintainable codebase with reduced coupling and clearer separation of concerns, ready for future enhancements without increased risk. --- ## What Was Done The refactor was delivered incrementally across the following slices: - **R1** — Representation entry logic extraction - **R2** — Page loader separation (SSR/data orchestration) - **R3** — Journey step resolution extraction - **R4** — Flow shell decomposition - **R5** — Representation elements normalisation - **R6** — Data/service layer cleanup - **R7** — Summary rendering proof slice - **R8** — Submission/finalisation boundary isolation - **R9** — Summary rollout (Batch 1) Each slice: - was isolated to a single concern - followed strict guardrails - was validated before merge Full detail is available in: `context/representations-refactor-tracker.md` --- ## Key Improvements - Reduced coupling across the representations journey - Separated data loading, orchestration, and rendering concerns - Simplified complex conditional logic into testable helpers - Standardised summary rendering using shared primitives (`SummaryCard`, `SummaryRow`) - Isolated submission/finalisation sequencing into explicit boundaries - Improved overall readability and maintainability --- ## Behaviour Preservation This refactor does **not** change: - User journeys (APP / IP / Agent / LPA) - Route and query behaviour - Payload contracts and API interactions - Redux state shape and usage - Validation rules and messaging - EN/CY behaviour - File upload / PDF / email sequencing - Linked-case logic All changes are structural only. --- ## Validation ### Automated - `npm run lint` — passed (warnings only, no new errors) - `npm run test:reps` — passed (7/7) ### Manual Validated end-to-end across: - APP - IP - Agent - LPA Including: - representation creation - editing/resuming representations - submission flow - confirmation/completion behaviour - summary rendering across case types - EN/CY parity --- ## Risk Management The refactor targeted several high-risk areas: - Case summary entry logic - Representation submission/finalisation sequencing - Dual-mode entry (new vs existing representation) Risk was controlled through: - small, incremental slices - one branch per slice - regression validation per slice - strict behaviour-preservation guardrails - controlled rollout for summary rendering changes --- ## Reviewer Guidance Suggested areas to focus on: - End-to-end representation journey (create → submit → complete) - S... |