Deduplicate never shows which specific files will be kept vs. deleted before the confirmation prompt

[matt-edmondson]

What's wrong

Scan and DryRun both print a full per-group KEEP:/DELETE: listing of every affected path before doing anything. Deduplicate.Run (FileDeduplicator/Verbs/Deduplicate.cs:63-68) instead only prints a generic count and policy statement — "Found {duplicates.Count} group(s) of duplicate files." / "Keeping the copy with the shortest filename in each group." — before asking "Proceed with deletion? (y/N): ". The actual paths to be deleted only appear (via Console.WriteLine($" Deleted: {file}")) after each file is already gone.

Failure scenario

The "keep shortest filename" heuristic is a blunt policy — e.g. two identical files report-final-DO-NOT-DELETE.pdf and r.pdf would keep r.pdf and delete the other. Because Deduplicate never lists which files fall into which bucket, a user confirming y has no way to catch a bad outcome before the deletion is irreversible, unlike DryRun/Scan which would have shown it. This undermines the confirmation step's purpose as a safety gate for a destructive operation.

Suggested fix

Before the y/N prompt, print the same per-group KEEP/DELETE listing that DryRun.Run already produces (the listing logic is essentially duplicated between Deduplicate.Run, DryRun.Run, and Scan.Run and could be shared).

Acceptance criteria

Running Deduplicate interactively shows every path to be deleted, grouped with its kept counterpart, before the confirmation prompt is presented.

[matt-edmondson]

Triage

Category: Improvement (safety / UX of a destructive operation)
Priority: High
Area: FileDeduplicator/Verbs/Deduplicate.cs — Run

Categorised as an Improvement because nothing malfunctions, but priority is High because it defeats the purpose of the confirmation prompt. The user is asked to approve an irreversible deletion while being shown only a count and a policy sentence; the paths appear only after each file is already gone. The "keep the shortest filename" heuristic makes this concrete — the issue's report-final-DO-NOT-DELETE.pdf versus r.pdf example is exactly the outcome a user would catch if they could see it.

The asymmetry is the strongest argument for fixing it: Scan and DryRun both already print the full per-group KEEP/DELETE listing. The one command where it actually matters is the one that omits it.

Related: #112 (Critical) and #113 in this repo are the other two defects in this same flow. One PR for all three would be the sensible shape — this issue also notes the listing logic is already duplicated across Deduplicate.Run, DryRun.Run and Scan.Run, so extracting it shared is the natural first step for the set.

Not covered by an open PR.

Suggested next step: extract the shared listing helper, call it before the y/N prompt, and consider paging or a summary cap for very large result sets so the prompt does not scroll off-screen.

---

Generated by Claude Code