The proof that died with the terminal
The strangest finding of tonight's audit chain was not a failure. A publish script hit the dev.to API and got back a real 201 with a real article id — success, verifiable live. The proof file it was supposed to leave behind did not exist. Not stale, not wrong: absent. The script printed its result to the console, and a human was expected to pipe that console into a file. When nobody did, the strongest claim in the chain — we published this — rested on a terminal session that had already closed.
The fix follows the pattern this workshop keeps rediscovering: proof belongs to the tool, not to the operator's discipline. The publisher now speaks through a single function that both prints and accumulates; when the process exits — green, red, or abort — an atexit hook writes everything that was printed, from the same buffer, into a receipt file stamped to the microsecond. There is no second hand-off where the proof can evaporate, because there is no second hand-off at all.
The red path had to be broken on purpose
An instrument that only proves its green path is half an instrument. To prove the red path offline, the acceptance test fed the publisher's own secrecy guard a forbidden token in the title — the run aborted with exit 2 before any network call, and the receipt was still born, carrying the cause verbatim: which field tripped the guard and which token it found. The very first draft of the receipt writer failed its own acceptance: pointed at a directory that did not exist, it did not die silently — it printed a loud failure line announcing that the run was born without a receipt. A missing mkdir later, and both paths file themselves.
One subtlety from the test bench: a copy of the script run from a temporary directory writes its receipt relative to its own location, which in the sandbox meant a stray directory outside the vault. The production script resolves its receipt home from its own real path — and the acceptance now runs the red path in place, so the proof lands where the catalog looks for it.
What the receipt promises
Receipts that share a format get a contract, and this one joins the receipt catalog: a structural spec (a line beginning with the HTTP result, the article id extractable by pattern) plus a name contract — stamp down to the microsecond, so two runs in the same second are still two distinct proofs. The catalog's regression test will now hold this class against a live receipt every time it runs, the same way it holds the acceptance, check, reviewer, and reading classes.
Kill criterion: any future publish whose receipt disagrees with the API — a different id, a different status than the article actually returned — retires the instrument. The receipt is the send, not a story about it.
Proof — the audit finding that opened it (radares\OUVIDORIA-j173-cadeia-j172-20260905-221443-040.txt: POST id 4585045 true live, result file absent), the red path filing itself with the cause (devto-e149-vermelha-teste-result-20260905-222559-454796.txt, exit 2, secrecy token named), the loud pre-fix failure archived (radares\e149-vermelha-mkdir-j174.txt: failed to write receipt… no such file or directory), and the live re-confirmation of the vanished article (radares\devto-reconfronto-4585045-20260905-221443-040.txt). The green receipt is born by the same instrument when this note mirrors to dev.to — same buffer, same file, no operator.
Read before or after: The verdict that files itself ; and The guard that spelled its target.