analyst(ET): auto-commit from analyst run_id=459

This commit is contained in:
2026-06-09 14:32:28 +03:00
committed by orchestrator-deployer
parent 9deff540f5
commit bd5d681083
4 changed files with 587 additions and 0 deletions

View File

@@ -0,0 +1,150 @@
# 01 — BRD (бизнес-требования): ORCH-077 — ORCH-52d: оптимизация 6 системных промптов по Anthropic
Work Item: **ORCH-077** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
## 1. Бизнес-контекст и проблема
Эпик **ORCH-52** строит сквозной контракт документации конвейера тремя слоями:
- **52b (ORCH-075)** — описательный стандарт документов: `docs/_standards/PIPELINE_DOCS.md`
(карта «стадия → агент → документ → гейт → machine-key») + копируемые скелеты в
`docs/_templates/`.
- **52c (ORCH-076)** — машинный контракт: единый `src/frontmatter.py` (reader + writer +
валидатор `validate_schema`/`REQUIRED_FIELDS`) и спека `docs/_standards/HANDOFF_PROTOCOL.md`
с **обязательной frontmatter-схемой** (`work_item`, `stage`, `author_agent`, `status`,
`created_at`, `model_used`).
- **52d (эта задача, ORCH-077)** — слой промптов: замыкающее звено.
**Боль 1 (разрыв цепочки 52b→52c→52d).** 52c заложила writer и валидатор обязательной схемы,
но работает в режиме **обратной совместимости** (`frontmatter_validation_strict=False`,
warning-only) — агенты **физически не проставляют** эти поля в своих выходных документах. Пока
6 системных промптов не научены эмитить схему, петля 52 не замкнута: writer есть, валидатор
есть, а данных на входе нет.
**Боль 2 (форма промптов).** 6 системных промптов агентов (`.openclaw/agents/*.md`) написаны
в свободной разнородной форме (часть по-русски, deployer — по-английски), без единой структуры.
Это снижает предсказуемость поведения агентов прода и затрудняет сопровождение. Канон Anthropic
по построению системных промптов (XML-разметка секций, few-shot с эталонами, явное место для
рассуждения, позитивные примеры рядом с запретами, литеральный scope) даёт измеримо более
стабильный выход.
**Установленные факты (проверено в репозитории):**
- Промпты в `.openclaw/agents/`: `analyst.md`, `architect.md`, `developer.md`, `reviewer.md`,
`tester.md`, `deployer.md` — все 6 в объёме.
- Модель/эффорт каждого агента резолвятся ТОЛЬКО из config (`resolve_agent_model` /
`resolve_agent_effort`, ORCH-41); frontmatter `model:` удалён как мёртвый (ORCH-074, тест
`tests/test_agent_frontmatter_no_model.py`). Все 6 ролей сейчас на `claude-opus-4-8`.
- Обязательная схема: `src/frontmatter.py::REQUIRED_FIELDS =
("work_item", "stage", "author_agent", "status", "created_at", "model_used")`.
- Machine-verdict ключи (регистрозависимы, читаются гейтами ТОЛЬКО из frontmatter):
`verdict:` (12-review.md), `result:`/`verdict:`/`status:` (13-test-report.md),
`staging_status:` (15-staging-log.md), `deploy_status:` (14-deploy-log.md),
`security_status:` (17-security-report.md).
## 2. Объём (scope)
### В объёме
- Переписать **все 6** промптов `.openclaw/agents/*.md` в едином каноне Anthropic с
XML-структурой секций: `<context>` / `<task>` / `<deliverables>` / `<constraints>` /
`<output_format>` (допустимы дополнительные семантические секции, напр. `<thinking>`-подсказка).
- Добавить в каждый промпт **явную инструкцию эмитить обязательную frontmatter-схему 52c**
(`work_item` / `stage` / `author_agent` / `status` / `created_at` / `model_used`) в тех
выходных документах, которые роль авторствует, с конкретными для роли значениями
(`author_agent` = роль, `stage` = стадия роли, `model_used` = резолв ORCH-41).
- Few-shot: ссылки на скелеты 52b (`docs/_templates/`) и эталонные work item (ORCH-073 / ORCH-088)
как примеры заполнения; позитивные примеры рядом с запретами («делай Y вместо X»).
- Явное место для рассуждения (CoT/thinking) там, где это уместно для роли.
- Чёткие success-criteria артефакта стадии (что считается готовым выходом).
- Обновить документацию: `CLAUDE.md`, `docs/architecture/README.md`, ADR (per-work-item +
при необходимости сквозной), `CHANGELOG.md`.
### Вне объёма
- **Любая правка кода**: `src/config.py`, `src/agents/launcher.py`, `resolve_agent_model` /
`resolve_agent_effort`, `src/frontmatter.py` (сделана в 52c), `src/stages.py`,
`src/qg/checks.py`, `src/stage_engine.py`.
- **Включение жёсткой валидации** схемы (`frontmatter_validation_strict`) — остаётся `False`
(warning-only). 52d учит промпты эмитить схему добровольно; enforcement не включается.
- Изменение состава/семантики Quality Gates, `STAGE_TRANSITIONS`, набора machine-verdict ключей.
- Model-routing / смена моделей ролей (вне эпика).
- Изменение `tools:`-блока (разрешённые инструменты) в frontmatter промптов.
## 3. Заинтересованные стороны
- **Заказчик / Owner (Слава)** — принимает результат; ручной BRD-гейт.
- **Потребитель прямой** — 6 агентов прода, которые исполняют эти промпты на КАЖДОЙ задаче ВСЕХ
проектов (orchestrator + enduro-trails) из общего инстанса.
- **Косвенно затронуты** — все будущие work item (качество артефактов конвейера) и петля 52
(наполнение frontmatter-схемы реальными данными).
## 4. Бизнес-требования (BR)
- **BR-1** — Все 6 промптов (`.openclaw/agents/*.md`) переписаны единым XML-стилем секций
(`<context>` / `<task>` / `<deliverables>` / `<constraints>` / `<output_format>`).
- **BR-2** — Каждый промпт **явно инструктирует** агента проставлять обязательную
frontmatter-схему 52c (все 6 полей) в выходных документах, которые роль авторствует, с
конкретными для роли значениями.
- **BR-3** — Few-shot: каждый промпт ссылается на скелеты 52b (`docs/_templates/`) и эталоны
(ORCH-073 / ORCH-088); запреты сопровождаются позитивным примером («делай Y вместо X»).
- **BR-4 (АНТИ-РЕГРЕСС, критично для self-hosting)** — НИ ОДНА функциональная инструкция
старого промпта не потеряна: гейты, machine-verdict ключи и их регистр, маркеры `ORCH-NNN`,
правила `CLAUDE.md`, ролевые запреты, идемпотентный merge-guard, canonical staging-команда
(`docker exec`), self-hosting-запреты. Агенты продолжают проходить свои гейты.
- **BR-5** — Код НЕ изменён: правятся только `.openclaw/agents/*.md` + документация;
`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` нетронуты.
- **BR-6** — Проведена A/B-проверка минимум на одной репрезентативной стадии (старый vs новый
промпт): новый промпт НЕ хуже по числу циклов `REQUEST_CHANGES` / качеству артефакта.
- **BR-7** — Документация (`CLAUDE.md` / `README` / ADR / `CHANGELOG`) обновлена в том же PR.
## 5. Нефункциональные требования (NFR)
- **NFR-1 (обратная совместимость гейтов)** — Новые промпты эмитят схему **аддитивно**: рядом с
существующими machine-verdict ключами, не меняя их имени/регистра/позиции. Гейты читают вердикты
ровно как раньше (схема при `strict=False` в вердикте не участвует).
- **NFR-2 (безопасность прода)** — Промпт = поведение агента прода для ВСЕХ проектов. Рефактор
формы не должен ослабить ни одну рабочую инструкцию (особенно self-hosting-запреты deployer'а:
«не рестартить 8500 изнутри», merge-guard).
- **NFR-3 (валидность frontmatter промпта)** — YAML-frontmatter каждого `.openclaw/agents/*.md`
остаётся валидным YAML, сохраняет `name`/`description`, НЕ возвращает удалённый `model:`
(тест `test_agent_frontmatter_no_model.py` остаётся зелёным).
- **NFR-4 (читабельность/сопровождаемость)** — Единый канон облегчает будущие правки; объём
каждого промпта остаётся соразмерным (без раздувания «воды»).
- **NFR-5 (обратимость)** — Изменение чисто текстовое; откат = git revert PR, без миграций
состояния/БД.
## 6. Допущения и ограничения
- **Допущение 1** — `model_used` для всех 6 ролей сейчас = `claude-opus-4-8` (README §«Модель и
эффорт по ролям»); промпт инструктирует ставить именно эту модель как резолв ORCH-41. Если
model-routing включат позже — значение пересматривается, но это вне ORCH-077.
- **Допущение 2** — `created_at` агент берёт как текущую дату (`YYYY-MM-DD`); источник —
доступный агенту способ (напр. `date +%F` через Bash там, где Bash в `tools:`).
- **Ограничение 1** — `tools:`-блок и разрешённые пути записи каждого промпта НЕ расширяются:
агент эмитит схему только в те документы, которые и так авторствует.
- **Ограничение 2** — Developer не авторствует номерного handoff-вердикт-документа (его выход —
код + PR, гейт `check_ci_green`); для него инструкция схемы применяется к when-applicable
докам (`07`/`08`/`10`), если он их трогает, а основной акцент — на сохранении dev-инструкций.
- **Ограничение 3** — `frontmatter_validation_strict` остаётся `False`; ORCH-077 НЕ включает
hard-fail (это была бы правка config = вне scope).
## 7. Критерии успеха
Резюме: 6 промптов переписаны по канону Anthropic, эмитят схему 52c, не потеряли ни одной
функциональной инструкции, код не тронут, документация обновлена, A/B подтверждает «не хуже».
Детальные PASS/FAIL — `03-acceptance-criteria.md`.
## 8. Риски
Краткий перечень (детали — `10-tech-risks.md`, заполняет архитектор):
- **R-1 (регресс поведения агента)** — при рефакторе формы потерять рабочую инструкцию →
агент ломает выход для ВСЕХ проектов. Митигация: построчная карта «старая инструкция → где в
новом промпте» (AC-4), A/B-прогон.
- **R-2 (ложный гейт-провал)** — случайно изменить регистр/имя machine-verdict ключа или
сместить его так, что парсер не найдёт. Митигация: явный инвентарь ключей, структурные тесты.
- **R-3 (некорректный `model_used`)** — захардкодить неверную модель. Митигация: ссылка на
резолв ORCH-41 и таблицу README.
- **R-4 (раздувание промпта)** — XML-канон + few-shot увеличат объём и «утопят» ключевые
запреты. Митигация: ссылки на эталоны вместо инлайна, контроль объёма.

