Аудит на основе git — каждая передача это коммит

Как это работает

Когда Forge выполняет ваш процесс, он коммитит вывод каждой роли в ветку, привязанную к процессу:

1
2
3
4
5
6
7
8

forge/workflow/{workflowId}/run/{runId}
├── .workflow/spec.json          ← спецификация процесса (самоописательная)
├── .workflow/brief.md           ← исходный бриф на обычном языке
├── .agents/alex/handoff.json   ← структурированный вывод Алекса
├── .agents/alex/handoff.md     ← свободный вывод Алекса
├── .agents/sam/handoff.json   ← сводка ресёрча Сэма
├── .agents/sam/handoff.md
└── .agents/<остальные роли>/...

В сообщении каждого коммита есть:

• идентификатор процесса и идентификатор прогона;
• идентификатор роли;
• фаза (первичный прогон или повтор после доработки);
• ключ идемпотентности (чтобы повторы не тратили вызовы модели дважды).

Роль также записывается строкой Co-authored-by — просматривая коммиты на GitHub, вы видите, что каждая роль «авторствует» собственную передачу. История читается как git-лог настоящей команды.

Два режима хранения

Подключённый репозиторий

Вы наводите процесс на один из своих репозиториев. Forge коммитит в ветку этого репозитория, привязанную к процессу. Ветку можно в любой момент git fetch и изучить всю историю процесса. Нужен PR по завершении? Forge откроет его в вашу ветку по умолчанию. Нужно влить передачи в основной код? Дальше это просто git.

Общий репозиторий

Если репозиторий не подключён, Forge создаёт скрытый репозиторий на организацию (forge-shared-workflows-{orgId}). Все ваши прогоны коммитятся туда. Вы просматриваете их через панель Forge; сам git-репозиторий невидим вашим пользователям, но это по-прежнему настоящий git-репозиторий — аудиторам при необходимости можно выдать доступ на чтение.

В обоих случаях системой учёта является git. Состояние Forge в нашей базе — лишь проекция того, что лежит в git.

Почему git, а не собственное хранилище

Три причины:

1. Долговечность. Git непробиваем. Если наш сервис завтра исчезнет, история ваших процессов останется на диске в репозитории.
2. Сравнимость. Когда управляющий агент перезапускает роль с инструкциями по доработке, новая передача — коммит. Старая — тоже коммит. git diff показывает ровно то, что изменилось. Особый инструмент сравнения не нужен.
3. Одна ментальная модель. Инженеры уже знают git. Аудиторы его узнают. Ни новой системы для изучения, ни проприетарной привязки.

Сценарии использования

• Ревью оператором. Когда процесс эскалирует к вам, вы видите все предыдущие попытки в истории ветки. Можно сравнить попытки, выбрать лучшую или закоммитить исправленную передачу самому — процесс продолжится со следующего перехода.
• Комплаенс-аудит. SOC 2, ISO 27001, HIPAA — аудитор получает доступ к git log. Вход и выход каждой роли, каждый вердикт управляющего агента, каждый повтор — всё в истории коммитов. Особого аудиторского инструментария не требуется.
• История версий. Спустя полгода после прогона можно поднять точную спецификацию, бриф, передачи и вердикты. Ветка остаётся, пока вы её не удалите.
• Форк процесса. Возьмите ветку успешного прогона как отправную точку для похожего процесса. Спецификация и бриф уже там.

Безопасность

• Подключённый репозиторий: Forge использует доступы GitHub App, которые вы выдали при создании процесса. Коммиты идут под личностью приложения. Отозвали приложение — Forge больше не может пушить (а идущие процессы аккуратно эскалируют).
• Общий репозиторий: изоляция по организациям. Операторы организации A никогда не видят коммиты организации B. Владелец репозитория — та организация GitHub, которую вы зарегистрировали в Forge.
• Удаление ветки: удаление убирает SHA из активного дерева git, но они остаются в reflog в течение стандартного окна хранения GitHub (обычно 90 дней). Для комплаенс-сценариев, требующих более строгих гарантий, включите архивирование тегом по завершении процесса.