# Блок 4. Структура объектов: каноническая модель

> Источник истины — фактическая схема SQLite в `src/db.py` и реестр проектов в
> `src/projects.py`; подробное описание таблиц — [internals, «Database Schema»](../architecture/internals.md).

## Каноническая модель

```
Project ──1:N──► Work-Item / Task ──1:N──► Job ──1:N──► Agent-run
   │                    │
   │                    └── артефакты задачи (docs/work-items/<ID>/)
   └── Plane-проект ↔ git-репозиторий ↔ префикс задач
```

### Project — проект в реестре
Связка «Plane-проект ↔ git-репозиторий ↔ префикс задач» (например, `ORCH-`). Реестр живёт в
конфиге (`src/projects.py`): один инстанс платформы обслуживает несколько проектов; по
префиксу задачи платформа находит репозиторий и настройки.

### Work-Item / Task — задача конвейера
Строка таблицы `tasks`: текущая **стадия** (`stage`), **маршрут** (`track`: полный или
багфикс), рабочая **ветка**, счётчики откатов, отметки отмены. Натуральные ключи — ID задачи
в Plane и человекочитаемый номер (`ORCH-NNN`). На каждой стадии задача накапливает
**артефакты** — номерные документы в `docs/work-items/<ID>/` (от бизнес-запроса до
deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md)).

### Job — единица работы в очереди
Строка таблицы `jobs`: что запустить (агент какой стадии), для какой задачи, в каком статусе
(`queued` → `running` → терминал). Очередь даёт: **атомарный захват** (два worker'а не возьмут
один job), **зависимости** между job'ами, **ретраи** с экспоненциальным backoff и breaker
после исчерпания бюджета, ограничение параллелизма.

### Agent-run — один запуск агента
Строка таблицы `agent_runs`: какой агент, какой моделью и эффортом, сколько длился, сколько
стоил (токены/доллары). Из этих строк складывается честная стоимость задачи в живой карточке
и аналитика по ролям.

### События вебхуков и дедуп
Входящие события Plane/Gitea фиксируются с ключом дедупликации: повторная доставка того же
события (ретраи источника, сетевые икоты) не порождает повторной работы.

## Вспомогательные таблицы

| Таблица | Зачем |
|---------|-------|
| `repo_freeze` | durable-заморозка репозитория после деградации прода (serial gate) |
| `coverage_baseline` | базовая линия покрытия тестами; растёт только вверх (ratchet) |
| `tracker_messages` | леджер всех Telegram-карточек задачи (зачистка сирот) |
| `lessons` | машинный журнал уроков — структурированные отклонения конвейера |

Все изменения схемы — аддитивные и идемпотентные (`CREATE TABLE IF NOT EXISTS`, ensure-column
при старте): обновление платформы не требует ручных миграций.

## Словарь терминов

| Термин | Значение |
|--------|----------|
| **Стадия** | Позиция задачи в конвейере; карта стадий — `STAGE_TRANSITIONS` ([блок 2](tech-pipeline.md)) |
| **Гейт (exit-гейт)** | Машинная проверка выхода со стадии; реестр — `QG_CHECKS` |
| **Под-гейт** | Проверка-врезка внутри перехода (не стадия); см. деплойное ребро в [блоке 2](tech-pipeline.md) |
| **Job** | Единица работы в очереди; задача порождает job'ы по мере продвижения |
| **Worktree** | Изолированная рабочая копия репозитория для ветки задачи |
| **Lease (merge-lease)** | Эксклюзивная блокировка «кто сейчас мержит этот репозиторий» — сериализация слияний |
| **Track (маршрут)** | Вариант пути задачи: полный цикл или багфикс с пропуском проектирования |
| **Freeze** | Заморозка очереди репозитория после инцидента до ручного разбора |

---

*Как объекты двигаются по конвейеру — [блок 2](tech-pipeline.md); кто их создаёт —
[агенты](tech-agents.md); как за ними наблюдать — [блок 7](tech-observability.md).*