audit fixes (P4 + P6): make the dormant Clinical Ask and Caring Contacts surfaces genuinely dormant

[BigSimmo]

Summary

Two audit remediation packages bundled into one pull request, from docs/audit/full-repository-audit-2026-09-02.md (PR #2573). They share a theme — a feature that is supposed to be switched off still behaving as if it were on — and touch no file in common, so they gate and review together. Branch claude/audit-fix-p6 is folded in here and is superseded; it needs no pull request of its own.

P4 — Dormant Clinical Ask. Findings M16, L33, L16, L17, M34, plus L124 (reassigned here).

• b19a05e speech: answer 404 and deny the microphone while Clinical Ask is off (M16)
• 8c58bed clinical-ask: answer 404 before auth and the limiter when the master flag is off (L33)
• f5af132 clinical-ask: return no catalogue evidence when nothing matches (L16)
• 551bd66 clinical-ask: surface 401 and 429 as unauthorized and rate_limited in the client stream (L17)
• 770d1ee docs: state that Clinical Ask has no user entry point and is flag-gated (M34)
• 52fe0f1 clinical-ask: remove always-empty "Review extract" disclosure (L124)

The substantive change is that CLINICAL_ASK_ENABLED=false now actually means off. Both provider-backed routes consult clinicalAskEnabled() as their first statement and answer a no-store JSON 404 before body parsing, the Supabase auth lookup, the durable rate-limiter write, or any provider client is constructed. Previously a disabled feature still authenticated callers, consumed rate-limiter budget and could reach OpenAI. Permissions-Policy now denies the microphone while the flag is off, and the pinned expectation in tests/security-headers.test.ts moved in the same commit.

P6 — Caring Contacts live surface. Findings M13, L113, L50, L74.

• b0ae178 tools: hide the Caring Contacts card wherever its workspace is locked (M13)
• e7cb5ce registries: fail loudly on unknown tool ids, and stop re-listing every search kind (L113)
• e6e8602 docs: document CARING_CONTACTS_DATABASE_URL where operators look (L50)
• ff5275e docs(caring-contacts): record that Phase 2B merged in feat(caring-contacts): Phase 2B workspace, plan lifecycle, team roster and database #2451 (L74)
• 1163fd9 tests: type the environment matrix for the production-lock check (M13)

L113 is the one with teeth beyond the card: toolCatalogRecordById returned the first tool for an unknown id rather than nothing, so a typo or stale id silently resolved to an unrelated tool.

L124 was verified before it was acted on rather than taken from the audit: all three server paths that build a Clinical Ask response call publicClinicalAskEvidence, which sets extract: "" before the response leaves the server, so the disclosure could never render content. It was removed rather than gated, since gating on a value that can never arrive is dead code.

Decisions needed from the owner:

• P6/M13: the card is now hidden entirely when the workspace is locked. The package notes permitted either that or a visible "demonstration only" card with no Open action; hiding was chosen as the smaller change. Say if you would rather it stayed visible and disabled.
• P6/L50: CARING_CONTACTS_DATABASE_URL is documented as set on no deployment. If a hosted Caring Contacts database is intended before enterprise sign-on exists, the role-membership grant and the Railway service placement need an operator decision and a check:env-parity entry.
• P4/M34 follow-on (product, not taken here): whether Clinical Ask stays dormant, gets a governed composer action reinstated behind the flag, or has its client layer retired.

RAG impact: none — Clinical Ask is a separate, flag-gated path and the Tools catalogue is not a retrieval surface; no ranking, ordering, comparator, selection or retrieval RPC change, and no file under src/lib/rag/** was touched.

Verification

• npm run verify:pr-local — - completed: check:runtime, check:installed-lock-parity, format:changed, check:diff-integrity, sitemap:check, check:repo-awareness-snapshot, docs:check-index, docs:check-inventory, docs:check-scripts, docs:check-links, check:branch-review-ledger, check:outstanding-issues, check:ledger-write-discipline, lint, typecheck, test, build, check:rag:fixtures, check:medication-interactions, check:medication-lexicon-report · - failed: (none) · - not reached: (none) · Test Files 1127 passed | 1 skipped (1128) · Tests 14983 passed | 2 expected fail | 3 skipped (14988) · ✓ Compiled successfully in 85s
• npm run check:diff-integrity — [diff-integrity] PASS — 9 changed test file(s), 86 -> 101 test case(s), against base 51ddfcd83. No test deleted, skipped or weakened; the case count rose by 15.
• L124 proved red-then-green before commit: the new assertion failed against the previous code (found <summary>Review extract</summary>) and passes after — Test Files 1 passed (1) / Tests 4 passed (4).

Verification not run: npm run verify:ui — browser proof left to CI; the pinned Chromium is not installed in this container, and no narrowed browser run is claimed as the full gate.
Verification not run: npm run verify:release — no release or handoff confidence is claimed.
Verification not run: provider-backed gates (check:production-readiness, the live eval:* commands) — nothing here reaches OpenAI, Supabase, Railway or Sentry at run time; all work was offline. The offline check:rag:fixtures step did run inside the gate and passed.

Risk and rollout

• Risk: medium — the change makes two provider-backed routes refuse earlier and removes a card from the Tools launcher; both are pinned by new tests and adversarially reviewed. Residual risk: the per-mode denylist still answers over the 200 SSE mode_unavailable frame by design, so only the master flag produces the hard 404. For M13, the card is hidden using a catalogue-local predicate that reads NODE_ENV and NEXT_PUBLIC_DEMO_MODE, because the real server-side predicate also reads PLAYWRIGHT_OFFLINE_MODE, which never reaches the client bundle. The two are proved equal by test in every environment src/instrumentation.ts permits a server to start in, and the test pins the instrumentation refusal string — but it is a mirror, not a shared implementation, and would need revisiting if a new environment shape were introduced.
• Rollback: revert this pull request's commits; each is one finding and reverts independently.
• Provider or production effects: None. The 404 path removes provider calls rather than adding any.
• RAG impact: none.

Clinical Governance Preflight

Each item confirmed against this pull request's diff. The checked line is the exact policy item; the note beneath it is the evidence.

• Source-backed claims still require linked source verification before clinical use
  unchanged; no citation or verification path touched.
• No patient-identifiable document workflow was introduced or expanded without explicit governance approval
  none introduced or expanded; the Caring Contacts card is withdrawn from the launcher, narrowing exposure.
• Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
  no Supabase env value, migration target or configured project changes.
• Service-role keys and private document access remain server-only
  unchanged; the routes now refuse before constructing any Supabase client.
• Demo/synthetic content remains clearly separated from real clinical sources
  reinforced: the Caring Contacts demonstration surface no longer appears as an openable tool outside demo mode.
• Source metadata, review status, and outdated/unknown-source behavior remain conservative
  unchanged.
• Deployment classification/TGA SaMD impact was checked when clinical decision-support behavior changed
  reviewed; no decision-support behaviour is added — a dormant path is closed and a demonstration card withdrawn.

Notes

• P6's adversarial review passed; P4's passed after one fix round. L124 was implemented and verified in this session.
• origin/main was merged into this branch (not rebased) before gating; the branch was level with origin/main at push time.
• One owner per file across the remediation programme: no other open remediation pull request edits these files. Files in common between P4 and P6: none.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DHSyfuC6mS98ystWFiitAR

---

Generated by Claude Code

---

Note

Medium Risk
Touches API gates, security headers, and Tools launcher visibility for suicide-prevention and provider-backed paths; behavior is heavily tested but Clinical Ask’s client/server lock predicates remain mirrored rather than shared.

Overview
Audit remediation (P4 + P6) makes two “off” surfaces behave as off instead of still doing work or advertising dead links.

Clinical Ask (CLINICAL_ASK_ENABLED=false). /api/clinical-ask/stream and /api/speech/transcribe now call clinicalAskEnabled() first and return a no-store JSON 404 (without error-level logging) before body parsing, Supabase auth, durable rate limits, or OpenAI. Per-mode disable still uses the existing SSE mode_unavailable path when the master flag is on. Permissions-Policy denies the microphone while there is no governed dictation UI. Catalogue retrieval no longer backfills with an empty query when a question matches nothing—empty evidence lets the orchestrator hit evidence_gap without synthesis. The client stream maps 401 and 429 to unauthorized / rate_limited with retry hints. The always-empty “Review extract” disclosure is removed from the answer surface. Privacy copy documents that Clinical Ask has no composer entry point when dormant.

Caring Contacts launcher. toolCatalogRecordsForSession hides the caring-contacts card in production unless NEXT_PUBLIC_DEMO_MODE=true (client-safe mirror of the workspace lock). toolCatalogRecordById throws on unknown ids instead of silently returning the first catalogue entry. Operators get documented CARING_CONTACTS_DATABASE_URL in .env.example and deployment architecture; Caring Contacts progress/handover docs record Phase 2B merged on main.

Minor: isSearchableAppMode delegates to isAppModeId instead of re-listing every search kind.

^{Reviewed by Cursor Bugbot for commit 6fe074f. Configure here.}

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: 57773d4f-36b0-4b22-ad23-7b1a492c9721

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_e4bf2fe5-e4e3-4a72-8e88-399586db40c1)

[github-actions]

CI triage

CI failed on this PR. Automated classification of the 2 failed job(s):

• Production UI (3) — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.
• PR required — main-side: the same job also failed on the latest completed main CI run.

Compared with main CI run #15583 (failure).

Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_9060e4be-93eb-4920-b1f2-82623aec1693)