Robert Bond
@@ -18,6 +18,335 @@ 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.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Performed a bounded watched-case usage audit across services, pages, and components.
|
||||
- Audit findings established that:
|
||||
- no frontend components directly call legacy watched-case endpoint URLs
|
||||
- normal watched-case journey calls are routed through `actions/services/portalDirectService.js`
|
||||
- `getWatchedCasesProxy()` is actively used in the current watched-case UI journey
|
||||
- `deletewatchedcasesproxy_api` remains present but is not part of the currently adopted normal watched-case service path
|
||||
- Added grouped façade route:
|
||||
- `pages/api/subscriptions/get-watched-cases-proxy.js`
|
||||
- delegates directly to `pages/api/endpoint/getwatchedcasesproxy_api.js`
|
||||
- Updated `actions/services/portalDirectService.js` so `getWatchedCasesProxy` now targets:
|
||||
- `/api/subscriptions/get-watched-cases-proxy`
|
||||
- Extended the existing subscriptions façade characterization test to prove:
|
||||
- grouped proxy façade delegation works
|
||||
- legacy proxy handler remains present
|
||||
- watched-case service methods now target grouped subscriptions routes for both normal and proxy watched-case reads
|
||||
- adopted methods no longer target the legacy watched-case endpoint URLs directly
|
||||
- delete proxy remains outside grouped pilot scope and legacy support route remains present
|
||||
- Updated the adoption roadmap to define what “complete vertical slice” means for this pilot and to record the proxy-scope boundary.
|
||||
|
||||
Validation:
|
||||
|
||||
- Focused validation only:
|
||||
- `npx eslint actions/services/portalDirectService.js tests/phase22/api-grouping-facade-subscriptions.test.cjs pages/api/subscriptions/get-watched-cases.js pages/api/subscriptions/get-watched-cases-proxy.js pages/api/subscriptions/create-watched-case.js pages/api/subscriptions/delete-watched-case.js`
|
||||
- `node tests/phase22/api-grouping-facade-subscriptions.test.cjs`
|
||||
- No repository-wide test suite run.
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- For the intended watched-case/subscriptions scope, the pilot now forms a complete vertical slice:
|
||||
- subscriptions journey
|
||||
- service layer
|
||||
- grouped façade routes
|
||||
- legacy canonical endpoint handlers
|
||||
- unchanged behaviour
|
||||
- Any future expansion beyond this scope should be a separate bounded slice (for example, deciding whether legacy/support proxy delete routes also need grouped façade coverage).
|
||||
|
||||
### 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.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Re-read required continuation context before implementation:
|
||||
- `context/api-grouping-plan.md`
|
||||
- `context/api-grouping-adoption-roadmap.md`
|
||||
- `context/api-route-map.md`
|
||||
- `memory-bank/change-log.md`
|
||||
- Updated only the watched-case methods in `actions/services/portalDirectService.js` to target grouped façade routes:
|
||||
- `getWatchedCases` -> `/api/subscriptions/get-watched-cases`
|
||||
- `createWatchedCases` -> `/api/subscriptions/create-watched-case`
|
||||
- `deleteWatchedCases` -> `/api/subscriptions/delete-watched-case`
|
||||
- Did not modify any other service methods in `portalDirectService.js`.
|
||||
- Did not modify underlying watched-case endpoint handlers or façade handler delegation.
|
||||
- Extended the existing façade characterization test to prove:
|
||||
- grouped façade delegation still works
|
||||
- legacy endpoint handler files remain present
|
||||
- the internal service layer now targets `/api/subscriptions/...`
|
||||
- the adopted watched-case methods no longer point at legacy `/api/endpoint/...` routes
|
||||
- key service-layer request-contract cues remain present (`loggedInUserId`, `watchedCaseID`, POST method)
|
||||
- Updated the adoption roadmap to record:
|
||||
- first internal consumer adoption has occurred
|
||||
- legacy routes remain canonical implementations
|
||||
- no migration or deprecation has occurred
|
||||
- this validates incremental adoption of grouped journey-owned routes
|
||||
|
||||
Validation:
|
||||
|
||||
- Focused validation only:
|
||||
- `npx eslint actions/services/portalDirectService.js tests/phase22/api-grouping-facade-subscriptions.test.cjs context/api-grouping-adoption-roadmap.md memory-bank/change-log.md`
|
||||
- `node tests/phase22/api-grouping-facade-subscriptions.test.cjs`
|
||||
- No repository-wide test suite run.
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- The subscriptions façade pattern has now been validated through both additive route introduction and one successful internal service adoption.
|
||||
- Any further adoption should continue incrementally and only with the same behaviour-preserving characterization discipline.
|
||||
|
||||
### 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.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Confirmed required implementation context was read before changes:
|
||||
- `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`
|
||||
- Added the first grouped façade routes under `pages/api/subscriptions/`:
|
||||
- `get-watched-cases.js`
|
||||
- `create-watched-case.js`
|
||||
- `delete-watched-case.js`
|
||||
- Implemented each façade as the smallest safe compatibility wrapper:
|
||||
- import the existing watched-case endpoint handler
|
||||
- delegate `req` and `res` directly to that existing handler
|
||||
- Preserved the existing canonical watched-case routes unchanged:
|
||||
- `pages/api/endpoint/getwatchedcases_api.js`
|
||||
- `pages/api/endpoint/createwatchedcases_api.js`
|
||||
- `pages/api/endpoint/deletewatchedcases_api.js`
|
||||
- Did not change frontend call sites; `actions/services/portalDirectService.js` continues to call the legacy endpoint routes.
|
||||
- Added a focused characterization test file to prove:
|
||||
- grouped façade route files exist and delegate to the expected legacy handlers
|
||||
- legacy endpoint files still exist
|
||||
- frontend watched-case service call sites were not migrated to `/api/subscriptions/`
|
||||
- Updated the API grouping plan and adoption roadmap to record:
|
||||
- this is the first additive grouping façade pilot
|
||||
- existing watched-case endpoint routes remain canonical/stable
|
||||
- new subscriptions routes are grouped façade routes
|
||||
- no old route removal or migration has occurred
|
||||
|
||||
Validation:
|
||||
|
||||
- Focused implementation only; no broad refactor performed.
|
||||
- Characterization coverage added for façade delegation and unchanged frontend call sites.
|
||||
- Intended validation set for this slice:
|
||||
- `npx eslint pages/api/subscriptions/*.js tests/phase22/api-grouping-facade-subscriptions.test.cjs`
|
||||
- `node tests/phase22/api-grouping-facade-subscriptions.test.cjs`
|
||||
- Existing watched-case endpoint files were preserved in place.
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- If the pilot is accepted, use the same additive façade pattern for future journey-owned grouping candidates only where behaviour preservation can be equally well characterized.
|
||||
|
||||
### 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.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Confirmed the required roadmap context was read before drafting:
|
||||
- `context/api-grouping-plan.md`
|
||||
- `context/api-route-map.md`
|
||||
- `context/journey-architecture-map.md`
|
||||
- `context/portal-api-platform-assessment.md`
|
||||
- `context/architecture.md`
|
||||
- `context/integration-map.md`
|
||||
- `memory-bank/change-log.md`
|
||||
- Added new document: `context/api-grouping-adoption-roadmap.md`.
|
||||
- Kept the roadmap explicitly scoped to **architecture planning only**.
|
||||
- Recorded the core adoption philosophy that PEDW should favour:
|
||||
- gradual evolution
|
||||
- behaviour preservation
|
||||
- contract preservation
|
||||
- incremental consistency
|
||||
- reuse of shared helpers
|
||||
over large restructures, wholesale moves, rewrites, or mass renaming.
|
||||
- Added a staged roadmap covering:
|
||||
- Stage 1 — Current state
|
||||
- Stage 2 — Future development guidance
|
||||
- Stage 3 — Documentation maturity
|
||||
- Stage 4 — Future opportunities
|
||||
- Added concise adoption principles emphasising:
|
||||
- preserve stable APIs
|
||||
- preserve contracts and integrations
|
||||
- prefer additive improvements
|
||||
- improve findability first
|
||||
- avoid unnecessary churn
|
||||
- never move APIs solely for cosmetic reasons
|
||||
- Added a future-development decision matrix covering:
|
||||
- new APIs
|
||||
- existing stable APIs
|
||||
- existing APIs being enhanced
|
||||
- shared/platform concerns
|
||||
- cross-cutting concerns
|
||||
- orchestration-heavy routes
|
||||
- Added qualitative success measures focused on maintainability outcomes rather than implementation metrics.
|
||||
- Added explicit non-goals including:
|
||||
- no migrations
|
||||
- no implementation
|
||||
- no route movement
|
||||
- no route renaming
|
||||
- no API deletion
|
||||
- no consolidation
|
||||
- no contract changes
|
||||
- no behaviour changes
|
||||
- Recommended the next architecture planning document only:
|
||||
- `context/api-maintainer-guidance-v2.md`
|
||||
|
||||
Validation:
|
||||
|
||||
- Documentation-only planning work; no runtime code changed.
|
||||
- Non-destructive synthesis only:
|
||||
- reused the completed architecture programme as the evidence base
|
||||
- reused the newly completed API grouping plan rather than reopening discovery
|
||||
- remained at architecture-roadmap level and did not widen into implementation or migration guidance
|
||||
- Did not perform another API inventory.
|
||||
- Did not recommend implementation, migration, refactor, or route moves.
|
||||
- No repo-wide automated analysis performed.
|
||||
- No Python used.
|
||||
- Lint/tests not run because this was documentation-only work.
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- Next architecture planning document only:
|
||||
- `context/api-maintainer-guidance-v2.md`
|
||||
|
||||
---
|
||||
|
||||
### 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.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Confirmed the required planning context was read before drafting:
|
||||
- `context/api-route-map.md`
|
||||
- `context/journey-architecture-map.md`
|
||||
- `context/portal-api-platform-assessment.md`
|
||||
- `context/architecture.md`
|
||||
- `context/integration-map.md`
|
||||
- `memory-bank/change-log.md`
|
||||
- Added new document: `context/api-grouping-plan.md`.
|
||||
- Kept the document explicitly scoped to **architecture planning only**.
|
||||
- Recorded the key evidence-base finding that the main API maintenance problem is:
|
||||
- findability
|
||||
- ownership clarity
|
||||
- consistency
|
||||
- reuse discipline
|
||||
- Assessed the proposed future grouping concepts only as documentation guidance:
|
||||
- `account/`
|
||||
- `admin/`
|
||||
- `appeals/`
|
||||
- `auth/`
|
||||
- `cases/`
|
||||
- `documents/`
|
||||
- `notifications/`
|
||||
- `platform/`
|
||||
- `representations/`
|
||||
- `search/`
|
||||
- `subscriptions/`
|
||||
- `shared/`
|
||||
- For each proposed group, documented:
|
||||
- purpose
|
||||
- primary journeys supported
|
||||
- typical integrations
|
||||
- typical route types
|
||||
- representative existing routes
|
||||
- shared components used
|
||||
- relationship to other groups
|
||||
- migration cautions
|
||||
- Added a **Shared Platform Components** section classifying reusable helpers such as:
|
||||
- relay helpers
|
||||
- response helpers
|
||||
- hash helpers
|
||||
- signed request helpers
|
||||
- Azure Storage helpers
|
||||
- auth/session helpers
|
||||
- Notify helpers
|
||||
- logging helpers
|
||||
- validation helpers
|
||||
- Added a **Journey-to-Group Mapping** section working at journey/API-family level only and classifying areas as:
|
||||
- Natural fit
|
||||
- Likely fit
|
||||
- Shared / Platform concern
|
||||
- Cross-cutting concern
|
||||
- Leave unchanged for now
|
||||
- Added future guidance principles and explicit non-goals, including:
|
||||
- no implementation
|
||||
- no migrations
|
||||
- no folder restructuring
|
||||
- no route movement
|
||||
- no route renaming
|
||||
- no API deletions
|
||||
- no API consolidation
|
||||
- no behaviour change
|
||||
- no contract change
|
||||
- Recommended the next architecture planning document only:
|
||||
- `context/api-rationalisation-planning.md`
|
||||
|
||||
Validation:
|
||||
|
||||
- Documentation-only planning work; no runtime code changed.
|
||||
- Non-destructive evidence gathering and synthesis only:
|
||||
- read required context files
|
||||
- targeted extraction from existing route/journey/platform architecture documents
|
||||
- top-level `pages/api` listing only to compare current shape with future grouping concepts without producing a new API inventory
|
||||
- Did not reopen architectural discovery.
|
||||
- Did not perform a new route inventory.
|
||||
- Did not recommend implementation, refactor, migration, or route moves.
|
||||
- No repo-wide automated analysis performed.
|
||||
- No Python used.
|
||||
- Lint/tests not run because this was documentation-only work.
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- Next architecture planning document only:
|
||||
- `context/api-rationalisation-planning.md`
|
||||
|
||||
---
|
||||
|
||||
### CL-2026-06-22-JOURNEY-ARCHITECTURE-MAP-SLICE-8: case-messages-notices and related-published-case-communications lifecycle map
|
||||
|
||||
date: 2026-06-22
|
||||
|
||||
Reference in New Issue
Block a user