Haft v9.0.3

Haft 9.0.3

A patch release for the repeated project fingerprint walk in snapshot-backed
TypeScript code indexing, startup-safe project-ledger activation, and several
currentness and reporting defects. Its published predecessor is
v9.0.2.

TypeScript code-index fix

During a full incremental index, Haft already built one immutable project
snapshot and passed it to every TypeScript, JavaScript, and Vue resolver. The
resolver nevertheless loaded the standalone TypeScript project resolution
first. That load recomputed a project-configuration fingerprint with a full
tree walk for every indexed file, then discarded the result in favor of the
snapshot. On the repository reported in
#106, this made resolve account
for 98.5% of a roughly 25-minute first index.

Snapshot-backed resolution now reads the snapshot directly and never enters
that fallback loader. A regression test clears the standalone resolution cache
and proves that a full incremental refresh leaves it untouched. This removes
the once-per-indexed-file full-tree walk from the production EnsureIndex to
RefreshIncremental path. Standalone and other snapshot-less resolution keep
their existing fingerprint-based invalidation. This release makes no new
wall-time claim for the reporter's repository.

Safe startup migration

haft serve now activates every compatible startup migration before opening
project-backed tools. The first admitted chain is project-ledger schema 57 to
58. All entry points that can cross migration 58 share the same process and
file lease, revalidate the SQLite carrier, and write a verified private 0600
snapshot before changing data.

Migration 58 removes only legacy affected_files rows whose paths cannot be
expressed as canonical project-relative paths and were already excluded by the
read path. It verifies that none survive and logs the affected artifacts. An
already-current ledger remains a no-op.

Manual chains, missing bindings, future or invalid schemas, unhealthy ledgers,
lease timeouts, and stale WAL/SHM generations keep the MCP server alive but
project-backed tools closed, with a specific recovery diagnostic. Other legacy
CLI opens remain current-only and cannot bypass the coordinator.

Other fixes and diagnostics

• haft init --no-file-instructions preserves existing managed AGENTS.md
  and CLAUDE.md fragments while reconciling selected MCP and skill surfaces.
• haft host status reports currentness for discovered manifest-free skill
  roots without rewriting them or changing existing exit codes.
• haft spec review reports SQL-edition and Markdown-carrier drift by section
  hash and claim ID without changing lifecycle state.
• haft check and evidence-path output expose evidence freshness inventory;
  an unavailable auxiliary scan remains diagnostic and does not suppress the
  rest of the governance report.
• The README and documentation site use the shorter v9 product description;
  the detailed contract and authority boundaries remain in managed agent
  instructions, specifications, and tests.

Upgrade from v9.0.2

Install 9.0.3, then reconnect or restart the host so every MCP process loads
the new binary. The next haft serve may apply the compatible 57-to-58 ledger
migration automatically. If startup reports a manual migration boundary, use
the exact haft project migrate --project-root ... --project-id ... command
from that diagnostic. Future-schema, missing-binding, integrity, and stale
WAL/SHM failures have different recovery paths and must not be replaced with a
generic migration run. Keep the generated pre-migration snapshot until the
project has been checked.

Rolling the binary back to v9.0.2 does not restore rows removed by migration
58. v9.0.2 can read schema 58, while restoring the pre-migration database is a
separate offline recovery operation.

This committed note describes the release contract; it does not record P13 or
P14 evidence and is not release authority. Exact-main CI, tag validation, and
public GitHub Release publication remain separate actions.