Post-resolve dedupe: duplicate reads merge, review can veto

Rows resolving to the same (bgg_id, version_id — or both version- unknown) are the same physical game read twice unless their extraction cues conflict (two editions stay separate). The survivor is the read whose transcription matches the BGG name; losers are marked match_status=merged with a new merged_into column — no row is ever deleted, and older matches.csv files without the column still read. Downstream: diff skips merged rows but folds their photos into the survivor's to_add provenance; enrich and the review passes ignore them. The web UI gains a Merges section ("Jokin Ha... merged into Joking Hazard") with a veto (v key) that restores the row as a distinct approved match, plus a merged catalog chip and header tally. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-01 16:59:47 -04:00
parent 123e7b41a9
commit 8420a0a1ca
9 changed files with 377 additions and 6 deletions
@@ -60,6 +60,7 @@ Each stage reads the previous stage's artifact and writes its own. Re-running a
  - `unmatched` — nothing plausible found.
 - Expansions: BGG returns `boardgameexpansion` as a distinct type. Keep them — I own expansions and want them in the collection — but tag them so review can catch base-game/expansion confusion (a spine reading "Wingspan Europe" must not match base Wingspan).
 - Cache all BGG responses on disk (keyed by query/ID) so re-runs don't re-hit the API.
+- **Post-resolve dedupe**: rows resolving to the same (bgg_id, version_id — or both version-unknown) are the same physical game read twice (typo, partial spine) unless their extraction cues conflict (two editions). Losers get `match_status=merged` + a `merged_into` column pointing at the survivor — rows never silently disappear, the survivor keeps the combined photo provenance downstream, and review surfaces every merge with a veto that restores the row as a distinct approved match.
 - **Version resolution**: once a game ID is settled (auto or approved), fetch `/thing?id=<id>&versions=1` and score the version list against the extraction's edition cues (publisher, year, language, edition wording). Same three-way classification: a single clear winner is `version_auto`; multiple plausible → `version_ambiguous` (goes to review); no cues at all → `version_unknown` (acceptable — BGG allows collection entries with no version set, and guessing wrong is worse than leaving it blank).
 - Output: `matches.csv` with columns: `title_raw, bgg_id, bgg_name, year, type, match_status (auto|ambiguous|unmatched|approved|rejected), version_id, version_name, version_status (version_auto|version_ambiguous|version_unknown|version_approved), candidates_json, version_candidates_json, source_photos`.