analyst(ET): auto-commit from analyst run_id=797

docs/work-items/ORCH-020/01-brd.md

@@ -4,122 +4,179 @@ stage: analysis
 author_agent: analyst
 status: ready-for-review
 created_at: 2026-06-17
-model_used: claude-fable-5
+model_used: claude-opus-4-8
 ---
 
-# 01 — BRD (бизнес-требования): ORCH-020 — Оценка задачи (прогноз стоимости/времени/сложности в story points + калибровка)
+# 01 — BRD (бизнес-требования): ORCH-020 — Оценка задачи (прогноз стоимости/времени/story points), запускаемая статусом «Оценка»
 
 Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 
-> **Resume после Needs Input.** Заказчик (Слава) ответил на блокирующие вопросы из `01-questions.md`
-> комментариями в Plane (16:12 / 16:16 / 16:34, 2026-06-17). Этот пакет (`01`–`04`) выпускается по
-> ответам и **supersede’ит** `01-questions.md` по mtime — повторного Needs Input нет. Объём
-> зафиксирован ответами: **только Шаг 1 (оценка)**; Шаг 2 (адаптивный выбор моделей) выведен из
-> объёма (см. §2 «Вне объёма» + ACTION).
+> **Revision после REJECT (Plane, 2026-06-17).** Заказчик отклонил предыдущий пакет: «**что я не
+> увидел в БРД — как запускать оценку?** Я хотел бы переводить задачу в статус "Оценка", после чего
+> запускался бы механизм оценки, и после завершения оценки задача бы меняла статус на backlog. На
+> оценку я буду отправлять задачи **массово через Plane**. Также я могу **переоценивать задачи много
+> раз**.» Этот раунд **переписывает модель триггера**: оценка теперь — **операторское действие,
+> запускаемое выделенным Plane-статусом «Оценка»** (а не «автоматически для каждой задачи на
+> `start_pipeline`», как в отклонённой версии). Прочие требования (что прогнозируем, куда пишем,
+> леджер прогноз↔факт, leaf-инварианты) сохранены и согласованы с новым триггером. Полный пакет
+> `01`–`04` supersede’ит прежний по mtime.
 
 ## 1. Бизнес-контекст и проблема
 
-Заказчик планирует работу по бэклогу «вручную» и хочет **до отправки задачи в работу** видеть
-прогноз: сколько задача будет стоить (токены × тариф = $), сколько займёт времени и насколько она
-сложна (размер в story points). Сейчас этих данных до старта нет: оркестратор собирает фактуру
+Заказчик планирует работу по бэклогу вручную и хочет **до отправки задачи в работу** видеть прогноз:
+сколько задача будет стоить (токены × тариф = $), сколько займёт времени и насколько она сложна
+(размер в story points). Сейчас этих данных до старта нет: оркестратор собирает фактуру
 (`input_tokens`/`output_tokens`/`cache_*`/`cost_usd`/`model`/`effort`, тайминги
 `agent_runs.started_at/finished_at`, `tasks.created_at/updated_at`) **только постфактум** через
 `src/usage.py` (`task_usage_summary`, `agent_cost_totals`, `record_usage`). Контур **прогноза до
 старта** отсутствует.
 
-Цитата заказчика (Plane, 2026-06-17): «Оценка нужна заранее, до передачи в работу… на основе оценки
-я буду понимать объём задачи и планировать какие задачи отправлять в работу… все задачи бэклога
-пакетно можно оценить и переоценить если изменился скоуп. В Plane есть поле оценка, туда и нужно
-записывать оценку. По факту завершения задачи вписать в смежное поле… для оценки есть два поля.»
+**Корень REJECT — отсутствовал способ ЗАПУСКА оценки.** Заказчик мыслит оценку как **операторский
+жест в Plane**, а не как невидимый авто-шаг: он сам решает, какие задачи бэклога оценить, **массово**
+переводит их в выделенный статус, получает прогнозы и продолжает планирование. Отклонённая версия
+прятала триггер в `start_pipeline` («оценка обязательна для каждой задачи автоматически») и явно
+называла точку триггера «реализационной деталью» — это и есть то, что заказчик «не увидел» и
+отверг.
+
+Цитаты заказчика (Plane, 2026-06-17):
+- REJECT: «как запускать оценку? Я хотел бы **переводить задачу в статус "Оценка"**, после чего
+  запускался бы механизм оценки, и после завершения оценки задача бы **меняла статус на backlog**. На
+  оценку я буду отправлять задачи **массово через Plane**. Также я могу **переоценивать задачи много
+  раз**.»
+- Раунд Needs Input: «В Plane есть поле оценка, туда и нужно записывать оценку. По факту завершения
+  задачи вписать в смежное поле… для оценки есть два поля.»; «Только Шаг 1, без выбора модели»;
+  «Модели не выбираем и не меняем. Это вне скоупа».
 
 Установленные факты по коду (на которые опирается решение, не изобретать):
+- **Прецедент «статус-триггер уже есть в платформе.** Plane-статусы — слой B (индикация, ORCH-066) и
+  НЕ управляют машиной стадий; но платформа уже имеет **операторские action-статусы**, запускающие
+  side-механизмы: **STOP** (ORCH-090, отмена задачи) и **Confirm Deploy** (ORCH-059, прод-деплой).
+  Оба разбираются в `webhooks/plane.py::handle_issue_updated` через
+  `proj_states.get("<key>")` и оба **намеренно отсутствуют** в `plane_sync._DEFAULT_STATES`
+  (fail-closed: доска без статуса → `None` → ветка не активируется). Статус «Оценка» — **третий
+  представитель этого же семейства**.
+- **Маппинг имени статуса → логический ключ** — `plane_sync._PLANE_NAME_TO_KEY` (`"STOP"→"stop"`,
+  `"Confirm Deploy"→"confirm_deploy"`); `get_project_states` резолвит UUID статуса per-project из
+  Plane API.
+- **Массовость — «бесплатно».** Plane multi-select по N задачам в статус «Оценка» порождает N
+  отдельных `issue.updated`-вебхуков (по одному на issue); каждый обрабатывается независимо. Отдельный
+  «batch-UX» в оркестраторе не требуется — массовость обеспечивает сам Plane.
 - **Фактура для калибровки уже накоплена** (`agent_runs`, агрегаты `task_usage_summary` /
   `agent_cost_totals`, тайминги). Это сырьё для «истории похожих задач».
-- **Plane-поля существуют.** На issue ORCH-020 присутствуют поля `estimate_point` и `point` (оба
-  сейчас `None`); estimate-система на проекте (`project.estimate`) **не настроена** (`None`) — это
-  инфра-предусловие (см. NFR-6).
+- **Plane-поля существуют.** На issue присутствуют поля `estimate_point` (ОЦЕНКА) и `point` (ФАКТ);
+  estimate-система на проекте (`project.estimate`) на момент анализа **не настроена** — инфра-
+  предусловие (NFR-7).
 - **Выбор модели/эффорта статичен по роли** (`resolve_agent_model`/`resolve_agent_effort`,
-  ORCH-41/74) и в этой задаче **не трогается** (Шаг 2 вне объёма).
-- **leaf-паттерн платформы** (`serial_gate`/`coverage_gate`/`labels`/`lessons`): never-raise,
+  ORCH-41/74; дефолт `claude-opus-4-8`) и в этой задаче **не трогается** (Шаг 2 вне объёма).
+- **leaf-паттерн платформы** (`serial_gate`/`coverage_gate`/`labels`/`lessons`/`cancel`): never-raise,
   kill-switch `*_enabled`, `*_repos` CSV (пусто → self-hosting only), read-only блок в `GET /queue`.
 
 ## 2. Объём (scope)
 
-### В объёме (Шаг 1 — Оценка)
-- **Прогноз перед стартом** для задачи: стоимость ($), время, токены и **сложность в story points**
-  из фиксированной шкалы `{1, 2, 3, 5, 8}`.
-- **Шкала story points (фиксированная, ответ Q-3 = вариант A):**
-  - `1` — мелкая docs / label / config задача;
-  - `2` — небольшой фикс;
-  - `3` — средняя задача;
-  - `5` — сложная (код + тесты);
-  - `8` — эпик / разбивать.
+### В объёме (Шаг 1 — Оценка, запускаемая статусом)
+- **Триггер «Оценка» (ядро правки).** Перевод issue в выделенный Plane-статус **«Оценка»** запускает
+  механизм оценки этой задачи. Оператор делает это **вручную и массово** (multi-select в Plane).
+- **Жизненный цикл статуса:** `Backlog → (оператор) «Оценка» → [оркестратор: оценка] → (оркестратор)
+  Backlog`. По завершении оценки оркестратор **сам возвращает** issue в статус **`Backlog`**.
+- **Пере-оценка много раз.** Повторный перевод в «Оценка» переоценивает задачу заново (идемпотентно:
+  перезапись `estimate_point` и строки леджера). Применимо при изменении скоупа.
+- **Прогноз четырёх величин:** стоимость ($), время, токены и **сложность в story points** из
+  фиксированной шкалы `{1, 2, 3, 5, 8}`.
+- **Шкала story points (фиксированная, ответ Q-3 = вариант A):** `1` — мелкая docs/label/config;
+  `2` — небольшой фикс; `3` — средняя; `5` — сложная (код + тесты); `8` — эпик / разбивать.
 - **Запись прогноза в Plane-поле `estimate_point`** (это ОЦЕНКА).
 - **Запись факта в Plane-поле `point`** по завершении задачи (фактическая реализованная сложность в
-  story points, выведенная из фактических токенов/времени/стоимости по той же шкале) — для будущей
-  калибровки механизма оценки.
+  story points из фактических токенов/времени/стоимости по той же шкале) — для калибровки.
 - **Отображение прогноза на двух поверхностях** (ответ Q-5 = оба): Plane-коммент + пункт **«Оценка»**
   в общей Telegram-карточке задачи (`src/notifications.py`) — **время, токены, стоимость**.
