claude-bot
6d798c01ef
Единая точка входа в документацию платформы (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>
106 lines
10 KiB
Markdown
106 lines
10 KiB
Markdown
# Бизнес-уровень: что это и зачем
|
||
|
||
> Читатель этого документа — нетехнический: заказчик, руководитель, менеджер. Технические
|
||
> детали вынесены в [тех-часть витрины](README.md) и даются здесь только ссылками.
|
||
|
||
## Проблема
|
||
|
||
Классическая разработка — это люди-бутылочное-горлышко на каждом шаге: аналитик, архитектор,
|
||
разработчик, ревьюер, тестировщик, деплой-инженер. Каждая передача задачи между ними — потеря
|
||
времени, контекста и денег. Мелкая фича или баг едут до прода днями: не потому, что работа
|
||
сложная, а потому, что задача ждёт людей в очередях между ролями.
|
||
|
||
## Решение
|
||
|
||
**Orchestrator** — конвейер из ИИ-агентов, который проводит задачу через все стадии разработки
|
||
сам: анализ требований → проектирование → код → ревью → тестирование → репетиция выкладки →
|
||
выкладка на прод. Человек в этой схеме — **постановщик и приёмщик**: он формулирует задачу,
|
||
одобряет постановку и подтверждает выкладку на прод. Всё между — автономно.
|
||
|
||
Честность конвейера держат **гейты качества**: автоматические проверки на каждом переходе,
|
||
которые не пускают задачу дальше, пока стадия не выполнена по-настоящему (тесты зелёные,
|
||
ревью одобрено, репетиция выкладки успешна). Агент не может «уговорить» гейт — вердикты
|
||
машинные, не прозой.
|
||
|
||
## Что умеет платформа сегодня
|
||
|
||
Ниже — фактическое состояние, не планы (концепция развития — отдельный документ,
|
||
[Product Vision](../PRODUCT_VISION.md)).
|
||
|
||
- **Автономный конвейер «задача → прод».** Задача, поставленная в трекере, проходит весь путь
|
||
до выкладки без ручных пинков; человек участвует ровно в двух точках — одобрение постановки
|
||
и подтверждение прод-выкладки.
|
||
- **Мультипроектность.** Один инстанс платформы ведёт несколько проектов (репозиториев)
|
||
одновременно, с общей очередью и честным разделением работы.
|
||
- **Самовосстановление.** Фоновые механизмы находят и чинят зависшие задачи: упавший агент
|
||
перезапускается, осиротевшая задача возвращается в очередь, переполненный диск чистится,
|
||
а независимый сторож следит за самой платформой снаружи.
|
||
- **Пакетный авто-режим.** Задачи одного проекта выстраиваются в очередь и едут друг за другом
|
||
без столкновений; специальными метками на задаче можно снять оба человеческих одобрения —
|
||
и пакет задач уедет «за ночь» полностью автономно.
|
||
- **Дешёвый багфикс-маршрут.** Задача с меткой «баг» едет коротким путём — без тяжёлой
|
||
аналитики и отдельной стадии проектирования, но через все те же гейты качества.
|
||
- **Отмена задачи одной кнопкой.** Перевод задачи в статус «STOP» в трекере останавливает
|
||
работу, снимает её с очереди и прибирает за собой — безопасно даже посреди конвейера.
|
||
- **Наблюдаемость.** У каждой задачи — живая карточка в Telegram (стадия, время, стоимость);
|
||
у платформы — служебные страницы состояния и машинные метрики; история отклонений пишется
|
||
в журнал уроков.
|
||
- **Самообслуживание (self-hosting).** Платформа дорабатывает сама себя тем же конвейером,
|
||
с обязательной репетицией на песочнице и ручным подтверждением выкладки.
|
||
- **Тиражируемость.** Платформа разворачивается на новой инфраструктуре без правки кода:
|
||
вариант Lite (у заказчика своя инфраструктура) и вариант Bundled (весь стек одним
|
||
комплектом) — по пошаговым инструкциям.
|
||
|
||
## Ценность
|
||
|
||
- ⚡ **Скорость.** Полный цикл «постановка → прод» без очередей между ролями; по оценке из
|
||
[Product Vision](../PRODUCT_VISION.md) — порядка 35 минут на типовую фичу без ручных
|
||
вмешательств.
|
||
- 💰 **Стоимость.** Работа агентов в разы дешевле команды специалистов; стоимость каждой
|
||
задачи видна в её карточке — расходы прозрачны.
|
||
- 🎯 **Автономность.** Ноль ручных пинков в штатном прогоне: человек принимает решения,
|
||
а не двигает задачу.
|
||
- 🛡️ **Надёжность.** Многоуровневые гейты качества и репетиция выкладки на песочнице не
|
||
пускают недоделку на прод; сломавшаяся выкладка откатывается, проект замораживается до
|
||
разбора.
|
||
- 🔁 **Масштаб.** Одна платформа — несколько проектов; сама платформа тиражируется на новые
|
||
хосты за часы по инструкции.
|
||
|
||
## Сценарии использования
|
||
|
||
### Сценарий 1: фича за вечер
|
||
Заказчик формулирует задачу в трекере и переводит её в работу. Конвейер собирает требования,
|
||
проектирует, пишет код и тесты, проходит ревью и тестирование, репетирует выкладку. Человек
|
||
дважды нажимает «одобрить» — на постановке и перед продом. Вечером фича на проде.
|
||
|
||
### Сценарий 2: багфикс по короткому маршруту
|
||
На задачу ставится метка «баг» — конвейер пропускает тяжёлую аналитику и отдельное
|
||
проектирование, сразу чинит и фиксирует дефект регресс-тестом. Все гейты качества — без
|
||
исключений.
|
||
|
||
### Сценарий 3: пакет задач на ночь
|
||
Несколько задач проекта получают метки авто-одобрения. Очередь проводит их друг за другом:
|
||
каждая следующая стартует от свежей версии кода с результатом предыдущей. Утром — пакет
|
||
изменений на проде и полный след по каждой задаче.
|
||
|
||
### Сценарий 4: несколько проектов параллельно
|
||
Один инстанс платформы обслуживает несколько репозиториев: задачи разных проектов едут
|
||
одновременно, не мешая друг другу; внутри одного проекта порядок строго последовательный.
|
||
|
||
### Сценарий 5: развернуть платформу у себя
|
||
Заказчик получает платформу на своей инфраструктуре по инструкции
|
||
[Lite](../deployment/LITE_SETUP.md) (есть свои трекер и git) или
|
||
[Bundled](../deployment/BUNDLED_SETUP.md) (весь стек одним комплектом, ~14 контейнеров),
|
||
со свежими секретами и проверкой каждого шага.
|
||
|
||
### Сценарий 6: остановить задачу
|
||
Передумали — переводите задачу в статус «STOP»: работа агента останавливается, ветка и
|
||
рабочие материалы прибираются, задача помечается отменённой. Если задача в этот момент в
|
||
необратимой фазе выкладки — отмена аккуратно откладывается до её честного завершения.
|
||
|
||
---
|
||
|
||
*Технические детали каждой способности — в [тех-части витрины](README.md): как устроен
|
||
[конвейер](tech-pipeline.md), кто такие [агенты](tech-agents.md), как работает
|
||
[наблюдаемость](tech-observability.md).*
|