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

Критерии приёмки — ORCH-058

Work Item ID: ORCH-058

Критерии сформулированы вокруг инварианта INV-FRESH и не зависят от выбранной архитектором стратегии (A — пересборка, B — fail-fast по провенансу, A+B). Каждый — с чётким условием PASS/FAIL.

AC-1 — Соответствие артефакта коду (центральный инвариант)

• PASS: образ, который BUILD-ONCE retag промоутит в прод (SOURCE_IMAGE), доказуемо собран из коммита, провалидированного стадией deploy-staging для этой задачи.
• FAIL: в прод может уехать образ, собранный не из провалидированного коммита.

AC-2 — Fail-fast при рассинхроне (никаких тихих зелёных)

• PASS: если staging-образ собран НЕ из провалидированного коммита (или провенанс нечитаем), деплой завершается deploy_status: FAILED и откатом на development (БАГ-8); прод НЕ рестартуется на устаревший образ.
• FAIL: при рассинхроне деплой завершается SUCCESS / «зелёным», прод тихо откатывается.

AC-3 — Fail-closed на сомнении

• PASS: при отсутствии лейбла происхождения, пустом ожидаемом SHA, ошибке docker image inspect или любой неоднозначности — трактуется как несоответствие → FAILED (никогда не промоутится «на авось»).
• FAIL: сомнительный/непроверяемый случай трактуется как «свежий» и промоутится.

AC-4 — Валидация и промоут — один и тот же артефакт

• PASS: staging_check.py прогоняется против образа/контейнера, соответствующего тому же провалидированному коммиту, который затем уезжает в прод.
• FAIL: валидируется один образ, а в прод retag'ается другой.

AC-5 — Условность (self-hosting only)

• PASS: проверка/пересборка реальна только для orchestrator (и репо из image_freshness_repos, если задан); для прочих репо — no-op, синхронный деплой не-self репо без регрессий.
• FAIL: логика срабатывает для не-self репозиториев или ломает их деплой.

AC-6 — Никакого deadlock деплоя (BR-5)

• PASS: при штатном прогоне (staging-образ корректно отражает провалидированный коммит) деплой доходит до SUCCESS и deploy → done; механизм свежести не блокирует валидный деплой навсегда.
• FAIL: валидный деплой вечно fail-fast'ится / задача зависает на deploy.

AC-7 — Контракты не изменены

• PASS: STAGE_TRANSITIONS (набор стадий), exit-code-контракт хука (0/1/2), map_exit_code_to_status, check_deploy_status/_parse_deploy_status, БАГ-8 rollback, terminal-sync, merge-gate — без изменений; схема БД без миграций.
• FAIL: затронут любой из перечисленных контрактов или добавлена миграция БД.

AC-8 — never-raise

• PASS: сбой проверки свежести/провенанса (битый образ, ssh/docker error, отсутствующий worktree) не пробрасывает исключение в stage_engine; возвращается безопасный вердикт.
• FAIL: исключение из новой логики всплывает и валит обработку стадии.

AC-9 — Self-hosting safety

• PASS: новая логика НЕ рестартует/не роняет прод-контейнер orchestrator (8500) и не пушит/форс-пушит main; любые сборки/recreate — только staging (8501).
• FAIL: нарушено любое из ограничений выше.

AC-10 — Конфигурация и kill-switch

• PASS: новые настройки имеют префикс ORCH_; есть kill-switch (напр. image_freshness_enabled) для поэтапного раската; при выключенном флаге — прежнее поведение.
• FAIL: настройка без ORCH_-префикса (не читается pydantic) или нет способа отключить.

AC-11 — Документация (golden source)

• PASS: в том же PR обновлены DEPLOY_HOOK.md, STAGING.md, INFRA.md, architecture/README.md, CHANGELOG.md и заведён ADR 06-adr/ADR-001-*.
• FAIL: функционал изменён, документация/ADR не обновлены (→ reviewer REQUEST_CHANGES).

AC-12 — Тесты зелёные

• PASS: pytest tests/ -q зелёный, включая новые тесты из 04-test-plan.yaml и snapshot-тест реестра QG (если добавлен под-чек).
• FAIL: любой тест из плана красный или регрессия существующих.