mathiasandClaude Sonnet 5
bdba49b756
Review of PR #132 found a real bug in the first-occurrence-wins fix: routing every one of b's occurrences of a normalized heading to a's single first occurrence means a self-merge (or a revision pass echoing a page back unchanged, exactly what #106 can produce) pairs b's SECOND "## NOTES" against a's FIRST "## Notes" -- different content, same normalized key -- and MergeReport wrongly reports a disagreement where none exists. Inert in #130 (fed the vestigial Merge wrapper, which discards conflicts) and only became visible once correctly wired into MergeReport, the function production actually calls. Fixed by pairing occurrences positionally: a's on-disk sections sharing a normalized heading are collected into an ordered list per key: b's 1st occurrence of that key pairs with a's 1st, b's 2nd with a's 2nd, and so on. b having MORE occurrences than a appends the extra as new content and registers it, so a third occurrence in b pairs with that newly appended one rather than creating yet another duplicate. Flip-tested: forcing every pairing back to position 0 (the prior fix's actual behavior) turns the new self-merge test red; the positional version stays green, and the original PR #130 regression test (fresh content must route to the first occurrence when b has only one occurrence) still passes unchanged -- the two fixes aren't in tension, positional pairing subsumes first-occurrence-wins as the pos==0 case. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>