c39e4bcc9ac844fb736e9b289bc8d4976f6a2736
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
|
9595ad86df |
Merged PR 2374: addeding domain layer extrraction
# Summary This PR introduces a **Case Lifecycle Domain Boundary** to centralize lifecycle decision logic and reduce coupling within the appeals application. The work is **behaviour-preserving** and introduces no intentional changes to business rules, CRM integrations, translations, dashboards, API routes, or user-facing functionality. ## What was added New lifecycle boundary: ```text lib/domain/case-lifecycle/ ``` Key responsibilities extracted: - Specialist process normalization - Appeal type mapping - Specialist process stage override mapping - Stage case-type resolution - Stage catalogue lookup - Closed-case status recognition - Lifecycle stage index resolution - Lifecycle stage status assignment ## Behaviour preserved Characterization tests were added before each extraction to preserve: - Appeal type mapping and aliases - Specialist process handling - Lifecycle stage progression - Closed-case handling - Status assignment (`complete`, `in-progress`, `not-started`) - Existing ROW behaviour - Existing `statuscode` lifecycle semantics Closed-case recognition remains unchanged for: ```text 1000 5 6 846040013 846040059 846040060 ``` ## Documentation Added: ```text lib/domain/case-lifecycle/README.md ``` Documenting: - Boundary ownership - Non-goals - Lifecycle invariants - Known architectural constraints - Future extraction roadmap ## Testing Added lifecycle characterization coverage for: - Stage wrapper behaviour - Specialist process normalization - Appeal type mapping - Specialist process stage mapping - Stage case-type resolution - Stage catalogue lookup - Progress behaviour - Closed-case status handling - Stage index resolution - Stage status assignment ## Validation - Lifecycle characterization tests passed - `npm run lint` passed with no errors ## Out of Scope No changes to: - Stage catalogue ownership - Representation eligibility - Dashboard calculations - CRM/OData queries - API routes - Redux state - EN/CY translations - Event visibility logic ## Risk **Low risk** The refactor was delivered through small, characterization-first slices with no functional changes intended. Related work items: #23527 |