docs(issues): archive #113 and #114, open #117 for the stale spec reference

[BigSimmo]

Summary

Ledger closeout for the three defect fixes that merged this morning. #113 and #114 both landed but were still sitting in the Open items table, which puts finished work back into the recommended queue — the precise drift docs/outstanding-issues.md exists to prevent.

• #113 → archive. PR fix(mode-nav): size slots to their content so labels stop being clipped #1405, landed on main as 020c1260. The outcome record carries forward the one thing worth remembering rather than just "fixed": the ~8% threshold headroom is not padding. A measured-plus-one-pixel attempt (21/31rem) passed locally and failed CI by exactly 1px, because the variable face rasterises wider on ubuntu-24.04. A threshold calibrated to one machine's font metrics is calibrated to nothing.
• #114 → archive. PR fix(web-vitals): sample each route, grade the median, refuse a noisy cell #1407, landed as a73db460. Records both defects, including the one review caught second: samples is a free-text workflow_dispatch input, so samples=1 reached the grader as a valid integer and reproduced the exact single-run matrix the work removes — verified against the pre-fix logic at 0 breaches, 0 incomplete, printing the bold "Every mobile route is within" verdict.
• #117 opened for the loose end I flagged in fix(mode-nav): size slots to their content so labels stop being clipped #1405's own body and deliberately kept out of that diff: ui-therapy-nav-scroll.spec.ts cites a mode-nav-bar-anchoring.spec.ts that PR feat(nav): pin a shared ModeNav inside the universal header, wired to Therapy search #1390 left behind and that exists nowhere in the repo. Harmless at runtime; it just sends the next person looking for anchoring coverage to a file that isn't there.

#112 was already archived by PR #1410 (landed f5a76c5e) and is untouched here.

Bundled into one PR rather than three branches, per the ## PR bundling rule added to AGENTS.md in #1408 — append-only ledger edits are named there as the best bundling candidates.

Correction. The first revision of this description, and the #113 row itself, cited c2edda18 as #1405's merge commit. That was the PR's branch tip, which the squash merge discarded — git merge-base --is-ancestor c2edda18 origin/main fails, so a later operator could not have verified the claim. Caught in review; the landing SHA is 020c1260. Worth recording that this repo mixes merge strategies — #1407 and #1410 landed as merge commits, so their branch SHAs remain reachable, which is exactly what made the squashed one easy to get wrong.

Verification

Scripted, not hand-edited. The open table is seven cells and the archive is five; hand-editing across that boundary is exactly how #112/#113/#114 landed in the wrong table on 2026-07-29. The script converts the row shape explicitly and refuses to run if it does not find exactly two rows to move.

Row-set diff computed against origin/main rather than eyeballed:

ids before: 116  after: 117
lost: (none)
#112: archive -> archive
#113: open    -> archive
#114: open    -> archive
#117: absent  -> open
moved tables: #113,#114

• npm run check:outstanding-issues — the gate added for #112, now validating an edit to the file it was written to protect: 117 rows (55 open, 62 archived), unique ids, next-id=118 above the highest
• npm run verify:cheap — exit 0, Test Files 431 passed (431), Tests 4480 passed | 4 skipped (4484)
• npm run format:check — All matched files use Prettier code style!
• Landing SHAs re-verified with git merge-base --is-ancestor after the review finding above, rather than by reading the branch tip.
• No provider-backed gate run; none applies.

Risk and rollout

• Risk: minimal. One documentation file; no source, config, or CI change. The worst realistic outcome is a wrong resolution note — which is precisely what review caught here, and why the SHAs are now checked for reachability rather than copied from the PR head.
• Rollback: revert the commit; the two rows return to the open table.
• Provider or production effects: none.

Clinical Governance Preflight

Not applicable — the diff is one markdown ledger file. No ingestion, answer generation, search/ranking, source rendering, document access, privacy, or clinical output path is touched.

• Source-backed claims still require linked source verification before clinical use
• No patient-identifiable document workflow was introduced or expanded
• Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
• Service-role keys and private document access remain server-only
• Demo/synthetic content remains clearly separated from real clinical sources
• Source metadata, review status, and outdated/unknown-source behavior remain conservative
• Deployment classification/TGA SaMD impact checked — no clinical decision-support behaviour changed

RAG impact: no retrieval behaviour change — a documentation ledger only; nothing under src/lib/rag/**, clinical-search, ranking-config, the eval harness or the golden fixture is touched.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FvU8z73P6TXUXoYBqN5K1P

[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: 30 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: 265a9913-c07e-4da3-be20-363bb60a20d7

📥 Commits

Reviewing files that changed from the base of the PR and between 90b3e34 and 4157e78.

📒 Files selected for processing (1)

• docs/outstanding-issues.md

---

_{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: d5baf7e5f0

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