ui phase 8

dev/shared-working-context/frontend/requests/for-backend.md

@@ -860,3 +860,39 @@ delivers fixes in its own change. **Frontend never edits backend code to "fix" a
 - **Proposed shape:** n/a — filed to put the need on record, not to propose an endpoint shape yet.
 - **Status:** deferred, non-blocking — build nothing for it this phase; the 15s poll remains the only
   freshness mechanism.
+
+## REQ-055 — `submittedAt` on the nurse-facing `VerificationStatusDto` — filed by ui-phase-8 — 2026-07-19
+- **Need:** Add `submittedAt` (UTC ISO, nullable) to the nurse-facing `VerificationStatusDto`
+  (`GET nurse_verification/status`-equivalent) — the timestamp the nurse first left `not_started`.
+- **Why:** The B6 unified-journey rebuild (phase §3.2) shows a Shamsi submitted timestamp above the
+  "what happens next" timeline. The data already exists — the **admin** queue DTO
+  (`AdminVerificationQueueItem.submittedAt`) serves it today — but the nurse's own status read doesn't.
+  The client's `VerificationStatus` type now carries `submittedAt` as an optional, mock-tolerant field
+  (`services/verification/types.ts`); the mock stamps it when the checklist is first seeded
+  (`services/verification/apis/mockApi.ts`); the real `verificationClientApi` leaves it `undefined` and
+  B6 simply omits the timestamp line rather than fake one.
+- **Proposed shape:** `VerificationStatusDto { …, submittedAt: string | null }` (same semantics as the
+  admin queue's field — set once, on first leaving `not_started`, never updated after).
+- **Status:** open — mock-only until served; the real path omits the B6 timestamp line.
+
+## REQ-056 — Nurse-facing read-back of submitted credential details — filed by ui-phase-8 — 2026-07-19
+- **Need:** A nurse-facing read of the structured B5 fields already accepted by REQ-011's
+  `submit_credential_details` write: whether an INO number is on file (boolean — **never** the number
+  itself, which stays encrypted server-side and is never re-served by design), `specialties: string[]`,
+  and the optional registry fields (`issuingAuthority`, `issuedAt`, `expiresAt`). Either add these to
+  `VerificationStatusDto` directly or a sibling nurse-facing read.
+- **Why:** B5's rebuild (phase §3.4) fixes the "returning nurse sees blank fields and a dead disabled
+  submit button" defect by hydrating the form from the server — but there is **no nurse-facing read** of
+  what was actually submitted (REQ-011 delivered only the write; the admin `decide` endpoint is the only
+  place these fields are currently readable, and only post-decision). The client's `VerificationStatus`
+  type now carries an optional, mock-tolerant `credentialSubmission` field
+  (`{ inoNumberSubmitted: boolean, specialties: string[], issuingAuthority: string | null, issuedAt:
+  string | null, expiresAt: string | null }`); the mock persists what `submitCredentialDetails` receives
+  and serves it back; the real path leaves it `undefined` and B5 falls back to its pre-phase-8 blank-form
+  behavior (never a lie about what's on file, just less helpful).
+- **Proposed shape:** `VerificationStatusDto { …, credentialSubmission?: { inoNumberSubmitted: boolean,
+  specialties: string[], issuingAuthority: string | null, issuedAt: string | null, expiresAt: string |
+  null } | null }`. Verify against Swagger first — file only if it truly doesn't exist (per the phase
+  doc's instruction); at authoring time no such read was found in the b6 contract or swagger snapshot.
+- **Status:** open — mock-only until served; the real path degrades to the pre-phase-8 blank-form
+  behavior (documented, not a regression — just not yet as helpful as the mock demonstrates).