fix(ci): route src/lib/rag/** to the offline RAG eval gates in change-scope classification - #2127
Conversation
…-scope classification `ragEvalPatterns` in scripts/ci-change-scope.mjs matched only the pre-#994 flat layout (`src/lib/rag.ts`, `src/lib/rag-*.ts`), so a pull request touching only the extracted `src/lib/rag/**` subtree classified as `rag_eval_changed=false`. Both `eval:rag:offline` and `eval:rag:adversarial:offline` were then skipped in verify:pr-local and in the CI safety/RAG eval job, leaving only the cheap `check:rag:fixtures` guard. PR #2065 reached main that way, and the live eval canary — not the offline adversarial harness — was what caught it. Add the directory prefix `/^src\/lib\/rag\//`, keeping every legacy pattern so the flat paths classify exactly as before. A directory prefix rather than a filename regex covers any future file in that subtree whatever it is named: `src/lib/rag/answer-composition.ts` carries no `rag-` prefix at all and was the clearest example of the gap. This mirrors the shape `scripts/pr-policy.mjs` already uses in `ragRankingPatterns`, which was widened for the #994 move while this classifier was not. Extend the change-scope self-test with three positive cases asserted alone — `src/lib/rag/rag.ts`, `src/lib/rag/answer-composition.ts`, and `src/lib/rag/rag-claim-support.ts` — plus the first negative `rag_eval_changed` assertion the file has carried: `src/lib/app-modes.ts` stays false while remaining an executable source change, so a future over-broad widening that dragged the offline RAG contracts onto every pull request would be caught. Deleting the new pattern makes the self-test fail, so the assertions are not vacuous. No workflow edit was needed: .github/workflows/ci.yml and scripts/verify-pr-local.mjs both consume the `rag_eval_changed` output rather than duplicating its regex. RAG impact: no retrieval behaviour change — CI/gate routing only. 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:42 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill 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 for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling 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 (3)
Comment |
Uh oh!
There was an error while loading. Please reload this page.
Summary
#SDQSFD:scripts/ci-change-scope.mjssetrag_eval_changedonly for the pre-refactor(rag): extract the rag cluster into src/lib/rag/ (maturity X2) #994 flat layout (src/lib/rag.tsandsrc/lib/rag-*.ts), so a pull request touching only the extractedsrc/lib/rag/**subtree classified asrag_eval_changed=false. That silently skippedeval:rag:offlineandeval:rag:adversarial:offlinein bothverify:pr-localand the CI safety/RAG eval job, leaving only the cheapcheck:rag:fixturesguard. PR fix(rag): bind claim-leading for/in conditions in the high-risk trigger check (S1c follow-up) #2065 reachedmainthat way, and the live eval canary — not the offline adversarial harness — was what caught it./^src\/lib\/rag\//toragEvalPatterns, keeping every existing legacy pattern untouched so the flatsrc/lib/rag.tsandsrc/lib/rag-*.tspaths still classify exactly as before. A directory prefix rather than a filename regex means any future file added to that subtree is covered whatever it is named —src/lib/rag/answer-composition.tscarries norag-prefix at all and was the clearest example of the gap. This is the same shapescripts/pr-policy.mjsalready uses in itsragRankingPatternslist, which was widened for the refactor(rag): extract the rag cluster into src/lib/rag/ (maturity X2) #994 move while the CI change-scope classifier was not.npm run check:ci-scope, the script's own--self-testassertions) with three positive cases —src/lib/rag/rag.ts,src/lib/rag/answer-composition.ts, andsrc/lib/rag/rag-claim-support.ts, each asserted alone — plus the first negativerag_eval_changedassertion the file has ever carried:src/lib/app-modes.tsstaysfalsewhile remaining an executable source change, so a future over-broad widening that dragged the offline RAG contracts onto every pull request would be caught..github/workflows/ci.ymlandscripts/verify-pr-local.mjsboth consume therag_eval_changedoutput from this classifier rather than duplicating its regex, so the corrected classification reaches the RAG eval job and the PR-local selector without any change to the workflow job graph.RAG impact: no retrieval behaviour change — CI/gate routing only. No file under
src/lib/rag/**or any other retrieval, ranking, selection, or eval-fixture surface was touched; the change only widens which offline gates CI andverify:pr-localselect for a diff.Verification
npm run verify:pr-localscripts/**is not a recognised light scope, so the run failed closed to the heavy route:check:runtime,check:installed-lock-parity,format:changed,lint,typecheck, the full offline unit suite,build,check:rag:fixtures,check:medication-interactions, andcheck:medication-lexicon-report.npm run check:ci-scope— the change-scope self-test, including the four new assertions.npm run verify:pr-local -- --dry-run --files src/lib/rag/rag-claim-support.tsonorigin/mainselectednpm run check:rag:fixturesand printedoffline RAG production contracts skipped: no RAG-scoped changes (fixtures still selected). With this change the same command selectsnpm run eval:rag:offlineandnpm run eval:rag:adversarial:offline, and the skip line is gone./^src\/lib\/rag\//pattern and re-runningnpm run check:ci-scopefails atassertScope, so the new tests genuinely detect the regression rather than passing vacuously.UI verification not run: no UI, routing, styling, browser, reduced-motion, or forced-colors behaviour changed — this diff is a single CI classification script.
No provider-backed command was run.
eval:rag:offlineandeval:rag:adversarial:offlineappear here only as gate names that CI will now select; neither was executed locally, and no live eval canary, OpenAI, or Supabase call was made.Risk and rollout
src/lib/rag/**now also runeval:rag:offlineandeval:rag:adversarial:offline, which is exactly the coverage this item exists to restore. Both are offline harnesses that fail closed on any network attempt.Notes
#SDQSFDproposedsrc/lib/answer-follow-up.tsas the negative test case, but that path is alreadyrag_eval_changed=trueonorigin/mainand remains so here: the pre-existinganswer(?:-[^/]+)?\.tsalternation in the same pattern list matches it. Making itfalsewould narrow RAG gate coverage on an answer-path file, which is the opposite of this item's intent and outside its scope, so the negative assertion usessrc/lib/app-modes.tsinstead — a genuinely unrelatedsrc/libmodule that proves the new directory prefix stayed a directory prefix.npm run issues:done; the canonicaldocs/outstanding-issues.mdis untouched and gets reconciled separately after this lands.src/libsubdirectories while here.documents/,extractors/,observability/,supabase/,validation/, andwebhooks/all classifyrag_eval_changed=false, which is correct — none of them is a retrieval or ranking surface underdocs/rag-behaviour/safeguards.md.🤖 Generated with Claude Code