Initial spec: MVP-1 workload + drafts for MVP-2/3/4 + Subsystem D

2026-05-13 19:42:17 +05:00
commit 76f9a1ccfa
7 changed files with 979 additions and 0 deletions
@@ -0,0 +1,23 @@
 # XML-выгрузки источников (не код проекта — внешние данные)
 bitra/
 finrez_1c/
 # Секреты
 .env
 .env.local
 *.secret
 # Backups
 *.sql.gz
 backups/
 # OS / IDE
 .DS_Store
 Thumbs.db
 .vscode/
 .idea/
 *.swp
 # Temp
 *.tmp
 .tmp/
@@ -0,0 +1,67 @@
 # bit-flight-deck
 Система учёта рабочего времени сотрудников и контроля проектов для проектного отдела.
 ## Контекст
 Инициатива объединяет данные четырёх систем-источников в единое read-only аналитическое хранилище для ответов на главные вопросы руководителя проектного отдела:
 - Кто из сотрудников сейчас загружен коммерческими работами?
 - Какие задачи подвисают и тормозят следующие работы?
 - В каком состоянии проекты по срокам, марже, НЗП, актированию?
 - Какой финрезультат у каждого подразделения?
 ## Системы-источники
 | Система | Что в ней мастер | Транспорт |
 |---|---|---|
 | **BIT.RA** (1С на BSP) | Часы, классификация работ, проектная финансовая аналитика, справочник сотрудников | HTTP-сервисы 1С (одноразовая разработка) |
 | **EVA Desk** | Задачи разработчиков/PM, Service Desk, история смены статусов | JSON-RPC pull + глобальный админ-токен |
 | **Битрикс24** | Сделки и прогноз продаж, оргструктура | Outbound webhooks через CF Tunnel + nightly reconcile |
 | **finrez_1c** (самописная 1С) | Месячный финрез по подразделениям (ручной ввод) | HTTP-сервисы 1С (отложено до MVP-4) |
 ## Архитектура
 PostgreSQL + N8N + Metabase + NocoDB. Используется существующая инфра в `~/infrastructure/`:
 - `pipeline_postgres` (PG 15) — создаём отдельную БД `bit_flight_deck`.
 - `n8n` — оркестратор, workflows в существующем контейнере.
 - `pipeline_litellm` — LLM-шлюз (опц. для fuzzy-match имён).
 - `cloudflared` (host-systemd) — публичный поддомен `n8n.bigmadnekenny.ru` для Bitrix webhooks.
 Новые сервисы в `~/projects/bit-flight-deck/docker-compose.yml`:
 - **Metabase** — дашборды.
 - **NocoDB** — UI для управления identity_map и весами проектных команд.
 ## Декомпозиция на MVP
 | MVP | Цель | Статус |
 |---|---|---|
 | **MVP-1** | Загрузка сотрудников (4 слоя: факт / текущая / плановая как «осталось» / прогноз из Битрикса) | Spec ready ([docs/superpowers/specs/2026-05-13-mvp1-workload-design.md](docs/superpowers/specs/2026-05-13-mvp1-workload-design.md)) |
 | **MVP-2** | Подвисшие задачи + контроль сроков проектов | Draft ([docs/superpowers/specs/2026-05-13-mvp2-deadlines-design.md](docs/superpowers/specs/2026-05-13-mvp2-deadlines-design.md)) |
 | **MVP-3** | Маржа, НЗП, прогноз актирования | Draft ([docs/superpowers/specs/2026-05-13-mvp3-finance-design.md](docs/superpowers/specs/2026-05-13-mvp3-finance-design.md)) |
 | **MVP-4** | Финрез по подразделениям | Draft, требует отдельного мозгового штурма ([docs/superpowers/specs/2026-05-13-mvp4-finrez-design.md](docs/superpowers/specs/2026-05-13-mvp4-finrez-design.md)) |
 | **Подсистема D** | Компетенции сотрудников (производная из истории работ) | Draft ([docs/superpowers/specs/2026-05-13-subsystem-d-competence-design.md](docs/superpowers/specs/2026-05-13-subsystem-d-competence-design.md)) |
 ## Принципы
 - **Read-only** интеграция. Источники остаются мастерами.
 - **Single-user MVP.** Multi-user — вне scope MVP-1.
 - **Email — главный ключ identity-resolution** для сотрудников между всеми системами.
 - **Вертикальный срез по MVP.** Каждый MVP даёт видимый дашборд за 2-4 недели, не «фундамент на всё».
 - **Компетенции — производные.** Не справочник, а расчёт из истории работ.
 ## Структура репозитория
 ```
 docs/superpowers/specs/   — спецификации MVP по очереди
 sql/                       — DDL миграции, views, procedures, seed
 infra/                     — init-скрипты БД, документация по поддоменам CF Tunnel
 n8n/workflows/             — JSON-экспорты workflows
 ```
 (На MVP-1: создаются по мере реализации.)
 ## Связанные
 - Инфра-репозиторий: `https://gitea.bigmadnekenny.ru/admin/infrastructure`
 - EVA-bot документация (API EVA + SD-проекты): `https://gitea.bigmadnekenny.ru/admin/eva-bot`
