# Анализ: Plane — что должно быть + чего не хватает

---
updated_at: 2026-05-24
author: Слава
---

## 1. Что должно быть в Plane согласно proposal

Иерархия (из `proposal_v1/06_plane_integration.md`):

- **Workspace** — один на всю компанию
- **Project** = один репозиторий (например, `enduro-trails`)
- **Work Item** типа `Feature` (или `Bug` / `Tech-debt`) — основная задача
- **7 подзадач (Subtasks)** на каждой Feature:

| № | Subtask | Кто выполняет | Артефакт |
|---|---------|---------------|----------|
| 1 | Анализ | Analyst | BRD + ТЗ + Test Plan + AC (Gherkin) |
| 2 | Архитектура | Architect | ADR + C4 + требования к данным/инфраструктуре |
| 3 | Дизайн UI/UX | Designer (пока вне пилота) | Макеты (или `skip:not-applicable`) |
| 4 | Разработка | Developer | Код + unit-тесты + PR |
| 5 | Code Review | Reviewer | Approve / Request changes |
| 6 | Тестирование | Tester | Отчёт о прогоне e2e/UI-тестов + регресс |
| 7 | Внедрение | Deployer | Деплой в test → пром, smoke-тест |

**Дополнительно proposal требует:**
- Custom fields на Work Item (`qg_status`, `repo_branch`, `repo_pr`, `tokens_spent_usd`, `ui_affected` и т.д.)
- Labels (`stage:*`, `type:*`, `area:*`, `back-to:*`, `qg-blocked` и т.д.)
- Reactions (`:approved:`) как механизм согласования
- Webhooks Plane → Orchestrator

---

## 2. Чего не хватает прямо сейчас (критическое)

1. **Analyst agent** ещё не создан (ни в `agents.list[]`, ни как отдельный агент с workspace)
2. **Нет скилла `plane-api`** (или MCP)
3. **Нет Plane webhooks → Orchestrator**
4. **Нет синхронизации статусов** Plane ↔ Git (оркестратор не обновляет подзадачи)
5. **Нет Test Plan** как machine-readable артефакта (proposal требует YAML с тест-кейсами, которые Tester может исполнить)
6. **Нет Tester agent** (Claude Code CLI + скилл для запуска UI-тестов через Playwright + vision)
7. **Отсутствует сценарий «полный тест UI без новой фичи»** — proposal описывает только конвейер от постановки фичи

---

## 3. Сценарий «полный тест UI без новой фичи» по proposal

Proposal не предусматривает отдельный упрощённый путь. Даже для аудита/регресса:
- Нужно создать Work Item (тип `Feature` или `Spike` с меткой `type:tech-debt`)
- Analyst пишет/обновляет Test Plan (даже если фичи нет)
- Tester agent берёт этот Test Plan и прогоняет
- Всё равно проходят Quality Gates

**Альтернатива** (которую proposal не описывает, но логично добавить):
- Отдельный Work Item типа `Audit` / `Regression` c урезанным конвейером: только Анализ → Тестирование

---

## 4. Что реально нужно добавить в бэклог (два пункта)

### 4.1 Тестирование / аудит — проработать:
- Как выглядит Work Item для чистого тестирования (тип, лейблы, custom fields)
- Нужен ли отдельный `Audit` тип или использовать `Feature + skip:*`
- Формат Test Plan (YAML-схема), чтобы Tester agent мог его исполнять автономно
- Как Tester agent запускает UI-тесты (playwright + vision + отчёт)
- Обновление `09_ui_testing.md` под этот сценарий

### 4.2 Управление бэклогом — проработать:
- Кто и куда заводит задачи (Слава напрямую в Plane / через Analyst / через Стрим)
- Как декомпозировать крупные фичи (тип `Decomposition`)
- Правила работы с backlog (приоритет, эпик/фаза, когда заводить Phase)
- Кто обновляет статусы (Analyst? Orchestrator?)
- Нужно ли отдельное хранилище backlog'а или Plane — единственный источник