harness-integration-guidelisted

# Harness integration guide This skill describes the **feature matrix** every Doppl harness must consider. Use it when planning, reviewing, or implementing a new harness. Doppl has two distinct harness tracks with different architectures and feature sets: - **SDK/subprocess harnesses** — run the vendor model directly (in-process SDK, CLI subprocess, or ACP subprocess). They own the model lifecycle. - **Native harnesses** — wrap a vendor's own TUI or server and mirror its output into Doppl. They observe and relay, rather than drive. --- ## Part 1 — SDK / subprocess harnesses These harnesses run the vendor model directly and bridge Doppl tools into the vendor's tool-calling interface. ### Capability matrix | Capability | What it means | |---|---| | **Connects to Doppl MCP** | Harness exposes/consumes tools via the MCP protocol (in-proc SDK MCP server) | | **Model override** | User can select a model via `--model` / config; some harnesses are vendor-locked (e.g. Claude-only, GPT-only, Gemini-only) | | **Auth** | How credentials are obtained — API key, gateway token, vendor CLI login, OAuth, etc. | | **Streaming** | Harness forwards token-level or delta-level streaming to the Doppl forwarder | | **Doppl policies** | Harness enforces Doppl-side tool policies — must support ALLOW, ASK, and DENY verdicts for both tool calls and tool results | | **Native elicitation** | When a policy verdict is ASK, the harness surfaces the approval request in the Doppl web UI so the user