[Juliusolsson05]

Problem

Agents stop at the first natural pause, leaving multi-step goals half-finished until a human re-prompts (#1001). Provider Stop hooks cannot be the fix: Claude Code force-stops after 9 consecutive blocks (which kills every ralph/ultrawork-style mode — oh-my-claudecode #3138), and OpenCode has no block-capable Stop hook at all.

Implemented behavior

• New built-in MCP domain goal_loop (off by default, Settings row like Goal): goal_loop_start(goal, loopPrompt, maxContinuations?) — the agent writes its own continuation prompt when the user asks for a loop — and goal_loop_complete(outcome: done | blocked, summary) — instructed to fire only when the goal is utterly satisfied, with blocked as the honest needs-the-user exit.
• GoalLoopService (main process): subscribes to SessionManager semantic events, detects working→idle via reduceWorkingState (never continues while tools are pending or the agent is blocked on the user), and delivers the continuation prompt through deliverPromptToAgent with an iteration/budget header. Works identically for Claude, Codex and OpenCode — no provider hooks.
• Safety: budget (default 25) pauses before exceeding, never hard-kills; failed deliveries self-retry with backoff (a failed delivery means no turn_completed will ever rescue the loop) and pause with error after three rounds; control actions racing an in-flight continuation hand off through a pending flag instead of being dropped; state is durable so a crash surfaces as paused(interrupted) with one-click resume; session removal pauses as interrupted.
• Control surface: an always-on per-pane status strip (Goal loop · active · iteration 3/25 · <goal>) with Pause/Stop, a latched overlay (Cmd+Shift+Y) adding Resume/Raise cap, palette commands Goal Loop and Stop Goal Loop, and a controlGoalLoop IPC. Creating loops stays MCP-only; the renderer only steers.

Design decisions and tradeoffs

• Harness-owned loop, single mechanism — research summary in the spec; the send interface and turn-boundary observation are ours, so the loop is provider-agnostic and unbounded by provider overrides.
• Spec refinements (documented in the plan's self-review): loops keyed by sessionId (the actuator is deliverPromptToAgent(sessionId, …)), a latch + always-on strip instead of extending tldr's hold-peek PreviewKind (different data model; the loop surface's job is control), and domain teaching via MCP init instructions (workflows-domain pattern) rather than a managed product skill.
• Keybinding is Cmd+Shift+Y: Cmd+Shift+G is owned by global-dispatch and check:keybindings rejects unapproved overlaps.

Tests and verification

• New: 14 service/store/system tests (unit + real MCP-host system test driving start → idle → continuation → complete), prompt-builder and domain tests, 3 renderer pane/commands tests; catalog governance baselines pinned to 132 commands and the goal-loop feature reference documented.
• npm run typecheck clean; npm run check:keybindings clean; full npm test: 4417 passed, 1 failed — imageAttachment.test.ts corpus invariant, verified failing identically on main (pre-existing, unrelated).

Known limitations

• No stall detection: an agent that never returns a turn boundary event holds the loop in active (delivery failures are covered; silent stalls are not).
• Provider switch/reload mid-loop pauses as interrupted; resume is manual (conservative v1).
• complete(done) is the agent's claim, not a verified fact; the instructions put the verification burden on the model and the summary surfaces what it believes finished.

Fixes #1001