Анализ эндпоинтов в services и возможность перехода с моков на реальный бэкенд¶

Соответствие docs/architecture/microservices-map.md и фактической реализации в services/, плюс оценка готовности к отключению моков на фронте.

Целевая спецификация (Gateway, REST+GraphQL, gRPC между сервисами): gateway-services-grpc-spec.md.

1. Что реализовано в services (по карте микросервисов)¶

1.1 В корневых workspaces (package.json)¶

В services/package.json в workspaces входят только: shared, auth, control, contact, company, gateway.
Остальные папки (activity, orders, pipe, product) в workspaces не объявлены и выглядят как шаблонные/дублирующие структуры.

1.2 Реальные эндпоинты по сервисам¶

Сервис (по карте)	Реализованные эндпоинты	Соответствие карте
auth	`POST /auth/login`, `POST /auth/service-token`, `GET /auth/me`; `GET/POST /oauth/authorize`, `POST /oauth/token`, `POST /oauth/introspect`, `POST /oauth/revoke`; `GET /users`; `GET /.well-known/openid-configuration`; `GET /oidc/providers`; `POST /api-keys/introspect`; health/metrics	Частично: вход, токены, me, OIDC/OAuth, API keys. Нет: signUp, forgotPassword, resetPassword, verifyEmail, 2FA, acceptInvite, явного refresh.
control (Org + Project)	`POST/GET/GET :id /projects`, `PUT /projects/:id`, `GET/POST/PUT/DELETE /projects/:id/members`; `POST/GET/GET :id /workspaces`; `GET /internal/v1/access/check`; health/metrics	Частично: проекты, участники, воркспейсы, внутренняя проверка доступа. Нет: организации, подразделения, сотрудники, приглашения (Org).
contact	`POST/GET/GET :id/PUT/DELETE /contacts`, `POST /contacts/:id/restore`; все с `?projectId=`. Health/metrics.	Да: CRUD + soft delete/restore. Нет: merge, дедупликация, импорт, связь contact–company (many-to-many).
company	`POST/GET/GET :id/PUT/DELETE /companies`, `POST /companies/:id/restore`; все с `?projectId=`. Health/metrics.	Да: CRUD + soft delete/restore. Нет: merge, импорт, связь с контактами.
gateway	GraphQL (Mercurius), Auth (свой контроллер), Users, Health, Metrics. БД (Prisma).	Не AGW из карты: нет маршрутизации на contact/company/pipe/orders и т.д., нет единой точки входа для REST CRM. Сейчас это отдельное BFF-подобное приложение с GraphQL и своим auth.

1.3 Чего нет в реализованных сервисах (по карте)¶

Pipelines & Deals (pipe): в репозитории есть папки pipe/, pipe/company/, pipe/company/contact/ с теми же шаблонными контроллерами (companies, contacts, health, metrics). Отдельных эндпоинтов для воронок, источников сделок, сделок (CRUD, moveDealToStage, closeDeal и т.д.) нет.
Orders (orders): папки orders/, orders/company/, orders/company/contact/ — только companies/contacts/health/metrics. Эндпоинтов для типов продаж, продаж, этапов, DLQ нет.
Products (product): аналогично — только шаблонные companies/contacts. Эндпоинтов для каталога продуктов нет.
Activities (activity): только contacts (+ companies в подпапках). Эндпоинтов для задач/звонков/встреч/заметок, календаря, напоминаний нет.
Documents, Reports, Search, Audit, Notifications, Billing, Storage, IGW — в коде сервисов не представлены.
AGW как в документе: единой точки входа с проксированием на доменные сервисы (contact, company, pipe, orders и т.д.) нет; gateway — отдельное приложение с GraphQL и своим auth.

2. Что ожидает фронт (моки)¶

Базовый URL: apiPrefix: '/api' (запросы уходят на тот же origin или прокси).
Auth:
POST /api/sign-in (body: email, password) → 201 + { user, token }.
В бэкенде: POST /auth/login (LocalAuthGuard, тело по LoginDto). Путь и формат ответа могут отличаться (например, login vs email, структура user).
CRM (crmFakeApi):
Список/одна: GET /api/crm/contacts, GET /api/crm/contacts/:id; то же для companies, deals, orders, activities, products.
Специфичное: GET /api/crm/dashboard; GET /api/crm/deals/kanban, GET /api/crm/orders/kanban, GET /api/crm/order-types; GET /api/crm/pipelines, GET /api/crm/deal-sources, GET /api/crm/members.
Пагинация/сортировка/поиск через query: pageIndex, pageSize, sort (order, key), query и др.
Моки возвращают { list, total } для списков.

