baya-monorepo/mvp/blocker-phases/09-nurse-verification-badge.md

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 — 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 for the rest of that phase.