[ergofobe]

Closes #27.

upload, download and edit each ran a batch and each decided for itself what a refusal meant:

• edit exited 0 when every edit was refused. It printed Edited 0 photographs. and returned Ok(()). A script that submitted a hundred edits and had a hundred refused saw success — which is what undercut assets edit drops the fields a 400 named, and prints raw JSON at the person #23, since the rejection said which field was wrong and $? still said nothing was.
• upload --json wrote two documents when a file failed. The summary, then main::report's {"error":"N files failed",…} after it, on the same stdout. jq and every ordinary parser choke on the second.
• download --json exited 0 where the identical run in prose exited 1. Its JSON branch returned before the bail!.

The rule

One finish_batch in src/commands/mod.rs, called by all three.

Exit status. 0 when nothing was refused; 1 when nothing got through; 3 when some items succeeded and some were refused.

The partial case is the decision the three drifted apart over, so it is worth saying why 3. A script that fires a hundred uploads wants to know which failure it has: "the server is down / the token is wrong / nothing landed" calls for stopping and shouting, and "ninety-seven landed, three were refused" calls for reading failures and retrying those three. Collapsing both into 1 throws that away and costs a document read to recover. 2 is not used, because clap already exits with it for a command line it could not parse, and a script cannot tell a usage error from a batch outcome if they share a code. A file the server already had, and a download skipped because it was already on disk, count as got through: the caller asked for the file to be there and it is.

One document. In --json a failing batch writes nothing to stdout itself. The summary travels out with BatchFailure and main::report writes it once, with the sentence added under error so a reader looking only for that key is not misled by a document full of items. Success still writes the summary from the command. Whichever way the run went, stdout parses as exactly one document.

Prose. A run that got nothing through no longer closes with a green summary line saying so — Edited 0 photographs. immediately above error: 2 photographs failed was the success line contradicting the exit status. All three leave it out when nothing succeeded.

This is a behaviour change for scripts

Someone may be relying on today's zero. Plainly:

Run	Today	Now
edit with every edit refused	0	1
edit partly refused	0	3
download --json with a failure	0	1 or 3
upload/download prose, all refused	1	1
upload/download partly refused	1	3
anything wholly successful	0	0

The prose sentence for a wholly failed run is unchanged (error: 3 files failed); a partial one now reads error: 1 of 5 files failed.

Tests

Written first and watched fail — all three failed against main for exactly the reason #27 gives, and the upload one printed the two concatenated documents verbatim.

They run the real program against a stub HTTP server (std TcpListener, no new dependency), because $? and the bytes on stdout only exist once there is a process. The single-document property is asserted by parsing the whole of stdout as a JSON stream and counting what comes out — a second document is invisible to a grep and obvious to a parser.

cargo test --locked && cargo fmt --check && cargo clippy --all-targets --locked -- -D warnings && cargo build --release --locked is green: 137 unit, 4 integration.

Found, not fixed

• An album-fill failure still exits 0 and is absent from the --json document. upload.rs renders it with ctx.out.warn(format!("Could not fill an album: {error}")) and never makes it a Failure, so finish_batch counts none. This is explicitly Two seams left by the error-reporting rework: a lost download path, and an un-migrated album failure #34's second half, which says it should "participate in whatever exit rule The batch commands disagree about exit status, and upload --json emits two documents #27 settles" — it is a few lines above the finish_batch call this PR added, and deliberately left where it is. Whoever takes Two seams left by the error-reporting rework: a lost download path, and an un-migrated album failure #34 gets a one-line landing site.
• An empty --json batch writes no document at all. Nothing to upload. / Nothing matched. go to stderr and stdout stays empty, so a script gets nothing rather than a summary of zeros. Not a parse failure, so it is not part of The batch commands disagree about exit status, and upload --json emits two documents #27's defect; the README now says so rather than over-promising. Settling it means settling the --dry-run shapes alongside it.

🤖 Generated with Claude Code