9.7 KiB
work_item, stage, author_agent, status, created_at, model_used
| work_item | stage | author_agent | status | created_at | model_used |
|---|---|---|---|---|---|
| ORCH-019 | analysis | analyst | ready-for-review | 2026-06-10 | claude-opus-4-8 |
03 — Критерии приёмки (Acceptance Criteria): ORCH-019 — Режим багфиксинга
Work Item: ORCH-019 · Repo: orchestrator · Стадия: analysis
Формат: каждый критерий имеет PASS (что должно быть истинно для приёмки) и FAIL (что считается провалом). Reviewer/tester проверяют их буквально по файлам репозитория и тестам.
⚠️ Корневой инвариант (см. AC-3/AC-8): срезается только аналитика/архитектура; ни один Quality Gate не ослаблен. Это главное условие приёмки — нарушение = безусловный FAIL всей задачи.
AC-1 — Классификация задачи по метке Bug
Условие: issue с меткой Plane bug_fast_track_label (дефолт Bug) при включённом флаге и
применимом репо распознаётся как багфикс-задача.
- PASS: при
bug_fast_track_enabled=Trueиapplies(repo)==Trueдля issue с меткойBugis_bug_task(...)возвращаетTrue(черезlabels.has_label→plane_sync.fetch_issue_labels); задача стартует на багфикс-треке. Источник метки — Plane API, не payload вебхука. - FAIL: метка
Bugигнорируется; ИЛИ тип читается из payload вебхука; ИЛИ задача без меткиBugошибочно попадает на багфикс-трек.
AC-2 — Укороченный маршрут: пропуск стадии architecture
Условие: багфикс-задача проходит конвейер, минуя стадию architecture.
- PASS: для багфикс-задачи переход из
analysisведёт вdevelopment(а неarchitecture); стадияarchitectureи её требование06-adr/для багфикса не исполняются; задача доходит доdone. Маршрут не-баг задачи остаётсяanalysis → architecture → development → …. - FAIL: багфикс-задача всё равно проходит
architecture; ИЛИ не-баг задача начинает пропускатьarchitecture; ИЛИSTAGE_TRANSITIONSизменён структурно (новые/удалённые стадии).
AC-3 — Все Quality Gate'ы исполнены на багфикс-треке (корневой инвариант)
Условие: на багфикс-треке исполняются все гейты качества без изменений.
- PASS: для багфикс-задачи отрабатывают
check_ci_green,check_reviewer_verdict(12-review.md),check_tests_passed(13-test-report.md),check_staging_status,check_deploy_statusи под-гейты ребраdeploy-staging→deploy(security → merge → coverage → image-freshness) и merge-verify ребраdeploy→done. РеестрQG_CHECKS, сигнатурыcheck_*, вердикт-ключи (verdict:/result:/deploy_status:/staging_status:/security_status:/coverage_status:) и порядок под-гейтов — байт-в-байт прежние. - FAIL: хоть один гейт качества пропущен/ослаблен/изменён на багфикс-треке; ИЛИ изменён состав
QG_CHECKS/ имя или регистр любого вердикт-ключа / порядок под-гейтов.
AC-4 — Обязательный регресс-тест
Условие: багфикс фиксирует дефект тестом.
- PASS: PR багфикса содержит новый/изменённый тест, воспроизводящий исправляемый дефект
(красный на коде до фикса, зелёный после); требование закреплено в
04-test-plan.yamlбагфикса и в reviewer-оси (.openclaw/agents/reviewer.md: фикс без теста → finding ≥P1 / REQUEST_CHANGES). - FAIL: багфикс мержится без теста-фиксатора; ИЛИ reviewer-ось отсутствует/не срабатывает; ИЛИ тест присутствует, но не падает на исходном (нефиксированном) коде.
AC-5 — Эскалация сложного бага в полный цикл
Условие: сложный/архитектурный/визуальный баг возвращается в полный цикл.
- PASS: существует и документирован путь эскалации (минимум ручной: снятие метки
Bug/ перевод стадии, и/или решение мини-аналитика «баг сложный → не фаст-трекать»); после эскалации задача проходит штатный маршрут сarchitecture. - FAIL: механизма эскалации нет; ИЛИ багфикс-задача необратимо застревает без
architecture, когда баг требует архитектурного решения/макета.
AC-6 — Fail-safe → полный цикл (нулевая регрессия)
Условие: при выключении/ошибке/неприменимости — строго прежнее поведение (полный цикл).
- PASS: при
bug_fast_track_enabled=False, неприменимом репо, ошибке/таймауте/неоднозначности чтения метки, отсутствии меткиBug— задача стартует наanalysisи идёт маршрутом сarchitecture(как до ORCH-019). Логика never-raise: ошибка не роняетstart_pipeline/вебхук. При выключенном флаге путь старта и маршрут идентичны текущим (диффом по поведению — нулевые). - FAIL: ошибка/неоднозначность приводит к молчаливому пропуску стадий; ИЛИ исключение из логики классификации роняет вебхук/конвейер; ИЛИ при выключенном флаге поведение отличается от прежнего.
AC-7 — Наблюдаемость трека и метрика стоимости
Условие: факт багфикс-трека и экономия наблюдаемы.
- PASS:
GET /queueсодержит аддитивный read-only блокbug_fast_track(флаг/область/метка + счётчик задач на треке + агрегатная метрика экономии стадий/agent-runs/токенов/времени); решение о маршруте логируется; существующие ключиGET /queueне изменены. - FAIL: трек/метрика ненаблюдаемы; ИЛИ блок ломает существующий контракт
GET /queue; ИЛИ ошибка построения блока роняет эндпоинт (нарушен never-raise).
AC-8 — Аддитивность и self-hosting безопасность
Условие: изменение аддитивно и безопасно для общего прод-инстанса.
- PASS: миграции БД (если есть) аддитивны и идемпотентны (
_ensure_column/CREATE TABLE IF NOT EXISTS); enduro при выключенном/неприменимом флаге не затронут; механизм не рестартит/не роняет прод-контейнер, не пушит/force-push вmain. Полный регрессtests/зелёный. - FAIL: ломающая миграция/изменение существующих контрактов; ИЛИ затронут enduro при выключенном
флаге; ИЛИ механизм трогает прод-контейнер/
main; ИЛИ красныйtests/.
AC-9 — Композиция с существующими гейтами
Условие: багфикс-трек корректно сосуществует с ORCH-088/089/027/043.
- PASS: багфикс-задача корректно учитывается serial-gate (ORCH-088) как обычная задача репо;
autoApprove/autoDeploy(ORCH-089) работают на багфикс-треке; coverage-gate (ORCH-027) и merge-gate (ORCH-043) исполняются штатно. Интеграционный тест композиции зелёный. - FAIL: изменённая точка входа ломает serial-очередь/auto-label/merge/coverage; ИЛИ багфикс- задача обходит serial-gate.
Сводная матрица AC ↔ BR/FR
| AC | Покрывает |
|---|---|
| AC-1 | BR-1 / FR-1 |
| AC-2 | BR-2 / FR-2 |
| AC-3 | BR-3 / FR-3 / NFR-1 |
| AC-4 | BR-4 / FR-4 |
| AC-5 | BR-5 / FR-5 |
| AC-6 | BR-6 / FR-6 / NFR-2 / NFR-3 |
| AC-7 | BR-7 / FR-7 |
| AC-8 | BR-8 / NFR-2 / NFR-6 |
| AC-9 | NFR-7 |