-- **Обязательность для всех задач** (ответ Q-4): оценка производится автоматически, best-effort.
-- **Пакетная оценка бэклога и пере-оценка при изменении скоупа** (ответ Q-4): возможность оценить/
-  переоценить все backlog-задачи проекта одним вызовом.
 - **Локальный леджер прогноз↔факт** (фундамент петли калибровки, связь с ORCH-8): хранение прогноза,
-  факта и дельты.
+  факта и дельты, **ключ — `work_item_id`** (issue может ещё не иметь pipeline-задачи на момент
+  оценки — она на бэклоге).
 
 ### Вне объёма
-- **Шаг 2 — адаптивный выбор моделей агентов** (ответы Q-1/Q-2: «Только шаг 1, без выбора модели»;
+- **Шаг 2 — адаптивный выбор моделей агентов** (ответы Q-1/Q-2: «Только Шаг 1, без выбора модели»;
   «Модели не выбираем и не меняем. Это вне скоупа»). Горячий путь `resolve_agent_model`/
   `resolve_agent_effort`/`_spawn` **не модифицируется**.
   > **ACTION (поручение заказчика, Plane 16:34):** «заведи отдельную задачу в Plane для адаптивного
-  > выбора модели и укажи зависимость на мультипровайдеров (ORCH-13)». Создание Plane-issue —
-  > действие уровня заказчика/PM и **вне write-объёма аналитика** (Write ограничен
-  > `docs/work-items/<plane-id>/*`). Фиксирую как обязательный follow-up: новый work item «Адаптивный
-  > выбор модели агента по сложности» с зависимостью на **ORCH-13 (мультипровайдерность)**; оценщик
-  > сложности из ORCH-020 — его вход (сигнал). Оператору: подтвердить создание или создать вручную.
-- **Автопереключение трека по сложности** (связка с ORCH-19) — позже; в ORCH-020 сложность лишь
+  > выбора модели и укажи зависимость на мультипровайдеров (ORCH-13)». Создание Plane-issue — действие
+  > уровня заказчика/PM и **вне write-объёма аналитика** (Write ограничен `docs/work-items/<id>/*`).
+  > Фиксирую как обязательный follow-up: новый work item «Адаптивный выбор модели агента по сложности»
+  > с зависимостью на **ORCH-13**; оценщик сложности из ORCH-020 — его вход. Оператору: подтвердить
+  > создание или создать вручную.
+- **Автопереключение трека по сложности** (связка с ORCH-19) — позже; здесь сложность лишь
   вычисляется и публикуется как сигнал.
-- **Авто-ретроспективщик / RICE-приоритизатор** (E2/E3 ORCH-8) — вне объёма; леджер прогноз↔факт —
-  лишь фундамент.
-- **Изменение тарифной/биллинговой модели** — используется уже существующий `cost_usd` из `usage.py`.
+- **Авто-ретроспективщик / RICE-приоритизатор** (E2/E3 ORCH-8) — вне объёма; леджер — фундамент.
+- **Автоматическая оценка КАЖДОЙ задачи на `start_pipeline`** — **исключена явно** (модель
+  отклонённой версии). Оценка — операторский on-demand жест через статус «Оценка».
+- **Изменение тарифной/биллинговой модели** — используется существующий `cost_usd` из `usage.py`.
+- **Новый «batch-UX»/массовый эндпоинт как ОСНОВНОЙ путь** — не нужен (массовость даёт Plane
+  multi-select → N вебхуков). Программный `POST /estimate*` допустим лишь как **опциональное**
+  удобство/диагностика, не как основной триггер (см. TRZ §4).
 
 ## 3. Заинтересованные стороны
-- **Заказчик / владелец продукта (Слава)** — потребитель прогноза для планирования бэклога; принимает
-  результат.
+- **Заказчик / владелец продукта (Слава)** — инициатор оценки (переводит задачи в «Оценка»),
+  потребитель прогноза для планирования бэклога; принимает результат.
 - **Оркестратор (self-hosting)** — носитель функции; общий прод обслуживает и `enduro-trails`.
 - **Будущая петля саморазвития (ORCH-8)** — потребитель леджера прогноз↔факт для калибровки.
 - **ORCH-13 (мультипровайдерность)** — будущий потребитель сигнала сложности (через follow-up Шаг 2).
 
 ## 4. Бизнес-требования (BR)
+
+### Триггер и жизненный цикл (ядро ревизии)
+- **BR-T1 — Запуск оценки статусом «Оценка».** Перевод issue в выделенный Plane-статус **«Оценка»**
+  запускает оценку именно этой задачи. Это **единственный обязательный** способ запуска (массовый и
+  ручной), реализуемый по образцу операторских action-статусов STOP (ORCH-090) / Confirm Deploy
+  (ORCH-059).
+- **BR-T2 — Авто-возврат в Backlog.** По завершении оценки (успех или best-effort-пропуск)
+  оркестратор **сам** переводит issue обратно в статус **`Backlog`**. Заказчик видит задачу
+  вернувшейся в бэклог с заполненным `estimate_point`.
+- **BR-T3 — Массовость через Plane.** Массовый перевод N задач в «Оценка» (multi-select Plane)
+  оценивает все N; каждый issue обрабатывается независимо (N вебхуков). Отдельный массовый UX в
+  оркестраторе не требуется.
+- **BR-T4 — Пере-оценка много раз (идемпотентно).** Повторный перевод задачи в «Оценка»
+  переоценивает её заново; прогноз и строка леджера **перезаписываются** (не дублируются). Число
+  пере-оценок не ограничено.
+- **BR-T5 — Fail-closed статус.** На доске без статуса «Оценка» (enduro / частичная конфигурация /
+  Plane недоступен) триггер **не активируется** (ключ резолвится в `None`) — нулевая регрессия;
+  это инфра-предусловие (NFR-7), а не ошибка.
+- **BR-T6 — Не нарушать машину стадий и in-flight работу.** Статус «Оценка» запускает **side-
+  механизм**, а не переход стадии. Если у issue есть **активная** pipeline-задача (queued/running
+  job), триггер — **no-op + лог** (не выдёргивать выполняемую работу в Backlog, не трогать
+  `STAGE_TRANSITIONS`). Авто-возврат в Backlog **не** создаёт цикла: статус `Backlog` ни одной веткой
+  `handle_issue_updated` не обрабатывается (no-op-эхо).
+
+### Содержание оценки (сохранено, согласовано с триггером)
 - **BR-1 — Прогноз.** Для задачи оркестратор производит прогноз четырёх величин: **стоимость ($)**,
   **время**, **токены** и **сложность в story points** из фиксированной шкалы `{1,2,3,5,8}`.
 - **BR-2 — База оценки — история.** Прогноз строится на истории похожих **завершённых** задач (по
   типу/стадиям/стеку): средние токены/время/стоимость из уже накопленной фактуры (`agent_runs`,
   `task_usage_summary`, `agent_cost_totals`, тайминги). При отсутствии истории — разумный bootstrap-
   дефолт (не блокирует).
-- **BR-3 — Шкала story points фиксированная** с точной семантикой `1/2/3/5/8` (см. §2). Значение `8`
-  трактуется как «эпик — разбивать».
-- **BR-4 — Обязательность для всех.** Оценка производится для **каждой** задачи (всех проектов общего
-  прода) автоматически; строго best-effort.
-- **BR-5 — Доступность до старта работы.** Прогноз доступен **до** перевода задачи в работу
-  (на бэклоге/триаже, до `To Analyse`/`start_pipeline`), чтобы заказчик планировал отправку задач.
-- **BR-6 — Пакетная оценка и пере-оценка.** Поддержать оценку/пере-оценку **всех** backlog-задач
-  проекта одним вызовом; пере-оценка применима при изменении скоупа задачи.
+- **BR-3 — Шкала story points фиксированная** с точной семантикой `1/2/3/5/8` (см. §2). Значение `8` —
+  «эпик: разбивать».
+- **BR-4 — On-demand, не блокирующая.** Оценка производится **по запросу** (перевод в «Оценка»), а не
+  для каждой задачи автоматически; строго best-effort — сбой/выключение оценки **никогда** не тормозит
+  конвейер и не меняет маршрут.
+- **BR-5 — Доступность до старта работы.** Поскольку оператор оценивает задачи на **бэклоге** (до
+  `To Analyse`/`start_pipeline`), прогноз доступен **до** перевода задачи в работу — он и нужен для
+  планирования отправки задач.
 - **BR-7 — Запись прогноза в Plane.** Прогноз сложности (story points) записывается в поле issue
   **`estimate_point`** (= ОЦЕНКА).
-- **BR-8 — Запись факта в Plane.** По завершении задачи фактическая реализованная сложность (story
-  points, выведенная из фактических токенов/времени/стоимости по той же шкале) записывается в
-  смежное поле **`point`** — для калибровки.
+- **BR-8 — Запись факта в Plane.** По завершении задачи (переход в `done`) фактическая реализованная
+  сложность (story points из фактических токенов/времени/стоимости по той же шкале) записывается в
+  смежное поле **`point`** — для калибровки; прогноз `estimate_point` при этом **не перезаписывается**.
 - **BR-9 — Отображение на двух поверхностях.** Прогноз публикуется: (a) **Plane-комментом**;
   (b) пунктом **«Оценка»** в общей Telegram-карточке задачи — **время, токены, стоимость**.
-- **BR-10 — Леджер прогноз↔факт (калибровка).** Прогноз и факт сохраняются локально вместе с дельтой;
-  это фундамент петли уточнения модели оценки (связь с ORCH-8). Достаточно фиксировать обе величины
-  и дельту (авто-уточнение модели — позже).
+- **BR-10 — Леджер прогноз↔факт (калибровка).** Прогноз и факт сохраняются локально вместе с дельтой
+  (ключ `work_item_id`); фундамент петли уточнения модели оценки (связь с ORCH-8). Достаточно
+  фиксировать обе величины и дельту (авто-уточнение модели — позже).
 
 ## 5. Нефункциональные требования (NFR)
-- **NFR-1 — Оценка ≠ Quality Gate.** Модуль — наблюдатель/продюсер. `STAGE_TRANSITIONS` / `QG_CHECKS`
-  / `check_*` / machine-verdict-ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/
-  `security_status:`/`coverage_status:`) / схемы **существующих** таблиц — **байт-в-байт не тронуты**.
-  Оценка никогда не влияет на продвижение задачи по стадиям.
+- **NFR-1 — Оценка ≠ Quality Gate / ≠ переход стадии.** Модуль — наблюдатель/продюсер.
+  `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи (`verdict:`/`result:`/
+  `deploy_status:`/`staging_status:`/`security_status:`/`coverage_status:`) / схемы **существующих**
+  таблиц — **байт-в-байт не тронуты**. Статус «Оценка» не добавляет ребра в машину стадий; он
+  запускает side-механизм и сам возвращает issue в Backlog.
 - **NFR-2 — leaf-паттерн.** never-raise (любой сбой → warning + безопасный дефолт), kill-switch
   `*_enabled`, скоуп `*_repos` (CSV; **пусто → self-hosting only**), read-only блок в `GET /queue`.
 - **NFR-3 — self-hosting safety.** Модуль не рестартит/не роняет прод-контейнер, не трогает `main`/
@@ -127,40 +184,55 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
   `resolve_agent_effort`/`_spawn` не модифицируются). Выключенный флаг / неприменимый репо → нулевая
   регрессия для `enduro-trails` и `orchestrator`.
 - **NFR-4 — Стоимость оценки ≪ её ценности.** Сама оценка должна быть дешёвой и быстрой относительно
-  выгоды планирования (оценка не должна стоить дороже экономии). Выбор механизма (эвристика по
-  истории / отдельный LLM-вызов-оценщик / гибрид) и баланс «точность vs стоимость» — **архитектурное**
-  решение (`06-adr`); в TRZ фиксируется лишь требование-ограничение.
-- **NFR-5 — Запись в Plane через существующие примитивы.** `estimate_point`/`point`/коммент пишутся
-  через `plane_sync` и подчиняются sandbox write-guard (ORCH-117): в боевом рантайме (`uvicorn`) —
-  штатная запись, из тест/worktree-процесса — заблокирована. **Новых секретов/токенов не вводится.**
-- **NFR-6 — Fail-safe записи в Plane.** Если поле/estimate-система Plane не сконфигурированы, запись
-  `estimate_point`/`point` **не роняет** конвейер (best-effort пропуск + лог). **Инфра-предусловие:**
-  в проекте Plane должна быть настроена estimate-система со значениями `1/2/3/5/8` (Fibonacci) для
-  `estimate_point`; деталь — `07-infra-requirements.md` (архитектор).
-- **NFR-7 — Обратная совместимость данных.** Хранение прогноз↔факт — **аддитивная** новая таблица
+  выгоды планирования. Выбор механизма (эвристика по истории / отдельный LLM-вызов / гибрид) и баланс
+  «точность vs стоимость» — **архитектурное** решение (`06-adr`); в TRZ — лишь требование-ограничение.
+- **NFR-5 — Толерантность к массовости.** Массовый перевод (десятки задач разом → десятки вебхуков
+  почти одновременно) **не должен** перегружать прод/конвейер: оценка best-effort, изолирована от
+  control-path; механизм сглаживания нагрузки (дешёвая эвристика / очередь / троттлинг) — деталь
+  `06-adr`. Требование: bulk не роняет и не тормозит обслуживание других проектов.
+- **NFR-6 — Запись в Plane через существующие примитивы.** `estimate_point`/`point`/коммент/возврат в
+  Backlog пишутся через `plane_sync` и подчиняются sandbox write-guard (ORCH-117): в боевом рантайме
+  (`uvicorn`) — штатная запись, из тест/worktree-процесса — заблокирована. **Новых секретов/токенов не
+  вводится.**
+- **NFR-7 — Fail-safe и инфра-предусловия Plane.** (a) Статус **«Оценка»** должен существовать на
+  доске проекта (его отсутствие = fail-closed no-op, BR-T5). (b) estimate-система Plane со значениями
+  `1/2/3/5/8` (Fibonacci) для `estimate_point` должна быть настроена; при её отсутствии запись
+  `estimate_point`/`point` **best-effort пропускается** (+ лог) и **не роняет** конвейер. Детали и
+  точные группы статуса — `07-infra-requirements.md` (архитектор).
+- **NFR-8 — Обратная совместимость данных.** Хранение прогноз↔факт — **аддитивная** новая таблица
   (`CREATE TABLE IF NOT EXISTS`); существующие таблицы/колонки не изменяются.
 
 ## 6. Допущения и ограничения
-- Фактура `usage.py`/`agent_runs` достаточна для расчёта факта (токены/стоимость/время) при
-  завершении; «фактические story points» выводятся из факта по той же шкале `{1,2,3,5,8}`.
-- Без ORCH-13 «выбор модели» бессмысленен (один дефолт) — поэтому Шаг 2 корректно вынесен в follow-up.
+- Оценка на бэклоге работает по **issue** (описание/тип/лейблы из Plane API + история похожих), а не
+  по локальной pipeline-задаче: на момент оценки `tasks`-строки может **не быть** → леджер и запись
+  ключуются по `work_item_id`, `task_id` — нуллабелен до старта пайплайна.
+- Статус «Оценка» — транзиентный (issue в нём лишь на время оценки, затем Backlog); его Plane-группа
+  (`backlog`/`unstarted`) косметична — деталь онбординга/инфры (ORCH-009 расширяется на 23-й статус).
+- Фактура `usage.py`/`agent_runs` достаточна для расчёта факта при завершении; «фактические story
+  points» выводятся из факта по той же шкале `{1,2,3,5,8}`.
+- Без ORCH-13 «выбор модели» бессмыслен (один дефолт) — Шаг 2 корректно вынесен в follow-up.
 - Точная Plane-семантика `estimate_point` (FK на estimate-point estimate-системы) vs `point`
-  (целочисленный) — деталь реализации/инфры (архитектор + NFR-6).
-- Точка интеграции триггера «оценка до старта» (webhook создания issue / отдельный статус / эндпоинт)
-  — реализационная деталь; требование — прогноз доступен ДО `To Analyse` (BR-5).
+  (целочисленный) — деталь реализации/инфры (архитектор + NFR-7).
 
 ## 7. Критерии успеха
-Заказчик до отправки задачи в работу видит прогноз (стоимость/время/токены/story points) в Plane-
-комменте и в Telegram-карточке; прогноз записан в `estimate_point`; по завершении факт записан в
-`point`; прогноз и факт сохранены локально для калибровки; всё это — без единого изменения
-control-path/гейтов и без касания горячего пути запуска агентов; при выключенном флаге — нулевая
-регрессия. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+Заказчик **массово переводит** задачи бэклога в статус **«Оценка»**; по каждой оркестратор
+производит прогноз (стоимость/время/токены/story points), пишет его в `estimate_point`, публикует в
+Plane-комменте и пункте «Оценка» Telegram-карточки, сохраняет в леджер прогноз↔факт и **возвращает
+issue в Backlog**; пере-оценка повтором перевода идемпотентна; по завершении задачи факт пишется в
+`point`. Всё это — без единого изменения control-path/гейтов, без касания горячего пути запуска
+агентов, без выдёргивания in-flight работы; на доске без статуса «Оценка» / при выключенном флаге —
+нулевая регрессия. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
 
 ## 8. Риски
-- **Запись в боевой Plane** (`estimate_point`/`point`/коммент) на общей доске — снимается write-guard
-  (ORCH-117) + best-effort/fail-safe (NFR-5/NFR-6).
-- **Неточность прогноза на холодном старте** (мало истории) — снимается bootstrap-дефолтом + петлёй
-  калибровки (BR-10).
-- **Расползание в Шаг 2** (control-path) — снимается жёстким out-of-scope + NFR-3.
-- **Стоимость самой оценки** — снимается NFR-4 (механизм выбирает архитектор).
+- **Статус «Оценка» дёргает in-flight задачу** → снимается BR-T6 (no-op при активном job) + авто-
+  возврат только в Backlog, никогда не трогая стадии.
+- **Цикл вебхуков** (возврат в Backlog → новый webhook) → снимается тем, что `Backlog` не
+  обрабатывается ни одной веткой `handle_issue_updated` (no-op-эхо) — анти-loop по построению.
+- **Перегрузка от массового перевода** → снимается NFR-5 (best-effort, дешёвый механизм/сглаживание —
+  `06-adr`).
+- **Запись в боевой Plane** (`estimate_point`/`point`/коммент/состояние) на общей доске → снимается
+  write-guard (ORCH-117) + best-effort/fail-safe (NFR-6/NFR-7).
+- **Неточность прогноза на холодном старте** (мало истории) → bootstrap-дефолт + петля калибровки
+  (BR-10).
+- **Расползание в Шаг 2** (control-path) → жёсткий out-of-scope + NFR-3.
 Детальный разбор — `10-tech-risks.md` (архитектор).

docs/work-items/ORCH-020/02-trz.md

@@ -4,125 +4,163 @@ stage: analysis
 author_agent: analyst
 status: ready-for-review
 created_at: 2026-06-17
-model_used: claude-fable-5
+model_used: claude-opus-4-8
 ---
 
-# 02 — ТЗ (TRZ): ORCH-020 — Оценка задачи (story-point прогноз + калибровка)
+# 02 — ТЗ (TRZ): ORCH-020 — Оценка задачи, запускаемая Plane-статусом «Оценка»
 
 Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 
 > ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
 > Архитектурное обоснование/решения (выбор механизма оценки эвристика vs LLM vs гибрид, точные
-> сигнатуры врезок, индексы, формулы маппинга, точка триггера) — задача архитектора (`06-adr`).
+> сигнатуры врезок, индексы, формулы маппинга, сглаживание массовой нагрузки, Plane-группа статуса
+> «Оценка») — задача архитектора (`06-adr`).
 
 ## 1. Сводка изменения
 
-Вводится **новый leaf-модуль оценки** (`src/estimator.py`, never-raise), который для задачи
-прогнозирует **стоимость / время / токены / сложность (story points `{1,2,3,5,8}`)** на основе
-истории завершённых задач (агрегаты `src/usage.py`). Прогноз: (a) пишется в Plane-поле
-`estimate_point`, (b) публикуется Plane-комментом, (c) добавляется пунктом «Оценка» (время/токены/
-стоимость) в общую Telegram-карточку. По завершении задачи **факт** (story points из фактических
-токенов/времени/стоимости) пишется в Plane-поле `point`. Прогноз и факт сохраняются в **новой
-аддитивной таблице** `task_estimates` (леджер прогноз↔факт для калибровки). Оценка обязательна для
-всех задач (best-effort), доступна **до** старта работы и **пакетно** по бэклогу.
+Вводится **новый операторский Plane-статус «Оценка»** — триггер механизма оценки (по образцу
+action-статусов **STOP**/ORCH-090 и **Confirm Deploy**/ORCH-059). Перевод issue в «Оценка»
+(в т.ч. **массово** через Plane multi-select) запускает **новый leaf-модуль оценки**
+(`src/estimator.py`, never-raise), который прогнозирует **стоимость / время / токены / сложность
+(story points `{1,2,3,5,8}`)** на основе истории завершённых задач (агрегаты `src/usage.py`).
+Прогноз: (a) пишется в Plane-поле `estimate_point`, (b) публикуется Plane-комментом, (c) добавляется
+пунктом «Оценка» (время/токены/стоимость) в общую Telegram-карточку, (d) сохраняется в **новой
+аддитивной таблице** `task_estimates` (леджер прогноз↔факт, ключ `work_item_id`). По завершении
+оценки оркестратор **возвращает issue в статус `Backlog`**. По завершении самой задачи (переход в
+`done`) **факт** пишется в Plane-поле `point`. Пере-оценка — повтор перевода в «Оценка»
+(идемпотентно).
 
-**Инвариант (NFR-1/NFR-3):** оценка — наблюдатель/продюсер, **не** Quality Gate. `STAGE_TRANSITIONS`
-/ `QG_CHECKS` / `check_*` / machine-verdict-ключи / схемы существующих таблиц — байт-в-байт; горячий
-путь `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — не трогается.
+**Инвариант (NFR-1/NFR-3):** оценка — наблюдатель/продюсер, **не** Quality Gate и **не** переход
+стадии. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схемы существующих
+таблиц — байт-в-байт; горячий путь `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — не
+трогается. Статус «Оценка» не добавляет ребра в машину стадий.
 
 ## 2. Задействованные модули / пути
 | Путь | Действие |
 |------|----------|
-| `src/estimator.py` | **создать** — leaf: прогноз (история→{токены,время,стоимость,story_points}), маппинг величин→story-point bucket `{1,2,3,5,8}`, never-raise, `applies(repo)`, `snapshot()` |
+| `src/plane_sync.py` | **изменить** — (1) `_PLANE_NAME_TO_KEY += {"Оценка": "estimate"}`; ключ `estimate` **НЕ добавлять** в `_DEFAULT_STATES` (fail-closed, как `stop`/`confirm_deploy`); (2) новые write-хелперы `set_issue_estimate_point(work_item, value)`, `set_issue_point(work_item, value)`, `set_issue_backlog(work_item)` (все через guard `_guard_allows_write`, ORCH-117); (3) read-хелпер текущих полей `estimate_point`/`point`. fail-safe при отсутствии estimate-конфига |
+| `src/webhooks/plane.py` | **изменить** — в `handle_issue_updated` добавить **fail-closed ветку** `estimate_state = proj_states.get("estimate")` → `handle_estimate(data, project_id)` (распознаётся как **отдельный** жест, не алиасит stop/to_analyse/confirm_deploy/approved/rejected). Новый `handle_estimate`: резолв issue (pipeline-задачи может не быть), guard `estimator.applies(repo)`, guard «нет активного job» (BR-T6), запуск оценки, затем `set_issue_backlog` |
+| `src/estimator.py` | **создать** — leaf: `estimate(work_item_id, issue|description, repo)` → прогноз `{tokens,seconds,cost_usd,story_points}`; маппинг величин → story-point bucket `{1,2,3,5,8}` (чистая функция); расчёт факта из `usage.py`; `applies(repo)`, `should_estimate(task|None)` (анти-disruption), `snapshot()`; never-raise |
 | `src/db.py` | **изменить** — аддитивная таблица `task_estimates` (`CREATE TABLE IF NOT EXISTS` в `init_db()`) + хелперы `record_estimate`/`set_actual`/`get_estimate`/`estimates_snapshot`; существующие таблицы/колонки не трогать |
-| `src/usage.py` | **переиспользовать** (read-only) — `task_usage_summary` / `agent_cost_totals` / тайминги для расчёта **факта**; при необходимости тонкий read-only агрегат «история похожих задач» |
-| `src/plane_sync.py` | **изменить** — новые write-хелперы `set_issue_estimate_point(work_item, value)` и `set_issue_point(work_item, value)` (через существующий guard `_guard_allows_write`, ORCH-117) + read-хелпер текущих полей; fail-safe при отсутствии estimate-конфига |
-| `src/notifications.py` | **изменить** — добавить пункт «Оценка» (время · токены · стоимость) в рендер общей карточки задачи; never-raise, пустой прогноз → пункт опускается |
-| `src/webhooks/plane.py` | **изменить** — триггер оценки на бэклоге (до `To Analyse`/`start_pipeline`, BR-5) + запись факта `point` по завершении (на переходе в `done`) |
-| `src/main.py` | **изменить** — эндпоинты `POST /estimate`, `POST /estimate/backlog`, (опц.) `GET /estimate`; read-only блок `estimator` в `GET /queue` |
+| `src/usage.py` | **переиспользовать** (read-only) — `task_usage_summary`/`agent_cost_totals`/тайминги для **факта**; при необходимости тонкий read-only агрегат «история похожих задач» |
+| `src/notifications.py` | **изменить** — пункт «Оценка» (время · токены · стоимость) в рендере общей карточки; never-raise, пустой прогноз → пункт опускается |
+| `src/main.py` | **изменить** — (опц.) `POST /estimate?work_item=<id>` / `POST /estimate/backlog` как программное удобство; **read-only блок `estimator` в `GET /queue`** |
 | `src/config.py` | **изменить** — флаги (см. §7) |
 | `tests/test_orch020_estimator.py` | **создать** — покрытие (см. `04-test-plan.yaml`) |
 
 ## 3. Функциональные требования
 
-### FR-1 — Прогноз задачи (BR-1, BR-2, BR-3)
-`estimator.estimate(work_item_id|task)` возвращает структуру `{forecast_tokens, forecast_seconds,
-forecast_cost_usd, story_points}` где `story_points ∈ {1,2,3,5,8}`. Прогноз строится на истории
-похожих **завершённых** задач (средние токены/время/стоимость из `usage.py`-агрегатов); при пустой
-истории — bootstrap-дефолт. Маппинг величин → story-point bucket — чистая функция (пороги — деталь
-`06-adr`). never-raise: любой сбой → безопасный дефолт + warning, без исключения наружу.
+### FR-T1 — Статус «Оценка» как триггер (BR-T1, BR-T5)
+`_PLANE_NAME_TO_KEY["Оценка"] = "estimate"`; ключ `estimate` **отсутствует** в `_DEFAULT_STATES`.
+В `handle_issue_updated` — отдельная ветка: `estimate_state = proj_states.get("estimate")`;
+`if estimate_state and new_state == estimate_state: await handle_estimate(...)`. Доска без статуса →
+`estimate_state is None` → ветка инертна (fail-closed, зеркало `stop`/`confirm_deploy`). Ветка не
+должна аннулировать/перехватывать STOP/`to_analyse`/`confirm_deploy`/approved/rejected (UUID
+«Оценка» отличен от всех; порядок ветки выбирает архитектор, инвариант — взаимоисключение жестов).
 
-### FR-2 — Семантика story points (BR-3)
+### FR-T2 — Обработчик `handle_estimate` (BR-T1, BR-T6)
+`handle_estimate(data, project_id)`: резолвит `plane_id`/`work_item_id`; `repo` определяется по
+проекту. Guard-цепочка (все — no-op-with-log при невыполнении, never-raise):
+1. `estimator.applies(repo)` — kill-switch + скоуп (False → no-op);
+2. **анти-disruption (BR-T6):** если у issue есть pipeline-задача с **активным** job
+   (`has_active_job_for_task`) → no-op + лог (не выдёргивать in-flight работу). Issue без задачи
+   (бэклог) или с терминальной/idle-задачей → оценка допустима.
+Далее: `estimator.estimate(...)` → запись прогноза (FR-T3) → **`set_issue_backlog(work_item)`**
+(BR-T2). Контракт never-raise: любая ошибка логируется, вебхук-флоу не падает.
+
+### FR-T3 — Прогноз задачи (BR-1, BR-2, BR-3)
+`estimator.estimate(work_item_id, description|issue, repo)` возвращает `{forecast_tokens,
+forecast_seconds, forecast_cost_usd, story_points}`, `story_points ∈ {1,2,3,5,8}`. База — история
+похожих **завершённых** задач (средние токены/время/стоимость из `usage.py`-агрегатов); пустая
+история → bootstrap-дефолт. Маппинг величин → bucket — чистая функция (пороги — `06-adr`).
+never-raise: сбой → безопасный дефолт + warning.
+
+### FR-T4 — Семантика story points (BR-3)
 Шкала фиксированная: `1` docs/label/config · `2` небольшой фикс · `3` средняя · `5` сложная
 (код+тесты) · `8` эпик/разбивать. Значения вне набора не выдаются.
 
-### FR-3 — Доступность до старта + обязательность (BR-4, BR-5)
-Оценка выполняется автоматически для каждой задачи **до** перевода в работу (точка интеграции в
-`webhooks/plane.py`, до `start_pipeline`). best-effort: сбой/выключение оценки **никогда** не тормозит
-конвейер и не меняет маршрут.
+### FR-T5 — Авто-возврат в Backlog + анти-loop (BR-T2, BR-T6)
+После оценки `handle_estimate` зовёт `set_issue_backlog(work_item)` → issue возвращается в `Backlog`.
+Это **не** создаёт цикла: `Backlog`-UUID не совпадает ни с одной триггер-веткой `handle_issue_updated`
+(`stop`/`to_analyse`/`confirm_deploy`/`approved`/`rejected`/`estimate`) → входящий webhook «state →
+Backlog» = no-op-эхо. Возврат best-effort: сбой записи статуса не роняет флоу (прогноз уже записан).
 
-### FR-4 — Пакетная оценка и пере-оценка (BR-6)
-`POST /estimate/backlog` (или `?all=true`) оценивает/переоценивает все backlog-задачи проекта;
-`POST /estimate?work_item=<id>` — одну задачу (в т.ч. пере-оценка при изменении скоупа).
-Идемпотентно: повторный вызов перезаписывает прогноз и обновляет `task_estimates`/`estimate_point`.
+### FR-T6 — Массовость и пере-оценка (BR-T3, BR-T4)
+Массовый перевод N задач в «Оценка» = N независимых `issue.updated`-вебхуков → N вызовов
+`handle_estimate` (никакого спец-batch-кода). Пере-оценка = повторный перевод: `estimate`
+идемпотентно **перезаписывает** прогноз в `task_estimates` (UPSERT по `work_item_id`) и
+`estimate_point`; дублей строк нет.
 
-### FR-5 — Запись прогноза и факта в Plane (BR-7, BR-8, NFR-5, NFR-6)
+### FR-T7 — Запись прогноза и факта в Plane (BR-7, BR-8, NFR-6, NFR-7)
 - Прогноз story points → `set_issue_estimate_point` → поле issue `estimate_point`.
-- По завершении задачи (переход в `done`): из `usage.py` считается факт (токены/время/стоимость) →
-  маппится в story-point bucket → `set_issue_point` → поле issue `point`.
-- Обе записи через `plane_sync` под guard ORCH-117; отсутствие estimate-конфига/поля → best-effort
+- По завершении задачи (переход в `done`, врезка в существующий done-путь): из `usage.py` считается
+  факт (токены/время/стоимость) → маппится в story-point bucket → `set_issue_point` → поле `point`;
+  `estimate_point` не перезаписывается.
+- Все записи через `plane_sync` под guard ORCH-117; отсутствие estimate-конфига/поля → best-effort
   пропуск + лог (не падать).
 
-### FR-6 — Отображение (BR-9)
+### FR-T8 — Отображение (BR-9)
 - **Plane-коммент** с прогнозом (стоимость/время/токены/story points) — `plane_sync.add_comment`.
 - **Telegram-карточка** — пункт **«Оценка»**: время · токены · стоимость (`notifications`).
 Обе поверхности — best-effort, не блокируют конвейер.
 
-### FR-7 — Леджер прогноз↔факт (BR-10)
-`task_estimates` хранит прогноз (на момент оценки) и факт (на момент `done`) + дельту. Это фундамент
-калибровки (ORCH-8); авто-уточнение модели в объём ORCH-020 не входит.
+### FR-T9 — Леджер прогноз↔факт (BR-10)
+`task_estimates` хранит прогноз (на момент оценки) и факт (на момент `done`) + дельту, ключ
+`work_item_id` (т.к. на момент оценки `task_id` может быть `NULL` — issue на бэклоге). Фундамент
+калибровки (ORCH-8); авто-уточнение модели в объём не входит.
 
-### FR-8 — leaf-инварианты (NFR-2, NFR-3)
+### FR-T10 — leaf-инварианты (NFR-2, NFR-3)
 `applies(repo)` = `estimator_enabled` ∧ скоуп `estimator_repos` (пусто → self-hosting only),
-проверяется локально и ПЕРВЫМ (без сети). Выключено → весь модуль инертен (нулевая регрессия).
-read-only блок `estimator` в `GET /queue` (флаг/скоуп/счётчики прогнозов и записей).
+проверяется локально и ПЕРВЫМ (без сети). Выключено → весь модуль инертен (нулевая регрессия:
+статус «Оценка» не обрабатывается, ничего не пишется). read-only блок `estimator` в `GET /queue`
+(флаг/скоуп/счётчики прогнозов/записей/возвратов-в-Backlog).
 
 ## 4. Изменения API
 | Метод/путь | Назначение |
 |------------|-----------|
-| `POST /estimate?work_item=<id>` | Произвести/обновить прогноз одной задачи (пишет `estimate_point` + коммент + строку карточки + `task_estimates`) |
-| `POST /estimate/backlog` (или `?all=true`, опц. `?project=`) | Пакетно оценить/переоценить backlog-задачи проекта (BR-6) |
+| **Plane-статус «Оценка»** (не HTTP-эндпоинт) | **Основной триггер**: перевод issue в статус → `handle_estimate`. Массовость — multi-select Plane. |
+| `POST /estimate?work_item=<id>` *(опц.)* | Программно произвести/обновить прогноз одной задачи (то же ядро, что статус-триггер) — удобство/диагностика, не основной путь |
+| `POST /estimate/backlog` *(опц.)* | Программно оценить backlog-задачи проекта — удобство; основной массовый путь — статус «Оценка» |
 | `GET /estimate?work_item=<id>` *(опц.)* | Прочитать текущий прогноз vs факт из `task_estimates` |
-| `GET /queue` | **+ read-only блок `estimator`** (флаг/скоуп/счётчики); existing-поля не меняются |
+| `GET /queue` | **+ read-only блок `estimator`**; existing-поля не меняются |
 
-Существующие эндпоинты/контракты не изменяются.
+Существующие эндпоинты/контракты не изменяются. Webhook-контракт `issue.updated` не меняется —
+добавляется лишь распознавание ещё одного целевого статуса.
 
 ## 5. Изменения схемы БД
 **Новая аддитивная таблица** `task_estimates` (`CREATE TABLE IF NOT EXISTS`, без правки существующих):
-`work_item_id` · `task_id` · `repo` · прогноз (`forecast_tokens`, `forecast_seconds`,
-`forecast_cost_usd`, `forecast_story_points`) · факт (`actual_tokens`, `actual_seconds`,
-`actual_cost_usd`, `actual_story_points`) · дельта (`delta_*` или вычисляемая) · `source`
-(`auto`/`manual`) · `created_at` · `updated_at`. Точные типы/индексы/уникальность — `06-adr`.
-Существующие таблицы (`tasks`/`agent_runs`/`jobs`/…) — **не изменяются**.
+`work_item_id` (ключ/UPSERT-цель) · `task_id` (нуллабелен до старта пайплайна) · `repo` · прогноз
+(`forecast_tokens`, `forecast_seconds`, `forecast_cost_usd`, `forecast_story_points`) · факт
+(`actual_tokens`, `actual_seconds`, `actual_cost_usd`, `actual_story_points`) · дельта (`delta_*`
+или вычисляемая) · `source` (`status`/`manual`/`api`) · `estimate_count` (число пере-оценок,
+опц.) · `created_at` · `updated_at`. Точные типы/индексы/уникальность (UNIQUE по `work_item_id`
+для идемпотентного UPSERT) — `06-adr`. Существующие таблицы (`tasks`/`agent_runs`/`jobs`/…) — **не
+изменяются** (NFR-8).
 
 ## 6. Требования к новым/изменённым QG checks
-**Нет.** Оценка — наблюдатель/продюсер, не Quality Gate. `QG_CHECKS` / `check_*` / machine-verdict-
-ключи / `STAGE_TRANSITIONS` — **не трогаются**. Новых артефактов pipeline (номерных `NN-*.md`) и
-новых вердикт-парсеров не создаётся (оценка публикуется в Plane/Telegram/`task_estimates`, не во
-frontmatter-гейтах).
+**Нет.** Оценка — наблюдатель/продюсер, не Quality Gate; статус «Оценка» — операторский side-триггер,
+не ребро `STAGE_TRANSITIONS`. `QG_CHECKS` / `check_*` / machine-verdict-ключи / `STAGE_TRANSITIONS` —
+**не трогаются**. Новых номерных артефактов pipeline (`NN-*.md`) и новых вердикт-парсеров нет (оценка
+публикуется в Plane/Telegram/`task_estimates`, не во frontmatter-гейтах).
 
 ## 7. Совместимость / регресс
 - **Флаги** (`config.py`, дефолты безопасные): `estimator_enabled` (kill-switch, env
   `ORCH_ESTIMATOR_ENABLED`), `estimator_repos` (CSV, env `ORCH_ESTIMATOR_REPOS`; **пусто →
-  self-hosting only**). Доп. тюнинг (bootstrap-дефолты, пороги bucket) — конфиг-ключи на усмотрение
-  `06-adr`.
-- **Откат** = `ORCH_ESTIMATOR_ENABLED=false` → модуль инертен: ни записи в Plane, ни строки карточки,
-  ни таблицы-обращений; конвейер байт-в-байт до ORCH-020.
-- **Область раската:** по умолчанию self-hosting `orchestrator`; `enduro-trails` не затронут
-  (скоуп `estimator_repos` пуст).
+  self-hosting only**). Доп. тюнинг (bootstrap-дефолты, пороги bucket, целевой возврат-статус,
+  сглаживание массовой нагрузки) — конфиг-ключи на усмотрение `06-adr`.
+- **Откат** = `ORCH_ESTIMATOR_ENABLED=false` → модуль инертен: статус «Оценка» не обрабатывается
+  (`applies`=False до сети), ни записи в Plane, ни строки карточки, ни обращений к таблице; конвейер
+  байт-в-байт до ORCH-020. Доп. откат «на уровне доски» — не создавать статус «Оценка» (fail-closed,
+  BR-T5).
+- **Область раската:** по умолчанию self-hosting `orchestrator`; `enduro-trails` не затронут (скоуп
+  `estimator_repos` пуст + на его доске статуса «Оценка» нет → fail-closed).
 - **never-raise / fail-safe:** все публичные функции и врезки изолированы (`try/except` → warning +
-  безопасный дефолт). Сбой оценки/записи в Plane/рендера карточки — не роняет конвейер (NFR-2/5/6).
+  безопасный дефолт). Сбой оценки/записи в Plane/возврата статуса/рендера карточки — не роняет
+  конвейер (NFR-2/6/7).
+- **Анти-disruption / анти-loop:** активный job → no-op (BR-T6); возврат в Backlog — no-op-эхо
+  (FR-T5). Машина стадий и in-flight задачи не затрагиваются.
 - **Горячий путь не тронут:** `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — без изменений
