# 08 — Требования к схеме БД: Security-гейт (ORCH-022)

## Решение: схема БД НЕ меняется

Миграций нет. Обоснование (соответствует TRZ §6 и паттерну edge-под-гейтов ORCH-043/058):

1. **Вердикт гейта — артефакт-файл** `17-security-report.md` (YAML-frontmatter), как
   `14-deploy-log.md` / `15-staging-log.md`. Не хранится в БД.
2. **Состояние/идемпотентность** — детерминированная пересборка вердикта при каждом тике
   (гейт чистый, без долгоживущего состояния между прогонами); sentinel-файлы НЕ требуются
   (в отличие от deploy-state/post-deploy-state — там асинхронный self-restart).
3. **Retry-счётчик** — переиспользуется существующий `_developer_retry_count(task_id)`
   (подсчёт по `jobs`/`agent_runs`), общий с merge-gate/image-freshness. **Новой колонки
   `security_retry` НЕ вводим** (TRZ §6: предпочесть подсчёт по `jobs`/`agent_runs`). Это
   корректно: security-FAIL, как merge/freshness-FAIL, откатывает на `development` и
   запускает developer — он и есть единица retry; общий cap=3 защищает от петли.

## Используемые существующие таблицы (без изменений)
- `tasks` — стадия задачи (`update_task_stage` при откате на `development`).
- `jobs` — enqueue `developer` при FAIL; основа `_developer_retry_count`.
- `agent_runs` — usage/duration; основа подсчёта retry.

## Что НЕ делаем
- Не добавляем таблицу findings/CVE-журнала (история находок — в артефактах per-task; петля
  уроков ORCH-8 читает артефакт).
- Не добавляем колонок в `tasks`/`jobs`.