Coding with sub-agents

1. A coding agent for the work

Coding work goes to a coding agent on the roster: the one the user named, otherwise one the ## Delegation section says owns coding, otherwise one whose description says it writes or edits code. When a Worker Table is bound, subagent takes worker labels instead: pick the worker whose brief covers the coding work. When none does, tell the user and ask how to go on rather than writing the code yourself or sending it to an agent outside the enum.

2. One instance per task

An instance is one conversation with one agent, named by the instance handle.

• A new task gets a new instance, never an earlier task's handle, which would carry that task's context into it. That holds for a task built on a finished one, such as docs for a finished feature: it starts fresh, with the earlier task's output file (section 3).
• A follow-up on an unfinished task - a correction, a bug in what it did, "keep going" - goes to that task's instance: same subagent, same instance, a new node_id. The agent keeps its context, so the prompt carries the new request in the user's words.
• Send a follow-up only once the instance's running dispatch has returned: sent sooner, it can start a separate conversation without that context.

3. Results by file

When a task needs what another produced, put that task's output file in its prompt - {{ <node_id>.output_path }} of its last dispatch - instead of retelling the result. The file is the agent's report, not the code, so also say where the code is (section 4).

4. A worktree per task in a shared project