@@ -14,3 +14,3 @@
 **Multi-state verdicts**: When the tool's verdict has more than two states, give each state its own documented exit code instead of making callers parse output. `grep` is the classic form — `0` match, `1` no match, `2` error — and `gh pr checks` the modern one: `0` passing, `1` failing, a documented `8` while checks are pending, so a script can wait on pending without scraping prose. Keep `0` for the good state, give each remaining state — errors included — its own nonzero code, and document every code in `--help`. When one table in the code maps states to codes, render help's list from that table. The README points at `--help` for the codes and keeps what help can't show, such as which codes are safe to retry. Avoid codes with reserved meanings: `126`–`127` (not executable / not found) and `128+n` (killed by signal `n`).
 
-**How to verify**: Search for `process.exit()` and `process.exitCode` usage. Ensure success returns 0 and errors return non-zero. Test: run CLI without required args and verify exit code is non-zero. If the tool's domain has a more-than-binary verdict, check that distinct states get distinct exit codes and that `--help` documents them, rendered from the code's state-to-code table when one exists.
+**How to verify**: Search for `process.exit()` and `process.exitCode` usage. Ensure success returns 0 and errors return non-zero. Test: run CLI without required args and verify exit code is non-zero. If the tool's domain has a more-than-binary verdict, check that distinct states get distinct exit codes and that `--help` documents them, rendered from the code's state-to-code table when one exists. Check that the README points at `--help` for the codes and keeps any retry guidance that help cannot show.