chore(issues): reconcile the four rejected-closure corrections

[BigSimmo]

Summary

• docs — applies the four requests merged in PR docs(issues): record why three closures were rejected, and that #231's instrument now exists #1957 to the canonical ledger. Queueing a request does not change docs/outstanding-issues.md; only a serial reconciliation does, and the corrections are not actually delivered until they reach the file the SessionStart hook reads back to every agent. This is that step.
• 4 update requests, no cancellations, zero live same-target collisions (targets #231 #235 #237 #238). Scan run before applying, as on every batch — planRequestBatch dedupes on request UUID rather than target row id, so it is the operator's check, not the tool's.
• Row counts are deliberately unchanged: 99 open / 235 archived. These are detail rewrites, not archives. #235, #237 and #238 stay open on purpose — the closures were refused and the rows now say why. Inbox goes to 0 pending / 133 applied.

What each row gained:

Row	Now records
#235	The closure attempt citing ADOPTION.md §7.1, its cancellation ("executable evidence does not replace the requested proof shots"), and that §7.1's own first line says it records evidence rather than image baselines. Stop rule: never close on unit/DOM/contract evidence.
#237	The closure attempt citing a jsdom 320px assertion and its cancellation. Notes that jsdom does not lay out text, so the assertion proves the string is present, not that it fits. Stop rule: only a real browser at 320px settles it.
#238	The closure attempt citing tests/sheet.dom.test.tsx and its cancellation. Notes the risk is ancestor-scoped CSS/contain/transform on five host surfaces, invisible to any Sheet component test. Stop rule: the question is about the hosts, not Sheet.
#231	That scripts/probe-generation-quality.ts now exists (a3bc4da) and PR #1861 was adjudicated superseded for phase 1, so the stale "Next: instrument and reproduce" no longer sends anyone to rebuild a tool that exists or review #1861 as the live fix.

All three of the first group also dropped their stale IN FLIGHT — do not start prefix; #1841 and #1842 have merged.

Verification

• npm run verify:pr-local

Ledger inbox check passed: 0 pending request(s), 133 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 b58a2359eede.
Ledger write discipline passed for b58a2359eede..HEAD.
- failed: (none)
- not reached: (none)

A --dry-run preceded the write and reported the same 4 request(s). Post-apply spot check on the file itself: three rows carry CLOSURE ATTEMPTED AND REJECTED, one carries probe-generation-quality — matching the four requests exactly.

UI verification not run: no UI, routing, styling, or browser-behaviour change in this diff.

Risk and rollout

• Risk: Low. Four detail-cell rewrites and four request files moved to applied/. No archives, no id allocation, no application source, no dependency, no schema, no workflow.
• Rollback: git revert the single commit — it restores both the canonical ledger and the pending inbox, since request files are moved rather than destroyed.
• Provider or production effects: None. Reconciliation is entirely local.
• Not bundled with anything, deliberately: reconciliation runs on its own dedicated fresh-base branch and never as part of a product PR (docs/outstanding-issues-inbox/README.md:13).

Notes

• No ## Clinical Governance Preflight section: classifyPullRequestFiles returns clinicalRisk: false, operationalRisk: false, ragRanking: false, ui: false for docs/outstanding-issues.md and docs/outstanding-issues-inbox/**. #231 is a clinical-answer row but only its ledger text changes here.
• The visual register (ISSUES-LIST.html) is not refreshed — that runs from a Windows PowerShell script on the operator's machine. Per the issues skill a stale visual artifact must not invalidate a successful canonical transaction: the Markdown is current, the HTML lags until refreshed locally.

---

Generated by Claude Code

[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:20 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: dde922aa-19b2-46e1-bf20-b9f0074642e5

📥 Commits

Reviewing files that changed from the base of the PR and between eada299 and 50a0a48.

📒 Files selected for processing (2)

• docs/branch-review-records/2cdb103223cd78c8d29b3a26ffae52f385cd5e9fa87be7bbcb0fe5f75c369912.record.md
• docs/branch-review-records/332ea83963cbf2857a64df609c9722ca734364de32bf354d9092762d7a6e4786.record.md

---

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

[BigSimmo]

Final review summary

Final PR head: 50a0a48a72164e251820837a0c1b18501052bef1. The PR was externally merged as 0c0245b4af21c6f15ce391ab5bbbc5af0c4b3c9f; its final merge tree was clean and incorporated the then-current base.

Disposition: the branch’s four inbox requests and ledger corrections had already landed on main. A fresh-context Codex adversarial review verified the exact applied request blobs, found #235/#237/#238 identical, and confirmed that branch-first resolution would roll back newer #231 evidence. I merged the base preserving its canonical ledger, retained the existing immutable historical record, and added the required current-base ledger entry. No PR-introduced P0/P1 or reproducible P2 remains. There were no actionable review threads.

Decisive local checks: docs-link check (1776 references), ledger inbox check (12 pending/138 applied), ledger self-test, ledger guard, and diff check passed. npm run verify:pr-local was unavailable because tsx/cli is absent from the isolated worktree (Node 24.14.0); this is the only residual local-verification limitation.

Exact-head CI is green: Secret Scan, SAST, and CI 31824999642. Required Static PR checks and PR required succeeded; risk-inapplicable/advisory jobs were skipped. No blockers remain.

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