Files
orchestrator/docs/PRODUCT_VISION.md
claude-bot 6d798c01ef docs(overview): витрина системы docs/overview/ — бизнес+тех, 3 аудитории, презентация (ORCH-011)
Единая точка входа в документацию платформы (ADR-001 D1–D9):
- docs/overview/ — 10 файлов: индекс (маршруты «Я заказчик / Я менеджер /
  Я разработчик» + норматив «изменил функциональность → обнови витрину в том же
  PR»), business.md (без жаргона, 6 сценариев), 7 тех-блоков (link-first),
  presentation.md (16 слайдов + процедура сборки «команда + Проверка:»).
- scripts/build_presentation.py — генератор .pptx в тёмном дизайне (python-pptx;
  чистый stdlib-парсер parse_slides + ленивый import pptx; бинарь не коммитится,
  build/ в .gitignore; зависимость НЕ в прод-образе — машинный гард TC-09).
- tests/test_system_docs.py — структурный анти-дрейф: derive-сверки стадий/
  гейтов/агентов импортом STAGE_TRANSITIONS/QG_CHECKS/glob промптов/config,
  валидность ссылок, FORBIDDEN-скан + секрет-эвристика, слайды каноническим
  парсером, NFR-2, указатели.
- reviewer.md — ось обзорных доков ORCH-079 расширена на витрину (D7; канон 52d
  байт-в-байт, только текст внутри секций) + анти-регресс ассерт в
  test_agent_prompts_canon.py.
- Указатели: README.md, CLAUDE.md (правила №2/№6, «Структура»),
  PRODUCT_VISION.md (врезка-ссылка), CHANGELOG.md.

