Let delegate_task run a child in its own project and worktree

[Goshujinsama]

Problem

delegate_task children always run in their parent's project, branch and worktree. That fits fanning out slices of one task, but not a change that spans repositories, which is a common layout: an application repo, the repo that builds its runtime image, and an infrastructure repo (Ansible/Terraform/Helm) that deploys it. One logical change touches all three, each with its own branch and PR.

Today an agent can get a worktree in another project only through t3_thread_launch, but that thread is top-level: it has no parent, so its completion never wakes the agent that started it, and there's no task_status for it. So an agent coordinating such a change either polls threads or the human does the coordination by watching the sidebar.

Related reports from people working this way: #17103 and #9435 (threads in a non-git parent workspace with PRs in other repos), #13390 (threads linked to repos other than their project's), #1453 (multi-repo projects).

Proposal

Let delegate_task take an optional projectId and workspaceStrategy (the same shapes t3_thread_launch already accepts: worktree / existing_worktree / root).

• The child is created in that project, keeping its lineage and sub-agent record as today.
• With a strategy, its first run goes through the existing worktree preparation (defer_start, worktree creation, setup script, release), and the task is delivered once preparation finishes. A preparation failure ends the task as failed and wakes the parent with the reason.
• Completion delivery, task_status and task_cancel are unchanged, so the parent is woken as for any child.
• Omitting both keeps today's behavior.
• Policy as for any child: modes no broader than the parent's, and an existing_worktree must belong to the target project.

No new UI: the child appears in its project in the sidebar and as a sub-agent of its parent.

Status

We're building this in a fork (a T3 Code fork for a multi-machine setup) and plan to run it for a while. Would a maintainer confirm whether this direction and scope fit T3 Code before we propose a PR?

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed write-up. This is the same proposal as #17415 (optional projectId and workspaceStrategy on delegate_task, reusing the t3_thread_launch workspace strategies, with the child keeping its parent, completion wake-up and task_status), so I'm closing this as a duplicate to keep the discussion in one place. Please add your multi-repo use case and any notes from running it in your fork over there: #17415

Related: #16460 (per-child worktrees) and #16719 (delegate_task to a linked environment).