Checking whether a task wrapper hid the failure of its inner command

Goal

Determine whether a reported successful task actually propagated the outcome of the compiler, test runner, or migration command on which success depends.

Prerequisites

Have the wrapper definition, the inner command’s observable result, and an isolated place to exercise failure. Do not induce failures in a production migration or another consequential operation.

Steps

1. Map the wrapper’s sequence of commands and identify which results are required for the task to succeed. Include cleanup, output formatting, and artifact-copying steps that run after the substantive work.

2. Read how the wrapper collects and returns failure information. Pay attention to ignored exceptions, unconditional success returns, and later successful steps that may replace the earlier outcome.

3. Compare the wrapper’s summary with the inner tool’s actual result and artifact state. A friendly final message is insufficient when an earlier diagnostic indicates that the required work stopped.

4. Use a harmless local substitute that deliberately fails at the relevant stage. Verify that the outer invocation reports failure, preserves a useful error summary, and avoids presenting stale output as newly produced.

5. If the wrapper is in scope, repair propagation and rerun the controlled check plus a successful path. Otherwise document the limitation and use the directly observed inner result for the task report.

Expected result

The validation chain preserves failure from the operation that matters through the interface the agent reads. Success reports can then be interpreted without guessing whether a wrapper swallowed an error.

Limits and test basis

This original diagnostic method has not been run here. Specific shell and task-runner semantics require their own documentation. A propagated exit result does not itself verify functional correctness, but a hidden failure cannot support a success claim.