docs(issues): queue the two risk-classifier gaps PR #2145 exposed - #2153
Conversation
Both were found on a change that removed the Therapy production gate, and neither is a defect in that change — they are gaps in what the classifiers notice, so the next similar change gets the same reduced scrutiny. - `pr-policy` returned `clinicalRisk: false` for a diff touching the two modules that decide whether 205 clinically-unreviewed records are reachable in production, because its `src/lib/` patterns key on filenames and neither `app-modes` nor `therapies` matches one. No governance preflight was enforced; both PRs completed one voluntarily, which is precisely the fragility. - CI change-scope recorded `UI_CHANGED: false` and skipped Production UI for a change that alters which modes render for every user, because the UI patterns cover `src/app/`, `src/components/`, `public/` and the Playwright specs but not `src/lib/`. Browser coverage came only from a local run that no policy required. Each carries a stop rule against the obvious over-correction: do not widen clinical-risk until ordinary UI work trips the preflight, and do not make all of `src/lib` UI scope — that would put a 20-minute Chromium gate on every library change and reintroduce the documented cancellation waste. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:51 minutes Limit details: You’ve used the included review currently available. Your 102 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Comment |
Uh oh!
There was an error while loading. Please reload this page.
Summary
Two queued issue records. Both were found while removing the Therapy production gate (#2145, since closed in favour of #2150), and neither is a defect in that change — they are gaps in what the risk classifiers notice, so the next similar change receives the same reduced scrutiny. Each is its own commit-level record and independently actionable.
pr-policyreportsclinicalRisk: falsefor the switch controlling whether unreviewed clinical content reaches production.classifyPullRequestFilesreturned false for a diff touchingsrc/lib/app-modes.tsandsrc/lib/therapies.ts— the two modules deciding whether 205 clinically-unreviewed therapy records are reachable by users. Itssrc/lib/patterns key on filenames containingauth,permission,privacy,security,rag,retriev,rank,search,answer,clinical,citation,source,document,uploadordownload; neitherapp-modesnortherapiesmatches one. The data patterns match the records themselves but not the code gating their reachability. No governance preflight was enforced. Both PRs completed one voluntarily, which is exactly the fragility — voluntary compliance is not a control.CI change-scope reports
UI_CHANGED: falsefor a change that alters which modes render. The run for feat(therapy): expose Therapy in production ahead of clinical sign-off #2145 recordedUI_CHANGED: false,UI_RESULT: skippedandUI_FAST_RESULT: skipped, so Production UI never ran on a change that adds a mode to the shell for every user. The UI patterns coversrc/app/(non-api),src/components/,src/styles/,public/,tests/ui-*.spec.tsand the Playwright config — the diff touched onlysrc/lib/and unit tests. Browser coverage for both feat(therapy): expose Therapy in production ahead of clinical sign-off #2145 and feat(therapy): ship Therapy in production with its review state disclosed #2150 came solely from localverify:uiruns (447 passed each) that no policy required.Each record carries a stop rule against the obvious over-correction. For the first: do not widen the clinical-risk patterns until ordinary UI work trips the preflight — the classifier's own comment already warns that presentation files are not clinical-risk merely for living under a clinically-named directory, and that judgement is right. For the second: do not make all of
src/libUI scope, which would put a 20-minute Chromium gate on every library change and reintroduce the cancellation waste documented indocs/testing.md.Verification
npm run verify:pr-localfailed: (none). The risk router classified this as recognised low-risk documentation scope and ran the focused contracts —check:runtime,check:installed-lock-parity,format:changed,sitemap:check,docs:check-index,docs:check-inventory,docs:check-scripts,docs:check-links,check:branch-review-ledger,check:outstanding-issues,check:ledger-write-discipline— and correctly skipped lint, typecheck, the unit suite and the build, none of which have a plausible failure path in two added JSON files.npm run verify:uiwhen UI, routing, styling, browser behavior, reduced-motion, or forced-colors behavior changedUI verification not run: not applicable — no source file is touched, so no rendered surface can change. (Noted without irony: this is a case where
UI_CHANGED: falseis correct.)npm run verify:releasebefore release or handoff confidence claimsVerification not run: provider-backed, not authorized, and no release confidence is claimed.
npm run eval:retrieval:quality(must stay 36/36) when retrieval, ranking, selection, chunking, or scoring behavior changedVerification not run: not applicable — no retrieval surface is touched.
npm run eval:rag -- --limit 15+npm run eval:quality -- --rag-onlywhen answer generation, the synthesis prompt, or answer post-processing changedVerification not run: not applicable — answer generation is untouched.
npm run check:production-readinesswhen clinical workflow, privacy, environment, Supabase, source governance, or deployment behavior changedVerification not run: not applicable — this adds two queued records and changes no behaviour.
npm run check:deployment-readinesswhen deployment startup, hosting, or rollout behavior changedVerification not run: not applicable — no deployment behaviour changed.
Risk and rollout
docs/outstanding-issues.mdis untouched. Acting on either record later is a separate change with its own review.git revertthis single commit.Notes
Both requests land as pending and become numbered ledger rows only when
npm run issues:reconcilenext runs from its own deliberately serialized fresh-base branch. That single-writer constraint is what keepsdocs/outstanding-issues.mdconflict-free, so it is intentionally not done here.Related but deliberately not bundled: the Therapy sign-off tooling task landed separately in #2152, because it is clinical follow-up work rather than CI classification.
🤖 Generated with Claude Code
https://claude.ai/code/session_01CXpFsse3vVMy7CTxNRi568
Generated by Claude Code