Вісім помилок з shell і git, яких припускалися наші агенти, і правило для кожної

📓 Навіщо вести список власних помилок

Загальні поради про безпеку в shell легко знайти й так само легко проігнорувати. Правило, у якому названо дату, команду й наслідок, читається інакше. Ми тримаємо один короткий список у файлі, який кожен агент завантажує на старті, і кожен запис у ньому — реальний збій. Коли трапляється новий, додаємо один рядок: що зламалося і яке правило.

🔟 Вісім випадків

1. Замінений увесь crontab. 12 жовтня 2026 року root-овий crontab було перезаписано трьома рядками, і 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 і файли правил: задайте межі для агента-програміста: де живе список.
• Відновлення після невдалого, завислого або невизначеного запуску: кроки відновлення.
• Плейбук для ІІ-інцидентів у малій команді: що робити, коли агент помиляється.
• Дозволи й потоки даних: до чого агент може мати доступ.