View File

@@ -0,0 +1,227 @@
# 02 — ТЗ (TRZ): ORCH-077 — ORCH-52d: оптимизация 6 системных промптов по Anthropic
Work Item: **ORCH-077** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
> ТЗ описывает **конкретные изменения** (выведенные из BRD и фактического содержимого репозитория).
> Архитектурное обоснование (порядок секций, формулировки, нужен ли сквозной ADR) — задача
> архитектора (`06-adr`). Это **docs/prompts-only** задача: код не меняется.
## 1. Сводка изменения
Переписать 6 системных промптов агентов (`.openclaw/agents/*.md`) в едином каноне Anthropic
(XML-секции) и научить каждый эмитить обязательную frontmatter-схему 52c в авторских документах.
**Тело** промпта (Markdown ниже frontmatter) реструктурируется; **YAML-frontmatter промпта**
(`name`, `description`, `tools`) сохраняется как есть (без `model:`). СОДЕРЖАНИЕ всех
функциональных требований переносится 1:1 (см. §3 — инвентарь анти-регресса). Параллельно
обновляется документация (§8).
## 2. Задействованные модули / пути
| Путь | Действие |
|------|----------|
| `.openclaw/agents/analyst.md` | переписать (тело) |
| `.openclaw/agents/architect.md` | переписать (тело) |
| `.openclaw/agents/developer.md` | переписать (тело) |
| `.openclaw/agents/reviewer.md` | переписать (тело) |
| `.openclaw/agents/tester.md` | переписать (тело) |
| `.openclaw/agents/deployer.md` | переписать (тело) |
| `CLAUDE.md` | обновить (раздел про промпты / эпик 52) |
| `docs/architecture/README.md` | обновить (раздел про схему/handoff и слой промптов 52d) |
| `docs/work-items/ORCH-077/06-adr/ADR-001-*.md` | создать (архитектор) |
| `docs/architecture/adr/adr-NNNN-*.md` | создать при необходимости (архитектор, если сквозное) |
| `CHANGELOG.md` | добавить запись `## [Unreleased]` |
| `tests/test_agent_prompts_canon.py` (имя — на усмотрение dev) | создать (структурные тесты, §7 / см. test-plan) |
| **НЕ трогать** | `src/**` (любой), включая `config.py`, `agents/launcher.py`, `frontmatter.py`, `stages.py`, `qg/checks.py`, `stage_engine.py` |
## 3. Функциональные требования
### FR-1 — Единая XML-структура секций во всех 6 промптах (BR-1)
Тело каждого промпта организовано вокруг секций (XML-теги как разделители смысловых блоков):
- `<context>` — кто агент, проект orchestrator, стек, self-hosting, что прочесть перед работой
(обязательный пункт «прочти `CLAUDE.md` и `docs/architecture/README.md`»).
- `<task>` — что делает роль на своей стадии; допускается вложенная `<thinking>`-подсказка
(явное место для рассуждения, где уместно — FR-4).
- `<deliverables>` — какие файлы и куда роль создаёт через Write tool.
- `<constraints>` — запреты и обязательные правила (включая ролевые «Запрещено» из старых промптов).
- `<output_format>` — точный формат выходных документов, включая frontmatter-схему (FR-2) и
machine-verdict ключи.
Дополнительные секции допустимы (напр. `<success_criteria>`, `<escalation>`), но 5 перечисленных
обязательны во всех 6 промптах.
### FR-2 — Инструкция эмитить обязательную frontmatter-схему 52c (BR-2)
В секции `<output_format>` каждого промпта явно перечислены 6 обязательных полей схемы
(`src/frontmatter.py::REQUIRED_FIELDS`) с конкретными для роли значениями. Схема ставится
**аддитивно** — ПОВЕРХ существующих ключей документа, НЕ заменяя и НЕ смещая machine-verdict
ключи (NFR-1).
| Поле | Значение / источник |
|------|---------------------|
| `work_item` | ID задачи (`ORCH-NNN` / `ET-NNN`) — подставляется агентом |
| `stage` | стадия роли (см. таблицу ниже) |
| `author_agent` | роль (см. таблицу ниже) |
| `status` | статус выхода стадии (роле-специфично; для вердикт-доков согласован с вердиктом) |
| `created_at` | текущая дата `YYYY-MM-DD` |
| `model_used` | резолв ORCH-41 — на текущий момент `claude-opus-4-8` для всех ролей (README §«Модель и эффорт») |
**Карта роль → стадия → author_agent → документы, несущие схему:**
| Роль (prompt) | `stage` | `author_agent` | Документы со схемой | Machine-verdict ключ (НЕ трогать) |
|---------------|---------|----------------|---------------------|-----------------------------------|
| analyst | `analysis` | `analyst` | `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml` | — (нет; гейт = наличие файлов + Approved) |
| architect | `architecture` | `architect` | `06-adr/ADR-NNN-*.md`, `07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md` | — |
| developer | `development` | `developer` | when-applicable доки, если трогает (`07`/`08`/`10`); код/PR номерного вердикт-дока не несёт | — (гейт = `check_ci_green`) |
| reviewer | `review` | `reviewer` | `12-review.md` | `verdict:` (`APPROVED`\|`REQUEST_CHANGES`) |
| tester | `testing` | `tester` | `13-test-report.md` | `result:`/`verdict:`/`status:` (`PASS`\|`FAIL`\|`BLOCKED`) |
| deployer | `deploy-staging`, `deploy` | `deployer` | `15-staging-log.md`, `14-deploy-log.md`, `17-security-report.md` (when-applicable) | `staging_status:`, `deploy_status:`, `security_status:` |
> Примечание по `04-test-plan.yaml`: это YAML-документ (не Markdown с frontmatter-блоком). Схема
> ложится как top-level ключи YAML рядом с существующими (`work_item` уже присутствует в скелете;
> добавляются `stage`/`author_agent`/`status`/`created_at`/`model_used`). Архитектор фиксирует
> точную форму в ADR, если есть нюанс совместимости со скелетом 52b.
### FR-3 — Few-shot и позитивные примеры (BR-3)
В каждом промпте (секция `<deliverables>` и/или `<output_format>`):
- ссылка на копируемый скелет роли в `docs/_templates/` (напр. analyst → `01-brd.md`,
`02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`);
- ссылка на эталонный заполненный work item — **ORCH-073** и/или **ORCH-088** — как пример
качества/полноты;
- каждый запрет в `<constraints>` сопровождается позитивной альтернативой: формат
«❌ не делай X → ✅ делай Y» (литеральность Opus 4.8).
### FR-4 — Явное место для рассуждения (CoT/thinking)
Там, где роль принимает решение (architect — выбор решения; reviewer — вынесение вердикта;
tester — классификация PASS/FAIL/BLOCKED; deployer — трактовка exit-кодов/waiver), промпт
содержит явную `<thinking>`-подсказку «сначала рассуди, потом пиши вердикт». Для механических
ролей (минимально) — не обязательно.
### FR-5 — Success-criteria артефакта стадии
В каждом промпте есть явный блок «выход считается готовым, когда…»: перечень файлов + наличие
обязательных frontmatter-полей + (для вердикт-ролей) корректный machine-verdict ключ.
### FR-6 — АНТИ-РЕГРЕСС: инвентарь сохраняемых инструкций (BR-4, критично)
Ниже — обязательный к переносу 1:1 минимум по каждому промпту. Reviewer проверяет ПОСТРОЧНО.
Список не исчерпывающий: переносится ВСЁ функциональное содержание, перечисленное — обязательный
костяк.
**analyst.md:**
- «Используй Write tool; не выводи содержимое в stdout».
- Список «что прочесть» (`CLAUDE.md`, README, `00-business-request.md`, `src/`).
- 4 обязательных deliverable: `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`,
`04-test-plan.yaml`.
- Формат TRZ (модули `src/`, изменения API, изменения БД, требования к QG, артефакты pipeline).
- Формат `test-plan.yaml` (id/type/description/module/expected).
- Запреты: не предлагать архитектурные решения, не писать код, не править чужие work item, не
выводить в stdout.
**architect.md:**
- «Прочти CLAUDE.md и README».
- Контекст стека, конвейер, self-hosting-предупреждение (общий прод-контейнер).
- Deliverables: `06-adr/ADR-NNN-*.md` (обяз.), `07`/`08`/`10` (по применимости).
- Правило сквозного ADR `docs/architecture/adr/adr-NNNN-*` для сквозных решений.
- ADR-формат (Статус / Контекст / Решение / Последствия).
- «Документация = golden source»: обновлять README/internals при изменении стадий/QG.
- Self-hosting-запреты: не предлагать рестарт прода без staging-гейта, всё ORCH — через 8501.
- Принципы (Docker/один сервер, SQLite, conventional/trunk, без k8s/облака, без ORM при raw SQL).
- Запреты (multi-node/managed, лишний MQ, менять QG без ADR, рестарт прода без staging).
- Эскалация (`arch:major-change`, `back-to:analysis`).
**developer.md:**
- «Прочти CLAUDE.md и README».
- Стек, список «что прочесть» (`02-trz` — источник правды, `03`, `04`, `06-adr/`, код).
- Алгоритм: fetch+rebase origin/main → TDD (тест, потом код) → миграции при смене схемы →
`ruff check` + `pytest` → conventional commit (`Refs: <plane-id>`) → push → PR в Gitea.
- «Документация = golden source в ТОМ ЖЕ PR» (API/конвейер/конфиг/компонент/CHANGELOG).
- Конвенции (conventional commits, ветки, docstring, содержательные тесты).
- Self-hosting: НЕ перезапускать прод, проверять через `pytest` локально.
- Запреты: не менять ТЗ/ADR, без ADR не решать архитектуру, не коммитить секреты,
PR > 1500 строк без декомпозиции, не мержить свой PR, без `--no-verify`/`--force-push`,
не рестартить прод.
**reviewer.md:**
- «Прочти CLAUDE.md (правила документирования!) и README».
- 4 оси: соответствие ТЗ, соответствие ADR, качество кода, **качество документации**.
- Жёсткое правило: src/ изменён, а `docs/`/`CHANGELOG`/ADR НЕ обновлены → ОБЯЗАТЕЛЬНО
`REQUEST_CHANGES` (приоритет над остальным).
- Severity P0/P1/P2/P3 (с пунктом «документация не обновлена при изменении src/» = P0).
- Правило вердикта: любой P0/P1 → `REQUEST_CHANGES`; только P2/P3 / нет findings → `APPROVED`.
- **Frontmatter-контракт `12-review.md`:** вердикт читается ТОЛЬКО из `verdict:` (UPPERCASE,
строго `APPROVED`|`REQUEST_CHANGES`), упоминания в прозе не учитываются; без frontmatter →
not-approved.
- Запреты: не править код, не апрувить PR того же экземпляра developer, без subjective без
ссылки на правило, не пропускать проверку документации.
**tester.md:**
- «Прочти CLAUDE.md и README».
- Что прочесть (`02`/`03`/`04`/`12-review.md` — убедиться, что вердикт APPROVED).
- Алгоритм: проверка окружения (`curl /health`) → `pytest tests/ -v --tb=short` → smoke API
(`/health`, `/status`, `/queue`) → сверка покрытия ТЗ с `04-test-plan.yaml` и `03`.
- **Frontmatter `13-test-report.md`:** `result:` (PASS|FAIL) — машинный вердикт; таблица TC,
вывод pytest, итог.
- Вердикт: все PASS+smoke OK → `result: PASS` → deploy-staging; любой FAIL → `result: FAIL`
откат на development.
- Запреты: не писать прод-код, не подгонять тесты под код, не запускать деструктив на проде.
**deployer.md** (наиболее рискованный — self-hosting):
- Шапка-предупреждение: прочесть CLAUDE.md/README/INFRA.md; **НЕ перезапускать прод 8500**.
- Стадия `deploy-staging`: canonical-команда `docker exec orchestrator-staging python3
/repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`
(с обоснованием B6 registry-isolation — сохранить!); маппинг exit 0 → `SUCCESS`, ≠0 → `FAILED`.
- ORCH-061: толерантность к waived C9a/C9b (`INFRA-WAIVED:` копировать в лог; доверять exit-коду,
не пересуживать); kill-switch `ORCH_STAGING_INFRA_TOLERANCE_ENABLED=false`/`--strict`.
- `staging_status:` строго `SUCCESS`|`FAILED` (UPPERCASE) — единственный машинный ключ
`check_staging_status`.
- Merge `15-staging-log.md` в `main` (commit+push).
- Стадия `deploy`: контракт `deploy_status: SUCCESS|FAILED` (читает только `check_deploy_status`).
- **Идемпотентный merge-guard (ORCH-065):** перед (повторным) merge feature-PR в `main`
консультировать `merge_gate.pr_already_merged(repo, branch)`; MERGED=1 → не мержить повторно
(no-op), MERGED=0 → мержить; guard never-raise.
- **Self-hosting (`orchestrator`):** ты НЕ деплоишь себя; Phase A/B/C оркестрируются кодом
(`stage_engine`/`self_deploy`); НИКОГДА не запускать `docker compose up -d orchestrator` /
`--build` / рестарт 8500 изнутри; `deploy_status: SUCCESS` = реальный host health-ok.
- Non-self репо (enduro): прежний синхронный ssh-деплой через
`scripts/orchestrator-deploy-hook.sh`.
- Общие правила: всегда машинный YAML-frontmatter (гейты парсят только frontmatter); никогда
push в `main` напрямую; не менять `.env`/`.env.staging`/`docker-compose.yml`/прод-инфру.
### FR-7 — Валидность frontmatter промптов (NFR-3)
YAML-frontmatter каждого `.openclaw/agents/*.md` остаётся валидным YAML, сохраняет
`name`==роль и непустой `description`, и НЕ содержит ключа `model:`
(`tests/test_agent_frontmatter_no_model.py` остаётся зелёным).
## 4. Изменения API
Нет. Эндпоинты не добавляются/не меняются.
## 5. Изменения схемы БД
Нет. Миграции/таблицы/индексы не трогаются.
## 6. Требования к новым/изменённым QG checks
Нет. `QG_CHECKS`, `check_*`, `_parse_*`, `STAGE_TRANSITIONS` — без изменений.
`frontmatter_validation_strict` остаётся `False` (warning-only) — hard-fail НЕ включается.
## 7. Совместимость / регресс
- **Обратная совместимость гейтов:** схема эмитится аддитивно; machine-verdict ключи (имя,
регистр) неизменны → все 5 вердикт-парсеров читают как раньше (NFR-1).
- **Без kill-switch:** изменение чисто текстовое (промпты + доки); поведение кода идентично.
- **Обратимость:** `git revert` PR; нет миграций/состояния.
- **Тесты:** добавляются структурные тесты промптов (присутствие 5 XML-секций; присутствие
инструкции по 6 полям схемы; присутствие сохранённых machine-verdict ключей и ключевых
маркеров анти-регресса). Существующий `test_agent_frontmatter_no_model.py` остаётся зелёным;
полный `pytest tests/ -q` — зелёный.
- **A/B (BR-6):** на ≥1 репрезентативной стадии сравнить выход старого vs нового промпта;
критерий — новый не увеличивает число циклов `REQUEST_CHANGES` и не теряет содержания
артефакта. Метод фиксирует архитектор/исполнитель (напр. прогон одной стадии в staging /
ручное сравнение артефактов на эталонной задаче).

