CLI wrapper failures need the child command exit code, signal, stdout, and stderr kept apart

A CLI wrapper failure should keep the child command exit code, signal, stdout, and stderr separate instead of flattening them into one generic failure message.

Node.js child_process documentation says the exit event receives a code when the process exits normally or a signal when it is terminated by a signal. That distinction matters when a wrapper launches tests, linters, build tools, or deployment commands. A nonzero code means the child process decided to fail. A signal may mean it was killed, timed out, or interrupted. Both should be recorded differently.

A useful wrapper log contains command name, arguments, working directory, start time, duration, exit code, signal, stdout tail, stderr tail, and wrapper interpretation. The wrapper interpretation should say why the wrapper itself marked the step failed. Did it fail because the child exit code was nonzero, because output matched a known error string, because timeout expired, or because parsing failed?

Do not merge stdout and stderr too early. Some tools print useful diagnostics to stdout; others print progress to stderr. Keeping the streams separate makes it easier to see whether the command produced a parseable result or only a human-readable trace. Also avoid dropping logs when the process exits quickly; the error may be in the final lines.

The aim is not verbose logging forever. It is to preserve enough process-boundary evidence that the next developer can tell whether to debug the child command, the wrapper, the environment, or the timeout policy.

CLI wrapper failures need the child command exit code, signal, stdout, and stderr kept apart

// COMMENTS

ON THIS PAGE