What changed in v9

v9 makes Haft narrower on the outside and stronger underneath. You keep working in Claude Code, Codex, or another host. Haft supplies the FPF source, project memory, code context, validation, and explicit human decision boundaries around that work.

Release status: v9.0.2 is current. It includes the v9.0.1 project-path migration repair and fixes conventional monorepo scope detection without changing the v9 capability or authority boundary. Projects upgrading from v9.0.0 should run haft init once so migration 58 can clean pre-v9 invalid affected_files rows.

1. FPF is retrieved from its source

Older Haft versions relied more heavily on Haft-owned routing concepts. v9 starts with the current engineering concern, retrieves candidates from the pinned FPF publication, and then opens the exact full pattern when it applies. The source remains the authority for FPF meaning; Haft does not maintain a second miniature FPF beside it.

2. Skills are capabilities, not a mandatory workflow

Use h-frame when the problem is unclear, h-diagnose when a failure has rival causes, h-compare when existing options need a fair comparison, and h-verify when an old claim must meet current evidence. h-reason is the umbrella when you do not yet know which kind of help the question needs. You do not march through all 12 skills in order.

3. Project memory is typed and conditional

Haft can keep problems, options, human decisions, specifications, evidence, and their relations as different project records. It writes durable memory when later work has a concrete reason to rely on it—handoff, another session, audit, automation, delayed evidence, or costly reversal. Small, reversible reasoning can stay in chat.

v9 organizes memory around the exact project thing currently in question, called an EntityOfConcern in the advanced model. Default memory is installed automatically. Compatible bundled memory-model upgrades are activated automatically; users are not asked to choose internal schemas.

4. Code and reasoning context meet in one graph

The agent can enter through a concern, file, or symbol and recover nearby decisions, specifications, invariants, and notes. This reduces the search space before an edit. Candidate rank and proximity remain orientation—not proof that a record governs the code.

5. Setup is explicit, but ordinary use stays simple

haft init --claude and haft init --codex publish the correct MCP configuration, skills, and managed instructions for that host. Re-init replaces recognized Haft-owned files without overwriting project instructions outside the managed markers. After setup, the normal interface is still conversation with the agent.

What v9 keeps

  • local-first storage with reviewable .haft/ files;
  • explicit human decisions, specifications, evidence freshness, and drift checks;
  • CLI, skills, and MCP surfaces over the same project state;
  • runner-neutral commission and run records for external integrations.

What v9 deliberately removes

  • haft run and haft harness;
  • the complete Open-Sleigh source and packaged runtime;
  • the Elixir/OTP/BEAM build, CI, installer, and archive dependency.

Haft no longer tries to be a second coding agent or execution runtime. There are no compatibility stubs for the removed commands. The existing host performs the work; Haft keeps the project model and boundaries around it. An independently operated runner can still consume commission records.

The v9 trade-off

v9 trades an all-in-one runtime for a smaller integration surface. That reduces packaging and execution complexity and lets people keep their preferred coding agent. It also means Haft itself will not create a worktree, run an agent, apply a patch, merge, push, deploy, or publish.

Next