---
doc_id: REF-CK8S-0015
type: governance
title: "kodex — Human gate и контракт подтверждений в четвёртой волне"
status: active
owner_role: EM
created_at: 2026-04-21
updated_at: 2026-04-22
related_issues: [470]
related_prs: []
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-04-21-refactoring-wave4"
  approved_by: "ai-da-stas"
  approved_at: 2026-04-21
---

# Человеческие контрольные точки и контракт подтверждений в четвёртой волне

## TL;DR
- Human gate — это не "на всякий случай ещё один review", а конкретная точка процесса, где решение обязан принять человек.
- Для каждой контрольной точки платформа обязана собрать пакет подтверждений понятного состава и показать, какого именно решения она ждёт.
- Решение человека должно быть видно через provider-native артефакты и/или платформенный диалоговый контур; скрытый флажок в БД не считается достаточным evidence.
- Агентные reviewer-роли полезны как предварительный и параллельный контур проверки, но не отменяют обязательную человеческую контрольную точку.
- По умолчанию платформа должна двигаться к минимально достаточному числу контрольных точек: лишний человеческий gate так же вреден, как и его отсутствие.

## 1. Что считается human gate
Human gate — это этапный или релизный переход, где policy требует явного решения человека перед продолжением процесса.

Human gate нужен не "для красоты", а когда есть хотя бы один из факторов:
- риск не может быть надёжно снят машинной проверкой;
- решение связано с продуктовым смыслом, а не только с корректностью оформления;
- ошибка может иметь заметный production impact;
- требуется осознанное принятие остаточного риска;
- нужно право на destructive или организационно чувствительное действие.

## 2. Канонические типы человеческих контрольных точек

### 2.1. Продуктовая контрольная точка
Применяется, когда нужно подтвердить:
- смысл документа или инициативы;
- корректность product direction;
- приемлемость компромиссов;
- готовность идти на следующий этап.

Обычно используется на переходах:
- `intake -> vision`
- `vision -> prd`
- `prd -> arch/design`

### 2.2. Архитектурная или data-контрольная точка
Применяется, когда изменение затрагивает:
- сервисные границы;
- API-контракт;
- модель данных;
- внешние интеграции;
- runtime policy.

### 2.3. Контрольная точка перед merge
Применяется перед merge изменений класса `R1+`, если требуется человек, который подтверждает:
- корректность реализации;
- понятность diff;
- соответствие договорённостям по качеству;
- отсутствие очевидных регрессий.

### 2.4. Релизная контрольная точка
Применяется перед запуском deploy `job` для target-контура.

Он подтверждает:
- что evidence package достаточен;
- что известные риски приняты;
- что release можно выпускать сейчас, а не когда-нибудь позже;
- что postdeploy-план существует и понятен.

### 2.5. Пострелизная контрольная точка
Применяется после выкладки, если нужно:
- подтвердить отсутствие блокирующих сигналов;
- признать релиз стабильным;
- решить, нужен ли follow-up;
- инициировать rollback или incident flow.

### 2.6. Аварийная контрольная точка
Специальный gate для hotfix, rollback, recovery и иных действий, где допустима ускоренная процедура, но не допускается полное отсутствие ответственного человека.

## 3. Пакет подтверждений

### 3.1. Общий принцип
Пакет подтверждений должен быть минимальным, но достаточным.

Нельзя:
- требовать десятки формальных полей без практической ценности;
- идти в человеческую контрольную точку без структурированного набора фактов;
- прятать evidence только в глубине логов или внутренней БД.

### 3.2. Канонический минимальный состав

| Блок evidence | Что должно быть внутри | Где это живёт |
|---|---|---|
| Контекст изменения | связанный `Issue`, `PR/MR`, flow, этап, target-контур | provider-native артефакты + platform mirror |
| Класс риска | текущий risk class, причина классификации, повышающие факторы | platform policy state + открытый summary |
| Результат машинной приёмки | acceptance status, обязательные поля, ссылки на follow-up | acceptance machine |
| Review и проверки | reviewer-комментарии, `qa` summary, контрольные роли | `PR/MR`, комментарии, platform mirror |
| Runtime/e2e сведения | build/deploy `job`, итог checks, короткий хвост логов, health summary | runtime-manager + operations projection |
| Известные ограничения | что осталось нерешённым, что принято сознательно | открытые разделы артефакта или структурированный комментарий |
| Следующее решение | чего именно ждёт платформа: merge, release, hold, rollback, follow-up | human gate request |

