mathiasandClaude Sonnet 5
28d9f40733
Review of PR #130 found a real bug in the new normalizeHeading matching: idx was built with idx[normalizeHeading(s.heading)] = i, plain map assignment while iterating secsA — last write wins. A page that already carries two on-disk sections differing only by case or whitespace (real, pre-existing corpus drift, the exact pattern #106 itself cites) never collided in idx before this normalization existed, since it keyed on the exact string. After normalization they collide, and every future update silently, deterministically routes to whichever duplicate happens to sort last in the file — the first one is frozen forever, never receiving an update again, with nothing to say so. Same bug class parseSections's own doc comment already warns about (two keys sharing one map slot means one loses lookup visibility), reintroduced here. Fixed by keeping only the first occurrence's index when a collision happens while building idx — deterministic, and matches "earliest is canonical," the same reasoning behind every other on-disk-wins default in this file. New test reproduces the exact review finding with a positional assertion (the fresh bullet must land adjacent to the first occurrence's own content, not the second) — a Contains-only version of this test would have passed even with the bug present, since nothing is literally deleted, a bullet just silently routes to the wrong of two still-present sections. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>