-  (NFR-3). in-flight задачи и чужие репозитории не затрагиваются.
-- **Инфра-предусловие (NFR-6):** estimate-система Plane (`1/2/3/5/8`) для `estimate_point`; при её
-  отсутствии запись best-effort пропускается (фиксируется в `07-infra-requirements.md` архитектором).
+  (NFR-3).
+- **Инфра-предусловия (NFR-7):** (a) статус **«Оценка»** на доске проекта (онбординг ORCH-009 →
+  23-й статус; группа — `06-adr`/`07-infra-requirements.md`); (b) estimate-система Plane
+  (`1/2/3/5/8`) для `estimate_point`; их отсутствие → fail-closed/best-effort пропуск, не падение.

docs/work-items/ORCH-020/03-acceptance-criteria.md

@@ -4,10 +4,10 @@ stage: analysis
 author_agent: analyst
 status: ready-for-review
 created_at: 2026-06-17
-model_used: claude-fable-5
+model_used: claude-opus-4-8
 ---
 
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-020 — Оценка задачи (story-point прогноз + калибровка)
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-020 — Оценка задачи, запускаемая статусом «Оценка»
 
 Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 
@@ -16,15 +16,77 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 
 ---
 
+## AC-T1 — Запуск оценки статусом «Оценка» (ядро ревизии)
+
+**Условие:** перевод issue в Plane-статус «Оценка» запускает оценку этой задачи.
+- **PASS:** `_PLANE_NAME_TO_KEY` содержит `"Оценка" → "estimate"`; `handle_issue_updated` имеет
+  отдельную ветку `proj_states.get("estimate")` → `handle_estimate(...)`; при переводе issue в
+  «Оценка» вызывается оценка (прогноз вычислен и записан).
+- **FAIL:** триггера-статуса нет; оценка по-прежнему авто-запускается на каждой задаче в
+  `start_pipeline`; ветка «Оценка» аннулирует/перехватывает STOP/`to_analyse`/`confirm_deploy`/
+  approved/rejected.
+
+---
+
+## AC-T2 — Авто-возврат в Backlog
+
+**Условие:** по завершении оценки issue возвращается в статус `Backlog`.
+- **PASS:** после записи прогноза `handle_estimate` вызывает `set_issue_backlog(work_item)` и issue
+  оказывается в `Backlog`; возврат best-effort (сбой записи статуса не роняет флоу, прогноз уже
+  записан).
+- **FAIL:** issue остаётся в «Оценка»/ином статусе; возврат отсутствует; сбой возврата роняет вебхук.
+
+---
+
+## AC-T3 — Массовость через Plane
+
+**Условие:** массовый перевод задач в «Оценка» оценивает их все.
+- **PASS:** N задач, переведённых в «Оценка» (multi-select Plane → N `issue.updated`-вебхуков),
+  дают N независимых вызовов `handle_estimate`; каждая получает прогноз; спец-batch-кода для этого не
+  требуется.
+- **FAIL:** часть задач не оценивается; обработка зависит от несуществующего «batch-режима»; один
+  webhook гасит остальные.
+
+---
+
+## AC-T4 — Пере-оценка много раз (идемпотентно)
+
+**Условие:** повторный перевод в «Оценка» переоценивает задачу без дублей.
+- **PASS:** повтор обновляет прогноз в `task_estimates` (UPSERT по `work_item_id`) и `estimate_point`;
+  строка одна, не дублируется; число пере-оценок не ограничено.
+- **FAIL:** повтор создаёт дубль строки в `task_estimates`; повтор игнорируется/падает.
+
+---
+
+## AC-T5 — Fail-closed статус «Оценка»
+
+**Условие:** на доске без статуса «Оценка» триггер не активируется.
+- **PASS:** `estimate` отсутствует в `_DEFAULT_STATES`; на проекте без статуса
+  `proj_states.get("estimate") is None` → ветка инертна (нет KeyError, нет оценки); enduro-trails не
+  затронут.
+- **FAIL:** `estimate` добавлен в `_DEFAULT_STATES`; отсутствие статуса даёт KeyError/ошибку; чужой
+  репо триггерится.
+
+---
+
+## AC-T6 — Анти-disruption in-flight + анти-loop
+
+**Условие:** статус «Оценка» — side-механизм, не трогает выполняемую работу и не зацикливается.
+- **PASS:** issue с активным (queued/running) job → `handle_estimate` = no-op + лог (in-flight работа
+  не выдёргивается в Backlog, стадии не трогаются); возврат в `Backlog` — no-op-эхо (`Backlog`-UUID не
+  совпадает ни с одной триггер-веткой → входящий webhook ничего не запускает).
+- **FAIL:** активную задачу выдёргивает в Backlog/прерывает; возврат в Backlog порождает повторный
+  запуск оценки (цикл); меняется `STAGE_TRANSITIONS`.
+
+---
+
 ## AC-1 — Прогноз четырёх величин
 
