Model Citizen v0.14.2

The control plane for your coding agents, however you run them.

An open-source control plane for coding agents. One checkout of rules, skills, roles and stances, projected into Claude Code and Codex with your own primitives, enforced with hooks, and measured with usage telemetry and cost controls. It layers under the rules libraries and orchestration you already use.

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

Qualification basis: native evidence recorded for this release.

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.14.1 to package the Claude Directory submission as a minimal regular-file plugin bundle, fix the sandbox skill's network and credential guidance, and publish matching plugin metadata at v0.14.2. The patch changes no configuration schema or defaults, and the architecture-viewer preview is inert until an external adapter is registered and selected.

• Run citizen upgrade --dry-run, inspect the recorded plugin and checkout changes, then run citizen upgrade. The plugin marketplace and plugin manifests now report v0.14.2.
• Run citizen sync --dry-run, resolve any unmanaged-file conflict it names, then run citizen sync. Existing configuration and stance selections remain unchanged.
• Run citizen diff and citizen doctor; both should report no projection drift.

Recovery

• Preserve every conflict or adopted backup reported by the dry run.
• To return to v0.14.1, check out v0.14.1, run citizen sync --dry-run, then citizen sync; no configuration migration needs reversing.
• If the Claude Code plugin was upgraded, reinstall the v0.14.1 checkout as the model-citizen marketplace source before installing its plugin version again.
• Use citizen uninstall only to remove the installation entirely; see docs/runtime-installation.md for ownership recovery.

Model Citizen v0.14.1

The control plane for your coding agents, however you run them.

An open-source control plane for coding agents. One checkout of rules, skills, roles and stances, projected into Claude Code and Codex with your own primitives, enforced with hooks, and measured with usage telemetry and cost controls. It layers under the rules libraries and orchestration you already use.

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

Qualification basis: native evidence recorded for this release.

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.14.0 to complete the Model Citizen rename across public documentation and distribution metadata, accept every bundled skill manifest in standard YAML registries, publish plugin metadata at v0.14.1, and keep reworded framework review-layer briefs inside their declared constrained role. The patch changes no configuration schema or defaults, and the architecture-viewer preview is inert until an external adapter is registered and selected.

• Run citizen upgrade --dry-run, inspect the recorded plugin and checkout changes, then run citizen upgrade. The plugin marketplace and plugin manifests now report v0.14.1.
• Run citizen sync --dry-run, resolve any unmanaged-file conflict it names, then run citizen sync. Existing configuration and stance selections remain unchanged.
• Run citizen diff and citizen doctor; both should report no projection drift.

Recovery

• Preserve every conflict or adopted backup reported by the dry run.
• To return to v0.14.0, check out v0.14.0, run citizen sync --dry-run, then citizen sync; no configuration migration needs reversing.
• If the Claude Code plugin was upgraded, reinstall the v0.14.0 checkout as the model-citizen marketplace source before installing its plugin version again.
• Use citizen uninstall only to remove the installation entirely; see docs/runtime-installation.md for ownership recovery.

Model Citizen v0.14.0

The control plane for your coding agents, however you run them.

An open-source control plane for coding agents. One checkout of rules, skills, roles and stances, projected into Claude Code and Codex with your own primitives, enforced with hooks, and measured with usage telemetry and cost controls. It layers under the rules libraries and orchestration you already use.

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.13.1 by reviewing the generated v0.14.0 projection before applying it: a minor release that renames the product to Model Citizen, adds the citizen command with harness kept as an alias, renames the plugin to model-citizen@model-citizen, and adds one selection resolver with modes and on/off switches for rules, skills, workflows, roles and hooks. Sync now links the repository's rules one file at a time into a real ~/.claude/rules/harness/ directory instead of one directory link. The release also adds the local decision provider's user-level policy file and its binding into Bash command grading, a write-intent ledger for parallel writers, workspaces built from .code-workspace files, session-start injection of a differing project or session stance, a profile fingerprint, schema versions and context attribution on ledger rows, and the concise voice. Every new switch, mode, provider and workspace is off or unchanged until you select it. The architecture-viewer preview is inert until an external adapter is registered and selected.

