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

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