Skip to content

feat(ledger): make the recommended-execution queue correctable, and record three owner decisions - #2286

Merged
BigSimmo merged 8 commits into
mainfrom
claude/ledger-queue-edit
Aug 22, 2026
Merged

feat(ledger): make the recommended-execution queue correctable, and record three owner decisions#2286
BigSimmo merged 8 commits into
mainfrom
claude/ledger-queue-edit

Conversation

@BigSimmo

Copy link
Copy Markdown
Owner

Summary

The recommended-execution queue was the one table in docs/outstanding-issues.md that no writer could
edit. done pruned rows; nothing else touched them. So a re-grade recorded against an Open-items row
left 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 #231 as A1 — "Immediate approved live
investigation"
into a retrieval budget the Phase 5 measurements had already closed. The #231 row
itself carried the instruction INCONSISTENCY TO FIX AT RECONCILE, and it could not be honoured.

This 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. 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-discipline exists to refuse.

Design decisions worth reviewing

Decision Why
Editable: Acuity, Capability, When, Estimate, Outcome The cells that carry a judgement.
Not editable: Order Renumbered 1..N on every close by pruneResolvedIdFromQueue, so a hand-set value is silently discarded by the next done. Re-ordering stays a separate, visible decision.
Not editable: ID(s) It is the linkage checkIssues validates against Open items. Changing queue membership is an add or a done, not an edit.
Own fingerprint (queueRowFingerprint) A queue edit is optimistic against the queue row. An unrelated detail edit must not invalidate a pending re-grade; a concurrent queue edit must. Both directions are asserted.
mutationConflicts namespaces queue targets Re-grading an item and updating its detail row are two different rows and land in one batch. Without this, the ordinary case would need an artificial cancel/reland round trip.
Ambiguous target refuses An id cited by more than one queue row throws rather than guessing.

The collision this surfaced, and how it was resolved

docs:check-links projects the ledger through applyRequestBatch, and it refused the batch: two
pending mutations targeted #M6JNR8 — this PR's closure and request 993f7ca7 from a second
session
, which had independently hit the same wall and re-graded the row P2 → P1 so it would be
fixed sooner. Its evidence, verbatim:

a probe commit changing queue row 1 from A1 to A2 was refused by npm run check:ledger-write-discipline
with "does not exactly match the audited application of 0 moved inbox request(s) from the base", and
the probe was reverted

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:

A fourth row is added, not closed: the two zero-cost levers from
docs/decisions/ccz4hb-review-coverage.md (skip documentation-only PRs; stop opening
bookkeeping-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.

That analysis lives on claude/preserve-review-coverage-docs, which is local and unpushed. The
branch ref survives a worktree sweep, but nobody else can see it.

RAG impact: none. No retrieval, ranking, selection, ordering, answer-generation, match_* RPC, eval
harness, 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 including lint, typecheck, check:pr-policy,
    check:skills, check:gate-manifest; test failed (see below).

The new self-tests were mutation-tested rather than merely run. Each mutation below was applied,
observed to fail, and reverted:

Mutation Caught by
QUEUE_EDITABLE.acuity 2 → 3 "queue writes the Acuity cell"; "queue leaves Order, ID(s) and untouched columns alone"
Missing-row and ambiguous-row guards disabled "queue for an id with no queue row threw the wrong error: Cannot read properties of undefined"
escapeCellString "queue escapes pipes in new text"
queue dispatch removed from applyRequest throws in updateIssue, exit 1
queueRowFingerprint → echo the request's own value "stale queue request was not rejected"
Conflict key un-namespaced "a queue edit and an open-row update were treated as conflicting"

The 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 rejectsWith exists.

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-snapshot and
issues-report all passed.

Three reproduce on a clean main checkout with this branch not present:

tests/codex-cloud-setup.test.ts > pins connected retrieval mode and rejects unsafe shell-policy configs
tests/gate-receipts.test.ts > changes the signature when only the WORKING-TREE mode changes
tests/gate-receipts.test.ts > keeps both modes, so one cannot cancel the other

The gate-receipts pair are the core.fileMode=false trap 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-local printed failed: docs:check-links (exit 1) in its own summary block and
then exited 0. It did the same on the second run with failed: test (exit 1). Had the exit code
been trusted, a genuine failure would have shipped as green. Read the summary block, not $?.

Clinical Governance Preflight

  • Source-backed claims still require linked source verification before clinical use
  • No patient-identifiable document workflow was introduced or expanded without explicit governance approval
  • Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
  • Service-role keys and private document access remain server-only
  • Demo/synthetic content remains clearly separated from real clinical sources
  • Source metadata, review status, and outdated/unknown-source behavior remain conservative
  • Deployment classification/TGA SaMD impact was checked when clinical decision-support behavior changed

Notes

  • No migration, no schema change, no hosted mutation. The only provider contact was a read-only
    list_branches call for #9X40BT.
  • docs/outstanding-issues.md itself is not edited here. Every mutation is a queued immutable
    request; a separate fresh-base npm run issues:reconcile applies them after this lands.

BigSimmo and others added 3 commits August 22, 2026 19:36
… 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>
@coderabbitai

coderabbitai Bot commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your current included review allowance is based on your included PR review attempts over the past 7 days.

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 @coderabbitai review or push new commits to the PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: dbbcf6c4-5142-4399-a397-d0853fdb20c4

📥 Commits

Reviewing files that changed from the base of the PR and between d617473 and f6901da.

📒 Files selected for processing (21)
  • .claude/skills/issues/SKILL.md
  • AGENTS.md
  • data/outstanding-issues-snapshot.json
  • docs/database-remediation-plan.md
  • docs/outstanding-issues-inbox/337fc2e1-c50c-4f80-b865-58c76af4ff81.json
  • docs/outstanding-issues-inbox/54bbb5e0-a573-47e5-9daa-f7eedc4e6b73.json
  • docs/outstanding-issues-inbox/5bdfac3c-a3b4-4f00-869c-9a59cc756e11.json
  • docs/outstanding-issues-inbox/8db683bd-8be5-4f86-912a-bcf40eb0404c.json
  • docs/outstanding-issues-inbox/README.md
  • docs/outstanding-issues-inbox/acc8b0f7-b363-4888-9eb8-1712f48e2779.json
  • docs/outstanding-issues-inbox/ae7596a8-9064-4554-9530-4d145a02672c.json
  • docs/outstanding-issues-inbox/e0508db3-fdbc-4d76-9d6a-5e592b77d198.json
  • docs/outstanding-issues-inbox/f046ea4a-214f-4917-8740-4f56565fee0b.json
  • docs/outstanding-issues-inbox/fac29c48-c558-4249-97ed-c86e61b61b97.json
  • docs/scripts-index.md
  • package.json
  • scripts/check-outstanding-issues.mjs
  • scripts/ledger-inbox.mjs
  • scripts/outstanding-issues.mjs
  • tests/ledger-inbox-cancellation.test.ts
  • tests/outstanding-issues-writer.test.ts

Comment @coderabbitai help to get the list of available commands.

@supabase

supabase Bot commented Aug 22, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread scripts/ledger-inbox.mjs Outdated
Comment thread scripts/outstanding-issues.mjs Outdated
@BigSimmo
BigSimmo enabled auto-merge (squash) August 22, 2026 13:08
@BigSimmo
BigSimmo merged commit 93af96c into main Aug 22, 2026
42 checks passed
@BigSimmo
BigSimmo deleted the claude/ledger-queue-edit branch August 22, 2026 14:07
BigSimmo pushed a commit that referenced this pull request Aug 22, 2026
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant