Rollout status

Phase 1 and Phase 2 source changes are merged; complete installed acceptance remains open. Phase 2 merged in PR #520 as 024232bae1e7ac1b7b47e8c1b7c3a48ce033cdda after exact-head/base GitHub CI, clean Codex review and zero unresolved threads. Local checks, development clients and model assessment are recorded below. No checkpoint, installation or restart was requested by this delivery. Reuse final #484; same-task Action ownership remains Phase 3. Each phase keeps its separate installed/real-use gate. A combined candidate may include #484 and both merged phases; no repair-only installation is required.

• Phase 1: Action inspection/status and safe parent mediation — implemented; Astra High and Opus 5.5 High reviews clean; local checks passed; PR #509 merged as bea65a384b25b364054fc14035f78747f24fb89a; normal installed mediation and representative separate-checkout real use observed; full installed acceptance remains open.
• Phase 2: visible waits and pause recovery — PR #520 merged as 024232bae1e7ac1b7b47e8c1b7c3a48ce033cdda; reviewed source a57aefcd20ba2467dce60e84e09171e17db16709, base 1556523eef088062a129484af6e859c349b25c56. The merged tree exactly matches the reviewed head and is contained in main. Source checks pass 694 tests across 18 files and all 36 typechecks; Quick CI, exact GitHub CI, clean Codex review, Astra integration review and matching-client native development QA passed. Current affected model controls pass 20/20 valid samples; broader failed samples/errors and source pins remain recorded. Installed checkpoint acceptance and representative real use remain open; merge does not check this box.
• Phase 3: one logical task across a child Action wait — later authorization required.
• Phase 4: child-owned PR watches — later authorization required.

A check means the phase has passed installed acceptance and representative real use, not merely merged. Record phase PRs, artifacts, validation results, and reassessment in this issue. Concrete machine details stay private.

An app-owned delegated child can launch a resumable Project Action, end its provider turn as instructed, and be reported to its parent as a completed task while the Action is still running. The published result can literally say the child is waiting for the Action. An automatic Action follow-up can later resume the same child thread without retaining the original task ownership, so the resumed work does not produce the expected final task result for the parent.

Reproduction

1. Delegate work to an app-owned child.
2. In that child, call run_project_action_and_resume for an eligible Action and end the turn.
3. Observe that the parent's task becomes completed before the Action finishes.
4. Let the automatic follow-up resume the child. Inspect the continuation run's delegated ownership and the parent's final result.

Retained execution records confirm both premature completion and successful same-child resumption without a later result transfer for the resumed work. This is not a general inability of children to launch Actions.

Expected behavior

The logical task remains unfinished while its owned Action or continuation is outstanding. Its automatic follow-up runs under the same task, and the parent receives one final result only after the work finishes. Ordinary turn-end notices can remain, but intermediate notices must identify a nonterminal wait and say when no parent action is needed. Parent polling is not a recovery mechanism.

The client and MCP status must distinguish a running Action from a finished command awaiting continuation. #509 supplies inspectable status, and #507 adds a desktop/web notice for completed results carrying retained pause intent. Phase 2 consolidates that notice into current pause and exact-follow-up visibility across clients, preserving the result meaning and summary. Respect the environment pause; do not expire or bypass it.

Relevant code

• packages/provider-core/src/server/subagentProjection.ts: task progress does not include Action obligations.
• apps/server/src/orchestration-v2/Orchestrator.ts: delegated finalization and task-specific pending-result checks; ordinary system follow-ups do not propagate task ownership.
• apps/server/src/mcp/OrchestratorMcpService.ts: task-specific status can infer finality from a terminal run alone.
• apps/server/src/actionResume/ActionResume.ts: Action delivery dispatches an ordinary queued system message without its originating task/run ownership.
• Web useActionResumeBanners.tsx and mobile ActionResumeNotice.tsx: pending-delivery visibility.

Acceptance should include an isolated parent → child → Action → ended turn → automatic same-task continuation → final parent result, with no premature completion and no polling. Cover fast completion, duplicate delivery, restart, pause/Resume, Stop, and archive.

Investigated with GPT-6.1 Sol through Codex, with Astra High and Claude Opus 5.5 High analysis.

Reliable delegated waits: four checkpoint phases

Goal and boundaries

Make delegated work dependable without asking parent agents to poll or carry every child's workflow. Deliver four incremental phases. Each phase has distinct merge, identified-checkpoint, installed acceptance and real-use gates. The user has authorized Phase 2 development after recent Phase 1 evidence while its complete acceptance matrix remains explicitly open; this is a progression exception, not a claim that unobserved cases passed. No other phase bypasses its preceding gate. Plan readiness does not authorize implementation, PRs, checkpoint runs, installation, or restarting a running environment.

Status: Phase 1 merged in PR #509 as bea65a384b25b364054fc14035f78747f24fb89a; recent installed normal-path mediation and metadata are validated, while the full acceptance matrix remains incomplete. Phase 2 development is authorized; Phases 3–4 remain unauthorized. Issue #482 is the umbrella tracker and the durable home for the reviewed plan. Keep the working Markdown mirror and private acceptance records outside the repository. Thread or worktree deletion must not remove the shared plan or its phase evidence. No phase is authorized by a review result or by publication of this plan.

Current source baseline and completed repair

Current reassessment and installed evidence:

• Phase 2 delivery base: LastCode 1556523eef088062a129484af6e859c349b25c56; published source a57aefcd20ba2467dce60e84e09171e17db16709. The incorporated upstream common ancestor remains 9e09926d97824179d97311d1a810c6b5bb60d2d1; the recorded locally fetched upstream comparison ref is 8298664e9e46ad8af2c8966cfb4c08a2a31898a4. Reuse final fix(server): deliver delegated children's background command results to the parent #484 and fix(server): deliver Action results that finish during a pause #497 unchanged. Main’s unified current-work UI, subsequent compact styling and independent PR-watch quiet deadline are integrated. Local/remote children retain their owning-environment badges/navigation. With fix(server): deliver Action results that finish during a pause #497, accepted delivery may be delivered while the exact continuation remains durably paused; no historical hold flag or queueHeld marker is required. Refresh both source baselines before the next phase. These repairs do not solve same-task Action ownership.
• Installed version used for the recorded Phase 1 evidence: server and desktop 0.1.3-nightly.20261026.3717.1, immutable tag lastcode/revision/v0.1.3-nightly.20261026.3717.1, source 802f8a0472f760830d7e26fe53844f6c75265e3f. Carry-compiled source contains Phase 1's status helper, safe summary and read-only settlement metadata.
• Phase 1 merged in PR #509, merge bea65a384b25b364054fc14035f78747f24fb89a, reviewed head 428bca5ec9bfd3b4d4a7dfb62796df11c8203789. Local/changed-file checks, exact GitHub CI and Astra/Opus/Codex reviews passed. The final fix(server): deliver delegated children's background command results to the parent #484 repair is retained: merge 5d3e8b15276811a51281573afa11899d55f42a06, final PR head a24eb45587c5f32e5d972598b6c1f274e85e21d8.
• Recent installed evidence proves bounded Action reads, a running automatic wait and one successful separate-checkout mediation: terminal child handoff → parent Action → automatic parent continuation → explicit queued child return with stable identity/task receipt → actual child work and result. The wait showed no agent polling. Earlier successes before installation were excluded.
• Full Phase 1 acceptance remains open: fast/shared-checkout, pause/recovery/held/interrupted/disposed states, fix(server): deliver delegated children's background command results to the parent #484's installed background-notification regression and full fresh-provider/client/native/remote coverage are not established by that recent-thread audit. The known settlement-guidance defect is excluded from that audit at the user's request and is corrected narrowly in Phase 2.

Reuse #484; do not implement its background-result repair again. Its shared mayStartSubagentFollowup predicate admits qualifying non-monitor provider notifications and selects the same parent lock for follow-up registration. The final repair preserves lifecycle admission, Pause, independent children, and released ownership. Its regression covers a background command waking an already-completed child, registering a later task round, and delivering that later result exactly once. Preserve these source changes and tests, including their existing carry ownership.

#484 does not keep one task alive across an Action wait. The Action service still dispatches an ordinary system/server message without a notification or originating task/run identity. #484's predicate does not admit that message as a background notification; even a new task round would not meet #482's same-task guarantee. Current Action state has no originating logical-task ownership, and task progress still does not include Action obligations. Phase 3 owns this remaining vertical change. Do not disguise Action continuations as generic command notifications to obtain a new #484 task round.

The fetched upstream includes the equivalent background-follow-up predicate plus newer runless provider-turn cleanup and command metrics changes. Those are reassessment inputs, not additional Phase 1 implementation work. Inspect current upstream again at each phase entry; reuse already-solved behavior rather than transplanting an old orchestration design.

Source of truth

This plan and the final #484 source and regression tests are current specification inputs. Earlier incident notes, recommendations, and provider comparisons are historical evidence, not implementation requirements. The original environment pause was lifted; this plan does not assume a live pause remains. Issue #498 separately tracks PR-watch scannability. The observed quota-admission problem is also separate; neither silently expands Phase 1.

Temporary parent-owned waits

Until Phase 3's installed checkpoint is accepted, parents must tell app-owned delegated children that this workflow temporarily forbids them from launching resumable Actions themselves. The launch tool exists, but task completion and automatic final reporting are unreliable. Child PR watches remain unavailable until Phase 4 is accepted. Narrowly authorized acceptance scenarios may exercise the new capability in an isolated instance of the installed candidate; this exception never enables ordinary work before acceptance. Ordinary independent conversations can still use their own Actions and watches; provider-native subagents have no general guarantee of a dispatchable child context.

• The child ends its turn with one explicit, identified handoff request, work unfinished as its final response and recorded task result, identifying its child thread, project/environment, exact checkout and head, eligible Action or PR, expected result, and continuation step. It does not send its parent a separate t3_thread_send message to hand off. The parent receives the recorded result through the async completion notification or a terminal delegate_task wait-mode return; a timeout is not a recorded result. That completed-turn result represents the handoff, not completion of the overall work. A successful tool receipt is required before anyone says a wait is armed or a PR is watched. Ordinary top-level Actions launch and resume without any settlement change. This temporary protection keeps a mediating parent visible while it owes a child a result; it is not Action eligibility. Before mediated work starts, protect the parent thread using its existing persistent per-thread automatic-settlement setting (thread.auto-settle.set, represented by autoSettleDisabledAt) to disable automatic settlement for the workflow. Expose autoSettleDisabledAt read-only in thread detail. Set this up once per mediated workflow. Read and record the parent's prior value. If it is already set, retain that timestamp as the receipt and skip setup; restore nothing the workflow did not change. Otherwise have the user disable automatic settlement from the existing parent thread menu, or use an authorized collaborative-browser setup under the runbook and machine policy. Confirm the value through t3_thread_read and privately record its timestamp as the receipt. Before later requests confirm the receipt still matches; respect a changed user setting and report the blocker. The current MCP metadata tool does not expose this mutation; do not add a mutation tool or operate the live workspace without authorization. Report a setup blocker if no supported authorized route is available. Do not assume an active override survives automatic message admission. After the workflow finishes, restore only a setting changed for that workflow, through the user or an already-authorized setup route, only if the current timestamp still equals the recorded post-setup timestamp and restoration is consistent with subsequent user choices. Otherwise leave it unchanged and explain why. Preserve any explicit user Stop or Settle decision.
• The parent records which child owns the request and prepares the target, then waits for the existing child-completion notification or terminal wait-mode return containing the recorded handoff result before launching the mediated Action. An explicit handoff message sent while the child turn still runs is not sufficient. Use that notification rather than polling to establish the recorded result; only then list eligible Actions, launch one, and end the turn. The parent handles the automated Action result and sends one follow-up to the existing child conversation with t3_thread_send, explicit mode: "queue", and a stable clientRequestId; do not use auto or steer for this return. Require and retain the returned task ID before claiming tracked continuation. If the send receipt omits it, retain the accepted message/run receipt and report the precise tracking blocker instead of blindly resending or claiming success. Do not automatically steer unrelated active child work. Today a follow-up creates a task round; do not claim the original task ID spans the handoff. A PR uses the parent's native watch, existing-findings review, and watch-then-gates ordering. Each meaningful watch event is relayed once; no agent polls for completion.
• Before assigning implementation work, verify dependency preparation and the exact execution target. Eligible-Action listing alone proves neither command nor target. Use t3_project_read to inspect the registered workspace and saved scripts and eligible-Action listing to confirm opt-in; use supported Project Settings/setup only when import, changes or opt-in are needed; verify effective cwd, worktree environment, and any worktree-local package/build selection. Prefer a shared checkout with serialized mutations when suitable. For a separate child worktree, prepare an explicitly targeted, opted-in saved Action using the supported setup runbook, docs/internals/resumable-project-actions-setup.md; its setup must not depend on that child's missing packages. Keep concrete paths and selection details in private environment settings. If preparation needs unavailable dependencies or additional authorization, use the shared-checkout route when safe, otherwise report that precise blocker. Never substitute a default parent Action, reproduce its long-running command in an agent shell, bypass trust with direct database writes, or rebind an active parent to the child worktree.
• One parent thread can have only one outstanding Action continuation. Serialize child requests in the parent's existing work record; do not build a queue service or launch duplicate work. An unavailable Action or a pause is a named blocker, not permission to poll. Parent cancellation and later follow-ups must account for the retained Action before retrying.

Phase 1 updates the owning injected agent instructions as well as repository/workflow guidance, with a Claude writing pass. In packages/provider-core/src/server/runtimeInstructions.ts, place the child Action handoff rule beside the existing child PR-watch restriction. In packages/provider-core/src/server/orchestrationInstructions.ts, put the parent mediation sequence beside delegated follow-up guidance. Align apps/server/src/mcp/toolkits/actionResume/tools.ts descriptions, LastCode AGENTS.md, and the owning workflow skills. This must reach agents in other projects through provider injection, not depend on parents remembering a repository-only rule. Update every source assertion and recorded replay fixture that embeds a changed injected block; Codex developer-instruction, Claude adapter, and ACP adapter tests are examples, not an exhaustive list. Search apps/server/src/orchestration-v2/testkit/fixtures/ for literal runtime/orchestration instruction copies, including Muse and Grok NDJSON, and mechanically replace only the changed injected text without re-recording transcripts or altering unrelated events. Focused validation includes the affected ProviderReplayFixtures-based, ClaudeReplayFixtures, AcpRegistryReplayFixtures, and OrchestratorReplayRecovery suites; do not rely on beside-file tests alone. Keep the existing PR-watch restriction until Phase 4; Phase 3 conditional Action enablement revises these same injected sentences. Do not leave unconditional child launch instructions alongside this temporary rule. Ship conditional enablement guidance with Phases 3 and 4: normal autonomous use requires the destination environment's verified runtime capability and accepted checkpoint identity; source availability or a newer-looking version alone is insufficient. Acceptance can therefore lift the Action restriction after Phase 3 and watch restriction after Phase 4 without another guidance-only checkpoint. Use fresh agent sessions to verify installed prompts and tool descriptions. Previously created mediated work keeps its recorded owner until deliberately handed over; do not migrate it implicitly.

Delivery and umbrella record

Use one explicitly authorized PR per phase, each targeting lastcode/main. Merge each phase independently when its normal gates pass; keep #482 open until all four phases have installed acceptance and real-use evidence. Phase PRs reference #482 without auto-closing it. No umbrella PR or permanent integration branch is required.

Keep the reviewed plan and authorized Phase 1 boundary published in #482. Revise that one plan in place after material reassessment; do not maintain competing plan versions. After each phase, add a concise validation comment and update its phase checklist with:

• phase PR and merge SHA;
• checkpoint tag, full source SHA, artifact identity, and evidence the tag includes the required changes;
• installed server/client identity and affected surfaces, with concrete machine details retained privately;
• installed acceptance scenarios and representative real use, observed results, failures, and remaining manual/native QA;
• upstream/LastCode reassessment and the explicit decision to repair this phase or seek approval for the next.

Distinguish merged, published, built, installed, accepted, and observed in real use. A completed PR alone does not advance the checklist. Use the existing issue and private acceptance record rather than adding a queue, tracker service, or duplicated repository checklist.

Required gate after every phase

1. Run the phase's focused regression checks and normal PR gates. Publish one phase checkpoint through the existing release workflow and prove the immutable tag contains its changes; a merged PR or an unrelated newer build is insufficient. Phase 1 may include fix(server): deliver delegated children's background command results to the parent #484 and Phase 1 together in this checkpoint. Prove inclusion of fix(server): deliver delegated children's background command results to the parent #484's final merged repair (by ancestry, or exact source/test equivalence if the release workflow replays commits); do not require a separate fix(server): deliver delegated children's background command results to the parent #484-only installation before Phase 1. Use parent-owned Wait for Checkpoint and the appropriate architecture's resumable package build. Published and built are separate from installed.
2. At the authorized installation window, install the exact artifact through the existing guarded process. Record tag, full source SHA, artifact identity, server descriptor, connected environment, and client version. A development preview is preparation, not installed-checkpoint acceptance. Do not restart agents or services without the applicable authorization.
3. Exercise the phase's scenarios using that installed version and disposable QA threads/state. Run destructive lifecycle cases and global pause/restart tests in an isolated instance of the installed executable, never by pausing the maintainer's live environment. Record one real client acceptance pass for affected surfaces, following test-t3-app or test-t3-mobile; deferred human or unavailable native QA remains pending. Use fresh parent/child agent sessions and a harmless opted-in test Action so injected instructions, actual tools, and runtime behavior are tested together. Follow deterministic installed acceptance with representative real use on that same installed version; record it in Delegated tasks finish before resumable Action continuations complete #482 before progressing. An isolated acceptance scenario proves safety and behavior, while real use establishes that the phase helps the intended workflow.
4. After authorization and before Phase 1 implementation, and again before every subsequent phase, refresh the current upstream and LastCode baselines. Diff the affected contracts, continuation/notification paths, finalization, automatic settlement (ThreadSettlementService.ts), Action service, watch service, and clients against the planning baseline or accepted checkpoint. Reproduce the remaining defect, remove work already solved upstream, and rewrite this plan as one complete current plan. Obtain an Astra High review of material changes. Track installed evidence and the go/no-go decision in the owning issue, without private infrastructure details.

A failed or incomplete installed gate normally stops progression. The user explicitly authorized Phase 2 development after the bounded recent-use audit; retain its listed Phase 1 gaps as unresolved, and do not mark full acceptance or authorize Phase 3 from that exception. Diagnose within the current phase and deliver a repair checkpoint. Preserve supported user data; never downgrade a database to make rollback convenient. Keep parent mediation available as the safe workflow. If publication omits the change or upstream materially changes the model, reassess instead of expanding the phase silently.

Phase 1 — Inspectable status and safe mediation

Delivered boundary: Phase 1 only. Base the work on refreshed LastCode main containing final #484. Reuse its registration, shared intake/locking predicate, safeguards, and regression coverage unchanged unless a separately reviewed concrete regression requires attention. No duplicate background-result fix, generalized notification rewrite, task-finalization change, Action ownership change, child-watch enablement, client redesign, quota-admission repair, or new scheduler is included.

Deliverables: bounded Action summaries in existing thread reads; delivery/hold detail in Action inspection; a small truthful derived presentation; the parent's read-only autoSettleDisabledAt; consistent interim parent-mediation guidance; focused metadata/projection regressions. Build on the existing Action service and durable ledger. The implementation review must identify exact touched contracts, service/MCP projection paths, tests, and owning guidance before coding. Repository guidance changes get the required Claude writing pass. No frontend UI work is planned in this phase; any necessary wire consumers must remain compatible with the deliberately bounded additive metadata contract.

Improvement: a parent can determine whether its child has a real Action and why delivery is held, while the temporary handoff prevents new reliance on broken child completion.

Add bounded Action summaries to existing thread reads and delivery/hold details to Action inspection. Cross-thread summary fields are explicitly allowlisted: runId, actionId, actionName, outcome, delivery, startedAt, finishedAt, exitCode, exitSignal, derived status, and optional report outcome plus bounded report summary labelled as untrusted Action output. Exclude terminalId, exact command, report facts/artifact URLs, progress detail, and outputTail. Add a focused parent-reading-child test proving no excluded fields escape. Define one pure derived-status function in the existing packages/shared/src/actionResume.ts subpath. Pass plain values for current environment pause, Action outcome/delivery, follow-up run status/queue hold, and pending-request presence; perform no I/O in the helper. Thread read and Action inspection are its first callers, and later clients reuse it. Test the distinctions in the existing shared Action test module and focused service/MCP fixtures. heldByEnvironmentPause records recovery intent, not current pause truth: a pending result may now wait behind an approval after Resume. delivered means dispatch accepted, not resumed work complete. available and interrupted/disposed outcomes must identify whether attention is required instead of promising automatic resume. Test these metadata/projection distinctions using existing fixtures; no new wait engine, polling, or full-transcript hydration.

Use the existing durable ledger and shell; do not change task finalization, wake routing, provider adapters, or watch permissions. Parent reads may inspect an authorized child's safe summary; raw retained terminal output keeps its current access boundary. Label mediated Actions as parent-owned and retain the child association only in the explicit handoff record. Automatic child summaries describe actual child-owned state; structured task-to-Action association belongs in Phase 3.

Installed gate: use one Phase 1 checkpoint that includes #484 and the Phase 1 changes; no repair-only installation is a prerequisite. In an isolated instance of that installed candidate, demonstrate #484's ordinary background-command case: the already-finished child gets a later task round and its later result reaches the parent once, while monitor, independent, released-ownership, and Pause boundaries remain intact. This acceptance reuses #484; it is not the Action same-task test and must not be reported as one. Then demonstrate a successful shared-checkout parent-owned Action handoff and queued return to the correct child, including a fast Action: the original handoff result must already be recorded before launch, and the return receipt must include a task ID. With older merged PRs present, verify that the persistent automatic-settlement setting survives the Action wake and child return; restore its prior value only when appropriate. Also demonstrate a verified different-checkout target when supported, or an explicit refusal before launch; refusal proves safety, not successful isolated-worktree mediation. Query running, succeeded/pending, resumed-but-pending behind an approval, stale held flags after delivery, queued follow-up, and interrupted cases. Confirm an isolated pause hold is explained and ordinary top-level Action behavior is unchanged. Capture the current UI before Phase 2. Complete a representative parent-mediated dependency or validation wait during real work on the installed version and record the receipt, correct target, queued return to the child, and outcome in #482. If targeting cannot be prepared, record the precise blocker; safe refusal does not pass the positive mediation or real-use gate.

Phase 2 — Visible waits and pause recovery

