wiki/tasks/multi-agent/proposal_v1/10_launch_checklist.md

10. Чек-лист запуска

Назначение: последовательный список того, что должно быть сделано, чтобы перейти от «пакета документов» к работающему процессу — на одном пилотном проекте, а потом расшириться. Это не «теория», а конкретные шаги с явными артефактами на выходе каждого шага.

---

Простым языком

Запуск — за 6 недель, по неделям наращиваем функциональность. Сначала готовим инфраструктуру (1–2 нед), затем включаем агентов по одному и проверяем, что цепочка работает (3–5 нед), на 6-й — снимаем метрики и решаем о масштабировании на остальные проекты.

Плохой подход — «давайте сразу всех 7 агентов». Хороший — «по одному, на пилоте, каждый запуск с явной проверкой».

Пилотный проект — fr24-noisemap (как уже было предложено в analysis_implementation_options.md).

---

Вводные предположения

• Plane self-hosted уже поднят (если нет — это первый шаг).
• Forge — GitHub или Gitea (рекомендация: Gitea для контроля и стоимости).
• VPS под self-hosted сервисы (рекомендация: 4 CPU / 16 GB RAM / 200 GB SSD / Ubuntu 22.04 LTS / Docker).
• Anthropic API-ключ доступен.
• Один человек на роль DevOps/Owner на время запуска.

---

Чек-лист недели 1: фундамент инфраструктуры

П1.1. Поднять/проверить Plane

