70 lines
4.3 KiB
Markdown
70 lines
4.3 KiB
Markdown
---
|
||
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 отсутствуют.
|