agent-harness v0.13.0

Find out which of your agent rules actually fire.

A user-owned agent harness with a measurement loop. Every rule names a deterministic detector over the transcript or says in one line why nothing in a transcript can decide it, and lint fails the commit otherwise. harness usage --rules then reports which rules fired, grouped by repository and by the preference variant you had selected.

Preferences you can switch: autonomy, delegation, cost, testing, voice, commits, planning, licensing and build versus buy. Three of those bind to enforcement today: autonomy sets which shell-command grade stops and asks, delegation changes spawn routing, and cost resolves a model and budget table per role. The rest are prose that swaps cleanly. The usage report groups rule hits by the variant that was selected, so a switch can be checked rather than assumed.

Compatibility

• claude-code-cli-macos: qualified
• claude-code-vscode-macos: unqualified
• claude-code-cli-linux: qualified
• claude-code-plugin-marketplace: unqualified
• codex-cli-macos: unqualified
• codex-vscode-macos: unqualified
• codex-desktop-macos: unqualified
• codex-cli-linux: unqualified
• cursor: planned
• grok: planned

Native restrictions remain authoritative. See the versioned compatibility catalog for evidence and gaps.

Compatibility policy

Stable interfaces, preview boundaries, deprecation, migration and failed-release recovery are defined in the versioned compatibility policy.

Migration

Upgrade from v0.12.0 by reviewing the generated v0.13.0 projection before applying it: a minor release that adds declared framework integrations under policy/integrations/ with a generic harness integration check|apply, spawn-hook confinement that classifies a framework's review layers however the client names them, an opt-in jev decision provider, a sampled record of allowed Bash commands in the decision log, and an optional completion-claim field on the stop-gate row. /plan now enters the runtime's plan mode and hands the approved plan to /build, the output style and the skill and role descriptions are shorter, and the settings template no longer carries a hooks block. No network call is made and no assistant text is recorded until you turn each on. The architecture-viewer preview is inert until an external adapter is registered and selected.

• Run harness sync --dry-run from the v0.13.0 checkout and inspect every proposed write, ownership change and conflict. Expect no new commands, skills or roles: expect changed text in the plan and build commands, the scannable output style, every skill and role description, the delegation and cost stances and the delegation rule. The installed hook registration does not change, because sync already wrote the single-coordinator registration.
• Run harness sync only after resolving unmanaged-file and adoption conflicts.
• harness bmad check|apply remains an alias of harness integration check|apply bmad. If you route BMad code review through the harness, run harness integration check bmad <framework-root> and then apply; installed override files are unaffected either way.
• The jev decision provider stays off unless you ask for it. governance.jev.mode and governance.jev.modes.<point> take off, shadow, advise or act, every point defaults to off, and governance.jev.state_fields is empty by default. While ~/.local/state/agent-harness/jev-disabled exists every call is disabled. Read the credential from an environment variable, never inline.
• Expect grade-bash rows marked sampled: true in ~/.local/state/agent-harness/decisions.jsonl: one allowed Bash command in twenty, redacted before it is capped. telemetry.allow_sample_rate: 0 or telemetry.decisions: false turns them off. telemetry.completion_claim is off by default and is the only field that records assistant prose.

Recovery

• Preserve reported conflicts, adopted backups, external viewer adapter descriptors and external viewer installations.
• To return to v0.12.0, remove any governance.jev block and the telemetry.allow_sample_rate and telemetry.completion_claim keys from your configuration and run harness sync once from the v0.12.0 checkout; use harness bmad check|apply there, since v0.12.0 has no harness integration command.
• Use harness uninstall --dry-run before uninstalling, and follow docs/runtime-installation.md for rollback and ownership recovery; use docs/task-continuation.md for task continuation.