Агент-инженер по репозиторию · Модуль 6 · Урок 6.4
Governance: полный аудит-лог и версионирование промптов
Зачем (какую проблему чиним)
Агент автономно пишет код и открывает MR в проде. Когда (не если) что-то пойдёт не так, нужно уметь ответить: кто, что, когда и на основании чего сделал. Это governance: полный аудит каждого действия записи/коммита/MR и версионирование промптов, чтобы воспроизвести поведение и откатить плохую версию.
Решение и альтернативы
Решение: неизменяемый (append-only) аудит-лог: на каждое действие записи — запись с task_id, issue, веткой, sha чекпойнтов, ключом allowlist-команды, вердиктом verify, URL MR, версией промпта и моделью. Промпты версионируются (хэш/семвер) и хранятся в репозитории (control plane); в аудит пишется, какая версия промпта приняла решение. Секреты в аудит не попадают.
Альтернативы: обычные логи — не предназначены для аудита (ротация, изменяемость, нет гарантий); промпт-строки в коде без версий — невозможно связать инцидент с конкретным поведением и откатить. Append-only аудит + версионирование — требование к ответственному автономному агенту.
DIFF
Вводим append-only аудит-лог действий записи/коммитов/MR и версионирование промптов; связываем записи по task_id.
⚠ Безопасность
Аудит-лог — это сквозная гарантия обратной прослеживаемости всего, что курс выстраивал: каждая запись, коммит и MR оставляют неизменяемый след. Это и сдерживающий фактор (как в кейсе Replit, где искажение отчётности усугубило инцидент), и инструмент расследования. Версионирование промптов позволяет мгновенно откатить вредную версию для всех будущих задач.
Проверка
После задачи аудит-лог содержит полную цепочку: триггер → ветка → чекпойнты (sha) → verify → MR (URL) → версия промпта и модель. Записи неизменяемы (append-only), секретов нет, всё связано по task_id.
Глубже
Governance, версионирование промптов, A/B, аудит — курс «Продакшн-разработка», Модуль 6 (гл. 14); безопасность и least privilege — Модуль 5 (гл. 11).
+package main
+
+import "time"
+
+// AuditEntry — неизменяемая запись об одном действии. Секреты НЕ включаются.
+type AuditEntry struct {
+ At time.Time
+ TaskID string
+ Action string // write|checkpoint|mr_create|rollback
+ Branch string
+ CommitSHA string
+ VerifyGreen bool
+ MRURL string
+ PromptVersion string // какая версия промпта приняла решение
+ Model string
+}
+
+// Audit — append-only журнал (файл/БД). Только добавление, без перезаписи.
+type Audit interface{ Append(e AuditEntry) error }Anti-patterns
| Грабля | Почему плохо | Как правильно |
|---|---|---|
| Полагаться на обычные логи как на аудит | Ротация, изменяемость, отсутствие гарантий — для расследования не годится | Append-only аудит-лог действий записи/коммитов/MR, связанный по task_id |
| Промпты строками в коде без версий | Нельзя связать инцидент с поведением и откатить плохую версию | Версионирование промптов (хэш/семвер) в репозитории; версия — в аудите |
| Писать секреты/токены в аудит | Аудит превращается в источник утечки | Только факты действий; секреты исключены |
Практическое задание (RA-v5)
- Реализовать append-only аудит-лог: запись на каждое действие записи/коммита/MR со связкой по
task_id. - Версионировать промпты (хэш/семвер) и писать версию решения в аудит; исключить секреты.
- Закоммитить:
git commit -m "v5: full audit log + prompt versioning".
Проверка знаний
Почему для автономного агента, пишущего код в проде, нужен append-only аудит-лог, а не обычные логи?
Верный ответ: B
B. Ответственная автономия требует достоверного следа каждого действия записи/коммита/MR, который нельзя задним числом изменить. Это нужно и для расследования инцидентов, и как сдерживающий фактор. Обычные логи этих гарантий не дают.
Зачем версионировать промпты и записывать версию в аудит?
Верный ответ: B
B. Промпт определяет поведение не меньше кода. Версионирование и запись версии в аудит позволяют связать инцидент с конкретным поведением, воспроизвести его и откатить плохую версию централизованно (control plane).