# 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 если:** задача ломает/рестартует прод-инстанс, останавливая конвейер других проектов.