Status: development authorized after recent Phase 1 real-use validation, with its full acceptance matrix still open. The detailed Phase 2 scope and verification milestones are published with this plan. Astra High's four material planning findings were applied before implementation.

Improvement: users can see the named Action, running or completed-command wait, automatic-resume status and attention reason without transcript investigation. Use Phase 1's helper and the exact continuation userMessageId; never infer it from an unrelated latest run. Known connected pause truth is session != null && session.phase !== 'resuming'. Unknown/disconnected observations make no automatic-resume promise; a resuming notice does not claim delivery remains held.

Use consistent web/desktop and mobile notices, existing subscriptions/permission checks and explicit Resume controls. No new polling engine or RPC is required. Unopened child rows show only directly supported non-delivered running/pending/available state from actual child shells, owning-environment pause and pending-request summary. Hide delivered/disposed child wait badges when exact continuation state is unavailable; opening the child supplies detailed status. Do not hydrate child transcripts, substitute latestRunId/activeRunId, parse mediation prose or persist temporary associations. Parent-mediated Actions appear normally on their parent; the handoff supplies the child link. An ended follow-up turn is not completed logical child work.

Make the environment pause visible beside affected thread/Action state, including when no Action is running. Reuse the explicit Resume dialog without auto-expiry or implicit Resume. Correct guidance that frames the automatic-settlement menu setting as an ordinary Action-resume prerequisite; keep any temporary parent-relay visibility safeguard accurately scoped. Automatic ownership/settlement enforcement remains Phase 3.

Verification milestones: before implementation capture the missing pending notice in isolated installed-client state, clearly labelling synthetic visual fixtures, and establish focused failing coverage at implementation entry. Before delivery exercise an exact continuation durably held by Pause, explicit Resume with a remaining request, a separately held exact queued continuation, interrupted/available recovery and disappearance after the exact follow-up ends. Distinguish actual runtime transitions from fixtures/test-harness proof. Keep broader installed Phase 1 gaps recorded rather than silently waived.

Installed gate: capture before/after views of running Action, an ended Action whose continuation is held by Pause, delivered/queued follow-up and interrupted result. Verify correct child/terminal targets and existing cancel/resume controls. Check web/desktop and an actual mobile client when changed, including remote connection. An intentional Pause must survive isolated restart, and only explicit Resume releases it; the UI must then stop presenting a stale hold while preserving any request/queue barrier. No global pause/restart scenario runs in live maintainer state. Record representative real use and a fresh upstream reassessment before seeking Phase 3 authorization. After #497, accepted delivery may already be delivered; prove the exact queued continuation persists without provider start. Neither a historical hold flag nor queueHeld:true is required as evidence of environment Pause.

Phase 3 — Complete one child Action under one task

Improvement: app-owned children can finally use resumable Actions autonomously and report their actual final result once.

Preserve #484 as the ordinary background-notification follow-up path; it already creates later task rounds and delivers their results. For Actions, implement one complete vertical change: bind an Action to its originating logical task/run; preserve that ownership through automatic follow-up; account for outstanding work consistently in finalization, recovery, MCP status/waits, and client presentation. Reuse persistent records and existing scheduling. Transfer ownership to a durable queued continuation before releasing the wait. Route an owned Action continuation under its original logical task before generic follow-up registration can create a different task round; keep #484's ordinary background-result behavior and its shared locking predicate coherent with this route. Preserve existing nested-work checks and ordinary terminal-turn notifications. For a verified automatic wait, intermediate notifications say unfinished; automatic resume armed; no parent action or polling needed rather than publish a final result. Paused, interrupted, or unavailable delivery instead names the actual attention required, using Phase 1's status distinctions.

Handle task cancellation/Stop/archive without a later automatic resurrection; distinguish cancelling a task from cancelling just its Action. Keep explicit pause holds, recoverable interruptions, duplicate/fast completions, and routine parent updates coherent. Automatic settlement must respect owed delegated continuations/handoffs using the same outstanding-work truth, without overriding an explicit user decision to stop or settle. Do not broaden this guarantee to provider-native subagents or change PR watch policy. Resolve source-specific details against the newly installed/upstream baseline rather than introducing a second orchestration engine.

Installed gate: an actual parent delegates, the child launches a harmless Action, ends its turn, resumes automatically under the same task, and produces exactly one final result. Check both the original task and a later requested task round, using supported Codex-parent/Codex-child, Claude-parent/Codex-child, and Claude-parent/Claude-child app-owned combinations. Intermediate notices stay visible but cannot be mistaken for completion or prompt polling. Include a regression with the parent's older linked PRs all merged while a child still owes its continuation/handoff: automatic settlement must not hide that unfinished work or lose the eventual parent notification. Repeat focused failure, duplicate, cancellation, pause/restart, and parent-update scenarios. Only after acceptance lift the temporary Action restriction for new work on that installed version.

Phase 4 — Child-owned PR watches

Improvement: a delegated child can own its full authorized PR workflow, including passive CI/review waits, without the parent relaying routine news.

Reuse Phase 3's ownership and outstanding-work rules for task-owned watches and their continuations. Update MCP, command-admission, reactor, packages/provider-core/src/server/runtimeInstructions.ts, and workflow-skill restrictions together, plus the distinction between owned watch work and unrelated monitor messages. Preserve watch-then-gates ordering, existing findings, exact-head review requirements, deduplication, and unchanged merge authority.

Before implementation, specify the small ownership-transition matrix for merge, close, explicit unwatch, handoff, comment-limit exhaustion, settlement, terminal read failure, cancellation, archive, and deletion. Each ending must durably transfer ownership to an appropriate continuation or explicitly dispose/cancel it, including when final-event delivery fails. Removing a watch must not strand the task or finish it before the child processes its final event. Restart and generation checks must keep old watch events from attaching to a later task round. Ordinary top-level watches and unrelated monitor messages retain their behavior.

