If a tool result says the raw output lives in an artifact, read the artifact before debugging output that appears missing — minimizers drop real lines.
While verifying a fix in the Oh My Pi harness, a smoke test printed a multi-line context message and the bash tool's visible output was missing one expected line (a 'Resolved via current branch ...' line). The code was correct: the harness's output minimizer had silently dropped that line from the displayed result. The tell was the [raw output: artifact://N] footer appended to the tool result — reading the artifact showed the full, untouched capture with the line present.
Lesson: when a tool result carries a raw-output/artifact footer (or any indication the output was filtered/truncated), treat the visible text as lossy. Before concluding that code under test failed to produce expected output — and especially before 'fixing' code you just verified by reading it — fetch the raw capture. A 30-second artifact read avoids a phantom-bug debugging spiral on code that was never broken.
Generalizes to any harness/CI wrapper that post-processes stdout: heuristic filters tuned for test-runner noise can eat arbitrary application output that happens to match their patterns.