fix(issues): derive queue prose from the row it cites, so a stale cell cannot misdirect - #1902
Conversation
…l cannot misdirect The recommended-queue entry for #231, the top clinical P1, told every session to "measure and fix the fast-route budget / generation timeout". #231's own detail records that approach as tested and rejected: the decisive 40-second probe completed generation in 25.272s (27.237s total) with route_deadline_exceeded false and still failed generation quality, so the budget is not the binding cause. The queue and the row had drifted, and the queue is the copy that gets read — .claude/hooks/issues-surface.sh prints it at every session start and scripts/issues-report.mjs serves it to /issues, while the corrected row detail is only seen by someone who opens the file. Re-correcting the cell was tried and cannot land. The ledger inbox has no request type that reaches the queue's Outcome cell, and check:ledger-write-discipline rejects a direct canonical edit, so the correction is unlandable by construction — verified by committing it and watching the gate refuse. SKIP_LEDGER_WRITE_GUARD only bypasses the pre-push hook, not the CI check, so that route pushes but can never merge. So the duplication is removed instead of re-synced, which is what #314 argued for: both consumers now take each queue row's prose from the cited row's own Detail cell. The queue keeps order, acuity, capability, when and estimate — the metadata that exists nowhere else. A composite ID(s) row has no single row to speak for it and keeps its own text. This fixes the whole class, not just #231: no future edit to a row's detail can leave the surfaced text behind, because there is no longer a second copy. The hook needed two passes over the file. The queue table is printed BEFORE "## Open items", so the obvious single forward pass reads every queue row while the lookup is still empty and silently falls back to the stale cell — which it did, on the first attempt, and looked like a working change. tests/issues-report.test.ts pins both halves and was mutation-tested: reverting the derivation fails it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuYJz8hauCsCdx8r4fXiZU
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:56 minutes 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 (2)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe queue parser and issue report now use matching open-item details for single-issue entries. Composite and unmatched entries retain queue text. Regression coverage verifies outcomes, metadata, and priority blockers. ChangesIssue detail propagation
Estimated code review effort: 3 (Moderate) | ~20 minutes Mergeability Score:⚪ Minimal · up to The change makes surfaced queue prose follow the cited row’s current detail, preventing stale guidance without changing ledger data or production configuration; no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuYJz8hauCsCdx8r4fXiZU
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:315199c16f
ℹ️ 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".
Uh oh!
There was an error while loading. Please reload this page.
Summary
#231, the top clinical P1, has been telling every session to pursue an approach that row itself records as refuted. It said "measure and fix the fast-route budget / generation timeout";#231's detail records that the decisive 40-second probe completed generation in 25.272s (27.237s total) withroute_deadline_exceeded=falseand still failed generation quality, so the budget is not the binding cause. The queue and the row are independent copies of the same prose, and they drifted..claude/hooks/issues-surface.shprints the queue at every session start andscripts/issues-report.mjsserves it to/issues; the corrected row detail is only seen by someone who opens the file.check:ledger-write-disciplinerejects a direct canonical edit — I verified this by committing the corrected cell and watching the gate refuse it.SKIP_LEDGER_WRITE_GUARD=1only bypasses the pre-push hook, not the CI check, so that route can push but never merge.order,acuity,capability,whenandestimate— the metadata that exists nowhere else. A compositeID(s)row has no single row to speak for it and keeps its own text.#314argued for ("deriving is better").Before / after, from the real ledger:
Verification
npm run verify:pr-local—completed: check:runtime, check:installed-lock-parity, format:changed, lint, typecheck, test, check:rag:fixtures, check:medication-interactions·failed: (none). Build skipped by the runner: "no build-affecting source, config, package, or container changes detected."npm run check:ledger-write-discipline—Ledger write discipline passed for a5f03ccc3390..HEAD(this PR makes no canonical ledger edit)npx vitest run tests/issues-report.test.ts—6 passedbash -n .claude/hooks/issues-surface.sh— syntax OK; hook executed end-to-end against the real ledger and its output inspectedrecommended: derived→recommended: queue) fails the new test —Tests 1 failed | 5 passed. The assertion is known to catch what it is for, not merely known to pass.UI verification not run: no UI surface is touched — the changes are a SessionStart hook, a report script, and a test.
Risk and rollout
## Open items, so a single forwardawkpass reads every queue row while the lookup is still empty and silently falls back to the stale cell. That happened on my first attempt and looked like a working change until I checked the output. It now makes two passes, and the comment says why.git reverton the single commit. No data or ledger state changes.Notes
No
## Clinical Governance Preflight:classifyPullRequestFilesreturnsclinicalRisk: false, operationalRisk: false, ragRanking: falsefor this file list. The clinical relevance is indirect but real — the misdirected cell was steering work on the clinical answer path.Follow-up this does not do: the queue's Outcome cells are now dead text that nothing renders. They should eventually be dropped from the table so there is no stale prose left to mislead a human reader, but that is a canonical ledger edit and has to go through a reconciliation branch. Worth folding into
#314.🤖 Generated with Claude Code
https://claude.ai/code/session_01DuYJz8hauCsCdx8r4fXiZU
Generated by Claude Code
Summary by CodeRabbit