• Run citizen sync --dry-run from the v0.14.0 checkout and inspect every proposed write, ownership change and conflict. Expect one migrate ~/.claude/rules/harness (one link per rule replaces the directory link) line followed by one link line per rule into that directory, and relink lines for skills, agents, commands, hooks, the output style, stance links and CLAUDE.md. Nothing outside the harness's own files should appear.
• Run citizen sync only after resolving unmanaged-file and adoption conflicts. Afterwards ~/.claude/rules/harness is a real directory of per-rule links, and citizen diff reports no drift.
• harness keeps working as an alias of citizen; the documentation now names citizen.
• If you installed the Claude Code plugin, move it to the new ID: with a checkout installed run citizen upgrade --dry-run, then citizen upgrade, which uninstalls agent-harness@agent-harness, removes the agent-harness marketplace, adds it again from its recorded source and installs model-citizen@model-citizen. A plugin-only install runs the same four /plugin steps in a session; see docs/runtime-installation.md. Skills move from /agent-harness:<name> to /model-citizen:<name>.
• Your configuration keeps working unchanged. A new citizen init records the stances it wrote under init_defaults; a v0.13.1 configuration has none, so every stance reads as set by you in citizen selection. To try a mode, run citizen config set mode minimal (or full, the defaults); a key you typed still wins over the mode. Switch a unit off with citizen config set <kind>.<id> off, for example rules.decisions-and-plans; the four core hooks, grade-bash, stop-gate, brief-guard and neutralize-tool-output, can be switched off only after you set core_switches_acknowledged true. See docs/modes.md.
• With governance.provider set to anything but none, grade-bash now asks the provider about every Bash command it lets through, and an agent write to a governance policy file or to your config.json is always asked about. A user-level governance.json beside config.json is read under the repository's .agent-harness/governance.json. Under provider none nothing changes.
• Workspaces are opt-in: set workspaces_dir to the folder holding your .code-workspace files to turn on citizen workspace and the workspace-session start hook; while it is set, sync owns CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD in ~/.claude/settings.json. See docs/workspaces.md.
• Expect new rows in ~/.local/state/agent-harness/ to carry schema_version, profile_fingerprint and, on session rows, context_attribution; rows written earlier are read unchanged and never rewritten. On Claude Code a second edit to a path a live sibling session has claimed with citizen intent claim is denied; coordination.repeat_overlap: "warn" only warns.

Recovery

• Preserve reported conflicts, adopted backups, external viewer adapter descriptors and external viewer installations.
• To return to v0.13.1, first remove ~/.claude/rules/harness, which v0.14.0 made a real directory holding only links to the checkout's rules, then check out v0.13.1 and run harness sync once. Skip the removal and the v0.13.1 sync refuses at that path, exiting 2 after it has already relinked stances, hooks, skills, commands and CLAUDE.md, which leaves a mixed home until a sync succeeds; --adopt completes it only by moving v0.14.0's directory under ~/.local/state/agent-harness/pre-harness/ as though it were your own backup. After the rollback, v0.13.1's harness diff and harness doctor report one missing link per rule under ~/.claude/rules/harness/: stale journal entries from v0.14.0, harmless because the directory link serves every rule, and cleared by the next v0.14.0 sync.
• v0.13.1 ignores modes, switches, init_defaults, core_switches_acknowledged and workspaces_dir, so every rule, command and hook comes back on, and nothing in your configuration needs removing for its sync to succeed. Its local provider reads only the repository's .agent-harness/governance.json, never the user-level file, and its grade-bash does not ask the provider. If you set workspaces_dir, run citizen config unset workspaces_dir and citizen sync from v0.14.0 before rolling back, so sync puts CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD in ~/.claude/settings.json back to what it held; v0.13.1 never touches that key.
• A rollback sync does not touch the plugin: citizen upgrade has no reverse, and a moved install stays model-citizen@model-citizen.
• Use harness uninstall to remove the installation, and follow docs/runtime-installation.md for rollback and ownership recovery; use docs/task-continuation.md for task continuation.

agent-harness v0.13.1

The control plane for your coding agents, however you run them.

An open-source control plane for coding agents. One checkout of rules, skills, roles and stances, projected into Claude Code and Codex with your own primitives, enforced with hooks, and measured with usage telemetry and cost controls. It layers under the rules libraries and orchestration you already use.

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.13.0 by reviewing the generated v0.13.1 projection before applying it: a patch release that changes only landing copy, the product.json source and the README hero rendered from it. It changes no runtime, configuration, hook, role, stance, skill or projection, and adds no files or local state. The architecture-viewer preview is inert until an external adapter is registered and selected.

• Run harness sync --dry-run from the v0.13.1 checkout and inspect every proposed write, ownership change and conflict. Expect no changed rule, stance, skill, role, command, hook or settings content: the only source changes since v0.13.0 are landing copy that sync never installs.
• Run harness sync only after resolving unmanaged-file and adoption conflicts.
• No configuration key, command or opt-in changed; nothing in ~/.config/agent-harness/config.json or ~/.local/state/agent-harness/ needs attention.

Recovery

• Preserve reported conflicts, adopted backups, external viewer adapter descriptors and external viewer installations.
• To return to v0.13.0, check out that tag and run harness sync once; no configuration or local state needs undoing, because v0.13.1 changes none.
• 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.

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.

