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

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 достаточен (один хост, один инстанс).