# 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 файлам и проверил:

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