Context
Discovered during review of #4741 (part of epic #4737's REES/deterministic-tier phase, PR #4760).
Non-urgent — the current behavior is a documented, acknowledged v1 heuristic limit, not a defect.
The problem
assignSurvivors (review-enrichment/src/analyzers/duplication-delta.ts) greedily assigns each OLD
(pre-PR) duplicate block to the first UNCLAIMED matching NEW (post-PR) block, in file order. This is
not a globally optimal bipartite matching. In a multi-candidate scenario where old blocks match NEW
occurrences asymmetrically — e.g. old block A matches BOTH of the two remaining NEW occurrences, but
old block B matches only one of them — first-come-first-claimed can let A grab the occurrence B needed,
leaving B unmatched even though a different (optimal) assignment would have paired both.
Practical effect: the analyzer can occasionally report a duplicate pair as "resolved" when it is, in
fact, still present. Advisory-only, never a crash or a data-integrity issue (this signal never gates
anything, per epic #4737's design constraints) — but a real accuracy gap worth closing eventually.
Fix
Replace the greedy assignment in assignSurvivors with a true maximum bipartite matching (e.g. an
augmenting-path search / Hopcroft-Karp-style algorithm) over the old-block/new-block candidate graph.
Keep the existing fail-safe behavior (an aborted signal must still stop early and never report a
partial/stale result as conclusive) and the existing public contract (boolean[] parallel to
oldBlocks).
Acceptance criteria
Context
Discovered during review of #4741 (part of epic #4737's REES/deterministic-tier phase, PR #4760).
Non-urgent — the current behavior is a documented, acknowledged v1 heuristic limit, not a defect.
The problem
assignSurvivors(review-enrichment/src/analyzers/duplication-delta.ts) greedily assigns each OLD(pre-PR) duplicate block to the first UNCLAIMED matching NEW (post-PR) block, in file order. This is
not a globally optimal bipartite matching. In a multi-candidate scenario where old blocks match NEW
occurrences asymmetrically — e.g. old block A matches BOTH of the two remaining NEW occurrences, but
old block B matches only one of them — first-come-first-claimed can let A grab the occurrence B needed,
leaving B unmatched even though a different (optimal) assignment would have paired both.
Practical effect: the analyzer can occasionally report a duplicate pair as "resolved" when it is, in
fact, still present. Advisory-only, never a crash or a data-integrity issue (this signal never gates
anything, per epic #4737's design constraints) — but a real accuracy gap worth closing eventually.
Fix
Replace the greedy assignment in
assignSurvivorswith a true maximum bipartite matching (e.g. anaugmenting-path search / Hopcroft-Karp-style algorithm) over the old-block/new-block candidate graph.
Keep the existing fail-safe behavior (an aborted signal must still stop early and never report a
partial/stale result as conclusive) and the existing public contract (
boolean[]parallel tooldBlocks).Acceptance criteria
assignSurvivors(or its replacement) produces a maximum matching, not just a greedy one —regression test reproducing the exact asymmetric scenario described above (A matches both
remaining occurrences, B matches only one) and asserting BOTH old blocks are correctly reported
as surviving.
duplication-delta.test.tssuite continues to pass).reporting them as conclusive.
docs.notes(in all three registration sites —registry.ts,apps/gittensory-ui/src/lib/rees-analyzers.ts,analyzer-metadata.json) to removethe "known v1 limitation" caveat once this lands.