hamid
45 lines
2.9 KiB
Markdown
45 lines
2.9 KiB
Markdown
# Phase 09 — Nurse verification badge doesn't reflect reality
|
|
|
|
**Blocker:** blockers.md § "Trust — nurse verification."
|
|
**Depends on:** nothing to start; do together with [10-search-dedup-and-trust.md](10-search-dedup-and-trust.md) — same root cause on two of the four call sites.
|
|
|
|
---
|
|
|
|
**Root cause.** `client/src/services/verification/constants.ts:9` — `USE_VERIFICATION_MOCK = true`. The real
|
|
backend is fully built and shape-matched: `GET nurse_verification` → `NurseVerificationController.cs:32-35`;
|
|
`GET nurses/{id}/trust_badge` (anonymous) → `NursesController.cs:26-29`; all admin queue/decide endpoints
|
|
(`AdminVerificationsController.cs`) match the client's `DecideStepInput` fields exactly.
|
|
|
|
## Two real gaps that must ship in the same change as flipping the flag, or the admin half 404s
|
|
|
|
- `verificationClientApi.approveVerification`/`.rejectVerification` (`clientApi.ts:269-278`) POST to
|
|
`admin_verifications/{id}/approve`/`/reject` — **routes that don't exist.** They're wired into the live UI
|
|
(`admin/verification/[nurseId]/page.tsx:81-82`), so this is a real break, not theoretical. This is also
|
|
exactly the gap forgotten-features.md calls out for nurse approval. The real
|
|
workflow already achieves the same outcome via `Decide` on the last pending step
|
|
(`AdminReviewStepCommand.Handler.cs:72` → `VerificationAggregator.Finalize`) — so either add the two
|
|
explicit endpoints (thin wrappers that resolve "the last pending step" and call the same finalize path), or
|
|
rewire the two admin buttons to call `decideStep` directly. Not a business-rule question — pure engineering
|
|
gap.
|
|
- `getDocumentSignedUrl` (`clientApi.ts:255-256`) targets `admin_verifications/documents/{id}/url` — also
|
|
missing; the case detail already carries a signed URL per document, so a re-open should just refetch the
|
|
case instead.
|
|
|
|
## Small DTO gap, currently harmless
|
|
|
|
Server's `VerificationStepDto.IsRequired` has no client-side
|
|
equivalent (`verification/types.ts:62-71`), and `blockingSteps` is computed from *all* non-passed steps, not
|
|
just required ones (`VerificationRepository.cs:138-141`) — fine while every seeded step is required; would
|
|
misrepresent "what's blocking" the day an optional step type is added. Worth a note, not urgent.
|
|
|
|
**Fix:** flip `USE_VERIFICATION_MOCK` to `false`, ship the two missing/rewired admin actions in the same
|
|
change.
|
|
|
|
## Same-symptom bugs, actually filed under Search — fix together since they're one root cause
|
|
|
|
Hardcoded literals, not the mock: `search/nurse/[nurseId]/page.tsx:173` and
|
|
`NurseResultCard.tsx:87` both hardcode `state="verified"` instead of deriving it from the real
|
|
`profile.isVerified` / index-guarantee data. `verification/types.ts:328-330` already has the exact helper
|
|
built for this (`publicBadgeState`) — neither call site uses it. See
|
|
[10-search-dedup-and-trust.md](10-search-dedup-and-trust.md) for the rest of that phase.
|