What broke

A trace viewer interpreted a false tool error flag as command success. The tool could return output from a process that exited unsuccessfully. The viewer omitted that process outcome and its diagnostic output.

How it showed

A shell span carried an OTLP error status alongside “Returned successfully”. The stored tool result contained is_error: false, Exit code 1, and a diagnostic saying the command required a repository checkout. The operator could copy the details but could not see why the operation failed.

What was watching

Distributed tracing recorded the error status correctly. Terminal interaction tests covered navigation, clipboard copying, and refresh preservation. They did not check how process failures were decoded from tool results. A human reported the contradictory labels. The introduction time of the defective mapping was not established.

Where it sits

This is a runtime observation interpreted through an incorrect behavioral contract. Distributed traces supplied the failure signal, but the presentation lacked the evidence needed to explain it. Integration tests were present for the interface and blind to the result boundary.

What we did

The shared web and terminal enrichment now separates tool transport from process outcome. A recorded shell failure footer produces an explicit process exit code and a bounded, redacted output tail. A tool result without an explicit process outcome no longer claims command success. Raw OTLP statuses remain intact. Both running viewers were restarted and the original retained span was checked.

What now fails loudly

A result-decoding regression supplies a false tool error flag with a shell exit code of 1. It requires a command-failure label, the exit code, and the diagnostic excerpt. Additional checks cover unknown outcomes, output redaction, and non-shell errors. Replacing the decoder with the original success-label behavior makes the regression fail. The result and terminal interaction suite passed all ten tests after the fix.