• Plane self-hosted работает
• HTTPS настроен (Let's Encrypt)
• Постgres резервируется ежедневно (docs/operations/backup-restore.md)
• Workspace создан (одна организация — все проекты)
• API-токен сгенерирован и сохранён в секретах CI
• Custom fields добавлены (см. 06_plane_integration.md)
• Лейблы созданы (см. 06_plane_integration.md)

П1.2. Поднять Forge (если не GitHub)

• Gitea / GitLab CE поднят
• Service account claude-bot создан, SSH-ключ + PAT настроены
• GPG-ключ для подписи коммитов (опц.)
• Webhooks настроены на Orchestrator URL

П1.3. Поднять Orchestrator

• Репозиторий internal/orchestrator создан
• Базовый FastAPI/Express скелет (~150 строк): endpoint /webhook/plane, /webhook/forge, /health
• Postgres-схема для журнала событий (см. 08_interaction_protocol.md)
• Деплой Orchestrator'а на VPS (Docker Compose)
• HTTPS endpoint доступен из Plane и Forge

П1.4. Подготовить пилотный репо fr24-noisemap

• Привести к каноническому виду структуры (см. 02_repo_structure.md)
• Dockerfile, docker-compose.yml, docker-compose.test.yml
• Makefile с целями: dev, test, lint, build, deploy-test
• CLAUDE.md заполнен (см. шаблон в 02_repo_structure.md)
• docs/architecture/README.md + хотя бы базовый c4-context.mmd
• docs/runbook.md
• .env.example + миграции БД (если есть)
• .pre-commit-config.yaml
• tests/ структура: unit, integration, e2e, visual, fixtures, smoke

П1.5. Поднять test-окружение пилота

• VPS / контейнер test-окружения
• HTTPS на test.fr24-noisemap.example.com
• Ansible-плейбук деплоя (infra/ansible/deploy.yml)
• Healthcheck endpoint /health

Чем закрывается: один работающий пилотный репо, один работающий Plane, один работающий Orchestrator, одно работающее test-окружение.

---

Чек-лист недели 2: CI/CD и preview

П2.1. CI pipeline

• .github/workflows/ci.yml (или Gitea-аналог) — линт+тип+тест+build
• Coverage reporting (make coverage)
• Security-scan (Trivy + bandit/npm-audit)
• Spec-linter, ADR-linter, naming-check скрипты в scripts/
• req-coverage.py скрипт

П2.2. Branch protection

• На main: required status checks, no force push, no merge-commit, signed commits (если включено)
• Service account для агентов имеет push-права на feature/*, не на main

П2.3. Ephemeral preview

• preview.yml workflow поднимает stack через Docker Compose
• nginx-reverse-proxy с wildcard *.preview.example.com
• Скрипт wait-healthy.sh
• При закрытии PR — автоматическое удаление preview

П2.4. Deploy pipelines

• deploy-test.yml на push в main
• deploy-prom.yml на тег + approve
• nightly.yml cron 02:00 UTC
• semver-from-commits скрипт

П2.5. Plane MCP-сервер

• Если официальный есть — подключить
• Если нет — написать тонкую обёртку (~150 строк Python) над Plane REST API, экспонировать как MCP-сервер согласно контракту в 08_interaction_protocol.md
• Проверить из Claude Code CLI: plane_get_work_item, plane_update_status работают

Чем закрывается: PR → CI зелёный → preview работает → merge в main → авто-деплой в test → smoke-тесты зелёные. Без агентов, чисто инфраструктурный pipeline.

---

Чек-лист недели 3: Analyst

П3.1. Subagent definition

• .openclaw/agents/analyst.md — копия из 05_agent_system_prompts.md
• Параметризация: {{plane_id}}, {{project_name}}
• Allowed tools: Plane MCP, Filesystem (только docs/work-items/{{plane_id}}/), Bash (read-only Git)

П3.2. Webhook-обработка work_item.created

• Plane → Orchestrator: при создании Feature
• QG-0 проверка
• Создание ветки в Git через Forge MCP
• Создание 7 подзадач через Plane API
• Создание docs/work-items/<id>/00-business-request.md
• Запуск Analyst через claude --agent analyst <id> или эквивалентный API-вызов

П3.3. QG-1 проверки

• Скрипт scripts/lint-spec.sh готов
• Скрипт scripts/lint-test-plan.sh (валидация YAML по схеме)
• Скрипт scripts/req-coverage.py
• Скрипт scripts/check-reaction.py (через Plane API)
• CI workflow qg-analysis.yml

П3.4. Тестовый прогон

• Создать тестовый Work Item «Add new noise zone toggle» через Plane UI
• Проверить: ветка создаётся, подзадачи создаются, BR-файл создаётся, Analyst запускается
• Проверить: Analyst задаёт вопросы; ответить через Plane comment; Analyst пишет BRD/ТЗ/AC/TestPlan
• Проверить: QG-1 валидирует артефакты
• Поставить :approved:; проверить переход на следующий этап (но без Architect ещё — просто меняется статус)

Чем закрывается: живой Analyst производит ТЗ по живому запросу, QG-1 проверяет.

---

Чек-лист недели 4: Architect + Developer

П4.1. Architect subagent

• .openclaw/agents/architect.md готов
• Mermaid CLI установлен на Orchestrator/CI
• Скрипт scripts/render-mermaid.sh
• Скрипт scripts/lint-adr.sh
• CI workflow qg-arch.yml
• Webhook: при QG-1 ✅ → запуск Architect

П4.2. Developer subagent

• .openclaw/agents/developer.md готов
• Allowed tools: Forge MCP (создание PR), Git (commit/push), Bash (test runners)
• PR template (.github/PULL_REQUEST_TEMPLATE.md)
• CI запускает QG-4 на PR
• Webhook: при QG-2 ✅ (или QG-3 если UI) → запуск Developer

П4.3. Тестовый прогон

• Завести Work Item «add /api/health endpoint» (тривиальная задача без UI)
• Прогнать: Analyst → QG-1 → Architect → QG-2 → Developer → QG-4
• Получить открытый PR с зелёным CI
• Проверить, что артефакты лежат в правильных местах

Чем закрывается: end-to-end от запроса до зелёного PR — без человеческого участия в самой работе (только approve).

---

Чек-лист недели 5: Reviewer + Tester + Designer

П5.1. Reviewer subagent

• .openclaw/agents/reviewer.md готов
• Forge MCP с правом оставлять review
• CI workflow qg-review.yml
• Webhook: при QG-4 ✅ → запуск Reviewer
• Защита: orchestrator не запускает Reviewer в той же сессии, что Developer

П5.2. Tester subagent

• .openclaw/agents/tester.md готов
• Playwright MCP подключён
• Скрипт scripts/run-test-plan.py готов
• Visual baseline'ы созданы для пилота
• axe-core интегрирован
• Lighthouse CI настроен
• CI workflow qg-test.yml
• Webhook: при QG-5 ✅ → лейбл stage:test → запуск Tester

П5.3. Designer subagent (опц., можно отложить)

• .openclaw/agents/designer.md готов
• docs/design/design-tokens.json для пилота
• docs/design/components.md (хотя бы 5–10 базовых)
• CI workflow qg-design.yml
• Webhook: при QG-2 ✅ + ui_affected=true → запуск Designer

П5.4. Тестовый прогон с UI

• Завести Work Item с UI-составляющей
• Прогнать полный конвейер до Tester
• Получить зелёный test-report

Чем закрывается: полный 7-агентный конвейер работает от запроса до stage:ready-to-deploy.

---

Чек-лист недели 6: Deployer + метрики + ретроспектива

П6.1. Deployer subagent

• .openclaw/agents/deployer.md готов
• infra/ansible/deploy.yml с обработкой test и prom
• scripts/rollback.sh
• scripts/check-metrics.sh (Prometheus query)
• CI workflow deploy-test.yml, deploy-prom.yml
• Webhook: при QG-6 ✅ → запуск Deployer

П6.2. Прод-инфра

• Prom-окружение готово (отдельный VPS / контейнер)
• HTTPS, healthcheck, мониторинг (Prometheus + Grafana)
• Алёрты на Telegram/Slack/email
• Smoke-тесты на prom (минимальный набор)
• Runbook rollback'а отрепетирован руками (не агентом)

П6.3. Дашборды

• DORA-метрики (Lead Time, Deploy Frequency, CFR, MTTR) — Grafana
• Cost dashboard (USD/задача, USD/день) — Grafana или Streamlit
• QG pass-rate, retry-count, override-count — Grafana
• Plane Views: текущая работа, витрина, backlog, health (см. 06_plane_integration.md)

П6.4. Финальная end-to-end проверка

• Завести Work Item с полноценной UI-фичей
• Прогнать через все 7 этапов до Done
• Снять метрики: tokens spent, lead time, retry count
• Записать ретроспективу в docs/operations/retrospectives/2026-week-6.md

П6.5. Принять решение о масштабировании

• Если метрики ОК: tokens < $25/задача, lead time < 24ч, intervention rate < 50%, retry < 2 в среднем — расширять на следующий проект
• Если метрики не ОК — диагностика и итерация

Чем закрывается: живая фича прошла от запроса до prom за разумное время и стоимость, метрики собраны.

---

Что готовить заранее (до недели 1)

Секреты

• ANTHROPIC_API_KEY (для Sonnet, Opus, Haiku)
• OPENROUTER_API_KEY (опционально, для GLM/Qwen) или endpoint Ollama / vLLM
• PLANE_API_TOKEN
• GITEA_TOKEN или GITHUB_TOKEN
• ORCHESTRATOR_WEBHOOK_SECRET
• SSH-ключ service account
• Ansible Vault password
• Prometheus credentials

Все хранятся в CI secrets и в Ansible Vault. Никогда не в репо.

Доменные имена

• plane.example.com
• git.example.com (если Gitea)
• orchestrator.example.com
• *.preview.example.com (wildcard)
• test.<project>.example.com
• <project>.example.com (prom)

Учётные записи и роли

• Все участники команды добавлены в Plane workspace
• Роли распределены: Owner, Admin, Stakeholder, Member, Viewer
• Stakeholder — кто может ставить :approved:
• Owner — кто может разрешать override

Бюджет на LLM

• Согласованный месячный лимит на Anthropic API (Cost Limit в console.anthropic.com)
• Согласованный per-task budget (.openclaw/budget.yaml)

---

Финальная проверка консистентности пакета

Прошёл по всем 11 файлам и проверил:

• Иерархия Plane. Везде согласовано: Workspace → Project → Phase (опц.) → Feature (с 7 подзадачами); глубина 1 уровень.
• Названия этапов. Один набор: Inception → Анализ → Архитектура → Дизайн → Разработка → Code Review → Тестирование → Внедрение.
• Quality Gates. Нумерация QG-0 … QG-7 + QG-final. Описаны во всех релевантных файлах одинаково.
• Артефакты. Имена файлов (01-brd.md, 02-trz.md …) согласованы между 01_production_process.md, 02_repo_structure.md, 03_quality_gates.md, 05_agent_system_prompts.md.
• Лейблы. stage:*, back-to:*, skip:*, escalation:*, incident:* — единый словарь.
• Reactions. :approved:, :rejected:, :break-glass:, :final-approved: — единый словарь, везде те же роли.
• Модели LLM. Sonnet 4.6 / Opus 4.7 / Qwen 3.6+ / GLM-5.1 — везде одинаково. Ревьюер всегда Opus, архитектор всегда Opus.
• Изоляция Reviewer ≠ Developer. Прописано в 04_agents_roles.md, 05_agent_system_prompts.md, 08_interaction_protocol.md.
• Branch naming. feature/<plane-id>-<slug> везде согласовано.
• Conventional Commits. Формат и список типов согласованы между 02_repo_structure.md и 07_git_workflow.md.
• MCP-tools. Контракт в 08_interaction_protocol.md совпадает с использованием в 04_agents_roles.md и 05_agent_system_prompts.md.
• Окружения. dev / preview / test / prom — везде одинаково. Принцип «один Docker, разница только в данных» прописан.
• UI-тестирование. Уровни тестов в 09_ui_testing.md согласованы с QG-6 в 03_quality_gates.md и с обязанностями Tester в 04/05.

---

Известные сложности и где их решить позже

Сложность	Описание	Когда решать
Plane MCP-сервер	Может не быть готового; писать обёртку	Неделя 2
Стоимость Opus	Архитектор + Reviewer на Opus — самая дорогая часть	Мониторить с недели 6, оптимизировать prompt caching
Visual regression baseline'ы	На старте baseline'ов нет — первый прогон создаст. Команда должна привыкнуть к процедуре «обновить baseline = намеренное действие»	Неделя 5 (Tester)
Flaky e2e	Появятся со временем; нужна процедура карантина	Неделя 5+
Prompt caching	Использовать для CLAUDE.md и часто читаемых ADR	С недели 3
Локальные LLM (Qwen, GLM)	Удешевление; нужно поднять Ollama / vLLM	Опционально с недели 4, если бюджет позволяет
Onboarding новых проектов	После пилота — как масштабировать на остальные 19 проектов	После недели 6, отдельным runbook'ом

---

Roll-out на остальные проекты (после пилота)

После успешного пилота: runbook миграции существующего проекта (≈4 часа на проект):

1. Привести структуру к канону (02_repo_structure.md).
2. Сделать CLAUDE.md.
3. Импортировать минимальные C4 + 2–3 базовых ADR.
4. Подключить .openclaw/agents/ (копия с пилота).
5. Подключить webhooks Plane и Forge.
6. Настроить CI (ci.yml, preview.yml, deploy-test.yml).
7. Запустить тестовую Feature через конвейер.
8. По итогам — внести проектные особенности в CLAUDE.md.

Ожидаемая нагрузка: 1 проект в неделю (после пилота). Полная миграция всех 20 проектов — ≈5 месяцев.

---

Финальный итог пакета

После прохождения всех чек-листов вы получаете:

1. Жёсткий, повторяемый процесс разработки ПО с 7 этапами и автоматическими QG.
2. Каждое изменение документировано (BRD, ТЗ, ADR, дизайн, отчёт о тестах, deploy log) и доступно в Plane как «витрина», в Git как источник правды.
3. 7 специализированных агентов с готовыми системными промптами, корректными границами ответственности, защитой от само-согласования.
4. Полное автотестирование, включая UI (e2e + visual + a11y + perf + security).
5. Воспроизводимые среды dev/preview/test/prom с автоматическим деплоем через CI.
6. Метрики (DORA + агентные + cost) с дашбордами.
7. Audit trail всех действий агентов и QG-проверок.

Что вы делаете как Stakeholder:

• Заводите Work Item в Plane.
• Отвечаете на уточняющие вопросы Analyst'а.
• Ставите :approved: на ТЗ, дизайне, и финальном деплое.

Всё остальное — агенты + CI + Plane.