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

## Вывод: изменение схемы SQLite НЕ требуется.

Merge-lease (сериализация слияний, BR-5) реализуется **файлом**, а не таблицей:

- Путь: `<repos_dir>/.merge-lease-<repo>.json` (`settings.repos_dir`, по умолчанию `/repos`).
- Содержимое: `{ "task_id": int, "work_item_id": str, "branch": str,
  "acquired_at": "<ISO>", "pid": int }`.
- Жизненный цикл — см. ADR-001 §4 (acquire неблокирующий / release идемпотентный /
  реклейм по возрасту `merge_lock_timeout_s`).

### Почему файл, а не таблица БД
- ТЗ §4 прямо предпочитает реализацию без миграции схемы.
- Файловый lease проще делается **restart-safe** (реклейм по mtime/возрасту + `pid`) и не
  трогает инициализацию `src/db.py` (никаких изменений `tasks`/`agent_runs`/`jobs`/`events`).
- Атомарность захвата обеспечивается `open(O_CREAT|O_EXCL)` на одном хосте (mva154,
  один инстанс) — достаточно для сериализации в пределах одного процесса-оркестратора.

### Существующие таблицы — без изменений
`tasks`, `agent_runs`, `jobs`, `events` не модифицируются. Defer-механизм переиспользует
существующий столбец `jobs.available_at` (ORCH-1) для отложенного повторного запуска
deployer'а — **новых столбцов не нужно**.

> Если в будущем потребуется кросс-процессная/мульти-хостовая сериализация — lease можно
> мигрировать в таблицу (или advisory-lock). Это будет отдельным ADR; в рамках ORCH-043
> файловый lease достаточен (один хост, один инстанс).