# MVP-2 «Подвисшие задачи и контроль сроков» — Design Draft

| | |
|---|---|
| Дата | 2026-05-13 |
| Статус | **Draft — фиксация обсуждённого, требует доработки после MVP-1** |
| Зависимости | MVP-1 завершён (есть core.employee, core.task, core.project, core.work_log) |
| Срок | 2-3 недели после MVP-1 |

> **Назначение этого документа:** зафиксировать то, что уже обсудили по MVP-2, чтобы не вспоминать заново. Это **набросок**, не финальная спека. Финальная спека пишется отдельно перед стартом MVP-2 после результатов MVP-1.

## Цели MVP-2

Автоматический контроль за сроками проектов и поиск подвисающих задач, которые тормозят следующие работы. Расширение дашборда MVP-1 + добавление алёртов.

### Главные бизнес-вопросы (из исходной постановки пользователя)

- В каком состоянии сейчас проекты?
- Где отстаём по срокам?
- Какие задачи подвисают и тормозят следующие работы?
- На какой задаче может зависнуть проект (декомпозиция до уровня задачи)?

## Что добавляем к MVP-1

### Расширение core

```sql
-- (MVP-1 уже имеет core.task)
core.task_status_history (
    id bigserial PRIMARY KEY,
    task_id bigint REFERENCES core.task,
    from_status_type text,        -- OPEN | IN_PROGRESS | IN_REVIEW | CLOSED
    to_status_type text,
    from_status_id text,
    to_status_id text,
    cmf_author_id text,           -- кто сделал переход (EVA)
    employee_id bigint REFERENCES core.employee,
    cmf_created_at timestamptz,
    transition_id text,
    resolution_id text
)

core.stage (
    id bigserial PRIMARY KEY,
    name text,
    bitra_id text,
    project_id bigint REFERENCES core.project,
    plan_start_date date,
    plan_end_date date,
    is_completed boolean,         -- BIT.RA.Catalog.ЭтапыПроектов.Выполнен
    is_acted boolean              -- BIT.RA.Catalog.ЭтапыПроектов.АктПодписан
)
```

### Новые витрины

```
mart.stalled_tasks            — задачи IN_PROGRESS без смены статуса > N дней (N конфигурируется)
mart.project_health           — по каждому открытому проекту: список задач, кто работает, факт-часы, текущий статус, риск-флаги
mart.deadline_risks           — задачи и этапы у которых дедлайн в ближайшие N дней, но статус не закрыт
mart.task_lead_time           — среднее время задачи в каждом статусе (для бенчмарка «нормальное» vs «подвисло»)
```

### Источники данных (помимо MVP-1)

- **EVA** — добавить полную синхронизацию `CmfStatusHistory` (есть 114k записей, фильтр по `cmf_created_at` работает — инкрементально).
- **BIT.RA** — добавить эндпоинт `/api/stages` для `Catalog.ЭтапыПроектов` (с реквизитами `Выполнен`, `АктПодписан`).
- **BIT.RA** — добавить эндпоинт `/api/project_status` для `Document.СтатусПроекта` (протоколы статус-совещаний). Опционально — может пригодиться для понимания «когда последний раз обсуждали проект».

### Алёрты Telegram

Базовый набор:
- «Задача подвисла» — в IN_PROGRESS более N дней без смены статуса (N = 5 / 7 / 10 — конфигурируется).
- «Этап проекта просрочен» — `Catalog.ЭтапыПроектов.ДатаОкончания < today AND Выполнен=false`.
- «Проект без активности» — нет работ по проекту за последние N дней.

Триггер — N8N workflow раз в сутки → SELECT из витрин → POST в Telegram бот.

### Дашборд (расширение MVP-1)

Новые секции на главном дашборде Metabase:
- Плитка «N подвисших задач» с цветом (красная если > X).
- Таблица «Топ-N подвисших задач» — задача, исполнитель, проект, статус, дней без активности.
- Таблица «Проекты с риском срыва» — проект, плановая дата, % выполнения, последняя активность.
- Heatmap «Среднее время в статусе» по сотрудникам — кто узкое горло.

## Бэклог в рамках MVP-2

- **Автоматическое распределение SD-задач по компетенциям сотрудников** (из исходного бэклога). Это связано с [Subsystem D](./2026-05-13-subsystem-d-competence-design.md): компетенции = производная от `core.work_log`. Распределение = выбор сотрудника с подходящей компетенцией и низкой текущей загрузкой.

## Open questions (для финализации перед стартом MVP-2)

- Пороги «подвисло» — конфигурируемые в `core.config` (per-status, per-priority?) или единый N дней?
- Включаем ли в MVP-2 контроль сроков по подписанию документов (актов)? Это пересекается с MVP-3 (НЗП). Возможно стоит часть из MVP-3 (контроль актов) перенести в MVP-2.
- Алёрты — только в Telegram, или ещё в дашборд (плитка «требует внимания»)?
- Что делать с задачами без `responsible_id` (43% покрытие — см. [reference-eva-empirical](../../memory/reference_eva_empirical.md))? Они невидимы в контроле сроков — нужна отдельная стратегия (например, алёрт «N задач без исполнителя» — намёк команде заполнять).

## Зависимости от MVP-1

MVP-2 стартует когда:
- ✅ MVP-1 работает в проде (3 слоя загрузки + дашборд).
- ✅ `core.task` и `core.work_log` заполняются стабильно.
- ✅ Identity-map по сотрудникам стабильно работает (>95% сматчены).
- Дисциплина EVA в команде начала улучшаться (растёт % задач с `responsible_id`).