Рантайм байт-в-байт: src/**, docker-compose.yml, Dockerfile, requirements* —
ноль изменений (docs+tests+dev-скрипт, паттерн ORCH-102/103). pytest: 1873 passed.

Refs: ORCH-011

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-11 09:36:40 +03:00

11 KiB
Raw Permalink Blame History

Product Vision — Автономная фабрика разработки (Orchestrator)

Мультиагентная платформа, которая превращает идею или баг в задеплоенный на прод результат — автономно, надёжно и дёшево.

Версия: 1.0 · Дата: 2026-06-04 · Статус: концепция развития

Фактическое текущее состояние платформы (что уже умеет, как устроена) — витрина системы docs/overview/ (ORCH-011). Этот документ — vision: «куда идём».


1. Зачем это (бизнес-взгляд)

Проблема

Классическая разработка — это люди-бутылочное-горлышко на каждом шаге: аналитик, архитектор, разработчик, ревьюер, тестировщик, деплой-инженер. Каждая передача задачи между ними — потеря времени, контекста и денег. Мелкая фича или баг едут днями.

Решение

Orchestrator — это конвейер из ИИ-агентов, который проводит задачу через все стадии разработки сам: от бизнес-постановки до релиза на прод. Человек ставит задачу и принимает результат. Всё между — автономно.

Ценность

  • Скорость: фича проходит полный цикл (анализ → архитектура → код → ревью → тесты → деплой) за ~35 минут без ручных вмешательств.
  • 💰 Стоимость: работа агентов в разы дешевле команды; адаптивный выбор моделей экономит на простых задачах.
  • 🎯 Автономность: 0 ручных пинков в штатном прогоне. Человек — постановщик и приёмщик, а не оператор.
  • 🛡️ Надёжность: многоуровневые гейты качества не пускают недоделку на прод.
  • 🔁 Масштаб: одна платформа ведёт несколько проектов; саму платформу можно тиражировать на новые хосты.

2. Как это работает (обзор)

Конвейер

created → analysis → architecture → development → review → testing → deploy → done

На каждом переходе стоит quality gate — автоматическая проверка, которая не пускает задачу дальше, пока стадия не выполнена честно:

Переход Гейт Что проверяет
analysis → architecture check_analysis_approved BRD/TRZ/AC готовы + апрув человека
architecture → development check_architecture_done Архитектура/ADR зафиксированы
development → review check_ci_green CI зелёный (тесты проходят)
review → testing check_reviewer_verdict Машинный вердикт ревьюера: APPROVED
testing → deploy check_tests_passed Машинный вердикт тестера (не подделать)
deploy → done check_deploy_status Деплой реально успешен, лог в origin/main

Агенты

  • Analyst — собирает бизнес-требования, пишет BRD/TRZ/критерии приёмки.
  • Architect — проектирует решение, фиксирует ADR.
  • Developer — пишет код в изолированном git-worktree.
  • Reviewer — ревьюит, выносит машинный вердикт.
  • Tester — прогоняет тесты, фиксирует результат в отчёте.
  • Deployer — мержит, тегирует, деплоит на прод, пишет deploy-log.

Объекты

  • Project — проект в реестре (Plane project ↔ git-репозиторий ↔ префикс задач).
  • Work-Item — задача, проходящая конвейер; на каждой стадии накапливает артефакты (00-business-request … 14-deploy-log).
  • Job — единица работы в очереди (atomic claim, ретраи, restart-safe).

Интеграции

  • Plane — управление задачами, статусы как триггеры конвейера, webhooks.
  • Gitea — репозитории, PR, защита main (pre-receive hook).
  • Telegram — живой трекер прогресса, апрувы, уведомления.
  • LLM — модели агентов (сейчас Claude, в планах мультипровайдерность).

3. Что уже сделано (фундамент)

Автономный конвейер — подтверждён живым прогоном: задача от issue до Done без ручных вмешательств (~35 мин). Очередь задач — atomic claim, max_concurrency, ретраи, restart-safe. Изоляция через git-worktree — каждая задача в своём дереве, без конфликтов в shared-репо. Машинные гейты качества — вердикты читаются из структурированных артефактов, а не угадываются по тексту. Multi-repo — платформа ведёт несколько проектов (enduro-trails, сам orchestrator). Идемпотентность webhooks — дедуп по delivery-id, защита от дублей. Наблюдаемость — учёт токенов и стоимости каждой задачи. Живой Telegram-трекер — прогресс редактируется в одном сообщении, без спама.


4. Куда движемся (дорожная карта)

Развитие сгруппировано в 5 стратегических направлений.

🛡️ Надёжность и безопасность

  • Post-deploy мониторинг + авто-rollback — следить за продом после релиза, откатывать при деградации.
  • Security-гейт — secret-scanning + аудит зависимостей перед мержем.
  • Бюджетный circuit-breaker — хард-лимит стоимости на задачу, защита от «убегающих» расходов.
  • Опциональная human-приёмка — финальный взгляд человека для критичных фич.

💰 Экономика и интеллект

  • Мультипровайдерность LLM — Claude, OpenRouter, другие провайдеры на выбор.
  • Оценка задачи — прогноз стоимости/времени до старта.
  • Адаптивный выбор модели — по сложности: тривиальное на дешёвой, сложное на сильной.
  • Багфикс-трек — упрощённый дешёвый путь для багов (без потери качества).

🏗️ Платформа и масштаб

  • Self-hosting — оркестратор пилит сам себя через собственный конвейер.
  • Саморазвитие — петля уроков: ловить отклонения → фиксировать → предлагать улучшения.
  • Онбординг проектов — turnkey-заведение нового проекта в систему.
  • Тиражирование — развернуть платформу на новой инфраструктуре под ключ.

💬 Взаимодействие с человеком

  • UX/UI дизайнер — макеты интерфейсов на этапе аналитики.
  • Интерактивный аналитик — живой диалог для уточнения требований и обсуждения макетов.
  • Единые коммент-артефакты — все агенты прикладывают результаты с кликабельными ссылками.
  • Прямые ссылки в Telegram — апрув в один клик, без блужданий.

🧩 Расширение возможностей

  • Тяжёлые расчёты данных — опциональная стадия для миграций/обработки больших данных.
  • Android-разработка — мобильный стек через тот же конвейер.
  • Декомпозиция эпиков — большая фича → подзадачи → сборка.
  • Управление зависимостями — задача B ждёт задачу A.
  • Code coverage gate — защита покрытия тестами от деградации.
  • База знаний проекта — персистентный контекст для агентов.

5. Принципы (что для нас неизменно)

  1. Автономность по умолчанию, человек — на ключевых развилках. Машина делает, человек ставит и принимает.
  2. Качество не приносится в жертву скорости/цене. Удешевляем аналитику — гейты качества остаются. Урок дорого выученный: срезанная проверка = недоделка на проде.
  3. Машинные вердикты, а не угадывание. Гейты читают структурированные поля, а не ищут слова в тексте.
  4. Самоизменение — только через PR + ревью + апрув. Агент, меняющий агентов, всегда под контролем человека.
  5. Документация — сразу, не потом. Изменил функционал → обновил доки.
  6. Прод — источник правды. «Деплой прошёл» ≠ «работает». Проверяем реальный результат.

6. Видение в одну фразу

Самодостаточная фабрика разработки, которая размножается, учится на ошибках, оценивает себя, бережёт бюджет и не ломает прод — превращая намерение человека в работающий продукт почти без его участия.


Документ поддерживается в репозитории orchestrator. Источник дорожной карты — задачи проекта ORCH в Plane (ORCH-7…ORCH-28).