Files
orchestrator/docs/overview/business.md
claude-bot 375bd468dd
All checks were successful
CI / test (push) Successful in 1m20s
CI / test (pull_request) Successful in 1m22s
docs(overview): отразить операторскую способность «Оценка» в витрине (ORCH-020)
Закрывает P1 из 12-review.md (attempt 2/3): бизнес-витрина docs/overview/
не отражала новый операторский Plane-статус «Оценка» (ORCH-020).

- business.md: бизнес-способность «Оценка задачи до запуска» + Сценарий 7.
- presentation.md: статус-жест «Оценка» на слайдах 8/9/15.
- tech-pipeline.md: новая секция «Оценка задачи: статус «Оценка»» +
  переформулировано устаревшее «управляющих статусов ровно три» в семейство
  операторских статусов-действий (запуск / гейты / STOP / Оценка).
- tech-integrations.md: то же переформулирование + запись прогноза/факта в Plane.
- tech-data-model.md: таблица task_estimates в списке вспомогательных.
- tech-observability.md: блок estimator в GET /queue + пункт «Оценка» карточки.

Также (P3): ужесточён тавтологичный assert TC-20 (был `... or True`) —
теперь проверяет, что ни один таргет ребра STAGE_TRANSITIONS не равен estimate.

Машинные факты витрины (tests/test_system_docs.py) и control-path не тронуты;
ruff на изменённом файле чист; полный pytest зелёный (2248 passed).

Refs: ORCH-020

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 22:04:39 +03:00

11 KiB
Raw Blame History

Бизнес-уровень: что это и зачем

Читатель этого документа — нетехнический: заказчик, руководитель, менеджер. Технические детали вынесены в тех-часть витрины и даются здесь только ссылками.

Проблема

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

Решение

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

Честность конвейера держат гейты качества: автоматические проверки на каждом переходе, которые не пускают задачу дальше, пока стадия не выполнена по-настоящему (тесты зелёные, ревью одобрено, репетиция выкладки успешна). Агент не может «уговорить» гейт — вердикты машинные, не прозой.

Что умеет платформа сегодня

Ниже — фактическое состояние, не планы (концепция развития — отдельный документ, Product Vision).

  • Автономный конвейер «задача → прод». Задача, поставленная в трекере, проходит весь путь до выкладки без ручных пинков; человек участвует ровно в двух точках — одобрение постановки и подтверждение прод-выкладки.
  • Мультипроектность. Один инстанс платформы ведёт несколько проектов (репозиториев) одновременно, с общей очередью и честным разделением работы.
  • Самовосстановление. Фоновые механизмы находят и чинят зависшие задачи: упавший агент перезапускается, осиротевшая задача возвращается в очередь, переполненный диск чистится, а независимый сторож следит за самой платформой снаружи.
  • Пакетный авто-режим. Задачи одного проекта выстраиваются в очередь и едут друг за другом без столкновений; специальными метками на задаче можно снять оба человеческих одобрения — и пакет задач уедет «за ночь» полностью автономно.
  • Дешёвый багфикс-маршрут. Задача с меткой «баг» едет коротким путём — без тяжёлой аналитики и отдельной стадии проектирования, но через все те же гейты качества.
  • Отмена задачи одной кнопкой. Перевод задачи в статус «STOP» в трекере останавливает работу, снимает её с очереди и прибирает за собой — безопасно даже посреди конвейера.
  • Оценка задачи до запуска. Перевод задачи в статус «Оценка» в трекере даёт прогноз её стоимости, времени и сложности (story points) по истории похожих задач — можно оценить сразу пачку задач и спланировать, что и когда брать в работу. По завершении задачи рядом с прогнозом ложится факт — оценки калибруются на реальных данных.
  • Наблюдаемость. У каждой задачи — живая карточка в Telegram (стадия, время, стоимость); у платформы — служебные страницы состояния и машинные метрики; история отклонений пишется в журнал уроков.
  • Самообслуживание (self-hosting). Платформа дорабатывает сама себя тем же конвейером, с обязательной репетицией на песочнице и ручным подтверждением выкладки.
  • Тиражируемость. Платформа разворачивается на новой инфраструктуре без правки кода: вариант Lite (у заказчика своя инфраструктура) и вариант Bundled (весь стек одним комплектом) — по пошаговым инструкциям.

Ценность

  • Скорость. Полный цикл «постановка → прод» без очередей между ролями; по оценке из Product Vision — порядка 35 минут на типовую фичу без ручных вмешательств.
  • 💰 Стоимость. Работа агентов в разы дешевле команды специалистов; стоимость каждой задачи видна в её карточке — расходы прозрачны.
  • 🎯 Автономность. Ноль ручных пинков в штатном прогоне: человек принимает решения, а не двигает задачу.
  • 🛡️ Надёжность. Многоуровневые гейты качества и репетиция выкладки на песочнице не пускают недоделку на прод; сломавшаяся выкладка откатывается, проект замораживается до разбора.
  • 🔁 Масштаб. Одна платформа — несколько проектов; сама платформа тиражируется на новые хосты за часы по инструкции.

Сценарии использования

Сценарий 1: фича за вечер

Заказчик формулирует задачу в трекере и переводит её в работу. Конвейер собирает требования, проектирует, пишет код и тесты, проходит ревью и тестирование, репетирует выкладку. Человек дважды нажимает «одобрить» — на постановке и перед продом. Вечером фича на проде.

Сценарий 2: багфикс по короткому маршруту

На задачу ставится метка «баг» — конвейер пропускает тяжёлую аналитику и отдельное проектирование, сразу чинит и фиксирует дефект регресс-тестом. Все гейты качества — без исключений.

Сценарий 3: пакет задач на ночь

Несколько задач проекта получают метки авто-одобрения. Очередь проводит их друг за другом: каждая следующая стартует от свежей версии кода с результатом предыдущей. Утром — пакет изменений на проде и полный след по каждой задаче.

Сценарий 4: несколько проектов параллельно

Один инстанс платформы обслуживает несколько репозиториев: задачи разных проектов едут одновременно, не мешая друг другу; внутри одного проекта порядок строго последовательный.

Сценарий 5: развернуть платформу у себя

Заказчик получает платформу на своей инфраструктуре по инструкции Lite (есть свои трекер и git) или Bundled (весь стек одним комплектом, ~14 контейнеров), со свежими секретами и проверкой каждого шага.

Сценарий 6: остановить задачу

Передумали — переводите задачу в статус «STOP»: работа агента останавливается, ветка и рабочие материалы прибираются, задача помечается отменённой. Если задача в этот момент в необратимой фазе выкладки — отмена аккуратно откладывается до её честного завершения. Подробнее — FAQ по статусу STOP.

Сценарий 7: оценить бэклог перед планированием

Оператор выделяет несколько задач в бэклоге и переводит их в статус «Оценка». По каждой платформа считает прогноз стоимости, времени и сложности по истории завершённых задач и возвращает задачу в бэклог с проставленной оценкой и комментарием. Видно, что дорого, а что дёшево — и чем наполнить ближайший прогон. По завершении задачи рядом ляжет факт.


Технические детали каждой способности — в тех-части витрины: как устроен конвейер, кто такие агенты, как работает наблюдаемость.