diff --git a/context/api-grouping-adoption-roadmap.md b/context/api-grouping-adoption-roadmap.md
index 41f5043d..c121089b 100644
--- a/context/api-grouping-adoption-roadmap.md
+++ b/context/api-grouping-adoption-roadmap.md
@@ -419,6 +419,32 @@ UI journey
- legacy endpoint handlers remain canonical
- no route migration, deletion, contract change, auth change, storage change, or behaviour change has occurred
+#### Workflow boundary assessment checkpoint
+
+- A bounded follow-on assessment of the remaining major API families established that the current additive façade pattern has a natural stop point.
+- Main conclusion:
+
+> The current façade rollout pattern is proven for bounded read-style journey families, but it should not be stretched across workflow/orchestration-heavy areas without a different design.
+
+- Classification outcome from the representative family assessment:
+ - **B — Possible façade candidate with caution**
+ - account / registration / personal-details family, but only for a narrowly bounded future read-support slice
+ - **C — Workflow / orchestration boundary**
+ - notifications / email
+ - appeals / drafts / finalisation
+ - representations / drafts / finalisation
+ - **D — Leave unchanged for now**
+ - storage / blob / file operations
+ - auth / session
+ - admin / reporting
+- What this means for rollout discipline:
+ - the obvious low-risk read-family slices are now largely exhausted
+ - remaining complex areas are complex because they cross identity, storage, queue, Notify, PDF, or finalisation boundaries
+ - those areas do not meet the original checkpoint criteria for the same read-style façade rollout pattern
+- Recommended next step after the completed façade baseline:
+ - prefer a workflow/orchestration design assessment rather than another broad façade slice
+ - if one more implementation slice is ever chosen first, the only reasonable candidate is a **narrow account read-support cautious slice** that excludes create/update/bootstrap-critical behavior
+
---
### Stage 3 — Documentation Maturity
diff --git a/context/api-grouping-workflow-boundary-assessment.md b/context/api-grouping-workflow-boundary-assessment.md
new file mode 100644
index 00000000..7259afaf
--- /dev/null
+++ b/context/api-grouping-workflow-boundary-assessment.md
@@ -0,0 +1,589 @@
+# API Grouping Workflow Boundary Assessment
+
+## Purpose
+
+This document defines where the current **additive read-style façade pattern** naturally stops.
+
+It is a bounded architecture assessment only.
+
+It does **not** recommend implementation, migration, route movement, route renaming, route deletion, service URL changes, or behaviour change.
+
+---
+
+## Required Context Read
+
+The following files were read before drafting this assessment:
+
+- `context/api-grouping-plan.md`
+- `context/api-grouping-adoption-roadmap.md`
+- `context/api-route-map.md`
+- `context/journey-architecture-map.md`
+- `context/portal-api-platform-assessment.md`
+- `context/architecture.md`
+- `memory-bank/change-log.md`
+
+---
+
+## Completed Façade Baseline
+
+Completed additive façade slices now provide a bounded evidence base for what the current pattern does well:
+
+- **Subscriptions / Watched Cases**
+- **Documents / Published Document Metadata**
+- **Public Search Results**
+- **Case Details Read Journey**
+- **My Portal Dashboard Reads**
+
+What these completed slices prove:
+
+1. The pattern is strongest when the area is **read-only**.
+2. It works best when a **clear owning service layer** already exists.
+3. It is lowest risk when a grouped route can **delegate trivially** to a canonical legacy handler.
+4. It is safest when service adoption can happen **without frontend refactor**.
+5. It weakens materially once the route family becomes:
+ - identity-coupled
+ - storage-owned
+ - side-effect-heavy
+ - orchestration-heavy
+ - cross-integration by design
+
+---
+
+## Classification Model
+
+### A — Safe façade candidate
+
+Read-only, clear service layer, low orchestration, stable contract, and additive delegation/adoption would be low risk.
+
+### B — Possible façade candidate with caution
+
+Clear journey ownership exists, but the family also touches identity, account state, sensitive reads, or adjacent state assumptions.
+
+### C — Workflow / orchestration boundary
+
+Crosses storage, queue, CRM, Notify, PDF generation, finalisation, or other multi-step side effects.
+
+The current read-style façade pattern should **not** be applied without a separate workflow-specific design.
+
+### D — Leave unchanged for now
+
+The area is already reasonably coherent, has unclear adoption value, is integration/platform-owned rather than journey-owned, or does not meet the rollout checkpoint criteria.
+
+---
+
+## Family Assessment
+
+This assessment uses **representative route-family inspection only**.
+
+It is **not** a full route inventory.
+
+### 1. Account / Registration / Personal Details
+
+Representative evidence reviewed:
+
+- `actions/services/accountDirectService.js`
+- `pages/api/endpoint/createaccount_api.js`
+- `pages/api/endpoint/getpersonalaccount_api.js`
+- `pages/api/endpoint/updateaccount_api.js`
+- `pages/api/endpoint/getportallogin_api.js`
+- `pages/api/endpoint/getpreferredlanguage_api.js`
+
+#### Journey owner
+
+- account registration
+- personal details / account management
+- post-sign-in account bootstrap
+
+#### Read-only or mutation/orchestration?
+
+- mixed
+- includes read-only lookup routes (`getpersonalaccount_api`, `getpreferredlanguage_api`, `getportallogin_api`)
+- also includes account creation and update mutations (`createaccount_api`, `updateaccount_api`)
+
+#### Clear service layer?
+
+- yes
+- `actions/services/accountDirectService.js`
+
+#### Integration boundaries crossed?
+
+- yes
+- CRM + NextAuth/session bootstrap expectations
+- signed hash on portal login path
+
+#### Would façade delegation be trivial?
+
+- for some reads, yes
+- for the family as a whole, not safely enough
+
+#### Would service adoption be safe without frontend refactor?
+
+- probably for selected reads
+- not for the whole family without careful identity/bootstrap scoping
+
+#### Rollout checkpoint fit?
+
+- only partially
+- the family fails the clean read-only boundary because account reads are tightly coupled to sign-in/bootstrap and account state
+
+#### Classification
+
+- **B — Possible façade candidate with caution**
+
+#### Assessment conclusion
+
+Account is the strongest remaining **cautious** candidate, but only as a narrowly bounded future read-support slice.
+
+The obvious danger is treating identity/bootstrap support routes as if they were ordinary journey reads.
+
+Any future slice here would need to separate:
+
+- safe lookup-style reads
+- from create/update/bootstrap-critical behavior
+
+---
+
+### 2. Notifications / Email
+
+Representative evidence reviewed:
+
+- `actions/services/notifyDirectService.js`
+- `pages/api/email/notify.js`
+- `pages/api/email/getall.js`
+
+#### Journey owner
+
+- auth verification email
+- watchlist/business notifications
+- completion-triggered communications
+
+#### Read-only or mutation/orchestration?
+
+- not read-only
+- outbound send and aggregation/orchestration focused
+
+#### Clear service layer?
+
+- partial
+- a service exists for direct sends, but route family ownership is broader than one thin service call
+
+#### Integration boundaries crossed?
+
+- yes
+- GOV.UK Notify + CRM + document/event/watchlist aggregation
+
+#### Would façade delegation be trivial?
+
+- only for thin `notify.js`
+- not for the family meaningfully
+
+#### Would service adoption be safe without frontend refactor?
+
+- not as a family-level rollout pattern
+
+#### Rollout checkpoint fit?
+
+- no
+- family is orchestration-heavy and cross-cutting
+
+#### Classification
+
+- **C — Workflow / orchestration boundary**
+
+#### Assessment conclusion
+
+Email is the clearest example of where the read-style façade pattern stops being the right tool.
+
+Even where one thin send route exists, the family itself is dominated by orchestration and side effects.
+
+---
+
+### 3. Appeals / Drafts / Finalisation
+
+Representative evidence reviewed:
+
+- `actions/services/documentDirectService.js`
+- `pages/api/file/createappealcompletemessage_api.js`
+- `pages/api/endpoint/createcase_api.js`
+
+#### Journey owner
+
+- draft appeal creation
+- save/resume
+- upload
+- check answers
+- finalisation / submission
+
+#### Read-only or mutation/orchestration?
+
+- predominantly mutation/orchestration
+
+#### Clear service layer?
+
+- multiple services/helpers participate
+- `documentDirectService`, `caseDirectService`, `accountDirectService`, `azurestorage`
+
+#### Integration boundaries crossed?
+
+- yes
+- Azure Storage + CRM + queue/finalisation + account side effects
+
+#### Would façade delegation be trivial?
+
+- not in any useful way for the actual workflow boundary
+
+#### Would service adoption be safe without frontend refactor?
+
+- no
+- service calls are only one part of a broader workflow handoff
+
+#### Rollout checkpoint fit?
+
+- no
+- orchestration-heavy and storage-owned
+
+#### Classification
+
+- **C — Workflow / orchestration boundary**
+
+#### Assessment conclusion
+
+Appeals are beyond the natural stop point for the current façade pattern.
+
+If future work is desired here, it needs a **workflow/orchestration-specific design**, not another read-style façade slice.
+
+---
+
+### 4. Representations / Drafts / Finalisation
+
+Representative evidence reviewed:
+
+- `actions/services/portalDirectService.js`
+- `pages/api/endpoint/getrepresentations_api.js`
+- `pages/api/file/createrepcompletemessage_api.js`
+- `pages/api/file/createrepinvolvement_api.js`
+
+#### Journey owner
+
+- public/case representation reads
+- draft representation editing
+- representation submission/finalisation
+
+#### Read-only or mutation/orchestration?
+
+- mixed, but dominated by workflow concerns once the full journey is considered
+
+#### Clear service layer?
+
+- partial
+- portal/document/notify/storage helpers all participate depending on the journey segment
+
+#### Integration boundaries crossed?
+
+- yes
+- CRM + Azure Storage + queue/finalisation + Notify
+
+#### Would façade delegation be trivial?
+
+- only for isolated read endpoints such as `getrepresentations_api`
+- not for the family as a whole
+
+#### Would service adoption be safe without frontend refactor?
+
+- maybe for isolated reads
+- not for the broader draft/finalisation family
+
+#### Rollout checkpoint fit?
+
+- not for the whole family
+- only limited read-only sub-slices would fit
+
+#### Classification
+
+- **C — Workflow / orchestration boundary**
+
+#### Assessment conclusion
+
+Representations still contain future read-only candidate edges, but the family requested here is primarily a workflow boundary once drafts, involvement, and completion are included.
+
+That means the current façade pattern should stop here and not be stretched across the whole area.
+
+---
+
+### 5. Storage / Blob / File Operations
+
+Representative evidence reviewed:
+
+- `actions/services/documentDirectService.js`
+- `pages/api/file/uploadsinglefile.js`
+- `pages/api/file/getprogressobjblob.js`
+
+#### Journey owner
+
+- no single journey owner
+- this is primarily shared integration/platform support for drafts and uploads
+
+#### Read-only or mutation/orchestration?
+
+- mixed
+- read, upload, delete, download, progress, container setup
+
+#### Clear service layer?
+
+- yes technically, through `documentDirectService`
+- but ownership is integration-shaped, not journey-shaped
+
+#### Integration boundaries crossed?
+
+- primarily Azure Storage
+- protected by signed hash/integrity semantics
+
+#### Would façade delegation be trivial?
+
+- possible technically
+- low architectural value for the current grouping goal
+
+#### Would service adoption be safe without frontend refactor?
+
+- in some cases, yes
+- but it would not meaningfully improve journey ownership clarity
+
+#### Rollout checkpoint fit?
+
+- no
+- this family is not a clean journey-owned read family and includes uploads/deletes plus integrity-sensitive support behavior
+
+#### Classification
+
+- **D — Leave unchanged for now**
+
+#### Assessment conclusion
+
+The storage/file family is exactly the kind of area that should **not** be forced into the same pattern just because wrappers are technically easy.
+
+It is better treated as an integration-owned support boundary unless a different storage-specific design is approved later.
+
+---
+
+### 6. Auth / Session
+
+Representative evidence reviewed:
+
+- `pages/api/auth/[...nextauth].js`
+
+#### Journey owner
+
+- sign-in
+- verify request
+- callback/redirect
+- locale-aware auth bootstrap
+
+#### Read-only or mutation/orchestration?
+
+- orchestration/support
+
+#### Clear service layer?
+
+- not in the same sense as the completed façade slices
+
+#### Integration boundaries crossed?
+
+- yes
+- NextAuth + Notify + CRM locale/bootstrap behavior
+
+#### Would façade delegation be trivial?
+
+- not usefully
+
+#### Would service adoption be safe without frontend refactor?
+
+- not relevant to the current pattern
+
+#### Rollout checkpoint fit?
+
+- no
+- explicitly fails the auth/session-critical guardrail
+
+#### Classification
+
+- **D — Leave unchanged for now**
+
+#### Assessment conclusion
+
+Auth/session is beyond the current façade rollout boundary.
+
+This area should remain unchanged unless there is a separate auth-specific design or hardening programme.
+
+---
+
+### 7. Admin / Reporting
+
+Representative evidence reviewed:
+
+- `actions/services/adminDirectService.js`
+- `pages/api/admin/getnewappeals_api.js`
+
+#### Journey owner
+
+- admin/reporting/internal operational views
+
+#### Read-only or mutation/orchestration?
+
+- mostly read-only
+
+#### Clear service layer?
+
+- yes
+- `actions/services/adminDirectService.js`
+
+#### Integration boundaries crossed?
+
+- CRM relay only in the reviewed sample
+
+#### Would façade delegation be trivial?
+
+- yes technically
+
+#### Would service adoption be safe without frontend refactor?
+
+- likely yes
+
+#### Rollout checkpoint fit?
+
+- only partially
+- the main issue is not technical unsuitability but **unclear value**, because `pages/api/admin/*` is already one of the more coherent existing areas
+
+#### Classification
+
+- **D — Leave unchanged for now**
+
+#### Assessment conclusion
+
+Admin is coherent enough already that another façade layer is not currently justified.
+
+This is a good example of an area that should stay unchanged unless a concrete maintainer pain justifies more structure.
+
+---
+
+## Classification Summary
+
+| Family | Classification | Why |
+| ----------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------- |
+| Account / Registration / Personal Details | **B** | clear service layer, but tightly coupled to identity/bootstrap and includes create/update state changes |
+| Notifications / Email | **C** | cross-cutting send/orchestration family with Notify + CRM aggregation |
+| Appeals / Drafts / Finalisation | **C** | storage + CRM + queue + completion side effects |
+| Representations / Drafts / Finalisation | **C** | contains read edges, but family is dominated by draft/finalisation/orchestration concerns |
+| Storage / Blob / File Operations | **D** | integration-owned support area, not a clean journey-owned façade target |
+| Auth / Session | **D** | platform-critical cross-cutting concern; fails current rollout guardrails |
+| Admin / Reporting | **D** | already coherent enough; unclear value in adding façade grouping now |
+
+---
+
+## Façade Continuation Candidates
+
+Only the following area remains a plausible continuation of the **existing** additive façade pattern:
+
+### 1. Account read-support slice only, with caution
+
+Potentially suitable only if narrowly bounded to read-support routes such as:
+
+- `getpersonalaccount_api.js`
+- `getpreferredlanguage_api.js`
+- possibly `getportallogin_api.js` if treated explicitly as bootstrap support rather than generic account read
+
+Why this is not A:
+
+- identity/bootstrap coupling is strong
+- route sensitivity is higher than completed public/myportal/search/case/documents reads
+- mutations in the same family (`createaccount_api`, `updateaccount_api`) must remain out of scope
+
+No other remaining family reviewed here is a stronger continuation candidate than this.
+
+---
+
+## Workflow / Orchestration Candidates
+
+These areas need a **different pattern** if future work is ever approved:
+
+### 1. Notifications / Email
+
+- thin send routes and aggregation/batch routes should not be treated as one read-style façade family
+
+### 2. Appeals / Drafts / Finalisation
+
+- requires workflow-aware design across storage, CRM, queue, and completion sequencing
+
+### 3. Representations / Drafts / Finalisation
+
+- requires workflow-aware design across storage, CRM, Notify, and completion/involvement sequencing
+
+These are the clearest boundaries where the current façade rollout should stop.
+
+---
+
+## Leave-Unchanged Areas
+
+The following areas should remain unchanged for now:
+
+### 1. Storage / Blob / File Operations
+
+- integration-owned support boundary
+- better kept distinct from journey-owned read façades
+
+### 2. Auth / Session
+
+- platform-critical and cross-cutting
+- should not be folded into the current façade rollout model
+
+### 3. Admin / Reporting
+
+- already relatively coherent
+- insufficient evidence that another façade layer would improve maintainability enough to justify it
+
+---
+
+## Recommendation
+
+The next step should **not** be another broad façade slice.
+
+The strongest recommendation is:
+
+### Prefer a workflow / orchestration design assessment next
+
+Reason:
+
+- the completed façade slices have now covered the obvious low-risk read families
+- the remaining difficult areas are difficult for structural reasons, not because they have not yet been wrapped
+- stretching the current pattern into workflow-heavy areas would weaken the rollout discipline established by the checkpoint
+
+### If one more implementation slice is desired before pausing
+
+The only defensible candidate is:
+
+- a **narrow account read-support cautious slice**
+
+and only if it is explicitly bounded to safe read-support routes and excludes create/update/bootstrap-critical behavior.
+
+### Overall recommendation
+
+- **Primary recommendation:** workflow/orchestration design pattern assessment
+- **Secondary fallback:** one cautious account read-support façade slice only
+- **Do not recommend:** direct continuation into appeals, representations, notifications, auth, or storage families using the current read-style façade pattern
+
+---
+
+## Validation Performed
+
+Documentation-only assessment.
+
+Performed:
+
+- read the required context files
+- direct representative inspection of remaining API families and owning services only
+- no implementation changes proposed from the evidence itself
+
+Not performed:
+
+- no full route inventory
+- no runtime analysis
+- no lint/tests required for the assessment itself
diff --git a/memory-bank/change-log.md b/memory-bank/change-log.md
index e953b3b4..ad413172 100644
--- a/memory-bank/change-log.md
+++ b/memory-bank/change-log.md
@@ -20,14 +20,71 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-SEARCH-VERTICAL-SLICE: active public search results grouping and service adoption
+### CL-2026-06-25-API-GROUPING-WORKFLOW-BOUNDARY-ASSESSMENT: classify where the additive façade pattern should stop
+
+date: 2026-06-25
+author: Cline
+scope: `context/api-grouping-workflow-boundary-assessment.md`, `context/api-grouping-adoption-roadmap.md`, `memory-bank/change-log.md`
+type: change
+rationale: After completing the main additive façade read slices, perform a bounded architecture assessment to determine which remaining API families are still suitable for the current façade pattern, which require extra caution, which are workflow/orchestration boundaries, and which should be left unchanged for now.
+impact: Documentation/context only; clarifies the natural stop point of the current façade rollout pattern and guides future planning without any runtime, routing, auth/session, CRM, storage, queue, notification, or behaviour change.
+status: completed
+
+Summary:
+
+- Confirmed the required context was read before the assessment:
+ - `context/api-grouping-plan.md`
+ - `context/api-grouping-adoption-roadmap.md`
+ - `context/api-route-map.md`
+ - `context/journey-architecture-map.md`
+ - `context/portal-api-platform-assessment.md`
+ - `context/architecture.md`
+ - `memory-bank/change-log.md`
+- Created new assessment document:
+ - `context/api-grouping-workflow-boundary-assessment.md`
+- Used representative family inspection only, not a full inventory.
+- Reviewed representative service/routes across the remaining major families, including:
+ - account / registration / personal details
+ - notifications / email
+ - appeals / drafts / finalisation
+ - representations / drafts / finalisation
+ - storage / blob / file operations
+ - auth / session
+ - admin / reporting
+- Recorded the A/B/C/D classification model:
+ - A — safe façade candidate
+ - B — possible façade candidate with caution
+ - C — workflow / orchestration boundary
+ - D — leave unchanged for now
+- Main findings:
+ - the completed façade slices prove the current pattern is strongest for bounded read-only journey families with clear service ownership and trivial delegation
+ - the strongest remaining cautious candidate is account read-support only, because the family has a clear service layer but is tightly coupled to identity/bootstrap and includes mutations
+ - notifications/email, appeals/drafts/finalisation, and representations/drafts/finalisation all cross workflow/orchestration boundaries and should not use the same façade pattern without a different design
+ - storage/blob/file operations, auth/session, and admin/reporting should currently be left unchanged because they are either integration-owned, platform-critical, already coherent enough, or low-value for another façade layer
+- Updated the adoption roadmap with a workflow-boundary checkpoint stating that the current additive façade pattern now has a natural stop point and should not simply continue into orchestration-heavy families.
+
+Validation:
+
+- Documentation-only validation.
+- Representative inspection only; no full route inventory, no implementation work, and no service/route changes performed.
+- Intended lightweight validation for this slice:
+ - `git diff --check`
+
+Follow-ups:
+
+- Primary next planning recommendation:
+ - workflow/orchestration design assessment
+- Secondary fallback only if another implementation slice is explicitly desired:
+ - one narrow account read-support cautious façade slice
+
### CL-2026-06-25-API-GROUPING-FACADE-MYPORTAL-READS-VERTICAL-SLICE: bounded myportal dashboard CRM read/enrichment grouping and service adoption
-date: 2026-06-25
-author: Cline
-scope: `pages/api/myportal/get-my-cases.js`, `pages/api/myportal/get-my-lpa-cases.js`, `pages/api/myportal/get-portal-module-details.js`, `actions/services/portalDirectService.js`, `actions/services/caseDirectService.js`, `tests/phase22/api-grouping-facade-myportal-reads.test.cjs`, `context/api-grouping-adoption-roadmap.md`
-type: change
-rationale: Implement the next additive API grouping façade vertical slice for the bounded My Portal dashboard read / enrichment journey by grouping only the proven active CRM read/enrichment routes under `pages/api/myportal/` and adopting those grouped routes in the existing owning service layers without changing dashboard storage, auth, watched-case, submission, or account behaviour.
-impact: Runtime behaviour is intended to remain unchanged; grouped myportal façade routes now cover the proven active dashboard CRM read/enrichment family, legacy endpoint handlers remain canonical, watched-case behaviour remains owned by subscriptions, and no route migration, deletion, contract change, CRM query change, auth/session change, storage/draft change, or submission/orchestration change has occurred.
+date: 2026-06-25
+author: Cline
+scope: `pages/api/myportal/get-my-cases.js`, `pages/api/myportal/get-my-lpa-cases.js`, `pages/api/myportal/get-portal-module-details.js`, `actions/services/portalDirectService.js`, `actions/services/caseDirectService.js`, `tests/phase22/api-grouping-facade-myportal-reads.test.cjs`, `context/api-grouping-adoption-roadmap.md`
+type: change
+rationale: Implement the next additive API grouping façade vertical slice for the bounded My Portal dashboard read / enrichment journey by grouping only the proven active CRM read/enrichment routes under `pages/api/myportal/` and adopting those grouped routes in the existing owning service layers without changing dashboard storage, auth, watched-case, submission, or account behaviour.
+impact: Runtime behaviour is intended to remain unchanged; grouped myportal façade routes now cover the proven active dashboard CRM read/enrichment family, legacy endpoint handlers remain canonical, watched-case behaviour remains owned by subscriptions, and no route migration, deletion, contract change, CRM query change, auth/session change, storage/draft change, or submission/orchestration change has occurred.
status: completed
Summary:
@@ -100,12 +157,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-CASE-DETAILS-VERTICAL-SLICE: bounded case-details read grouping and service adoption
-date: 2026-06-25
-author: Cline
-scope: `pages/api/cases/get-incident-by-id.js`, `pages/api/cases/get-case-message.js`, `pages/api/cases/get-linked-cases.js`, `pages/api/cases/get-sips-events.js`, `pages/api/cases/get-sips-media.js`, `actions/services/caseDirectService.js`, `actions/services/searchDirectService.js`, `tests/phase22/api-grouping-facade-case-details.test.cjs`, `context/api-grouping-adoption-roadmap.md`
-type: change
-rationale: Implement the next additive API grouping façade vertical slice for the bounded Case Details read journey by grouping only the proven case-specific read family under `pages/api/cases/` and adopting those grouped routes in the existing owning service layers without changing bootstrap/search/documents behavior.
-impact: Runtime behaviour is intended to remain unchanged; grouped cases façade routes now cover the proven incident-id, case-message, linked-cases, and SIPS enrichment reads, legacy endpoint handlers remain canonical, and no route migration, deletion, contract change, document behaviour change, search behaviour change, auth change, storage change, or submission/orchestration change has occurred.
+date: 2026-06-25
+author: Cline
+scope: `pages/api/cases/get-incident-by-id.js`, `pages/api/cases/get-case-message.js`, `pages/api/cases/get-linked-cases.js`, `pages/api/cases/get-sips-events.js`, `pages/api/cases/get-sips-media.js`, `actions/services/caseDirectService.js`, `actions/services/searchDirectService.js`, `tests/phase22/api-grouping-facade-case-details.test.cjs`, `context/api-grouping-adoption-roadmap.md`
+type: change
+rationale: Implement the next additive API grouping façade vertical slice for the bounded Case Details read journey by grouping only the proven case-specific read family under `pages/api/cases/` and adopting those grouped routes in the existing owning service layers without changing bootstrap/search/documents behavior.
+impact: Runtime behaviour is intended to remain unchanged; grouped cases façade routes now cover the proven incident-id, case-message, linked-cases, and SIPS enrichment reads, legacy endpoint handlers remain canonical, and no route migration, deletion, contract change, document behaviour change, search behaviour change, auth change, storage change, or submission/orchestration change has occurred.
status: completed
Summary:
@@ -180,12 +237,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-ROLLOUT-CHECKPOINT: proven rollout pattern and guardrails checkpoint
-date: 2026-06-25
-author: Cline
-scope: `context/api-grouping-adoption-roadmap.md`, `tests/phase22/api-grouping-facade-rollout.test.cjs`, `memory-bank/change-log.md`
-type: milestone
-rationale: Record a short checkpoint after the first successful additive API grouping façade slices so the proven rollout pattern, completion criteria, and delay/guardrail criteria are documented before considering more complex API groups.
-impact: Documentation and characterization only; no runtime behaviour, handler implementation, service URL, route location, payload, contract, auth/session behaviour, or integration behaviour change.
+date: 2026-06-25
+author: Cline
+scope: `context/api-grouping-adoption-roadmap.md`, `tests/phase22/api-grouping-facade-rollout.test.cjs`, `memory-bank/change-log.md`
+type: milestone
+rationale: Record a short checkpoint after the first successful additive API grouping façade slices so the proven rollout pattern, completion criteria, and delay/guardrail criteria are documented before considering more complex API groups.
+impact: Documentation and characterization only; no runtime behaviour, handler implementation, service URL, route location, payload, contract, auth/session behaviour, or integration behaviour change.
status: completed
Summary:
@@ -245,12 +302,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-SEARCH-VERTICAL-SLICE: active public search results grouping and service adoption
-date: 2026-06-25
-author: Cline
-scope: `pages/api/search/basic-paged.js`, `pages/api/search/advanced.js`, `pages/api/search/advanced-paged.js`, `pages/api/search/basic-details-paged.js`, `actions/services/searchDirectService.js`, `tests/phase22/api-grouping-facade-search.test.cjs`, `context/api-grouping-adoption-roadmap.md`
-type: change
-rationale: Implement the next additive API grouping façade vertical slice by grouping the active Public Search results journey under `pages/api/search/` and adopting the grouped routes only in the existing common public-search service layer, while preserving legacy endpoint handlers unchanged and leaving adjacent/excluded search journeys alone.
-impact: Runtime behaviour is intended to remain unchanged; grouped search façade routes now cover the proven active public-results path, `actions/services/searchDirectService.js` now targets those grouped routes for the bounded in-scope calls, legacy endpoint handlers remain canonical, and no migration, route deletion, query-parameter change, paging change, sorting change, payload change, or response-contract change has occurred.
+date: 2026-06-25
+author: Cline
+scope: `pages/api/search/basic-paged.js`, `pages/api/search/advanced.js`, `pages/api/search/advanced-paged.js`, `pages/api/search/basic-details-paged.js`, `actions/services/searchDirectService.js`, `tests/phase22/api-grouping-facade-search.test.cjs`, `context/api-grouping-adoption-roadmap.md`
+type: change
+rationale: Implement the next additive API grouping façade vertical slice by grouping the active Public Search results journey under `pages/api/search/` and adopting the grouped routes only in the existing common public-search service layer, while preserving legacy endpoint handlers unchanged and leaving adjacent/excluded search journeys alone.
+impact: Runtime behaviour is intended to remain unchanged; grouped search façade routes now cover the proven active public-results path, `actions/services/searchDirectService.js` now targets those grouped routes for the bounded in-scope calls, legacy endpoint handlers remain canonical, and no migration, route deletion, query-parameter change, paging change, sorting change, payload change, or response-contract change has occurred.
status: completed
Summary:
@@ -331,12 +388,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-DOCUMENTS-VERTICAL-SLICE: active published-document metadata grouping and service adoption
-date: 2026-06-25
-author: Cline
-scope: `pages/api/documents/get-search-document-details.js`, `pages/api/documents/get-search-document-details-paged.js`, `pages/api/documents/get-search-document-types.js`, `actions/services/searchDirectService.js`, `tests/phase22/api-grouping-facade-documents.test.cjs`, `context/api-grouping-adoption-roadmap.md`
-type: change
-rationale: Implement the second additive API grouping façade vertical slice by grouping the active published-document metadata journey under `pages/api/documents/` and adopting the grouped routes only in the existing common document metadata service layer, while preserving the existing download route and legacy endpoint handlers unchanged.
-impact: Runtime behaviour is intended to remain unchanged; grouped document façade routes now cover the active metadata/type journey calls, `actions/services/searchDirectService.js` now targets those grouped routes, legacy endpoint handlers remain canonical, the existing grouped download route remains unchanged, and no migration, route deletion, auth change, CRM query change, hash-link generation change, payload change, or response-contract change has occurred.
+date: 2026-06-25
+author: Cline
+scope: `pages/api/documents/get-search-document-details.js`, `pages/api/documents/get-search-document-details-paged.js`, `pages/api/documents/get-search-document-types.js`, `actions/services/searchDirectService.js`, `tests/phase22/api-grouping-facade-documents.test.cjs`, `context/api-grouping-adoption-roadmap.md`
+type: change
+rationale: Implement the second additive API grouping façade vertical slice by grouping the active published-document metadata journey under `pages/api/documents/` and adopting the grouped routes only in the existing common document metadata service layer, while preserving the existing download route and legacy endpoint handlers unchanged.
+impact: Runtime behaviour is intended to remain unchanged; grouped document façade routes now cover the active metadata/type journey calls, `actions/services/searchDirectService.js` now targets those grouped routes, legacy endpoint handlers remain canonical, the existing grouped download route remains unchanged, and no migration, route deletion, auth change, CRM query change, hash-link generation change, payload change, or response-contract change has occurred.
status: completed
Summary:
@@ -403,12 +460,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-SUBSCRIPTIONS-VERTICAL-SLICE-COMPLETION: watched-case proxy read adoption and scope closure
-date: 2026-06-25
-author: Cline
-scope: `pages/api/subscriptions/get-watched-cases-proxy.js`, `actions/services/portalDirectService.js`, `tests/phase22/api-grouping-facade-subscriptions.test.cjs`, `context/api-grouping-adoption-roadmap.md`
-type: change
-rationale: Complete the intended subscriptions/watched-cases vertical slice by covering the active proxy read path still used by the normal watched-case UI journey, while keeping legacy endpoint and proxy handlers in place as canonical/support implementation routes.
-impact: Runtime behaviour is intended to remain unchanged; the grouped subscriptions façade now covers the active watched-case journey service methods including proxy reads, while legacy handlers remain canonical and no route deletion, migration, auth/session change, CRM query change, payload change, or status-code change has occurred.
+date: 2026-06-25
+author: Cline
+scope: `pages/api/subscriptions/get-watched-cases-proxy.js`, `actions/services/portalDirectService.js`, `tests/phase22/api-grouping-facade-subscriptions.test.cjs`, `context/api-grouping-adoption-roadmap.md`
+type: change
+rationale: Complete the intended subscriptions/watched-cases vertical slice by covering the active proxy read path still used by the normal watched-case UI journey, while keeping legacy endpoint and proxy handlers in place as canonical/support implementation routes.
+impact: Runtime behaviour is intended to remain unchanged; the grouped subscriptions façade now covers the active watched-case journey service methods including proxy reads, while legacy handlers remain canonical and no route deletion, migration, auth/session change, CRM query change, payload change, or status-code change has occurred.
status: completed
Summary:
@@ -451,12 +508,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-SUBSCRIPTIONS-INTERNAL-ADOPTION: first internal consumer targets grouped watched-case routes
-date: 2026-06-25
-author: Cline
-scope: `actions/services/portalDirectService.js`, `tests/phase22/api-grouping-facade-subscriptions.test.cjs`, `context/api-grouping-adoption-roadmap.md`
-type: change
-rationale: Validate the subscriptions façade pilot through one carefully selected internal consumer by updating watched-case service methods in `portalDirectService` to call the new grouped subscriptions routes while leaving the legacy endpoint handlers unchanged and canonical behind the façade.
-impact: Runtime behaviour is intended to remain unchanged because the grouped routes still delegate to the existing watched-case handlers; validates incremental internal adoption without route migration, deprecation, auth/session change, CRM query change, payload change, or signed-request behaviour change.
+date: 2026-06-25
+author: Cline
+scope: `actions/services/portalDirectService.js`, `tests/phase22/api-grouping-facade-subscriptions.test.cjs`, `context/api-grouping-adoption-roadmap.md`
+type: change
+rationale: Validate the subscriptions façade pilot through one carefully selected internal consumer by updating watched-case service methods in `portalDirectService` to call the new grouped subscriptions routes while leaving the legacy endpoint handlers unchanged and canonical behind the façade.
+impact: Runtime behaviour is intended to remain unchanged because the grouped routes still delegate to the existing watched-case handlers; validates incremental internal adoption without route migration, deprecation, auth/session change, CRM query change, payload change, or signed-request behaviour change.
status: completed
Summary:
@@ -498,12 +555,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-FACADE-PILOT-SUBSCRIPTIONS: additive watched-case subscriptions façade routes
-date: 2026-06-25
-author: Cline
-scope: `pages/api/subscriptions/*`, watched-case API façade pilot, focused characterization tests, and grouping-plan/adoption-roadmap documentation
-type: change
-rationale: Implement the first additive API grouping façade pilot by adding journey-owned subscriptions wrapper routes for watched-case read/create/delete operations that delegate to the existing canonical endpoint handlers without changing current frontend call sites, contracts, or behaviour.
-impact: Runtime impact is intentionally additive only; existing watched-case endpoint routes remain canonical/stable; no auth/session, CRM query, hash/signing, payload, status-code, i18n, or frontend-callsite behaviour change intended; documentation now records the pilot and its non-migration status.
+date: 2026-06-25
+author: Cline
+scope: `pages/api/subscriptions/*`, watched-case API façade pilot, focused characterization tests, and grouping-plan/adoption-roadmap documentation
+type: change
+rationale: Implement the first additive API grouping façade pilot by adding journey-owned subscriptions wrapper routes for watched-case read/create/delete operations that delegate to the existing canonical endpoint handlers without changing current frontend call sites, contracts, or behaviour.
+impact: Runtime impact is intentionally additive only; existing watched-case endpoint routes remain canonical/stable; no auth/session, CRM query, hash/signing, payload, status-code, i18n, or frontend-callsite behaviour change intended; documentation now records the pilot and its non-migration status.
status: completed
Summary:
@@ -553,12 +610,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-ADOPTION-ROADMAP: gradual adoption roadmap for future journey-owned API grouping
-date: 2026-06-25
-author: Cline
-scope: `context/api-grouping-adoption-roadmap.md`, architecture roadmap for gradual adoption of future API grouping concepts
-type: milestone
-rationale: Create a planning-only roadmap document describing how PEDW could gradually adopt the future journey-owned API grouping model over time through documentation guidance, additive consistency, and future-development discipline rather than migration or restructuring.
-impact: Documentation/context only; improves architecture planning clarity for gradual API grouping adoption, maintainability direction, and future decision support; no runtime, auth, CRM, storage, queue, notification, i18n, contract, or behaviour change.
+date: 2026-06-25
+author: Cline
+scope: `context/api-grouping-adoption-roadmap.md`, architecture roadmap for gradual adoption of future API grouping concepts
+type: milestone
+rationale: Create a planning-only roadmap document describing how PEDW could gradually adopt the future journey-owned API grouping model over time through documentation guidance, additive consistency, and future-development discipline rather than migration or restructuring.
+impact: Documentation/context only; improves architecture planning clarity for gradual API grouping adoption, maintainability direction, and future decision support; no runtime, auth, CRM, storage, queue, notification, i18n, contract, or behaviour change.
status: completed
Summary:
@@ -634,12 +691,12 @@ Follow-ups:
### CL-2026-06-25-API-GROUPING-PLAN-PHASE-1: future journey-owned API grouping model
-date: 2026-06-25
-author: Cline
-scope: `context/api-grouping-plan.md`, architecture planning for future journey-owned API grouping concepts
-type: milestone
-rationale: Create a planning-only architecture document that synthesises the completed API platform, route map, journey map, integration map, and architecture findings into a future journey-owned API grouping model focused on maintainability, findability, consistency, and extensibility without reopening discovery or recommending implementation.
-impact: Documentation/context only; improves future architecture planning clarity around journey-owned API grouping, shared platform concerns, and API-family classification; no runtime, auth, CRM, storage, queue, notification, i18n, contract, or behaviour change.
+date: 2026-06-25
+author: Cline
+scope: `context/api-grouping-plan.md`, architecture planning for future journey-owned API grouping concepts
+type: milestone
+rationale: Create a planning-only architecture document that synthesises the completed API platform, route map, journey map, integration map, and architecture findings into a future journey-owned API grouping model focused on maintainability, findability, consistency, and extensibility without reopening discovery or recommending implementation.
+impact: Documentation/context only; improves future architecture planning clarity around journey-owned API grouping, shared platform concerns, and API-family classification; no runtime, auth, CRM, storage, queue, notification, i18n, contract, or behaviour change.
status: completed
Summary:
@@ -732,12 +789,12 @@ Follow-ups:
### CL-2026-06-22-JOURNEY-ARCHITECTURE-MAP-SLICE-8: case-messages-notices and related-published-case-communications lifecycle map
-date: 2026-06-22
-author: Cline
-scope: `context/journey-architecture-map.md`, case messages/notices and related published case communications architecture documentation
-type: milestone
-rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting how public case-level notices are loaded and rendered on case pages, how adjacent published communication content such as SIPS events/media participates in the case-detail experience, and how the relevant routes classify under a future grouping view without proposing implementation changes.
-impact: Documentation/context only; improves maintainer understanding of the case-message retrieval path, the case-page notice rendering model, the split ownership between message props and event/media Redux state, and the boundary between on-page case communications, document delivery, and outbound notifications; no runtime, CRM, relay, auth, storage, notification, or i18n behaviour change.
+date: 2026-06-22
+author: Cline
+scope: `context/journey-architecture-map.md`, case messages/notices and related published case communications architecture documentation
+type: milestone
+rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting how public case-level notices are loaded and rendered on case pages, how adjacent published communication content such as SIPS events/media participates in the case-detail experience, and how the relevant routes classify under a future grouping view without proposing implementation changes.
+impact: Documentation/context only; improves maintainer understanding of the case-message retrieval path, the case-page notice rendering model, the split ownership between message props and event/media Redux state, and the boundary between on-page case communications, document delivery, and outbound notifications; no runtime, CRM, relay, auth, storage, notification, or i18n behaviour change.
status: completed
Summary:
@@ -808,12 +865,12 @@ Follow-ups:
### CL-2026-06-22-JOURNEY-ARCHITECTURE-MAP-SLICE-7: published-document-discovery and download lifecycle map
-date: 2026-06-22
-author: Cline
-scope: `context/journey-architecture-map.md`, published document discovery and published document retrieval/download architecture documentation
-type: milestone
-rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting how published documents are surfaced on case pages, how published-document metadata is retrieved and shaped, how download links are generated, how the dedicated download proxy delivers files, and how the relevant routes classify under a future grouping view without proposing implementation changes or reopening authorization assessment.
-impact: Documentation/context only; improves maintainer understanding of the case-document discovery path, the metadata-to-hashlink-to-download-proxy handoff, document-history route visibility boundaries, and journey ownership across the document route family; no runtime, CRM, relay, auth, storage, notification, or i18n behaviour change.
+date: 2026-06-22
+author: Cline
+scope: `context/journey-architecture-map.md`, published document discovery and published document retrieval/download architecture documentation
+type: milestone
+rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting how published documents are surfaced on case pages, how published-document metadata is retrieved and shaped, how download links are generated, how the dedicated download proxy delivers files, and how the relevant routes classify under a future grouping view without proposing implementation changes or reopening authorization assessment.
+impact: Documentation/context only; improves maintainer understanding of the case-document discovery path, the metadata-to-hashlink-to-download-proxy handoff, document-history route visibility boundaries, and journey ownership across the document route family; no runtime, CRM, relay, auth, storage, notification, or i18n behaviour change.
status: completed
Summary:
@@ -887,12 +944,12 @@ Follow-ups:
### CL-2026-06-21-JOURNEY-ARCHITECTURE-MAP-SLICE-6: watchlist-subscriptions and unsubscribe-watchlist-removal lifecycle map
-date: 2026-06-21
-author: Cline
-scope: `context/journey-architecture-map.md`, watchlist/subscriptions and unsubscribe/watchlist-removal architecture documentation
-type: milestone
-rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting watched-case creation, viewing, removal, unsubscribe paths, the visible CRM contact↔watched-case relationship model, and future grouping candidates for watched-case APIs without proposing implementation changes or reopening the completed authorization assessment.
-impact: Documentation/context only; improves maintainer understanding of the CRM watched-case relationship lifecycle, dashboard/search/case watch-state reuse, email-notification participation on watched-case records, and watched-case API ownership boundaries; no runtime, auth, CRM, Notify, storage, or i18n behaviour change.
+date: 2026-06-21
+author: Cline
+scope: `context/journey-architecture-map.md`, watchlist/subscriptions and unsubscribe/watchlist-removal architecture documentation
+type: milestone
+rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting watched-case creation, viewing, removal, unsubscribe paths, the visible CRM contact↔watched-case relationship model, and future grouping candidates for watched-case APIs without proposing implementation changes or reopening the completed authorization assessment.
+impact: Documentation/context only; improves maintainer understanding of the CRM watched-case relationship lifecycle, dashboard/search/case watch-state reuse, email-notification participation on watched-case records, and watched-case API ownership boundaries; no runtime, auth, CRM, Notify, storage, or i18n behaviour change.
status: completed
Summary:
@@ -955,12 +1012,12 @@ Follow-ups:
### CL-2026-06-21-JOURNEY-ARCHITECTURE-MAP-SLICE-5: authentication-sign-in and notifications-email lifecycle map
-date: 2026-06-21
-author: Cline
-scope: `context/journey-architecture-map.md`, authentication/sign-in and notifications/email architecture documentation
-type: milestone
-rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting authentication/sign-in and notifications/email as cross-cutting journeys, including future grouping classification for auth/email-related APIs and an explicit auth-vs-notification comparison, without reopening the completed authorization assessment or proposing implementation changes.
-impact: Documentation/context only; improves maintainer understanding of NextAuth-to-CRM bootstrap continuity, locale-aware sign-in behaviour, Notify usage across auth and business notifications, and journey ownership/grouping boundaries for auth/email routes; no runtime, auth, CRM, Notify, storage, or i18n behaviour change.
+date: 2026-06-21
+author: Cline
+scope: `context/journey-architecture-map.md`, authentication/sign-in and notifications/email architecture documentation
+type: milestone
+rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting authentication/sign-in and notifications/email as cross-cutting journeys, including future grouping classification for auth/email-related APIs and an explicit auth-vs-notification comparison, without reopening the completed authorization assessment or proposing implementation changes.
+impact: Documentation/context only; improves maintainer understanding of NextAuth-to-CRM bootstrap continuity, locale-aware sign-in behaviour, Notify usage across auth and business notifications, and journey ownership/grouping boundaries for auth/email routes; no runtime, auth, CRM, Notify, storage, or i18n behaviour change.
status: completed
Summary:
@@ -1033,12 +1090,12 @@ Follow-ups:
### CL-2026-06-21-JOURNEY-ARCHITECTURE-MAP-SLICE-4: account registration and personal-details/account-management lifecycle map
-date: 2026-06-21
-author: Cline
-scope: `context/journey-architecture-map.md`, account registration and personal-details/account-management architecture documentation
-type: milestone
-rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting account registration and personal-details/account-management journeys, and by classifying relevant APIs against a future journey-based grouping model without proposing implementation changes.
-impact: Documentation/context only; improves maintainer understanding of the NextAuth-session-to-CRM-contact bootstrap model, account journey ownership, and future grouping candidates for account/auth/shared/platform-level APIs; no runtime, auth, storage, CRM, or i18n behaviour change.
+date: 2026-06-21
+author: Cline
+scope: `context/journey-architecture-map.md`, account registration and personal-details/account-management architecture documentation
+type: milestone
+rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting account registration and personal-details/account-management journeys, and by classifying relevant APIs against a future journey-based grouping model without proposing implementation changes.
+impact: Documentation/context only; improves maintainer understanding of the NextAuth-session-to-CRM-contact bootstrap model, account journey ownership, and future grouping candidates for account/auth/shared/platform-level APIs; no runtime, auth, storage, CRM, or i18n behaviour change.
status: completed
Summary:
@@ -1096,12 +1153,12 @@ Follow-ups:
### CL-2026-06-21-JOURNEY-ARCHITECTURE-MAP-SLICE-3: draft representation and representation submission/finalisation lifecycle map
-date: 2026-06-21
-author: Cline
-scope: `context/journey-architecture-map.md`, representation draft creation and representation submission/finalisation architecture documentation
-type: milestone
-rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting the representation draft lifecycle and the representation submission/finalisation lifecycle, including an explicit comparison against the already documented appeal lifecycle, without proposing implementation changes.
-impact: Documentation/context only; improves maintainer understanding of representation storage ownership, queue handoff, CRM representation boundaries, and appeal-vs-representation lifecycle differences; no runtime, auth, storage, queue, CRM, or i18n behaviour change.
+date: 2026-06-21
+author: Cline
+scope: `context/journey-architecture-map.md`, representation draft creation and representation submission/finalisation architecture documentation
+type: milestone
+rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting the representation draft lifecycle and the representation submission/finalisation lifecycle, including an explicit comparison against the already documented appeal lifecycle, without proposing implementation changes.
+impact: Documentation/context only; improves maintainer understanding of representation storage ownership, queue handoff, CRM representation boundaries, and appeal-vs-representation lifecycle differences; no runtime, auth, storage, queue, CRM, or i18n behaviour change.
status: completed
Summary:
@@ -1157,12 +1214,12 @@ Follow-ups:
### CL-2026-06-21-JOURNEY-ARCHITECTURE-MAP-SLICE-2: draft appeal and appeal submission/finalisation lifecycle map
-date: 2026-06-21
-author: Cline
-scope: `context/journey-architecture-map.md`, draft appeal creation and appeal submission/finalisation architecture documentation
-type: milestone
-rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting the draft appeal lifecycle and the appeal submission/finalisation lifecycle from page entry through state, services, APIs, storage, queue, and CRM transition without proposing implementation changes.
-impact: Documentation/context only; improves maintainer understanding of draft ownership, storage container boundaries, queue handoff, and submitted-appeal transition; no runtime, auth, storage, queue, CRM, or i18n behaviour change.
+date: 2026-06-21
+author: Cline
+scope: `context/journey-architecture-map.md`, draft appeal creation and appeal submission/finalisation architecture documentation
+type: milestone
+rationale: Extend the Journey Architecture Map with the next bounded maintainability slice by documenting the draft appeal lifecycle and the appeal submission/finalisation lifecycle from page entry through state, services, APIs, storage, queue, and CRM transition without proposing implementation changes.
+impact: Documentation/context only; improves maintainer understanding of draft ownership, storage container boundaries, queue handoff, and submitted-appeal transition; no runtime, auth, storage, queue, CRM, or i18n behaviour change.
status: completed
Summary:
@@ -1216,12 +1273,12 @@ Follow-ups:
### CL-2026-06-20-PORTAL-API-PLATFORM-ASSESSMENT-SLICE-A: API family classification sample
-date: 2026-06-20
-author: Cline
-scope: `context/portal-api-platform-assessment.md`, sampled API families under `pages/api/{endpoint,file,email,documents,auth}`
-type: milestone
-rationale: Record the first bounded slice of the Portal Integration Contract & API Platform Assessment by classifying representative API families, integration responsibilities, repeated patterns, duplication candidates, and contract-critical areas without widening into a full inventory.
-impact: Documentation/context only; improves visibility of the portal API platform shape and integration-family boundaries; no runtime, contract, auth, storage, email, or i18n behaviour change.
+date: 2026-06-20
+author: Cline
+scope: `context/portal-api-platform-assessment.md`, sampled API families under `pages/api/{endpoint,file,email,documents,auth}`
+type: milestone
+rationale: Record the first bounded slice of the Portal Integration Contract & API Platform Assessment by classifying representative API families, integration responsibilities, repeated patterns, duplication candidates, and contract-critical areas without widening into a full inventory.
+impact: Documentation/context only; improves visibility of the portal API platform shape and integration-family boundaries; no runtime, contract, auth, storage, email, or i18n behaviour change.
status: completed
Summary:
@@ -1287,12 +1344,12 @@ Follow-ups:
### CL-2026-06-20-PORTAL-API-PLATFORM-ASSESSMENT-SLICE-B: endpoint CRM relay contract shape sample
-date: 2026-06-20
-author: Cline
-scope: `context/portal-api-platform-assessment.md`, representative `pages/api/endpoint` route sample
-type: milestone
-rationale: Record the second bounded slice of the Portal Integration Contract & API Platform Assessment by classifying endpoint contract shapes inside `pages/api/endpoint`, comparing helper-oriented read contracts with older direct-wrapper mutation contracts, and assessing contract consistency without widening into a full endpoint inventory.
-impact: Documentation/context only; improves visibility of endpoint contract structure, implementation-style split, and maintainability shape in the CRM relay layer; no runtime, auth, storage, i18n, or API behaviour change.
+date: 2026-06-20
+author: Cline
+scope: `context/portal-api-platform-assessment.md`, representative `pages/api/endpoint` route sample
+type: milestone
+rationale: Record the second bounded slice of the Portal Integration Contract & API Platform Assessment by classifying endpoint contract shapes inside `pages/api/endpoint`, comparing helper-oriented read contracts with older direct-wrapper mutation contracts, and assessing contract consistency without widening into a full endpoint inventory.
+impact: Documentation/context only; improves visibility of endpoint contract structure, implementation-style split, and maintainability shape in the CRM relay layer; no runtime, auth, storage, i18n, or API behaviour change.
status: completed
Summary:
@@ -1372,12 +1429,12 @@ Follow-ups:
### CL-2026-06-20-PORTAL-API-PLATFORM-ASSESSMENT-SLICE-C: API maintenance map and reuse baseline
-date: 2026-06-20
-author: Cline
-scope: `context/portal-api-platform-assessment.md`, top-level `pages/api` maintenance structure and existing reuse primitives
-type: milestone
-rationale: Record the third bounded slice of the Portal Integration Contract & API Platform Assessment by mapping current folder responsibility, feature-to-API maintenance entry points, folder drift, reusable building blocks, and a future-facing consistency baseline without proposing implementation or file movement.
-impact: Documentation/context only; improves API findability and maintainability guidance for future work planning; no runtime, auth, storage, email, i18n, or API behaviour change.
+date: 2026-06-20
+author: Cline
+scope: `context/portal-api-platform-assessment.md`, top-level `pages/api` maintenance structure and existing reuse primitives
+type: milestone
+rationale: Record the third bounded slice of the Portal Integration Contract & API Platform Assessment by mapping current folder responsibility, feature-to-API maintenance entry points, folder drift, reusable building blocks, and a future-facing consistency baseline without proposing implementation or file movement.
+impact: Documentation/context only; improves API findability and maintainability guidance for future work planning; no runtime, auth, storage, email, i18n, or API behaviour change.
status: completed
Summary:
@@ -1453,12 +1510,12 @@ Follow-ups:
### CL-2026-06-20-PORTAL-API-PLATFORM-ASSESSMENT-SLICE-D: route ownership and change-entry sample
-date: 2026-06-20
-author: Cline
-scope: `context/portal-api-platform-assessment.md`, bounded journey change-entry mapping across watched cases, account/personal details, public document retrieval, and appeal submission/finalisation
-type: milestone
-rationale: Record the fourth bounded slice of the Portal Integration Contract & API Platform Assessment by identifying maintainer-first change-entry sets, route ownership, change risk, first-look checklists, and reuse points for four high-value journeys without widening into a full dependency inventory.
-impact: Documentation/context only; improves maintainability and change-entry clarity for future API work; no runtime, auth, storage, queue, i18n, or API behaviour change.
+date: 2026-06-20
+author: Cline
+scope: `context/portal-api-platform-assessment.md`, bounded journey change-entry mapping across watched cases, account/personal details, public document retrieval, and appeal submission/finalisation
+type: milestone
+rationale: Record the fourth bounded slice of the Portal Integration Contract & API Platform Assessment by identifying maintainer-first change-entry sets, route ownership, change risk, first-look checklists, and reuse points for four high-value journeys without widening into a full dependency inventory.
+impact: Documentation/context only; improves maintainability and change-entry clarity for future API work; no runtime, auth, storage, queue, i18n, or API behaviour change.
status: completed
Summary:
@@ -1519,12 +1576,12 @@ Follow-ups:
### CL-2026-06-20-PORTAL-API-PLATFORM-ASSESSMENT-SLICE-E: wider API surface pattern validation
-date: 2026-06-20
-author: Cline
-scope: `context/portal-api-platform-assessment.md`, top-level API surface validation across wider route families and implementation styles
-type: milestone
-rationale: Record the fifth bounded slice of the Portal Integration Contract & API Platform Assessment by validating whether the route-family, contract-shape, implementation-style, and folder-drift conclusions from earlier representative slices generalise across the wider API surface without generating a full endpoint inventory.
-impact: Documentation/context only; increases confidence that the architecture model is representative of the wider API platform; no runtime, auth, storage, queue, i18n, or API behaviour change.
+date: 2026-06-20
+author: Cline
+scope: `context/portal-api-platform-assessment.md`, top-level API surface validation across wider route families and implementation styles
+type: milestone
+rationale: Record the fifth bounded slice of the Portal Integration Contract & API Platform Assessment by validating whether the route-family, contract-shape, implementation-style, and folder-drift conclusions from earlier representative slices generalise across the wider API surface without generating a full endpoint inventory.
+impact: Documentation/context only; increases confidence that the architecture model is representative of the wider API platform; no runtime, auth, storage, queue, i18n, or API behaviour change.
status: completed
Summary:
@@ -1612,12 +1669,12 @@ Follow-ups:
### CL-2026-06-20-PORTAL-API-PLATFORM-ASSESSMENT-SLICE-F: final synthesis and stream closure
-date: 2026-06-20
-author: Cline
-scope: `context/portal-api-platform-assessment.md`, `context/architecture.md`, API platform assessment stream closure
-type: milestone
-rationale: Consolidate Slices A–E into one concise architecture-level API platform view, record the stable route-family / contract-shape / implementation-style model, and formally close the Portal Integration Contract & API Platform Assessment stream.
-impact: Documentation/context only; improves long-term maintainability guidance and architectural clarity for future API planning work; no runtime, auth, storage, queue, i18n, or API behaviour change.
+date: 2026-06-20
+author: Cline
+scope: `context/portal-api-platform-assessment.md`, `context/architecture.md`, API platform assessment stream closure
+type: milestone
+rationale: Consolidate Slices A–E into one concise architecture-level API platform view, record the stable route-family / contract-shape / implementation-style model, and formally close the Portal Integration Contract & API Platform Assessment stream.
+impact: Documentation/context only; improves long-term maintainability guidance and architectural clarity for future API planning work; no runtime, auth, storage, queue, i18n, or API behaviour change.
status: completed
Summary:
@@ -1690,12 +1747,12 @@ Follow-ups:
### CL-2026-06-20-API-ROUTE-MAP-MAINTAINER-GUIDE: first-generation journey-owned route map
-date: 2026-06-20
-author: Cline
-scope: `context/api-route-map.md`, maintainability-focused journey-owned API documentation
-type: milestone
-rationale: Create a first-generation maintainer guide that converts the completed API platform assessment into a journey-owned route map so future contributors can identify where to start, which APIs/helpers matter, what integrations are touched, and where change risk is highest without reopening discovery.
-impact: Documentation/context only; improves API maintainability, findability, and ownership clarity for future planning and change review; no runtime, auth, storage, queue, i18n, or API behaviour change.
+date: 2026-06-20
+author: Cline
+scope: `context/api-route-map.md`, maintainability-focused journey-owned API documentation
+type: milestone
+rationale: Create a first-generation maintainer guide that converts the completed API platform assessment into a journey-owned route map so future contributors can identify where to start, which APIs/helpers matter, what integrations are touched, and where change risk is highest without reopening discovery.
+impact: Documentation/context only; improves API maintainability, findability, and ownership clarity for future planning and change review; no runtime, auth, storage, queue, i18n, or API behaviour change.
status: completed
Summary:
@@ -1770,12 +1827,12 @@ Follow-ups:
### CL-2026-06-19-ARCHITECTURE-PROGRAMME-MILESTONE: discovery close-out and transition to adoption planning
-date: 2026-06-19
-author: Architecture Review
-scope: architecture programme
-type: milestone
-rationale: Record the conclusion of the architectural discovery programme and the transition into the next architecture phase.
-impact: Documentation/context only; improves programme clarity, handoff readiness, and next-stream prioritisation; no runtime or implementation behaviour change.
+date: 2026-06-19
+author: Architecture Review
+scope: architecture programme
+type: milestone
+rationale: Record the conclusion of the architectural discovery programme and the transition into the next architecture phase.
+impact: Documentation/context only; improves programme clarity, handoff readiness, and next-stream prioritisation; no runtime or implementation behaviour change.
status: completed
Summary:
@@ -1807,12 +1864,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-SECURITY-FIRST-PASS: endpoint inventory and access-boundary assessment
-date: 2026-06-19
-author: Cline
-scope: `pages/api/**`, `context/portal-api-security-boundary-assessment.md`
-type: milestone
-rationale: Record the first-pass architecture assessment of the portal API security and access boundary, focusing on endpoint inventory, authentication visibility, trust boundaries, and ownership enforcement evidence.
-impact: Documentation/context only; improves visibility of API security posture and next-step prioritisation; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `pages/api/**`, `context/portal-api-security-boundary-assessment.md`
+type: milestone
+rationale: Record the first-pass architecture assessment of the portal API security and access boundary, focusing on endpoint inventory, authentication visibility, trust boundaries, and ownership enforcement evidence.
+impact: Documentation/context only; improves visibility of API security posture and next-step prioritisation; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -1845,12 +1902,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-OWNERSHIP-TRACE: session-to-contact and ownership-enforcement trace
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, portal SSR loaders, account/portal/document service flows, selected user-owned API handlers
-type: milestone
-rationale: Record the ownership-enforcement trace for the Portal API Security & Access Boundary Assessment by identifying how the authenticated session becomes portal identity, CRM contact identity, blob/container identity, and user-owned API access.
-impact: Documentation/context only; clarifies current authorization architecture and ownership-enforcement locations; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, portal SSR loaders, account/portal/document service flows, selected user-owned API handlers
+type: milestone
+rationale: Record the ownership-enforcement trace for the Portal API Security & Access Boundary Assessment by identifying how the authenticated session becomes portal identity, CRM contact identity, blob/container identity, and user-owned API access.
+impact: Documentation/context only; clarifies current authorization architecture and ownership-enforcement locations; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -1899,12 +1956,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-PINSUSER-TRACE: cookie identity provenance and comparison with CRM contact resolution
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, `pinsUser` cookie lifecycle, SSR loaders, homepage/login routing, account/search/myportal flows
-type: milestone
-rationale: Record the architectural role of `pinsUser` by tracing where it is created, refreshed, cleared, and consumed, and by comparing it to the canonical session-to-CRM-contact identity path.
-impact: Documentation/context only; clarifies current identity and trust-boundary model; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, `pinsUser` cookie lifecycle, SSR loaders, homepage/login routing, account/search/myportal flows
+type: milestone
+rationale: Record the architectural role of `pinsUser` by tracing where it is created, refreshed, cleared, and consumed, and by comparing it to the canonical session-to-CRM-contact identity path.
+impact: Documentation/context only; clarifies current identity and trust-boundary model; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -1951,12 +2008,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-ACCOUNT-MUTATION-TRACE: account/profile read and mutation boundary assessment
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, account/profile pages, account direct services, account endpoint handlers
-type: milestone
-rationale: Record the account/profile mutation assessment by tracing how account pages establish identity, how personal details are read and updated, whether email can diverge from session identity, and whether account/password APIs re-bind caller-supplied contact IDs to the authenticated session.
-impact: Documentation/context only; clarifies account/profile authorization posture and legacy-route risk; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, account/profile pages, account direct services, account endpoint handlers
+type: milestone
+rationale: Record the account/profile mutation assessment by tracing how account pages establish identity, how personal details are read and updated, whether email can diverge from session identity, and whether account/password APIs re-bind caller-supplied contact IDs to the authenticated session.
+impact: Documentation/context only; clarifies account/profile authorization posture and legacy-route risk; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -2003,12 +2060,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-USER-OWNED-MUTATION-SURFACE-TRACE: systemic caller-ID trust across watchlists, cases, involvements, and representations
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, watchlist/case/involvement/representation mutation routes, related service helpers, and completion/finalisation flows
-type: milestone
-rationale: Extend the security boundary assessment beyond account/profile routes to determine whether caller-supplied CRM identity and record-ID trust is isolated or systemic across other user-owned CRM mutation families.
-impact: Documentation/context only; clarifies systemic authorization-boundary posture for user-owned CRM mutations; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, watchlist/case/involvement/representation mutation routes, related service helpers, and completion/finalisation flows
+type: milestone
+rationale: Extend the security boundary assessment beyond account/profile routes to determine whether caller-supplied CRM identity and record-ID trust is isolated or systemic across other user-owned CRM mutation families.
+impact: Documentation/context only; clarifies systemic authorization-boundary posture for user-owned CRM mutations; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -2058,12 +2115,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-HASH-WATCHLIST-DELETE-VERTICAL-SLICE: request integrity vs referential ownership verification
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, `gethash_api`, signing helpers, watchlist delete route, and watched-case delete UI/service flow
-type: milestone
-rationale: Perform a focused vertical-slice assessment of signed hash issuance and watchlist deletion to determine whether the hash mechanism materially strengthens the mutation boundary beyond request/identifier integrity.
-impact: Documentation/context only; clarifies what the signed-hash model does and does not visibly protect; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, `gethash_api`, signing helpers, watchlist delete route, and watched-case delete UI/service flow
+type: milestone
+rationale: Perform a focused vertical-slice assessment of signed hash issuance and watchlist deletion to determine whether the hash mechanism materially strengthens the mutation boundary beyond request/identifier integrity.
+impact: Documentation/context only; clarifies what the signed-hash model does and does not visibly protect; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -2113,12 +2170,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-DRAFT-STORAGE-OWNERSHIP-ASSESSMENT: session user ID to container boundary
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, draft appeal/representation loaders, storage service helpers, Azure storage helpers, and file/blob draft APIs
-type: milestone
-rationale: Assess the draft-storage ownership boundary by tracing how `session.user.id` becomes container identity, how draft data/files are created/read/deleted/submitted, and whether storage operations remain container-scoped through the queue handoff to CRM creation.
-impact: Documentation/context only; clarifies pre-submission storage ownership architecture and the storage-to-CRM ownership transition; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, draft appeal/representation loaders, storage service helpers, Azure storage helpers, and file/blob draft APIs
+type: milestone
+rationale: Assess the draft-storage ownership boundary by tracing how `session.user.id` becomes container identity, how draft data/files are created/read/deleted/submitted, and whether storage operations remain container-scoped through the queue handoff to CRM creation.
+impact: Documentation/context only; clarifies pre-submission storage ownership architecture and the storage-to-CRM ownership transition; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -2164,12 +2221,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-AUTHORIZATION-ARCHITECTURE-MODEL: consolidated authorization roots, patterns, integrity controls, and risk framing
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, `memory-bank/change-log.md`
-type: milestone
-rationale: Consolidate the completed portal API assessment passes into one PEDW authorization architecture model that clearly distinguishes authorization roots, ownership patterns, integrity controls, proven findings, and non-proven findings without widening scope into a new endpoint review.
-impact: Documentation/context only; improves architectural clarity, auditability, and future review discipline; no runtime, contract, auth, storage, relay, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, `memory-bank/change-log.md`
+type: milestone
+rationale: Consolidate the completed portal API assessment passes into one PEDW authorization architecture model that clearly distinguishes authorization roots, ownership patterns, integrity controls, proven findings, and non-proven findings without widening scope into a new endpoint review.
+impact: Documentation/context only; improves architectural clarity, auditability, and future review discipline; no runtime, contract, auth, storage, relay, or i18n behaviour change.
status: completed
Summary:
@@ -2230,12 +2287,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-SECURITY-STREAM-CLOSURE: formal close-out of authorization architecture assessment
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, `context/architecture.md`, `memory-bank/change-log.md`
-type: milestone
-rationale: Formally close the Portal API Security & Access Boundary Assessment stream and record the resulting stable architectural conclusions, programme status, and future framing in core project documentation.
-impact: Documentation/context only; clarifies that the stream is complete and records the final authorization architecture model for future review work; no runtime, contract, auth, relay, storage, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, `context/architecture.md`, `memory-bank/change-log.md`
+type: milestone
+rationale: Formally close the Portal API Security & Access Boundary Assessment stream and record the resulting stable architectural conclusions, programme status, and future framing in core project documentation.
+impact: Documentation/context only; clarifies that the stream is complete and records the final authorization architecture model for future review work; no runtime, contract, auth, relay, storage, or i18n behaviour change.
status: completed
Summary:
@@ -2275,12 +2332,12 @@ Follow-ups:
### CL-2026-06-19-PORTAL-API-REGISTRATION-TRACE: session-to-CRM-contact registration and dashboard bootstrap
-date: 2026-06-19
-author: Cline
-scope: `context/portal-api-security-boundary-assessment.md`, registration pages/components, account service helpers, `createaccount_api`, homepage signed-in bootstrap
-type: milestone
-rationale: Record how the portal transitions an authenticated NextAuth user with no CRM contact into a CRM-contact-backed portal user, and identify where dashboard access becomes valid.
-impact: Documentation/context only; improves architectural clarity around registration, identity binding, and dashboard authorization bootstrap; no runtime, contract, auth, or i18n behaviour change.
+date: 2026-06-19
+author: Cline
+scope: `context/portal-api-security-boundary-assessment.md`, registration pages/components, account service helpers, `createaccount_api`, homepage signed-in bootstrap
+type: milestone
+rationale: Record how the portal transitions an authenticated NextAuth user with no CRM contact into a CRM-contact-backed portal user, and identify where dashboard access becomes valid.
+impact: Documentation/context only; improves architectural clarity around registration, identity binding, and dashboard authorization bootstrap; no runtime, contract, auth, or i18n behaviour change.
status: completed
Summary:
@@ -2328,12 +2385,12 @@ Follow-ups:
### CL-2026-06-18-CRM-CASE-PROGRESS-CONTEXT: record CRM Case Progress Display investigation conclusions
-date: 2026-06-18
-author: Cline
-scope: `context/current-platform-state.md`, `memory-bank/{techContext,productContext,change-log}.md`
-type: change
-rationale: Preserve the completed CRM Case Progress Display investigation conclusions in project context so future contributors do not re-open the same status/lifecycle ambiguity without need.
-impact: Documentation/context only; improves architectural clarity around case status display ownership and inputs; no runtime, auth, i18n, API, or behaviour change.
+date: 2026-06-18
+author: Cline
+scope: `context/current-platform-state.md`, `memory-bank/{techContext,productContext,change-log}.md`
+type: change
+rationale: Preserve the completed CRM Case Progress Display investigation conclusions in project context so future contributors do not re-open the same status/lifecycle ambiguity without need.
+impact: Documentation/context only; improves architectural clarity around case status display ownership and inputs; no runtime, auth, i18n, API, or behaviour change.
status: completed
Summary:
@@ -2366,12 +2423,12 @@ Follow-ups:
### CL-2026-06-18-RPA-DOCS: representation participation availability documentation + context update
-date: 2026-06-18
-author: Cline
-scope: `docs/representation-participation-availability.md`, `docs/representation-participation-business-review.md`, `context/current-platform-state.md`, `memory-bank/{techContext,productContext,open-questions,change-log}.md`
-type: change
-rationale: Preserve the completed Representation Participation Availability investigation in repository documentation and project context so future contributors do not need to repeat the same discovery work.
-impact: Documentation/context only; improves architectural clarity and business-validation readiness; no runtime, auth, i18n, or API behaviour change.
+date: 2026-06-18
+author: Cline
+scope: `docs/representation-participation-availability.md`, `docs/representation-participation-business-review.md`, `context/current-platform-state.md`, `memory-bank/{techContext,productContext,open-questions,change-log}.md`
+type: change
+rationale: Preserve the completed Representation Participation Availability investigation in repository documentation and project context so future contributors do not need to repeat the same discovery work.
+impact: Documentation/context only; improves architectural clarity and business-validation readiness; no runtime, auth, i18n, or API behaviour change.
status: completed
Summary:
@@ -2401,12 +2458,12 @@ Follow-ups:
### CL-22541: breadcrumb/back-link route-state helper extraction (`va/adv/ads/key`)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/routeState.js`, `components/breadcrumbs.js`, `components/case/summary.js`, `tests/phase22/{route-state-helper.test.cjs,index.test.cjs}`
-type: change
-rationale: Action Priority 3 refactor backlog item by extracting duplicated route-state decision logic (`va/adv/ads/key`) into a shared pure helper and reusing it from breadcrumb and case-summary back-link flows to reduce drift/regression risk.
-impact: Refactor-only decision-layer consolidation for search/case/myportal navigation; no auth/session/CSP/API contract changes; EN/CY behavior intended unchanged as helper only resolves route targets and preserves existing query forwarding behavior.
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/routeState.js`, `components/breadcrumbs.js`, `components/case/summary.js`, `tests/phase22/{route-state-helper.test.cjs,index.test.cjs}`
+type: change
+rationale: Action Priority 3 refactor backlog item by extracting duplicated route-state decision logic (`va/adv/ads/key`) into a shared pure helper and reusing it from breadcrumb and case-summary back-link flows to reduce drift/regression risk.
+impact: Refactor-only decision-layer consolidation for search/case/myportal navigation; no auth/session/CSP/API contract changes; EN/CY behavior intended unchanged as helper only resolves route targets and preserves existing query forwarding behavior.
status: completed
Summary:
@@ -2435,10 +2492,10 @@ Follow-ups:
### CL-22541-B: breadcrumb route-state helper expansion (label + DNS path helper)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/routeState.js`, `components/breadcrumbs.js`, `components/case/summary.js`, `tests/phase22/route-state-helper.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/routeState.js`, `components/breadcrumbs.js`, `components/case/summary.js`, `tests/phase22/route-state-helper.test.cjs`
+type: change
rationale: Continue Priority 3 breadcrumb refactor in a second bounded commit by extracting remaining repeated breadcrumb label and DNS-route-path decision logic into shared pure helpers.
impact: Refactor-only extraction for navigation decision logic; no auth/session/CSP/API changes; no intended EN/CY behavior change beyond internal logic centralization.
status: completed
@@ -2466,10 +2523,10 @@ Follow-ups:
### CL-22541-C: breadcrumb case-state bundling helper (single-call resolver)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/routeState.js`, `components/breadcrumbs.js`, `tests/phase22/route-state-helper.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/routeState.js`, `components/breadcrumbs.js`, `tests/phase22/route-state-helper.test.cjs`
+type: change
rationale: Continue Priority 3 breadcrumbs refactor by bundling repeatedly paired breadcrumb href/label resolution into one pure helper so component call sites stay thinner and less drift-prone.
impact: Refactor-only centralization of existing route-state composition logic; no intended auth/session/API/i18n behavior change.
status: completed
@@ -2495,10 +2552,10 @@ Follow-ups:
### CL-22541-D: breadcrumbs shared my-portal crumb helper extraction
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue bounded breadcrumbs decomposition by extracting repeated my-portal breadcrumb `
` markup into one local render helper to reduce duplication and keep follow-on slices safer.
impact: Refactor-only JSX deduplication in breadcrumb rendering; no intended route, auth/session, API, EN/CY, or accessibility behavior change.
status: completed
@@ -2520,10 +2577,10 @@ Follow-ups:
### CL-22541-E: breadcrumbs case-reference crumb helper extraction
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue bounded breadcrumbs decomposition by extracting repeated case-reference tail breadcrumb markup into one local helper and replacing repeated inline blocks.
impact: Refactor-only JSX deduplication in breadcrumb rendering; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2545,10 +2602,10 @@ Follow-ups:
### CL-22541-F: breadcrumbs multi-pattern helper bundle (text + link crumbs)
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Deliver a slightly larger bounded slice by extracting and reusing multiple breadcrumb rendering patterns (plain text crumb and linked crumb) across several route branches.
impact: Refactor-only JSX deduplication and consistency improvement in breadcrumb rendering; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2573,10 +2630,10 @@ Follow-ups:
### CL-22541-G: breadcrumbs inline Link-crumb consolidation bundle
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue the larger bounded breadcrumb refactor cadence by replacing the next batch of repeated inline `
` crumbs with the shared link helper.
impact: Refactor-only JSX deduplication and consistency improvement in breadcrumb rendering; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2602,10 +2659,10 @@ Follow-ups:
### CL-22541-H: breadcrumbs anchor/back-link helper consolidation bundle
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue the larger bounded breadcrumbs refactor cadence by extracting repeated anchor/back-link crumb markup into one local helper while preserving non-Link semantics.
impact: Refactor-only JSX deduplication and consistency improvement in breadcrumb rendering; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2630,10 +2687,10 @@ Follow-ups:
### CL-22541-I: breadcrumbs edge branch consolidation + semantic back-crumb wrapper
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue the same bounded breadcrumbs refactor cadence by consolidating remaining edge inline Link/back crumbs and introducing a semantic back-crumb wrapper for readability.
impact: Refactor-only JSX deduplication/readability improvement; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2658,10 +2715,10 @@ Follow-ups:
### CL-22541-J: breadcrumbs static text-only route crumb consolidation
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue the same bounded refactor cadence by consolidating repeated static text-only breadcrumb route branches into one route-label resolver.
impact: Refactor-only structural deduplication/readability improvement; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2688,10 +2745,10 @@ Follow-ups:
### CL-22541-K: breadcrumbs grouped two-crumb helper extraction
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue the same bounded refactor cadence by extracting recurring two-crumb patterns into small grouped helpers while preserving explicit route branches.
impact: Refactor-only readability/deduplication improvement; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2716,10 +2773,10 @@ Follow-ups:
### CL-22541-L: breadcrumbs simple-route renderer map introduction
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`
+type: change
rationale: Continue bounded readability refactor by introducing a small route-to-renderer map for simple static branches, reducing conditional-chain length while preserving explicit dynamic branches.
impact: Refactor-only structural deduplication/readability improvement; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2744,10 +2801,10 @@ Follow-ups:
### CL-22541-M: breadcrumbs simple link+text pair map + focused structure coverage
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`, `tests/phase22/{breadcrumbs-route-map-structure,index}.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`, `tests/phase22/{breadcrumbs-route-map-structure,index}.test.cjs`
+type: change
rationale: Execute the next bounded slice by extracting simple link+text pair route branches into a tiny renderer map and adding focused regression checks that mapped and dynamic callback branches remain in the intended structure.
impact: Refactor-only structural deduplication/readability improvement plus focused test coverage; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2775,10 +2832,10 @@ Follow-ups:
### CL-22541-N: breadcrumbs unified mapped-route resolver + widened structural guardrails
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
+type: change
rationale: Execute the requested wider next slice by removing duplicated mapped-route invocation patterns, introducing a single top-level mapped resolver with explicit precedence, and migrating an additional safe my-portal route group into map-driven rendering while preserving explicit dynamic/callback branches.
impact: Refactor-only structural consolidation/readability improvement with widened mapped-route coverage and stronger structure guardrail tests; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2812,10 +2869,10 @@ Follow-ups:
### CL-22541-O: breadcrumbs myportal results-pair migration into unified mapped resolver
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
+type: change
rationale: Execute the agreed next slice by migrating the remaining callback-free myportal results-pair branches into the unified mapped resolver so more safe branches are rendered through one consistent mapping flow.
impact: Refactor-only structural consolidation/readability improvement; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2842,10 +2899,10 @@ Follow-ups:
### CL-22541-P: breadcrumbs grouped route-map constants + unified map composition point
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
+type: change
rationale: Execute the next wider slice by replacing per-group resolver functions with grouped route-map constants and a single composition array to further improve scanability while preserving route precedence semantics.
impact: Refactor-only structural readability improvement; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2875,10 +2932,10 @@ Follow-ups:
### CL-22541-Q: breadcrumbs route-map helper module extraction + map-order invariants
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/breadcrumbRouteMaps.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure,index}.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/breadcrumbRouteMaps.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure,index}.test.cjs`
+type: change
rationale: Execute both queued follow-up slices together by extracting map composition/resolution logic into a pure routing helper module and adding stronger structure + pure-helper guardrails for map-order precedence.
impact: Refactor-only structural modularization and test hardening; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2915,10 +2972,10 @@ Follow-ups:
### CL-22541-R: breadcrumbs mapped-group factory composition + unmapped-route null parity guard
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/breadcrumbRendererFactories.js`, `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/breadcrumbRendererFactories.js`, `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
+type: change
rationale: Execute both approved next slices in one commit by centralizing deterministic mapped route-group composition into a factory-level helper and adding explicit structure guard coverage for null fallback behavior on unmapped routes.
impact: Refactor-only structural consolidation and test hardening; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2948,10 +3005,10 @@ Follow-ups:
### CL-22541-S: breadcrumbs deterministic case-branch extraction (`/myportal/case`, `/case/id/[incident]`)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/breadcrumbRendererFactories.js`, `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/breadcrumbRendererFactories.js`, `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
+type: change
rationale: Execute the next deterministic extraction slice by migrating remaining callback-free case breadcrumb branches into the case-detail factory group while preserving map precedence and leaving stateful/callback routes inline.
impact: Refactor-only structural extraction and test guardrail expansion; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -2985,10 +3042,10 @@ Follow-ups:
### CL-22541-T: breadcrumbs larger slice — new-appeal mapped group extraction (`/newappeal/selectappeal`)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
+type: change
rationale: Execute the next larger deterministic refactor slice by extracting callback-free new-appeal breadcrumb branching into a dedicated mapped renderer group and extending map-order guardrails.
impact: Refactor-only structural extraction plus precedence-test hardening; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3021,10 +3078,10 @@ Follow-ups:
### CL-22541-U: breadcrumbs smaller slice — defensive mapped-route resolver hardening
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/breadcrumbRouteMaps.js`, `tests/phase22/breadcrumb-route-maps-helper.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/breadcrumbRouteMaps.js`, `tests/phase22/breadcrumb-route-maps-helper.test.cjs`
+type: change
rationale: Execute the queued smaller slice by hardening mapped-route lookup against malformed map entries and non-function values while keeping precedence behavior unchanged.
impact: Refactor-hardening only; no intended breadcrumb route behavior change for valid mapped renderers.
status: completed
@@ -3051,10 +3108,10 @@ Follow-ups:
### CL-22541-V: breadcrumbs larger slice — callback route-group extraction (`/myportal/case/id/[incident]`, `/case`)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
+type: change
rationale: Execute the next larger extraction slice by moving callback-bearing breadcrumb branches into a dedicated callback renderer map while preserving `router.back()` behavior through explicit callback injection.
impact: Structural refactor with preserved callback semantics; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3092,10 +3149,10 @@ Follow-ups:
### CL-22541-W: breadcrumbs larger slice — step-back route-group extraction (`/newappeal/[appealtypes]`, `/myportal/[appealtypes]`)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
+type: change
rationale: Execute the next larger extraction slice by moving step-based back-link branches into a dedicated mapped route group with explicit setter callback injection, preserving section-navigation semantics.
impact: Structural refactor with preserved back-link and step-state behavior; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3137,10 +3194,10 @@ Follow-ups:
### CL-22541-X: breadcrumbs smaller slice — strict null lookup guard coverage (empty/whitespace/non-exact paths)
-date: 2026-04-09
-author: Cline
-scope: `tests/phase22/breadcrumb-route-maps-helper.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `tests/phase22/breadcrumb-route-maps-helper.test.cjs`
+type: change
rationale: Execute the queued smaller follow-up slice by hardening helper regression coverage for strict exact-match route lookup semantics.
impact: Test-only hardening; no runtime route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3167,10 +3224,10 @@ Follow-ups:
### CL-22541-Y: breadcrumbs larger slice — representation route-group extraction (`/myportal/representation`)
-date: 2026-04-09
-author: Cline
-scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
-type: change
+date: 2026-04-09
+author: Cline
+scope: `lib/routing/{breadcrumbRendererFactories,breadcrumbRouteMaps}.js`, `components/breadcrumbs.js`, `tests/phase22/{breadcrumb-route-maps-helper,breadcrumbs-route-map-structure}.test.cjs`
+type: change
rationale: Execute the queued larger follow-up slice by extracting `/myportal/representation` callback/state breadcrumb branches into a dedicated mapped route group with explicit callback injection while preserving questionnaire/submit side-effects.
impact: Structural refactor with preserved representation back-link state behavior; no intended route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3216,11 +3273,11 @@ Follow-ups:
### CL-22541-Z: breadcrumbs closure slice 1 — mapped-route precedence/callback invariants decision
-date: 2026-04-09
-author: Cline
-scope: `memory-bank/decisions.md`
-type: change
-rationale: Execute closure slice 1 by documenting explicit architectural invariants for breadcrumb mapped-route precedence and callback injection contracts so future refactors remain safe and auditable.
+date: 2026-04-09
+author: Cline
+scope: `memory-bank/decisions.md`
+type: change
+rationale: Execute closure slice 1 by documenting explicit architectural invariants for breadcrumb mapped-route precedence and callback injection contracts so future refactors remain safe and auditable.
impact: Documentation/governance hardening only; no runtime route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3243,11 +3300,11 @@ Follow-ups:
### CL-22541-Z2: breadcrumbs closure slice 2 — missing representation map negative-path guard
-date: 2026-04-09
-author: Cline
-scope: `tests/phase22/breadcrumb-route-maps-helper.test.cjs`
-type: change
-rationale: Execute closure slice 2 by adding focused negative-path coverage ensuring resolver behavior remains stable when representation route-map dependency is missing from grouped map input.
+date: 2026-04-09
+author: Cline
+scope: `tests/phase22/breadcrumb-route-maps-helper.test.cjs`
+type: change
+rationale: Execute closure slice 2 by adding focused negative-path coverage ensuring resolver behavior remains stable when representation route-map dependency is missing from grouped map input.
impact: Test hardening only; no runtime route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3270,11 +3327,11 @@ Follow-ups:
### CL-22541-Z3: breadcrumbs closure slice 3 — remove lingering `/newappeal` no-op inline branch
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
-type: change
-rationale: Execute closure slice 3 by resolving the remaining inline `/newappeal` edge branch (a no-op render guard) and locking its removal with explicit structure coverage.
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
+type: change
+rationale: Execute closure slice 3 by resolving the remaining inline `/newappeal` edge branch (a no-op render guard) and locking its removal with explicit structure coverage.
impact: Refactor/test hardening only; no runtime route/auth/session/API/EN-CY/a11y behavior change.
status: completed
@@ -3295,11 +3352,11 @@ Follow-ups:
### CL-22541-Z4: breadcrumbs post-closure hotfix — callable label resolver parity (static + view-all)
-date: 2026-04-09
-author: Cline
-scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
-type: change
-rationale: Fix post-refactor regression where some breadcrumbs rendered blank labels because mapped label entries were returned as function references instead of resolved values.
+date: 2026-04-09
+author: Cline
+scope: `components/breadcrumbs.js`, `tests/phase22/breadcrumbs-route-map-structure.test.cjs`
+type: change
+rationale: Fix post-refactor regression where some breadcrumbs rendered blank labels because mapped label entries were returned as function references instead of resolved values.
impact: Restores user-visible breadcrumb labels for static and view-all keyed routes; no auth/session/API/security behavior change.
status: completed
@@ -3322,11 +3379,11 @@ Follow-ups:
### CL-22541-Z5: architecture comparison overview refresh (senior architecture review)
-date: 2026-04-09
-author: Cline
-scope: `context/architecture-overview-2026-04-09.md`
-type: change
-rationale: User requested a fresh senior architecture review and comparison baseline covering scalability, maintainability, coupling, boundary quality, operational/deployment risk, and prioritized technical debt actions.
+date: 2026-04-09
+author: Cline
+scope: `context/architecture-overview-2026-04-09.md`
+type: change
+rationale: User requested a fresh senior architecture review and comparison baseline covering scalability, maintainability, coupling, boundary quality, operational/deployment risk, and prioritized technical debt actions.
impact: Documentation-only architecture guidance update; no runtime/auth/session/security/API behavior change.
status: completed
@@ -3352,12 +3409,12 @@ Follow-ups:
### CL-00X: 22500 `components/elements/index.js` Phase 1 helper extraction
-date: 2026-04-07
-author: Cline
-scope: `components/elements/index.js`, `components/elements/helpers/fileUploadHelpers.js`, `components/elements/helpers/translationHelpers.js`, `memory-bank/refactor-backlog.md`
-type: change
-rationale: Execute Phase 1 of the approved `components/elements/index.js` decomposition plan by extracting pure helper logic only, reducing monolith coupling while preserving UI/component behavior.
-impact: No route/API contract changes; refactor-only extraction of translation/file-upload helper functions with expected behavior parity for EN/CY field labels, file naming, thumbnail icon mapping, and filename validation.
+date: 2026-04-07
+author: Cline
+scope: `components/elements/index.js`, `components/elements/helpers/fileUploadHelpers.js`, `components/elements/helpers/translationHelpers.js`, `memory-bank/refactor-backlog.md`
+type: change
+rationale: Execute Phase 1 of the approved `components/elements/index.js` decomposition plan by extracting pure helper logic only, reducing monolith coupling while preserving UI/component behavior.
+impact: No route/API contract changes; refactor-only extraction of translation/file-upload helper functions with expected behavior parity for EN/CY field labels, file naming, thumbnail icon mapping, and filename validation.
status: completed
Summary:
@@ -3386,12 +3443,12 @@ Follow-ups:
### CL-00Y: 22500 `components/elements/index.js` Phase 2 leaf renderer extraction (Rich multiline)
-date: 2026-04-07
-author: Cline
-scope: `components/elements/index.js`, `components/elements/fields/renderRichMultiline.js`
-type: change
-rationale: Continue the approved phased decomposition by extracting one low-risk leaf renderer (`RenderRichMultiline`) from the elements monolith while keeping existing field wiring and behavior intact.
-impact: Refactor-only move of rich multiline renderer implementation; no route/API/auth/security changes and no intended EN/CY behavior change.
+date: 2026-04-07
+author: Cline
+scope: `components/elements/index.js`, `components/elements/fields/renderRichMultiline.js`
+type: change
+rationale: Continue the approved phased decomposition by extracting one low-risk leaf renderer (`RenderRichMultiline`) from the elements monolith while keeping existing field wiring and behavior intact.
+impact: Refactor-only move of rich multiline renderer implementation; no route/API/auth/security changes and no intended EN/CY behavior change.
status: completed
Summary:
@@ -3410,12 +3467,12 @@ Follow-ups:
### CL-00Z: 22500 `components/elements/index.js` Phase 2 leaf renderer extraction (Text + Multiline)
-date: 2026-04-07
-author: Cline
-scope: `components/elements/index.js`, `components/elements/fields/renderTextfield.js`, `components/elements/fields/renderMultiline.js`
-type: change
-rationale: Complete the requested next bounded phase by extracting the additional low-risk leaf renderers (`RenderTextfield`, `RenderMultiline`) from the elements monolith into dedicated field modules while preserving existing wiring and behavior.
-impact: Refactor-only move of two renderer components; no intended changes to auth/API/security and no intended EN/CY behavior change.
+date: 2026-04-07
+author: Cline
+scope: `components/elements/index.js`, `components/elements/fields/renderTextfield.js`, `components/elements/fields/renderMultiline.js`
+type: change
+rationale: Complete the requested next bounded phase by extracting the additional low-risk leaf renderers (`RenderTextfield`, `RenderMultiline`) from the elements monolith into dedicated field modules while preserving existing wiring and behavior.
+impact: Refactor-only move of two renderer components; no intended changes to auth/API/security and no intended EN/CY behavior change.
status: completed
Summary:
@@ -3434,12 +3491,12 @@ Follow-ups:
### CL-001: TASK22211 endpoint search-document contract consistency slice
-date: 2026-03-23
-author: Cline
-scope: `pages/api/endpoint/{getsearchdocumenthistory_api,getsearchdocumenthistorypaged_api,getsearchdocumentdetails_api,getsearchdocumentdetailspaged_api,getsearchdocumentTypes_api}.js`, `tests/phase21/endpoint-handler-contract.test.cjs`
-type: change
-rationale: Continue the endpoint contract-consistency stream by normalizing a coherent search-document handler cluster that still used raw error passthrough and noisy legacy logging patterns.
-impact: Improved negative-path consistency and safer error contract handling in search-document endpoints while preserving success payload behavior.
+date: 2026-03-23
+author: Cline
+scope: `pages/api/endpoint/{getsearchdocumenthistory_api,getsearchdocumenthistorypaged_api,getsearchdocumentdetails_api,getsearchdocumentdetailspaged_api,getsearchdocumentTypes_api}.js`, `tests/phase21/endpoint-handler-contract.test.cjs`
+type: change
+rationale: Continue the endpoint contract-consistency stream by normalizing a coherent search-document handler cluster that still used raw error passthrough and noisy legacy logging patterns.
+impact: Improved negative-path consistency and safer error contract handling in search-document endpoints while preserving success payload behavior.
status: completed
Summary:
@@ -3470,12 +3527,12 @@ Follow-ups:
### CL-002: TASK22211 endpoint token handler contract consistency slice
-date: 2026-03-23
-author: Cline
-scope: `pages/api/endpoint/getToken.js`, `tests/phase21/endpoint-handler-contract.test.cjs`
-type: change
-rationale: Close out remaining non-standard endpoint contract handling by normalizing the legacy token endpoint to shared API response helpers and explicit error coding.
-impact: Improved endpoint error consistency and test coverage for token acquisition failures while preserving successful token payload passthrough.
+date: 2026-03-23
+author: Cline
+scope: `pages/api/endpoint/getToken.js`, `tests/phase21/endpoint-handler-contract.test.cjs`
+type: change
+rationale: Close out remaining non-standard endpoint contract handling by normalizing the legacy token endpoint to shared API response helpers and explicit error coding.
+impact: Improved endpoint error consistency and test coverage for token acquisition failures while preserving successful token payload passthrough.
status: completed
Summary:
@@ -3502,12 +3559,12 @@ Follow-ups:
### CL-003: TASK22211 endpoint contract-hardening stream backfill (all known slices)
-date: 2026-03-23
-author: Cline
-scope: `pages/api/endpoint/*_api.js`, `pages/api/endpoint/getToken.js`, `tests/phase21/endpoint-handler-contract.test.cjs`
-type: change
-rationale: Backfill memory-bank traceability so the complete known TASK22211 contract-consistency stream is documented in one place now that memory-bank is being versioned.
-impact: Improves governance/auditability of API contract hardening, makes rollout and rollback analysis easier, and records exactly which endpoint clusters were normalized.
+date: 2026-03-23
+author: Cline
+scope: `pages/api/endpoint/*_api.js`, `pages/api/endpoint/getToken.js`, `tests/phase21/endpoint-handler-contract.test.cjs`
+type: change
+rationale: Backfill memory-bank traceability so the complete known TASK22211 contract-consistency stream is documented in one place now that memory-bank is being versioned.
+impact: Improves governance/auditability of API contract hardening, makes rollout and rollback analysis easier, and records exactly which endpoint clusters were normalized.
status: completed
Summary:
@@ -3548,12 +3605,12 @@ Follow-ups:
### CL-004: TASK22224 file + static endpoint contract hardening bundle (phase21)
-date: 2026-03-23
-author: Cline
-scope: `pages/api/file/{downloadblob,generateappealpdfcopy}.js`, `pages/api/endpoint/{getsipsmedia_api,getappealtypesfornewappeal_api}.js`, `tests/phase21/{file-handler-contract,endpoint-handler-contract}.test.cjs`
-type: change
-rationale: Deliver the agreed larger bounded slice for remaining non-standard file/static handlers, improving negative-path consistency while preserving current success payload behavior.
-impact: Standardized error envelopes/codes for download and generated PDF copy flows, method guard parity for static endpoints, and expanded phase21 contract coverage for both file and endpoint handlers.
+date: 2026-03-23
+author: Cline
+scope: `pages/api/file/{downloadblob,generateappealpdfcopy}.js`, `pages/api/endpoint/{getsipsmedia_api,getappealtypesfornewappeal_api}.js`, `tests/phase21/{file-handler-contract,endpoint-handler-contract}.test.cjs`
+type: change
+rationale: Deliver the agreed larger bounded slice for remaining non-standard file/static handlers, improving negative-path consistency while preserving current success payload behavior.
+impact: Standardized error envelopes/codes for download and generated PDF copy flows, method guard parity for static endpoints, and expanded phase21 contract coverage for both file and endpoint handlers.
status: completed
Summary:
@@ -3594,12 +3651,12 @@ Follow-ups:
### CL-005: TASK22224 downloadblob hotfix closure (path normalization + hash compatibility)
-date: 2026-03-23
-author: Cline
-scope: `pages/api/file/downloadblob.js`
-type: change
-rationale: Close post-merge runtime regressions reported on live links where download URLs alternated between filename-only/full-path blob names and mixed encoded/raw hash input variants.
-impact: Restored reliable blob downloads without relaxing hash security guarantees (still HMAC validated), and preserved existing caller compatibility across legacy/new URL encodings.
+date: 2026-03-23
+author: Cline
+scope: `pages/api/file/downloadblob.js`
+type: change
+rationale: Close post-merge runtime regressions reported on live links where download URLs alternated between filename-only/full-path blob names and mixed encoded/raw hash input variants.
+impact: Restored reliable blob downloads without relaxing hash security guarantees (still HMAC validated), and preserved existing caller compatibility across legacy/new URL encodings.
status: completed
Summary:
@@ -3634,12 +3691,12 @@ Follow-ups:
### CL-006: TASK22224 file delete-route guard parity slice
-date: 2026-03-23
-author: Cline
-scope: `pages/api/file/{deleteblob,deleteblobcase,deleteblobrep}.js`, `tests/phase21/file-handler-contract.test.cjs`
-type: change
-rationale: Execute the next planned slice to align hash/canonicalization behavior and negative-path contracts across high-risk file delete routes, matching the compatibility posture established for `downloadblob`.
-impact: Reduces false `INVALID_HASH` failures for legitimate encoded/raw caller variants while preserving strict hash enforcement and improving resilience via explicit catch-path contracts.
+date: 2026-03-23
+author: Cline
+scope: `pages/api/file/{deleteblob,deleteblobcase,deleteblobrep}.js`, `tests/phase21/file-handler-contract.test.cjs`
+type: change
+rationale: Execute the next planned slice to align hash/canonicalization behavior and negative-path contracts across high-risk file delete routes, matching the compatibility posture established for `downloadblob`.
+impact: Reduces false `INVALID_HASH` failures for legitimate encoded/raw caller variants while preserving strict hash enforcement and improving resilience via explicit catch-path contracts.
status: completed
Summary:
@@ -3675,12 +3732,12 @@ Follow-ups:
### CL-007: TASK22224 getrepsblob stability hotfix after delete representation flow
-date: 2026-03-23
-author: Cline
-scope: `actions/azurestorage.js` (`getRepsBlobs`), `tests/phase21/file-handler-contract.test.cjs`
-type: change
-rationale: Resolve reported runtime 400 (`GET_REPS_BLOB_FAILED`) after delete representation actions, caused by stale soft-deleted blob tag hits during representation blob enumeration.
-impact: Prevents transient/stale Azure tag index entries from breaking representation retrieval, improving reliability of post-delete refresh without relaxing route security contracts.
+date: 2026-03-23
+author: Cline
+scope: `actions/azurestorage.js` (`getRepsBlobs`), `tests/phase21/file-handler-contract.test.cjs`
+type: change
+rationale: Resolve reported runtime 400 (`GET_REPS_BLOB_FAILED`) after delete representation actions, caused by stale soft-deleted blob tag hits during representation blob enumeration.
+impact: Prevents transient/stale Azure tag index entries from breaking representation retrieval, improving reliability of post-delete refresh without relaxing route security contracts.
status: completed
Summary:
@@ -3712,12 +3769,12 @@ Follow-ups:
### CL-008: TASK22224 awaiting-submission route resilience parity hardening
-date: 2026-03-23
-author: Cline
-scope: `pages/api/file/getawaitingsubmissionfromblob.js`, `tests/phase21/file-handler-contract.test.cjs`
-type: change
-rationale: Add explicit catch-path contract parity for awaiting-submission blob retrieval route so unexpected dependency failures return consistent, actionable error envelopes.
-impact: Improves reliability/diagnostics for post-delete case refresh and aligns file-route error handling style without changing success payload contract or hash verification behavior.
+date: 2026-03-23
+author: Cline
+scope: `pages/api/file/getawaitingsubmissionfromblob.js`, `tests/phase21/file-handler-contract.test.cjs`
+type: change
+rationale: Add explicit catch-path contract parity for awaiting-submission blob retrieval route so unexpected dependency failures return consistent, actionable error envelopes.
+impact: Improves reliability/diagnostics for post-delete case refresh and aligns file-route error handling style without changing success payload contract or hash verification behavior.
status: completed
Summary: