claude-bot
b50cf1dd08
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>
5.3 KiB
Блок 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 |
— (гейт проверяет полноту пакета + одобрение человека) |
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 артефакта (никогда из прозы) и неизменны байт-в-байт — подробнее в блоке качества.
Модель и эффорт
Модель и эффорт каждой роли резолвятся только из конфига (не из промпта); текущие дефолты конфига:
| Роль | Модель | Эффорт |
|---|---|---|
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-консультаций.
Человек как седьмая роль
Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы
агентам: одобрение постановки (после analyst) и подтверждение прод-выкладки (перед финалом
работы deployer). Подробнее — человеческие гейты.
Структуры документов, которые сдаёт каждая роль, — PIPELINE_DOCS;
скелеты — docs/_templates/.