docs(issues): capture the H5a residual and the ledger id-scheme test gap

[BigSimmo]

Summary

Two immutable outstanding-issues inbox requests from the packet G1 session (PR #2053, merged). No product code, no canonical-ledger edit — npm run issues:reconcile applies them later from a serialized ledger branch.

• P3 issue — the H5a residual outlives its row. G1 closed the legibility half: the fabricated similarity: 1 on document-summary rows is now tagged document_context, so it is no longer indistinguishable from a perfect cosine at any surface that reads a row. The governance question underneath was deferred, not answered — may a score nobody measured contribute to the confidence label a clinician reads? Because G1 also closes the paired question row #J912J9, that knowledge would otherwise survive only in docs/clinical-hazard-analysis.md and drop out of the queue anyone actually reads. The row records that no action is required unless a measured signal appears, and that the tag is what makes a future gate cheap.
• P3 rec — why a broken lookup survived the ULID migration.issueRowFingerprint matched only /^#(\d+)$/ and keyed on entry.number, which is null on ULID-backed rows, so issues:done and issues:update were unusable for every row minted since that migration — failing with "#J912J9 is not in Open items" about a row plainly in Open items. Fixed in PR feat(rag): tag document-summary rows with a document_context provenance origin #2053; what is captured here is the survival cause: the ledger writer's self-tests and fixtures use legacy #005-style ids almost throughout, so nothing ever drove a Crockford id through that path. The row also records the adjacent trap — Crockford's alphabet includes 0-9, so a display locator can be entirely digits (#041061) and is indistinguishable from a legacy id by pattern.

Both rows state the next action, not just the finding.

Verification

• npm run verify:pr-local

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
- failed: (none)
- not reached: (none)
Skipping build: no build-affecting source, config, package, or container changes detected.

The risk router selected light docs scope, so build and the unit suite were correctly skipped — this diff is two inbox JSON files plus a review record. The two gates that actually bear on it both passed:

Ledger inbox check passed: 18 pending request(s), 217 applied.
Outstanding-issues guard passed: 348 rows (97 open, 251 archived), unique display and durable ids,
collision-free allocation enabled, deprecated next-id marker ignored, no merge driver,
no ids deleted from base 7662720cb42b.
Ledger write discipline passed for 7662720cb42b..HEAD.

npm run format run and committed; whole-tree prettier --check . reports All matched files use Prettier code style!.

Request content was inspected after generation rather than assumed: both payloads parse, carry no unescaped |, and the regex in the second row renders as /^#(\d+)$/. An earlier generation of that request stored a double-escaped /^#(\\d+)$/; it was regenerated before commit rather than shipped, since these rows are read by people.

• npm run verify:ui — not run: no UI, routing, styling, or browser-behaviour file is touched.
• npm run verify:release — not run: ordinary handoff, not a release-confidence claim, and it is provider-backed.
• npm run eval:retrieval:quality / eval:rag / eval:quality — not run: no retrieval, ranking, generation, or answer-contract code is touched. All are provider-backed and unauthorized here.
• npm run check:production-readiness — not run: no clinical workflow, privacy, environment, Supabase, source-governance, or deployment behaviour changed. This PR adds two JSON request files.
• npm run check:deployment-readiness — not run: no deployment, startup, hosting, or rollout behaviour changed.

Risk and rollout

• Risk: Minimal. Inbox requests are inert until issues:reconcile applies them; the canonical docs/outstanding-issues.md is untouched by this PR. add requests allocate a fresh ULID at reconcile time and carry no baseRowFingerprint, so they cannot go stale the way a done/update request can.
• Rollback: git revert either commit independently, or simply delete the two request files before reconcile.
• Provider or production effects: None.

Notes

• Verified while preparing this branch: the two G1 closure requests already on main (#J912J9, #0MSNT8) still have matchingbaseRowFingerprint values against the current ledger, so they will apply cleanly at the next reconcile. I had flagged them as a possible staleness risk during the G1 session; that risk did not materialise.
• Also verified by content rather than by PR state (per #324/#330): G1 landed correctly on main — similarity_origin?: "cosine" | "synthetic_text" | "document_context" in src/lib/types.ts and the document_context stamp in rag-row-contracts.ts.
• The ledger record in the second commit points at 5c9b69a, the commit carrying the reviewed content; the record commit itself adds no reviewable change, so no superseding record is needed.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01VHxUr5eyRwrBiXKMoqoARq

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[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

Limit details: You’ve used all 1 included review currently available under your plan. You completed 100 included PR reviews in the past 7 days; at that activity level, included reviews refill 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?

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: 204dd6ee-9d64-4baa-8d30-a578aba20ed7

📥 Commits

Reviewing files that changed from the base of the PR and between ca989cb and 3e4485f.

📒 Files selected for processing (3)

• docs/branch-review-records/f76cd75e2ad4d6a67dd26e562753ca92c3cd2b63e321bef0fd8f7c226ee31714.record.md
• docs/outstanding-issues-inbox/7c1f5850-ddcd-47da-89ad-99314d0040fe.json
• docs/outstanding-issues-inbox/f6798c46-7f43-4481-8e02-bcac1bf9b262.json

---

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

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.