Текущие бэкенд-контроллеры (contact, company) используют пути без префикса /api/crm/ и требуют projectId в query. То есть расхождение: базовый путь (/contacts vs /api/crm/contacts) и обязательный projectId на бэке при том, что фронт может не передавать его в том же виде.

3. Оценка возможности использовать реальный бэкенд вместо моков¶

3.1 Уже можно перевести на реальный бэкенд (с доработками)¶

Аутентификация
Реализованы: login, me, OAuth/API keys.
Нужно: привести фронт к контракту бэкенда (путь POST /auth/login, тело/ответ, куда класть токен) и при необходимости добавить на бэке sign-up/refresh, если решите их использовать с фронта.
Контакты и компании
Реализованы полные CRUD + restore по projectId.
Нужно:
- на стороне фронта вызывать /api/.../contacts и /api/.../companies с projectId (из текущего проекта/контекста);
- ввести слой (BFF или gateway), который либо проксирует запросы с префиксом вида /api/crm/contacts → contact-сервис с подстановкой projectId, либо фронт переводится на прямые пути вида /api/contacts?projectId=... и единый базовый URL бэкенда.

3.2 Нужна доработка бэкенда и/или контракта¶

Единая точка входа (AGW)
Сейчас нет маршрутизации вида /api/crm/* → contact/company/deals/orders. Варианты:
Реализовать в gateway (или отдельном прокси) маршруты типа /api/crm/contacts → contact, /api/crm/companies → company, с добавлением projectId из JWT или query.
Либо оставить фронт с прямыми вызовами на contact/company с общим базовым URL и явной передачей projectId.
Формат списков
Бэкенд уже отдаёт { list, total } для contact/company — это совпадает с моками. Нужно зафиксировать контракт (и при необходимости пагинацию: pageIndex 0-based vs 1-based) и придерживаться его на фронте и в остальных сервисах.
Проекты и воркспейсы
Эндпоинты control (projects, workspaces, access) есть; фронту нужно получать список проектов/текущий проект и подставлять projectId в запросы к contact/company.

3.3 Пока только моки (нет реализации в services)¶

Сделки (deals): списки, канбан, CRUD, move stage, close, reopen, transfer, drift, bulk — в services не реализованы.
Воронки и источники: pipelines, deal-sources — нет.
Продажи (orders): списки, канбан, типы продаж, этапы, DLQ — нет.
Продукты: каталог, привязка к типу продажи — нет.
Активности: задачи, календарь, напоминания — нет.
Дашборд, отчёты, участники проекта (members), документы, поиск, аудит, уведомления, биллинг, файлы — либо нет, либо только в карте/требованиях.

Для этих сущностей переход на реальный бэкенд возможен только после реализации соответствующих API в services (и приведения контракта к тому, что ожидает фронт).

4. Краткий вывод¶

Направление	Реализовано в services	Готовность к отказу от моков
Auth (login, me, токены)	Да (путь/формат могут отличаться)	Возможно после согласования контракта и, при необходимости, доработки auth/gateway.
Контакты	Да (CRUD + restore, projectId)	Возможно после введения префикса/прокси и передачи projectId с фронта.
Компании	Да (CRUD + restore, projectId)	То же.
Проекты / воркспейсы / доступ	Частично (control)	Возможно использовать для выбора проекта и projectId.
Сделки, воронки, продажи, типы продаж, продукты, активности	Нет	Только моки до появления соответствующих эндпоинтов.
Дашборд, отчёты, members, документы и пр.	Нет	Только моки.

Итого: реальный бэкенд вместо моков уже можно использовать для аутентификации, контактов и компаний при условии: (1) согласования путей и форматов с фронтом (в т.ч. префикс /api/crm/ и projectId), (2) появления в gateway/прокси маршрутизации на contact/company или перевода фронта на прямые вызовы с projectId. Остальные разделы CRM (сделки, продажи, продукты, активности и др.) в services по микросервисной карте пока не реализованы, их подключать не к чему — фронт для них остаётся на моках до реализации API.