Files
wiki/tasks/orchestrator/BACKLOG.md
2026-06-03 12:00:01 +03:00

12 KiB
Raw Blame History

Бэклог — Мультиагентная разработка ПО


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 <slug>), идемпотентный, с 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/<slug>/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/<id>/
  • Коммитит в 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)

  • Claude Code CLI установлен на mva154 (v2.1.142)
  • Gitea работает (v1.25.5)
  • Plane работает
  • Node.js на mva154 (v24.14.0)
  • Service account claude-bot в Gitea
  • Репо enduro-trails — каноническая структура
  • 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)