Case note 1: parsing a report must not erase its exit code

[okgrit]

A check can emit valid JSON and still fail. If a consumer keeps only the formatter's result, that failure can disappear.

This is a maintainer-run synthetic Linux/Bash reproduction, pinned to ed83afab. A command was captured once with a selected file; then that file was changed. The recorded command succeeded, but its selected evidence was now stale.

Observed result	Selected bytes unchanged	Selected bytes changed
Historical child exit	0	0
Current recheck state	matches	different
Freshness	matches	changed
Reporter exit	0	1
JSON formatter exit	0	0
Bash pipeline without pipefail	0	0
Bash pipeline with pipefail	0	1

The receipt and selected file stayed unchanged during each reporting comparison. The command's execution marker remained at one; reporting did not rerun it.

The masking example

From the pinned toolkit checkout, let $receipt be the local receipt path and $project its project root. The usage guide explains capture and path selection. These examples assume valid JSON output from that reporter.

This is the unsafe comparison:

set +o pipefail
python3 tools/report_receipt.py "$receipt" --project "$project" --format json |
    python3 -m json.tool

For the changed-input case above, formatting succeeded and the pipeline returned 0, although the reporter returned 1.

Keep the failure visible

set -o pipefail
python3 tools/report_receipt.py "$receipt" --project "$project" --format json |
    python3 -m json.tool

The same changed-input summary now leaves the pipeline at 1. The unchanged-input control still returns 0. The snippet ends with the pipeline; in a longer script, preserve its result before a later command can replace it.

This follows Bash's pipeline status rules. pipefail selects the rightmost nonzero status, so it does not guarantee the reporter's exact code if the parser also fails. Our parser returned zero in these comparisons. We did not run a hosted CI workflow or test a particular runner's defaults.

historical_child_exit: 0 also remains a historical value, not a current success gate. A receipt is editable, scoped and non-atomic; matching observations cannot certify task completion.

Credit to sacravenger / NaN Mesh's scoped synthetic consumer report for highlighting the masking control. This note is a separate Bash reproduction; a small Python-wrapper PR is invited in that issue. No NaN Mesh service integration or production incident is claimed.

Hit this in another shell or consumer? A minimal synthetic example, its revision and the observed exits would be useful. Other contribution opportunities are open too. Please keep raw receipts and private logs local.

Prepared with Codex; the table reports the reproduction above, not an agent-performance benchmark.