Files
orchestrator/docs/overview/tech-agents.md
claude-bot b50cf1dd08
All checks were successful
CI / test (push) Successful in 1m8s
CI / test (pull_request) Successful in 1m8s
feat(staging): deterministic staging-runner replacing LLM deployer on deploy-staging (ORCH-115)
Replace the LLM `deployer` agent on the `deploy-staging` stage (self-hosting
orchestrator) with a deterministic staging-runner intercepted in launch_job
BEFORE _spawn (the deploy-finalizer / post-deploy-monitor reserved-agent
precedent). The runner executes the SAME staging suite, maps the exit-code to
`staging_status:` via the existing self_deploy.map_exit_code_to_status contract,
writes 15-staging-log.md, and initiates the UNCHANGED check_staging_status gate
exactly as a finished LLM-deployer would.

Invariant (NFR-1): this replaces only the *producer* of the artifact — the
artifact contract, the gate / _parse_staging_status / check_staging_status name,
STAGE_TRANSITIONS, the machine-verdict key `staging_status:` and the DB schema are
byte-for-byte unchanged. Additive, under a kill-switch + repo-scope CSV,
never-raise, fail-safe back to the LLM path.

Two-level outcome (D5, anti ORCH-110): suite executed -> verdict -> advance
(FAILED -> the existing deploy-staging -> development rollback + developer-retry,
same as a FAILED LLM verdict); tool-error (suite did not execute) -> bounded DEFER
-> fail-closed FAILED + alert on exhaustion (infra != code fault; never a silent
advance / false green).

First implemented slice of the LLM determinization roadmap (ORCH-118 A6,
replace-deterministic-now).

- New leaf src/staging_runner.py (never-raise; proc_group tree-kill + timeout)
- launch_job intercept + _run_staging_runner_job (mirror _run_deploy_finalizer_job)
- config: ORCH_STAGING_RUNNER_* keys (enabled/repos/timeout/infra-retry budget)
- GET /queue staging_runner observability block
- docs: llm-call-sites/roadmap/usage-policy (A6 implemented; machine blocks +
  single-transport invariant intact), deployer.md (LLM branch -> fallback),
  CLAUDE.md, CHANGELOG.md, overview (tech-pipeline/tech-agents/tech-quality-security),
  .env.example
- tests/test_orch115_staging_runner.py (TC-01..TC-13); LLM anti-drift green (TC-14)

Refs: ORCH-115

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 01:59:43 +03:00

67 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Блок 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` | — (гейт проверяет полноту пакета + одобрение человека) |
| `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).
## Модель и эффорт
Модель и эффорт каждой роли резолвятся **только из конфига** (не из промпта); текущие
дефолты конфига:
| Роль | Модель | Эффорт |
|------|--------|--------|
| `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).
## Человек как седьмая роль
Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы
агентам: одобрение постановки (после `analyst`) и подтверждение прод-выкладки (перед финалом
работы `deployer`). Подробнее — [человеческие гейты](tech-pipeline.md).
---
*Структуры документов, которые сдаёт каждая роль, — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md);
скелеты — `docs/_templates/`.*