orchestrator/docs/work-items/ORCH-020/01-questions.md

work_item, stage, author_agent, status, created_at, model_used

work_item	stage	author_agent	status	created_at	model_used
ORCH-020	analysis	analyst	needs-input	2026-06-17	claude-opus-4-8

01 — Открытые вопросы (Open Questions): ORCH-020 — Оценка задачи: стоимость, время и сложность (адаптивный выбор моделей)

Work Item: ORCH-020 · Repo: orchestrator · Стадия: analysis

Сигнальный when-applicable артефакт (ORCH-120, adr-0053). Пишется аналитиком ТОЛЬКО при блокирующей неоднозначности, когда выпустить корректные 4 deliverables (01-brd/02-trz/ 03-acceptance-criteria/04-test-plan) нельзя без ответа заказчика. Не machine-verdict; гейтом не парсится — сигнал движку (_handle_analysis_approved_flow) увести задачу в Needs Input. После ответов в Plane аналитик перезапускается (resume), читает свежие комментарии и выпускает полный пакет.

1. Контекст

Бизнес-запрос (00-business-request.md) ставит две связанные, но разные по риску функции и сам перечисляет 4 нерешённых вопроса для Славы («❓ Открытые вопросы Славе»). Это решения уровня владельца продукта, а не аналитические дефолты: они определяют объём, модель данных и — главное — затрагивается ли прод-control-path выбора модели агента на self-hosting инстансе, который из ОДНОГО процесса с ОБЩЕЙ БД обслуживает и enduro-trails.

Что установлено по фактическому коду (карта src/, на которую опираются вопросы):

• Фактура для оценки уже есть, но только post-run. src/usage.py парсит токены/cost_usd/ модель из вывода Claude CLI ПОСЛЕ финиша агента; agent_runs несёт input_tokens/output_tokens/ cache_*/cost_usd/model/effort; есть агрегаты task_usage_summary/agent_cost_totals и тайминги (agent_runs.started_at/finished_at, tasks.created_at/updated_at/brd_review_*). → Прогноз ДО старта как контур сейчас отсутствует — это новый продюсер, не правка гейта.
• Выбор модели/эффорта статичен по роли. resolve_agent_model/resolve_agent_effort (src/agents/launcher.py, ORCH-41/74) резолвят модель из config/project-override и применяют её в _spawn (--model/--effort, launch-стамп ORCH-109). Хука «варьировать модель по сложности задачи нет». Любой адаптивный per-task override — это вмешательство в горячий путь запуска агентов на общем проде.
• ORCH-13 (мультипровайдерность) ещё не реализован. Дефолт один — claude-opus-4-8; реально различимы лишь тиры эффорта (low/medium/high/xhigh/max). Без ORCH-13 «выбор модели» фактически вырождается в «выбор эффорта».
• tasks.track (ORCH-019) уже существует ('full'|'bug') — связка «сложность → трек» опирается на готовый механизм, отдельной модели данных под трек не требует.
• lessons (ORCH-098) — журнал ОТКЛОНЕНИЙ, НЕ леджер «прогноз vs факт»: готовой калибровочной основы под петлю прогноз↔факт (связь с ORCH-8) пока нет.
• Leaf-паттерн (serial_gate/coverage_gate/labels/lessons): never-raise, kill-switch *_enabled, *_repos CSV (пусто → self-hosting only), read-only блок в GET /queue. Любой новый модуль оценки обязан ему следовать — это ограничение, а не предмет вопроса.

Без ответов ниже корректные BR/TRZ/AC/тест-план выпустить нельзя: для пунктов Q-2/Q-3 существуют взаимоисключающие варианты спецификации (разные AC, разная модель данных, разный контракт), а Q-1 определяет, какие из «Шаг 1 / Шаг 2» вообще входят в этот work item.

2. Блокирующие вопросы

Q-1…Q-4 — жёсткие блокеры. Q-5 — вопрос самого Славы с безопасным дефолтом (включён, чтобы закрыть все его вопросы за один раунд Needs Input и не плодить второй цикл).

• Q-1 — Объём и очерёдность: ORCH-020 = «Шаг 1 + Шаг 2» сразу, или «Шаг 1 сейчас» + «Шаг 2 после ORCH-13»?

  • Вариант A (рекомендуемый): Шаг 1 (прогноз стоимости/времени) сейчас; Шаг 2 (адаптивный выбор модели) — отдельным work item ПОСЛЕ ORCH-13, т.к. без мультипровайдерности «выбор модели» сводится к выбору эффорта, а сам по себе оценщик сложности можно поставлять как сигнал.
  • Вариант B: оба шага в одном work item — тогда оценщик сложности обязан выдавать решение, готовое кормить адаптивный выбор уже сейчас (на тирах эффорта, до ORCH-13).
  • Вариант C: только Шаг 2 (классификация сложности + маппинг), прогноз стоимости/времени — позже.
  • Почему блокирует: определяет, выпускаю ли я deliverables на Шаг 2 вообще и какие BR/AC в них попадут. Объём — зона аналитика, угадывать его нельзя.

