issues: reconcile the nine queued ledger requests

[BigSimmo]

Summary

Applies the pending outstanding-issues inbox queue to the canonical ledger — the deliberately serialized step check:ledger-write-discipline requires, run from a fresh base off main at a1aa449ae (the squash of #2522).

Nine immutable requests, all created today through the CLI, none hand-written:

• Five verified closures — #0HYHTH (prohibited-language check scope), #PWZYY8 (lucide icon-aria lint rule), #XHADPV (stored per-section counts), #5YKAQ5 (publishable-key tracing fallback), #DVRZA4 (.prettierignore snapshot asymmetry). Each carries its own verification evidence against origin/main d1bb2c197; I did not re-derive those, and they are recorded as their authors wrote them.
• Four updates — #EG4Q7W, #59JT7W, #AGRAKQ, and #YTR84P.

Their audit records move to docs/outstanding-issues-inbox/applied/ unchanged. Open items go 75 to 70; pending goes 9 to 0.

#YTR84P is this session's own, and is why the reconcile ran now. The row claimed the WardFlowProvider pinned-clock fix existed only on an unpushed Windows branch and had to be carried across. It is on main, by two independent routes. It also said 40 initialNow call sites all passing NOW_ANCHOR (it is 51, four of them deliberately not), and that the Phase 6 morning page still carried the defect (it does not, and is not on main at all). The remaining work was recorded as a D5 pre-08:00 test; that test cannot be written as specified, because owner decision WB-DB-11 removed the fixed/live split and the component holding the sentence it would assert is exported but rendered by nothing. The row stays open, now describing a decision rather than a task.

data/outstanding-issues-snapshot.json was regenerated with the repo tooling rather than edited by hand, per #Y090R5.

Verification

• npm run check:ledger-write-discipline — the gate that matters here, since it enforces that the canonical ledger diff exactly equals the recorded reconciliation transaction:

ledger write discipline self-test passed.
Ledger write discipline passed for a1aa449ae369..HEAD.

• npm run check:outstanding-issues:

Outstanding-issues guard passed: 529 rows (70 open, 459 archived), unique display and durable ids,
collision-free allocation enabled, deprecated next-id marker ignored, no merge driver,
no ids deleted from base a1aa449ae369.
[snapshot] in step with data/outstanding-issues-snapshot.json (70 open, 0 pending)

• npm run format run and committed; npm run format:changed reports All matched files use Prettier code style!

Not run, with reasons: no lint, typecheck, unit suite, build or Playwright — this diff contains no executable file, so there is no plausible regression for those to catch. No provider-backed gate of any kind.

Risk and rollout

• Risk: Low. Documentation and generated-snapshot only; no source, test, script, schema or configuration file is touched.
• Rollback: Revert the single commit. The immutable request records are preserved either way, so nothing is lost.
• Provider or production effects: None.
• RAG impact: none — no retrieval, ranking, selection, chunking, scoring, source-rendering or answer-contract surface is touched.

Clinical Governance Preflight

• Source-backed claims still require linked source verification before clinical use
• No patient-identifiable document workflow was introduced or expanded without explicit governance approval
• 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 was checked when clinical decision-support behavior changed

Why this section is present on a ledger-only PR, and why every box above is genuinely true.

classifyPullRequestFiles marks this diff clinical-risk on the strength of one path, data/outstanding-issues-snapshot.json. The data/ prefix is where generated clinical snapshot exports live, so the rule fails closed over the whole directory. That is the rule working as designed, not a misfire to route around, and the correct response is to answer the seven items rather than narrow a safety classifier for one PR's convenience.

The boxes are checked because each is verifiably true of this diff, not to clear the gate. The diff contains no executable file at all — no source, test, script, schema, workflow or configuration — so every clinical surface those items name is untouched, and that is checkable from the six-file list rather than taken on trust. Item by item: no answer-generation, citation or verification path is touched, so the linked-source requirement stands unchanged; no document, upload, ingestion or access workflow is touched, and the ledger rows added are prose about repository housekeeping containing no patient data; no Supabase configuration, migration, environment value or client is touched, and the Supabase integration independently reported it ignored this PR because nothing under supabase/ changed; no key handling, authorization, owner-scope or query-privacy code is touched; no fixture, demo corpus or seed data is touched, and the one ward-flow subject discussed in the ledger prose is synthetic design scratch under src/app/mockups/ward-flow/**, which 404s in production; no source-governance, metadata or render-policy code is touched, so conservative degradation is unchanged; and the deployment classification was checked and is unaffected, because nothing in this diff can alter runtime behaviour.

Notes

• The one file driving the clinical-risk classification is a generated ledger snapshot, produced by npm run snapshot:issues rather than hand-edited. #Y090R5 already tracks that this generated file is a recurring conflict point between concurrent ledger PRs. Expect this section to be required on every ledger PR marked ready for review, for the same reason.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NiskRgeXeNRiU3npGP4M9f

[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]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: 87d6dfd0-f10f-45f8-9e73-55feb5c30ba3

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_3deb76fc-1712-4153-8f60-e1e10fe98360)

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-02T06:02:05.103583Z	f57ef2e	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.