# Блок 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. ## Self-hosting-страховки Платформа дорабатывает сама себя тем же конвейером — прод-инстанс при этом обслуживает и другие проекты. Страховки: - **Песочница обязательна:** перед прод-выкладкой платформы изменение репетируется на staging-инстансе (отдельный порт/БД); guard не даёт staging-операциям коснуться прод-порта. - **Прод-выкладка — только по явному человеческому статусу Confirm Deploy** (обычный approve прод не выкатывает); деплой идёт детачнутым процессом с финализатором — честный исход фиксируется даже при рестарте. - **`main` неприкосновенен:** слияние только через PR-API, force-push запрещён всем. - **Прод-контейнер никогда не роняется задачей**: агенты проверяют изменения локально и на песочнице; рестарт прода — только штатным деплой-маршрутом. - **Пост-деплой наблюдение:** после выкладки платформа следит за своим здоровьем; деградация замораживает репозиторий и зовёт человека. --- *Операционные детали и топология прода — `docs/operations/` (см. [инженерный справочник](../architecture/README.md)); наблюдение за здоровьем — [блок 7](tech-observability.md).*