# Блок 6. Качество и безопасность

> Реестр гейтов и их распределение по стадиям — [блок 2](tech-pipeline.md); механизм
> machine-verdict доков — [PIPELINE_DOCS §3](../_standards/PIPELINE_DOCS.md); машинный
> контракт стадий — [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md).

## Философия Quality Gates

**Вердикты — машинные, никогда проза.** Гейт читает вердикт ТОЛЬКО из YAML-frontmatter
артефакта (ключи вида `verdict:`, `result:`, `staging_status:`, `deploy_status:`,
`security_status:` — имена и регистр неизменны байт-в-байт). Агент не может «уговорить» гейт
красивым отчётом: нет ключа — нет прохода. Парсинг frontmatter сведён к единому контракту
`src/frontmatter.py` — одна точка чтения для всех гейтов.

**Гейт ≠ маршрутизация.** Маршруты задач (багфикс-трек, авто-лейблы, serial gate) — свойство
планировщика; ни один из них не ослабляет ни одного гейта. Любая новая способность платформы
проектируется так, чтобы реестр гейтов и карта стадий не трогались.

**Анти-петля.** Откаты на доработку ограничены (max 3 подряд); инструментальные сбои
вспомогательных проверок по умолчанию fail-open с предупреждением (не запирают конвейер),
критичные проверки — fail-closed.

## Специальные гейты деплойного ребра

- **Security-гейт** (`check_security_gate`) — детерминированная (без LLM) проверка секретов и
  зависимостей перед продом; вердикт — `security_status:` в отчёте задачи.
- **Coverage-гейт** (`check_coverage_gate`) — покрытие тестами измеряется на финальном коде
  ветки; базовая линия по репозиторию растёт только вверх (ratchet при подтверждённом
  слиянии) — покрытие не может деградировать молча.

Оба — врезки в переход ([блок 2](tech-pipeline.md)), включаются по конфигу и скоупятся по
репозиториям.

## Канон секретов

- Секреты живут **только в `.env`-файлах на хосте** и никогда не коммитятся; в git — только
  канон-примеры с пустыми плейсхолдерами.
- Для нового хоста секреты **выпускаются свежими** (`scripts/gen_secrets.py`), боевые не
  копируются.
- Анти-регресс машинный: структурные тесты сканируют исполняемый код на боевые хост-литералы,
  а документацию — на секретоподобные значения; находка рвёт CI.

## Где уместен LLM: карта вызовов и нормативная политика

Платформа держит **доказательную карту** всех мест, где поток управления потребляет суждение
LLM, и **нормативную политику** «LLM — только там, где нужно настоящее суждение». Карта разводит
три факта: консультация ≠ транспорт/слот; **control-path** (вердикт LLM ветвит поток управления)
≠ **artifact-producer** (детерминированный гейт судит артефакт независимо); и деривируемость
вердикта из tool-сигналов. Путь называется **avoidable LLM control path**, когда он одновременно
control-path и его вердикт деривируем из exit-кодов (тогда консультацию можно заменить
детерминированным раннером). Поимённо: avoidable = `{tester, deployer}`; настоящее суждение
сохраняется у `{analyst, architect, developer, reviewer}`. Карта — снимок, прибитый структурными
анти-дрейф тестами. **Первый срез реализован (ORCH-115):** на `deploy-staging` для self-hosting
`orchestrator` LLM-`deployer` заменён детерминированным `src/staging_runner.py` (вердикт
`staging_status:` = маппинг exit-кода staging-сюиты); LLM-ветвь остаётся fallback'ом, гейт
`check_staging_status` не тронут. **Второй срез реализован (ORCH-116):** на `testing` для self-hosting
`orchestrator` LLM-`tester` заменён детерминированным `src/test_runner.py` (вердикт `result:` = exit-код
`pytest` + read-only smoke); это гибрид (`needs-hybrid-fallback`) — LLM-ветвь остаётся fallback'ом /
будущим off-control-path триажем, гейт `check_tests_passed`/`_parse_tests_verdict` не тронут.

- Карта вызовов LLM: [`../architecture/llm-call-sites.md`](../architecture/llm-call-sites.md)
- Нормативная политика: [`../architecture/llm-usage-policy.md`](../architecture/llm-usage-policy.md)
- Порядок замен: [`../architecture/llm-determinization-roadmap.md`](../architecture/llm-determinization-roadmap.md)

## Self-hosting-страховки

Платформа дорабатывает сама себя тем же конвейером — прод-инстанс при этом обслуживает и
другие проекты. Страховки:

- **Песочница обязательна:** перед прод-выкладкой платформы изменение репетируется на
  staging-инстансе (отдельный порт/БД); guard не даёт staging-операциям коснуться прод-порта.
- **Прод-выкладка — только по явному человеческому статусу Confirm Deploy** (обычный approve
  прод не выкатывает); деплой идёт детачнутым процессом с финализатором — честный исход
  фиксируется даже при рестарте.
- **`main` неприкосновенен:** слияние только через PR-API, force-push запрещён всем.
- **Прод-контейнер никогда не роняется задачей**: агенты проверяют изменения локально и на
  песочнице; рестарт прода — только штатным деплой-маршрутом.
- **Пост-деплой наблюдение:** после выкладки платформа следит за своим здоровьем; деградация
  замораживает репозиторий и зовёт человека.

---

*Операционные детали и топология прода — `docs/operations/` (см.
[инженерный справочник](../architecture/README.md)); наблюдение за здоровьем —
[блок 7](tech-observability.md).*