notes: audit the options roadmap against the repos, not against itself

[JulienMartel]

What

An accuracy pass over notes/options-roadmap.md,
driven by an audit of every open - [ ] in §5 against the actual repos.

Three items had shipped and were never ticked, and one option family was
renamed out from under the whole document:

Box	Actually shipped
§5.9 rice-side nebelhaus.pounce.items	rice#149, 2026-07-30
§5.12 haus doctor detects FDA	rice#128
§5.2 Finder sidebar size follows ui.scale	rice#181
§5.4(a) multi-source install	rice#182 — which also renamed nebelhaus.apps → nebelhaus.roster

Plus rice#198 (hot corners + screenshots) recorded, closing §5.6's first two
groups, and a new §5.14 on the drift itself.

Why

§5.9 is the case that prompted this. The status block at the top of the file
already credited rice#149 by number, while the checkbox 600 lines below still
read "rice side, and it is the next cheap win in this section". Picking work off
the checkboxes — which is how the file is actually used — meant starting to
rebuild something that had existed for four days.

That is a documentation bug with a cost, so §5.14 records the mechanism rather
than just fixing the symptom. Two structural reasons this file drifts more than
an ordinary TODO list, both worth designing around instead of resolving to try
harder:

1. The work happens in four repos and the doc lives in a fifth. Nothing in
   nebelhaus, nebelung or pounce CI can see this file, so a PR that closes
   an item has no mechanical way to say so. Every other cross-repo seam in this
   project got fixed by making the upstream repo emit data (options-json,
   wm-bindings-json, ports.meta.json, §7) — this one is still prose on both
   sides.
2. Items ship out of phase, from the app side. §5.1's port metadata and
   §5.9's item schema both arrived from downstream repos that wanted the data
   structure for their own reasons. Phase 4 already notes that as a good thing,
   and it is — but it means a rice-side box goes stale without anyone in the rice
   touching the item.

The rule it leaves: the header summarises, the checkbox decides, and when they
disagree the repo settles it.

Two smaller findings that came out of the same pass and are recorded where
they'll be read:

• §5.4's tagged union lost on purpose, and the reasoning generalises. What
  shipped in roster is four parallel nullable source fields, not
  { source; package; }. A discriminated union reads better in a doc but is
  worse to merge, and merging is what a registry is for — parallel fields let
  two modules contribute to one entry under the module system's ordinary merge,
  while a union makes every contributor restate the discriminator and turns a
  partial contribution into a type error.
• Phase 0 is the one genuinely stalled phase, and its remaining item needs no
  code at all — the format, the guide and the four install sources all exist.
  That's exactly why it keeps losing to items that do.

Verify

Docs only — no code, no generated artefact, nothing for CI to check.

git diff main -- notes/options-roadmap.md

• Every ticked box names the PR that closed it, so each claim is checkable with
  gh pr view <n> --repo nebelhaus/nebelhaus.
• nebelhaus.apps now appears only where it's explicitly discussed as the old
  name; apps.*.workspace / apps.*.key are roster.*.
• Box count moves 67 → 71 done, 44 → 37 open, with 4 marked ◐ partial.

Watch-out

• §5.6's two new rows point at rice#198, which is open, not merged. If that
  PR changes shape or doesn't land, this file overstates by two groups.
• The audit covered §5's open boxes and the apps/roster vocabulary. It did
  not re-verify the already-ticked [x] boxes, so an item that shipped and
  was later reverted would still read as done.

🤖 Generated with Claude Code