HAR 1.0.0

HAR 1.0.0 changes one thing, and everything else follows: the runtime lives in the package, and .har/ is only what is yours.

Pre-1.0, har env init copied the machinery into every repo — an 812-line agent-slot.sh, provisioning scripts, and lifecycle logic. Across three boilerplate profiles that was about 8,800 lines of template, 2,400 of them byte-identical duplicates. A bug fix had to land three times, and an already-adapted harness usually never got it.

In 1.0 the machinery runs once. .har/ keeps config, stages, hooks, and plugins. The ./.har/*.sh entry points are thin shims (exec har env …), so the CLI, MCP, and raw scripts write the same run records. Muscle memory does not change: har env launch 1 and ./.har/verify.sh 1 --full still work.

If you already have a harness, start at the migration guide — or copy the prompt above into your coding agent. How we shipped this is a separate piece: The factory line.

What you keep, what HAR manages

Customization has five sanctioned homes: config values, registered stages, lifecycle hooks, plugins (including local ones), and — if you genuinely want to own the runtime — har env eject. har env doctor validates the whole contract.

On this repository the migration took the main harness from 2,010 lines of shell (812 of them runtime) to 940. Machinery lines remaining: zero. har env doctor is green on all three harnesses here.

What did not break

• ./.har/launch.sh 1 / verify.sh 1 --full / teardown.sh 1
• har env … and the MCP tools
• Existing stages.json ids and slot registries

Pre-1.0 vendored scripts keep working against the 1.0 CLI for a compatibility window — you get deprecation warnings, not a brick. Migrate when ready.

What 1.0 does retire: vendored-script internals, add-stage --custom (use a local plugin), shell functions in harness.env, and treating every drift warning as noise.

What else shipped

Grouped from the 1.0.0 milestone:

• One runtime. The harness implementation moved into @osfactory/har (#234). Installed scripts are shims with a pinned npx fallback (#235). CLI and MCP share the launch guard (#233).
• Config, not shell. harness.env is schema-validated KEY=value (#230). Profiles are capability manifests, not forked file trees (#236).
• Verification as data. One stage namespace, quick and full tiers (#231). har env doctor is the contract check (#232). Drift distinguishes “you edited this” from “upstream changed” (#237).
• Extension points. Lifecycle hooks (#238), har env eject (#239), and har plugin create for local plugins — which retires add-stage --custom (#240).
• A real migration. har env maintain detects the pre-1.0 shape, writes MIGRATE-PROMPT.md, and --migrate does the mechanical rewrite (#241). Agents read one instruction file: AGENTS.md (#301).

The full issue-by-issue list is on the v1.0.0 GitHub release.

Upgrade the CLI before the shims

If the har on PATH is older than 1.0, a 1.0 shim can exec back into that binary, which executes the shim again. That loop took a machine to 2,306 node processes. The shims now refuse (exit 86) instead of forking forever.

npm install -g @osfactory/har@latest

In CI, put the runtime you mean to test on PATH before any ./.har/*.sh step.

Migrate

From the directory that owns .har/:

har env maintain
har env maintain --migrate   # after you have read the prompt
har env doctor
har env launch 1 && har env verify 1 --full
har env maintain --finalize --summary "Migrated to the 1.0 config surface"

The migration guide is the operator checklist. The copy button at the top of this post is a starter you can paste into Cursor, Claude, or Codex.

How the line that produced 1.0 actually ran — stations, a cumulative gate, and the questions nobody thought to ask — is The factory line.