35 lines
2.2 KiB
Markdown
35 lines
2.2 KiB
Markdown
# Требования к данным / схеме БД — 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).
|