75 lines
4.7 KiB
Markdown
75 lines
4.7 KiB
Markdown
# Анализ: 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 — единственный источник
|