orchestrator/docs/work-items/ORCH-087/03-acceptance-criteria.md

# Критерии приёмки — ORCH-087

Каждый критерий — чёткое условие PASS/FAIL. Привязка к BR (`01-brd.md`) и ТЗ (`02-trz.md`).

---

## G0 — расследование

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-0.1 | ADR `06-adr/ADR-NNN-tracker-orphan-cleanup.md` существует и отвечает на ВСЕ 4 вопроса §4 BRD (число реальных сирот; точки рассинхрона a–e; причина застывания `To Analyse`; bump vs edit с данными). | ADR содержит ответы по всем 4 пунктам + явную рекомендацию | Любой вопрос без ответа / рекомендация без обоснования |
| AC-0.2 | В ADR зафиксировано staging-воспроизведение: таблица «стадия → (заголовок+тело в Telegram) vs (stage в БД)» по прогону задачи на 8501. | Таблица воспроизведения приложена | Воспроизведения нет / только предположения |
| AC-0.3 | Фикс (G1–G3) реализует механизм, выбранный и обоснованный в ADR (не противоречит выводу). | Код соответствует ADR | Код расходится с ADR без объяснения |

## G1 — нет осиротевших карточек

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-1.1 (=AC-1) | После прохождения стадий в чате НЕ остаётся карточек с устаревшим заголовком (нет `To Analyse` на завершённой задаче). | На staging-прогоне в чате только одна карточка, заголовок актуальный | Видна ≥1 замёрзшая/устаревшая карточка |
| AC-1.2 | Система ведёт учёт ВСЕХ незакрытых `message_id` задачи (не только последнего); при bump удаляются ВСЕ известные незакрытые. | Учёт присутствует, unit-тест на мульти-mid зачистку зелёный | Учёт только скаляр / сироты остаются |
| AC-1.3 (=AC-3) | При сбое `send` (`new_mid=None`) / рестарте орка / гонке указатель не теряет старые карточки — они подчищаются (или остаются в учёте до следующей попытки). | Unit моделирует send→None / повторный вызов: прежние mid не потеряны | mid теряется → сирота |
| AC-1.4 | Telegram-лимит 48ч на удаление задокументирован как known-limitation (старые сироты могут не удалиться). | Ограничение в ADR/доке | Не упомянуто |

## G2 — актуальный заголовок

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-2.1 (=AC-2) | Единственная актуальная карточка показывает текущий статус, включая весь deploy-цикл. | На каждой стадии заголовок/статус соответствует `stage` в БД | Расхождение заголовка и `stage` |
| AC-2.2 | `plane_status_label(stage)` детерминированно даёт корректный лейбл для всех стадий `created…done` (unit). | Unit перебирает все стадии, лейблы верны | Любой stage даёт неверный/`To Analyse` по умолчанию некорректно |

## G3 — deploy-цикл виден

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-3.1 | Стадия `deploy` показывает `⏸️ Awaiting Deploy` (offline). | Unit/staging подтверждает | Не показывает |
| AC-3.2 | Live-overlay покрывает `Deploying` / `Monitoring` (когда Plane-статус реально такой). | Overlay рисует ветку при наличии UUID статуса | Ветка не рисуется при живом статусе |
| AC-3.3 | `Done` рендерится по `stage == "done"` (`ГОТОВО` + итог). | Карточка done корректна | — |

## BR-EFF — эффорт в карточке

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-E.1 | Колонка `agent_runs.effort` создаётся идемпотентно; стамп фактического эффорта происходит в момент запуска агента. | Миграция + стамп есть, unit подтверждает запись | Колонки нет / эффорт не стампится |
| AC-E.2 | Строка каждой завершённой стадии карточки показывает эффорт рядом с моделью (выбранный формат `· model · effort` или `· model/effort`). | Рендер содержит эффорт, unit зелёный | Эффорт отсутствует в строке |
| AC-E.3 | developer-строка показывает `xhigh`; tester/deployer — `medium`; analyst/architect/reviewer — `high`. | Значения соответствуют ORCH-41/081 | Значения не совпадают |
| AC-E.4 | Пустой/неизвестный эффорт → суффикс эффорта опускается, рендер не падает. | Unit на пустой effort зелёный | Падение/мусорный суффикс |

## BR-G5 — честное время

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-5.1 | На задаче с искусственным застоем (открытый `brd_review` ~6ч) итоговое «твоё время» НЕ показывает ~6ч. | Unit с brd-окном 6ч → «твоё время» ограничено/активное, не 6ч | Показывает ~6ч |
| AC-5.2 | agent-время = `Σ agent_runs` точно (без регресса). | Unit сверяет сумму | Расхождение |
| AC-5.3 | Числа в итоговой строке сходятся: wall помечен как «общее (с ожиданием)» ИЛИ wall = Σ(стадии)+Σ(паузы с подписью). | Итог прозрачен и согласован | wall выдаётся за рабочее/не сходится |

## BR-G6 — свежий main / без эрозии reconciler

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-6.1 | Ветка разработана/смержена поверх `origin/main`, содержащего ORCH-86 (`merge-base` = merge-коммит 86 или новее). | `git merge-base --is-ancestor origin/main HEAD` → true; маркеры ORCH-086 в `src/reconciler.py` ветки присутствуют | Ветка отстаёт / маркеры 86 потеряны |
| AC-6.2 | `src/reconciler.py` / `tests/test_reconciler.py` не эродированы (ORCH-086 terminal-skip + `state_uuid`-dedup на месте). Проверено на merge-gate. | Диф не удаляет ORCH-086 логику; merge-gate зелёный | Логика 86 затёрта |

## Сквозные

| ID | Критерий | PASS | FAIL |
|----|----------|------|------|
| AC-X.1 (=AC-4) | Инвариант «одна карточка на задачу» соблюдён; дубликатов нет; ≤1 `send` за вызов. | Unit/staging: одна карточка | Дубликаты |
| AC-X.2 (=AC-5 задачи) | `pytest tests/ -q` зелёный; весь путь нотификаций never-raise (любая ошибка Telegram/БД не валит конвейер). | Тесты зелёные; unit на исключения не поднимает | Падение/raise |
| AC-X.3 | Документация обновлена в ТОМ ЖЕ PR: `CLAUDE.md` (§Нотификации), `docs/architecture/README.md` (Notifications), `CHANGELOG.md`. | Доки обновлены | Reviewer → REQUEST_CHANGES |
| AC-X.4 | Ссылки ORCH-067 (`plane_issue_link`) и `disable_web_page_preview` (ORCH-080) сохранены. | Кликабельный номер + нет link-preview | Регресс |
| AC-X.5 | `STAGE_TRANSITIONS` / `QG_CHECKS` без изменений; миграции БД аддитивны/идемпотентны (enduro-данные не тронуты). | Диф не меняет машину стадий; миграции безопасны | Изменение машины стадий / небезопасная миграция |