## Summary

Make `HARNESS=atomic` run the hosted Planner as a **full Atomic session** instead of the isolated, Chopin-tools-only harness. There's no separate flag: choosing the atomic harness is the choice. Atomic workflows, subagents, MCP, web access, intercom, and the normal coding tools can run *inside* the Planner against a local checkout of the document's repository. Chopin acts as the Atomic human-input host (`HostInput`), so every question such a session asks (`ask_user_question`, extension dialogs, workflow-stage questions) is routed to Chopin's `ask`, so it lands in **Decisions** instead of a terminal.

This lets a terminal agent hand a structured planning workflow to Chopin with a single call. The whole conversation, the document, and its questions then live in Chopin, where several people can answer them.

## Motivation

Today a local coding agent can create and update documents over MCP, but it can't:

- ask the room questions. Questionnaires can only come from the Planner's `ask`, and `update_document` rejects authored `<Questionnaire>` nodes; - let people in the document's chat talk to the agent that is doing the work; - run its own tools or workflows inside the Planner. The `atomic` harness deliberately turns off every Atomic builtin (`BUILTINS_OFF`) and loads no extensions, skills, or context files.

So planning is split between a terminal (questions, intent review) and Chopin (the document). That's the wrong way round for a shared review surface.

## Proposal

### 1. The atomic harness is a full Atomic session

- No new flag or mode switch. `HARNESS=atomic` always runs the Planner as a full Atomic session, in local and hosted deployments alike. The other harnesses stay as they are. - The Atomic session: - enables Atomic builtins (workflows, subagents, mcp, web-access, intercom) and the default coding tools, in addition to Chopin's host tools; - loads the operator's Atomic resources (extensions, skills, prompt templates, context files) from their normal agent dir; - uses a checkout of the channel's repository as `cwd`, as below. - Repository mapping: an operator-configured list of checkouts, or a path supplied when an agent invokes the Planner. Either way, Chopin verifies that the checkout's `origin` matches the channel repository before using it. Without a verified checkout, the session runs in an empty per-channel working directory, with the same tools and no repository files. - Document the trust change clearly: choosing `HARNESS=atomic` gives the Planner shell and filesystem access as the server process's user, on hosted instances too. Operators who don't want that keep using `copilot-sdk` or `pi`. `docs/self-hosting.md` and `docs/hosted-agent.md` should say this where the harness is chosen.

### 2. Chopin as the Atomic human-input host, backed by Decisions

Atomic's SDK is only the runtime. Human input goes through the host adapter the embedder binds (`extensionBindings.humanInput`, a `HostInput` with `confirm`, `select`, `input`, `editor` and `questionnaire`). With the atomic harness, Chopin should be that host:

- `questionnaire` becomes a Chopin `ask`. Questions, options, multi-select, and free text map one-to-one; answers are returned as `QuestionnaireResult` with their question indices and answer kinds. This covers `ask_user_question` in the Planner session and in every workflow stage and nested workflow it runs, since those use the same callbacks. - `confirm` and `select` become single-question questionnaires; `input` and `editor` become free-text questions. - Requests carry `requestId`, `sessionId`, and, for workflows, `workflowRunId` and `workflowStageId`. Chopin can use these to group a stage's questions and to show which run is asking. Questions are anchored to the blocks they concern when the caller names them; otherwise they're appended. - The `AbortSignal` cancels the pending questionnaire (the card shows it was withdrawn). Durable workflow approvals stay pending when input is withdrawn, as the SDK already guarantees, so a restarted server can rebind and present them again. - An optional per-request timeout, after which the callback returns "no answer", so callers can proceed on stated assumptions.

No tool interception is needed. Nothing is terminal-specific, so the same workflow definitions run unchanged in a terminal host or in Chopin.

### 3. Let a local agent hand work to the Planner

- A new MCP tool, for example `invoke_planner({ id, instruction, checkout? })`. It posts the instruction as a Planner turn on an existing document, attributed to the MCP caller and run under the channel's existing Planner ownership rules, and returns immediately with the document URL. `checkout` only applies to the atomic harness. Progress, questions, and results then appear in the document and its chat.

### 4. Fix MCP `outputSchema` for `rename_document`, `archive_document`, `restore_document`

Their output schemas are a top-level `oneOf` without `"type": "object"`. The MCP spec requires an object schema, and strict clients (for example Atomic's MCP client, which uses zod validation) refuse to connect: `tools[4].outputSchema.type: Invalid input: expected "object"`. Wrapping these as `{ type: "object", oneOf: [...] }`, as `update_document` already does, fixes it.

## Out of scope

- Persisting Atomic session state across server restarts beyond what the harness already does.

## Open questions

- On hosted instances without a configured checkout, should Chopin clone the channel repository on demand with the owner's token instead of using an empty working directory? - For question batches without anchors, should the batch be appended to the end of the document or collected under a single "Open questions" block?