feat(issues): give docs/outstanding-issues.md a writer, not just a gate

.claude/skills/issues/SKILL.md

@@ -56,6 +56,23 @@ paragraph; put the smallest next action in **Detail / next action**.
 
 ## Writing rules
 
+**Use the writer, not an editor.** Row mechanics are handled by
+`scripts/outstanding-issues.mjs`, the counterpart to the gate:
+
+```bash
+npm run issues:add -- --pri P2 --type issue --summary "…" --detail "…" --source "…"
+npm run issues:done -- '#151' --outcome "Resolved 2026-07-31 by PR #1494. …"
+npm run issues:update -- '#151' --detail "…"
+```
+
+It allocates the id from the marker and bumps it, appends into the **open** table (never the
+archive), moves rather than copies on `done`, reshapes to each table's width, escapes `|`, and
+re-runs the gate against its own output — refusing to write anything CI would reject. Hand-editing
+is what produced the wrong-table inserts, unescaped pipes and broken cell counts this writer exists
+to prevent; treat it like `ledger:append` for the review ledger. It does **not** solve id collisions
+between concurrent branches (see `#156` / `#168`) — that needs a different id scheme, not a better
+writer.
+
 - Keep the table format and column order exactly as in `docs/outstanding-issues.md`. One row per item.
 - Add a retained task to the recommended queue with order, acuity, capability, timing, estimate,
   gate, success criteria, verification, and stop rule. Reorder rather than duplicate related work.

docs/outstanding-issues.md

@@ -82,7 +82,7 @@ removed after current-main verification; it is not missing recommended work.
 | 34 | `#163` | A3 | High — frontend/UI | After or with `#162` | 0.5–1.5 days | Redesign `/services?q=` as Progressive Referral Workflow (direction B): H1 = query (not match count), progressive shortlist/compare (no always-on decision panel or giant step rail). Comps in `public/mockups/mode-page-redesign-2026-07/services-search/`. Verify referral shortlist still works; stop before changing Services home ModeHome. |
 | 35 | `#164` | A3 | High — frontend/UI | Product confirmed Favourites is hybrid dashboard+search (no ModeHome) | 1–2 days | Redesign Favourites as one dashboard + search page: recommended Search-Led Workspace (direction B) — persistent search, sets as chips, Continue + recent + table on empty query, in-place filter on typed query. Comps in `public/mockups/mode-page-redesign-2026-07/favourites-hybrid/`. Do not reintroduce ModeHome for Favourites. Verify desktop+phone; stop before splitting into separate ModeHome routes. |
 
-<!-- issues:next-id=168 -->
+<!-- issues:next-id=169 -->
 
 ## Open items
 
