claude-bot
19c31778b2
Address reviewer P1 (ось ORCH-011/ORCH-079, правило агентов №6): витрина описывала паузу serial-gate как исключительно операторскую, но ORCH-120 добавил движковый авто-park/unpark на analyst Needs Input. - tech-pipeline.md: абзац пауз теперь называет два источника (оператор + авто-park движком на Needs Input, флаг analyst_needs_input_autopause_enabled, скоуп self-hosting, симметричный unpark на resume). - tech-observability.md: пункт пауз в GET /queue — оба источника. - tech-agents.md: when-applicable сигнальный канал 01-questions.md у analyst (строка таблицы + поясняющая врезка; не machine-verdict, не deliverable). - CHANGELOG: запись ORCH-120 дополнена строкой про обновление витрины. tests/test_system_docs.py зелёный (29 passed). src/STAGE_TRANSITIONS/QG_CHECKS не тронуты — docs-only. Refs: ORCH-120 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
84 lines
7.3 KiB
Markdown
84 lines
7.3 KiB
Markdown
# Блок 3. Агенты: 6 ролей конвейера
|
||
|
||
> Промпты ролей лежат в `.openclaw/agents/*.md` (по одному файлу на роль). Канон манифеста
|
||
> «документ → агент → стадия → гейт → machine-key» — [PIPELINE_DOCS §2](../_standards/PIPELINE_DOCS.md);
|
||
> машинный контракт передачи между стадиями — [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md).
|
||
|
||
## Паспорта ролей
|
||
|
||
| Роль | Стадия | Вход | Выходные артефакты | 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** артефакта (никогда из
|
||
прозы) и неизменны байт-в-байт — подробнее в [блоке качества](tech-quality-security.md).
|
||
|
||
> **Сигнальный канал аналитика → 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 — [конвейер](tech-pipeline.md).
|
||
|
||
## Модель и эффорт
|
||
|
||
Модель и эффорт каждой роли резолвятся **только из конфига** (не из промпта); текущие
|
||
дефолты конфига:
|
||
|
||
| Роль | Модель | Эффорт |
|
||
|------|--------|--------|
|
||
| `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`. Подробнее —
|
||
[конвейер](tech-pipeline.md) и [карта LLM-консультаций](../architecture/llm-call-sites.md).
|
||
|
||
Особенность (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:`. Подробнее — [конвейер](tech-pipeline.md) и
|
||
[карта LLM-консультаций](../architecture/llm-call-sites.md).
|
||
|
||
## Человек как седьмая роль
|
||
|
||
Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы
|
||
агентам: одобрение постановки (после `analyst`) и подтверждение прод-выкладки (перед финалом
|
||
работы `deployer`). Подробнее — [человеческие гейты](tech-pipeline.md).
|
||
|
||
---
|
||
|
||
*Структуры документов, которые сдаёт каждая роль, — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md);
|
||
скелеты — `docs/_templates/`.*
|