exit-inventory enumerates every process-exit site in safegit's production Go sources so the exit-code registry (internal/exitcode) can be derived from what the code actually does rather than from memory.
#scripts
#scripts
exit-inventory enumerates every process-exit site in safegit's production Go sources so the exit-code registry (internal/exitcode) can be derived from what the code actually does rather than from memory.
Run it through the wrapper:
scripts/exit-inventory # human table, grouped by code scripts/exit-inventory --tsv # one tab-separated row per site
Five site kinds are recognized, by AST shape rather than by regex:
die(N, ...) safegit's own fatal helper (main.go) os.Exit(N) a direct process exit strictcli.Exit(N) a handler's outcome, which the framework exits with return N a nonzero return from an int-returning function in package main -- safegit's handlers and their run* helpers propagate exit codes this way err.Code a Code: field in a composite literal, which is how internal/commit's CommitError carries an exit code out to the caller that os.Exit()s it
A site whose code is not an integer literal (a variable, a call, a named constant that is not resolved here) is reported with code -1 and the expression text, so the review pass sees it instead of losing it. Each row names its enclosing function, because the return kind necessarily over-reports: an int-returning helper in package main that computes a count rather than an exit code looks identical to a handler from the AST. Reading the enclosing function name is how the review pass separates them.
Test files are excluded: they assert exit codes, they do not define them.