admin/wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6f90f79bffd2fa3bf47250afb7178b5f0a6a605c
wiki/tasks/orchestrator/BACKLOG.md
Stream 6f90f79bff auto-sync: 2026-06-04 16:20:01
2026-06-04 16:20:01 +03:00

16 KiB
Raw Blame History

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

type: backlog updated_at: 2026-06-04

🐛 Баги (2026-06-04, живой прогон ET-013)

✅ BUG-TESTS-SUBSTRING · гейт тестов пропускал BLOCKED · СТАТУС: ✅ ИСПРАВЛЕН (PR #24, 83f5020f, на проде)

  • Приоритет: высокий (системный — подрывал автономность конвейера).
  • Симптом: ET-013/ET-8 недоделана, но доехала до Done → «по-прежнему мелко» на проде.
  • Корень: check_tests_passed (qg/checks.py:139) делал if "PASS" in content. Тестер выставил verdict: BLOCKED, но в теле «23 passed» / «✅ PASS» → substring нашёлся → уехало в Done.
  • Решение (PR #24): _parse_tests_verdict читает машинный verdict:/status: из frontmatter. Negative-токены (BLOCKED/FAILED/FAIL/REQUEST_CHANGES/REJECT/RED) authoritative, перебивают positive (PASS/PASSED/READY-TO-DEPLOY/GREEN/APPROVED). 285 passed / 9 off-limits. ET-013→False, все прошедшие WI→True.
  • Источники: STATUS.md (Баг C), DEV_TASK_TESTS_VERDICT_FIX.md, reports/dev-2026-06-04-tests-verdict-fix.md.

🔴 BUG-ET8-TERRAIN-TILES · перепады высот мелкие на z9-z11 · СТАТУС: 🔴 ОТКРЫТ (ET-8 → Backlog)

  • Приоритет: средний (функциональная фича для пользователя).
  • Симптом (Слава): на проде перепады высот по-прежнему мелкие на z9-z11.
  • Диагноз: код zoom-aware paint (ET-013, app.js) ЗАДЕПЛОЕН правильно (hillshade с minzoom 9, HILLSHADE_PAINT/TRI_PAINT). НО: (1) тайлы hillshade z8-z9 НЕ сгенерированы (на диске /home/slin/enduro-trails/data/terrain/hillshade только z10-z15), фронт просит hillshade с z9 → пусто; (2) TRI деградирует по размеру z8=42KB → z11=4.7KB, выразительность слабая.
  • Что нужно: (1) догенерировать hillshade z8-z9 (PH-6 terrain pipeline, gdal2tiles на сервере); (2) проверить выразительность TRI на z9-z11 (возможно exaggeration на этапе рендера тайлов, не opacity на фронте). Уточнить у Славы: TRI или hillshade включал, когда видел «мелко».
  • Урок: ET-8 была ошибочно закрыта в Done по «deploy SUCCESS» без проверки реального результата (и при проваленном AC-19). Причина пропуска — BUG-TESTS-SUBSTRING (исправлен).
  • Источники: memory/2026-06-04.md, Plane ET-8 (коммент переоткрытия).

✅ BUG-DEPLOY-LOG-PATH · ложный FAILED деплоя (рассинхрон путей 14-deploy-log.md) · СТАТУС: ✅ ИСПРАВЛЕН (PR #23, 34894f46, на проде)

  • Приоритет: высокий (бьёт по каждому успешному деплою — ложный откат).
  • Симптом (ET-013): деплой РЕАЛЬНО успешен (тег v0.0.5, deploy-hook RC=0, healthcheck HTTP 200, фича живая в app.js), но QG завернул в FAILED → откат deploy→development.
  • Корень: deployer пишет 14-deploy-log.md (deploy_status: SUCCESS) и мержит артефакты в main через отдельный PR (#27, 4e925cc). QG check_deploy_status (src/qg/checks.py ~284) читает файл через _repo_path(repo, branch) из worktree ВЕТКИ ФИЧИ (/repos/_wt/.../feature_ET-013/docs/work-items/ET-013/), где есть 10/12/13, но нет 14 → «Deploy log not found» → FAILED.
  • НЕ трогать: merge-gate из PR #20 (gitea.py, current_stage==deploy) — он СРАБОТАЛ ПРАВИЛЬНО (без него фейк-done).
  • Решение (PR #23): новые _deploy_log_from_main + _parse_deploy_status в qg/checks.py. Порядок: worktree → git fetch origin main + git show origin/main:docs/work-items/<WI>/14-deploy-log.md на shared-клоне → not found. Любая git-ошибка → деградация (None), таймауты 30s/15s. 277 passed / 9 off-limits. merge-gate gitea.py НЕ тронут.
  • Источники: memory/2026-06-04.md, STATUS.md (раздел багов), tasks/orchestrator/DEV_TASK_DEPLOY_GATE_PATH_FIX.md.

✅ BUG-TRACKER-DUP · трекер плодит дубли · СТАТУС: ✅ ИСПРАВЛЕН (PR #22, b222d7af)

  • См. STATUS.md «Баг A» и memory/2026-06-04.md. edit_telegram возвращал False на "message is not modified" → дубли. Фикс: 4 состояния (ok/not_modified/gone/failed), send только при gone.

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)
Reference in New Issue View Git Blame Copy Permalink