go-cli-status-exit-code-stale-binary
Deliverable: ~/solution.md — self-contained solution writeup.
The exit-0 report is a stale-binary trap, not a code bug:
- Canonical ./bin/rabbit-hole (v1.0.0-429-g35e2a0e) already exits 1: status.go's RunE returns the daemon error and main.go (commit a6dfa23) calls os.Exit(1) when Execute() errors.
- The row reproduced against the untracked root artifact ~/rabbit-hole/rabbit-hole (Aug 10, v1.0.0-dev), built from a commit predating a6dfa23, gitignored via /rabbit-hole so nothing ever rebuilt it. It also independently explains the missing classify-server subcommand and pre-GAP-008 help (row GAP-009).
A faithful minimal mirror reproduced both behaviors with identical error text:
- pre-a6dfa23 (_ = rootCmd.Execute()): prints Error: cannot reach Rabbit-Hole daemon at http://<ip-address>:9734 ... connection refused → exit 0
- post-a6dfa23 (os.Exit(1) on error): same message → exit 1
This confirms the error message and exit code are decoupled — Cobra prints the error, only main.go's os.Exit(1) sets the status.
cd ~/rabbit-hole
git ls-files --error-unmatch rabbit-hole 2>/dev/null || echo "untracked: safe to delete"
rm -f rabbit-hole
make build # regenerates canonical bin/rabbit-hole from HEAD
The doc includes the full verification matrix, a regression guard for future PM/hunter sweeps (test BOTH root and bin/ binaries, cross-check version string vs git describe), and a summary table.
# Evidence - Problem class: go-cli-status-exit-code-stale-binary - Model: openrouter/deepseek/deepseek-v4-flash-0731 - Solved: 2026-08-22T11:16:23.491Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Board row claims 'rabbit-hole status exits 0 when daemon unreachable' (PM sweep, 2026-08-22). Triage: canonical ./bin/rabbit-hole ALREADY exits 1 \u2014 cmd/rabbit-hole/status.go RunE returns the daemonClient.stats error (line 37) and main.go calls os.Exit(1) when rootCmd.Execute() returns an error (added in a6dfa23). The exit-0 bug reproduces ONLY on the stale root artifact ~/rabbit-hole/rabbit-hole (built Aug 10, v1.0.0-dev, predates the os.Exit(1) fix). Same stale binary also lacked the classify-server subcommand and pre-GAP-008 compact help (separate board row GAP-009). Fix: remove the untracked root binary (gitignored via /rabbit-hole); bin/rabbit-hole is the canonical make-build artifact. Triage lesson: when a PM/hunter sweep row describes CLI behavior that code inspection says is already correct, test BOTH the repo-root binary and bin/ before dispatching a worker \u2014 the root artifact is an undocumented stale trap.", "environment": "rabbit-hole Go 1.26 Cobra CLI (gitlab.readydedis.com/rabbit-hole/rabbit-hole), GitLab CI with 0 runners, PM gap-pusher sweep rows", "language": "go", "model": "openrouter/deepseek/deepseek-v4-flash-0731", "problem_class": "go-cli-status-exit-code-stale-binary", "provider": "openrouter", "solved_at": "2026-08-22T11:16:23.491Z", "version": "v1.0.0-429-g35e2a0e"}Deliverable: ~/solution.md — self-contained solution writeup.
The exit-0 report is a stale-binary trap, not a code bug:
- Canonical ./bin/rabbit-hole (v1.0.0-429-g35e2a0e) already exits 1: status.go's RunE returns the daemon error and main.go (commit a6dfa23) calls os.Exit(1) when Execute() errors.
- The row reproduced against the untracked root artifact ~/rabbit-hole/rabbit-hole (Aug 10, v1.0.0-dev), built from a commit predating a6dfa23, gitignored via /rabbit-hole so nothing ever rebuilt it. It also independently explains the missing classify-server subcommand and pre-GAP-008 help (row GAP-009).
A faithful minimal mirror reproduced both behaviors with identical error text:
- pre-a6dfa23 (_ = rootCmd.Execute()): prints Error: cannot reach Rabbit-Hole daemon at http://<ip-address>:9734 ... connection refused → exit 0
- post-a6dfa23 (os.Exit(1) on error): same message → exit 1
This confirms the error message and exit code are decoupled — Cobra prints the error, only main.go's os.Exit(1) sets the status.
cd ~/rabbit-hole
git ls-files --error-unmatch rabbit-hole 2>/dev/null || echo "untracked: safe to delete"
rm -f rabbit-hole
make build # regenerates canonical bin/rabbit-hole from HEAD
The doc includes the full verification matrix, a regression guard for future PM/hunter sweeps (test BOTH root and bin/ binaries, cross-check version string vs git describe), and a summary table.
# Evidence - Problem class: go-cli-status-exit-code-stale-binary - Model: openrouter/deepseek/deepseek-v4-flash-0731 - Solved: 2026-08-22T11:16:23.491Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Board row claims 'rabbit-hole status exits 0 when daemon unreachable' (PM sweep, 2026-08-22). Triage: canonical ./bin/rabbit-hole ALREADY exits 1 \u2014 cmd/rabbit-hole/status.go RunE returns the daemonClient.stats error (line 37) and main.go calls os.Exit(1) when rootCmd.Execute() returns an error (added in a6dfa23). The exit-0 bug reproduces ONLY on the stale root artifact ~/rabbit-hole/rabbit-hole (built Aug 10, v1.0.0-dev, predates the os.Exit(1) fix). Same stale binary also lacked the classify-server subcommand and pre-GAP-008 compact help (separate board row GAP-009). Fix: remove the untracked root binary (gitignored via /rabbit-hole); bin/rabbit-hole is the canonical make-build artifact. Triage lesson: when a PM/hunter sweep row describes CLI behavior that code inspection says is already correct, test BOTH the repo-root binary and bin/ before dispatching a worker \u2014 the root artifact is an undocumented stale trap.", "environment": "rabbit-hole Go 1.26 Cobra CLI (gitlab.readydedis.com/rabbit-hole/rabbit-hole), GitLab CI with 0 runners, PM gap-pusher sweep rows", "language": "go", "model": "openrouter/deepseek/deepseek-v4-flash-0731", "problem_class": "go-cli-status-exit-code-stale-binary", "provider": "openrouter", "solved_at": "2026-08-22T11:16:23.491Z", "version": "v1.0.0-429-g35e2a0e"}