docs(handoff): mark the 2026-08-05 list-handler run complete

All three brief tasks and the nine-child Usage Monitor unit are merged and main
verified green. Correct section 5: "exited with code 1 and no result" is a
catch-all, not a CLI crash — max_turns (sonnet presets default to 30 because
app_settings.model_presets is NULL) and the account session limit both surface
through the same message.

docs/handoff-list-handler-2026-08-05.md

@@ -1,7 +1,68 @@
 # Handoff — List-handler run on list "Claude do", 2026-08-05
 
+> **✅ COMPLETED 2026-08-05 (follow-up session).** Everything in §1 and §2 is merged and `main`
+> verified green. Read §0 below before §1–§8 — §5's diagnosis turned out to be **wrong** and the
+> rest is now history. Still nothing pushed.
+
 Repo: `C:\Private\ClaudeDo` · List id: `5f973815-050a-4136-94f0-1506a5d4560a` · Branch: `main` (nothing pushed)
 
+---
+
+## 0. What the follow-up session did (and what §5 got wrong)
+
+**All merged, `main` green after every step** (Worker 811/811, Data 143/143, Ui 292/292,
+Localization 16/16, builds 0 new warnings):
+
+| Merged | Task | Merge commit |
+|---|---|---|
+| §1 #1 | `9e307199` revert_merge + merge-SHA persistence | `3e7126b` |
+| §1 #2 | `0b2fbb48` post-merge verification gate | (conflict-resolved) |
+| §1 #3 | `8c1c2130` roadblock reply box | `519ea5a` |
+| §2 #42 | `c1df5b9a` Hub surface for usage | `6e2158d` |
+| §2 #43 | `f74b44d9` Usage pill | `7661129` |
+| §2 #45 | `06068810` gate thresholds in settings | `5115cfc` |
+| §2 #44 | `82488d2a` Usage Monitor modal | `338fc39` |
+| §2 #46 | `9c8cffe0` docs | `5872666` |
+| parent | `439a4daf` Usage Monitor unit | approved → Done (empty unit merge; all children already `Merged`) |
+
+Plus one hand-fix on `main`: `677a4c1` — `UsagePillViewModelTests` never set `Loc.Current`
+(defaults to a key-echo localizer) and only passed because another test class happened to
+install a real `Localizer` first; #44's new tests changed the ordering and broke it on `main`.
+Classic "both branches green, `main` red".
+
+### §5 is wrong — `"exited with code 1 and no result"` is NOT (only) a CLI crash
+
+It is a **catch-all** hiding at least three causes. The truth is in the run log's last NDJSON
+line (`{"type":"result", …}` → `terminal_reason` / `errors` / `result`):
+
+- **`max_turns`** — what actually killed #40 and #42. `app_settings.model_presets` is `NULL`, so
+  `ModelPresets.Parse` falls back to the shipping defaults, and **sonnet's default is 30 turns**.
+  `AppSettings.DefaultMaxTurns` (100) is only the fallback for an *unrecognized* alias, so it
+  never applies. Every task without an explicit `maxTurns` override got 30 turns.
+  → Fix used here: `set_task_config(taskId, model="sonnet", maxTurns=200)` before queueing.
+- **`api_error`** + `"You've hit your session limit · resets 1pm (Europe/Berlin)"` — the account's
+  5-hour limit, which took out #43's first attempt. Nothing to fix; wait for the reset, re-queue.
+- Genuine process death — the case §5 describes.
+
+§5's *operational* advice still holds and is what saved #42: **never `reset_failed_task`** on one
+of these; check the worktree, build/test it, then set the task `Queued` so the agent resumes its
+own session and commits. #42's worktree held a complete green implementation (773/773).
+
+Follow-up tasks: `ca6e55c0` (surface the real failure reason) is new; the turn-budget/presets side
+is already covered by the Idle task `2de2f008` (`b0317ec7` fixed only the unknown-alias half).
+
+### Still open
+
+- **Visual passes** (nobody has looked at these in a running app): usage pill in the footer *and*
+  the Mission Control header; Usage Monitor modal (gauges, tables, stale/blocked bands, dark/light);
+  the roadblock reply box; the verify-command field in the List Settings modal. See `docs/open.md`.
+- **`~/.todo-app/prompts/planning.md` still shadows the compiled default** (§7.1) — unchanged.
+- **`wait_for_task_change` is merged but not in the running Worker**, so it isn't callable over MCP
+  until the Worker is restarted. §3's sqlite poll was used instead.
+- One rough edge in the verify gate: if the verify command fails, the worktree has already been
+  removed and its state set `Merged` while the task stays `WaitingForReview` — re-approving is then
+  refused. Recovery is `update_task_status(..., "Done")` once `main` is fixed.
+
 Predecessor session ran the five-phase list handler over 11 briefed tasks and, along the way,
 absorbed the 9-child "Usage Monitor" unit. **Phases 0–3 are complete for the brief.** What is
 left is Phase 4 (review + merge) for three tasks, plus the Usage chain.