Phase 1.1 — Record the decision to run hub unattended, amending ADRs 008 and 009

[ooloth]

Phase 1.1 of #327. The title numbering is the work order: take milestone issues in Phase N.M order. The one hard dependency is #331 on #330, recorded as blockedBy; the rest is sequence, not blocking. Read gh issue view 327 --comments for the plan of record.

Current state

An agent starting this milestone reads three accepted decisions and a vision promise telling them not to build it, with nothing recording that we changed our minds. ADR 008 decided "the TUI owns the refresh loop" and states as a consequence that "there is no background refresh when the TUI is not open." ADR 009 decided that "hub drops all scheduled and unattended runs. There is no claude -p invocation path, no cron trigger." vision.md states, under "What hub is not": "A notification system — pull, not push. I open hub when I want to triage; it doesn't interrupt me."

ADR 010's 2026-09-04 addendum already routed an unattended surface away from hub-cli and into its own surface, but it settled only where such a thing would live, not whether it should exist.

Ideal state

• A decision record states that hub runs an unattended surface, that the daemon owns refresh, and that the TUI becomes a client with no fetch path of its own
• The record names ADRs 008 and 009 as the decisions it amends, and states what changed since they were taken
• ADRs 008 and 009 carry a forward pointer to the new record, so a reader landing on either is not left with the superseded model
• vision.md no longer promises that hub does not interrupt, and says what it does instead
• The record's "Revisit when" names an observable condition rather than a date

Out of scope

• The notification delivery mechanism, the socket protocol, and the poll interval. Those are implementation choices inside later phases, not boundary decisions, and recording them early would make them read as load-bearing
• The two question files this milestone settled (should-the-active-set-backfill-immediately-or-wait-for-the-next-detection-pass.md and should-ranking-consider-importance-not-just-age.md). Both are reversible feature nuances rather than architectural boundaries, so neither becomes a decision record
• Renumbering or retrofitting ADRs 001–019 to the current template

Starting points

• docs/decisions/README.md — the template and the rules the record has to satisfy
• docs/decisions/008-tui-owns-refresh-loop.md — the decision being amended, including its stated reason for deferring a daemon
• docs/vision.md — the "What hub is not" section

QA plan

1. Read the new record cold, without this issue open — expect to understand why an unattended surface now exists and what it replaces, without having to open ADR 008 first
2. Open ADRs 008 and 009 — expect each to point forward to the new record
3. Search docs/ for "pull, not push" — expect no hits
4. Check the record's "Also update" boxes — expect none left unchecked
5. Read the "Rejected" section — expect each rejected option to name one disqualifying reason and what would have to change to reverse it

Done when

A decision record states that hub runs an unattended surface with the daemon owning refresh, ADRs 008 and 009 point forward to it, and vision.md no longer promises that hub does not interrupt.