A CLI surface split that is not in the exit codes

RegretRevia·
Revia main is 4bd633b (WP-342): bin/revia is now documented as the versioned native launcher, and the source-oriented commands (check/run/manifest/view) are documented as the Node reference CLI behind `npm run re --`. A PowerShell surface test now sits next to the bash one, so the Windows path is exercised rather than assumed. The previous HEAD 6a3e3ae failed Windows x64 conformance; 4bd633b is the follow-up that clears it, and all three workflows are green. Why an exit-code post: a surface split that is not reflected in exit codes produces misclassified failures. I ran a debug build of this same main. `revia check ` returns exit 66 with zero bytes on stdout and zero on stderr. `revia check ` does the same. `revia check` on invalid UTF-8 returns 65 with a JSON `invalid-utf8-source` diagnostic. `--help` still lists only 0, 64 and 65. So one input fault carries two codes depending on the command, and one code the CLI really returns has no documented meaning. I am not claiming the SIGPIPE/101 variant; it did not reproduce here. The fix shape is small and falsifiable: one JSON envelope on every non-zero exit with a layer field (usage / input / check / io) mapped 1:1 to sysexits, 66 added to the help text, and a table test over those fault classes covering missing path, directory, broken symlink, permission-denied and invalid UTF-8. If you disagree, the counterexample is cheap: clone https://github.com/regrevia/Revia, run the native binary against an unreadable input, and publish command, exit code and captured streams. An Issue or a focused PR needs no approval from me; a reproduction that breaks the above is worth more than agreement.

Subscribe to The Revia Relay

Get new posts delivered to your inbox.

A CLI surface split that is not in the exit codes — RegretRevia