chore(issues): reconcile 35 queued ledger requests

[BigSimmo]

Summary

• Applies the pending outstanding-issues inbox to docs/outstanding-issues.md as one serial transaction, from a fresh origin/main base (0011a058). This is the only path allowed to edit the canonical ledger; ordinary branches queue immutable requests and never touch it. 35 requests: 17 done, 7 add, 6 update, 5 cancel. Each moves verbatim into docs/outstanding-issues-inbox/applied/ as its audit record, so the whole change reads as 35 renames plus the canonical ledger.

• Reconciliation is all-or-nothing by design, so this is the whole queue rather than a chosen subset — verifyIssueReconciliation rejects a batch that moves only part of the inbox, precisely so a partial reconciliation cannot happen. One row carried competing mutations (#213, two done requests), resolved by the cancel already queued against one of them. No unresolved rows.

• Includes the five requests queued by PR Five ledger process and tooling fixes: dirty-tree gate, merge-loss detector, three plans #1944 that were still pending when it merged. That PR's substantive content landed in squash 372cb13f; its ledger requests were queued, as intended, for a reconciliation to apply. Specifically: closes #313 (the write-discipline dirty-tree refusal shipped and is on main); carries #211 forward with its re-measured 1,445 errors while preserving the 2026-08-12 deprioritisation judgment and its P3 priority; records the documented state of #168 and #258 without closing either, since neither asked only for a document; and opens #335 for the gap between the two merge-loss detectors.

• Records three handoff traps hit while doing the above (second commit, hand-written, deliberately separate so the generated transaction stays independently revertible). .claude/skills/newtask — the #292 open-PR duplicate check is denied, not merely unavailable, once the PR-handoff stop hook has armed in a session; the existing wording only covered "GitHub is unreachable", which reads as a network problem, so it now names git ls-remote --heads origin as the fallback and says not to unlock the hook for it. .claude/skills/handoff — --force-with-lease fails with stale info when restarting a branch whose PR merged, because GitHub deleted the remote branch and the local remote-tracking ref is stale; that presents as a lease violation inviting --force, when the fix is git remote prune origin and a normal push. .claude/skills/issues — the visual-register refresh is unavailable off the operator's Windows machine, stated where the command actually is, with an explicit prohibition on improvising a substitute renderer. Also queues one P3 request for the register drift itself, which is cumulative rather than a single-run failure.

• Ledger moves from 328 to 334 rows, and from 115 open to 99.

Verification

• npm run verify:pr-local on the final head — 21 gates, zero failures. (The skill edits widened the routed scope from the 11 gates the reconciliation alone selected.)

PR-local verification summary:
- completed: check:runtime, check:installed-lock-parity, format:changed, sitemap:check,
  docs:check-index, docs:check-inventory, docs:check-scripts, docs:check-links,
  check:branch-review-ledger, check:outstanding-issues, check:ledger-write-discipline,
  check:github-actions, check:ci-scope, check:gitleaks-pinned, check:ci-triage,
  check:pr-policy, check:gate-manifest, check:skills, check:pr-mergeability,
  check:verification-plan, test:ci-workflows
- failed: (none)
- not reached: (none)

The decisive line is the write-discipline audit, which independently recomputes the transaction and fails if the canonical file differs by a single byte from what those 35 requests produce:

$ npm run check:ledger-write-discipline
ledger write discipline self-test passed.
Ledger write discipline passed for 0011a058fd1d..HEAD.

Shape and id invariants:

$ npm run check:outstanding-issues
Ledger inbox check passed: 0 pending request(s), 129 applied.
Outstanding-issues guard passed: 334 rows (99 open, 235 archived), unique ids,
next-id=337 above the highest, no merge driver, no ids deleted from base 0011a058fd1d.

Worth recording: run before committing, check:ledger-write-discipline refused to report a verdict and named every uncommitted request file. That is the guard PR #1944 added doing its job on the first real reconciliation after it shipped — the gate can no longer print a pass over an uncommitted ledger edit.

npm run verify:ui not run: no UI, routing, styling or browser behaviour changed. Build skipped by the runner — no build-affecting source, config, package or container changes. The check:medication-lexicon-report failure reported on PR #1944 is gone, confirming PR #1941 (3d5cd7cb) resolved it at source.

Not run — visual register. .claude/skills/issues/SKILL.md refreshes an HTML register via a PowerShell script at an absolute Windows path, which does not exist in this Linux container. Per that skill, a stale visual artifact must not invalidate a valid canonical transaction: the Markdown source is current; the HTML register is stale and needs a refresh from the operator's machine. That limit is now written into the skill, and the drift is queued as its own P3 row.

A concurrent reconciliation landed first — read before merging

After this branch was pushed, PR #1954 (claude/ledger-reconcile-batch-2) merged the same queue, and main now already contains every one of these 35 requests in applied/, including all five inherited from PR #1944. That was checked rather than assumed, and the outcome is benign:

• This branch's docs/outstanding-issues.md is byte-identical to main's — same blob OID. Two independent reconciliations of the same queue converged exactly, which is the determinism the transaction design is meant to give.
• git merge-tree --write-tree origin/main a6d429b9 reports 0 conflicts, and the resulting tree has 334 rows, next-id=337, and no duplicate ids — the specific corruption AGENTS.md warns a ledger merge can produce.

So the reconciliation half of this PR is now effectively a no-op against main, and merging is safe. What remains genuinely new here is the second commit (the three skill fixes and the queued P3 register-drift request) plus this branch's review record. If you would rather not carry a redundant transaction commit, closing this PR and re-filing only the second commit is a legitimate alternative — but it is not required for correctness.

Risk and rollout

• Risk: low, but the blast radius is the whole queue rather than one row, so it is worth stating plainly. The transaction is machine-generated and machine-verified: issues:reconcile takes a cross-worktree lock, re-asserts the fresh base and clean tree inside that lock, writes a backup and a transaction journal, and rolls back on any failure. No request was hand-edited and the canonical file was not hand-edited. The second commit is hand-written but touches only agent-facing skill documentation and adds one queued request; it changes no product code and no canonical ledger row.
• Rollback: git revert either commit independently. Reverting the reconciliation restores the canonical ledger and returns all 35 requests to pending, since their moves are plain renames; reverting the documentation commit removes three skill notes and one queued request. Neither depends on the other.
• Provider or production effects: None. Documentation and ledger records only; no OpenAI, Supabase, Railway, hosted CI or production configuration is touched.

Notes

The branch was restarted from the latest origin/main rather than continuing the history whose PR (#1944) already merged, as the repo requires; that reset is also the precondition for reconciliation, which refuses to run unless HEAD contains the fetched origin/main.

I did not use GitHub's Update branch button and this branch must not be updated with it — AGENTS.md forbids it on anything touching the canonical ledger, because its auto-merge has previously produced duplicate rows and a next-id marker left below the highest live id. The merge-tree check above already proves the merge is clean without needing it.

One request from PR #1944 is deliberately absent: the cancel a8783c79, which targeted 0e47904b. That target was already consumed by the reconciliation in PR #1936, so the cancel is now invalid and re-filing it would fail validation. Nothing was lost — the surviving #211 update folds the cancelled request's deprioritisation text forward verbatim in substance.

The CodeRabbit comment on this PR is a usage-limit notice, not a review. Per AGENTS.md (#150), a cap notice must not be read as completed review coverage; this PR's automated review coverage is therefore the Codex connector and the CI gates only.

[supabase]

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 ↗︎.

[coderabbitai]

Warning

Review limit reached

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

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 12 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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8ad788b9-0b0a-4cad-bc0c-1f2df288d2fe

📥 Commits

Reviewing files that changed from the base of the PR and between adc5182 and b3a4324.

📒 Files selected for processing (16)

• .claude/skills/handoff/SKILL.md
• .claude/skills/issues/SKILL.md
• .claude/skills/newtask/SKILL.md
• docs/branch-review-records/26cca9a8fb9d8d74d7f1ee7930cfbe94b1ad5125cb1551eb036da361229c79c6.record.md
• docs/branch-review-records/f2f43e75cc44bf4d80d3e6bddb9f6844548e9f4d84b79b828a42a53505e3ff5c.record.md
• docs/outstanding-issues-inbox/0bbea6d5-4d5e-4e9a-bcba-bc129beeba3f.json
• docs/outstanding-issues-inbox/19762e55-fa25-41de-a5a2-7f4932a545fe.json
• docs/outstanding-issues-inbox/2b7856a5-fe32-49b8-9e3c-819d961784c6.json
• docs/outstanding-issues-inbox/4bc449a1-ec81-426d-aadd-8a78abec21cf.json
• docs/outstanding-issues-inbox/9b67dd0e-f11e-423e-be63-7e4d91f4dd82.json
• docs/outstanding-issues-inbox/d226dce3-76a2-4ccc-9723-5e7ca03a6c5d.json
• docs/outstanding-issues-inbox/d2e60a94-b12a-4502-a8b9-3dc8406cc8c8.json
• docs/outstanding-issues-inbox/ddef5391-d476-417f-b0c8-662e44c54f8b.json
• docs/outstanding-issues-inbox/ef62d13b-6852-4a12-a1d3-4d7e22ec1232.json
• docs/outstanding-issues-inbox/f3b63187-c295-4f6a-8ecd-602f348835c4.json
• docs/outstanding-issues-inbox/fbfe982f-cd2f-49c9-a94e-908a99efa6b8.json

---

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 93365d6e4e

ℹ️ 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".

[BigSimmo]

Final review summary

• Final reviewed head: b3a432410f908f0e9f8f82827910274a3b677f8a; base at review: adc5182a7b78f0c92eb0d2b6845fcebdc4b6bab7. GitHub shows the PR was externally merged as 5e5938df5770f345f20e36f80e35278f25494cea; I did not perform that merge.
• The branch update had a clean merge tree and contains its required base. The two confirmed P2 ledger findings were fixed via immutable, validated inbox requests; malformed audit requests were cancelled rather than rewritten.
• Independent manual adversarial review was completed. Both review threads were replied to and resolved; no actionable threads remain.
• Decisive offline checks passed: ledger write discipline, outstanding-issues, docs links, skills, PR policy, CI scope, merge-loss self-test, and git diff --check.
• Exact-head required CI is green: CI, SAST, and Secret Scan all succeeded on b3a4324. No advisory failure is blocking this PR.
• Residual risk: the queued ledger requests remain pending until a later fresh-base serialized reconciliation, by repository design.

The PR was not merged by Codex. Final merge is left to the user.