Installed gate: use one disposable PR to prove child watch → one gate check → end turn → CI/review event → child continuation → authorized stopping point → one final parent result. Include a comment before registration, a racing comment, a changed head, watch cancellation, and terminal watch events. Focused fixture tests exercise every transition-matrix row, failed final-event delivery, restart during transfer, and stale events after a new task round. Confirm parent/top-level watches and unrelated monitor handling still work. After acceptance retire the temporary watch restriction and run a representative delegated workflow containing both an Action and a PR watch, recording that the parent neither polled nor relayed routine events.

Review and next action

Alternating Opus 5.5 High / Astra High Phase 1 plan review completed six passes with all findings addressed and a clean final review. Two implementation-review rounds followed. Astra High and Opus 5.5 High both found the final Phase 1 source clean. Their earlier findings were repaired: complete MCP test dependencies, unchanged child PR-watch restriction, once-per-workflow settlement protection including preexisting settings, and accurate target/status read guidance. No material findings are deferred. Source checks passed, including 171 changed-file tests, 369 provider instruction/replay tests, and 20 additional toolkit tests. Source review and checks do not replace installed acceptance or real use.

The user authorized Phase 1 implementation, both-model implementation review, PR babysitting, and guarded merge. Phase 1 merged through the guarded workflow after exact-head/base GitHub CI and clean Codex review. No checkpoint was requested. Use the attached installed-validation recipe for the next checkpoint. That checkpoint must wait until Phase 1 merges and the current in-flight checkpoint finishes. No build, installation or restart is part of coding/merge. Phase 2 is now authorized as described above. Phase 3 and Phase 4 each still require their preceding installed and real-use gate, refreshed upstream reassessment, material plan re-review and separate authorization.

Phase 2 next action: after a separately authorized checkpoint includes the merge, record its immutable tag, full source and actual installed server/client versions; run the installed scenarios below in isolated state, including durable Pause across restart, explicit release, mobile/remote destinations and representative real use. Refresh LastCode/upstream and reassess the remaining plan before requesting Phase 3 authorization. Source delivery is complete; no checkpoint/install/restart or Phase 3/4 work is started by this record. Keep the broader Phase 1 matrix open.

Phase 1 validation after the next checkpoint

Status: ready for the later checkpoint. Phase 1 merged in PR #509 as bea65a384b25b364054fc14035f78747f24fb89a. The current in-flight checkpoint must finish before a subsequent checkpoint is admitted. Installed acceptance and representative real use remain pending. This record does not start a build, install, restart, or advance Phase 2.

Select and identify the installed candidate

1. Record the Phase 1 PR, final merge SHA, and final reviewed source. Update the Phase 1 row in umbrella issue Delegated tasks finish before resumable Action continuations complete #482 to merged / installed acceptance pending. Keep Delegated tasks finish before resumable Action continuations complete #482 open.
2. Record the already-running checkpoint's identity and terminal publication/promotion result using the existing checkpoint workflow. If it remains in flight, use its supported resumable Wait for Checkpoint Action when waiting is authorized; do not poll or request a duplicate run. A failed or partially promoted run needs its owner's resolution before selecting a successor.
3. Once that run is finished, the next admitted checkpoint must incorporate both final fix(server): deliver delegated children's background command results to the parent #484 and Phase 1. Prove exact inclusion from its immutable tag/source manifest; use equivalent final source and tests when carry replay changes ancestry. No separate fix(server): deliver delegated children's background command results to the parent #484-only install is required.
4. Use the appropriate resumable package-build Action for that exact installable tag when required. Record artifact identity and distinguish published, built, and installed. Installation/restart follows the existing authorized window and guarded process.
5. Record actual installed server/client versions and source, connected environment, and affected surfaces. Keep machine names, paths, endpoints, and selection wiring in the private acceptance record. Exercise the installed executable in isolated QA state with disposable parent/child threads and a harmless opted-in Action; never pause or restart the maintainer's live environment for a test.

Acceptance on that installed version

Start fresh supported provider sessions in a disposable project outside the LastCode repository. Confirm the injected child Action restriction, final-response handoff, and parent queued-return instructions are present; no repository-local AGENTS.md should be needed to obtain those rules.

• Reused fix(server): deliver delegated children's background command results to the parent #484: an already-completed child gets a background-command notification, registers a later task round, and delivers its later result exactly once. Preserve monitor exclusion, independent/released ownership, and Pause. Do not claim this is same-task Action ownership.
• Inspectable Action: a parent reads its child's bounded Action summary and can distinguish running, finished/pending, currently paused, resumed-but-still-pending, queued/delivered continuation, interrupted/available, and disposed states. Historical hold intent must not be reported as current pause truth, and accepted dispatch must not be described as completed work. Raw command/output access remains restricted.
• Mediated wait: set up the existing persistent per-thread automatic-settlement protection once per workflow and record its prior value. Cover both an already-disabled setting (reuse its receipt, no toggle and no restoration) and a setting disabled for this workflow (verified receipt, conditional restoration). Recheck the receipt before a second Action request. Use a correct shared checkout, receive the child's final-response handoff as a recorded async or wait-mode result before parent launch, run a harmless Action including a fast completion, and send one child return with explicit mode: "queue", stable clientRequestId, and a retained task-ID receipt. Confirm the parent's before/post-setup autoSettleDisabledAt via thread read, and preserve a later changed timestamp when deciding restoration. Verify older merged PRs cannot hide the parent across the Action wake or child return. Restore only a setting changed for the workflow, after completion and when consistent with later user choices.
• Target safety: exercise a prepared separate-checkout target when supported; otherwise require a precise refusal before launch. That refusal proves safety but does not satisfy the positive shared-checkout mediation case.
• Regression boundaries: ordinary top-level Actions and PR watches remain usable; task finalization, Action ownership, and child-watch restrictions are unchanged. A genuine pause persists until explicit Resume in isolated state.

