v0.1.5 — a moved passage stops reading as a broken one

A moved passage stops reading as a broken one

If you run chamber verify in CI, 0.1.4 fires on every passage below an insertion. The pin formula contains the passage's position (path#pN), so adding a section at the top of a note re-slots everything under it and each pin reports hash_mismatch against text that did not change.

That is not a rare shape. A backtest over a real 44,000-passage vault measured nine false alarms from a single edit — half of all passage-level alarms inside edited files. A drift gate that cries wolf on an ordinary edit is one its reader learns to skip, which costs more than the feature is worth.

0.1.5 reports those as relocations: support intact, both positions named, kept out of the exit code. A genuinely edited passage still fails the run.

9 pinned passage(s) found at a new position in the same file:
  moved: 10 - Infrastructure/Skills Index.md#p0 → #p1
  (the pinned text was found intact at these positions; a duplicate
   passage in the same file is indistinguishable from a move)

The rescue is scoped to one file under one ingest root and requires byte-identical content through the same hash formula the pin was minted with, so it cannot weaken into a similarity match. verify --json gains relocatedPins and per-belief relocations; the composite Action passes them through untouched.

Measured, not asserted

scripts/backtest_drift.ts is the harness that found the defect, shipped so the claim can be re-tested against any git corpus instead of taken on trust:

npm run backtest:drift -- --repo ~/notes --from <rev> --exclude 'Private/**'

It stratifies on the interval's own diff (a uniform sample over 44k passages where 34 changed reports "recall n/a" — a clean-looking result that measured nothing), and it self-tests its ground-truth classifier against the starting state before reporting anything, because the first version of that classifier was wrong and confidently so.

On the vault it was built from: recall 100%, precision 84.6%, zero alarms across 366 untouched pins. The two remaining false positives are chunk-boundary re-cuts, and they stay alarms deliberately.

What is still true

A pinned passage that is edited while a byte-identical copy of its old text survives elsewhere in the same file reads as a move. Content-addressing cannot separate "the same paragraph, moved" from "a different paragraph that reads identically" — docs/KNOWN_LIMITATIONS.md entry 6 carries the full account and the fix it needs. Surfaces no longer claim "support intact" without saying so.

Also

• 0.1.0 deprecated: same broken install as 0.1.1/0.1.2 (no dist/), missed when those were deprecated.
• Eight probes now gate CI, up from six.

Full changelog: v0.1.4...v0.1.5