Haft 9.0.1

A patch release for one defect. Its published predecessor is v9.0.0. No contract, capability, or authority boundary changes in this release.

The defect

v9.0.0 introduced the canonical project-relative path invariant for affected_files and enforced it on both the write and the read path, but shipped no migration for rows admitted before that invariant existed.

A project database carrying even one absolute or traversing path — for example an agent attachment recorded as an affected file — failed every concern-seeded explore call:

fuse concern reasoning: stored affected file for <artifact-id>:
affected file: path "<absolute path>" must be a canonical project-relative path

Symbol-seeded explore was unaffected, which is why the failure read as intermittent rather than as a whole surface being down. The root cause is not a wrong path rule and not a corrupt database: it is a strict read-side invariant introduced without a paired migration, combined with a read that failed the entire projection on the first row it could not express.

Fresh installations were never affected. Both write paths have canonicalized since v9.0.0, so only databases that predate the invariant carry such rows.

What changed

AllAffectedFiles and GetAffectedFiles now exclude a row the current path invariant cannot express instead of failing the read. The projection returns the expressible rows together with a named Skipped entry per excluded row, so the gap stays visible as data rather than disappearing into a silently narrower graph. Concern fusion reports the count as unexpressible_affected_files in its basis.

Kernel migration 58 drops the rows that cannot be expressed. The invariant belongs to internal/projectpath, so the migration asks that package rather than restating the rule in SQL, verifies that no such row survives, and names every dropped row and artifact instead of deleting silently.

The two repairs are independent on purpose: the read fix restores explore even where the migration has not run yet, and the migration makes the stored table agree with what every reader can express.

Upgrade from v9.0.0

Install the new binary, then run haft init once in each existing project:

haft init            # applies kernel migration 58

Migration 58 applies during haft init. haft serve and the read-only surfaces require an already-current schema and report kernel schema is not current until that one command has run. Restart any host session afterwards so every MCP process loads the same binary.

A database that never carried a pre-invariant row pays nothing and reports nothing. This release adds no schema objects and removes no capability.

This committed note describes the release contract; it does not record a P13 or P14 result and is not release authority. Tag validation and public GitHub Release publication are separate operator-controlled actions.