## Problem `drush audit_trail:rewrite-archive --id=<id that does not exist>` exits 1. Every other command in the class exits 2 for the same input, and 1 has a different meaning. Measured: `rewriteArchive(['id' => 999999])` on a site with no such segment returns `1`. `archiveVerify(['id' => 999999])` on the same site returns `2`. ## Why it is wrong `AuditTrailCommands` opens with the contract, and `docs/verification.md` tells operators to script against it with `drush audit_trail:verify || mail`: > - 1 (`EXIT_FAILURE`): the audited state is bad. A chain verified broken, an archive failed its checks. The data is the problem, and the command worked. > - 2 (`EXIT_CANNOT_RUN`): the command could not run. A missing or unusable option, a chain or archive id that does not exist, a lock it could not take, an exception it has no handling for. Nothing was learned about the audited state. An archive id that does not exist is named in the 2 clause. The command's own docblock promises both codes, "0 when the archive was rebuilt, 2 when the command could not run, 1 when the rebuild was refused", and the code can only produce 2 for a missing `--id`: every throw out of `rewriteMissingArchiveFile()` becomes 1. So a wrapper reading the exit code is told the audit data is bad when what happened is a typo in the id, which is precisely the confusion the contract was written to remove: > The two meanings used to be swapped between commands. `audit_trail:verify` reported a break as 1 and an error as 2, while `audit_trail:archive-verify` reported bad arguments as 1 and a FAILED archive as 2, so no wrapper could apply one rule to both. The refusals the command exists for stay at 1, and should. A rebuild refused because the file is still there, because the segment was never archived, or because the rebuilt bytes do not match the digest that was signed, is a verdict about the audited state. The unknown id is the one case on the other side of the line. ## The change An id no segment carries is refused before the rebuild is attempted, the way `verify`, `acknowledge-reset`, `reindex-*` and `compact` refuse an unknown chain: reported, and `EXIT_CANNOT_RUN`. The rest of what `rewriteMissingArchiveFile()` refuses splits the same way, and did not. Measured against the contract at the top of `AuditTrailCommands`, two of its refusals are about the trail and four are not. Rows that no longer produce the digest they were signed with, and a digest the segment's own signature does not validate, are the data being the problem; both messages end by telling the operator to verify the chain. A segment that was never archived, one whose rows retention has already taken, a file still on disk, and a rebuild that could not be moved into place say nothing about the trail at all, and their remedies are to run a different command or move a file. The command could not tell them apart, because the catch was `\Throwable` and every one of them is a `\RuntimeException`. `Archive\ArchiveIntegrityException` now marks the ones about the data; the blanket catch answers `EXIT_CANNOT_RUN`. Typed that way round on purpose: a refusal added later defaults to "nothing was learned", where the other default would have new code reporting a healthy trail as damaged. It is also the shape the rest of the class already had. Of its nineteen catch arms, eighteen return `EXIT_CANNOT_RUN`; this command was the one returning `EXIT_FAILURE` from a blanket catch. ## User interface changes None. `docs/commands.md` gains the line saying which refusal gives which exit code, since a `|| mail` wrapper is the reason the split exists. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its test. I reviewed both, and the new test was confirmed to fail against the unpatched module and to pass with the change.)