reviewer(ET): auto-commit from reviewer run_id=153

docs/work-items/ORCH-048/12-review.md

@@ -0,0 +1,69 @@
+---
+type: review
+work_item_id: ORCH-048
+verdict: APPROVED
+version: 1
+---
+
+# Review ORCH-048
+
+## Summary
+
+PR чинит ложный FAIL чека **B6** в `scripts/staging_check.py`: реестр проектов теперь
+читается из окружения работающего staging-инстанса (вариант «в», выбранный Владельцем и
+зафиксированный в ADR-001), host-path хак `sys.path.insert(0, "/repos/orchestrator")` +
+`importlib.reload` удалён. Реализация соответствует ТЗ, ADR-001 и всем критериям приёмки.
+Документация обновлена синхронно. `pytest tests/ -q` — **470 passed**.
+
+Соответствие осям проверки:
+
+- **ТЗ (02-trz):** TR-1…TR-6 выполнены. TR-1/TR-6 — реестр строится из process-env
+  инстанса, host-path хак удалён. TR-2 — инвариант `passed ⟺ SANDBOX ∈ known ∧ PROD_ET ∉
+  known ∧ PROD_ORCH ∉ known` в `_evaluate_b6`. TR-3 — формат detail сохранён. TR-4 —
+  детерминированный FAIL при недоступности источника (`_run_b6` ловит `Exception`, нет
+  ложного PASS, нет необработанного исключения). TR-5 — stdlib. §9 — логика вердикта
+  вынесена в чистую `_evaluate_b6` для unit-теста.
+- **ADR-001:** реализация дословно следует пунктам 1–5 решения и scope-guards.
+  HTTP-эндпоинт не добавлен, прод-`src/main.py` не тронут.
+- **AC-1…AC-5:** AC-1 — механика читает реестр инстанса; AC-2 — оба исхода покрыты
+  (TC-01 clean→PASS, TC-02/03/05 polluted→FAIL); AC-3 — `git diff` не содержит
+  `src/projects.py`/`.env*`, блоки A1–A3/B4/B5/C не тронуты; AC-4 — 470 passed; AC-5 —
+  STAGING_CHECK.md, deployer.md, CHANGELOG, ADR-001 обновлены в этом же PR.
+- **Качество кода:** чистые функции, докстринги на всех новых функциях, defensive-обработка,
+  `sys` остаётся используемым (`sys.exit`), без мёртвых импортов. Тесты содержательные
+  (7 TC + happy-path wiring + статическая проверка отсутствия хака).
+
+## Findings
+
+### P0 — Blocker
+- нет
+
+### P1 — Must fix
+- нет
+
+### P2 — Should fix
+- нет
+
+### P3 — Nice-to-have
+- [ ] `test_tc06_no_host_path_hack_in_source` и `test_tc06_registry_loader_uses_src_projects`
+  носят одинаковый префикс `tc06` — формально это два разных кейса; имена можно было бы
+  развести для читаемости отчёта pytest. Косметика, на приёмку не влияет.
+
+## Документация
+
+Полностью обновлена в том же PR (golden source соблюдён):
+
+- `docs/operations/STAGING_CHECK.md` — канонический способ запуска (способ 1 через
+  `docker exec`), способ «с хоста» помечен как невалидный/воспроизводящий баг, добавлена
+  секция «Механика чека B6».
+- `.openclaw/agents/deployer.md` — команда стадии `deploy-staging` переведена на
+  `docker exec orchestrator-staging python3 /repos/orchestrator/scripts/staging_check.py …`
+  с пояснением, почему host-запуск ломает B6.
+- `CHANGELOG.md` — запись в разделе Fixed с полным описанием root cause и решения.
+- ADR `docs/work-items/ORCH-048/06-adr/ADR-001-b6-registry-via-in-container-run.md` —
+  обоснование варианта (в), отклонённые (а)/(б), scope-guards.
+
+`docs/architecture/README.md` обновлять не требовалось: API, реестр стадий и `QG_CHECKS`
+не менялись (изменение касается только достоверности одного чека внутри suite).
+
+**Вердикт: APPROVED** — P0/P1 отсутствуют.