Real-use record and next decision

After deterministic installed acceptance, complete one representative parent-mediated dependency or validation wait during real work on the same installed version. Record launch/return receipts, correct target, actual resumed result, and any friction. Do not introduce polling or use a failed setup as a successful case.

Add a concise public validation comment to #482 with checkpoint tag/SHA, artifact identity, installed client/server versions, scenarios and outcomes, representative real-use result, outstanding manual/native QA, and remaining defects. Private operational detail stays private. Refresh LastCode/upstream and revise/re-review material changes before the next phase decision. Phase 2 development is already authorized under the explicit exception above. Incomplete installed acceptance or real use leaves Phase 1 pending; source checks, merge, or publication alone do not pass it.

Phase 2 — visible Action waits and pause recovery

Goal, authority and boundaries

Show the Action name, command result, continuation state and attention reason on web/desktop and mobile. Show the affected environment’s current Pause beside the thread, including without an Action. App-owned child rows may display actual child-owned shell state without opening a transcript. Parent-mediated Actions belong to the parent; do not infer an association from handoff prose.

The user authorized Phase 2 implementation, review, native validation, babysitting and merge. Phase 1 normal installed mediation and representative separate-checkout real use are observed; its full acceptance matrix remains open. Phase 2 development is an explicit exception to waiting for that entire matrix. It does not pass those checks or authorize Phase 3/4, another checkpoint, production installation, production restart or pausing the live environment. A matching isolated native development client is an authorized QA prerequisite.

Current source and reused repairs

Phase 2 merged as 024232bae1e7ac1b7b47e8c1b7c3a48ce033cdda in PR #520. Reviewed source is a57aefcd20ba2467dce60e84e09171e17db16709, based on 1556523eef088062a129484af6e859c349b25c56; the merged tree is identical. Source checks, Quick CI, exact GitHub CI/Codex review, Astra’s integration re-check, matching native development QA and model assessment are complete. No context-budget approval label is required. Native evidence from f8beb472c81 applies through verified unchanged mobile application/native inputs. Reassess LastCode/upstream before the next phase; installed acceptance is separate.

Reuse Phase 1’s pure actionResumeStatus, bounded Action summary and read-only autoSettleDisabledAt. Select only the follow-up with userMessageId = action-resume:<Action runId>:follow-up; never substitute the latest or active run. Accepted dispatch and an ended turn do not mean a logical child task finished.

Reuse final #484 unchanged. It repairs qualifying later background-notification task rounds, not same-task Action ownership. Preserve child-watch restrictions, Action ownership, queue policy, provider adapters and current terminal-output authorization.

Reuse #497 unchanged. An Action finishing during Pause can now dispatch its continuation into the orchestrator’s durable paused queue and become delivery:delivered. Pause prevents provider execution. Startup/list/launch also retry retained pending results. Do not reintroduce the removed service-level hold or pending-to-available recovery downgrade.

For a known connected observation, Pause truth is session != null && session.phase !== 'resuming'. Unknown/disconnected observations stay outside the boolean helper and promise no automatic continuation. A resuming notice is separate from a Pause hold. heldByEnvironmentPause is historical recovery intent. Neither that flag nor queueHeld:true proves environment Pause. Explicit queue holds and pending requests remain separate barriers after Resume.

Implementation

1. Use the small shared client-runtime projector and existing detail atoms to read the owning Action, exact follow-up and pending requests. Keep context identity stable during unrelated streaming/visit changes. Reuse existing subscriptions and pause observations; add no polling engine, timer, wait service or transport.
2. Share one presentation model across web/desktop and mobile. Show the Action name and result meaning/summary with its running, pending delivery, paused, input, queued, held, dispatched, active, interrupted/available or disposed state. Remove stale waits when the exact continuation ends; do not infer completion from unrelated activity. Preserve fix(web): show completed Actions held by Pause #507’s result meaning while consolidating notices. Keep command/output detail behind existing terminal access.
3. Show current environment Pause beside the affected composer/Action. Distinguish pausing, paused, resuming and unknown. Reuse the existing explicit Resume dialog; opening it neither resumes nor expires the pause. Preserve destination-scoped cancel, terminal, Resume-agent, Discard and pause-control permissions. Resume/Discard require orchestration.operate; read-only destinations disable them as well as being rejected by the server.
4. Preserve nullable draft-detail guards on both clients, through draft promotion. No Action/detail subscription may request a reserved thread before materialization.
5. Resolve child badges with the same local/known-remote destination used for navigation. Read only that owning environment’s available shell and pause observation. Show only directly supported non-delivered running/pending/available state and shell pending-input reason. Hide delivered/disposed badges without exact continuation detail; opening the child supplies that detail. Do not hydrate history, parse prose, persist mediation metadata, relabel a terminal task as unfinished, or enable autonomous child Actions.
6. Correct injected guidance and the Action tool description: ordinary top-level threads launch and resume their own Actions without changing settlement. The temporary parent-relay safeguard keeps a parent visible while it owes a child a result; it is not runtime eligibility. Preserve the recorded final handoff, receipt reuse, verified target, queued idempotent return and tracked task-receipt workflow. Retain the completed Claude writing pass and mechanically synchronize actual embedded instruction copies. Same-task ownership and automatic settlement enforcement remain Phase 3.
7. Validate model-facing behavior with actual-source evals and ordinary-work controls. Preserve the before/fix comparison, avoid weakening checks after outputs, and distinguish model failures from setup/runner errors. The full per-model suite remains required after targeted checks. Use Codex for validation, with an explicit Codex shell simulator through the existing proxy if the runner needs that bounded support; do not silently remap model IDs, call real host tools or claim unrun cases passed.