agent-harness v0.12.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: unqualified
• claude-code-vscode-macos: unqualified
• claude-code-cli-linux: unqualified
• 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.11.1 by reviewing the generated v0.12.0 projection before applying it: a minor release that adds the /land and /close-out workflows, a local decision log, an optional OTLP export of the usage ledger with an optional per-runtime pass-through to each client's own telemetry, and harness remote-control. harness sync now installs the Claude Code output style named by your voice stance instead of a fixed one, so a selection you never made explicitly can change; nothing is exported and no supervisor is installed until you turn each on. The architecture-viewer preview is inert until an external adapter is registered and selected. This release carries no native qualification: no client holds acceptance evidence for this source, no client is required for release, and v0.11.1 remains the last release qualified on the Claude Code and Codex CLIs for macOS and Linux.

• Run harness sync --dry-run from the v0.12.0 checkout and inspect every proposed write, ownership change and conflict. Expect two new commands, close-out and land, and expect the installed Claude Code output style to follow your voice stance: if you had selected a style by hand, select the matching voice variant before syncing or the sync changes it.
• Run harness sync only after resolving unmanaged-file and adoption conflicts.
• Telemetry stays off unless you ask for it. To export the ledger, add a telemetry block to your configuration: export turns on OTLP/HTTP, and native takes true, false or a list of runtime names, so a collector only one runtime can authenticate against is written only for that runtime. Read headers from an environment variable or a mode-600 file outside every git work tree, never inline. See docs/telemetry.md.
• Expect new owner-only local state: ~/.local/state/agent-harness/decisions.jsonl, an append-only record of what a hook decided and what settled it. It is pruned with the rest of the local state, read only by harness usage, and removed by harness uninstall.
• harness remote-control install registers a launchd agent that supervises a Claude Code Remote Control host. It is opt-in, installs nothing on its own, and harness remote-control uninstall removes both the agent and the healer.

Recovery

• Preserve reported conflicts, adopted backups, external viewer adapter descriptors and external viewer installations.
• To return to v0.11.1, run harness remote-control uninstall if you installed it, remove the telemetry block from your configuration and run harness sync once from the v0.11.1 checkout; v0.11.1 ignores decisions.jsonl and restores the fixed output style from its own settings template.
• Use harness uninstall --dry-run before uninstalling, and follow docs/runtime-installation.md for rollback and ownership recovery; use docs/bmad.md for task continuation.

agent-harness v0.11.1

Your way of working, across AI agents.

A general-purpose, model-provider-agnostic harness built around you. Define how your agents work through shared rules, skills, roles, workflows, and custom primitives—including personal stances you can switch without rewriting your instructions.

Personal stances turn your working preferences into explicit switches. Choose how agents delegate, test, communicate, exercise autonomy, and approach decisions. Select a different stance when the situation changes, or define your own. The harness applies those choices through supported agent runtimes.

Compatibility

• claude-code-cli-macos: qualified
• claude-code-vscode-macos: unqualified
• claude-code-cli-linux: qualified
• codex-cli-macos: qualified
• codex-vscode-macos: unqualified
• codex-desktop-macos: unqualified
• codex-cli-linux: qualified
• 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.11.0 by reviewing the generated v0.11.1 projection before applying it: a patch release with no new files, hook events or roles. The spawn guard now refuses a constrained role's brief however the spawn is named, the builder role reports what produced any fixture it edits, and the delegation: off stance says that a spawn is denied; the architecture-viewer preview is inert until an external adapter is registered and selected.

• Run harness sync --dry-run from the v0.11.1 checkout and inspect every proposed write, ownership change and conflict. Expect the builder agent definition and the delegation stance text to change and nothing to be added.
• Run harness sync only after resolving unmanaged-file and adoption conflicts.
• If you route BMad code review through the harness, run harness bmad check <framework-root> and then harness bmad apply <framework-root>: each review layer's brief now begins with a harness-role: line that the spawn guard enforces, and a framework checkout keeps the old layer text until you apply it.
• Expect a session record under ~/.local/state/agent-harness/sessions/ to gain a bounded denied_spawns list once the guard has refused a constrained-role spawn in that session. It is pruned with the record and read by nothing else.

Recovery

• Preserve reported conflicts, adopted backups, external viewer adapter descriptors and external viewer installations.
• To return to v0.11.0, check out that tag and run harness sync once; v0.11.0 ignores the denied_spawns key in a session record, and a BMad framework checkout keeps working with or without the marker line.
• Use harness uninstall --dry-run before uninstalling, and follow docs/runtime-installation.md for rollback and ownership recovery; use docs/bmad.md for task continuation.

agent-harness v0.11.0

Your way of working, across AI agents.

A general-purpose, model-provider-agnostic harness built around you. Define how your agents work through shared rules, skills, roles, workflows, and custom primitives—including personal stances you can switch without rewriting your instructions.

