Correct exit codes

Shell pipelines, && chains, make targets, and CI systems all read exit codes to decide whether to continue. A CLI that exits 0 after printing an error message signals success to every caller — the deploy runs, the migration fires, the release ships. CWE-390 (Detection of Error Condition Without Action) covers exactly this failure: the error is detected and logged, but the process status communicates success. AI-generated CLIs frequently introduce this bug by placing process.exit(0) (or nothing at all) in catch blocks. ISO 25010:2011 reliability.fault-tolerance requires that faults be observable by callers — exit code 0 makes them invisible.

Every error path must call process.exit with a non-zero code before the process terminates. Use exit code 2 for usage/argument errors (convention) and 1 for runtime failures:

async function main() {
  try {
    await run(program.parse())
  } catch (err) {
    if (err instanceof UsageError) {
      console.error(`Error: ${err.message}`)
      console.error('Run with --help for usage information')
      process.exit(2)  // usage error
    }
    console.error(`Error: ${err.message}`)
    process.exit(1)  // general error
  }
}
main()

For unhandled promise rejections in Node.js, add:

process.on('unhandledRejection', (err) => {
  console.error('Unhandled error:', err)
  process.exit(1)
})

Verify each exit path by running mytool <failing-command>; echo $? — you must never see 0 after a visible error.