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

03 — Критерии приёмки (Acceptance Criteria)

Work Item: ORCH-048 Title: staging B6 check reads registry from host worktree, not staging container Stage: analysis Author: analyst Date: 2026-06-06

Каждый критерий формулирует чёткое условие PASS/FAIL. Источник — бизнес-запрос ORCH-048 (AC-1…AC-4) + BRD.

---

AC-1 — B6 PASS на staging, читая реестр из staging-окружения

Условие PASS:

• При staging-прогоне scripts/staging_check.py (канонический способ запуска, выбранный архитектором) чек B6 выдаёт ✓ PASS c detail sandbox=YES, prod-ET=NO(good), prod-ORCH=NO(good).
• Набор known id, по которому судит B6, получен из окружения работающего staging-инстанса (HTTP-эндпоинт / docker-окружение контейнера / собственный process-env при запуске внутри контейнера), не из локального импорта src.projects в произвольном process-env с host-path хаком /repos/orchestrator.

FAIL, если: B6 даёт ложный FAIL (prod-ET=YES(BAD!) / prod-ORCH=YES(BAD!)) при фактически исправной изоляции; либо реестр в B6 по-прежнему строится локальным импортом, зависящим от env процесса-запускателя.

AC-2 — B6 ловит РЕАЛЬНОЕ нарушение изоляции (оба исхода покрыты тестом)

Условие PASS:

• Существует unit-тест, проверяющий логику вердикта B6 на двух входах:
  1. «чистый» staging-реестр (known = {SANDBOX}) → B6 вердикт PASS;
  2. «загрязнённый» реестр (например known = {SANDBOX, PROD_ET} и/или {SANDBOX, PROD_ORCH}) → B6 вердикт FAIL.
• Тест не требует поднятия живого staging-инстанса/docker (логика вердикта изолирована и тестируема, см. 02-trz §9).

FAIL, если: покрыт только один исход; либо B6 даёт PASS при наличии прод-проекта в реестре (потеря защитной функции).

AC-3 — Остальные staging-чеки не сломаны; src/projects.py и .env не тронуты

Условие PASS:

• Блоки A1–A3, B4, B5 и блок C (E2E) в scripts/staging_check.py функционально не изменены (формат вывода и логика прежние).
• git diff work item НЕ содержит изменений в src/projects.py, .env, .env.staging, .env.example.
• Прод-логика оркестратора не затронута. Исключение допускается только если архитектор в ADR выбрал вариант (а) и добавил read-only эндпоинт — тогда изменение ограничено добавлением этого эндпоинта, прод-поведение существующих роутов неизменно.

FAIL, если: изменён src/projects.py или любой .env*; либо затронута/сломана логика прочих чеков.

AC-4 — Существующие unit-тесты зелёные

Условие PASS:

• python -m pytest tests/ -q завершается с кодом 0; все ранее зелёные тесты остаются зелёными; новый тест B6 (AC-2) проходит.

FAIL, если: любой тест падает.

AC-5 — Документация обновлена в том же PR (golden source)

Условие PASS:

• docs/operations/STAGING_CHECK.md отражает исправленную механику B6 и канонический способ запуска suite.
• При выборе варианта (а): обновлены таблица API в docs/architecture/README.md и CHANGELOG.md.
• При выборе варианта (в): обновлены .openclaw/agents/deployer.md (запуск через docker exec) и STAGING_CHECK.md.
• Заведён ADR docs/work-items/ORCH-048/06-adr/ADR-001-*.md с обоснованием выбранного варианта.

FAIL, если: код изменён, а соответствующая док/ADR не обновлены.

---

Сводная проверка (как мерить приёмку)

AC	Команда / действие	Ожидаемый результат
AC-1	staging-прогон suite (выбранным способом)	B6 … ✓ PASS [sandbox=YES, prod-ET=NO(good), prod-ORCH=NO(good)]
AC-2	pytest tests/test_staging_check_b6.py -q	оба кейса (clean→PASS, polluted→FAIL) зелёные
AC-3	git diff --name-only по ветке	нет src/projects.py, нет .env*; чеки A/B4/B5/C не изменены по сути
AC-4	python -m pytest tests/ -q	exit 0, все PASS
AC-5	ревью diff документации	STAGING_CHECK.md + ADR-001 присутствуют и согласованы с кодом