### 3.3. Что не должно входить в обязательный пакет
По умолчанию не требуется тащить в gate:
- полный stdout/stderr `job`;
- полный diff логов кластера;
- повторные копии всей переписки;
- сырые payload провайдера без нормализации.

## 4. Матрица gate по risk class

| Класс | Перед merge | Перед release | После release |
|---|---|---|---|
| `R0` | документный review по policy | обычно не применяется | обычно не применяется |
| `R1` | контрольная точка перед merge | облегчённая релизная контрольная точка по policy проекта | пострелизный follow-up по сигналам |
| `R2` | контрольная точка перед merge + профильный gate | обязательная релизная контрольная точка | обязательная пострелизная контрольная точка при выкладке |
| `R3` | high-risk gate до merge-ready | high-risk release gate до deploy `job` | обязательный postdeploy gate с правом `hold/rollback` |

Эта матрица задаёт дефолт. Risk profile проекта, репозитория, сервиса или операции может только усиливать требования, но не ослаблять их молча.

## 5. Кто принимает решение по умолчанию

| Сценарий | Кто принимает решение |
|---|---|
| Product docs и крупные этапные документы | Owner или явно назначенный продуктовый reviewer |
| Архитектурные и data-изменения | профильный технический reviewer |
| Обычный merge класса `R1` | технический reviewer |
| Merge/release класса `R2` | технический reviewer + `qa`/операционный gate по policy |
| High-risk release класса `R3` | человек, уполномоченный на high-risk decision; при необходимости Owner |
| Postdeploy incident / rollback | оператор или `sre` с обязательной трассировкой решения |

Если организация позже введёт более точную матрицу ролей, она должна сужать эти правила, а не ломать их.

## 6. Как фиксируется решение человека

### 6.1. Канонический принцип
Решение человека должно быть:
- явно связано с конкретным артефактом и переходом;
- читаемо другим людям;
- машиночитаемо платформой;
- пригодно для аудита.

### 6.2. Допустимые способы фиксации
Допустимо использовать:
- provider-native review/approval;
- структурированный комментарий под `Issue/PR/MR`;
- платформенный диалоговый ответ через frontend или внешний канал;
- явный release/postdeploy decision record во внутреннем policy-контуре с человекочитаемым summary.

Платформа обязана уметь свести эти сигналы в одно наблюдаемое решение.

### 6.3. Что запрещено
Нельзя считать человеческую контрольную точку выполненной, если:
- решение осталось только во внутренней записи без читаемого summary;
- непонятно, какой именно переход был разрешён;
- не видно, кто принял решение и на основании чего.

## 7. Если human gate не получен вовремя
Если нужное решение не получено, платформа не должна "догадываться" вместо человека.

Канонические исходы:
- переход остаётся в `hold`;
- через `interaction-hub` уходит повторное напоминание;
- оператор видит, какая контрольная точка зависла;
- при policy-таймауте создаётся escalation или follow-up задача.

## 8. Как связаны human gates и агентные роли проверки
Агентные роли проверки запускаются:
- до human gate, чтобы сократить ручную работу;
- параллельно, чтобы собрать разные виды evidence;
- после human gate, если policy требует последующего наблюдения.

Но их результат — это часть пакета подтверждений, а не финальная замена человеческого решения.

Пример канонического сценария:
1. основной агент делает `PR` и follow-up `Issue`;
2. acceptance machine принимает базовый контракт;
3. запускаются `vision-reviewer` и `lexical-gatekeeper`;
4. их замечания и approvals попадают в пакет подтверждений;
5. если есть замечания, основной агент-автор возвращается в revise-цикл, устраняет их и повторно публикует результат;
6. дополнительные роли проверки и нужные gates повторно запускаются по policy этого перехода;
7. только после прохождения revise-цикла продуктовый или high-risk gate решает, можно ли идти дальше.

## 9. Что deliberately не фиксируется в этой волне
В этой волне не фиксируются:
- точный UI редактора decision package;
- окончательные тексты всех запросов на человеческую контрольную точку;
- детальная оргструктура команд и персональные назначения;
- автоматический подбор конкретного человека по графику дежурств.

Но любая последующая реализация обязана собирать подтверждения и Human gate именно как first-class process capability, а не как цепочку необязательных комментариев.
