work_item: ORCH-048
title: staging B6 check reads registry from host worktree, not staging container
stage: analysis
notes: >
  B6 в staging_check.py должен оценивать реестр окружения работающего staging-инстанса.
  Для тестируемости логика вердикта B6 выделяется в чистую функцию (напр.
  _evaluate_b6(known: set[str]) -> tuple[bool, str]); тесты бьют именно её и не
  поднимают живой staging-инстанс/docker. Идентификаторы — те же константы из скрипта:
  SANDBOX_PROJECT_ID=8c5a3025-4f9d-4190-b79f-fa06276bb27e,
  PROD_ET_PROJECT_ID=7a79f0a9-5278-49cd-9007-9a338f238f9c,
  PROD_ORCH_PROJECT_ID=8da6aa25-a60e-44d6-a1e2-d8ae59aa7d6a.

tests:
  - id: TC-01
    type: unit
    description: >
      B6-вердикт PASS при чистом staging-реестре: known={SANDBOX} ->
      passed=True, detail содержит sandbox=YES, prod-ET=NO, prod-ORCH=NO. (AC-1, AC-2)
    module: tests/test_staging_check_b6.py
    expected: PASS

  - id: TC-02
    type: unit
    description: >
      B6-вердикт FAIL при попадании прод-ET в реестр: known={SANDBOX, PROD_ET} ->
      passed=False, detail помечает prod-ET как нарушение. (AC-2)
    module: tests/test_staging_check_b6.py
    expected: PASS

  - id: TC-03
    type: unit
    description: >
      B6-вердикт FAIL при попадании прод-ORCH в реестр: known={SANDBOX, PROD_ORCH} ->
      passed=False, detail помечает prod-ORCH как нарушение. (AC-2)
    module: tests/test_staging_check_b6.py
    expected: PASS

  - id: TC-04
    type: unit
    description: >
      B6-вердикт FAIL при отсутствии sandbox в реестре: known=set() (пусто) ->
      passed=False (sandbox absent), детерминированно, без исключения. (AC-2, TR-4)
    module: tests/test_staging_check_b6.py
    expected: PASS

  - id: TC-05
    type: unit
    description: >
      B6-вердикт FAIL при загрязнении и ET, и ORCH одновременно:
      known={SANDBOX, PROD_ET, PROD_ORCH} -> passed=False. (AC-2)
    module: tests/test_staging_check_b6.py
    expected: PASS

  - id: TC-06
    type: unit
    description: >
      Источник реестра в B6 больше не зависит от host-path хака
      sys.path.insert(0,"/repos/orchestrator"): проверить (статически/через структуру
      кода или мок источника), что построение known не делается локальным импортом
      src.projects из произвольного process-env. (AC-1, TR-6)
    module: tests/test_staging_check_b6.py
    expected: PASS

  - id: TC-07
    type: unit
    description: >
      Деградация источника реестра (HTTP-ошибка / недоступный контейнер / битый ответ)
      -> B6 даёт детерминированный FAIL с понятным detail, а не ложный PASS и не
      необработанное исключение. (TR-4)
    module: tests/test_staging_check_b6.py
    expected: PASS

  - id: TC-08
    type: unit
    description: >
      Регрессия реестра: существующие тесты src/projects.py остаются зелёными,
      подтверждая, что src/projects.py не изменён. (AC-3, AC-4)
    module: tests/test_projects.py
    expected: PASS

  - id: TC-09
    type: integration
    description: >
      Полный прогон pytest без падений после правок:
      `python -m pytest tests/ -q` -> exit 0. (AC-4)
    module: tests/
    expected: PASS

  - id: TC-10
    type: integration
    description: >
      Живой staging-прогон (ручной, вне CI): запустить scripts/staging_check.py
      выбранным архитектором способом против orchestrator-staging (8501) ->
      B6 == PASS (sandbox=YES, prod-ET=NO, prod-ORCH=NO); блоки A/B4/B5/C не сломаны.
      (AC-1, AC-3) Выполняется деплоером на стадии deploy-staging.
    module: scripts/staging_check.py
    expected: PASS