27 lines
2.1 KiB
Markdown
27 lines
2.1 KiB
Markdown
# 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`.
|