docs(issues): capture the merge-loss findings as inbox requests

[BigSimmo]

Summary

Four merge-safe ledger intake requests under docs/outstanding-issues-inbox/. No canonical ledger edit — docs/outstanding-issues.md is untouched, and the rows are allocated at npm run issues:reconcile after this lands.

• P1 rec — no gate detects a merged PR whose content is silently reverted by a later merge resolution. A blob sweep over origin/main (for each file a merged PR changed, compare origin/main's blob against the file's pre-merge parent blob; equality means the PR's change is gone) returned seven positives since 2026-08-06: Add conservative typo-tolerant fuzzy matching to catalogue searches #1800, Retire the --shadow-tight role alias onto the --e1 elevation tier #1803, Replace specifiers page breadcrumb/header with compact SpecifierToolHeader #1809, Route mode-specific Search/Find tabs to the universal search (/?mode=…) #1811, Remove cross-mode “Also matches in other modes” panel and related mounts/tests #1804, chore(deps): bump node from 24-bookworm-slim to 26-bookworm-slim in the docker-images group #1796, Tighten the mode-home hero rhythm and put its glyphs on the icon scale #1815. Six first show the wiped state at one commit, acf78bf ("Merge remote-tracking branch 'origin/main' into probe2-1815"), part of the PR Tighten the mode-home hero rhythm and put its glyphs on the icon scale #1815 unblock chain. The reverts took each PR's tests in the same stroke, which is why no gate went red. This is #311's ledger loss-detector generalised from docs to source.
• P2 task — re-land PR Add conservative typo-tolerant fuzzy matching to catalogue searches #1800 (fuzzy catalogue search), applying the #310 one-edit cap in the same commit rather than re-landing the known defect.
• P2 task — re-land PR Retire the --shadow-tight role alias onto the --e1 elevation tier #1803 (--shadow-tight retirement onto --e1). git grep -l shadow-tight over src/ on main still returns 67 files, which confirms the loss without relying on blob identity.
• update #310 — re-scoped. The cross-drug match is not reachable on main because the matcher is absent, not because it was fixed, so the row must not be closed and the fix belongs in the Add conservative typo-tolerant fuzzy matching to catalogue searches #1800 re-land.

Each item is its own request file and its own bullet, per the PR-bundling rule; all four are append-only ledger intake, no product behaviour.

Note on branch history: PR #1920 merged and its branch was deleted while this session held a stale remote ref, so the branch was restarted from origin/main and force-with-lease pushed. It now carries exactly one commit — the four JSON files — and none of #1920's already-merged history.

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.

Ledger inbox check passed: 23 pending request(s), 0 applied.
Outstanding-issues guard passed: 310 rows (114 open, 196 archived), unique ids,
next-id=313 above the highest, no merge driver, no ids deleted from base 63526ee5305e.
Ledger write discipline passed for 63526ee5305e..HEAD.

Additionally, the pending batch was dry-applied against origin/main's ledger to prove it reconciles cleanly: 23 requests, 114 open rows → 118, marker advances to issues:next-id=320, and checkIssues reports 5 problems before and 5 after — the same pre-existing prettier-ignore findings already present on main, so this change introduces none.

UI verification not run: no UI, routing, styling, or browser behaviour changed.

Risk and rollout

• Risk: none to product behaviour. The diff is four additive JSON intake files; nothing reads them until issues:reconcile runs.
• Rollback: delete the four files, or cancel individual requests through ledger-inbox.mjs cancel before reconciliation.
• Provider or production effects: None.

Notes

The two re-land tasks are deliberately filed as separate rows rather than one, because they need separate PRs: catalog-search.ts is clinicalRisk: true under classifyPullRequestFiles (it feeds medications.ts and prescribing) and carries a Clinical Governance Preflight, while the token retirement does not. Re-landing #1803 should also move the legacyShadowAliases measurement that open row #302 records as pinned at 220 against a measured 193, so #302 wants re-measuring afterwards rather than actioning on its current numbers.

The remaining five flagged PRs (#1809, #1811, #1804, #1796, #1815) are blob-evidence only. They are recorded inside the detector row as the sweep's output, not filed as individual re-land tasks, because a deliberate later revert is indistinguishable from a merge loss at blob level and each needs a human look first.

---

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:16 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: 7fea05fa-f18a-4502-bb8b-45338bd40f6b

📥 Commits

Reviewing files that changed from the base of the PR and between 804e931 and 2b03a75.

📒 Files selected for processing (6)

• docs/branch-review-records/575353430fcae06c9f21bdf48964297e47a5eba6285a23fe534414d846c8d51d.record.md
• docs/outstanding-issues-inbox/210e3db5-f863-4dc8-8d6e-4d75d044e661.json
• docs/outstanding-issues-inbox/31650c87-cfea-4a98-88e1-bd41b44c12b2.json
• docs/outstanding-issues-inbox/829597d4-698b-4cc2-9bf4-65310504cba3.json
• docs/outstanding-issues-inbox/8621298b-db72-4960-818a-66ae49a3977f.json
• docs/outstanding-issues-inbox/f23c14ec-e386-4910-ba60-fd488cc0a83b.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:6f1cd23a34

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

[github-actions]

CI triage

CI failed on this PR. Automated classification of the 2 failed job(s):

• Static PR checks — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.
• PR required — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.

Compared with main CI run #10733 (success).

Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger.