4.3 KiB
4.3 KiB
type, work_item_id, verdict, version
| type | work_item_id | verdict | version |
|---|---|---|---|
| review | ORCH-048 | APPROVED | 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 отсутствуют.