docs(#100): record that the incremental evidence browser proof already exists - #2545
Conversation
…y exists The 2026-08-21 ledger row for #100 said both incremental-evidence flags default false and that the remaining offline scope was verify:ui proof of the client render path. Three of its statements are no longer true. Both flags default ON, not off. src/lib/env.ts:225-228 declares RAG_INCREMENTAL_EVIDENCE_PREVIEW with .default("true"), and src/lib/client-env.ts:18-22 returns `value !== "false"`, so an unset NEXT_PUBLIC_RAG_INCREMENTAL_EVIDENCE_PREVIEW_RENDER renders the rail. The .env.example line is commented because unset means ON. docs/verified-answer-incremental-delivery-design.md records Phase 1 shipped and enabled by default on 2026-08-27. The browser proof already exists and was run here: tests/answer-progress-ui-smoke.spec.ts:623 and :685, chromium, 2 passed (12.4s). That spec does not match tests/ui-*.spec.ts, which is why earlier ui-* searches missed it; playwright.config.ts names it explicitly in both productionSpecPattern and testMatch, so it runs in verify:ui and the full release matrix. So this change does not build a browser proof. It records the one that exists, narrows the open item to the two things that genuinely are uncovered, and corrects the AnswerProgress doc comment, which still told readers the preview is "off by default". On the two residual gaps, the record is deliberately precise about what kind of coverage each one needs. The `false` rollback is inlined at build time (client-env.ts:16) and ClinicalDashboard.tsx:1933 calls the gate with no argument, so a browser assertion of it needs a second build and may be right to leave at unit level. The danger-level source-governance suppression (answer-preview.ts:40) is a server-only gate, and the browser spec drives the rail through a mocked stream, so no Playwright test can observe it at all — that gap is route-level, not browser-level. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N8JUuufwbFHy8PsgbztmGN
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 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. Comment |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Bugbot couldn't run - usage limit reachedBugbot 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_f9a215d1-8cd3-4d58-85c2-1b5ebe0fc6ba) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 98d33813ed
ℹ️ 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".
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@codex resolve actionable Codex review findings for this pull request and current head using the repository instructions. This is the pull request's single automatic repair pass: do not perform a fresh review, create new standalone findings, or request another review. Work only the existing unresolved Codex threads on the current head. The only repository destination is BigSimmo/Database, and the only branch destination is the pull request head branch claude/incremental-evidence at starting commit 98d3381; never publish fixes to a detached or synthetic work branch and never create a stacked pull request. Use the authenticated GitHub connector to commit each approved fix to BigSimmo/Database:claude/incremental-evidence, then verify that the pull request head contains the published commit before reporting success. Always fix P0 and P1 findings. For P2 and lower findings, fix only clear, scoped, low-risk issues; otherwise disposition them with a concise reason. For a fixed thread, reply with as the first line and as the second line. For a no-code disposition, use followed by . These result markers authorize the workflow to close that exact thread only after it verifies a fixed commit is the pull request head; a local-only commit is not a fix. If publication or verification fails, do not use either result marker, do not claim success, and leave the thread open with the blocker. If human input or new authorization is required, do the same. Finish only after every actionable thread is fixed or dispositioned and closed, or explicitly left open for a human decision. Do not update the branch from main, address unrelated reviews, broaden scope, or create more than one scoped fix commit. Do not use external APIs, paid services, credentials, dependency changes, or broad refactors unless explicitly authorized. Add targeted tests where behavior changes and run the narrowest relevant validation. |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
…ce suppression proof Raised in review on PR #2545 and verified before acting on it. The earlier record on this branch said closing the danger-level source-governance suppression gap needs a real /api/answer stream over a danger-governed corpus, and is therefore provider-backed. That is wrong in the direction that matters: it would have parked an offline clinical-safety regression check behind approval and provider spend. docs/verified-answer-incremental-delivery-design.md places that exact fixture in Phase 0 and states the phase is provider-free. The route is already reachable offline -- tests/answer-stream-preview-order.test.ts drives the /api/answer stream route with the RAG pipeline, public access context and Supabase admin client all vi.mock'd -- so a route-level suppression fixture needs no provider. Records are immutable, so this is a new superseding request rather than an edit to the existing one. The remaining scope is restated as two offline items; Phase 2 acceptance stays provider-gated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N8JUuufwbFHy8PsgbztmGN
Bugbot couldn't run - usage limit reachedBugbot 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_386b94f1-483b-413a-913a-848ac16beb53) |
Static PR checks went red on 2650515: docs:check-links runs the ledger inbox planner, and the branch carried two pending mutations for #100 -- the original update and the correction layered on top of it -- which the planner refuses without an explicit cancellation decision. That is the tool working as designed; a delta record is the wrong shape here, because an update's detail replaces the field wholesale rather than appending, so the correction would have landed a detail whose 'everything else in the earlier update stands' pointed at a record that had itself been superseded. Both pending records are cancelled with reasons, and one consolidated, self-contained #100 update replaces them. Its content is the earlier record's, with the provider-backed claim about the danger-level governance suppression proof corrected -- that fixture is Phase 0 and provider-free, and the stream route is already driven with mocked dependencies in tests/answer-stream-preview-order.test.ts. Reproduced the exact CI failure locally with LEDGER_WRITE_BASE_SHA set to the base sha from the failing run, then confirmed the same command passes: 'docs link check passed: 4789 repo path references resolve.' Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N8JUuufwbFHy8PsgbztmGN
Bugbot couldn't run - usage limit reachedBugbot 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_d6ceb4bd-a693-4fbe-8fa7-c6c1a3f8929d) |
Bugbot couldn't run - usage limit reachedBugbot 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_826e99c6-1c5e-4364-81ad-7469de493f63) |
Bugbot couldn't run - usage limit reachedBugbot 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_f343d0f7-dcb0-4a3c-bbda-5b7049c8de01) |
Bugbot couldn't run - usage limit reachedBugbot 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_0cdb4a25-28a0-41e0-a205-b2cc7851537b) |
2 participants
Summary
main.#100's ledger row (2026-08-21) says both incremental-evidence flags defaultfalseand that the remaining offline work is browser proof of the client render path.docs/verified-answer-incremental-delivery-design.md, updated six days later, records Phase 1 as shipped with both flags defaulting ON, and namestests/answer-progress-ui-smoke.spec.tsas closing that browser-proof gap.src/lib/env.tsdeclaresRAG_INCREMENTAL_EVIDENCE_PREVIEWwith.default("true"), andsrc/lib/client-env.tsreturnsvalue !== "false", so an unsetNEXT_PUBLIC_RAG_INCREMENTAL_EVIDENCE_PREVIEW_RENDERrenders the rail. The.env.exampleline is commented because unset means ON, not because the default is off.src/components/clinical-dashboard/answer-status.tsx, which still told readers the preview "is off by default, so today the line and the prose placeholder are the whole wait". That contradictedsrc/lib/client-env.tsand would have misled the next person to touch the component.#100to the two things that genuinely are uncovered, with the distinction between them stated: thefalserollback is inlined at build time andClinicalDashboardcalls the gate with no argument, so a browser assertion needs a second build and may be right to leave at unit level; the danger-level source-governance suppression insrc/lib/answer-preview.tsis a server-only gate, and the browser spec drives the rail through a mocked SSE stream, so no Playwright test can observe it at all — that gap is route-level, not browser-level.This PR ships no new product code. Its value is the accuracy of the record, so every claim in it is cited to a file and line and was checked against the tree.
Verification
npm run ensure— dev server started; the printed URL was used, no port assumed.tests/answer-progress-ui-smoke.spec.ts, chromium:npm run check:ledger-write-discipline—Ledger write discipline passed for 45a3dcacb54a..HEAD.npm run check:outstanding-issues—[snapshot] in step with data/outstanding-issues-snapshot.jsonnpm run format— run, and the result is committed.rag-retrieval-reviewersubagent on this diff before push. It audited every file:line citation in the comment, the inbox record and the commit message; all resolved. Its two accuracy notes (a citation pointing at the governance call's arguments rather than the suppression itself, and the browser-vs-route framing of the residual gap) were both applied before this push, because a merged inbox record is immutable.Note the spec does not match
tests/ui-*.spec.ts, which is why earlierui-*searches missed it.playwright.config.tsnames it explicitly in bothproductionSpecPatternandtestMatch, so it runs inverify:uiand in the full release matrix.UI verification not run:
npm run verify:uiin full was not run. The only source change is a block comment, which cannot alter rendering, and the two journeys that exercise the changed component's own surface were run directly and are quoted above.The
pr-policyclassifier was run offline against this diff's real file list and returnsclinicalRisk: false, operationalRisk: false, ragRanking: false, migration: false, ui: true, so no governance preflight section is required.Risk and rollout
Notes
Do not merge this PR yet. It is a draft and is labelled
holdanddo-not-merge.Approval still needed, and from whom: nothing for this PR's own content — it carries no migration, no provider call, and no behaviour change, so it is the one of these four that is technically merge-safe on its own. It is held only because this session was asked to leave all four for the owner (Josh) to review together. Josh is the approver.
Out of scope and still outstanding: the provider-backed Phase 2 acceptance gates in
docs/verified-answer-incremental-delivery-design.md, which need his approval and provider spend.After this lands,
npm run issues:reconcileapplies the queued inbox record to the canonical ledger from its own serialized branch.🤖 Generated with Claude Code
https://claude.ai/code/session_01N8JUuufwbFHy8PsgbztmGN
Generated by Claude Code
Note
Low Risk
Documentation and comment-only changes with no runtime, API, or RAG behavior changes.
Overview
This PR updates the outstanding-issues inbox for #100 so the ledger matches what is already on
main: incremental evidence preview flags default on, the UI journey intests/answer-progress-ui-smoke.spec.tsalready exercises the render path, and the remaining gaps are narrowed to offline work (mocked/api/answerroute test for danger-level governance suppression) rather than incorrectly labeling that check provider-backed. It cancels superseded inbox records that carried the wrong provider claim or dangling references, in favor of one consolidated self-contained update.The only code touch is a comment fix in
answer-status.tsxonAnswerProgress: it no longer says the preview rail is off by default and instead documents thatNEXT_PUBLIC_RAG_INCREMENTAL_EVIDENCE_PREVIEW_RENDERis on unless set tofalse, consistent withsrc/lib/client-env.ts.Reviewed by Cursor Bugbot for commit edc784b. Configure here.