Библиотека-фундамент: DDD-примитивы, EF Core + Postgres (авто-фильтры тенантов, аудит-штампы), Wolverine + NATS + outbox, identity propagation, Serilog / OTel / health.
Единая точка входа: YARP, JWT/JWKS-валидация, auto-discovery маршрутов, агрегация Swagger всех сервисов.
Вход / refresh / logout (RS256, ротация ключей), Провайдеры → Клиенты → Пользователи + admin CRUD (ETag, PATCH, пагинация).
Журнал действий («роли и мультиклиентность» из карты): аудит auth и админки, durable-consumer, DLQ + admin API.
Обмен справочниками между сервисами: push через outbox/NATS + pull API. Сейчас: User, Provider, Customer.
docker compose + Dockerfile'ы всех сервисов + smoke-тест уже в репо. Мультитенантность Provider(=реселлер)→Customer — сквозная, на уровне EF-фильтров.
Permission = Entity:Action, роли в БД Accounts, снимок прав в JWT, декларативный gate .RequirePermission("Tyre:Create") + готовый RequestContext до входа в handler. Сюда же: закрыть открытый /admin/users, мёртвый monitor:role, token lifecycle. Архревью готово (спек 05-31), модель прав — своя, не копия v4.
Общая сущность всех транспортных модулей: VIN, гос.номер, марка/тип, привязка к Customer. CRUD + push в SharedData. Пробег в MVP — ручной; телематика позже станет вторым источником тех же полей. Продолжаем осмысление старой попытки m5 (Fleet→Vehicle→Trip→Driver, глоссарий).
Каркас нового сервиса со всем подключённым (Blocks, БД+миграции, outbox, authz, тесты, Dockerfile, маршрут в Gateway). README бэкенда, карта сервисов, гайд «как создать модуль» + CLAUDE.md-конвенции для чужих агентов.
Репозиторий сейчас существует только на одной машине — запушить на сервер (вопрос: где). CI: build + все тесты на PR (runner с docker: Postgres/NATS). Сиды демо-данных для compose.
Операционная готовность (фоном между вехами): DLQ retention, ротация JWKS, миграции отдельным job'ом, полный .slnx, централизованные версии пакетов, секреты.
Калибровка темпа: вся текущая база (11 планов) сделана агентным процессом в одиночку за ≈3 недели. Потоки A–D — сопоставимый объём.
Основная петля: агент меняет код → тесты против реального Postgres/NATS → smoke. Стек лёгкий, compose поднимает всё. Мини-кубер на ноутбуках не нужен — поведение выравнено env-конфигом. При 15+ сервисах — compose-профили.
Авто-деплой после зелёного CI. Роли: точка приёмки человеком, интеграция «всё живьём», стабильный API для фронта, демо руководству. Сейчас: VM + compose (день работы). Позже: namespace в существующем k8s.
Ветка → PR → зелёный CI → ревью → main → стенд. PR — единица приёмки агентной работы: диф + тесты + поведение на стенде, а не вера на слово. Модуль = свой сервис → конфликты минимальны.
Основной автор кода — агенты; человек ставит задачи и принимает. Что это требует:
| Правила в репо | CLAUDE.md на монорепо и каждый сервис, шаблоны спек/планов, гайд модуля — агенты всех разработчиков играют по одним правилам |
| Машинная обратная связь | тесты, анализаторы, dotnet format, FSD-линтер фронта — агент видит поломку сам, до человека и до CI |
| Контракт-first | OpenAPI каждого сервиса → кодоген клиентов; агент не угадывает API соседа |
| Малые сервисы | модуль целиком помещается в контекст агента — выше точность правок |
| Локальные LLM-доки | паттерн уже есть (docs/wolverine) — не полагаемся на устаревшие тренировочные данные |
| Ревью-цепочка | спек-ревью → код-ревью → независимый Codex — текущая практика, стандарт и для модулей |
Цикл: человек пишет спеку → агенты имплементируют → CI + ревью → merge → стенд → приёмка на стенде.
| Монорепо | pnpm workspaces + Turborepo + Vite 7 ✓ |
| Ядро | React 19 + TypeScript 5.9 ✓ |
| UI-kit | FluentUI v9 — преемственность с v4 ✓ |
| Состояние | TanStack Query 5 + Zustand 5 (вместо MobX) ✓ |
| API-слой | Kubb: кодоген typed-клиента + react-query хуков из OpenAPI Gateway — контракт-first ✓✓ |
| Структура | Feature-Sliced Design + steiger-линтер — агенты не разводят хаос ✓ |
| Карта | MapLibre GL; ⚠ выбрать: react-map-gl или react-leaflet (сейчас оба) |
| Приложения | apps/web + apps/admin раздельно, i18n (react-intl) с первого дня ✓ |
• Главный экран — метрики и сигналы: система сама следит за парком и говорит, куда смотреть (отклонения, перерасход, просроченное ТО, рейтинг водителя).
• Карта — один из экранов, а не центр вселенной.
• Пользователь работает от задач и отклонений, а не от разглядывания отчётов.
• Каждый модуль поставляет свои метрики/сигналы на главный экран — контракт «модуль → дашборд» закладываем в шаблон модуля.
Деливерабл: концепт + прототип главного экрана (руководитель / диспетчер / механик).
| Когда | Модули карты | Почему |
|---|---|---|
| После В2 без телематики |
FMS: ТО по регламентам (ручной пробег), склад/шины/АКБ, заявки и наряды · TMS: путевые листы, задания · CORE: роли и мультиклиентность | опираются только на реестр ТС + права + справочники |
| После В4 | CORE: онлайн-мониторинг, треки, геозоны, события · FUEL · VEHICLE (CAN) · SAFETY | требуют потока телеметрии |
| По мере надобности | уведомления, движок отчётов, файлы (S3), интеграции/API-ключи | общие платформенные сервисы — когда первый модуль в них упрётся |
| Поздние | маркетплейс, white-label/биллинг, вертикали, регуляторика | эпики поверх зрелой платформы |