test(eval): scope danger warnings to answered routes; re-accept metadata debt at 0.6

[BigSimmo]

Two release-quality-eval governance fixes surfaced by the full release-gate re-run. Eval/docs only — no app behavior changes.

1. Danger warnings on declined (unsupported) answers are no longer failures

The app attaches a weak_evidencedanger warning when relevance verdict is none. On a refusal that is the correct reader signal ("no source-backed evidence — do not act"), not a governance failure. But source_governance_danger_failure_rate counted it, so 9 correctly-declined out-of-scope questions (coffee machine, air fryer, DKA-insulin, …) failed the gate.

• The rate now counts danger warnings only on answered routes (a delivered answer standing on dangerous sourcing).
• For genuinely out-of-scope cases, the warning's presence is positively asserted, so a regression that silently drops the refusal signal is still caught.
• For supported questions that were wrongly refused (a separate regression), the routing failure is reported by the existing validators; this change deliberately does not pile on a misleading "missing warning".
• New sourceGovernanceDangerFailuresForAnswer helper with 8 unit assertions covering answered/declined × expected/unexpected.

Verified on the live release eval:source_governance_danger_failure_rate0.225 → 0; all 9 affected cases confirmed correctly-declined.

2. Re-accept the bounded source-metadata debt at a 0.6 review-required ceiling

Top-result review_required_rate rose 0.14 → 0.5398 with no corpus change: the relevance-first ranking work (PR #118 / PR #130) removed governance metadata weighting from selection ordering, so review-flagged sources are no longer buried and the metric now reports true corpus state.

• Debt file re-accepted at max_review_required_rate: 0.6, expiry unchanged (2026-07-31), with rationale recorded.
• New docs/source-review-priority-2026-07-02.md: the 25 documents occupying golden top-5 slots, highest-frequency first (Clozapine GP mgmt 8 slots, Opioid use disorder 6, Bipolar 6, …). Reviewing the top 12 returns the rate to ~0.12, after which the ceiling should tighten back toward 0.2.

Not addressed here (separate, pre-existing)

The eval still reports blocking failures unrelated to these changes: grounded_supported_rate 0.867 (< 0.9), one prompt-injection false-positive (unsupported-prompt-injection-citation-forge returned a grounded answer), a citation failure, and extractive-route p95 latency. These are answer-quality regressions to investigate in the RAG-optimization track — flagged, not fixed.

Checks

vitest tests/eval-quality.test.ts 8/8 · typecheck clean · eslint clean · full live eval:quality:release confirmed items 1 & 2.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:36b7fa53c7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[BigSimmo]

Addressed both review notes in 14b129f:

Exempt non-grounded refusals (thread 2): confirmed finalizeRagAnswerQualityCore sets grounded=false while preserving the original routingMode, so a route-based check could fail the gate on a converted evidence-gap refusal. The danger-warning failure (and the summary rate) now key on grounded === true — an answer was actually delivered — which exempts every refusal regardless of route. New unit test covers the fast-route→evidence-gap case.

Missing-warning assertion (thread 1): you're right it was toothless. Rather than promote it to a gated metric — which would introduce new blocking failures on the current corpus (e.g. close-title-noise) and make the gate stricter than intended — I removed it. The grounded-based check is the clean core. Danger rate stays 0 on the current corpus.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:3c34fadb71

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:95ce58bb5c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:2b78614ef2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:4447ba8f3f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[BigSimmo]

Reviewed the P2 fixes (mirror-refusal + persisted-string detection). One correctness concern on the latest commit (4447ba8f3), capturedCaseExpectsSourceDangerWarning in src/lib/rag-eval-cases.ts:

The string branch treats any non-empty warning string as danger:

(typeofwarning==="string"&&warning.trim().length>0)||(typeofwarning==="object"&&warning!==null&&warning.severity==="danger")

But source_governance_warnings persists all severities as messages (ClinicalDashboard maps every warning.message), including non-danger ones — review_due ("…are due for review."), unverified ("…have not been locally validated."), partial_extraction, etc. So an unsupported_answer capture whose only persisted warning is, say, review_due gets expectsSourceDangerWarning: true. On the next eval run that refusal legitimately carries 0 danger warnings → it trips expected danger source governance warning missing and hard-blocks release on a false positive.

Suggest matching only the canonical danger messages instead of any string. The two per-source danger messages are stable literals in source-governance.ts (outdated_source, poor_extraction), so exporting them + an isDangerSourceGovernanceMessage(message) helper and matching against it keeps this precise and DRY:

// source-governance.tsexportconstOUTDATED_SOURCE_WARNING_MESSAGE="One or more supporting sources are marked outdated.";exportconstPOOR_EXTRACTION_WARNING_MESSAGE="One or more supporting sources have poor extraction quality.";constdangerMessages=newSet([OUTDATED_SOURCE_WARNING_MESSAGE,POOR_EXTRACTION_WARNING_MESSAGE]);exportconstisDangerSourceGovernanceMessage=(m: string)=>dangerMessages.has(m.trim());// rag-eval-cases.ts predicatereturnmetadataWarnings(row.metadata).some((warning)=>typeofwarning==="object"&&warning!==null
? (warningas{severity?: unknown}).severity==="danger"
: typeofwarning==="string"&&isDangerSourceGovernanceMessage(warning),);

Note weak_evidence danger can't be recovered from a message string (its text is dynamic relevance.supportReason and its fallback is shared with the non-danger partial-verdict variant), so it should stay uncovered by string-matching rather than be guessed — otherwise partial-evidence cases would false-positive too. A worth-considering follow-up is persisting source_danger_warning_count at capture time (the predicate already honours it), which recovers severity robustly for future captures.

I have this precise version implemented and green (tsc + eslint + prettier + a negative test proving a review_due-only capture does not set the flag) — happy to push it to this branch if you'd like, but held off to avoid clobbering the concurrent commits landing here.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[BigSimmo]

Pushed the precise-matching version in 23aa990 (branch had settled). It matches only the canonical danger messages (OUTDATED_SOURCE_WARNING_MESSAGE / POOR_EXTRACTION_WARNING_MESSAGE, exported from source-governance.ts and reused by the producer so they can't drift), replacing the any-non-empty-string check so a review_due/unverified-only capture no longer false-positives the expected danger … missing gate. Added a negative test covering that case. Green locally: tsc + eslint + prettier + the eval/rag-eval-cases/source-governance suites (30 tests).