Восемь ошибок наших агентов в shell и git и правило на каждую

📓 Зачем вести список собственных ошибок

Общих советов по безопасности shell много, и их легко игнорировать. Правило с датой, командой и последствием читается иначе. У нас один короткий список в файле, который каждый агент загружает при старте, и каждая запись — реальный сбой. Случается новый — добавляется одна строка: что сломалось и правило.

🔟 Восемь случаев

1. Целиком заменили crontab. 12 октября 2026 crontab пользователя root перезаписали тремя строками, и пропали 59 заданий, включая резервные копии и дампы баз. Заметили через сутки. Правило: не переписывать crontab. Новое задание — отдельный файл в каталоге cron, плюс сторож, который сверяет список заданий.
2. ssh внутри цикла чтения. В while read ... < file команда ssh читает остаток файла из стандартного ввода. Из пяти писателей запустился один. Правило: сначала прочитать список в массив или вызывать ssh -n.
3. Убить самого себя по шаблону. pkill -f и pgrep -f совпадают с командной строкой вашей же оболочки, если шаблон в ней есть. Агент убил собственную оболочку, а наблюдатель ждал сам себя. Правило: убивать по номеру процесса и проверять, что шаблон не встречается в запускающей строке.
4. Пустой список — это всё. git reset HEAD --pathspec-from-file= с пустым файлом сбросил весь общий индекс. Правило: перед любой командой, берущей список из файла или xargs, проверять, что список не пуст.
5. Зарезервированные имена shell. Присваивание GROUPS, RANDOM, SECONDS, UID или HOSTNAME молча игнорируется. Правило: давать своим переменным префикс.
6. && и set -e. cmd && echo ok не останавливает скрипт при сбое cmd под set -e, а в нашем инструменте агента set -e не работал вообще: команда обёрнута. Коммит ушёл при десяти красных тестах. Правило: проверять код возврата явно: if ! cmd; then exit 1; fi.
7. Код возврата забирает конвейер. pytest | tail -1 && git commit коммитит на красном, потому что код возврата конвейера принадлежит его последней команде. Правило: запускать тесты без конвейера или включать pipefail.
8. Команда, которая не выполнилась. chmod +x внутри заблокированной команды не сработал, и никто не проверил. Правило: проверять режим файла перед коммитом.

🛠️ Практика: заведите свой список

1. Откройте последние пять инцидентов, вызванных агентом или скриптом. По одной строке: дата, команда, последствие.
2. Для каждого напишите одно правило, которое можно проверить скриптом. Если проверить нельзя, переформулируйте.
3. Положите список в файл, который агенты читают первым, и держите его короче тридцати строк.
4. Добавьте проверку для тех правил, что поддаются тесту: например, скрипт, который отказывает в коммите при пустом списке путей или неверном режиме файла.
5. После каждого нового инцидента добавляйте строку в тот же день.
6. Раз в квартал удаляйте правила, которые уже обеспечивает инструмент.

✅ Проверьте себя

• Выберите любое правило. Вы можете назвать инцидент, за которым оно стоит.
• Запустите цикл с ssh внутри на двух хостах. Оба хоста достигнуты.
• Заставьте тест упасть под конвейером и убедитесь, что коммит отклонён.
• Агент, который никогда не видел вашей системы, читает список и избегает минимум трёх из восьми на первой же задаче.

🚧 Когда это не работает

• Список, который никто не загружает. Если файла нет в стартовом контексте агента, правил как будто нет.
• Правила без триггера. «Осторожнее с cron» — не правило. «Добавляй задания файлами, crontab не правь» — правило.
• Слишком много правил. После тридцати строк важное теряется. Убирайте то, что уже обеспечивает инструмент.
• Разные оболочки. Часть случаев в других оболочках ведёт себя иначе. Указывайте, о какой оболочке правило.
• Правила вместо прав. Агент, которому нельзя трогать прод, не должен иметь прод-доступа, что бы ни говорил список.

📊 Доказательства

➡️ Дальше

Настройте восстановление по материалу Восстановление после сбойного, зависшего или неопределённого запуска и прочитайте, как писать инструкции для агентов, в AGENTS.md и файлы правил.

Источники

• AGENTS.md и файлы правил: где живёт список.
• Восстановление после сбойного, зависшего или неопределённого запуска: шаги восстановления.
• План реагирования для небольшой команды: что делать, когда агент ошибся.
• Права и потоки данных: что агент может затрагивать.