The boundary: runward never wires itself.

The one boundary runward never crosses: wiring the gate

The apparent contradiction

This is the apparent contradiction to resolve head-on: how can runward be "agent-operable end-to-end" while every guide says you install the trigger manually?

The resolution

Wiring the gate into your repo is the single thing runward never does autonomously — and the single thing it does not do even for itself. runward wire detects and prints a recommendation; it "wires nothing — you are the operator's hands (ADR-0012)". runward writes no file into .git/, edits no .claude/settings.json, registers no CI (ADR-0012 Decision). The adapters are inert sample text under runward/adapters/ that do nothing until an operator copies them into place.

"Agent-operable end-to-end" does not mean runward silently mutates your repo. It means an agent can drive every step — including performing the wiring — but the wiring specifically requires the operator's explicit approval. The charter is exact: "Propose it and act only on explicit approval; never wire it silently… you are the operator's hands, and the operator owns the gate". ADR-0012's 2026-07-12 amendment makes this precise: the agent offers and the operator decides — "the difference is consent: the agent proposes and the operator decides, versus runward acting without the operator's act".

Why this boundary is a feature, not a missing capability

• No tool silently touching your git or CI. Auto-installing a hook into .git/hooks/ or editing a settings file is "surprise execution wired into a repo without the operator's act" — rejected on security grounds. A gate that a tool installs behind your back is exactly the class of foot-gun runward refuses to become.
• The frame must never become a runtime. A daemon, file-watcher, or runward-managed hook runtime "would each turn runward from a frame into a runtime — the one thing the doctrine forbids it to become". Keeping the wiring in the operator's hands keeps runward a frame.
• Detection stays honest. ADR-0030 preserves ADR-0012 exactly: "detection informs, the operator's approved gesture wires". runward at most prints the exact command.

What the CHANGELOG meant

Concretely: the CHANGELOG's "install and operate" refers to standing up the mission (init) and running the whole chain (check, manifest, compliance, …) autonomously — plus the agent-assisted, approval-gated wiring of the trigger. It never meant runward reaching into .git/ on its own. There is no contradiction: the manual/approved step is the deliberate consent seam.

Compliance and scope, stated plainly

The gate is deterministic and offline

The gate is deterministic, zero-LLM and offline: the audit "stays deterministic, zero-LLM, zero-run" — it reads and hashes files, it never runs your code. runward's default lens is engineering craft and security; a regulatory regime is an optional lens, and the CI adapter is the seam where that evidence is produced.

What the output is, and is not

What runward produces is audit-ready supporting evidence that feeds or supports a compliance programme (regimes: iso-42001, nist-ai-rmf, eu-ai-act); it does not make a system compliant or certified. The CLI itself frames the output as "a readiness draft, never a compliance claim". That determination is the auditor's.

Why this choice

The load-bearing choice and the rejected alternative

The load-bearing design choice is that runward never wires the gate itself, even though it is 'agent-operable end-to-end.' The rejected alternative was detection-first auto-wiring: on init or on detecting the harness, silently install the git hook into .git/hooks/ or edit the harness settings file.

It was rejected on two grounds

• Security: silent installation is 'surprise execution wired into a repo without the operator's act' — the exact foot-gun class runward refuses to become.
• Doctrine: a daemon, watcher, or runward-managed hook runtime 'would turn runward from a frame into a runtime — the one thing the doctrine forbids it to become'.

The chosen model

The chosen model keeps wiring as an operator consent gesture that an agent may perform on explicit approval (ADR-0012's 2026-07-12 amendment). Detection (ADR-0030) is layered on top as best-effort and read-only, with wires:false as a machine-checkable invariant, precisely so recognition can never slide into silent action. This makes the boundary a designed consent seam, not a missing capability.

What comes next

ADR-0030 sets an additive, non-breaking follow-on: extend --json coverage beyond check to status, doctor, manifest and compliance as the autonomous driving loop demands each read path.

The ADR's dated reevaluation trigger reopens the detection design if:

• a cross-harness runtime convention for agent identity emerges (a standard env marker adopted by more than two major harnesses), or
• the driving loop needs a read path that has no --json yet

still without runward writing a channel itself.