-**Условие:** для задачи `estimator.estimate(...)` возвращает прогноз стоимости, времени, токенов и
-сложности (story points).
-- **PASS:** возвращается структура с `forecast_cost_usd`, `forecast_seconds`, `forecast_tokens` и
-  `story_points`, где `story_points ∈ {1,2,3,5,8}`; при пустой истории отдаётся bootstrap-дефолт
-  (не исключение).
-- **FAIL:** отсутствует любая из четырёх величин, либо `story_points` вне набора `{1,2,3,5,8}`, либо
-  функция бросает исключение при отсутствии истории.
+**Условие:** `estimator.estimate(...)` возвращает прогноз стоимости, времени, токенов и сложности.
+- **PASS:** структура с `forecast_cost_usd`, `forecast_seconds`, `forecast_tokens` и `story_points`,
+  `story_points ∈ {1,2,3,5,8}`; пустая история → bootstrap-дефолт (не исключение).
+- **FAIL:** отсутствует любая из четырёх величин; `story_points` вне `{1,2,3,5,8}`; функция бросает
+  исключение при отсутствии истории.
 
 ---
 
@@ -33,25 +95,24 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 **Условие:** маппинг величин → story-point bucket соответствует шкале заказчика.
 - **PASS:** значения и смысл строго `1` (docs/label/config) · `2` (небольшой фикс) · `3` (средняя) ·
   `5` (сложная код+тесты) · `8` (эпик/разбивать); чистая функция маппинга покрыта unit-тестом.
