delegation-chainlisted

# delegation-chain — the full shape of a delegation, one document instead of five This exists because the mechanism it documents is genuinely non-obvious, undocumented by the harness itself, and easy to get wrong in a way that LOOKS successful. Getting any one part wrong — the spawn shape, the report channel, the wake signal, or what a watcher actually sees — produces a delegate that runs, writes something, and reports "done", while the work is lost, the observer never attached, or nothing was ever watching in the first place. None of those failures throw an error. They all look like success from one level up. Read the section you need; the four sections compose into one loop (spawn → work → report → wake), and the table at the end names which of the shipped watchers covers which part of it. ## 1. The downward chain — how a delegate is spawned, and what each shape costs | Spawn shape | Named? | Observer attaches? | Worktree-cleaner risk | Good for | |---|---|---|---|---| | anonymous (no `name`) | no | yes | none (no dedicated worktree unless the delegate makes its own) | a delegate that hands its writes to an external executor lane | | `name` **+** `isolation` | yes | yes | none | any delegate that must be addressable by name AND does not delegate its writes elsewhere | | `name` alone (no `isolation`) | yes | **no — dropped silently** | n/a | avoid | | installed via a PLUGIN (a namespaced type) | — | **no — pairing skipped silently, no warning** | n/a | never, if the obse