# Wire your harness

The gate is one hook; a well-kept harness carries more than the gate, and none of it is runward's to install. This page maps what each verification tier can become in the harness you already use: the turn-end hook and CI for the gate, post-edit mechanical checks that inform but never gate, instruction files that point at the mission, advisory review that never blocks. Runward emits inert samples and recommendations; you wire.

The gate is one hook. A well-kept harness carries more than the gate — and none of it is runward's to install. This page maps what each of the [three tiers](https://runward.dev/docs/concepts/three-tiers/) of verification can look like in the coding harness you already use. Runward emits inert samples and recommendations; you wire; nothing runs without your hand.

## What the harness can carry, tier by tier

**Tier 1 — the gate, at the harness seam.** Covered by [Wire the gate](https://runward.dev/docs/operating/wire-the-gate/): a turn-end hook where the harness supports one (hard where the seam allows it, advisory where it does not), and the CI required check at merge. Honestly tiered per channel — the distribution map is the source of truth.

**Tier 2 — mechanical checks after every edit.** Some harnesses expose a post-edit hook: a script that runs the typechecker after each file change and feeds failures back to the agent. The sober pattern, whatever the harness:

- no-op outside its territory — skip when the file type or the project does not match; the hook must never add friction to a mission's Markdown, or to projects it does not concern;
- inform and correct, never gate — phase crossings stay with `check`;
- one bounded timeout; failures return to the agent, not to a log nobody reads.

**Instruction files.** The canonical, vendor-neutral surface is `AGENTS.md` — most harnesses read it. Where a harness adds its own instruction file, the same rule as everywhere: the mission's operating rules live once, the harness file points at them. Two lines earn their place wherever your harness keeps standing instructions: a repo with a `runward/` directory is a mission and is driven through runward; the gate is not simulated or bypassed — no phase declared crossed on assertion.

**Tier 3 — advisory review.** If your harness can run a reviewer (a subagent, a review command), keep it advisory: findings in, operator decides. Never wire a model-controlled check as a blocker.

## Per-channel honesty

Capabilities differ and change monthly; verify against your vendor's current docs. As of writing: some harnesses expose both a turn-end seam and post-edit hooks; some expose only a stop seam that cannot hard-block; some expose neither and carry only instruction files and CI. The [distribution map](https://runward.dev/docs/operating/wire-the-gate/) stays the source of truth for the gate seam per channel; this page's Tier-2 and Tier-3 patterns apply wherever your harness has the corresponding extension point — and nowhere else. No channel is privileged; a harness without hooks still runs the full method through CI and `AGENTS.md`.

## What stays yours

Cost visibility for your own harness, usage self-audits, machine-wide preferences: operator tooling, out of runward's scope by decision — the CLI reads your mission repo, never your behavior. Instrument your own post however you like; the gate will keep asking only one thing: evidence.

## See also

- [Wire the gate](https://runward.dev/docs/en/operating/wire-the-gate/)
- [The three tiers of verification](https://runward.dev/docs/en/concepts/three-tiers/)
- [The boundary: runward never wires itself](https://runward.dev/docs/en/operating/from-an-agent/the-wiring-boundary/)
- [From an AI agent](https://runward.dev/docs/en/operating/from-an-agent/)