docs(issues): queue the #DREDWA residual test-coverage gap raised in review

[BigSimmo]

Summary

Queues one inbox request recording the residual test-coverage gap that a Codex review raised against the #DREDWA closure in pull request #2217. One additive JSON file under docs/outstanding-issues-inbox/; no other file is touched and the canonical ledger is not edited.

The review argued #DREDWA had been closed prematurely, on two specific grounds. Both were checked against the code rather than accepted, and both turn out to be inaccurate:

• tests/repo-hygiene.test.ts contains fingerprints and closes ULID-display-id rows minted by reconcile, which drives applyRequest with action: "done" against the ULID display id #6BG9X2, asserts the row is archived, and asserts the stale-fingerprint path throws. The inbox done path is therefore exercised with a modern id, not only add.
• The all-digit case is covered where the original defect lived: scripts/outstanding-issues.mjs self-tests drive addIssue, resolveIssue and updateIssue against #041061 (done archives all-digit Crockford #041061), and scripts/check-outstanding-issues.mjs resolves issueRowFingerprint for #041061 with an explicit failure message.

#DREDWA therefore stays closed: its recorded failure mode — issueRowFingerprint returning null for Crockford locators, which made issues:done and issues:update unusable for every row minted since the ULID migration — is guarded by tests.

What the review did surface, and what this request records, is genuinely uncovered and narrower than the original row: the inbox update action is only ever applied against legacy #001, since the ULID test covers done alone; and scripts/ledger-inbox.mjs --self-test builds its done, update, cancel and reconcile fixtures entirely from #001, so the self-test shipped with the writer would not catch an id-scheme regression by itself. The request names both gaps, the two places to add coverage, and the focused command that proves it.

It is filed as a request rather than fixed inline because the fix is executable test code, which does not belong in a ledger-scoped change; it is a small offline job for its own pull request.

Verification

• npm run check:outstanding-issues — Ledger inbox check passed: 5 pending request(s), 438 applied. and Outstanding-issues guard passed: 411 rows (61 open, 350 archived), unique display and durable ids, collision-free allocation enabled, deprecated next-id marker ignored, no merge driver, no ids deleted from base e2de814ebdb6.
• npx prettier --check on the added file — All matched files use Prettier code style!

UI verification not run: no executable product code, route, component, style or browser behaviour is touched.

Risk and rollout

• Risk: Very low. One additive, immutable request file. Nothing is applied to the canonical ledger until a later serialized reconciliation runs, and this change cannot alter any existing row.
• Rollback: git revert this pull request, or delete the request file before reconciliation runs.
• Provider or production effects: None.
• RAG impact: none — no file under src/lib/rag/, no retrieval RPC, no ranking configuration, no eval harness and no golden fixture is touched.

Notes

The review thread on pull request #2217 has been answered with the same findings and resolved. Branch claude/ledger-reconcile-2026-08-21 was recreated by a push that raced the squash-merge of #2217; it carries no unmerged content and can be deleted.

🤖 Generated with Claude Code

[coderabbitai]

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:5 minutes

Limit details: You’ve used the included review currently available. Your 87 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: 753a0ecc-aa1e-471b-a3dd-5ae107725f21

📥 Commits

Reviewing files that changed from the base of the PR and between e2de814 and 8f4a604.

📒 Files selected for processing (1)

• docs/outstanding-issues-inbox/0de7c846-b53f-42e5-ab1d-fe43135c1eef.json

---

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

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