From 282636fedbfd93209c06f12dd01ecdf53d0e95c9 Mon Sep 17 00:00:00 2001 From: claude-bot Date: Sun, 7 Jun 2026 07:06:10 +0000 Subject: [PATCH] analyst(ET): auto-commit from analyst run_id=262 --- docs/work-items/ORCH-058/01-brd.md | 87 ++++++++++++ docs/work-items/ORCH-058/02-trz.md | 126 ++++++++++++++++++ .../ORCH-058/03-acceptance-criteria.md | 71 ++++++++++ docs/work-items/ORCH-058/04-test-plan.yaml | 124 +++++++++++++++++ 4 files changed, 408 insertions(+) create mode 100644 docs/work-items/ORCH-058/01-brd.md create mode 100644 docs/work-items/ORCH-058/02-trz.md create mode 100644 docs/work-items/ORCH-058/03-acceptance-criteria.md create mode 100644 docs/work-items/ORCH-058/04-test-plan.yaml diff --git a/docs/work-items/ORCH-058/01-brd.md b/docs/work-items/ORCH-058/01-brd.md new file mode 100644 index 0000000..4ba0763 --- /dev/null +++ b/docs/work-items/ORCH-058/01-brd.md @@ -0,0 +1,87 @@ +# BRD — ORCH-058: Self-deploy retag берёт устаревший staging-образ (риск тихого регресса) + +Work Item ID: ORCH-058 +Тип: bug / техдолг инфраструктуры self-deploy +Источник: `docs/history/LESSONS_ORCH-036-selfdeploy.md` п.4 (самый опасный из 4 багов bootstrap ORCH-36) + +## 1. Контекст + +ORCH-36 сделал стадию `deploy` исполняемой для self-hosting репозитория `orchestrator`: +- Phase B (`src/self_deploy.py::build_deploy_command`) запускает детачед host-хук + `scripts/orchestrator-deploy-hook.sh` с параметром `SOURCE_IMAGE=orchestrator-orchestrator-staging`. +- Хук (шаг **2b**, BUILD-ONCE, ORCH-36 BR-6) делает `docker tag $SOURCE_IMAGE → $TARGET_IMAGE` + **без `docker build`** — «прод получает ровно тот артефакт, что прошёл staging». + +Дизайн-предпосылка BUILD-ONCE: **staging-образ свеж и провалидирован**. На практике этой +гарантии НЕТ. + +## 2. Проблема (корень) + +Конвейер **нигде не пересобирает** образ `orchestrator-orchestrator-staging` из текущего +кода (HEAD `main` / провалидированной ветки): +- Стадия `deploy-staging` запускает только `scripts/staging_check.py` (e2e-проверка) + против **уже работающего** контейнера `orchestrator-staging` (8501) — что бы в нём ни + крутилось. Сборка staging-образа — ручная операция (STAGING.md / ORCH-34), вне конвейера. +- Между «образ собран» и «retag в прод» нет провенанс-связи с провалидированным коммитом. + +Следствие (инцидент ORCH-36): staging-образ не пересобрали из нового `main` → +`staging_check` прошёл против СТАРОГО кода → BUILD-ONCE retag промоутнул СТАРЫЙ образ в прод. +Деплой «зелёный» (`result=0`, health ok), но прод молча откатился на код 2-дневной давности: +пропал `deploy-finalizer` → задача не закрылась → бесконечная петля Phase B. + +## 3. Почему это критично + +> Это **самый опасный** из четырёх багов self-deploy: он **не падает**, а **тихо откатывает +> прод**. Зелёный гейт = ложный позитив. Орк обслуживает все проекты (enduro-trails) из одного +> прод-инстанса → тихий регресс инструмента = групповой инцидент для всех проектов. + +Текущая защита (staging-гейт, merge-gate, health-check хука) НЕ ловит этот класс: все они +зелёные, потому что проверяют не тот артефакт, что уезжает в прод. + +## 4. Бизнес-цель + +Гарантировать инвариант: **в прод никогда не промоутится образ, не собранный из +провалидированного для данной задачи коммита; при невозможности это доказать — деплой +fail-fast (вердикт FAILED → откат на development), а не «тихо зелёный»**. + +## 5. Объём (scope) + +В объёме: +- Привязка артефакта (staging-образ → прод-retag) к провалидированному коммиту. +- Fail-fast при рассинхроне образа и кода (никаких тихих промоутов устаревшего). +- Условность как ORCH-35/36/43: реально только для `orchestrator`; прочие репо — no-op / + прежнее поведение. +- Контракт never-raise и fail-closed (на сомнении — не деплоить). + +Вне объёма: +- Полный авто-approve прод-деплоя (ORCH-54). +- Изменение exit-code-контракта хука (0/1/2) и реестров `STAGE_TRANSITIONS` / `QG_CHECKS` как + набора стадий. +- Миграции схемы БД. +- Деплой/рестарт **прод**-контейнера `orchestrator` (8500) в рамках задачи. + +## 6. Бизнес-требования (BR) + +- **BR-1.** Образ, который BUILD-ONCE retag промоутит в прод, ДОЛЖЕН соответствовать коду, + провалидированному стадией `deploy-staging` для данной задачи (тот же git-коммит). +- **BR-2.** Если соответствие НЕ доказуемо (staging-образ собран не из провалидированного + коммита, либо провенанс невозможно прочесть) — деплой ОБЯЗАН fail-fast: вердикт `FAILED`, + штатный откат на `development` (контракт БАГ-8), без рестарта прода. +- **BR-3.** `staging_check.py` (e2e-валидация) ДОЛЖЕН прогоняться против артефакта, + соответствующего тому же провалидированному коммиту, что уедет в прод (нельзя валидировать + один образ, а катить другой). +- **BR-4.** Поведение условно: реально для `orchestrator`; для прочих репозиториев — no-op / + без регрессий прежнего синхронного деплоя. +- **BR-5.** Выбранное решение НЕ должно приводить к вечной блокировке деплоя (если механизм + свежести отсутствует — нужен путь, который доводит до зелёного, а не fail-fast'ит навсегда). +- **BR-6.** Контракт never-raise: сбой проверки свежести/провенанса не должен валить + stage_engine; на любом сомнении — fail-closed (трактуем как несоответствие). +- **BR-7.** Документация-голден-сорс: INFRA / DEPLOY_HOOK / STAGING / architecture README + + CHANGELOG обновляются в том же PR; решение оформляется ADR. + +## 7. Связанные материалы + +- `docs/history/LESSONS_ORCH-036-selfdeploy.md` (п.4 — корень) +- `docs/architecture/adr/adr-0007-executable-self-deploy.md`, `docs/work-items/ORCH-036/06-adr/ADR-001-executable-self-deploy.md` +- `src/self_deploy.py`, `scripts/orchestrator-deploy-hook.sh`, `src/config.py` +- `docs/operations/STAGING.md`, `docs/operations/DEPLOY_HOOK.md`, `docs/operations/INFRA.md` diff --git a/docs/work-items/ORCH-058/02-trz.md b/docs/work-items/ORCH-058/02-trz.md new file mode 100644 index 0000000..dcada7d --- /dev/null +++ b/docs/work-items/ORCH-058/02-trz.md @@ -0,0 +1,126 @@ +# ТЗ — ORCH-058: провенанс staging-образа перед BUILD-ONCE retag в прод + +Work Item ID: ORCH-058 + +> Примечание: ТЗ фиксирует ТРЕБУЕМЫЕ изменения и точки в коде. **Выбор стратегии** +> (пересборка из HEAD `main` ПЕРЕД валидацией vs. fail-fast по провенансу образа, либо их +> комбинация) — решение **архитектора** (ADR в `06-adr/`). Ниже перечислены точки +> касания для обеих стратегий; архитектор выбирает и при необходимости сужает. + +## 1. Инвариант, который нужно обеспечить + +`INV-FRESH`: образ, передаваемый хуку как `SOURCE_IMAGE` для BUILD-ONCE retag в прод, +собран из ТОГО ЖЕ git-коммита, что прошёл `deploy-staging` для этой задачи. Если это +недоказуемо — деплой fail-fast (`deploy_status: FAILED` → откат на `development`, БАГ-8), +прод не трогается. + +Якорь «провалидированного коммита» (architect фиксирует точно в ADR): SHA HEAD ветки задачи +после merge-gate rebase на `origin/main` (то, что валидировал `deploy-staging` + merge-gate). + +## 2. Текущее поведение (что чинить) + +| Место | Сейчас | Проблема | +|---|---|---| +| `scripts/orchestrator-deploy-hook.sh` шаг 2b | `docker tag $SOURCE_IMAGE → $TARGET_IMAGE` без проверки происхождения образа | промоутит любой образ под именем `orchestrator-orchestrator-staging`, даже устаревший | +| Стадия `deploy-staging` (`.openclaw/agents/deployer.md` + `staging_check.py`) | гоняет e2e против уже запущенного 8501, не пересобирая образ | валидирует не тот артефакт, что уедет в прод | +| `src/self_deploy.py::build_deploy_command` | передаёт `SOURCE_IMAGE`, `TARGET_*`, `COMPOSE_PROFILE`, `PREV_IMAGE_FILE`; провенанс/SHA не передаёт | хук не знает, какой коммит ожидать | +| `Dockerfile` | без OCI-лейбла `revision`/git-SHA | у образа нет машиночитаемого происхождения для проверки | + +## 3. Задействованные модули `src/` и файлы + +- `src/self_deploy.py` — основной (provenance-helpers + проброс ожидаемого SHA в команду хука). +- `src/config.py` — новые настройки (`ORCH_`-префикс обязателен, урок ORCH-36 п.2). +- `scripts/orchestrator-deploy-hook.sh` — fail-fast по провенансу и/или пересборка перед retag. +- `Dockerfile` — лейбл происхождения образа (для стратегии «провенанс по labels/sha»). +- `src/qg/checks.py` — опц. новый детерминированный под-чек свежести (если стратегия «гейт»). +- `src/stage_engine.py` — опц. точка вызова под-чека на ребре `deploy-staging → deploy` + (рядом с merge-gate, строки ~262–288). **Реестр `STAGE_TRANSITIONS` не меняется.** +- `.openclaw/agents/deployer.md` — шаги стадии `deploy-staging` (если выбран rebuild-перед-валидацией). +- `docker-compose.yml` — опц. build-args/labels для staging-сервиса (если стратегия rebuild). + +## 4. Требуемые изменения — стратегия A (пересборка из HEAD main перед валидацией) + +A1. Перед прогоном `staging_check.py` стадия `deploy-staging` для `orchestrator` пересобирает + образ `orchestrator-orchestrator-staging` из провалидированного коммита (worktree ветки + после merge-gate rebase) и пересоздаёт контейнер 8501 на свежем образе. +A2. `staging_check.py` гоняется против свежего контейнера; на `SUCCESS` ровно ЭТОТ образ + становится `SOURCE_IMAGE` для прод-retag (loop closed). +A3. Детерминированно (без LLM в критическом пути): сборку/recreate выполняет код стадии или + host-хук в staging-режиме, не агент-деплойер «руками». +A4. Безопасность: операция трогает ТОЛЬКО staging (8501), НИКОГДА прод (8500). + +## 5. Требуемые изменения — стратегия B (fail-fast по провенансу образа) + +B1. `Dockerfile`: добавить лейбл происхождения, напр. + `LABEL org.opencontainers.image.revision=$GIT_SHA` через `ARG GIT_SHA` (build-arg). +B2. Сборка staging-образа (ручная или из стратегии A) проставляет `GIT_SHA` = коммит сборки. +B3. `src/self_deploy.py::build_deploy_command`: вычислить ожидаемый SHA провалидированного + коммита и пробросить в команду хука новым env (напр. `EXPECTED_REVISION=`). + Новый pure-helper, напр. `expected_revision(repo, branch) -> str` (never-raise). +B4. `scripts/orchestrator-deploy-hook.sh` шаг 2b: ПЕРЕД `docker tag` прочитать лейбл + `$SOURCE_IMAGE` (`docker image inspect --format '{{ index .Config.Labels "org.opencontainers.image.revision" }}'`) + и сравнить с `$EXPECTED_REVISION`. Несовпадение / пустой лейбл / пустой ожидаемый SHA → + `log` + `exit 1` (fail-fast). Поведение обратносовместимо: при незаданном + `EXPECTED_REVISION` — текущее поведение (без проверки), чтобы не сломать не-self репо. +B5. exit 1 хука уже маппится `map_exit_code_to_status → FAILED` (контракт не меняется), + Phase C пишет `14-deploy-log.md` `deploy_status: FAILED` → откат на `development` (БАГ-8). + +## 6. Требуемые изменения — опц. под-гейт (если архитектор выберет gate-side для B) + +- Новый детерминированный (без LLM) под-чек, напр. `check_staging_image_fresh`, по образцу + `check_branch_mergeable` (ORCH-043): pure verdict-logic + условность (`self_deploy_applies` + / `is_self_hosting_repo`), never-raise, для прочих репо → `(True, "N/A")`. +- Вызов на ребре `deploy-staging → deploy` ПЕРЕД Phase A (рядом с merge-gate, `stage_engine` + ~268–288). FAIL → откат на `development` (как merge-gate). Реестр стадий неизменен — + это под-гейт ребра, не новая стадия. +- Если выбран чисто хуковый fail-fast (раздел 5) — под-гейт не нужен. + +## 7. Изменения API + +Нет. Эндпоинты (`/health`, `/status`, `/queue`, `/webhook/*`) не меняются. Опц.: в снимок +`GET /queue` можно добавить диагностическое поле о свежести образа — НЕ обязательно. + +## 8. Изменения схемы БД + +Нет. Состояние deploy — sentinel-файлы (`.deploy-state-//`, ORCH-36). Миграции +запрещены (как ORCH-36/43/53). + +## 9. Конфигурация (`src/config.py`, ВСЕ с префиксом `ORCH_`) + +Кандидаты (architect финализирует имена и дефолты): +- `image_freshness_enabled: bool = True` — kill-switch проверки (поэтапный раскат). +- `image_freshness_repos: str = ""` — CSV; пусто → только self-hosting (как `self_deploy_repos`). +- (для стратегии B) проброс `EXPECTED_REVISION` строится в `build_deploy_command`, отдельной + настройки может не требоваться. +- (для стратегии A) при необходимости — имя/тег staging-образа уже есть + (`deploy_prod_source_image`). + +Урок ORCH-36 п.2: любая настройка, читаемая pydantic Settings, ОБЯЗАНА иметь префикс `ORCH_`. + +## 10. Новые QG checks (если применимо) + +- Опц. `check_staging_image_fresh` (см. §6) — добавить в реестр `QG_CHECKS` и в + snapshot-тест реестра (`tests/test_qg_registry_snapshot.py`). Только если выбран gate-side. + +## 11. Артефакты pipeline (создать/обновить В ТОМ ЖЕ PR) + +- `06-adr/ADR-001-.md` — выбор стратегии (A / B / A+B), якорь «провалидированного + коммита», точки fail-fast, условность, never-raise, отсутствие deadlock (BR-5). +- `docs/operations/DEPLOY_HOOK.md` — описание провенанс-проверки / пересборки и новых env. +- `docs/operations/STAGING.md` — как и когда пересобирается staging-образ в конвейере. +- `docs/operations/INFRA.md` — обновить топологию/риск self-deploy (закрыт п.4 каскада). +- `docs/architecture/README.md` — секция ORCH-36/58 (свежесть артефакта в BUILD-ONCE). +- `CHANGELOG.md` — запись ORCH-058. +- При выборе стратегии A: bootstrap-чеклист (урок ORCH-36 «сквозной»: реальный staging-прогон + до мержа). + +## 12. Инварианты / ограничения (self-hosting safety) + +- Никогда не рестартовать/ронять прод 8500 в рамках задачи (CLAUDE.md). Любая сборка/recreate — + только staging 8501. +- Никогда не пушить/форс-пушить `main` (как merge-gate). +- Контракты НЕ меняются: exit-code хука (0/1/2), `map_exit_code_to_status`, + `check_deploy_status`/`_parse_deploy_status`, БАГ-8 rollback, terminal-sync, merge-gate. +- Fail-closed: на любом сомнении (нет лейбла, нет ожидаемого SHA, ошибка inspect) — + трактовать как несоответствие → FAILED, никогда не промоутить «на авось». +- never-raise: helpers и под-чек не должны пробрасывать исключение в stage_engine. diff --git a/docs/work-items/ORCH-058/03-acceptance-criteria.md b/docs/work-items/ORCH-058/03-acceptance-criteria.md new file mode 100644 index 0000000..e97a68f --- /dev/null +++ b/docs/work-items/ORCH-058/03-acceptance-criteria.md @@ -0,0 +1,71 @@ +# Критерии приёмки — ORCH-058 + +Work Item ID: ORCH-058 + +Критерии сформулированы вокруг инварианта `INV-FRESH` и **не зависят** от выбранной +архитектором стратегии (A — пересборка, B — fail-fast по провенансу, A+B). Каждый — с +чётким условием PASS/FAIL. + +## AC-1 — Соответствие артефакта коду (центральный инвариант) +- PASS: образ, который BUILD-ONCE retag промоутит в прод (`SOURCE_IMAGE`), доказуемо собран + из коммита, провалидированного стадией `deploy-staging` для этой задачи. +- FAIL: в прод может уехать образ, собранный не из провалидированного коммита. + +## AC-2 — Fail-fast при рассинхроне (никаких тихих зелёных) +- PASS: если staging-образ собран НЕ из провалидированного коммита (или провенанс нечитаем), + деплой завершается `deploy_status: FAILED` и откатом на `development` (БАГ-8); прод НЕ + рестартуется на устаревший образ. +- FAIL: при рассинхроне деплой завершается `SUCCESS` / «зелёным», прод тихо откатывается. + +## AC-3 — Fail-closed на сомнении +- PASS: при отсутствии лейбла происхождения, пустом ожидаемом SHA, ошибке `docker image + inspect` или любой неоднозначности — трактуется как несоответствие → FAILED (никогда не + промоутится «на авось»). +- FAIL: сомнительный/непроверяемый случай трактуется как «свежий» и промоутится. + +## AC-4 — Валидация и промоут — один и тот же артефакт +- PASS: `staging_check.py` прогоняется против образа/контейнера, соответствующего тому же + провалидированному коммиту, который затем уезжает в прод. +- FAIL: валидируется один образ, а в прод retag'ается другой. + +## AC-5 — Условность (self-hosting only) +- PASS: проверка/пересборка реальна только для `orchestrator` (и репо из `image_freshness_repos`, + если задан); для прочих репо — no-op, синхронный деплой не-self репо без регрессий. +- FAIL: логика срабатывает для не-self репозиториев или ломает их деплой. + +## AC-6 — Никакого deadlock деплоя (BR-5) +- PASS: при штатном прогоне (staging-образ корректно отражает провалидированный коммит) + деплой доходит до `SUCCESS` и `deploy → done`; механизм свежести не блокирует валидный + деплой навсегда. +- FAIL: валидный деплой вечно fail-fast'ится / задача зависает на `deploy`. + +## AC-7 — Контракты не изменены +- PASS: `STAGE_TRANSITIONS` (набор стадий), exit-code-контракт хука (0/1/2), + `map_exit_code_to_status`, `check_deploy_status`/`_parse_deploy_status`, БАГ-8 rollback, + terminal-sync, merge-gate — без изменений; схема БД без миграций. +- FAIL: затронут любой из перечисленных контрактов или добавлена миграция БД. + +## AC-8 — never-raise +- PASS: сбой проверки свежести/провенанса (битый образ, ssh/docker error, отсутствующий + worktree) не пробрасывает исключение в `stage_engine`; возвращается безопасный вердикт. +- FAIL: исключение из новой логики всплывает и валит обработку стадии. + +## AC-9 — Self-hosting safety +- PASS: новая логика НЕ рестартует/не роняет прод-контейнер `orchestrator` (8500) и не + пушит/форс-пушит `main`; любые сборки/recreate — только staging (8501). +- FAIL: нарушено любое из ограничений выше. + +## AC-10 — Конфигурация и kill-switch +- PASS: новые настройки имеют префикс `ORCH_`; есть kill-switch (напр. `image_freshness_enabled`) + для поэтапного раската; при выключенном флаге — прежнее поведение. +- FAIL: настройка без `ORCH_`-префикса (не читается pydantic) или нет способа отключить. + +## AC-11 — Документация (golden source) +- PASS: в том же PR обновлены DEPLOY_HOOK.md, STAGING.md, INFRA.md, architecture/README.md, + CHANGELOG.md и заведён ADR `06-adr/ADR-001-*`. +- FAIL: функционал изменён, документация/ADR не обновлены (→ reviewer REQUEST_CHANGES). + +## AC-12 — Тесты зелёные +- PASS: `pytest tests/ -q` зелёный, включая новые тесты из `04-test-plan.yaml` и + snapshot-тест реестра QG (если добавлен под-чек). +- FAIL: любой тест из плана красный или регрессия существующих. diff --git a/docs/work-items/ORCH-058/04-test-plan.yaml b/docs/work-items/ORCH-058/04-test-plan.yaml new file mode 100644 index 0000000..f783828 --- /dev/null +++ b/docs/work-items/ORCH-058/04-test-plan.yaml @@ -0,0 +1,124 @@ +work_item: ORCH-058 +description: > + Провенанс staging-образа перед BUILD-ONCE retag в прод. Тесты покрывают инвариант + INV-FRESH: соответствие промоутируемого образа провалидированному коммиту, fail-fast + и fail-closed при рассинхроне, условность self-hosting, never-raise, неизменность + контрактов. Часть кейсов помечена strategy-зависимыми (A=пересборка, B=fail-fast по + провенансу) — финальный набор подтверждает архитектор в ADR; пишутся тесты для + выбранной стратегии. +tests: + - id: TC-01 + type: unit + description: > + Pure provenance-verdict: SHA образа == ожидаемый SHA -> свежий (PASS). + Совпадающие revision дают вердикт "соответствует". + module: tests/test_image_freshness.py + expected: PASS + + - id: TC-02 + type: unit + description: > + Pure provenance-verdict: SHA образа != ожидаемый SHA -> НЕ свежий -> + вердикт несоответствия (вход для fail-fast). + module: tests/test_image_freshness.py + expected: PASS + + - id: TC-03 + type: unit + description: > + Fail-closed: пустой/отсутствующий лейбл образа ИЛИ пустой ожидаемый SHA -> + трактуется как несоответствие (никогда не "свежий по умолчанию"). + module: tests/test_image_freshness.py + expected: PASS + + - id: TC-04 + type: unit + description: > + never-raise: provenance-helper при docker/ssh/inspect ошибке или отсутствующем + worktree возвращает безопасный вердикт (несоответствие), не пробрасывает исключение. + module: tests/test_image_freshness.py + expected: PASS + + - id: TC-05 + type: unit + description: > + Условность: для не-self репозитория проверка свежести = no-op (True/"N/A"); + для orchestrator (или репо из image_freshness_repos) — реальна. + module: tests/test_image_freshness.py + expected: PASS + + - id: TC-06 + type: unit + description: > + [Стратегия B] build_deploy_command пробрасывает EXPECTED_REVISION= + в remote-команду хука рядом с SOURCE_IMAGE; формат env корректен (shlex-quote). + module: tests/test_deploy_build_once.py + expected: PASS + + - id: TC-07 + type: unit + description: > + [Стратегия B] Хук содержит ветку fail-fast: при заданном EXPECTED_REVISION и + несовпадении revision лейбла SOURCE_IMAGE -> exit 1 ПЕРЕД docker tag; при пустом + EXPECTED_REVISION -> обратносовместимое поведение (без проверки). Статическая + проверка текста scripts/orchestrator-deploy-hook.sh (паттерн test_deploy_build_once). + module: tests/test_deploy_hook_provenance.py + expected: PASS + + - id: TC-08 + type: unit + description: > + [Стратегия B] Dockerfile объявляет ARG GIT_SHA и LABEL + org.opencontainers.image.revision=$GIT_SHA (статическая проверка текста Dockerfile). + module: tests/test_deploy_hook_provenance.py + expected: PASS + + - id: TC-09 + type: unit + description: > + Маппинг контракта: exit 1 хука (fail-fast по провенансу) -> + map_exit_code_to_status == "FAILED" (контракт ORCH-36 не изменён). + module: tests/test_deploy_hook_mapping.py + expected: PASS + + - id: TC-10 + type: integration + description: > + Stale-образ -> fail-fast end-to-end: на ребре deploy-staging->deploy при + несоответствии образа Phase B/хук дают FAILED -> advance_stage откатывает на + development (БАГ-8), прод не "зелёный". Прод-рестарт замокан. + module: tests/test_stage_engine.py + expected: PASS + + - id: TC-11 + type: integration + description: > + Свежий образ -> happy path: соответствие revision -> деплой доходит до SUCCESS и + deploy->done; механизм свежести не блокирует валидный деплой (anti-deadlock, AC-6). + Host-процесс/хук замокан. + module: tests/test_stage_engine.py + expected: PASS + + - id: TC-12 + type: unit + description: > + [Если выбран gate-side] check_staging_image_fresh зарегистрирован в QG_CHECKS; + snapshot-тест реестра обновлён и зелёный. + module: tests/test_qg_registry_snapshot.py + expected: PASS + + - id: TC-13 + type: unit + description: > + Конфигурация: новые настройки (image_freshness_enabled / image_freshness_repos) + читаются с префиксом ORCH_ и имеют дефолты; kill-switch off -> прежнее поведение. + module: tests/test_config.py + expected: PASS + + - id: TC-14 + type: unit + description: > + Регрессия контрактов: STAGE_TRANSITIONS (набор стадий) и exit-code-контракт хука + (0/1/2) не изменены существующими правками. + module: tests/test_stages.py + expected: PASS