208 lines
17 KiB
Markdown
208 lines
17 KiB
Markdown
# Бэклог — Мультиагентная разработка ПО
|
||
|
||
---
|
||
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/<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)
|
||
|
||
- [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)
|