docs: complete autonomous review gates

AGENTS.md

@@ -39,32 +39,56 @@ Python, SQLite и OpenSearch. Production пока не развернут.
 
 ## Автономный workflow PR
 
-- Центральный оркестратор: thread `01a144a5-8b95-77c3-b311-9a9afd062ca8`,
-  host local. DEV (этот агент) выполняет только явно назначенную пользователем
-  задачу в `admin/akyldash`; REVIEWER: thread
-  `01a144f9-5b51-7923-8398-61d4a6a98306`, host
-  `remote-ssh-codex-managed:b61555d7-8d1a-4cfa-988b-c8da4791d426`.
-- Обмен между чатами идёт через центральный relay: участники завершают каждый
-  этап структурированным отчётом с полями `task`, `repo`, `branch`, `pr`,
-  `head_sha`, `stage`, `checks`, `findings`, `next_action`. Не настраивай
-  отдельные webhook, daemon или транспорт.
-- Веди только одну пользовательскую задачу и один PR одновременно. Не
-  подхватывай старые PR самостоятельно; дождись конкретного назначения.
-- DEV исследует, изменяет, проверяет, коммитит и отправляет изменения, создаёт
-  или обновляет PR к `main`. После каждого push REVIEWER независимо проверяет
-  весь актуальный diff и повторно учитывает предыдущие findings. Не запускай
-  замену этому REVIEWER и не одобряй свой PR.
-- После успешного первоначального review DEV вносит значимые изменения в
-  существующий changelog, коммитит и отправляет их в тот же PR. Затем REVIEWER
-  повторно проверяет полный итоговый diff. Для документационной задачи не
-  придумывай изменения кода; соблюдай правила версии, только если они явно
-  применимы.
-- Слияние зарегистрированной задачи разрешено только REVIEWER и только после
-  формального `APPROVED` review текущего `head_sha`, успешных required checks и
-  прохождения всех действующих gates/branch protection. Approval в комментарии
-  не является разрешением на merge. При изменении head или base требуется
-  актуализировать review и проверки. Запрещено обходить защиту ветки, обязательные
-  проверки или требуемое review.
+- Маршруты ниже указаны из контекста оркестратора/root: оркестратор — thread
+  `01a144a5-8b95-77c3-b311-9a9afd062ca8`, host `local`; DEV — thread
+  `01a138f1-3b34-7c91-a9ed-4b43c3c85f1f`, host
+  `remote-ssh-codex-managed:712b8d4e-24e1-4dd5-92af-85d1fbd26449`, Gitea
+  `codex` (ID 6); REVIEWER — thread `01a144f9-5b51-7923-8398-61d4a6a98306`,
+  host `remote-ssh-codex-managed:b61555d7-8d1a-4cfa-988b-c8da4791d426`, Gitea
+  `agent` (ID 7). Если этот же чат отображает REVIEWER как `local` внутри его
+  собственного app-server, это self-label и не является маршрутом из контекста
+  оркестратора.
+- DEV принимает только явно зарегистрированную оркестратором человеческую
+  задачу с полями `task`, `repo`, `branch`, `pr`, `head_sha`, `phase`. Репозиторий
+  должен быть `admin/akyldash`; работай только в назначенной ветке и PR. Веди
+  одну задачу/PR за раз и не подхватывай старые PR самостоятельно.
+- Допустимые фазы: `initial_review` — реализация и устранение review findings;
+  `final_review_and_merge` — только после первоначального успешного review,
+  changelog-коммита и отдельного назначения оркестратора. Не переходи к следующей
+  фазе без назначения. Если задача приостановлена, останови любые действия;
+  после resume перепроверь назначение, PR, head/base, checks и review с нуля.
+- Повторная доставка одного назначения идемпотентна по ключу
+  `task`+`pr`+`head_sha`+`stage`: не дублируй commit, push, review-запрос или
+  merge; сообщи оркестратору о уже выполненном результате. Новый head или stage
+  образует новое назначение и требует повторной проверки.
+- Межчатовое чтение недоступно: оркестратор через central relay сам читает
+  результаты и выдаёт назначения. Завершай каждый этап отчётом с полями `task`,
+  `repo`, `branch`, `pr`, `head_sha`, `stage`, `checks`, `findings`,
+  `next_action`. Не настраивай отдельные webhook, daemon или транспорт.
+- DEV исследует, изменяет, проверяет, коммитит и отправляет изменения; REVIEWER
+  не меняет код и независимо проверяет полный diff от base после каждого push,
+  включая предыдущие findings. DEV не одобряет и не сливает свой PR.
+- Только после первоначального успешного формального review DEV добавляет
+  значимые изменения в существующий changelog, коммитит и отправляет их в тот же
+  PR. Затем REVIEWER полностью проверяет итоговый diff. Для docs-only задачи не
+  придумывай изменения кода; правила версии применяй только если они явно
+  относятся к этой документационной правке.
+- Слияние может выполнить только REVIEWER для зарегистрированной человеческой
+  задачи, в фазе `final_review_and_merge`, после явного назначения оркестратора.
+  Непосредственно перед ним REVIEWER подтверждает `admin/akyldash`, PR, base
+  `main`, ожидаемую ветку, автора PR `codex` (ID 6), неизменность base и head,
+  причём head должен совпадать с зарегистрированным `head_sha`, включая
+  `head_commit_id` для merge-запроса. Требуются все успешные required CI/test
+  checks и gates, отсутствие pending/failed/unknown checks, открытых
+  findings и активных `REQUEST_CHANGES`, плюс актуальный формальный `APPROVED`
+  от REVIEWER для точного текущего commit с параметрами `commit_id == head_sha`,
+  `stale == false`, `dismissed == false`. При изменении head или base review и
+  проверки выполняются заново. Комментарий с approval не является формальным
+  review.
+  Используй только обычный server-side merge с `head_commit_id`; не используй
+  `force_merge` и не обходи branch protection. Если любой существенный gate,
+  статус или защита неизвестны либо не проверяются — не сливай PR и сообщи
+  оркестратору, что именно осталось неизвестным.
 - Все Gitea API-вызовы выполняй только через `gitea-api` с личным окружением;
   Git используй с обычным credential helper. Не читай credentials из файлов
   репозитория. Запускай Git- и API-команды отдельно, без объединения с другими