@@ -149,6 +149,7 @@ removed after current-main verification; it is not missing recommended work.
 | #165 | P2 | task | Adopt a consolidated answer-home notice block — the studies exist, nothing adopts them | **Outcome:** the answer hero states its safety obligation, its scope, and its verification requirement as one block in one voice. **Detail:** `/mockups/warning-consolidation` (PR #1437) diagnoses today's three stacked notices — the APP-5 privacy warning at 11px muted, a bare `/privacy` link, and an accent-blue `ShieldCheck` capability claim at 14px semibold — and shows the hierarchy is inverted: the least important line is the loudest, and two shields with opposite meanings sit ~40px apart. Three consolidations are drawn at 1440px and 390px. Recommended: **02 Safety card** on the hero (obligation on a warning-tinted top row, everything descriptive in one grey voice below) and **01 Assurance bar** on the docked composer — the same content model at two densities, so one component with a `density` prop covers both. **This is a governance change, not just a design one:** `PrivacyInputNotice` is the single site-wide APP-5 line and renders on the answer, documents and calculators composers, so all three move together; `tests/privacy-ui.test.ts`, `tests/ui-accessibility.spec.ts` and the phone-chrome reserve coverage all assert against the current markup and must change in the same commit; and the PR will need a full `## Clinical Governance Preflight` (the mockup PR correctly did not). **Third study (before/after):** `/mockups/answer-home-proposal` draws the concrete D-direction proposal as a full hero before/after rather than an isolated notice. **Second study (words only):** `/mockups/warning-line` answers a narrower brief — no icon, border, tint or background, one line where width allows. Six variants A-F; line counts measured from the rendered DOM, not asserted. Only B (middot clauses), D (obligation + verify) and F (compressed obligation) hold one line at desktop width, and **none fit one line on a 390px phone while the pinned APP-5 sentence stays verbatim** — 46 characters of obligation plus the 27-character link exceeds the ~60 available at 11px. Recommended there: **D**, the only compliant variant that is both one line and keeps weight-only hierarchy, reached by dropping the scope claim (a capability statement already visible on the answer itself). F fits best but rewrites the pinned obligation to \|No patient-identifiable information.\| and so needs the same privacy sign-off as `#166` plus a matching `tests/privacy-ui.test.ts` update. **Status:** PR #1437 was closed unmerged on 2026-07-30 as a deliberate pause during an owner-authorized ordered merge sweep, to be reopened at its queued place; branch `claude/warning-consolidation-mockups-09jyj7` is preserved and merged onto current `main`; these follow-up rows have been renumbered on each sync because `main` kept claiming the next ids while the PR was paused; the superseded numbers are deliberately not listed, since they now belong to unrelated rows. **Next:** decide block (02 + 01) versus line (D) direction, get wording sign-off for `#166`, then implement behind one component and run `verify:phone-chrome` before `verify:ui`. | session 2026-07-30; PR #1437; `/mockups/warning-consolidation`; `/mockups/warning-line` | 2026-07-30 |
 | #166 | P2 | issue | Answer mode ships no verify-before-use caveat; every other clinical mode does | **Outcome:** the surface that actually generates prose from retrieved sources says so, and says it must be checked. **Detail:** differentials carry "Clinical decision support only. Review before use.", prescribing carries "Confirm against source", specifiers carry a confirm-the-manual line, and calculators carry "Scores support clinical judgement — they never replace a full assessment." The answer hero carries neither an equivalent nor anything about generation: only the APP-5 privacy line and "Searches indexed clinical sources", which reads as assurance rather than caution. `CLAUDE.md` calls this repo a clinical reference prototype and explicitly **not** validated clinical decision support, so the one mode that synthesises text is the one most needing the caveat. Proposed wording, matching the registers above rather than opening a new one: "Answers are AI-generated — verify against the cited source before clinical use." **Independent of `#165`:** even keeping today's three-notice layout, the missing sentence is the gap. **Next:** clinical-governance sign-off on the exact wording, then add it to the answer hero (bundled with `#165` if that lands first). | session 2026-07-30; PR #1437; `src/components/clinical-dashboard/answer-status.tsx` | 2026-07-30 |
 | #167 | P2 | issue | `verify:pr-local` exits 0 when its own build step refuses to run | **Outcome:** the PR-local gate cannot report success for a step that never executed. **Detail:** on 2026-07-30 `npm run verify:pr-local` selected the conditional production build for a UI diff; `scripts/guard-next-build.mjs` printed `Refusing to run next build while Clinical KB dev server is running. Stop the dev server first, or set ALLOW_BUILD_WITH_DEV_SERVER=1` — and the aggregate still exited **0**, so the run reported green with the build never run. Caught only by reading the tail of the log; `npm run build` was then re-run separately with the server stopped and passed. Same family as `#120` (`verify:phone-chrome` exits 0 while reporting failed browser tests) and exactly the trap `AGENTS.md` names — "exit code 0 alone is not proof". The guard itself is correct and protects the dev cache; what is wrong is the aggregate treating a refusal as a pass. **Next:** make the refusal exit non-zero, or have `verify:pr-local` list skipped-but-selected steps in its closing summary so a green exit cannot be misread as a build. | session 2026-07-30; PR #1437; `scripts/guard-next-build.mjs` | 2026-07-30 |
+| #168 | P2 | rec | Sequential issue ids force every concurrent append to conflict | **Outcome:** two sessions can append to this ledger at the same time without conflicting. **Detail:** ids are allocated read-modify-write against the `issues:next-id` marker inside the file being edited, so two branches both read N and both write N. Because duplicate ids are unacceptable, a union merge driver is unsafe — .gitattributes says so explicitly — which is why this file deliberately has no driver and every overlapping append conflicts by hand. Manual resolution is where rows get dropped: PR #1490 was closed during one and took the only record of four snapshots with it (#152), and ids were renumbered under in-flight work three times in one session (#154, #155). The new writer (`scripts/outstanding-issues.mjs`) removes the mechanical errors but explicitly not this one. **Next:** replace the counter with a collision-free id (ULID, timestamp+suffix, or a content hash), keeping a short display number derived at render time if `#151` reads better than 01JQ…; then a union driver becomes safe to reinstate and concurrent appends stop conflicting at all. A larger variant is one row per file under `docs/issues` with the table generated, which the repo already does for `site-map.md`. **Stop:** do not reinstate `merge=union` while ids are sequential — that combination was tried in PR #1416 and removed for duplicating rows and the marker. Renumbered from this PR's original `#159` because `main` already used `#159` for the duplicated test-file-list finding. | session 2026-07-31; .gitattributes; #154/#155; PR #1524 sync | 2026-07-31 |
 
 
 ## Resolved / archive