feat(server): tell the parent when a delegated task pauses on a request

[saphid]

What changed

A delegated child can stay running while waiting for an approval or question, so its parent previously received no completion and could wait indefinitely. This change exposes that pause and notifies the parent:

• task_status reports blocked_on_request and the pending request IDs and kinds.
• delegate_task with mode: "wait" returns when the child pauses, without claiming a timeout, and hands later result delivery to the completion wake.
• Async children notify their parent once per task for approvals and once per question. The existing notification row links to the child thread.

Notices tell the parent to check current task status before acting because a queued observation can be stale. Approvals still require a person in the child thread; a notice grants no broader permissions. The parent answers a question only when the delegation or the user's instructions settle the answer. Missing or closed owning-run cohorts suppress pause wakes, matching completion delivery: stopping the original delegating run prevents later child pauses from restarting it.

Pending-request reads use the existing thread/status index. The change adds no client renderer, permission bypass, or durable retry machinery. Web/Electron and React Native reuse their existing notification handling; actual client behavior remains unverified.

Verification

• Final focused server checks: 36 tests across five files passed, including approval/question deduplication, wait/resume behavior, answered-request suppression, failed enqueue recovery, stopped-parent suppression, and idle-parent new-run creation.
• The stopped-parent regression failed before the guard: a child pause created a notice and a new parent run. It passes after the repair. It seeds the state written by Stop and runs the real event listener; the actual Stop-button/provider flow has not been exercised.
• The idle-parent test proves that the stored notice owns a distinct nonqueued run. It does not prove a live provider session opens.
• Independent Claude Fable 5.1 review reran those 36 tests, five contract tests, server typechecking, and scoped lint/format/diff checks successfully. No blocking code findings on the frozen contribution. Lint retains one preexisting unused-variable warning. Local tests used Node 24.12.0, below the repository's declared 24.13.1 minimum.

Required live and UI proof is incomplete. No current before/after images or video are claimed. Still needed: real approval/question → idle-parent wake → response/resume; supervised mode: "wait"; Stop followed by a child pause; and notification links for multiple children in actual clients. This PR is not yet verified ready to merge.

Limits

• A failed enqueue is retried only when another request arrives. A child blocked on a question may never emit one. task_status still reports the pending request.
• A blocking wait that ends without upgrading its wake policy can lose a pause observed while the parent is active; that pause is not rechecked when the parent settles.
• A wait that returned a pause can still be followed by one notice for the next approval. Historical pause events are not replayed after restart.
• Stopping a run started by a pause notice does not close the original delegating run's cohort. A sibling approval or later question can therefore start the parent again. Closing that cohort would also discard later completion delivery; this narrower behavior is retained and disclosed.
• A pause notice already queued when the user presses Stop is held under the existing queue rules, not cancelled. Notification rows retain the text of the original observation after the child resumes.

Readiness repairs: GPT-6 Astra, Codex harness in T3 Code. Independent review: Anthropic Claude Fable 5.1, high reasoning, Claude Code harness through T3 Code.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR adds a cross-cutting delegated-task pause workflow that changes MCP results, wait semantics, parent notifications, and parent-run scheduling across the server. These existing-path runtime and user-visible changes are broader than a bounded additive adjustment and warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[juliusmarminge]

Note

This comment is posted by Julius' dot

The new approval/question notices and child-thread links have no current UI evidence, and the PR explicitly leaves the real pause → parent wake → response/resume flow unverified. The focused server tests are useful, but they do not establish that client interaction. Under verification requirements, please attach before/after notification screenshots and a short real-client recording covering wake/resume, supervised waiting, and Stop followed by a child pause, with the tested build and results, then request reconsideration.