View File

@@ -0,0 +1,133 @@
# 03 — Критерии приёмки (Acceptance Criteria): ORCH-077 — ORCH-52d: оптимизация 6 системных промптов по Anthropic
Work Item: **ORCH-077** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
(что считается провалом). Reviewer/tester проверяют их буквально по файлам репозитория.
---
## AC-1 — Единый XML-стиль во всех 6 промптах
**Условие:** Все 6 файлов `.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md`
переписаны единым каноном с XML-секциями.
- **PASS:** Тело каждого из 6 промптов содержит все 5 обязательных секций-тегов: `<context>`,
`<task>`, `<deliverables>`, `<constraints>`, `<output_format>` (открывающий и закрывающий тег).
- **FAIL:** Хотя бы в одном промпте отсутствует одна из 5 секций, ИЛИ структура осталась прежней
свободной формой без XML-разметки.
---
## AC-2 — Инструкция эмитить обязательную frontmatter-схему 52c
**Условие:** Каждый промпт явно инструктирует агента проставлять 6 обязательных полей схемы
(`work_item`, `stage`, `author_agent`, `status`, `created_at`, `model_used`) в авторских документах.
- **PASS:** В секции `<output_format>` каждого из 6 промптов перечислены ВСЕ 6 имён полей схемы;
для роли указаны конкретные значения `stage` (стадия роли) и `author_agent` (роль) согласно
карте TRZ §FR-2; `model_used` привязан к резолву ORCH-41 (`claude-opus-4-8`).
- **FAIL:** В любом промпте отсутствует хотя бы одно из 6 имён полей, ИЛИ `author_agent`/`stage`
не конкретизированы для роли, ИЛИ инструкция отсутствует вовсе.
---
## AC-3 — Few-shot и позитивные примеры рядом с запретами
**Условие:** Каждый промпт ссылается на скелеты 52b и эталоны, запреты имеют позитивную альтернативу.
- **PASS:** Каждый из 6 промптов содержит (а) ссылку на `docs/_templates/` для своих документов;
(б) ссылку хотя бы на один эталонный work item (`ORCH-073` или `ORCH-088`); (в) минимум один
запрет, оформленный с позитивной альтернативой («делай Y вместо X» / «❌ … → ✅ …»).
- **FAIL:** В любом промпте нет ссылки на шаблоны, ИЛИ нет ссылки на эталон, ИЛИ запреты поданы
только негативно (без позитивной альтернативы ни в одном пункте).
---
## AC-4 — АНТИ-РЕГРЕСС: ни одна функциональная инструкция не потеряна
**Условие:** Все функциональные инструкции старых промптов перенесены в новые (инвентарь TRZ §FR-6).
- **PASS:** Для каждого промпта присутствуют все ключевые элементы инвентаря §FR-6, в частности
(минимальный машинно-проверяемый набор):
- **reviewer.md** содержит machine-key `verdict:` со значениями `APPROVED`|`REQUEST_CHANGES`
(UPPERCASE) и правило «вердикт читается только из frontmatter»; правило «src/ изменён, доки нет
→ REQUEST_CHANGES».
- **tester.md** содержит `result:` со значениями `PASS`|`FAIL` как машинный вердикт; алгоритм
pytest + smoke (`/health`,`/status`,`/queue`).
- **deployer.md** содержит `staging_status:` (`SUCCESS`|`FAILED`), `deploy_status:`
(`SUCCESS`|`FAILED`), canonical `docker exec orchestrator-staging … staging_check.py`,
идемпотентный merge-guard `pr_already_merged`, self-hosting-запрет «не рестартить 8500 изнутри»,
ORCH-061 waiver-логику.
- **analyst.md** содержит 4 deliverable (`01`/`02`/`03`/`04`), «использовать Write tool», формат
TRZ и test-plan.
- **architect.md** содержит ADR-формат, правило сквозного ADR, self-hosting-запрет «без рестарта
прода без staging», эскалацию.
- **developer.md** содержит TDD-алгоритм, «документация в том же PR», запреты (не мержить свой PR,
без `--no-verify`/`--force-push`, не рестартить прод, не коммитить секреты).
- **FAIL:** Любой элемент инвентаря §FR-6 отсутствует или искажён (изменён регистр/имя
machine-verdict ключа; пропал self-hosting-запрет; пропал merge-guard; пропала canonical-команда).
---
## AC-5 — Код не изменён, гейты нетронуты
**Условие:** Правятся только `.openclaw/agents/*.md` + документация; код и контракты гейтов не тронуты.
- **PASS:** `git diff` затрагивает ТОЛЬКО `.openclaw/agents/*.md`, `CLAUDE.md`,
`docs/**`, `CHANGELOG.md` и (новые) `tests/test_*prompt*`/`tests/test_*canon*`. Файлы
`src/config.py`, `src/agents/launcher.py`, `src/frontmatter.py`, `src/stages.py`,
`src/qg/checks.py`, `src/stage_engine.py` НЕ изменены. `frontmatter_validation_strict` остаётся
`False`.
- **FAIL:** Изменён любой файл `src/**`, ИЛИ затронут `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`, ИЛИ
включён hard-fail валидации схемы.
---
## AC-6 — A/B-проверка на репрезентативной стадии: «не хуже»
**Условие:** Проведено сравнение старого vs нового промпта минимум на одной стадии.
- **PASS:** В артефактах задачи (`13-test-report.md` и/или ADR/`12-review.md`) зафиксирован
результат A/B: новый промпт даёт артефакт не хуже старого — число циклов `REQUEST_CHANGES` не
выросло, обязательные элементы артефакта присутствуют, машинный вердикт корректно парсится.
- **FAIL:** A/B не проводилось/не зафиксировано, ИЛИ новый промпт показал регресс (больше циклов
REQUEST_CHANGES, потеря содержания, непарсимый вердикт).
---
## AC-7 — Документация обновлена
**Условие:** `CLAUDE.md`, `docs/architecture/README.md`, ADR и `CHANGELOG.md` обновлены в том же PR.
- **PASS:** Есть per-work-item ADR `docs/work-items/ORCH-077/06-adr/ADR-001-*.md`; `CLAUDE.md` и
`docs/architecture/README.md` отражают слой промптов 52d (эмиссия схемы); `CHANGELOG.md` содержит
запись под `## [Unreleased]`.
- **FAIL:** Отсутствует ADR, ИЛИ README/CLAUDE.md не упоминают 52d-изменение, ИЛИ нет записи в
CHANGELOG.
---
## AC-8 — Валидность frontmatter промптов сохранена
**Условие:** YAML-frontmatter каждого промпта валиден и не возвращает `model:`.
- **PASS:** `tests/test_agent_frontmatter_no_model.py` зелёный: каждый frontmatter парсится как
YAML-mapping, `name`==роль, `description` непуст, ключа `model:` нет.
- **FAIL:** Любой промпт сломал YAML-frontmatter, потерял `name`/`description`, ИЛИ вернул `model:`.
---
## AC-9 — Полный регресс тестов зелёный
**Условие:** Изменение не ломает существующий набор тестов.
- **PASS:** `pytest tests/ -q` зелёный; новые структурные тесты промптов проходят.
- **FAIL:** Любой тест падает.
---
## Сводная матрица AC ↔ FR/BR
| AC | Покрывает |
|----|-----------|
| AC-1 | BR-1 / FR-1 |
| AC-2 | BR-2 / FR-2 |
| AC-3 | BR-3 / FR-3 |
| AC-4 | BR-4 / FR-6 / NFR-2 |
| AC-5 | BR-5 / TRZ §4§6 |
| AC-6 | BR-6 / FR-7(A/B) |
| AC-7 | BR-7 |
| AC-8 | NFR-3 / FR-7 |
| AC-9 | NFR-1 / TRZ §7 |