Evidence and remaining source-delivery checks

• Before/after web captures establish the missing-notice rendering change. The refreshed real-client check shows one named Action status and its result/wait details in main’s current-work UI, with no duplicate composer Action notice. Synthetic metadata has no Action ledger; these captures prove rendering only.
• Destination-permission and remote-child badge regressions failed before their fixes. Shared state, draft, permissions and interaction tests remain. The new rendering-only mobile table was removed following GitHub review.
• Reviewed source a57aefcd20ba2467dce60e84e09171e17db16709 on 1556523eef088062a129484af6e859c349b25c56 passed 694 tests across 18 files, all 36 affected typechecks and static checks. Exact head/base Quick CI run 38f31b1a-72c1-4c28-b272-6b290d54eb2b passed and the normal push reused its receipt. GitHub CI run 40845661655 passed on tested merge 09a6a35e068220e524a21c641ada904ad8e7d1ca; Codex’s exact-head review is clean with zero unresolved threads. Six current-work browser tests, the compiler check and all 411 grader tests passed. The guarded merge requested no checkpoint.
• Astra High’s full exact base-to-head integration review is clean. The main current-work status receives Phase 2’s pending notice; duplicate composer notices and duplicate running names are removed. Exact follow-up selection, permissions, draft guards, fix(server): deliver delegated children's background command results to the parent #484/fix(server): deliver Action results that finish during a pause #497 and shell-only child boundaries remain intact.
• The matched six-case Action-guidance comparison passed 18/18 candidate samples versus 15/18 baseline samples; only the visibility explanation improved from 0/3 to 3/3, and the original top-level demand was not reproduced. The full Sol-medium/Luna-shell run on dfc5f3468548bb8612c5c1dc30e3d33dfff733f4 / 4fc5620986a11ec9138e2bcac719364609b33337 completed 108 cases: 100 passed the majority rule, with 203/226 valid sample passes and one retained incomplete-response error. All four Action cases passed 8/8. Comparing the eight failed guards with the actual old Action text reproduced four failures; other scores differed under simulator contradictions or policy/check mismatches. That selected, small comparison establishes neither causality nor absence of regression. Following the watch-deadline integration, eight affected controls passed 16/16 valid samples; a provider-rejected child sample remains separately recorded and was not retried. Two new deadline graders first threw regex errors, then passed red/green fixture-based syntax repair and 4/4 model samples with unchanged prompts/requirements. The current focused total is 20/20 valid samples, not a full 110-case pass. All 110 initial requests and dynamically discovered tools remain unchanged through the latest styling/grader-only update.
• Refreshed matching-client native QA at f8beb472c81 passed real read-only/operate recovery permissions, interrupted-result Resume and Discard without command rerun, draft/live detail, a real named Action/result/continuation and durable Pause/explicit release. The actual release cancelled a draining pause; it does not prove an all-quiet Resume or installed restart persistence. Labelled local/remote child fixtures passed names, owning Pause/input reasons, negatives and navigation; they do not prove child execution. Native fingerprint 6fabe8c41ef164a8d9100d88463f12435ea928eb matches that source. Mobile application, client-runtime and native dependency inputs remain identical through subsequent test-only and web-styling updates; Astra identified no changed native path requiring a repeated development-client run. Earlier evidence retains its original source pins.

The source-delivery gate is complete: changed-file checks, Quick CI, local integration reviews, model assessment and exact-head GitHub CI/Codex review passed before the guarded merge, with zero unresolved threads. No expectations or installed acceptance gates were waived. Further validation belongs to the identified installed checkpoint below.

The integrated development-client passes are complete on web/desktop and matching native mobile, including destination permissions and the refreshed Action/Pause flow. Repeat only affected checks if new production or native inputs change. Avoid paid turns for generic UI streaming; use Replay (dev). Real providers are only for provider-dependent behavior, using the cheapest suitable Codex model. Development-client evidence does not pass the later installed-executable gate; deferred or unavailable acceptance remains unpassed.

For child badges/navigation, use explicitly labelled isolated local and distinct remote app-owned shell/projection fixtures for running, pending and available Actions. Verify name, owning-environment Pause/input reason and correct navigation. Include delivered/disposed and inherited parent-owned negative cases. This is fixture-backed integrated rendering/navigation only; real child-owned execution and same-task continuation belong to Phase 3. Do not impersonate a child or grant a launch exception to obtain this evidence.

Installed checkpoint and real-use gate

After a later authorized checkpoint includes Phase 2, identify immutable tag, full source, artifact, installed server/client versions and connected target. Do not request a new checkpoint or production restart through this delivery. Source checks, development clients and preview evidence do not pass installed acceptance.

On an isolated instance of that installed executable, capture all four scenarios: running Action; ended command whose continuation is held by Pause; delivered/queued exact continuation; and interrupted result with recovery controls. Verify correct terminal/environment/child destinations, cancel/Resume/Discard permissions, and removal after the exact follow-up ends. Cover web/desktop, actual mobile and remote connection.

For Pause: finish a harmless opted-in Action while paused, verify its exact continuation persists durably without provider start, restart only the isolated instance, verify Pause still holds it, then explicitly Resume the environment. Verify that same continuation runs without rerunning the command. With #497, delivery:delivered after acceptance is expected; do not demand delivery:pending, a historical hold flag or queueHeld:true. Separately prove remaining provider requests and explicit queue holds still block after Resume. No live global Pause/restart is authorized.

Keep the broader Phase 1/#484 acceptance matrix open: fast/shared-checkout mediation, installed background-notification delivery, fresh-provider injection and remaining client/remote/recovery cases. Record representative real use, refreshed upstream assessment, any unavailable checks and an explicit phase decision in #482 before seeking Phase 3 authorization. Merge alone does not pass any installed gate. Keep all four phases and #482 open.