-- **FAIL:** иные значения/градации (напр. свободное число, `4`, `7`) или произвольная числовая шкала.
+- **FAIL:** иные значения/градации (`4`, `7`, свободное число) или произвольная числовая шкала.
 
 ---
 
 ## AC-3 — Запись прогноза в Plane `estimate_point`
 
 **Условие:** прогноз story points записывается в поле issue `estimate_point`.
-- **PASS:** при оценке вызывается `set_issue_estimate_point` (через `plane_sync`/guard ORCH-117);
-  при настроенной estimate-системе значение оказывается в `estimate_point`.
-- **FAIL:** прогноз пишется в `point` (перепутаны поля), не пишется вовсе, либо запись обходит guard.
+- **PASS:** при оценке вызывается `set_issue_estimate_point` (через `plane_sync`/guard ORCH-117); при
+  настроенной estimate-системе значение оказывается в `estimate_point`.
+- **FAIL:** прогноз пишется в `point` (перепутаны поля), не пишется, либо запись обходит guard.
 
 ---
 
 ## AC-4 — Запись факта в Plane `point` по завершении
 
-**Условие:** по завершении задачи (переход в `done`) фактическая реализованная сложность пишется в
-смежное поле `point`.
+**Условие:** по завершении задачи (переход в `done`) факт пишется в смежное поле `point`.
 - **PASS:** на `done` факт вычисляется из `usage.py` (токены/время/стоимость), маппится в story-point