@@ -0,0 +1,479 @@
 # MVP-1 «Загрузка сотрудников» — Design Document
 | | |
 |---|---|
 | Дата | 2026-05-13 |
 | Статус | Draft на ревью пользователя |
 | Владелец | Чесноков Роман (Руководитель проектного отдела) |
 | Срок MVP | 3-4 недели |
 | Контекст-проект | Workload & Project Control System (см. memory `project_workload_control`) |
 ## 1. Контекст и проблема
 В компании используются 4 учётных системы, ни одна из которых не даёт ответа на главные вопросы руководителя проектного отдела:
 - **BIT.RA** (1С) — ежедневные отчёты сотрудников о выполненной работе, проектная финансовая аналитика.
 - **EVA Desk** — задачи разработчиков/PM и Service Desk.
 - **Битрикс24** — CRM, сделки, прогноз продаж.
 - **Самописная 1С (финрез)** — ручной агрегатор финреза по подразделениям.
 Чтобы понять «загрузку сотрудника» сейчас, руководитель должен открыть 3 системы параллельно и склеить данные в голове или в Excel. Это **не масштабируется** и **не даёт прогноза**.
 ## 2. Цели MVP-1
 Построить **первую вертикальную автоматизацию** — единый дашборд «Загрузка сотрудников» с 4 слоями (факт / текущая / плановая / прогнозная) для команды ~20 сотрудников за 3-4 недели работы.
 ### Не-цели MVP-1
 - Контроль сроков проектов поэтапно (подсистема C).
 - Расчёт маржи, НЗП, актирования (подсистема C/F).
 - Компетенции сотрудников (подсистема D).
 - Расчёт финреза по подразделениям (подсистема F — отдельный мозговой штурм).
 - BI-дашборды для всех руководителей (подсистема G).
 - Multi-user интерфейс с правами по сотрудникам (зафиксировано MVP single-user).
 - Двусторонняя интеграция (мы только читаем, источники остаются мастерами).
 - Подключение CmfTimeTrackerHistory (под ACL deny, не используется).
 - Подключение CmfTaskResAssign (не используется в команде).
 - Все 16 воронок Битрикса (только CAT=16 «Проектные продажи (нов.)»).
 - ИНН-маппинг клиентов BIT.RA ↔ Битрикс (поле в BIT.RA не заполняется).
 - Прямая связь сделок Битрикса с проектами BIT.RA (`UF_CRM_PROJECTID` мёртвое поле).
 ## 3. Бизнес-вопросы и их витрины
 | Вопрос | Витрина (mart) | Слой | Покрытие |
 |---|---|---|---|
 | Кто из сотрудников и сколько часов проработал коммерчески за месяц | `mart.workload_actual` | Факт | 100% от BIT.RA-отчётности |
 | Кто сейчас в работе на каких задачах и сколько часов на них уйдёт | `mart.workload_current` | Текущая | ~43% задач EVA (по sample на 2026-05-13 — только задачи с `responsible_id`) |
 | Сколько часов осталось доделать у каждого сотрудника (открытые задачи) | `mart.workload_planned` | Плановая (как «осталось») | То же ~43% |
 | Сколько часов может прилететь из сделок Битрикса в стадиях после Защиты КП | `mart.workload_forecast` | Прогноз | Зависит от заполнения проектной команды |
 | Сколько «безхозных» задач (без исполнителя или без проекта) — намёк команде | `mart.tasks_orphan` | Метрика качества данных | — |
 Дашборд в Metabase собирает всё в один экран.
 ## 4. Архитектура верхнего уровня
 ```
  Источники                       Транспорт              Оркестратор + Хранилище
  ─────────────                   ─────────              ────────────────────────
  BIT.RA (1C)        ──pull──>    HTTP-services    ─┐
  EVA Desk           ──pull──>    JSON-RPC + admin ─┤
  Bitrix24            ──pull──>    REST             ─┼──>  N8N orchestrator
  Bitrix24            ──push──>    Webhooks (tunnel)─┤      (cron + webhook triggers)
                                                     │             │
                                                     │             ▼
                                                     │     ┌──────────────────────┐
                                                     │     │     PostgreSQL       │
                                                     │     │  raw_bitra (JSONB)   │
                                                     │     │  raw_eva (JSONB)     │
                                                     │     │  raw_bitrix (JSONB)  │
                                                     │     │    ↓ SQL views/procs │
                                                     │     │  stg_*               │
                                                     │     │    ↓                 │
                                                     │     │  core.*              │
                                                     │     │    ↓                 │
                                                     │     │  mart.*              │
                                                     │     └─────┬────────────────┘
                                                     │           │
                                                     │     ┌─────┴─────┐
                                                     │     ▼           ▼
                                                     │  Metabase    NocoDB
                                                     │  (dashboards)(admin UI:
                                                     │              identity_map,
                                                     │              deal_team_weights)
                                                     │
                                                     └──>  Telegram (alerts, optional)
 ```
 ### Компоненты
 **Используем существующую инфраструктуру** на хосте (Ubuntu в WSL), репозиторий `~/infrastructure/`:
 | Компонент | Статус | Назначение | Как используем |
 |---|---|---|---|
 | **pipeline_postgres** (postgres:15-alpine) | ✅ уже стоит | Хранилище | Создаём новую БД `workload` + пользователя `workload_user` |
 | **n8n** | ✅ уже стоит | Оркестратор | Создаём наши workflows в существующем контейнере |
 | **pipeline_litellm** | ✅ уже стоит (87+ моделей через OpenRouter) | LLM для опц. fuzzy-match ФИО | HTTP-нода в N8N → `http://pipeline_litellm:4000` |
 | **pipeline_gitea** | ✅ уже стоит | Версионирование | Новый репозиторий `bit-flight-deck` |
 | **Cloudflare tunnel** (host-systemd) | ✅ уже стоит | Публичный endpoint для Bitrix webhooks | Добавляем поддомен `n8n.bigmadnekenny.ru` → `localhost:5678` (N8N webhook-trigger) |
 **Ставим новое** в `~/projects/bit-flight-deck/docker-compose.yml` (подключение к external network `pipeline_net`):
 | Компонент | Назначение |
 |---|---|
 | **Metabase** | Дашборды поверх mart-таблиц |
 | **NocoDB** | UI для ручного управления `core.identity_map`, `core.deal_team_weights` |
 **Источники данных (внешние):**
 | Компонент | Назначение | Где |
 |---|---|---|
 | **BIT.RA HTTP-сервисы** | Серверный модуль `IntegrationAPI` с REST-эндпоинтами под нужные core-сущности | Внутри BIT.RA (одноразовая 1С-разработка) |
 | **EVA Desk JSON-RPC** | Стандартный API EVA с глобальным админ-токеном | Внешний firstbit.evateam.ru |
 | **Bitrix24 REST + webhooks** | Pull через REST + push-приёмник через CF Tunnel | Внешний vdst421.1cbit.ru |
 ## 5. Транспорт по источникам
 ### 5.1. BIT.RA — HTTP-сервисы 1С (pull)
 В BIT.RA пишется серверный модуль `IntegrationAPI` с эндпоинтами:
 | Метод | Эндпоинт | Содержимое |
 |---|---|---|
 | GET | `/api/works?modified_since=<ts>&limit=N` | Document.Работы + ТЧ за период с инкрементом |
 | GET | `/api/employees?modified_since=<ts>` | Catalog.Пользователи + ContactInfo (email) |
 | GET | `/api/projects?modified_since=<ts>` | Catalog.Проекты с EVA_ID |
 | GET | `/api/dictionaries` | Подразделения, Офисы, Менеджеры, СценарииПланирования и т.д. (редкий полный) |
 | GET | `/api/work_types` | Enum.ВидыРабот (статичный, тянем раз в сутки) |
 | GET | `/api/dept_history?modified_since=<ts>` | InformationRegister.ПодразделениеСотрудников |
 Расписание: works/employees/projects — каждые 30 минут. Dictionaries/work_types — раз в сутки.
 Аутентификация — выделенный 1С-пользователь с правами только на чтение релевантных объектов.
 ### 5.2. EVA Desk — Pull-гибрид + глобальный админ-токен
 - **Nightly full sync** (раз в сутки): `.list` на CmfPerson, CmfProject, CmfTask, CmfStatus — полный снимок в `raw_eva.*`.
 - **Incremental sync** (каждые 30 минут): `CmfAudit.list?filter=cmf_created_at>=<last_sync>` → список изменённых объектов → `.get` за деталями.
 Глобальный админ-токен в env-переменной N8N. После разработки — пересоздаётся.
 ### 5.3. Bitrix24 — Webhooks + nightly reconcile
 - **Outbound webhooks** (push): на события `ONCRMDEALADD`, `ONCRMDEALUPDATE`, `ONCRMDEALDELETE`, `ONUSERADD`, `ONUSERUPDATE`, `ONUSERDELETE`. Битрикс POST'ит на наш endpoint через **существующий Cloudflare Tunnel** → новый поддомен → N8N webhook-trigger принимает → `crm.deal.get` за деталями → запись в raw.
 - **Nightly reconcile pull** (раз в сутки): `crm.deal.list?filter[CATEGORY_ID]=16` со всеми UF-полями для сверки.
 **Поддомен для webhook'а:** добавляется к существующему `cloudflared` (host-systemd сервис). Конфигурация — в `cloudflared.env` (route на `localhost:5678`). Webhook-URL — `https://n8n.bigmadnekenny.ru/webhook/bitrix/<secret-token>`.
 Только воронка CAT=16. Только сделки в стадиях от «Защита КП» (`FINAL_INVOICE`) для прогноза + стадии реализации (`UC_XPZ8Z5`, `UC_QYTFP3`) как текущая загрузка.
 ### 5.4. finrez_1c — НЕ в MVP-1
 Откладываем до подсистемы F. Доработка `Catalog.Сотрудники` (добавление email) — также вне MVP-1.
 ## 6. Data Model
 ### 6.1. Слои PostgreSQL
 ```
 raw_bitra.*      — JSONB-снимки ответов BIT.RA HTTP-сервисов
 raw_eva.*        — JSONB-снимки ответов EVA JSON-RPC
 raw_bitrix.*     — JSONB-снимки сделок и пользователей Битрикса
 stg_bitra.*      — нормализованные сущности BIT.RA (по одной таблице на сущность)
 stg_eva.*        — нормализованные сущности EVA
 stg_bitrix.*     — нормализованные сущности Битрикса
 core.*           — унифицированная модель (см. ниже)
 mart.*           — витрины для дашборда
 ```
 ### 6.2. core-таблицы (MVP-1 минимум)
 ```sql
 core.employee (
    id bigserial PRIMARY KEY,
    email text UNIQUE NOT NULL,
    full_name text,
    is_active boolean,
    is_target_for_mvp1 boolean,     -- флаг «в фокусе MVP-1»
    bitra_user_id text,             -- guid из BIT.RA
    eva_person_id text,             -- CmfPerson:UUID
    bitrix_user_id bigint,          -- ID Битрикса
    rate decimal(10,2),             -- ставка
    department_id bigint REFERENCES core.department,
    office_id bigint REFERENCES core.office,
    last_synced timestamptz
 )
 core.department (
    id bigserial PRIMARY KEY,
    name text,
    bitra_id text,
    bitrix_id bigint,
    parent_id bigint REFERENCES core.department
 )
 core.office (
    id bigserial PRIMARY KEY,
    name text,
    bitra_id text
 )
 core.work_type (
    code text PRIMARY KEY,         -- ЛУРВ, ЛТ, Демо, ИТС, ...
    label text,
    category text,                  -- commercial | presale | internal | free | ignored
    is_billable boolean
 )
 core.project (
    id bigserial PRIMARY KEY,
    name text,
    bitra_id text,
    eva_id text,
    is_sd boolean DEFAULT false,    -- SD-проект (из явного списка 3 ID)
    status text,
    deadline date,
    budget decimal(15,2)
 )
 core.work_log (
    id bigserial PRIMARY KEY,
    employee_id bigint REFERENCES core.employee,
    work_date date NOT NULL,
    work_type_code text REFERENCES core.work_type,
    project_id bigint REFERENCES core.project,
    stage_id bigint,
    client_id bigint,
    hours decimal(10,2),
    description text,
    bitra_doc_id text,              -- ссылка на Document.Работы
    bitra_row_index int
 )
 core.task (
    id bigserial PRIMARY KEY,
    code text,                       -- PBSD-12582
    name text,
    eva_id text UNIQUE,              -- CmfTask:UUID
    cache_status_type text,          -- OPEN | IN_PROGRESS | IN_REVIEW | CLOSED
    project_id bigint REFERENCES core.project,
    responsible_id bigint REFERENCES core.employee,
    cmf_created_at timestamptz,
    cmf_modified_at timestamptz,
    status_in_progress_start timestamptz
 )
 core.deal (
    id bigserial PRIMARY KEY,
    bitrix_id bigint UNIQUE,
    title text,
    category_id int,                 -- 16
    stage_id text,                   -- C16:FINAL_INVOICE и т.д.
    stage_semantic_id char(1),       -- P | S | F
    opportunity decimal(15,2),
    begindate date,
    closedate date,
    assigned_to_id bigint REFERENCES core.employee,
    company_id bigint                -- ID Битрикс-компании (без маппинга на BIT.RA)
 )
 core.deal_team_member (
    deal_id bigint REFERENCES core.deal,
    employee_id bigint REFERENCES core.employee,
    weight decimal(5,2) DEFAULT 1.0,  -- вес сотрудника в команде (для распределения часов). По умолчанию 1.0 = поровну
    is_manual boolean DEFAULT false,  -- проставлен вручную через NocoDB
    PRIMARY KEY (deal_id, employee_id)
 )
 core.identity_map (
    entity_type text,                 -- employee | client | project
    core_id bigint,
    bitra_id text,
    eva_id text,
    bitrix_id bigint,
    confidence text,                  -- auto | confirmed | manual
    confirmed_by text,
    confirmed_at timestamptz
 )
 ```
 ### 6.3. core.work_type — справочник видов работ
 Загружается из BIT.RA `Enum.ВидыРабот` (14 значений), плюс правило категоризации:
 | Code (1С) | Label | Category | is_billable |
 |---|---|---|---|
 | `ЛУРВ` | ЛУРВ | commercial | true |
 | `ЛТ` | ЛТ | commercial | true |
 | `Демо` | Пресейл | presale | false |
 | `ИТС` | ИТС (договор) | commercial | true |
 | `ИТСПлатныеРаботы` | ИТС (доп. услуги) | commercial | true |
 | `Сертификация` | Сертификация | internal | false |
 | `Внутреннее` | Обучение | internal | false |
 | `Управленка` | Работа руководителя | internal | false |
 | `ВнутренниеРаботы` | Внутренние работы | internal | false |
 | `НеОпл` | Бесплатные часы в счёт ПП | free | false |
 | `Установка` | Установка в счёт ПП | free | false |
 | `Гарантия` | Гарантия | free | false |
 | `Коробка`, `Отложено` | (рудимент) | ignored | false |
 ### 6.4. mart-таблицы (дашборд MVP-1)
 ```sql
 mart.workload_actual_monthly       -- сотрудник × месяц → часы по категориям
 mart.workload_current              -- сотрудник × текущие задачи EVA (статус IN_PROGRESS) → часы (если есть оценка) или штуки
 mart.workload_planned              -- сотрудник × открытые задачи EVA (OPEN + IN_PROGRESS с responsible_id) → штуки и/или оценочные часы
 mart.workload_forecast             -- сотрудник × сделки Битрикс (от защиты КП до создания EVA-проекта) × proекторное распределение по проектной команде
 mart.tasks_orphan                  -- задачи без responsible_id или без project_id (для team awareness)
 mart.workload_summary              -- composite: сотрудник × недели → факт/текущая/план/прогноз
 ```
 ## 7. Identity-resolution
 ### 7.1. Сотрудники — через email
 Главный ключ. `lower(email)` сравнивается между:
 - BIT.RA `Catalog.Пользователи.КонтактнаяИнформация` (нужно дозаполнить если где-то пусто)
 - EVA `CmfPerson.login` (= email на firstbit, домен `@1cbit.ru`)
 - Bitrix24 `User.EMAIL` (домен `@1cbit.ru` у 117 из 133 активных)
 Fallback: ФИО → ручное разрешение через `core.identity_map` в NocoDB.
 ### 7.2. Проекты — через регистры BIT.RA + EVA_ID
 - `Catalog.Проекты.EVA_ID` — частично заполнен.
 - `InformationRegister.СоответствиеПроектовEVA_РА` — есть данные, обработка синхронизации сломана. **В рамках MVP-1 НЕ восстанавливаем** (это отдельная 1С-задача). Используем то, что есть в регистре + EVA_ID.
 - Что не сматчилось — отмечаем `confidence='manual'` и ждём ручного разрешения в NocoDB.
 ### 7.3. Клиенты — не маппим
 В MVP-1 связь BIT.RA-клиент ↔ Битрикс-компания не строим (ИНН в BIT.RA не заполняется, согласовано). Сделки Битрикса висят с `bitrix_company_id` без связки на BIT.RA.
 ### 7.4. Identity-map — таблица
 ```sql
 core.identity_map (
    entity_type,         -- employee | project
    core_id,             -- наш id
    bitra_id,
    eva_id,
    bitrix_id,
    confidence,          -- auto (по точному email) | confirmed (через UI) | manual (без авто-сматчинга, ждёт человека)
    confirmed_by,
    confirmed_at
 )
 ```
 В NocoDB представление — отдельная страница «Identity issues» — все записи с `confidence='manual'` сортированные по дате создания. Пользователь пробегает раз в неделю и подтверждает.
 ## 8. Стратегия SQL-трансформаций
 ### 8.1. raw → stg
 Stored procedure на каждую сущность каждого источника. Логика: `INSERT INTO stg_X SELECT FROM raw_X WHERE NOT EXISTS (...) ON CONFLICT UPDATE`. Идемпотентно.
 ### 8.2. stg → core
 Stored procedure `core.merge_employee()`, `core.merge_project()`, `core.merge_task()`, `core.merge_work_log()`, `core.merge_deal()`.
 Логика merge:
 1. Найти `core_id` через `core.identity_map`.
 2. Если найден — UPDATE.
 3. Если нет — попытаться сматчить (email, EVA_ID и т.п.). Если успех — UPDATE + добавить запись в identity_map.
 4. Если не сматчилось — INSERT новый core_id + identity_map с `confidence='manual'`.
 ### 8.3. core → mart
 Materialized views, обновляемые после каждой пачки sync'а. Триггер: N8N после sync'а делает `SELECT mart.refresh_all()`.
 ### 8.4. Версионирование SQL
 Структура проекта `~/projects/bit-flight-deck/` (имя финальное обсуждаем) — Gitea репозиторий:
 ```
 ~/projects/bit-flight-deck/
 ├── docker-compose.yml       -- Metabase + NocoDB (подключение к pipeline_net)
 ├── .env / .env.example
 ├── infra/
 │   ├── init-workload-db.sql -- создание БД workload + workload_user в pipeline_postgres
 │   └── cloudflared-routes.md-- документация по поддоменам tunnel
 ├── sql/
 │   ├── migrations/          -- одноразовые DDL миграции (CREATE TABLE и т.п.)
 │   ├── views/               -- view-определения
 │   ├── procedures/          -- stored procedures
 │   └── seed/                -- начальные данные (work_type категории, SD-projects whitelist)
 ├── n8n/
 │   └── workflows/           -- JSON-экспорты workflows N8N
 ├── docs/superpowers/specs/  -- эта спека и будущие
 └── README.md
 ```
 ## 9. Дашборд Metabase
 ### 9.1. Главный экран «Загрузка сотрудников MVP-1»
 | Раздел | Содержимое |
 |---|---|
 | Заголовок | Дата последней синхронизации (timestamp) с каждым источником |
 | Plate 1 | Средний % коммерческой загрузки команды за 30 дней (большая цифра, цвет) |
 | Plate 2 | Количество «безхозных» задач (без responsible_id или project_id) — намёк команде |
 | Таблица | По каждому из ~20 сотрудников: ФИО / Подразделение / Факт 30д часы / Факт 30д % коммерч. / Текущая (часы IN_PROGRESS задач) / Осталось (часы OPEN+IN_PROGRESS) / Прогноз 4 недели (Б24) / Итого 4 недели |
 | Линейный график | Динамика % коммерческой загрузки команды по неделям за 90 дней |
 | Барчарт | Свободные ресурсы — топ-N сотрудников с факт+план ниже 50% |
 | Таблица | Перегруженные — топ-N сотрудников с факт+план выше 90% |
 ### 9.2. Принципы визуализации
 - Светофор: красный <50%, жёлтый 50-70%, зелёный 70-100%, серый >100% (перегруз).
 - Все таблицы — с сортировкой и фильтрами по подразделению, виду работ.
 - Цифры — округлены до часов, не до минут.
 ## 10. Operational concerns
 ### 10.1. Мониторинг
 - N8N-flow «health check» каждый час: проверяет последние sync-таймстампы. Если sync с любым источником > 2 часа — алёрт в Telegram (или просто logging).
 - Метрики на дашборде: количество записей в каждой raw_*, last_sync timestamp по каждому источнику.
 ### 10.2. Бэкап
 - **PostgreSQL** — автоматический pg_dumpall ещё не настроен в инфре (TODO в `~/infrastructure/ROADMAP.md`). Для MVP-1 — ручной `pg_dump workload > workload-YYYY-MM-DD.sql.gz` раз в сутки (cron в WSL). Когда инфра-уровневый backup поднимется (sidecar `pipeline_pg_backup`) — наш проект пользуется им автоматом.
 - **Schema-only** бэкап перед каждой миграцией (`pg_dump --schema-only`).
 - **Gitea-репозиторий проекта** — резервируется автоматически с остальным Gitea (в рамках инфры).
 ### 10.3. Безопасность
 - EVA админ-токен в env N8N, не в git.
 - Bitrix webhook URL — с секретным токеном в URL (защита от случайных POST'ов).
 - PostgreSQL — отдельные роли: `etl_writer` (N8N) с правами на raw_*/stg_*, `analyst` (Metabase, NocoDB) с правами read-only на core/mart.
 - HTTPS на туннеле для Bitrix-webhooks (Битрикс требует валидный SSL).
 ### 10.4. Производительность
 Объёмы маленькие (десятки сотрудников, тысячи задач, тысячи строк работ в год). PostgreSQL без напряга справится. Индексы — по timestamps (modified_at, work_date) + по FK.
 ## 11. Acceptance criteria MVP-1
 1. ✅ В Metabase открыт дашборд «Загрузка сотрудников MVP-1», виден список ~20 сотрудников с 4 слоями загрузки.
 2. ✅ Факт за вчера в дашборде совпадает с тем что в BIT.RA `Document.Работы` за вчера (выборочная проверка 3 сотрудников).
 3. ✅ Текущая загрузка показывает задачи EVA в статусе `IN_PROGRESS` для сотрудников с `responsible_id`. Сверка с EVA-UI (выборочно).
 4. ✅ Прогнозная загрузка показывает сотрудников из проектных команд сделок Битрикса CAT=16 от стадии `FINAL_INVOICE` («Защита сделки»).
 5. ✅ NocoDB-страница «Identity issues» показывает несматчившиеся сущности (с `confidence='manual'`).
 6. ✅ Свежесть данных: BIT.RA — не старше 1 часа, EVA — не старше 1 часа, Bitrix — не старше 5 минут (webhook).
 7. ✅ Один полный цикл E2E: меняешь данные в источниках → через указанные временные окна они отражаются в дашборде.
 8. ✅ Дашборд отвечает на 5 бизнес-вопросов из секции 3 без ручной фильтрации.
 ## 12. Параллельные организационные задачи
 Не блокеры запуска MVP-1, но запускаются параллельно:
 - **Дисциплина EVA**: внедрить в команде заполнение `plan_start_date` / `plan_end_date` / `deadline` / `responsible_id` для всех новых задач. Через 2-3 месяца — пересмотр MVP-1 с честной «плановой» через plan_start_date.
 - **Email во всех системах**: дозаполнить email сотрудников в BIT.RA `Catalog.Пользователи` где пусто. Аналогично в Битриксе для новых юзеров.
 ## 13. Open questions / TODO
 - ✅ **Имя проекта** — `bit-flight-deck`. Gitea-репозиторий `bit-flight-deck`. Локальная папка `~/projects/bit-flight-deck/`.
 - ✅ **Поддомен для Bitrix-webhooks** — `n8n.bigmadnekenny.ru`. Добавить ingress-роут в cloudflared `host-systemd`.
 - **Список ~20 сотрудников MVP-1.** Какие конкретно email/department-id попадают в фокус? До начала разработки — выписать явный whitelist.
 - **3 SD-проекта.** Извлечь точные ID/коды из `https://gitea.bigmadnekenny.ru/admin/eva-bot/docs/`.
 - **Стадии Битрикса для прогноза.** Подтвердить точный список стадий CAT=16, в которых сделка должна учитываться в прогнозе. Кандидаты: `FINAL_INVOICE` («Защита сделки»), `UC_A02TUT` («Отложено»), `UC_U68WK1` («Подготовка рамочного договора»). Стадии `UC_XPZ8Z5/UC_QYTFP3` (Реализация) — туда уже EVA, в прогноз НЕ включаем.
 - **Заполняемость email в BIT.RA.** Через MCP проверить какой % пользователей имеет email в `КонтактнойИнформации`. Если ниже 80% — параллельная организационная задача.
 - **Распределение часов сделки по проектной команде.** Базовая логика — поровну между членами команды. Веса можно править в NocoDB. Возможно нужна более умная логика (по компетенциям) — это backlog для подсистемы D.
 ## 14. Backlog после MVP-1
 Не в MVP-1, но зафиксировано для последующих итераций:
 - **MVP-2: Подвисшие задачи и контроль сроков** — EVA `CmfStatusHistory` + детектор простоев + алёрты в Telegram.
 - **MVP-3: Маржа, НЗП, актирование** — BIT.RA `ОборотыПроектныхПоказателей_v2` + расчёты маржинальности и НЗП.
 - **MVP-4: Финрез по подразделениям** — finrez_1c + отдельный мозговой штурм по схеме расчёта + доработка финрезной 1С.
 - **Подсистема D: Компетенции (производная из core.work_log)** — расчёт «что сотрудник реально умеет» из истории работ.
 - **Восстановление обработки `СинхронизацияДанныхEVA_РА` в BIT.RA** — если потребуется для подсистемы C/D.
 - **Автоматическое распределение SD-задач по компетенциям сотрудников** — подсистема D.
 - **EVA TimeTracker** — если получится получить токен с правами на TimeTracker.
 - **DataLens вместо Metabase** — если потребуются более сложные визуализации.
 - **Полная Bitrix-интеграция** — все воронки, лиды, контакты.
@@ -0,0 +1,104 @@
 # 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`).
@@ -0,0 +1,93 @@
 # MVP-3 «Маржа, НЗП, актирование» — Design Draft
 | | |
 |---|---|
 | Дата | 2026-05-13 |
 | Статус | **Draft — фиксация обсуждённого, требует доработки после MVP-2** |
 | Зависимости | MVP-1 + MVP-2 (есть core.employee, core.project, core.stage, core.work_log) |
 | Срок | 2-3 недели после MVP-2 |
 > **Назначение этого документа:** зафиксировать то, что уже обсудили по MVP-3, чтобы не вспоминать заново. Это **набросок**, не финальная спека.
 ## Цели MVP-3
 Финансовая аналитика по проектам: маржа план/факт, незавершёнка (НЗП), прогноз актирования следующего месяца, контроль подписания результирующих документов.
 ### Главные бизнес-вопросы
 - Какая маржа по проектам (план/факт)?
 - Сколько НЗП (незавершёнки) на каждом активном проекте?
 - Сколько денег будем актировать в следующем месяце?
 - Где отстаём по срокам подписания актов?
 - Какая общая себестоимость и себестоимость по закрытым актам?
 ## Что добавляем к MVP-1/2
 ### Расширение core
 ```sql
 core.project_finance (
    id bigserial PRIMARY KEY,
    project_id bigint REFERENCES core.project,
    stage_id bigint REFERENCES core.stage,
    scenario_code text,             -- план | факт | прогноз (из Catalog.СценарииПланирования BIT.RA)
    analytics_type text,            -- ВидАналитики из BIT.RA (рассмотреть в core или хранить как есть)
    employee_id bigint REFERENCES core.employee,
    period_date date,               -- дата движения
    sum_total decimal(15,2),        -- Сумма (плановая/фактическая)
    sum_acted decimal(15,2),        -- СуммаАкт
    sum_expense decimal(15,2),      -- СуммаРасход
    source_doc_id text              -- ссылка на Document.ПланФактПроектныхПоказателей_v2
 )
 -- Возможно понадобится:
 core.stage_act (
    id bigserial PRIMARY KEY,
    stage_id bigint REFERENCES core.stage,
    plan_act_date date,             -- плановая дата акта (из Catalog.ЭтапыПроектов.ДатаОкончания)
    actual_act_date date,           -- фактическая дата подписания (если известно)
    is_signed boolean,
    sum_planned decimal(15,2),
    sum_actual decimal(15,2)
 )
 ```
 ### Новые витрины
 ```
 mart.project_margin            — маржа план/факт по проекту: (Сумма_план - СуммаРасход_план) / Сумма_план и аналогично для факта
 mart.wip                       — НЗП = Σ(часы × ставка) - актированная_выручка по проекту/этапу
 mart.actuation_forecast        — прогноз актирования: открытые этапы с ДатаОкончания в следующем месяце и Σ их Сумма
 mart.deadline_risks_financial  — риски по подписанию документов (расширение mart.deadline_risks из MVP-2 на финансовую сторону)
 mart.cost_summary              — общая себестоимость и себестоимость по закрытым (АктПодписан=true) этапам
 ```
 ### Источники данных (помимо MVP-1/2)
 - **BIT.RA эндпоинт `/api/project_register`** — `AccumulationRegister.ОборотыПроектныхПоказателей_v2` с инкрементом (измерения Сценарий+Проект+Этап+ВидАналитики+Исполнитель → ресурсы Сумма+СуммаАкт+СуммаРасход).
 - **BIT.RA эндпоинт `/api/plan_fact_v2`** — `Document.ПланФактПроектныхПоказателей_v2`. **ValueStorage поле `ХранилищеДерева` не тянем** (по [identity-and-scope](../../memory/feedback_identity_and_scope.md)).
 - **BIT.RA эндпоинт `/api/lurv`** — `Document.ЛУРВ` для понимания фактически выписанных листов учёта результатов выполнения.
 ### Дашборд (расширение)
 Новый дашборд «Финансы проектов» в Metabase:
 - Плитка «Общая НЗП» (сумма по всем активным проектам).
 - Плитка «Прогноз актирования за следующий месяц».
 - Таблица «Маржинальность проектов» — проект, план-маржа, факт-маржа, отклонение, цвет светофор.
 - Таблица «Этапы к актированию в этом/следующем месяце» — этап, плановая дата, сумма, готовность.
 - График «Динамика НЗП по проектам» за 12 месяцев.
 ## Open questions (для финализации перед стартом MVP-3)
 - **Что считать НЗП именно?** Текущая идея — `Σ(core.work_log.hours × core.employee.rate) − Σ(core.project_finance где сценарий=факт-акт)`. Но если расход в `ОборотыПроектныхПоказателей_v2.СуммаРасход` уже считается по факту работ — это будет двойной счёт. Уточнить семантику регистра.
 - **Сценарии (`Catalog.СценарииПланирования` BIT.RA)** — какие реально используются? План, факт, прогноз? Нужно понять словарь.
 - **`ВидАналитики` в регистре** — что это за измерение, какие значения? Возможно нужно тянуть `Catalog.ВидыАналитикиПроектныхПоказателей` (или подобное).
 - **Связь с финрезом подразделений (MVP-4)** — финрез считается из выручки и расходов, маржа проектов — тоже. Не дублируем ли мы расчёты? Возможно MVP-3 и MVP-4 нужно объединить или строго разграничить (MVP-3 = разрез по проектам, MVP-4 = разрез по подразделениям).
 - **Контроль подписания документов** — нужны ли дополнительные сущности (Договоры, ДополнительныеСоглашения)? Они есть в BIT.RA `Catalog.Договоры` и в ТЧ `Проекты.ДокументыЭтапов`.
 ## Зависимости от MVP-2
 MVP-3 стартует когда:
 - ✅ MVP-2 работает (есть core.stage, deadline-логика).
 - ✅ Identity-map проектов BIT.RA ↔ EVA стабильна.
 - Полезно но не обязательно: восстановлена обработка `СинхронизацияДанныхEVA_РА` (для стабильного маппинга проектов).
@@ -0,0 +1,111 @@
 # MVP-4 «Финрез по подразделениям» — Design Draft
 | | |
 |---|---|
 | Дата | 2026-05-13 |
 | Статус | **Draft — требует отдельного мозгового штурма по схеме расчёта** |
 | Зависимости | MVP-1 + MVP-2 + MVP-3 |
 | Срок | 2-3 недели после MVP-3 + отдельная сессия с пользователем по схеме расчёта |
 > **Назначение этого документа:** зафиксировать то, что уже обсудили по MVP-4, чтобы не вспоминать заново. **Это самая сырая из спек** — финальная схема расчёта финреза требует отдельного мозгового штурма.
 ## Цели MVP-4
 Автоматизация расчёта финрезультата по подразделениям. Сейчас пользователь ведёт расчёт **руками в Excel** и кладёт итоги в самописную 1С (см. [reference-finrez-1c](../../memory/reference_finrez_1c.md)).
 ### Главные бизнес-вопросы
 - Какой финрез у каждого подразделения за прошлый месяц / квартал / год?
 - Прогноз финреза на основе текущей загрузки.
 - Какие подразделения убыточны, какие прибыльны?
 ## Текущий статус автоматизации (как есть)
 В **самописной 1С** (без БСП, 9 объектов):
 - `Document.РегистрацияПоказателейЗаПериод` — ввод вручную раз в месяц.
 - ТЧ: Сотрудник × ФОТ × Оборот × КоличествоЧасов.
 - `AccumulationRegister.ПоказателиЗаПериод` — обороты с измерениями Сотрудник + Подразделение, ресурсы ФОТ + Оборот + Часы.
 То есть **в 1С лежит только итог**. **Сложная схема расчёта** живёт в голове пользователя и Excel-файлах. По его словам — «считаю сам, кладу финальную информацию, конфигурацию придется дорабатывать под реальные расчеты».
 ## Что планируется в MVP-4
 ### Этап 1 — Сбор и автоматизация ввода (вместо Excel)
 **До детального проектирования** — обязательная **сессия с пользователем** где он рассказывает:
 - Как именно считается выручка по подразделению (распределение проектной выручки между подразделениями? через сотрудников?).
 - Как считается расход (ФОТ + амортизация + накладные? распределение общих расходов?).
 - Какие статьи используются (ДДС / БДР)?
 - Как меняется схема по времени (что было до этого, что планируется).
 ### Этап 2 — Доработка самописной 1С
 Текущая конфигурация — приёмник готовых цифр. Нужно превратить в **калькулятор**:
 - Добавить справочник статей затрат.
 - Добавить документ с детализацией: Сотрудник × Статья × Сумма за период.
 - Привязка к проектам (если расходы можно атрибутировать на проект).
 - Привязка к данным из BIT.RA (фактические работы сотрудников).
 - Добавить email в `Catalog.Сотрудники` (для identity-resolution).
 - HTTP-сервисы — реализация в самописной 1С (см. [architecture-transport-decisions](../../memory/architecture_transport_decisions.md)).
 ### Этап 3 — ETL в core
 ```sql
 core.dept_finance_monthly (
    department_id bigint REFERENCES core.department,
    period_month date,
    fot decimal(15,2),
    oborot decimal(15,2),
    hours_count decimal(15,2),
    finrez decimal(15,2)                -- oborot - fot - расходы
 )
 core.expense_item (
    code text PRIMARY KEY,
    label text,
    category text                       -- ФОТ, амортизация, общие, ...
 )
 core.dept_finance_detailed (
    department_id bigint,
    period_month date,
    employee_id bigint REFERENCES core.employee,
    expense_item_code text REFERENCES core.expense_item,
    amount decimal(15,2)
 )
 ```
 ### Этап 4 — Витрины
 ```
 mart.dept_finance_monthly      — по подразделению × месяц: выручка, расходы по статьям, финрез, маржинальность
 mart.finrez_trend              — динамика по подразделениям за 12 мес
 mart.finrez_forecast           — прогноз финреза на основе текущей загрузки + средних показателей
 ```
 ### Этап 5 — Дашборд
 «Финрез по подразделениям» в Metabase:
 - Плитка «Финрез компании за прошлый месяц».
 - Таблица по подразделениям: выручка, расходы, финрез, маржинальность %, цвета.
 - График: динамика финреза по подразделениям за 12 месяцев.
 - Прогноз следующего месяца на основе загрузки.
 ## Identity-resolution
 Сотрудники самописной 1С ↔ BIT.RA — **сейчас нет общего ключа** (`Catalog.Сотрудники` имеет только Код+Наименование). После добавления email в `Catalog.Сотрудники` — связь через email (см. [identity-and-scope](../../memory/feedback_identity_and_scope.md)).
 ## Open questions (для финализации перед стартом MVP-4)
 1. **Схема расчёта финреза.** Это **самый главный вопрос**. Без него нельзя проектировать. Отдельная сессия пользователя.
 2. **Уровень детализации.** Расход сразу по статьям или агрегированно? По сотрудникам или нет?
 3. **Атрибуция выручки.** Как делится выручка проекта между подразделениями (если в проекте сотрудники разных подразделений)? Пропорционально часам? По ставке × часы?
 4. **Альтернатива** — может проще не дорабатывать 1С, а реализовать расчёт прямо в core PG, оставив 1С только для просмотра итогов? Решение зависит от готовности пользователя работать с витриной в Metabase вместо отчёта в 1С.
 5. **Прогноз финреза** — на основе чего считать? Среднее за прошлые периоды + текущая загрузка + ставки. Или модель сложнее.
 ## Зависимости от MVP-3
 MVP-4 стартует когда:
 - ✅ MVP-3 работает (есть core.project_finance с маржой).
 - ✅ Отдельная сессия с пользователем по схеме финреза завершена.
 - ✅ Решение по доработке finrez_1c принято (доработка vs расчёт в core).
@@ -0,0 +1,102 @@
 # Подсистема D «Компетенции сотрудников» — Design Draft
 | | |
 |---|---|
 | Дата | 2026-05-13 |
 | Статус | **Draft — может реализовываться параллельно с MVP-2/3 или после** |
 | Зависимости | MVP-1 (есть core.work_log + core.employee + core.project) |
 | Срок | 1-2 недели работы (зависит от того, насколько детально нужен механизм распределения) |
 > **Назначение:** зафиксировать обсуждённый подход к компетенциям. Это **набросок**.
 ## Ключевое решение пользователя
 Цитата: «таблицу по компетенциям возможно придется собирать по проделанным зафиксированным работам в БИТ.РА, портфолио проектов возможно тоже».
 **Why:** ручное ведение справочника компетенций сотрудников — нерабочая практика (устаревает, субъективно, никто не обновляет). Объективная компетенция = что человек реально делал в последний период.
 См. [identity-and-scope](../../memory/feedback_identity_and_scope.md).
 ## Цели Подсистемы D
 1. Автоматически рассчитать матрицу «сотрудник × компетенция × уровень» на основе истории работ.
 2. Использовать матрицу для:
   - Подсказки распределения проектной команды Битрикс-сделок на конкретных сотрудников (улучшение MVP-1 — сейчас наивно поровну).
   - Автоматического распределения SD-задач по компетенциям (бэклог-айтем MVP-2).
   - Подсказки руководителю «кто свободен и умеет делать X».
 ## Что такое «компетенция» в нашем контексте
 **Двухмерное определение:**
 - **Конфигурация** = с каким продуктом сотрудник работал (1С:ERP, 1С:ЗУП, БИТ.ФИНАНС, и т.д.). Берём из `core.project.bitra_id` → `BIT.RA.Catalog.Проекты.Конфигурация` (`Catalog.Конфигурации`).
 - **ВидРаботы** = что делал (ЛУРВ / ЛТ / ИТС / Пресейл и т.п.). Берём из `core.work_log.work_type_code` (см. [reference-bitra-work-types](../../memory/reference_bitra_work_types.md)).
 То есть компетенция = пара `(Конфигурация × ВидРаботы)`.
 ## Расчёт уровня компетенции
 ```
 weight(employee, config, work_type, period) =
    Σ(hours) where work_log.employee = employee
              AND work_log.project.config = config
              AND work_log.work_type = work_type
              AND work_log.period >= period - 12 months
 ```
 Уровень владения = относительный вес:
 - «Эксперт» — > 100 часов за последние 12 мес.
 - «Опытный» — 30-100 часов.
 - «Знаком» — 5-30 часов.
 - «Нет опыта» — < 5 часов.
 Пороги — конфигурируемые в `core.config`.
 ## Расширение core
 ```sql
 core.employee_competence (
    employee_id bigint REFERENCES core.employee,
    config_code text,                  -- Конфигурация (1С:ERP, БИТ.ФИНАНС и т.д.)
    work_type_code text,               -- Вид работ
    hours_12m decimal(15,2),           -- часы за последние 12 месяцев
    hours_3m decimal(15,2),            -- за последние 3 месяца (для свежей картины)
    level text,                        -- эксперт | опытный | знаком | нет_опыта
    last_work_date date,               -- когда последний раз делал
    PRIMARY KEY (employee_id, config_code, work_type_code)
 )
 ```
 Заполняется materialized view'хой, обновляется раз в сутки (после ежедневной синхронизации BIT.RA).
 ## Применение в системе
 ### 1. Распределение проектной команды сделок Битрикс (улучшение MVP-1)
 Сейчас (MVP-1): часы делятся поровну между членами `UF_CRM_1729244690` (проектная команда).
 С компетенциями (улучшение): часы распределяются с учётом уровня компетенции каждого члена команды по `Конфигурации` сделки (`UF_CRM_1729244070`). Эксперт получает больше, новичок — меньше. Веса можно править в NocoDB вручную.
 ### 2. Автоматическое распределение SD-задач (бэклог-айтем)
 В SD-задачах часто нужно быстро назначить исполнителя. Если задача относится к 1С:ERP (по `cf_konfiguracziya1`), система предлагает топ-3 сотрудника с подходящей компетенцией и низкой текущей загрузкой.
 ### 3. Дашборд «Компетенции команды»
 Витрина `mart.competence_matrix`:
 - Heatmap: сотрудники × Конфигурации, цвет = уровень компетенции.
 - Таблица «Узкие места» — конфигурации, по которым у компании только 1 эксперт.
 - Таблица «Покрытие команды» — какие компетенции есть в команде, какие нет.
 ## Open questions
 - **Маппинг `Catalog.Конфигурации` BIT.RA ↔ Bitrix `UF_CRM_1729244070`** — это разные справочники, но семантически похожие. Нужна ручная таблица соответствий в `core.identity_map_config`. См. также [reference-bitrix24-classifications](../../memory/reference_bitrix24_classifications.md).
 - **Учёт пресейла как компетенции.** Если сотрудник делал только пресейл по конфигурации (без ЛУРВ/ЛТ) — он эксперт по продаже, но не по реализации. Различать.
 - **Перевод сотрудника** — если человек 5 лет делал 1С:Розница, потом переключился на 1С:ERP, окно «12 месяцев» это покажет, но текущая компетенция = ERP. Можно добавить «свежесть» (hours_3m).
 - **Подсистема D vs MVP-2.** Если автоматическое распределение SD-задач нужно как часть MVP-2 — D становится зависимостью MVP-2. Если как улучшение MVP-1 — параллельно с MVP-2. Решить после MVP-1.
 ## Зависимости от MVP-1
 Подсистема D стартует когда:
 - ✅ MVP-1 работает.
 - ✅ `core.work_log` стабильно заполняется из BIT.RA.
 - ✅ `core.project` маппится с конфигурациями (через `Catalog.Проекты.Конфигурация`).