orchestrator/docs/overview/tech-agents.md

Блок 3. Агенты: 6 ролей конвейера

Промпты ролей лежат в .openclaw/agents/*.md (по одному файлу на роль). Канон манифеста «документ → агент → стадия → гейт → machine-key» — PIPELINE_DOCS §2; машинный контракт передачи между стадиями — HANDOFF_PROTOCOL.

Паспорта ролей

Роль	Стадия	Вход	Выходные артефакты	Machine-verdict ключ
analyst	analysis	бизнес-запрос (00-business-request.md)	01-brd.md, 02-trz.md, 03-acceptance-criteria.md, 04-test-plan.yaml; when-applicable сигнальный 01-questions.md	— (гейт проверяет полноту пакета + одобрение человека)
architect	architecture	пакет аналитики	06-adr/ADR-NNN-*.md, when-applicable 07-infra-requirements.md / 08-data-requirements.md, 10-tech-risks.md	— (гейт проверяет наличие ADR)
developer	development	ТЗ + ADR	код в src/, тесты в tests/, обновлённые доки, CHANGELOG.md, PR в Gitea	— (гейт — зелёный CI ветки)
reviewer	review	PR diff + ТЗ/ADR	12-review.md	verdict: (APPROVED | REQUEST_CHANGES)
tester	testing	ветка задачи + тест-план	13-test-report.md	result: (PASS | FAIL | BLOCKED)
deployer	deploy-staging / deploy	прошедшая гейты ветка	15-staging-log.md, 14-deploy-log.md	staging_status: / deploy_status: (SUCCESS | FAILED)

Machine-verdict ключи читаются гейтами только из YAML-frontmatter артефакта (никогда из прозы) и неизменны байт-в-байт — подробнее в блоке качества.

Сигнальный канал аналитика → Needs Input (ORCH-120). Если на стадии analysis аналитик упирается в блокирующие открытые вопросы, он не фабрикует обязательные deliverables, а выпускает when-applicable артефакт 01-questions.md — задача уходит в Needs Input и (под флагом analyst_needs_input_autopause_enabled, скоуп self-hosting) автоматически встаёт на паузу, чтобы не клинить очередь репозитория, пока ждём ответа человека; ответ возобновляет анализ и снимает паузу. 01-questions.md — сигнальный артефакт того же владельца/стадии, не machine-verdict и не один из 4 обязательных deliverables (exit-гейт check_analysis_complete его не парсит). Как это вплетено в serial-gate — конвейер.

Модель и эффорт

Модель и эффорт каждой роли резолвятся только из конфига (не из промпта); текущие дефолты конфига:

Роль	Модель	Эффорт
analyst	claude-opus-4-8	high
architect	claude-opus-4-8	high
developer	claude-opus-4-8	xhigh
reviewer	claude-opus-4-8	high
tester	claude-opus-4-8	medium
deployer	claude-opus-4-8	medium

Разработчику — максимальный эффорт (он пишет код); тестировщику и деплойеру хватает среднего (их работа процедурная). Таблица сверяется с class-default'ами src/config.py структурным тестом — дрейф рвёт CI.

Канон промптов

Все промпты следуют единому канону (Anthropic XML, эпик 52): пять обязательных секций в нормативном порядке <context> → <task> → <deliverables> → <constraints> → <output_format>, запреты в формате «❌ X → ✅ Y», секция эскалации у решающих ролей. Каждый агент эмитит единую frontmatter-схему в своих документах (work item, стадия, автор, статус, дата, модель). Промпт читается из worktree в момент запуска — обновление промптов вступает в силу со следующей задачи, без рестарта прода.

Особенность: промпт deployer сознательно на английском (самый safety-critical — несёт запреты self-hosting в видной рамке); остальные пять — на русском.

Особенность (ORCH-115): на стадии deploy-staging для self-hosting orchestrator LLM-deployer заменён детерминированным staging-раннером (src/staging_runner.py) — его работа была чисто механической (запуск staging-сюиты + маппинг exit-кода). LLM-промпт deployer остаётся fallback'ом под выключенным флагом / для не-self репо и продолжает вести прод-стадию deploy. Подробнее — конвейер и карта LLM-консультаций.

Особенность (ORCH-116): на стадии testing для self-hosting orchestrator LLM-tester заменён детерминированным test-раннером (src/test_runner.py) — его PASS/FAIL-ядро деривируемо (exit-код pytest в worktree + read-only smoke), вердикт result: производит детерминированный код. Это гибрид (needs-hybrid-fallback): LLM-промпт tester остаётся fallback'ом под выключенным флагом / для репо без тест-контракта, а будущий off-control-path триаж падений не выносит и не переопределяет result:. Подробнее — конвейер и карта LLM-консультаций.

Человек как седьмая роль

Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы агентам: одобрение постановки (после analyst) и подтверждение прод-выкладки (перед финалом работы deployer). Подробнее — человеческие гейты.

---

Структуры документов, которые сдаёт каждая роль, — PIPELINE_DOCS; скелеты — docs/_templates/.