Платформа RU

Агент-инженер по репозиторию · Модуль 5 · Урок 5.1

Верификационный гейт: MR только на зелёном

Зачем (какую проблему чиним)

Агент версии v3 умеет писать и чинить, но «считает себя готовым» по собственному суждению. Доверять самооценке модели нельзя: она может объявить задачу решённой при красных тестах. Перед публикацией нужен объективный гейт — машинная проверка, а не мнение модели.

Решение и альтернативы

Решение: функция verify прогоняет весь allowlist проверок (build, tests, lint) в worktree и возвращает структурный вердикт. MR открывается, только если вердикт зелёный по всем пунктам. Красный вердикт = нет MR; агент либо чинит (петля v3), либо честно сообщает о провале. Гейт — детерминированный код, не суждение модели.

Альтернативы: спросить модель «готово ли?» — субъективно и обманчиво; гейт только на тестах без билда/линта — пропускает несобираемый или грязный код. Полный гейт по allowlist — объективная граница между «агент поработал» и «можно показывать человеку».

DIFF

Добавляем verify (структурный вердикт по allowlist) как обязательное предусловие любой публикации.

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

Верификационный гейт — машинный контроль качества перед выходом наружу. Он закодирован и не обходится моделью: даже если агент «уверен», красный verify физически блокирует создание MR (урок 5.2). Это прямое следствие honesty-инварианта версии v3 и предтеча task-completion eval (урок 5.4).

Проверка

На задаче с намеренно непроходящим тестом verify возвращает красный вердикт с указанием упавшего пункта; попытка открыть MR на таком вердикте отклоняется. На зелёном — гейт пропускает.

Глубже

Guardrails, верификация, human-in-the-loop — курс «Продакшн-разработка», Модуль 5 (гл. 10); eval-датасеты и регрессии — там же (гл. 9).

verify.go: структурный вердикт по allowlist (новый файл, фрагмент)
+package main
+
+import "context"
+
+// Verdict — машинный вердикт верификации. Green=true только если ВСЕ проверки прошли.
+type Verdict struct {
+	Green   bool
+	Results map[string]string // check -> краткий итог/вывод
+}
+
+// verify прогоняет весь allowlist проверок в worktree. Детерминированный гейт,
+// не суждение модели: его результат решает, можно ли открывать MR.
+func verify(ctx context.Context, ws *Workspace) Verdict {
+	v := Verdict{Green: true, Results: map[string]string{}}
+	for _, key := range []string{"build", "tests", "lint"} {
+		out, _ := runCheck(ctx, ws.Dir, key)
+		ok := checkPassed(key, out)
+		v.Results[key] = summary(out)
+		if !ok {
+			v.Green = false
+		}
+	}
+	return v
+}

Anti-patterns

Грабли верификации
ГрабляПочему плохоКак правильно
Спрашивать у модели «задача готова?» как критерий публикацииСамооценка модели субъективна и склонна к ложному успехуДетерминированный гейт verify по allowlist (build/tests/lint)
Гейт только на тестах, без билда и линтаНесобираемый/грязный код проходит наружуЗелёный вердикт по всем пунктам — обязательное предусловие MR

Практическое задание (RA-v4)

  • Реализовать verify (build/tests/lint в worktree) со структурным вердиктом.
  • Сделать зелёный вердикт обязательным предусловием публикации.
  • Закоммитить: git commit -m "v4: verification gate".

Проверка знаний

Почему критерием «можно открывать MR» служит детерминированный verify, а не ответ модели «я закончил»?

  • A Модель отвечает медленно
  • B Самооценка модели субъективна и может объявить готовым красный код; машинный гейт (build/tests/lint) объективен и не обходится
  • C verify дешевле токенов
  • D Так требует GitHub

Дальше почитать