[chuks-qua]

What

Before this change, a Coordinator that delegated a task with delegate_task heard nothing back. The child finished, failed, or waited on the user, and the Coordinator stayed idle until the user prompted it again.

Now the server wakes the Coordinator when a delegated task finishes, fails, is cancelled, or blocks on the user:

• An idle Coordinator gets a new turn whose prompt holds the task report.
• A running Coordinator gets the report as a steer, but only when the turn holds the task-tool lease and the provider can steer. Otherwise the report waits until the turn ends.
• A child blocked on a question or tool approval shows in the Coordinator's composer dock labelled "From ", and the user answers it there. The Subagents panel shows the child as Waiting.
• The timeline shows each wake-up as a "From " row with the status and a collapsible Prompt.

Each result is delivered once. A durable ledger on delegated_tasks records which result each Coordinator has seen:

on(task state change, turn end, boot)
  nudgeCoordinator (debounced 1 s, single flight, backoff on admission failure)
    candidates = tasks whose current notice key is not covered by notice_delivered
    select whole reports that fit 16,000 chars; leave the rest for the next wake
    claim(notice_claim) with compare-and-set
    steer into a leased, steerable turn | hold until the turn ends | send a new turn
    settle (claim -> notice_delivered) or return the claim on failure

A result the Coordinator already read through task_status, thread_wait, or its own task_cancel counts as delivered, so it is not sent again. A user Stop on the child still reaches the Coordinator. Stopping the Coordinator does not stop the child, and the later result is still delivered.

Verified with server tests for the ledger, wake service, steer delivery, and boot recovery, web tests for the dock, roster, and timeline row, and live Electron runs with Claude.

Closes #2217

Why

Users delegate work so they can step away. Without a wake-up, every delegation needed a manual "check on it" prompt, and a child blocked on an approval sat unseen in another thread.

UI Changes

Child finished. Before, the roster shows Done but the Coordinator stays idle:

After, the Coordinator wakes with a "From Count files" row and answers with the result:

Child blocked on the user. Before, the Coordinator thread shows no dock entry:

After, the child's approval shows in the Coordinator's dock and the roster shows Waiting:

After approving from the dock, the child finishes and the Coordinator wakes again:

Config Changes

None.

Review Notes

• Migration. 0097_parallel_madelyne_pryor adds nullable notice_delivered and notice_claim columns to delegated_tasks. It backfills notice_delivered for tasks that had already ended, so an upgrade does not wake Coordinators with old results. Older builds never read either column, so it is registered in COMPATIBLE_STEPS.
• Prompt injection. Reports come from other agents. The wake message opens with a line telling the Coordinator to treat them as data, not user instructions. A needs-input report tells the Coordinator not to answer the question itself.
• Known gap. The live run did not capture a structured question (Codex request_user_input) in the dock. The Codex child ran in Default mode, where the tool is unavailable. Tests cover the question path, and the tool-approval path was verified live.
• Known gap. The server-bootstrap.ts hooks that refresh the roster on child approval changes have no direct test. The service method they call is tested, and the live capture shows the roster moving to Waiting and back.
• Docs: the Coordinator's tool guidance now says it will be woken, so it does not need to poll.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}