-  bucket и пишется в `point`; прогноз (`estimate_point`) при этом не перезаписывается.
+  bucket и пишется в `point`; `estimate_point` не перезаписывается.
 - **FAIL:** факт пишется в `estimate_point`, не пишется, либо затирает прогноз.
 
 ---
@@ -60,9 +121,8 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 
 **Условие:** общая карточка задачи показывает прогноз.
 - **PASS:** в карточке присутствует пункт **«Оценка»** с **временем, токенами и стоимостью**; пустой
-  прогноз → пункт опускается (never-raise).
-- **FAIL:** пункт отсутствует, либо его рендер роняет/ломает карточку, либо инвариант «одна карточка
-  на задачу» нарушен.
+  прогноз → пункт опускается (never-raise); инвариант «одна карточка на задачу» не нарушен.
+- **FAIL:** пункт отсутствует; его рендер роняет/ломает карточку; нарушен инвариант одной карточки.
 
 ---
 
@@ -75,32 +135,35 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 
 ---
 
-## AC-7 — Пакетная оценка и пере-оценка
+## AC-7 — Программные эндпоинты (опциональны, не основной триггер)
 
-**Условие:** бэклог можно оценить/переоценить.
-- **PASS:** `POST /estimate/backlog` оценивает backlog-задачи проекта; `POST /estimate?work_item=<id>`
-  переоценивает одну (идемпотентно перезаписывает прогноз в `task_estimates` и `estimate_point`).
-- **FAIL:** нет пакетного пути, либо повторный вызов дублирует записи вместо обновления.
+**Условие:** программный путь, если реализован, использует то же ядро.
+- **PASS:** `POST /estimate?work_item=<id>` / `POST /estimate/backlog` (если есть) дают тот же
+  результат, что статус-триггер (UPSERT в `task_estimates` + `estimate_point` + коммент + карточка),
+  идемпотентны; их отсутствие не нарушает приёмку (основной путь — статус «Оценка»).
+- **FAIL:** эндпоинт расходится с поведением статус-триггера; преподносится как ЕДИНСТВЕННЫЙ способ
+  запуска (триггер-статуса нет).
 
 ---
 
