docs(issues): close #310 — the fuzzy catalogue cap already landed on main

[BigSimmo]

Summary

Read this first: the assigned work was already done, and this PR contains no source change. The task was to re-land the fuzzy catalogue matcher and cap the term.length >= 8 tier at 1 edit. That landed on main as 247a359 ("Add tappable phone suggestion ticker and conservative fuzzy catalog search (#1851)", 2026-08-14 02:03 +0800) about eight hours before the session started. src/lib/catalog-search.ts is untouched here. This is a ledger correction only.

• Verified the fix is present, by measurement rather than by reading the source — the method that originally opened #310. typoDistanceLimit is now term.length >= 5 → 1, 0 below, with no >= 8 two-edit tier at all, so the window that produced the cross-drug hits no longer exists. The hazard pairs fluoxetine → Duloxetine and prednisone → Prednisolone (and both reverses) return 0; intended recovery setraline, olanzepine, clozpaine, monitroing, fluoxetne, prednisne, schizophrnia, lithum all return 1; all five guards (SSRI/SNRI, ADHD/ODD, citalopram/escitalopram, clozapine/clonazepam, quetiapine/olanzapine) return 0. With the exact and near-match records both present, fluoxetine ranks ["Fluoxetine"] and prednisone ranks ["Prednisone"]. Fuzzy search was not removed, per the row's stop rule.
• Verified the owed test is present.tests/catalog-search.test.ts carries "never cross-matches a distinct drug two edits away, even with both records present", citing #310 by number, plus a dedicated tests/catalog-search-drug-name-regression.test.ts. Both pass: Test Files 2 passed (2), Tests 19 passed (19).
• Queued cancel of inbox request 8621298b. It asserted the matcher was absent from main and instructed that #310 not be closed on that ground. The ground no longer holds.
• Queued done for #310 carrying the evidence above.

Why the cancellation was necessary

The pending inbox requests for #310 had inverted against reality. Request e1506952 ("closeable when #1851 merges") was cancelled by 31650c87 at 05:48 on 2026-08-14 — after the merge at 02:03 — which left 8621298b ("NOT REACHABLE ON MAIN … do not close this row") as the sole surviving mutation. mutationConflicts in scripts/ledger-inbox.mjs only throws when two or more mutations for one id survive cancellation, so the next issues:reconcile would have applied that stale text quietly, stamping "the matcher is gone, do not close" onto a row whose code is present, capped and tested. A third mutation could not simply be added — it would trip the conflict guard — and e1506952 could not be revived, since ledger-inbox.mjs forbids cancelling a cancellation. Cancel-then-close was the only shape that reconciles.

Both requests were created through scripts/ledger-inbox.mjs, never hand-written. docs/outstanding-issues.md is deliberately untouched — reconcile owns it.

Verification

• npm run check:outstanding-issues — Ledger inbox check passed: 77 pending request(s), 19 applied. / Outstanding-issues guard passed: 314 rows (115 open, 199 archived), unique ids, next-id=317 above the highest, no merge driver, no ids deleted from base d47aa6d08b9b.
• npm run check:ledger-write-discipline — Ledger write discipline passed for d47aa6d08b9b..HEAD.
• npm run check:branch-review-ledger — Branch review ledger guard passed: 880 live table records + 1206 archived + 58 immutable …
• npm run docs:check-index / docs:check-inventory / docs:check-scripts / docs:check-links — all passed (1732 repo path references resolve, 473 npm-run reference(s) resolve to real scripts)
• planRequestBatch over all 77 real pending requests — no conflict throw; active mutations: 63, cancellations: 7 / ACTIVE MUTATIONS FOR #310: 1 -> done 00428ff0 / 8621298b cancelled: true. This is the specific failure the change exists to prevent, so it was proven rather than inferred.
• applyRequestBatch simulated in memory against the real ledger (nothing written) — succeeds, and #310 moves to the resolved format carrying the outcome.
• npx prettier --check on both new files — All matched files use Prettier code style!

Verification not run: npm run verify:pr-local — the container runs Node v22.22.2 against a repo requiring 24.x and has no node_modules (engine-strict would reject an install on this major), so check:runtime fails at resolve-tsx-cli before the plan starts. Its dry-run selects this diff as recognised low-risk docs scope — no lint, typecheck, unit suite, build or RAG checks — and every selected check that does not need tsx was run individually and passed, listed above. format:changed and sitemap:check fail on the same missing-dependency cause; Prettier was verified directly on both files instead, and the diff touches no routes. CI runs the real gate.

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

Risk and rollout

• Risk: Very low. Two additive JSON request files; no source, schema, or configuration change. The worst case is a ledger row carrying wrong prose, which a later inbox request corrects. Reconcile is a separate serialized operation that this PR does not perform.
• Rollback:git revert this commit. Since the requests are additive and unreconciled, reverting before the next issues:reconcile leaves #310 exactly as it is on main today.
• Provider or production effects: None. No source, runtime, deployment, Supabase, or OpenAI surface is touched, and no provider-backed command was run.

Clinical Governance Preflight

Not applicable — measured, not assumed. classifyPullRequestFiles returns clinicalRisk: false, operationalRisk: false, ragRanking: false, ui: false for both changed paths. The preflight would have been required had this PR edited src/lib/catalog-search.ts as the task anticipated; it does not, because that work is already on main. No RAG impact: line is required either — nothing under src/lib/rag/** is touched, and catalogue ranking is not the pgvector retrieval path.

Notes

• Deliberately not fixed here, flagged for the owner of the merge-loss row: pending requests f23c14ec and 829597d4 still assert that PR Add conservative typo-tolerant fuzzy matching to catalogue searches #1800's content is absent from main. The merge-loss finding itself stands (acf78bf really did drop it), but the "absent from main" claim is now stale for the catalogue-search portion.
• Minor and non-blocking: all four cancel requests in the inbox write the action value's third character as a unicode escape rather than a literal c. ledger-inbox.mjs serialises with JSON.stringify, which never escapes ASCII letters, so none of them came from the tool. It is identical across every cancel file, so it reads as a quirk of whatever writes cancellations rather than a one-off, and it parses to cancel either way.
• This branch is a few commits behind main (which advanced mid-session); the diff is two new files, so no conflict is possible.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_0122UC4BL5R39kz41WbBYcPj

---

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:55 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: 9b0f66d0-e0d8-4ad6-ba4b-3084cc7e0037

📥 Commits

Reviewing files that changed from the base of the PR and between f89fbcc and 5fc8c0d.

📒 Files selected for processing (1)

• docs/outstanding-issues-inbox/00428ff0-1b45-4066-9838-94216fa8b6eb.json

---

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

[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 #10777 (cancelled).

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