One copy plan that both the CLI and the browser render #8

New issue

Open

opened 2026-08-25 22:29:45 +02:00 by wokoman · 0 comments

wokoman commented

2026-08-25 22:29:45 +02:00

(Migrated from code.nolog.cz)

What to build

One answer to "what will this copy do", produced by the copy module and rendered by whoever asked — the command line prints it, the browser puts it in a confirmation popup.

Both callers need the same four facts before a copy starts: which files were found, how many need converting, whether ffmpeg is available, and whether the copy should be refused outright. Neither asks for those facts; each assembles them by hand from three separate helpers. The predictable happened — the browser's version came out missing the refusal, which is #6.

Answering the question once, in the module that owns copying, means the two front ends differ only in how they present it. It also makes the pre-flight rules testable, which they currently are not in any form.

Something close to this already exists: the dry-run function answers a neighbouring question and reads every file's tags to do it. Whether the plan and the dry run become one thing or stay two is a design decision for whoever picks this up — worth settling first, because it decides how much of the existing function survives.

Acceptance criteria

The copy module produces a single plan describing what a copy would do
Both front ends render that plan rather than assembling their own
The refusal rule is part of the plan, so no caller can forget it
Command-line output and browser confirmation text are unchanged from the user's point of view
The plan is assertable in a test with no device attached
The relationship between the plan and the existing dry run is resolved deliberately, not left as two overlapping answers
cargo clippy --all-targets clean; full suite passes

Blocked by

#6 — that ticket puts the refusal rule in one place; this one moves it behind the plan. Doing them in the other order means writing the guard twice.

## What to build One answer to "what will this copy do", produced by the copy module and rendered by whoever asked — the command line prints it, the browser puts it in a confirmation popup. Both callers need the same four facts before a copy starts: which files were found, how many need converting, whether ffmpeg is available, and whether the copy should be refused outright. Neither asks for those facts; each assembles them by hand from three separate helpers. The predictable happened — the browser's version came out missing the refusal, which is #6. Answering the question once, in the module that owns copying, means the two front ends differ only in how they present it. It also makes the pre-flight rules testable, which they currently are not in any form. Something close to this already exists: the dry-run function answers a neighbouring question and reads every file's tags to do it. Whether the plan and the dry run become one thing or stay two is a design decision for whoever picks this up — worth settling first, because it decides how much of the existing function survives. ## Acceptance criteria - [ ] The copy module produces a single plan describing what a copy would do - [ ] Both front ends render that plan rather than assembling their own - [ ] The refusal rule is part of the plan, so no caller can forget it - [ ] Command-line output and browser confirmation text are unchanged from the user's point of view - [ ] The plan is assertable in a test with no device attached - [ ] The relationship between the plan and the existing dry run is resolved deliberately, not left as two overlapping answers - [ ] `cargo clippy --all-targets` clean; full suite passes ## Blocked by - #6 — that ticket puts the refusal rule in one place; this one moves it behind the plan. Doing them in the other order means writing the guard twice.