CLI commands return exit 0 after printing Error to stderr

[arcavenai]

Summary

Several marvel CLI commands print Error: ... to stderr but return exit code 0. Shell scripts and CI pipelines that key off exit codes will miss the failure.

Observed

marvel work with preflight failure

$ marvel --cluster desk work /tmp/preflight.yaml; echo "exit: $?"
Error: runtime pre-flight failed on 1 role(s):
  team[0=broken].role[0=ghost]: command "/nonexistent/binary": not found: stat /nonexistent/binary: no such file or directory
Usage:
  marvel work <manifest.toml> [flags]
...
exit: 0

marvel events against a daemon that doesn't expose the RPC

A pre-PR #25 daemon responds with Error: unknown method: events — but:

$ marvel events -n 5; echo "exit: $?"
Error: unknown method: events
Usage: ...
exit: 0

Expected

Exit code non-zero (idiomatically 1) when the command prints Error:. The Usage trailer after Error: suggests cobra's default error handling is routing through SilenceUsage: false but swallowing the return.

Likely cause

cobra's RunE returning an error should propagate to exit 1 via cmd.Execute() in cmd/marvel/main.go. Either:

1. main.go isn't checking Execute()'s return
2. A command is printing the error itself and returning nil
3. SilenceErrors/SilenceUsage interaction is masking it

Test

After fix: marvel work /tmp/nonexistent-manifest.yaml; echo $? should print a non-zero code.

Environment

• marvel 0.1.0-alpha.20260419.014522.b8f1f4b (commit b8f1f4b)
• Linux aarch64, both mrvl:// and Unix socket paths reproduce

[arcavenai]

Partial verification on alpha-20260419.034700.20d90ac:

The marvel work preflight-error case (one of the two repros I filed this under) now returns exit 1 correctly:

$ marvel work /tmp/test40-bad.yaml
Error: runtime pre-flight failed on 1 role(s):
  ...
$ echo $?
1

The other repro — marvel events against a daemon that doesn't know the RPC, getting Error: unknown method: events with exit 0 — I can't retest now because the current daemon has the events RPC. If nothing changed in the RPC error-handling path, that case may still return 0.

If cmd.Execute() now checks its return in main.go (what I'd guess was the fix), the RPC-error case should be fixed incidentally. Worth a quick grep to confirm before closing.

Leaving open pending that confirmation.