View File

@@ -0,0 +1,77 @@
work_item: ORCH-077
title: "ORCH-52d — канон Anthropic + эмиссия frontmatter-схемы в 6 промптах агентов"
framework: pytest
scope: >
Структурная верификация 6 системных промптов (.openclaw/agents/*.md): наличие XML-секций,
инструкции эмитить обязательную frontmatter-схему 52c, сохранение machine-verdict ключей и
ключевых анти-регресс маркеров, валидность YAML-frontmatter. Вне покрытия: семантическое
качество выхода агентов (оценивается A/B-проверкой вручную, TC-09) и любая логика src/
(код не меняется).
notes: >
Задача docs/prompts-only — src/ не трогается. Тесты читают файлы .openclaw/agents/*.md как
текст/YAML. Существующий tests/test_agent_frontmatter_no_model.py (ORCH-074) ОБЯЗАН остаться
зелёным. Полный регресс pytest tests/ -q должен оставаться зелёным. Имена тест-функций/файла —
ориентир; точную реализацию определяет developer (например tests/test_agent_prompts_canon.py).
Списки обязательных секций/полей/ключей вынести в параметризацию, чтобы тест шёл по всем 6
ролям единообразно.
tests:
- id: TC-01
type: unit
description: "Каждый из 6 промптов содержит все 5 XML-секций (<context>/<task>/<deliverables>/<constraints>/<output_format>), открывающий и закрывающий тег. (AC-1)"
module: tests/test_agent_prompts_canon.py
expected: PASS
- id: TC-02
type: unit
description: "Каждый промпт перечисляет все 6 имён полей схемы 52c (work_item/stage/author_agent/status/created_at/model_used) в теле. (AC-2)"
module: tests/test_agent_prompts_canon.py
expected: PASS
- id: TC-03
type: unit
description: "Для каждой роли в промпте присутствуют корректные конкретные значения author_agent (==роль) и stage (стадия роли по карте FR-2). (AC-2)"
module: tests/test_agent_prompts_canon.py
expected: PASS
- id: TC-04
type: unit
description: "Каждый промпт ссылается на docs/_templates/ и хотя бы на один эталон (ORCH-073 или ORCH-088). (AC-3)"
module: tests/test_agent_prompts_canon.py
expected: PASS
- id: TC-05
type: unit
description: "АНТИ-РЕГРЕСС machine-verdict ключей: reviewer.md содержит 'verdict:' (APPROVED|REQUEST_CHANGES), tester.md — 'result:' (PASS|FAIL), deployer.md — 'staging_status:' и 'deploy_status:' (SUCCESS|FAILED), регистр сохранён. (AC-4)"
module: tests/test_agent_prompts_canon.py
expected: PASS
- id: TC-06
type: unit
description: "АНТИ-РЕГРЕСС deployer self-hosting: deployer.md содержит canonical 'docker exec orchestrator-staging' staging-команду, merge-guard 'pr_already_merged', запрет рестарта 8500 изнутри, ORCH-061 'INFRA-WAIVED'. (AC-4)"
module: tests/test_agent_prompts_canon.py
expected: PASS
- id: TC-07
type: unit
description: "АНТИ-РЕГРЕСС ключевых маркеров остальных ролей: analyst — 4 deliverable + Write tool; architect — ADR-формат + сквозной ADR + эскалация; developer — TDD + 'не мержить свой PR' + 'не рестартить прод'; reviewer — правило 'src изменён, доки нет → REQUEST_CHANGES'. (AC-4)"
module: tests/test_agent_prompts_canon.py
expected: PASS
- id: TC-08
type: unit
description: "Валидность frontmatter промптов: каждый .openclaw/agents/*.md парсится как YAML-mapping, name==роль, description непуст, ключа 'model:' нет (re-use существующего теста ORCH-074). (AC-8)"
module: tests/test_agent_frontmatter_no_model.py
expected: PASS
- id: TC-09
type: integration
description: "A/B-проверка на репрезентативной стадии (старый vs новый промпт): новый не хуже по числу циклов REQUEST_CHANGES и полноте артефакта; вердикт корректно парсится. Ручной/полуавтоматический прогон; результат фиксируется в 13-test-report.md. (AC-6)"
module: tests/manual/ab_prompt_compare.md
expected: PASS
- id: TC-10
type: integration
description: "Полный регресс: pytest tests/ -q зелёный (код не тронут, гейты и контракты целы). (AC-9)"
module: tests/
expected: PASS