Merged PR 2431: Add case details API grouping facade

Add case details API grouping facade Related work items: #23754
2026-06-25 09:22:12 +00:00
parent f9f78548b0
commit a1b89d19b8
10 changed files with 347 additions and 5 deletions
@@ -20,6 +20,86 @@ 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-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.  
+status: completed
+
+Summary:
+
+- Confirmed the required context was read before implementation:
+    - `context/api-grouping-plan.md`
+    - `context/api-grouping-adoption-roadmap.md`
+    - `context/api-route-map.md`
+    - `context/journey-architecture-map.md`
+    - `context/architecture.md`
+    - `memory-bank/change-log.md`
+- Performed a bounded audit of the active Case Details read journey across pages, components, services, and endpoint usage.
+- Audit findings established that:
+    - `pages/case/[ticketnumber].js` and `pages/myportal/case/[ticketnumber].js` still bootstrap primarily through the Public Search family using `getBasicSearch(...)` and `getSearchDetails(...)`
+    - `pages/case/id/[incident].js` and `pages/myportal/case/id/[incident].js` actively use the case-specific incident-id read route through `getIncidentbyID(...)`
+    - `getCaseMessage(...)` is actively used in case-page loading for banner/message content
+    - `getLinkedCases(...)` is actively used inside `components/case/summary.js` as a case-details read concern
+    - `getSIPSEvents(...)` and `getSIPSMedia(...)` are active case-page enrichments for relevant SIPS cases
+    - `components/case/documents.js` and document metadata routes remain part of the documents slice, not this case-details slice
+    - `getcase_api.js`, `getcasebyid_api.js`, and `getportalmoduledetails_api.js` are adjacent/support reads but were not proven to belong to the bounded active case-page read path for this slice
+- Added grouped façade routes under `pages/api/cases/` for the proven case-specific read family only:
+    - `get-incident-by-id.js`
+    - `get-case-message.js`
+    - `get-linked-cases.js`
+    - `get-sips-events.js`
+    - `get-sips-media.js`
+- Implemented each façade as the smallest safe compatibility wrapper:
+    - import the existing legacy endpoint handler
+    - delegate `req` and `res` directly to that existing handler
+- Updated only the existing owning service call sites needed for the bounded slice:
+    - `actions/services/caseDirectService.js`
+        - `getIncidentbyID`
+        - `getCaseMessage`
+        - `getSIPSEvents`
+        - `getSIPSMedia`
+    - `actions/services/searchDirectService.js`
+        - `getLinkedCases`
+- Left the following unchanged:
+    - legacy endpoint handlers
+    - search bootstrap routes and search detail expansion routes
+    - document metadata/download routes
+    - CRM queries
+    - transforms
+    - query parameter names
+    - response contracts
+    - status codes
+    - auth/session behavior
+    - storage/queue/submission behavior
+- Added focused characterization coverage to prove:
+    - grouped cases façade routes delegate correctly
+    - legacy endpoint handlers remain present
+    - adopted service methods now target grouped cases routes
+    - request-contract cues remain unchanged
+    - adjacent search/documents/support routes remain outside grouped adoption scope
+- Updated the adoption roadmap to record the audited scope boundary, included routes, excluded routes, service adoption status, and behaviour-preservation notes for the Case Details read slice.
+
+Validation:
+
+- Focused validation only intended for this slice:
+    - `npx eslint pages/api/cases/*.js actions/services/caseDirectService.js actions/services/searchDirectService.js tests/phase22/api-grouping-facade-case-details.test.cjs context/api-grouping-adoption-roadmap.md memory-bank/change-log.md`
+    - `node tests/phase22/api-grouping-facade-case-details.test.cjs`
+- No repository-wide validation run.
+
+Follow-ups:
+
+- The bounded Case Details read family is now a complete façade grouping slice only for the proven case-specific read routes adopted here.
+- Adjacent case bootstrap, document, and myportal aggregation/detail-enrichment routes should remain separate future slices if needed.
+
+---
+
+### CL-2026-06-25-API-GROUPING-FACADE-SEARCH-VERTICAL-SLICE: active public search results grouping and service adoption
+
 ### CL-2026-06-25-API-GROUPING-FACADE-ROLLOUT-CHECKPOINT: proven rollout pattern and guardrails checkpoint

 date: 2026-06-25