handofflisted

# Handing work to a chat that is not this one The operator is talking to you about one thing and has asked for another. There are three places that second thing can run, and charter names none of them for you — it cannot judge the work (`docs/adr/0016`). It supplies the facts, the two tests below, and the mechanism. 1. **A sub-agent** — your harness's own. charter never touches one. 2. **A new chat in this workspace.** 3. **A new chat in another workspace**, existing or new. 2 and 3 are one mechanism, a **handoff**, because a chat belongs to its workspace for life. The only thing that differs is the workspace. ## 1. Apply the two tests **Sub-agent or chat — who reads the result?** If this chat needs the answer to continue, it is a sub-agent. If the operator will read it and talk to it, it is a chat. There is no report-back channel from a handed-off chat: a parent that needs the answer wanted a sub-agent, and a handoff would leave it waiting for a message that never comes. **This workspace or another — does the ask serve this workspace's vision?** Yes → a new chat here. No → another workspace. ## 2. Find the workspace ```bash charter workspace list ``` The VISION column is what you match the ask against. The rules for the *proposal* — the command refuses none of them: - a workspace with **no vision** is never proposed; there is nothing to match against; - `default` is never a target; it is where a plane lands when nobody chose, not a task; - a workspace whose vision