# Бэклог — Мультиагентная разработка ПО --- type: backlog updated_at: 2026-06-03 --- ## EPIC: E2E онбординг нового проекта (03.06.2026) **ORCH-10** · тип: **Epic / Decomposition** · приоритет: средний-высокий · статус: бэклог **Цель:** одной командой / одним действием разворачивать новый проект в конвейере: от пустоты до «Слава заводит Work Item → агенты работают под своими именами» без ручных правок в БД/конфигах. Сейчас онбординг — ручной и разбросанный (БД Plane, Gitea, реестр, вебхуки), легко забыть шаг (напр. боты → 403). **Предлагаемый результат:** CLI/эндпоинт `onboard_project` (напр. `POST /admin/onboard-project` или `python -m src.onboard `), идемпотентный, с dry-run и проверкой каждого шага. ### Шаги онбординга (декомпозиция — кандидаты в подзадачи): 1. **Plane: проект** — создать (или принять существующий), получить `project_id`, `slug`, префикс (`ET-`, `ORCH-` …). 2. **Plane: states** — убедиться что есть нужные состояния (Backlog/In Progress/In Review/Needs Input/Done…), под которые завязан stage-engine. Сопоставить state_id ↔ стадия. 3. **Plane: боты в project_members** — добавить 7 сервис-ботов (role 15), иначе 403 на комменты. Это **бывшая ORCH-9** (см. ниже — вошла в этот эпик). 4. **Gitea: репо** — создать репозиторий (или принять), каноническая структура (`docs/work-items/`, `CLAUDE.md`, CI workflow lint+test+build), service account `claude-bot` с доступом, branch protection на main. 5. **Реестр ORCH-6** — записать в `src/projects.py` маппинг `project_id → repo + prefix`, чтобы webhook-фильтр пропускал новый проект и resolve repo работал. (Без этого webhook игнорит unknown-проект — защита от ET-009-инцидента.) 6. **Вебхуки** — Plane webhook → `/webhook/plane` (HMAC-secret), Gitea webhook → `/webhook/gitea`. Проверить is_active, секреты в .env. 7. **Деплой-хук** — если проект деплоится, завести deploy-hook по образцу enduro (с бэкапами/откатом). 8. **Документация + онтология** — `tasks//PROJECT.md`, запись Project в онтологию (`folder`, `doc_path`), `wiki ingest`. 9. **Smoke-проверка** — создать тестовый Work Item → пройти хотя бы 1 стадию → бот пишет коммент (201, автор = бот) → убрать тест. ### Решить на этапе ТЗ: - Один эндпоинт/команда или пайплайн из шагов? (склоняюсь к одной идемпотентной команде `onboard_project` с флагами). - Что обязательно авто, что — полуручное с подтверждением (создание Gitea-репо — рисковано?). - Где хранить реестр проектов — `src/projects.py` (код) или БД/конфиг (чтобы не деплоить ради нового проекта). - Роль Славы в новом проекте (админ) — добавлять авто? **Связи:** включает ORCH-9 (боты в project_members). Опирается на ORCH-6 (реестр проектов) и Plane per-agent authorship (PR #9). **Источники:** `memory/2026-06-03.md`, `src/projects.py`, `DEV_TASK_PLANE_PER_AGENT_AUTHOR.md`, `PROGRESS_2026-06-02.md` (ORCH-6 multi-repo). --- ## TODO: Plane — авто-добавление ботов в новый проект (03.06.2026) **ORCH-9** · подзадача ORCH-10 (шаг 3) · приоритет: средний · родитель: задача **Plane per-agent authorship** (PR #9 `e9fd3052`, замержена 03.06). **Проблема:** 7 сервис-ботов орка (🧠 Analyst / 🏗️ Architect / 💻 Developer / 🔍 Reviewer / 🧪 Tester / 🚀 Deployer / 🌊 Стрим) добавлены в `project_members` только текущего проекта enduro (`7a79f0a9-...`). При создании НОВОГО проекта в Plane боты в нём не состоят → POST коммента вернёт **403 Forbidden** (аутентификация ок, прав нет). Авторство сломается на новом проекте. **Решение:** автоматически добавлять 7 ботов в `project_members` (role 15) при появлении нового проекта. Точка интеграции — resolve проекта в ORCH-6 (`src/projects.py` / реестр Plane id→repo): когда оркестратор впервые видит новый project_id, дёрнуть «ensure bots in project». Идемпотентно (`NOT EXISTS`). **Грабли (зафиксированы 03.06):** - `project_members` NOT NULL: `member_id` обязателен (без него INSERT падает молча в транзакции). - Боты должны быть И в `workspace_members`, И в `project_members` — членство в воркспейсе само по себе НЕ даёт права комментить в проекте. - Связь автор↔токен: `issue_comments.actor_id` = владелец `api_tokens.token`. **Done when:** новый проект → боты авто-добавлены → коммент любого бота возвращает 201, автор в Plane = бот (не mva154). **Источники:** `memory/2026-06-03.md` (раздел «Plane per-agent authorship»), ТЗ `DEV_TASK_PLANE_PER_AGENT_AUTHOR.md`. --- ## Решения (19.05.2026) ### Analyst — пересмотр архитектуры **Было:** Analyst = Стрим (OpenClaw main agent), работает как посредник. **Стало:** Analyst = **отдельный полноценный агент OpenClaw** (не субагент). **Ключевые решения:** - Analyst — первоклассный агент в `agents.list[]`, равноправен с main - Слава общается с Analyst **напрямую** (не через Стрим) - Каналы связи: **отдельный Telegram-чат** + **Plane** (комментарии) - Модель: `anthropic/claude-sonnet-4-6` (API, не CLI) - Свой workspace, своя память, свои сессии **Поведение:** 1. Получает задачу от Славы (Telegram или Plane) 2. Читает `00-business-request.md` + `CLAUDE.md` проекта 3. Если неясности → формирует вопросы, останавливается, ждёт ответа 4. Пишет BRD, ТЗ, AC, Test Plan 5. Коммитит в feature-ветку 6. Запрашивает approve у Славы **Правила:** - ❌ Не пишет код - ❌ Не трогает архитектуру, дизайн, ADR - ❌ Не закрывает задачу без `:approved:` от Славы - ❌ Не угадывает — спрашивает - ✅ Читает весь репо (контекст) - ✅ Пишет только в `docs/work-items//` - ✅ Коммитит в feature-ветку - ✅ Обновляет статусы в Plane **Поток:** ``` Слава (Telegram) ──────► Analyst agent Слава (Plane comment) ──► Analyst agent (через webhook) Analyst ──► Git (коммит в feature-ветку) Analyst ──► Plane (статус, комментарии) Analyst ──► Слава (ответ в Telegram / Plane) ``` Стрим в цепочке НЕ участвует — Analyst автономен. --- ## TODO: Analyst agent - [ ] Решить: тот же Telegram-бот (binding по peer) или отдельный бот? - [ ] Решить: Plane webhook сразу или пока руками? - [ ] Решить: первый проект — enduro-trails? - [ ] Добавить `analyst` в `agents.list[]` в openclaw.json - [ ] Создать workspace `~/.openclaw/workspace-analyst/` с AGENTS.md (промпт из proposal) - [ ] Настроить Telegram binding - [ ] Дать доступ к Gitea (SSH key или token для `claude-bot`) - [ ] Дать `PLANE_API_TOKEN` в env агента - [ ] Написать скилл `plane-api` (или использовать exec curl) - [ ] Тестовый прогон: создать Work Item → Analyst пишет BRD --- ## TODO: Инфраструктура (из ревью 18.05) - [x] Claude Code CLI установлен на mva154 (v2.1.142) - [x] Gitea работает (v1.25.5) - [x] Plane работает - [x] Node.js на mva154 (v24.14.0) - [x] Service account `claude-bot` в Gitea - [x] Репо enduro-trails — каноническая структура - [x] CI workflow (lint + test + build) - [ ] Проверить авторизацию Claude CLI (`claude auth status`) - [ ] Проверить Gitea Actions runner (работает ли?) - [ ] Настроить branch protection на main - [ ] Plane webhooks → endpoint --- ## TODO: Orchestrator (Фаза 2) - [ ] FastAPI скелет: `/webhook/plane`, `/webhook/gitea`, `/health` - [ ] QG-проверки (lint-spec, req-coverage, reaction check) - [ ] Запуск агентов по событиям - [ ] Репо `admin/agent-dev` — заполнить кодом --- ## TODO: Тестирование / аудит (24.05.2026) - [ ] Определить тип Work Item для чистого тестирования (Audit / Regression или Feature+skip:*) - [ ] Описать YAML-схему Test Plan (чтобы Tester agent мог исполнять автономно) - [ ] Обновить `proposal_v1/09_ui_testing.md` под сценарий «регресс без новой фичи» - [ ] Прописать как Tester agent запускает Playwright + vision + формирует отчёт - [ ] Добавить тип `Audit` в список типов Work Item в `06_plane_integration.md` --- ## TODO: Управление бэклогом (24.05.2026) - [ ] Решить: кто и куда заводит задачи (Слава → Plane / через Analyst / через Стрим) - [ ] Описать правила декомпозиции крупных фич (тип `Decomposition`, когда и как) - [ ] Прописать правила работы с backlog (приоритет, эпик/фаза, когда заводить Phase) - [ ] Решить: кто обновляет статусы в Plane (Analyst? Orchestrator?) - [ ] Решить: Plane — единственный источник backlog'а или нужно отдельное хранилище --- ## TODO: Остальные агенты (после Analyst) - [ ] Architect (Claude CLI, Opus) - [ ] Developer (Claude CLI, Sonnet) - [ ] Reviewer (Claude CLI, Opus) - [ ] Tester (Claude CLI, Sonnet) - [ ] Deployer (Claude CLI, Sonnet)