Test-Env Verification

Правило

Если у пространства проекта есть тестовое окружение, изменение ОБЯЗАНО быть верифицировано на нём — и backend, и frontend — до подготовки к продакшен-деплою или архивирования. Верификация выполняется автономно: агент обнаруживает тестовое окружение, доставляет туда изменение, прогоняет его и фиксирует результат, не спрашивая оператора, нужно ли тестировать. Вопрос «а мы тестировали на тестовом окружении?» на каждой задаче — тот самый режим отказа, который этот gate устраняет.

Отличие от prod-readiness-probe

Gate работает рядом с prod-readiness-probe, но проверяет иное: prod-readiness-probe проверяет симметрию раннеров (test↔prod sudoers/PATH/порты) — примет ли прод деплой. Этот gate проверяет функциональное поведение развёрнутого тестового билда — работает ли изменение end-to-end на реальном окружении. Оба должны пройти до подготовки прода / архива для задачи, поставляющей поведение, в проекте с тестовым окружением.

Когда активен

Взводится, когда выполнены ОБА условия: (1) изменение поставляет рантайм-поведение (код, конфиг, миграция — не docs-only и не framework-only), и (2) пространство проекта декларирует тестовое окружение или оно обнаруживаемо. Цепочка разрешения: реестр пространства spaces/<space>/space.yml → test_environments[] (авторитетно), затем CI-эвристика (задача deploy:test, привязанная к push в ветку с тестовым хостом). Ни то, ни другое ⇒ вердикт NO-TEST-ENV — записывается, не является успехом. Docs-only / framework-only / infra-инвентарная задача ⇒ вердикт SKIP.

Автономная процедура

1. Разрешить тестовое окружение и записать источник, который его разрешил.
2. Доставить изменение через собственную CI-задачу проекта deploy:test — интегрировать на ветку-триггер (обычно dev). Если фича-ветка отрезана от main, а dev далеко впереди — cherry-pick только коммитов задачи на одноразовый worktree от origin/dev, никогда не слепой merge feature→dev. Ждать зелёного CI.
3. Прогнать backend: health-эндпоинт + минимум один поведенческий вызов по изменённому пути. Предпочесть safe-mode (dry_run, read-путь), если тестовое окружение может изменять реальные внешние системы.
4. Прогнать frontend: загрузить затронутую страницу/поток и подтвердить рендер/поведение. Если авторизация заблокирована тестовым окружением — откат к проверке развёрнутого бандла + component/live-render Playwright из /dr-qa Layer 4f, не пропускать молча.
5. Записать всё под ### Layer 4h — Test-Environment Verification.

Вердикты

PASS (backend И frontend прогнаны, поведение подтверждено), PASS_WITH_NOTES (верифицировано с записанным ограничением окружения), SKIP (нет рантайм-поведения), NO-TEST-ENV (нет зарегистрированного/обнаружимого окружения), FAIL (не доставлено на тест или сломано). FAIL — жёсткий блок с возвратом в /dr-do или на шаг деплоя; SKIP / NO-TEST-ENV не блокируют, но записываются дословно.

Режим /dr-auto

При DATARIM_AUTO_MODE=1 gate работает без вопросов — «тестировать ли на тестовом окружении?» предрешено как «да». Единственные допустимые эскалации к оператору — hard-gated граничные действия (продакшен-деплой или платное/деструктивное внешнее действие без safe-mode эквивалента); всё остальное идёт автономно и логируется.