Personal stances turn your working preferences into explicit switches. Choose how agents delegate, test, communicate, exercise autonomy, and approach decisions. Select a different stance when the situation changes, or define your own. The harness applies those choices through supported agent runtimes.

Compatibility

• claude-code-cli-macos: qualified
• claude-code-vscode-macos: unqualified
• claude-code-cli-linux: qualified
• codex-cli-macos: qualified
• codex-vscode-macos: unqualified
• codex-desktop-macos: unqualified
• codex-cli-linux: qualified
• 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.10.0 by reviewing the generated v0.11.0 projection before applying it: sync now renders a native Claude Code agent definition for a role your cost variant or role bindings actually move, registers the three usage-feed hook events and installs the three band workers; the architecture-viewer preview is inert until an external adapter is registered and selected.

• Run harness sync --dry-run from the v0.11.0 checkout and inspect every proposed write, ownership change and conflict. Each agent line names a role whose rendering under your selected cost variant and role_bindings differs from the shipped projection; only those roles are written as managed files, every other role keeps its managed link, and an install on balanced with no role bindings is unchanged.
• Run harness sync only after resolving unmanaged-file and adoption conflicts. It registers three further Claude Code hook events in your settings — UserPromptSubmit, SubagentStart and SubagentStop, the usage feed — and leaves your own hooks on those events untouched; Codex raises none of them and declares the feed uncovered.
• Expect three new roles to install as agents: worker-a, worker-b and worker-c. A runtime loads its agent list once at process start, so unnamed subagent spawns are routed to your cost variant's default_band worker only in a session started after the sync; start a new session before relying on it.
• Expect new owner-only local state under ~/.local/state/agent-harness/: feed/ per-session usage-feed files and sessions/ session records. Both are pruned automatically and both are removed by harness uninstall. usage.jsonl gains subagent and worker rows beside the session rows; run harness usage --rescan once over the window you care about to correct history, because earlier output-token totals were undercounted.
• To keep 0.10.0's behaviour without downgrading, select a cost variant whose switches set turn_feed to off and which sets no default_band and no budgets anywhere on its extends chain: nothing is injected, nothing is written and no unnamed spawn is routed. See docs/primitive-authoring.md for the sidecar contract.

Recovery

• Preserve reported conflicts, adopted backups, external viewer adapter descriptors and external viewer installations.
• To restore every agent link before checking out v0.10.0, select the balanced cost variant with no role_bindings and run harness sync once; sync retires each rendered definition it owns and relinks the committed projection. Alternatively run harness uninstall first.
• Use harness uninstall --dry-run before uninstalling, and follow docs/runtime-installation.md for rollback and ownership recovery; use docs/bmad.md for task continuation.

agent-harness v0.10.0

Your way of working, across AI agents.

A general-purpose, model-provider-agnostic harness built around you. Define how your agents work through shared rules, skills, roles, workflows, and custom primitives—including personal stances you can switch without rewriting your instructions.

Personal stances turn your working preferences into explicit switches. Choose how agents delegate, test, communicate, exercise autonomy, and approach decisions. Select a different stance when the situation changes, or define your own. The harness applies those choices through supported agent runtimes.

Compatibility

• claude-code-cli-macos: qualified
• claude-code-vscode-macos: unqualified
• claude-code-cli-linux: qualified
• codex-cli-macos: qualified
• codex-vscode-macos: unqualified
• codex-desktop-macos: unqualified
• codex-cli-linux: qualified
• 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.9.0 by reviewing the generated v0.10.0 projection before applying it; the architecture-viewer preview is inert until an external adapter is registered and selected.

• Run harness sync --dry-run from the v0.10.0 checkout and inspect every proposed write, ownership change and conflict.
• Run harness sync only after resolving unmanaged-file and adoption conflicts; the default builtin architecture-viewer selection remains unavailable and sync never launches a viewer.

Recovery

• Preserve reported conflicts, adopted backups, external viewer adapter descriptors and external viewer installations.
• Use harness uninstall --dry-run before uninstalling, and follow docs/runtime-installation.md for rollback and ownership recovery; use docs/bmad.md for task continuation.

agent-harness v0.9.0

Your way of working, across AI agents.

A general-purpose, model-provider-agnostic harness built around you. Define how your agents work through shared rules, skills, roles, workflows, and custom primitives—including personal stances you can switch without rewriting your instructions.

Personal stances turn your working preferences into explicit switches. Choose how agents delegate, test, communicate, exercise autonomy, and approach decisions. Select a different stance when the situation changes, or define your own. The harness applies those choices through supported agent runtimes.

Compatibility

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

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

Migration

Sync projects one shared catalog into selected runtimes. Review drift and adoption conflicts before applying.
Read docs/runtime-installation.md for recovery and docs/bmad.md for task continuation.