# Бот может сломать репозиторий. Просите проверяемую правку

Дата: 2026-09-07

Безопасный workflow для кода с Grok Bot: ветка, маленькая задача, тесты, diff и PR - без force push в main и без секретов в промпте.

Grok Bot полезен в коде, когда вы просите проверяемый diff, а не «почини всё сам». Бот может исследовать репозиторий, написать небольшой патч и подготовить PR. Он не должен бесконтрольно менять `main`, удалять историю или видеть секреты.

Это работа агента на компьютере, не чат с подсказками: [чем Grok Bot отличается от обычного Grok](/articles/chem-grok-bot-otlichaetsya-ot-obychnogo-grok). Старт: [первый час](/articles/pervyy-chas-s-grok-bot), официально [x.ai/bot](https://x.ai/bot) и [Grok Bot 101](https://x.ai/bot/guides/grok-bot-101). Роль и стопы - [создание своего бота](/articles/kak-sozdat-svoego-grok-bot), [мандат как ТЗ](/articles/mandat-bota-kak-TZ).
## Правило «сначала прочитай»
Перед изменением бот:
  1. Строит карту проекта (README, структура, инструкции).
  2. Находит существующие проверки (тесты, линтер, CI-подсказки).
  3. Формулирует план на маленькую задачу.
  4. Ждёт ок, если шаг рискованный.


Не давайте широкое «исправь техдолг». Одна issue - один ожидаемый результат - один набор файлов. Иначе получите огромный diff без review и сгоревший лимит.
## Безопасный цикл изменения
## Создать ветку
Отдельная ветка с понятным именем от актуального `main`/`develop`. Работа в `main` напрямую - запрет для стартового контура.
## Зафиксировать baseline
Статус репозитория, какие тесты зелёные сейчас, пустой или известный diff. Без baseline непонятно, что сломал патч.
## Маленький патч + diff
Внести изменение и показать diff. Человек смотрит, что реально тронуто.
## Тесты и линтер
Запустить релевантные проверки. Если тесты красные - остановить расширение задачи, показать лог, локализовать причину. Не «чинить» падающий тест вырезанием assert.
## PR
Описание: цель, файлы, тесты, риски, откат. Review и merge - человек. Логика «не в прод без стопов» та же, что в [как не пускать бота в прод](/articles/kak-ne-pustat-bota-v-prod).
Чеклист перед PR:
  * Ветка не `main`
  * Diff просмотрен
  * Тесты/линтер по зоне изменения
  * Нет секретов в коммите и в промпте
  * Есть способ отката
  * Нет force-push в защищённые ветки


## Красные линии репозитория
Запретите явно:
  * force push в `main` (и в другие защищённые ветки);
  * удаление веток «за компанию»;
  * переписывание истории без отдельного решения;
  * секреты, токены, приватные ключи в промпте или в файлах;
  * миграции БД, массовые зависимости, инфраструктуру без approval владельца.


Approval на рискованные шаги: [approval и 2FA](/articles/approval-i-2fa-bez-isteriki). Shared-машина и чужие сессии - риск: [shared computer](/articles/shared-computer-udobstvo-i-risk).
## PR - артефакт, а не печать доверия
В описании PR должны быть:
  * цель изменения;
  * список файлов / зона влияния;
  * что прогнали из тестов;
  * известные риски;
  * как откатить.


Человек проверяет diff, тесты и поведение на границах. Бот может ответить на комментарии review, но не закрывает замечания молчаливым «fixed» без diff. Merge - только после вашего решения.
## Что поручать первым
Хороший старт:
  * документация и README по факту кода;
  * тест-кейсы на уже понятное поведение;
  * поиск дублирования;
  * небольшие локальные фиксы;
  * разбор логов **без** секретов.


Плохой старт: «перепиши архитектуру», «задеплой», «почини прод», «положи ключ в env из чата». Примеры контуров - в [кейсах](/articles/keysy-grok-bot). Безопасный день-1 периметр - [безопасный старт](/articles/chto-mozhno-botu-v-den-1).
## Цена ошибки и Ultra
Ведите журнал: задача → ветка → diff → тесты → review → откат (если был). Не обещайте процент ускорения без своих данных.
Если команде не хватает рук на поток мелких PR, Ultra считайте как [ФОТ многорукого](/articles/heavy-kak-zarplata-mnogorukogo), не сравнивайте с подписками чатов: [цена Ultra - не подписка](/articles/cena-heavy-ne-podpiska). Сначала дисциплина ветки и review, потом масштаб.
Широкие «почини всё» часто жгут лимит: [сжёг лимиты за день](/articles/szhyog-limity-za-den).
## Пример мандата на маленький патч
> Роль: разработчик патча по issue #123. Цель: исправить X в файлах A,B; тесты зоны зелёные; PR-описание готово. Шаги: ветка fix/123-short → baseline тестов → патч → diff → тесты → описание PR. Нельзя: push в main, force-push, секреты в промпт/коммит, миграции, деплой. Approval: перед push ветки на remote (если включено), перед любым merge, перед изменением CI. Стоп: красные тесты вне зоны, нужны секреты, scope расползся больше чем на 2 файла сверх плана.
Так бот не превращается в «агента с правами админа репозитория». Если scope расползся - остановите и заведите вторую задачу, не дописывайте «заодно» в тот же PR.
## Типичные фейлы первой недели с кодом
Фейл| Почему больно| Что сделать  
---|---|---  
Работа сразу в main| Нет review/отката| Только ветка  
«Почини все варнинги»| Огромный diff| Одна issue  
Секрет в промпте| Утечка| Секрет-хранилище  
Правка теста вместо бага| Ложная зелень| Чинить код  
Merge без человека| Риск прод| Approval  
Честные фейлы общего старта - в [честных фейлах первой недели](/articles/chestnye-feyly-pervoy-nedeli). Для кода добавьте Git-дисциплину из этого материала.
## Частые вопросы
**Можно ли пушить в main?** Нет для стартового контура. Ветка и PR сохраняют review и откат.
**Нужен ли весь репозиторий?** Только необходимая область. Начните с read-only и конкретной задачи.
**Как защитить секреты?** Не вставлять в промпт, не коммитить; использовать секрет-хранилище команды.
**Тесты не проходят - что делать?** Остановить расширение, показать лог, локализовать причину. Не маскировать ошибку правкой теста «в зелень».
**Может ли бот сам сделать PR?** Подготовить ветку и описание - да. Review, merge и рискованные изменения - человек.
**С чего начать?** Откройте [/start](/start) и проведите один маленький патч с diff и тестом.
## Что сделать сейчас
  1. Выберите одну issue и запретите работу в `main`.
  2. Прогоните цикл: ветка → baseline → патч → тесты → PR-описание.
  3. Сверьте красный список с [не пускать в прод](/articles/kak-ne-pustat-bota-v-prod).
  4. Официально: [x.ai/bot](https://x.ai/bot), [Grok Bot 101](https://x.ai/bot/guides/grok-bot-101).