Local mode: run the Planner as a full Atomic session with questions routed to Decisions

[lavaman131]

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?