-## AC-8 — Обязательность + доступность до старта, best-effort
+## AC-8 — On-demand + доступность до старта, best-effort
 
-**Условие:** оценка авто-производится для всех задач **до** старта работы и никогда не блокирует
-конвейер.
-- **PASS:** прогноз появляется до `To Analyse`/`start_pipeline`; при сбое оценки задача всё равно
-  стартует штатно (best-effort, лог-warning).
-- **FAIL:** оценка обязательна как блокирующий шаг (сбой тормозит/меняет маршрут) либо появляется
-  только после старта работы.
+**Условие:** оценка запускается по требованию (статус), доступна до старта работы и никогда не
+блокирует конвейер.
+- **PASS:** оценка идёт по переводу в «Оценка» на бэклоге (до `To Analyse`/`start_pipeline`); при
+  сбое оценки конвейер не затрагивается (best-effort, лог-warning); НЕ авто-обязательна на каждой
+  задаче.
+- **FAIL:** оценка — блокирующий шаг (сбой тормозит/меняет маршрут); оценка авто-навязана каждой
+  задаче на `start_pipeline`.
 
 ---
 
 ## AC-9 — leaf-инварианты (kill-switch / скоуп / GET /queue)
 
 **Условие:** модуль следует leaf-паттерну.
-- **PASS:** `estimator_enabled=false` → модуль полностью инертен (нет записей в Plane/карточку/
-  таблицу); `estimator_repos` пуст → активен только на self-hosting `orchestrator`; есть read-only
-  блок `estimator` в `GET /queue`; все публичные функции never-raise.
+- **PASS:** `estimator_enabled=false` → модуль полностью инертен (статус «Оценка» не обрабатывается,
+  нет записей в Plane/карточку/таблицу); `estimator_repos` пуст → активен только на self-hosting
+  `orchestrator`; есть read-only блок `estimator` в `GET /queue`; все публичные функции never-raise.
 - **FAIL:** при выключенном флаге что-то пишется/меняется; enduro-trails затронут при пустом скоупе;
   нет блока в `GET /queue`; функция бросает наружу.
 
@@ -111,7 +174,7 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 **Условие:** оценка ничего не меняет в машине стадий и горячем пути.
 - **PASS:** `git diff` не затрагивает `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict-
   ключи и схемы существующих таблиц; `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — без
-  изменений; зелёный анти-регресс существующих тестов.
+  изменений; статус «Оценка» не добавлен как ребро стадий; зелёный анти-регресс существующих тестов.
 - **FAIL:** любое из перечисленного изменено; маршрут задачи зависит от результата оценки.
 
 ---
@@ -121,16 +184,16 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 **Условие:** адаптивный выбор модели не реализуется.
 - **PASS:** нет кода, выбирающего/меняющего модель/эффорт по сложности; в `01-brd.md` зафиксирован
   out-of-scope + follow-up на отдельный work item с зависимостью на ORCH-13.
-- **FAIL:** добавлена логика per-task override модели/эффорта, либо follow-up не зафиксирован.
+- **FAIL:** добавлена логика per-task override модели/эффорта; follow-up не зафиксирован.
 
 ---
 
 ## AC-12 — Леджер прогноз↔факт + fail-safe записи
 
 **Условие:** прогноз и факт сохраняются; запись в Plane fail-safe.
-- **PASS:** `task_estimates` (новая аддитивная таблица) хранит прогноз, факт и дельту; при
-  ненастроенной estimate-системе Plane запись `estimate_point`/`point` best-effort пропускается с
-  логом, конвейер не падает.
+- **PASS:** `task_estimates` (новая аддитивная таблица, ключ `work_item_id`, `task_id` нуллабелен)
+  хранит прогноз, факт и дельту; при ненастроенной estimate-системе Plane запись `estimate_point`/
+  `point` best-effort пропускается с логом, конвейер не падает.
 - **FAIL:** существующая схема БД изменена; отсутствие estimate-конфига роняет оценку/конвейер.
 
 ---
@@ -138,15 +201,21 @@ Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
 ## Сводная матрица AC ↔ FR/BR
 | AC | Покрывает |
 |----|-----------|
-| AC-1 | BR-1, BR-2 / FR-1 |
-| AC-2 | BR-3 / FR-2 |
-| AC-3 | BR-7 / FR-5 |
-| AC-4 | BR-8 / FR-5 |
-| AC-5 | BR-9 / FR-6 |
-| AC-6 | BR-9 / FR-6 |
-| AC-7 | BR-6 / FR-4 |
-| AC-8 | BR-4, BR-5 / FR-3 |
-| AC-9 | NFR-2 / FR-8 |
+| AC-T1 | BR-T1, BR-T5 / FR-T1 |
+| AC-T2 | BR-T2 / FR-T5 |
+| AC-T3 | BR-T3 / FR-T6 |
+| AC-T4 | BR-T4 / FR-T6 |
+| AC-T5 | BR-T5 / FR-T1 |
+| AC-T6 | BR-T6 / FR-T2, FR-T5 |
+| AC-1 | BR-1, BR-2 / FR-T3 |
+| AC-2 | BR-3 / FR-T4 |
+| AC-3 | BR-7 / FR-T7 |
+| AC-4 | BR-8 / FR-T7 |
+| AC-5 | BR-9 / FR-T8 |
+| AC-6 | BR-9 / FR-T8 |
+| AC-7 | §2 «Вне объёма» / FR-T6, TRZ §4 |
+| AC-8 | BR-4, BR-5 / FR-T2 |
+| AC-9 | NFR-2 / FR-T10 |
 | AC-10 | NFR-1, NFR-3 |
 | AC-11 | §2 «Вне объёма» (Q-1/Q-2) |
-| AC-12 | BR-10, NFR-6, NFR-7 / FR-5, FR-7 |
+| AC-12 | BR-10, NFR-7, NFR-8 / FR-T7, FR-T9 |

docs/work-items/ORCH-020/04-test-plan.yaml

@@ -3,113 +3,147 @@ stage: analysis
 author_agent: analyst
 status: ready-for-review
 created_at: 2026-06-17
-model_used: claude-fable-5
-title: "Оценка задачи: прогноз {токены,время,стоимость,story points}, запись в Plane, карточка, леджер прогноз↔факт, leaf-инварианты"
+model_used: claude-opus-4-8
+title: "Оценка задачи, запускаемая Plane-статусом «Оценка»: триггер/возврат в Backlog/массовость/пере-оценка + прогноз {токены,время,стоимость,story points}, запись в Plane, карточка, леджер прогноз↔факт, leaf-инварианты"
 framework: pytest
 scope: >
