orchestrator/docs/work-items/ORCH-022/08-data-requirements.md

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.