123 lines
9.4 KiB
Markdown
123 lines
9.4 KiB
Markdown
# 03 — Критерии приёмки (Acceptance Criteria)
|
||
|
||
**Work Item:** ORCH-044
|
||
Каждый критерий — однозначное PASS/FAIL. Привязка к TR из `02-trz.md`.
|
||
|
||
## P1 — Preflight ловит авторизацию
|
||
|
||
### AC-1 — Не залогинен ⇒ preflight FAIL (TR-1.1, TR-1.2, TR-1.5)
|
||
- **Дано:** бинарь claude существует, `claude --version` отвечает успешно, НО учётные
|
||
данные отсутствуют/нечитаемы (нет `.credentials.json`).
|
||
- **Когда:** вызывается `preflight.check(force=True)`.
|
||
- **Тогда:** возвращается `(False, reason)`, где `reason` упоминает авторизацию
|
||
(например, «not logged in» / «credentials»).
|
||
- **FAIL если:** возвращается `(True, ...)` (как сейчас — слепота к auth).
|
||
|
||
### AC-2 — Протухший OAuth-токен ⇒ preflight FAIL (TR-1.2a)
|
||
- **Дано:** `.credentials.json` существует и читаем, но `claudeAiOauth.expiresAt` в прошлом.
|
||
- **Когда:** `preflight.check(force=True)`.
|
||
- **Тогда:** `(False, reason)` с указанием на истечение токена.
|
||
- *(N/A, если архитектор выбрал чистый вариант (b) без чтения файла — тогда покрывается AC-9.)*
|
||
|
||
### AC-3 — Валидный логин ⇒ preflight OK без регрессии (TR-1.7)
|
||
- **Дано:** bin есть, `--version` ок, `.credentials.json` читаем, `expiresAt` в будущем.
|
||
- **Когда:** `preflight.check(force=True)`.
|
||
- **Тогда:** `(True, ...)`.
|
||
- **FAIL если:** залогиненный валидный кейс даёт FAIL (ложное срабатывание).
|
||
|
||
### AC-4 — Auth-fail блокирует клейм job (TR-1.5, BR-2)
|
||
- **Дано:** preflight возвращает `(False, ...)` из-за auth; в очереди есть `queued` job.
|
||
- **Когда:** `QueueWorker._drain_once()` выполняет тик.
|
||
- **Тогда:** job **не клеймится** (остаётся `queued`), в `worker.last_preflight_ok=False`,
|
||
пишется лог-warning; claude не спавнится.
|
||
- **FAIL если:** job переходит в `running` / спавнится агент.
|
||
|
||
### AC-5 — Token-free и локально (BR-1, TR-1.6)
|
||
- **Дано:** auth-проверка.
|
||
- **Тогда:** она НЕ делает prompt-ping и НЕ обращается к API модели (никаких httpx/сетевых
|
||
вызовов к провайдеру в пути проверки; проверяется по коду/моку — сетевой вызов не
|
||
происходит).
|
||
- **FAIL если:** проверка отправляет запрос к модели/жжёт токены.
|
||
|
||
### AC-6 — Кеширование auth-проверки (TR-1.4)
|
||
- **Дано:** `preflight_cache_ttl` > 0, первый `check()` выполнен.
|
||
- **Когда:** повторные `check()` в пределах TTL.
|
||
- **Тогда:** дорогая часть (чтение файла/процесс) не повторяется чаще TTL (как у version-check).
|
||
- **FAIL если:** файл/процесс дёргается на каждый тик внутри TTL.
|
||
|
||
## P2 — Решение по `--effort`
|
||
|
||
> ⛔ **ИСКЛЮЧЕНО ВЛАДЕЛЬЦЕМ (06.06):** AC-7, AC-8, AC-9 НЕ применяются в ORCH-044. effort не трогаем, вынесен в ORCH-50. См. коррекцию scope в 02-trz.md.
|
||
|
||
|
||
### AC-7 — Расследование задокументировано (TR-2.1)
|
||
- **Тогда:** в ADR (`06-adr/`) и/или `10-tech-risks.md` зафиксирована причина пустого stdout
|
||
при `--effort` + `--print --output-format json` (несовместимость/синтаксис/баг CLI).
|
||
- **FAIL если:** изменения внесены без объяснения первопричины.
|
||
|
||
### AC-8 — Однозначный исход A или B, без «мёртвого» флага (TR-2.2, TR-2.3)
|
||
- **Тогда:** реализован ровно один из вариантов:
|
||
- **A:** `--effort` формируется и запуск с ним даёт **непустой** result-JSON; прод-хотфикс
|
||
`ORCH_AGENT_EFFORT_*=""` более не требуется; есть регресс-тест на непустой вывод; ИЛИ
|
||
- **B:** `--effort` **не формируется** в активном пути `_spawn`; дефолты `agent_effort_*`
|
||
нейтрализованы; ORCH-41-доки помечают effort как unsupported на текущем CLI.
|
||
- **FAIL если:** в коде остаётся путь, где дефолтная конфигурация добавляет `--effort` и
|
||
гасит вывод; ИЛИ код/доки/дефолты противоречат друг другу.
|
||
|
||
### AC-9 — Дефолтный запуск даёт непустой результат (TR-2.3, перекликается с P3)
|
||
- **Дано:** конфигурация по умолчанию после задачи (без ручного хотфикса в `.env`).
|
||
- **Когда:** агент запускается стандартным путём `_spawn`.
|
||
- **Тогда:** результат запуска — непустой run-лог с валидным result-JSON (проверяемо
|
||
модульно через построение cmd и/или интеграционно на моке claude).
|
||
- **FAIL если:** дефолтный путь воспроизводит пустой stdout инцидента.
|
||
|
||
## P3 — Пустой лог / нет result-JSON ⇒ провал
|
||
|
||
### AC-10 — Пустой лог + exit 0 ⇒ job НЕ done (TR-3.1, TR-3.2)
|
||
- **Дано:** агент завершился `exit_code=0`, но run-лог пустой (0 байт).
|
||
- **Когда:** отрабатывает `_monitor_agent`/`_finalize_job`.
|
||
- **Тогда:** job НЕ переходит в `done`; переходит в `failed` (или `queued` при наличии
|
||
retry-бюджета) с информативным `error`; шлётся алерт.
|
||
- **FAIL если:** job становится `done`, либо остаётся `running` навсегда.
|
||
|
||
### AC-11 — Нет валидного result-JSON + exit 0 ⇒ job НЕ done (TR-3.1, TR-3.2)
|
||
- **Дано:** run-лог непустой, но не содержит валидного result-JSON (мусор/обрезок).
|
||
- **Когда:** финализация job.
|
||
- **Тогда:** job трактуется как провал (как AC-10).
|
||
- **FAIL если:** job становится `done`.
|
||
|
||
### AC-12 — Нет авто-advance и нет «успешного» коммента при провале результата (TR-3.2)
|
||
- **Дано:** кейс AC-10/AC-11.
|
||
- **Тогда:** `_try_advance_stage` НЕ вызывается (стадия не двигается), «успешный»
|
||
status-коммент агента НЕ постится.
|
||
- **FAIL если:** стадия продвинулась/запостился успех при пустом результате.
|
||
|
||
### AC-13 — Валидный результат не регрессирует (TR-3.1)
|
||
- **Дано:** `exit_code=0` и непустой run-лог с валидным result-JSON.
|
||
- **Когда:** финализация job.
|
||
- **Тогда:** job → `done`, авто-advance и usage-коммент работают как раньше.
|
||
- **FAIL если:** легитимный успешный запуск теперь ошибочно помечается провалом.
|
||
|
||
### AC-14 — Никогда не вечный `running` (TR-3.4, BR-3)
|
||
- **Тогда:** для любого завершившегося процесса (любой exit_code, включая 0 с пустым логом)
|
||
job завершается в терминальном/ретраябельном состоянии (`done`/`failed`/`queued`), не
|
||
остаётся `running`.
|
||
- **FAIL если:** существует путь, оставляющий job `running` после выхода процесса.
|
||
|
||
## Сквозные
|
||
|
||
### AC-15 — Документация обновлена в том же PR (правило агентов №2, №6)
|
||
- **Тогда:** обновлены `docs/operations/INFRA.md` (env-карта preflight-auth и/или effort),
|
||
`docs/architecture/internals.md` (effort-секция), `CHANGELOG.md`; заведён ADR.
|
||
- **FAIL если:** функционал изменён, доки/CHANGELOG/ADR не обновлены (reviewer → REQUEST_CHANGES).
|
||
|
||
### AC-16 — Тесты зелёные (test-plan)
|
||
- **Тогда:** все тесты из `04-test-plan.yaml` проходят; `pytest tests/ -q` зелёный.
|
||
- **FAIL если:** хотя бы один тест плана FAIL или существующие тесты сломаны без обоснованного
|
||
обновления контракта.
|
||
|
||
### AC-17 — Self-hosting безопасность (CLAUDE.md)
|
||
- **Тогда:** изменения не требуют рестарта/падения прод-контейнера `orchestrator` в рамках
|
||
задачи; проверка прошла через staging (8501).
|
||
- **FAIL если:** задача ломает/рестартует прод-инстанс, останавливая конвейер других проектов.
|