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
@@ -318,6 +318,59 @@ UI journey
    - grouping would require contract change
 - In these cases, documentation may still classify the area conceptually, but additive façade rollout should wait for a safer bounded slice.

+#### Additional vertical-slice proof point — Case Details read journey
+
+- The active Case Details read journey now has a fourth additive grouping slice for the proven case-specific read family only:
+    - grouped façade routes exist under `pages/api/cases/` for the proven active reads:
+        - `get-incident-by-id`
+        - `get-case-message`
+        - `get-linked-cases`
+        - `get-sips-events`
+        - `get-sips-media`
+    - the existing service-layer adoption is split across the current owning read services:
+        - `actions/services/caseDirectService.js` now targets grouped cases routes for:
+            - `getIncidentbyID`
+            - `getCaseMessage`
+            - `getSIPSEvents`
+            - `getSIPSMedia`
+        - `actions/services/searchDirectService.js` now targets grouped cases routes for:
+            - `getLinkedCases`
+    - legacy endpoint handlers remain present and canonical behind the façade:
+        - `pages/api/endpoint/getincidentbyid_api.js`
+        - `pages/api/endpoint/getcasemessage_api.js`
+        - `pages/api/endpoint/getlinkedcases_api.js`
+        - `pages/api/endpoint/getsipsevents_api.js`
+        - `pages/api/endpoint/getsipsmedia_api.js`
+- The bounded audit established that the true active Case Details read journey is narrower than the full case page bootstrap:
+    - public ticketnumber case pages (`pages/case/[ticketnumber].js`) still bootstrap primarily through the search family:
+        - `getBasicSearch(...)`
+        - `getSearchDetails(...)`
+    - incident-id case pages (`pages/case/id/[incident].js` and `pages/myportal/case/id/[incident].js`) use the case-specific incident-id route
+    - linked cases are actively loaded inside `components/case/summary.js` as a case-details read concern
+    - SIPS events/media are active case-page enrichments for the relevant case type
+    - documents remain a separate active journey owned by the documents slice through `components/case/documents.js` and `actions/services/searchDirectService.js`
+- The following routes were intentionally left outside this grouped adoption scope:
+    - `getbasicsearch_api.js`
+    - `getbasicsearchdetails_api.js`
+    - `getbasicsearchdetailspaged_api.js`
+    - `getsearchdocumentdetails_api.js`
+    - `getsearchdocumentdetailspaged_api.js`
+    - `getsearchdocumentTypes_api.js`
+    - `getcase_api.js`
+    - `getcasebyid_api.js`
+    - `getportalmoduledetails_api.js`
+- Exclusion reasoning:
+    - search bootstrap/detail-expansion routes remain part of Public Search or search-to-case bootstrap rather than the narrowed case-specific read family
+    - published document metadata remains owned by the documents slice
+    - `getcase_api.js` and `getcasebyid_api.js` are not proven active in the current case-page read path and remain adjacent/support routes
+    - `getportalmoduledetails_api.js` is actively used in myportal aggregation/detail enrichment rather than the bounded public/myportal case-details page read slice itself
+- For this Case Details slice, a complete vertical grouping slice means:
+    - the proven case-specific read family has grouped façade routes
+    - current owning service calls for that family target the grouped routes
+    - adjacent search bootstrap and documents routes remain unchanged
+    - legacy endpoint handlers remain canonical
+    - no route migration, deletion, or contract change has occurred
+
 ---

 ### Stage 3 — Documentation Maturity