Module harness 

The harness adapter API — the single seam between generic dispatch code and harness-specific behavior.

The trait is tiered into a baseline every harness must implement and enhancements that raise fidelity when a harness has the native support:

• Baseline (required): label and skills_dir. A new harness compiles with just these two methods; dispatched through its one-shot CLI (with --no-stage inlining the skill when native staging isn’t wired), it already supports llm_judge grading and the detect-stray-writes post-pass.
• Enhancements (defaulted): every other method has a default — either a working generic fallback (e.g. the plain available-skills block) or an Unsupported error naming the enhancement it belongs to (e.g. transcript ingest, the write guard). Override the methods of an enhancement to wire it for a harness.

Generic code resolves an adapter with adapter_for and then calls the trait — so the registry is the one place that names a concrete harness for this surface. The impls live in the per-harness modules (claude_code, codex, opencode).

Structs

CliDispatchContext

Context for rendering a harness’s one-shot CLI agent-dispatch guidance.

CliJudgeContext

Context for rendering a harness’s one-shot CLI judge-dispatch guidance.

CliManifestContext

Context for rendering a harness’s dispatch-manifest.md CLI recipe.

ToolVocabulary

One harness’s tool-name vocabulary: every name its guard hook payloads or transcript parser can produce, grouped by role. Consumers match against the union across all harnesses (all_tool_vocabulary).

Constants

RUNBOOK_TEMPLATE

The shared (human-followed) RUNBOOK.md template used by every run, regardless of harness (Claude Code, Codex, OpenCode).

Traits

HarnessAdapter

The behavior that varies by harness. Generic dispatch code depends on this trait, never on a concrete harness variant. See the module docs for the baseline-vs-enhancement contract.