# Бэклог — Мультиагентная разработка ПО --- 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`. ### 🔴 ET-10 · TRI на Copernicus DEM 30м — точные перепады на z9-z11 (вариант B) · СТАТУС: 🔴 BACKLOG - **Приоритет:** средний. **Тип:** данные + код (гибрид, НЕ весь через конвейер). - **Суть:** слой «Перепады высот» (TRI) мелкий на z9-z11 — корень в SRTM ~90м/пиксель (физический потолок). Перейти на Copernicus DEM GLO-30 (~30м, втрое детальнее) + перегенерация TRI-тайлов. - **Разделение:** через конвейер — правка generate_terrain.sh (воспроизводимая генерация TRI); вручную/фоном — скачивание DEM (гигабайты) + многочасовая генерация тайлов (НЕ влезает в таймауты агентов). - **Генерация TRI НЕ зафиксирована** в generate_terrain.sh (скрипт делает только hypso + hillshade `-z 2`; TRI лепился отдельным несохранённым прогоном). Заодно исправить. - **Альтернатива A** (быстрый первый шаг): перегенерить TRI на текущих SRTM с усиленным контрастом — если B тяжело. - **Источники:** Plane ET-10 (id `53829937-4d5e-4d7c-8357-f82347087bc9`), generate_terrain.sh. ### ✅ ET-8 · перепады высот z9-z11 (zoom-aware paint) · СТАТУС: ✅ ЗАКРЫТА по кодовой части (Done) - **Приоритет:** средний (функциональная фича для пользователя). - **Решение:** кодовая часть (zoom-aware paint, app.js, ADR-017) реализована и на проде — закрыта в Done. **Генерация данных вынесена в ET-10** (выше). Причина: «мелко» — не от кода, а от разрешения SRTM; тяжёлый серверный прогон не проходит через конвейер. - **Урок:** ET-8 вчера была ошибочно закрыта в Done по «deploy SUCCESS» без проверки реального результата (и при проваленном AC-19). Теперь закрыта осознанно — только кодовая часть, данные в ET-10. - **Источники:** `memory/2026-06-04.md`, Plane ET-8 (коммент закрытия), ET-10. ### ✅ 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//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 `), идемпотентный, с 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)