# Требования к данным / схеме БД — ORCH-036

Work Item: ORCH-036
Stage: architecture
Автор: architect

## Решение: миграция БД НЕ требуется

Схема SQLite (`events`, `tasks`, `agent_runs`, `jobs`) не меняется. Обоснование:

1. **Вердикт деплоя** — в `14-deploy-log.md` (frontmatter `deploy_status:`), как
   сейчас. `_parse_deploy_status` не трогаем (AC-10).
2. **Approve / initiated / result-состояние** — restart-safe через **sentinel-файлы**
   под `<repos_dir>/.deploy-state-<repo>/<work_item_id>/` (паттерн merge-lease
   `<repos_dir>/.merge-lease-<repo>.json`), а не через новую таблицу/колонку:
   - `approve-requested` — Фаза A;
   - `initiated` — Фаза B (idempotency-guard);
   - `result` — exit-code хука (пишет host-обёртка).
3. **Бюджет finalize-defer** считается из существующей таблицы `jobs`
   (`task_content LIKE '%deploy-finalize%'`), как `_merge_defer_count` для merge-gate
   — restart-safe, без новых полей.
4. **Finalizer-job** использует существующую структуру `jobs` (agent, repo,
   task_content, task_id, available_at). Reserved-agent `deploy-finalizer` — это
   значение в колонке `agent`, схема не меняется.

## Почему файлы, а не БД
- Sentinel должен быть виден И хосту (пишет `result`), И контейнеру (читает finalizer);
  файл на общем mount это обеспечивает, SQLite-запись из host-обёртки — нет.
- Зеркалит уже принятый паттерн merge-lease (ORCH-43) — единообразие, restart-safe,
  crash-реклейм по возрасту файла.

Если разработчик при реализации сочтёт необходимым поле статуса approve в БД —
это требует обновления данного ADR с обоснованием; по умолчанию — без миграции
(согласовано с TRZ §4).