8.9 KiB
8.9 KiB
Критерии приёмки — 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-данные не тронуты). |
Диф не меняет машину стадий; миграции безопасны | Изменение машины стадий / небезопасная миграция |