feat(ledger): make the recommended-execution queue correctable, and record three owner decisions - #2286
Conversation
… record three owner decisions The queue was the one table in docs/outstanding-issues.md that no writer could edit. `done` pruned rows and nothing else touched them, so a re-grade recorded against an Open-items row left the queue advertising the old acuity forever — and the queue is what an operator reads to decide what to start. The live instance (#M6JNR8): queue row 1 still presented #231 as A1 "immediate approved live investigation" into a retrieval budget the measurements had already closed. Adds `updateQueueRow` plus a `queue` inbox action (`npm run issues:queue`), so the correction travels through the same immutable-request + serial-reconcile transaction as every other ledger mutation — option (a) of the two the row offered, not the audited hand-edit path the guard exists to refuse. - Acuity, Capability, When, Estimate and Outcome are editable. Order and the ID(s) cell are not: Order is renumbered on every close, so a hand-set value would be discarded, and changing queue membership is an add or a done. - Queue edits fingerprint the QUEUE row (`queueRowFingerprint`), not the Open-items row, so an unrelated detail edit does not invalidate a pending re-grade and a concurrent queue edit does. - `mutationConflicts` namespaces queue targets separately, so re-grading an item and updating its detail row can land in one reconcile batch. Also queues the owner's decisions of 2026-08-22, with their documentation: - #CCZ4HB accepted as-is — CodeRabbit's cap stays, review from it is intermittent. AGENTS.md now records the measurements, that the Codex connector still reviews, and that no required check may be weakened to compensate. - #1K6T35 accepted as-is — PITR stays off, ~24 h recovery point accepted. The remediation plan's unsatisfiable "PITR restore point captured before any mutating phase" rule is replaced with what is actually achievable, scoped to this programme so the reindex plan's PITR stop condition is untouched. - #9X40BT measured: zero preview branches currently exist, so the uncapped branching cost is potential rather than active and nothing needs cleaning up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…its zero-cost levers out A separate session had already measured this issue in docs/decisions/ccz4hb-review-coverage.md (branch claude/preserve-review-coverage-docs, local and unpushed). Its finding changes what the closure means: the binding constraint is volume, not price — CodeRabbit's included reviews refill at 1/hour (24/day) against 25.4 PRs merged per day, and 24% of merged PRs changed only documentation while 16% changed only the repo's own record-keeping files. The owner's decision to leave the spending cap alone stands and is unchanged. But it decided the billing question only, so the two levers that cost nothing — skip documentation-only PRs, stop opening bookkeeping-only PRs — now live on their own row rather than being archived along with the cap decision. AGENTS.md points at the analysis before anyone acts on the accepted position, and no longer claims the Codex connector is simply unaffected: it reviewed #2278 on 2026-08-22, and it reported its own usage limit on #2113 on 2026-08-18. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ion's re-grade `docs:check-links` projects the ledger through applyRequestBatch, and that refused the batch: two pending mutations targeted #M6JNR8 — this PR's closure and request 993f7ca7 from a second session, which had independently re-proven the same defect (a probe commit changing queue row 1 from A1 to A2 was refused by check:ledger-write-discipline) and re-graded the row P2 -> P1 so it would be fixed sooner. The fix has now landed, so the row closes rather than being re-prioritised. Both requests are cancelled with reasons and the closure is reissued carrying that session's evidence verbatim, because requests are immutable and folding evidence in means replacing rather than editing. The re-grade is superseded, not rejected — it was correct, and it is the reason this was built. Also worth recording for the next reader: `npm run verify:pr-local` reported `failed: docs:check-links (exit 1)` in its own summary and then exited 0. The wrapper's exit code cannot be trusted; read the summary block. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 57 minutes Limit details: You’ve used the included review currently available. Your 90 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?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. 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 (21)
Comment |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
# Conflicts: # docs/scripts-index.md
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2f334f5a56
ℹ️ 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".
Resolves one conflict, in data/outstanding-issues-snapshot.json. Both sides regenerated that file: main via #2286's ledger work, this branch via the two inbox requests it queues. The snapshot is generated, so the conflict was resolved by taking main's version and re-running scripts/generate-outstanding-issues-snapshot.mjs rather than by editing the JSON, per the repo rule that generated files are regenerated with their own tooling. The regenerated snapshot carries both sides: 43 pending requests (main's plus this branch's two) and 78 open rows. check:outstanding-issues reports the snapshot in step with the ledger. No product code was touched by the resolution; the RAG predicate, its test, and the HANDOVER pointer are unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M4Xx767QUvVbdauUpmLDLG
Summary
The recommended-execution queue was the one table in
docs/outstanding-issues.mdthat no writer couldedit.
donepruned rows; nothing else touched them. So a re-grade recorded against an Open-items rowleft the queue advertising the old acuity indefinitely — and the queue, not the Open-items table, is
what the session-start hook surfaces and what an operator reads to decide what to start.
The live instance (
#M6JNR8): queue row 1 still presented#231as A1 — "Immediate approved liveinvestigation" into a retrieval budget the Phase 5 measurements had already closed. The
#231rowitself carried the instruction
INCONSISTENCY TO FIX AT RECONCILE, and it could not be honoured.This adds
updateQueueRowplus aqueueinbox action (npm run issues:queue), so the correctiontravels through the same immutable-request + serial-reconcile transaction as every other ledger
mutation. That is option (a) of the two the row offered — not the narrow audited hand-edit path,
which is the exact write
check:ledger-write-disciplineexists to refuse.Design decisions worth reviewing
pruneResolvedIdFromQueue, so a hand-set value is silently discarded by the nextdone. Re-ordering stays a separate, visible decision.checkIssuesvalidates against Open items. Changing queue membership is anaddor adone, not an edit.queueRowFingerprint)mutationConflictsnamespaces queue targetsThe collision this surfaced, and how it was resolved
docs:check-linksprojects the ledger throughapplyRequestBatch, and it refused the batch: twopending mutations targeted
#M6JNR8— this PR's closure and request993f7ca7from a secondsession, which had independently hit the same wall and re-graded the row P2 → P1 so it would be
fixed sooner. Its evidence, verbatim:
Both requests are cancelled with reasons and the closure is reissued carrying that evidence, because
requests are immutable and folding evidence in means replacing rather than editing. The re-grade is
superseded, not rejected — it was correct, and it is the reason this was built. The conflict
detector working on a real, unplanned collision is the best evidence the namespacing is right.
Owner decisions recorded (2026-08-22)
Three, all made by the repo owner in session and queued here rather than applied by hand:
#CCZ4HB— accepted as-is. The CodeRabbit spending cap stays; review from it is intermittent.AGENTS.md gains an "Automated review coverage" section with the measurements (skipped on fix(claude): make the session-start hook runnable, and give the agent config teeth #2113,
test(document-viewer): name the cause when render-ahead is never scheduled, and record the five unreproducible Windows failures #2252, test(codex-cloud): budget the shell-policy case for Windows Git Bash spawns #2255, test(http-readiness): widen the millisecond budgets Windows cannot hold, and record this session's findings #2256, docs(issues): record the review-bot budget exhaustion and two local-environment findings #2263, fix(medications): stop loperamide resolving as an opioid for interaction alerts #2278), the fact that the Codex connector reviewed fix(medications): stop loperamide resolving as an opioid for interaction alerts #2278 on 2026-08-22
but reported its own limit on fix(claude): make the session-start hook runnable, and give the agent config teeth #2113, and the standing prohibition on weakening any required check
to compensate.
#1K6T35— accepted as-is. PITR stays off; a ~24 h recovery point is accepted. The remediationplan's rule "PITR/backup restore point captured before any mutating phase" was unsatisfiable —
PITR is a paid add-on and is off, so the item read as met by default whenever nobody checked, which
is what happened through Phases 1–4. It is replaced with what is achievable: confirm and record the
latest daily backup timestamp, state what a restore would lose, and require a written tested
reversal path for anything that rewrites or drops data or policy objects. Scoped to this
programme only —
docs/superpowers/plans/2026-08-20-rag-ingestion-reindex.mdstill stops before aproduction re-index when PITR is disabled, and that is untouched.
#9X40BT— measured, not closed. Read-onlylist_branchesonsjrfecxgysukkwxsowpyreturnszero preview branches; the only entry is the default
main, which is the production projectitself. The uncapped branching cost is therefore potential, not active, and there is nothing to
clean up. The one remaining action is the dashboard limit, which no agent may change.
A fourth row is added, not closed: the two zero-cost levers from
docs/decisions/ccz4hb-review-coverage.md(skip documentation-only PRs; stop openingbookkeeping-only PRs). That analysis measured the binding constraint as volume rather than price —
included reviews refill at 1/hour against 25.4 PRs merged per day, and 24% of the last 1,190 merged
PRs changed only documentation while 16% changed only the repo's own record-keeping files. The
owner's decision settled the billing question; it did not settle those two, so they now live on
their own row instead of being archived alongside it.
RAG impact: none. No retrieval, ranking, selection, ordering, answer-generation,
match_*RPC, evalharness, or golden-fixture surface is touched. The diff is ledger-writer scripts, their self-tests,
generated ledger artefacts, and prose.
Verification
node scripts/outstanding-issues.mjs --self-test— "outstanding-issues writer self-test passed."node scripts/ledger-inbox.mjs --self-test— "ledger inbox self-test passed."npm run check:ledger-write-discipline— "Ledger write discipline passed for 7f29952..HEAD."npm run check:outstanding-issues— "in step with data/outstanding-issues-snapshot.json (78 open, 41 pending)".npm run docs:check-links— "docs link check passed: 2226 repo path references resolve."npm run verify:pr-local— 24 checks completed includinglint,typecheck,check:pr-policy,check:skills,check:gate-manifest;testfailed (see below).The new self-tests were mutation-tested rather than merely run. Each mutation below was applied,
observed to fail, and reverted:
QUEUE_EDITABLE.acuity2 → 3escapeCell→Stringqueuedispatch removed fromapplyRequestupdateIssue, exit 1queueRowFingerprint→ echo the request's own valueThe first pass of the rejection tests was a check that could not fail: without the guard the
lookup still threw, several frames later on a NaN index, so a bare
rejects()passed either way.They now assert the message. That is why
rejectsWithexists.Test failures — all four pre-existing
Test Files 3 failed | 706 passed | 3 skipped (712),Tests 4 failed | 8228 passed | 72 skipped.None are in the ledger surface;
outstanding-issues-writer,ledger-inbox-cancellation,ledger-inbox-remote-check,ledger-write-discipline,outstanding-issues-snapshotandissues-reportall passed.Three reproduce on a clean
maincheckout with this branch not present:The
gate-receiptspair are thecore.fileMode=falsetrap on this Windows checkout. The fourth,document-viewer-page-virtualization.dom.test.tsx > reads exactly one page ahead and one behind,passes in isolation on this branch (9/9) and fails only under full-suite load — a load-dependent
idle-callback flake already recorded as such, and this diff touches no React, DOM, or viewer code.
A gate that reported the wrong thing
npm run verify:pr-localprintedfailed: docs:check-links (exit 1)in its own summary block andthen exited 0. It did the same on the second run with
failed: test (exit 1). Had the exit codebeen trusted, a genuine failure would have shipped as green. Read the summary block, not
$?.Clinical Governance Preflight
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes
list_branchescall for#9X40BT.docs/outstanding-issues.mditself is not edited here. Every mutation is a queued immutablerequest; a separate fresh-base
npm run issues:reconcileapplies them after this lands.