• Q-2 — Адаптивный выбор модели: автоматический по сложности, или с твоим подтверждением для «дорогих»/нетривиальных? (вопрос Славы №3; самый критичный — self-hosting safety)

  • Вариант A (рекомендуемый): advisory-only — оценщик лишь предлагает класс/модель (коммент + карточка), фактический resolve_agent_model НЕ трогается; смена модели — ручной/конфиг-шаг. Прод-control-path неизменен, риск для enduro-trails нулевой.
  • Вариант B: авто-override на self-hosting только — per-task выбор модели/эффорта применяется автоматически, под kill-switch, скоуп *_repos пустой = только orchestrator, никогда не влияет на чужой репозиторий и на уже запущенные задачи.
  • Вариант C: авто для дешёвых тиров, подтверждение для дорогих (порог по прогнозу $/сложности).
  • Почему блокирует: A и B/C — это разные спецификации (advisory ⇒ AC про коммент/карточку и отсутствие правок горячего пути; auto ⇒ AC про безопасный gated override, скоуп, инвариант «не трогает enduro и in-flight»). Невозможно написать корректные FR/AC, не зная, ввязываемся ли мы в прод-путь запуска агентов на общем проде.

• Q-3 — Шкала сложности: фиксированные категории (trivial/small/medium/complex) или числовая (story points)? (вопрос Славы №4)

  • Вариант A (рекомендуемый): фиксированные категории (как в постановке) — простая модель данных (tasks.complexity TEXT, аддитивно по паттерну tasks.track), прозрачный маппинг «класс → эффорт/модель/трек».
  • Вариант B: числовая (story points / 1–N) — гибче для калибровки, но требует решить пороги отображения и маппинг диапазон→модель.
  • Вариант C: гибрид (число внутри + ярлык-категория для людей).
  • Почему блокирует: задаёт контракт выхода оценщика, тип новой колонки и форму маппинга «сложность → модель/трек». Это часть требований (модель данных), не реализационная деталь.

• Q-4 — Оценка обязательна для КАЖДОЙ задачи, или по запросу / только для крупных? (вопрос Славы №2)

  • Вариант A (рекомендуемый): для каждой задачи автоматически на входе/в аналитике (start_pipeline), но строго never-raise/best-effort — сбой оценки никогда не тормозит конвейер.
  • Вариант B: по запросу (эндпоинт/лейбл Plane) и/или только при превышении порога размера.
  • Вариант C: только self-hosting orchestrator на первом этапе (обкатка), enduro — позже.
  • Почему блокирует: определяет точку интеграции (триггер в start_pipeline для всех проектов общего прода vs опциональный путь) и формулировку NFR про область раската и обратимость.

• Q-5 — Где показывать прогноз стоимости/времени: Telegram при заведении, Plane-коммент, оба? (вопрос Славы №1; мягкий — есть безопасный дефолт)

  • Вариант A (рекомендуемый дефолт): оба — Plane-коммент (plane_sync.add_comment) + live-карточка/уведомление в Telegram (notifications.send_telegram); это безопасный суперсет поверх уже существующих поверхностей.
  • Вариант B: только Telegram. Вариант C: только Plane-коммент.
  • Почему (мягко) блокирует: влияет на объём (одна поверхность vs две) и на AC отображения; если промолчишь — зафиксирую дефолт A.

3. Что разблокирует анализ

• Ответы на Q-1…Q-4 (и подтверждение/override Q-5) комментарием в Plane к ORCH-020.
• Минимально для старта достаточно: Q-1 (объём), Q-2 (advisory vs auto — определяет, трогаем ли control-path) и Q-3 (шкала). Q-4/Q-5 имеют безопасные дефолты (A), которые я приму при молчании.
• На resume: прочту свежие комментарии-ответы и (а) если все блокеры сняты — выпущу полный валидный пакет из 4 файлов (он автоматически supersede’ит этот файл по mtime, повторного Needs Input не будет); (б) если часть вопросов осталась — перепишу этот файл, оставив только актуальные блокеры (снова Needs Input). Устаревшие вопросы вперемешку с новыми оставлять не буду.

Подразумеваемые инварианты, которые я зафиксирую в пакете при ЛЮБЫХ ответах (не вопросы — границы): новый функционал следует leaf-паттерну (never-raise, kill-switch, *_repos пусто → self-hosting only, блок в GET /queue); STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict-ключи/схемы существующих таблиц — не трогаются (оценка — наблюдатель/продюсер, не Quality Gate); прод- контейнер не рестартится; main/force-push не затрагиваются. Выбор механизма оценки (эвристика по истории / LLM-оценщик / гибрид) и «точность vs стоимость самой оценки» — архитектурное решение (06-adr), его я не предрешаю; в TRZ зафиксирую лишь требование-ограничение «стоимость оценки ≪ ожидаемой экономии».