Build the side-by-side near-duplicate resolution UI #17

New issue

Open

opened 2026-07-28 04:55:03 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-28 04:55:03 +00:00

Context

Near-duplicate detection produces candidate pairs; a reviewer has to decide what each
pair actually is. This UI was an explicit Phase 1 non-goal and is the reason detection
alone is not enough.

Scope

A side-by-side comparison view for resolving near-duplicate pairs.

Implementation notes

Show both scans at full resolution, side by side, with synchronized zoom and pan so
fine differences (crop, exposure, a torn corner) are actually visible.
Surface each photo's metadata next to it: filename, album, sequence, evidence summary,
current decision, and the pair's distance score.
Reviewer outcomes: mark as duplicates and pick the preferred scan; mark as distinct
photos (suppressing the pair permanently); or defer.
"Not a duplicate" must be sticky â€” the pair should never resurface after a rescan,
or reviewers will re-adjudicate the same pairs forever.
Choosing a preferred scan must not delete the other. Preservation is a core product
principle; the non-preferred scan is demoted and stays retrievable, and the action is
reversible.
Merging should carry evidence and decisions across rather than discarding the
non-preferred photo's review history.
A queue view listing outstanding pairs ordered by confidence, with keyboard-driven
progression â€” this is bulk work and mouse-only navigation makes it tedious.
Every resolution emits an audit event.

Done when

A reviewer can compare a pair side by side with synchronized zoom
All three outcomes are available and audited
Dismissed pairs never reappear
No resolution path deletes image data
The queue can be worked through from the keyboard

References

docs/circa-wireframes.md, docs/circa-ui-spec.md
README.md Phase 1 non-goals ("Near-duplicate resolution UI")

Depends on: near-duplicate detection.

## Context Near-duplicate detection produces candidate pairs; a reviewer has to decide what each pair actually is. This UI was an explicit Phase 1 non-goal and is the reason detection alone is not enough. ## Scope A side-by-side comparison view for resolving near-duplicate pairs. ## Implementation notes - Show both scans at full resolution, side by side, with synchronized zoom and pan so fine differences (crop, exposure, a torn corner) are actually visible. - Surface each photo's metadata next to it: filename, album, sequence, evidence summary, current decision, and the pair's distance score. - Reviewer outcomes: mark as duplicates and pick the preferred scan; mark as distinct photos (suppressing the pair permanently); or defer. - "Not a duplicate" must be sticky â€” the pair should never resurface after a rescan, or reviewers will re-adjudicate the same pairs forever. - Choosing a preferred scan must not delete the other. Preservation is a core product principle; the non-preferred scan is demoted and stays retrievable, and the action is reversible. - Merging should carry evidence and decisions across rather than discarding the non-preferred photo's review history. - A queue view listing outstanding pairs ordered by confidence, with keyboard-driven progression â€” this is bulk work and mouse-only navigation makes it tedious. - Every resolution emits an audit event. ## Done when - [ ] A reviewer can compare a pair side by side with synchronized zoom - [ ] All three outcomes are available and audited - [ ] Dismissed pairs never reappear - [ ] No resolution path deletes image data - [ ] The queue can be worked through from the keyboard ## References - `docs/circa-wireframes.md`, `docs/circa-ui-spec.md` - `README.md` Phase 1 non-goals ("Near-duplicate resolution UI") Depends on: near-duplicate detection.

claude-bot added this to the v0.4.0 milestone

2026-07-28 04:55:03 +00:00

claude-bot added the

enhancement

frontend

labels

2026-07-28 04:55:03 +00:00

claude-bot referenced this issue

2026-07-28 06:03:04 +00:00

Review workspace has no next/previous navigation or queue context #95

claude-bot referenced this issue

2026-07-28 06:07:50 +00:00