-  Покрывается: расчёт прогноза из истории (usage-агрегаты), маппинг величин -> story-point
-  bucket {1,2,3,5,8} (чистая функция), never-raise/bootstrap при пустой истории, запись прогноза
-  в Plane estimate_point и факта в point (через guard ORCH-117, fail-safe при отсутствии
-  estimate-конфига), пункт "Оценка" в Telegram-карточке, эндпоинты /estimate и /estimate/backlog,
-  read-only блок estimator в GET /queue, аддитивная таблица task_estimates (леджер прогноз<->факт),
+  Покрывается: распознавание статуса «Оценка» как триггера (handle_estimate),
+  fail-closed при отсутствии статуса, авто-возврат issue в Backlog + анти-loop,
+  анти-disruption in-flight (no-op при активном job), массовость (N вебхуков -> N оценок),
+  идемпотентная пере-оценка (UPSERT по work_item_id), расчёт прогноза из истории (usage-агрегаты),
+  маппинг величин -> story-point bucket {1,2,3,5,8} (чистая функция), never-raise/bootstrap при
+  пустой истории, запись прогноза в estimate_point и факта в point (через guard ORCH-117, fail-safe
+  при отсутствии estimate-конфига), пункт "Оценка" в Telegram-карточке, read-only блок estimator в
+  GET /queue, аддитивная таблица task_estimates (ключ work_item_id, task_id нуллабелен),
   kill-switch + скоуп (пусто -> self-hosting only).
   Вне покрытия: адаптивный выбор модели (Шаг 2, вне объёма), авто-уточнение модели оценки (ORCH-8),
   автопереключение трека по сложности (ORCH-19).
 notes: >
   Тесты используют изолированную временную SQLite-БД (фикстура init_db во временном файле) и
-  замоканные plane_sync/notifications/usage — без сети, без боевого Plane/Telegram, без LLM.
-  Запись в Plane проверяется на уровне вызова write-хелперов под guard (ORCH-117 autouse-floor
-  conftest держит opt-in OFF — сетевая запись физически невозможна из теста). Control-path
-  анти-регресс: STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict/схемы существующих таблиц
-  не меняются; полный регресс tests/ остаётся зелёным.
+  замоканные plane_sync/notifications/usage/get_project_states — без сети, без боевого Plane/Telegram,
+  без LLM. Триггер тестируется на уровне handle_issue_updated/handle_estimate с подставленными
+  proj_states (UUID статуса "Оценка"). Запись в Plane проверяется на уровне вызова write-хелперов под
+  guard (ORCH-117 autouse-floor conftest держит opt-in OFF — сетевая запись физически невозможна из
+  теста). Control-path анти-регресс: STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict/схемы
+  существующих таблиц не меняются; полный регресс tests/ остаётся зелёным.
 
 tests:
   - id: TC-01
-    type: unit
-    description: "estimate() возвращает {forecast_tokens,forecast_seconds,forecast_cost_usd,story_points} и story_points в {1,2,3,5,8} (AC-1)"
+    type: integration
+    description: "Триггер: new_state == proj_states['estimate'] -> handle_estimate вызывается; estimate-статус добавлен в _PLANE_NAME_TO_KEY как 'Оценка'->'estimate' (AC-T1)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-02
-    type: unit
-    description: "Маппинг величин -> story-point bucket: точная семантика 1/2/3/5/8 на граничных входах (AC-2)"
+    type: integration
+    description: "Fail-closed: 'estimate' отсутствует в _DEFAULT_STATES; на проекте без статуса proj_states.get('estimate') is None -> ветка инертна, handle_estimate не зовётся, нет KeyError (AC-T5)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-03
-    type: unit
-    description: "Пустая история -> bootstrap-дефолт, не исключение; estimate() never-raise при битых данных (AC-1, AC-9)"
+    type: integration
+    description: "handle_estimate на backlog-issue (нет pipeline-задачи): прогноз вычислен, записан, затем set_issue_backlog -> issue возвращён в Backlog (AC-T1, AC-T2)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-04
-    type: unit
-    description: "Расчёт факта на done из usage-агрегатов (токены/время/стоимость) маппится в story-point bucket (AC-4)"
+    type: integration
+    description: "Анти-disruption: issue с активным job (has_active_job_for_task=True) -> handle_estimate no-op + лог, оценка не запускается, статус не меняется (AC-T6)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-05
     type: integration
-    description: "Прогноз пишется в estimate_point через set_issue_estimate_point; факт — в point через set_issue_point; поля не перепутаны и прогноз не затирается (AC-3, AC-4)"
+    description: "Анти-loop: возврат в Backlog не алиасит триггер-ветки (Backlog-UUID != estimate/stop/to_analyse/confirm_deploy/approved/rejected) -> входящий 'state->Backlog' webhook = no-op-эхо (AC-T6)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-06
     type: integration
-    description: "Telegram-карточка содержит пункт 'Оценка' (время/токены/стоимость); пустой прогноз -> пункт опускается, карточка не падает (AC-5)"
+    description: "Массовость: N issue.updated со state='Оценка' -> N независимых вызовов handle_estimate, каждый даёт прогноз; один webhook не гасит остальные (AC-T3)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-07
     type: integration
-    description: "Plane-коммент с прогнозом постится через add_comment (best-effort) (AC-6)"
+    description: "Идемпотентная пере-оценка: повторный перевод в 'Оценка' -> UPSERT по work_item_id обновляет одну строку task_estimates и estimate_point, не дублирует (AC-T4)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-08
-    type: integration
-    description: "POST /estimate?work_item=<id> и POST /estimate/backlog: оценка/пере-оценка идемпотентна — повтор обновляет task_estimates и estimate_point, не дублирует (AC-7)"
+    type: unit
+    description: "estimate() возвращает {forecast_tokens,forecast_seconds,forecast_cost_usd,story_points}, story_points в {1,2,3,5,8} (AC-1)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-09
-    type: integration
-    description: "Оценка авто-производится до start_pipeline и best-effort: сбой estimate() не блокирует старт задачи (AC-8)"
+    type: unit
+    description: "Маппинг величин -> story-point bucket: точная семантика 1/2/3/5/8 на граничных входах (AC-2)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-10
     type: unit
-    description: "kill-switch estimator_enabled=false -> модуль инертен (нет записей в Plane/карточку/таблицу); applies() локален и first (AC-9)"
+    description: "Пустая история -> bootstrap-дефолт, не исключение; estimate() never-raise при битых данных (AC-1, AC-9)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-11
     type: unit
-    description: "Скоуп estimator_repos пуст -> активен только self-hosting orchestrator; enduro-trails -> no-op (AC-9)"
+    description: "Расчёт факта на done из usage-агрегатов (токены/время/стоимость) маппится в story-point bucket (AC-4)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-12
     type: integration
-    description: "GET /queue содержит read-only блок estimator (флаг/скоуп/счётчики); existing-поля не меняются (AC-9)"
+    description: "Прогноз пишется в estimate_point через set_issue_estimate_point; факт — в point через set_issue_point; поля не перепутаны, прогноз не затирается (AC-3, AC-4)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-13
-    type: unit
-    description: "Аддитивная таблица task_estimates: CREATE TABLE IF NOT EXISTS идемпотентна; record_estimate/set_actual/get_estimate хранят прогноз+факт+дельту; существующие таблицы не изменены (AC-12)"
+    type: integration
+    description: "Telegram-карточка содержит пункт 'Оценка' (время/токены/стоимость); пустой прогноз -> пункт опускается, карточка не падает (AC-5)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-14
     type: integration
-    description: "fail-safe записи в Plane: estimate-система не настроена -> set_issue_estimate_point/point best-effort пропуск + лог, без падения (AC-12, NFR-6)"
+    description: "Plane-коммент с прогнозом постится через add_comment (best-effort) (AC-6)"
     module: tests/test_orch020_estimator.py
     expected: PASS
 
   - id: TC-15
     type: unit
-    description: "Анти-регресс control-path: STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict-ключи и resolve_agent_model/resolve_agent_effort не изменены (AC-10, AC-11)"
+    description: "kill-switch estimator_enabled=false -> модуль инертен (handle_estimate no-op, нет записей в Plane/карточку/таблицу); applies() локален и first (AC-9)"
+    module: tests/test_orch020_estimator.py
+    expected: PASS
+
+  - id: TC-16
+    type: unit
+    description: "Скоуп estimator_repos пуст -> активен только self-hosting orchestrator; enduro-trails -> no-op (AC-9)"
+    module: tests/test_orch020_estimator.py
+    expected: PASS
+
+  - id: TC-17
+    type: integration
+    description: "GET /queue содержит read-only блок estimator (флаг/скоуп/счётчики прогнозов/записей/возвратов); existing-поля не меняются (AC-9)"
+    module: tests/test_orch020_estimator.py
+    expected: PASS
+
+  - id: TC-18
+    type: unit
+    description: "Аддитивная таблица task_estimates: CREATE TABLE IF NOT EXISTS идемпотентна; record_estimate/set_actual/get_estimate хранят прогноз+факт+дельту с ключом work_item_id (task_id нуллабелен); существующие таблицы не изменены (AC-12)"
+    module: tests/test_orch020_estimator.py
+    expected: PASS
+
+  - id: TC-19
+    type: integration
+    description: "fail-safe записи в Plane: estimate-система не настроена -> set_issue_estimate_point/point best-effort пропуск + лог, без падения; авто-возврат в Backlog всё равно отрабатывает (AC-12, AC-T2, NFR-7)"
+    module: tests/test_orch020_estimator.py
+    expected: PASS
+
+  - id: TC-20
+    type: unit
+    description: "Анти-регресс control-path: STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict-ключи, resolve_agent_model/resolve_agent_effort не изменены; статус 'Оценка' не добавлен как ребро стадий (AC-10, AC-11)"
     module: tests/test_orch020_estimator.py
     expected: PASS