Handshake. The editor announces what it can lend the harness: its own agent model (native mode — no API key needed) and a webview panel (native render). Call once at session start. Without it the harness assumes a bare MCP client and falls back to its own model from config.json plus a browser window.

What the harness currently holds: entry counts, design rules, pending changes, open questions.

Create /harness and assemble the initial harness for a NEW project from the user description. One-time: once a harness exists, changes go through harness_propose_change and human approval.

Create /harness and reverse-assemble the harness from EXISTING code. Code is the evidence and wins over stale docs; inferred intent is marked [assumption] with a question for the human. Pass ProjectMind analysis in analysis when available.

Native mode callback: the editor agent ran the requested generation with its own model and returns the result here. The request_id comes from a previous tool call that answered with status "needs_agent".

Read the harness. The agent implements FROM this and must not depart from it. Call it before writing code; the constitution belongs in every turn.

The way a human edits the harness with words: "make the buttons green", "move the sidebar left". Turns the message into proposed harness changes — queued for approval, never applied directly. Uses the editor model (native) or the configured model (universal).

Generate or extend the project structure (modules, entities, screens, flows) from an instruction. Result lands in pending changes for review.

Propose one precise change to the harness without involving a model. The change is NOT applied — it waits in pending_changes with a diff for a human to accept or reject.

Record a design rule ("all buttons have an 8px radius"). Once approved it applies GLOBALLY to the whole project — the agent must satisfy it in any UI it writes. Optionally attach a machine check so harness_verify can enforce it.

Host path to a design system: pass the payload of Design MCP's get_tokens({category:"all"}) (or an already normalized token set) and the mockup renders in the project's own visual language instead of a grey skeleton. Optionally pass the get_rules payload as rules to queue the design-system rules for approval.

Direct path to a design system: the harness itself connects to the Design MCP server configured in config.json (design_mcp.command/args), pulls tokens and rules, stores the tokens and queues the rules for approval. Use where no host wires the two servers together; otherwise prefer harness_set_design_tokens.

Pending changes with their diffs, plus the unapproved-count badge.

A human accepts a pending change: it is applied to the harness, the markdown spec is rewritten, and a checkpoint is taken first so it can be rolled back. Agents must not call this on their own behalf.

A human rejects a pending change. Nothing is applied; the reason is kept in the approval history.

Bridge between the ephemeral chat and the durable spec. The editor agent returns a STRUCTURED summary of the current session — completed_tasks, decisions, open_questions, touched_files — which is stored and turned into per-item proposals a human approves point by point. Amorphous prose is rejected.

Render the structure + mockup visualization. Returns HTML for a webview (native hosts) or serves it on localhost and opens a browser (everywhere else). The picture is an output: critique goes back in words through harness_chat.

On demand only: compare the real code against the harness and report divergences. The harness is never redrawn from code — this is the safety net for when the agent drifted.

Read or update /harness/config.json — the model for universal mode (provider, model, api_key) and render preferences.

Take a rollback point, list them, or restore one.