АРХИТЕКТУРА ПЛАТФОРМЫ — Единый стандарт

E0  ФИЛОСОФИЯ       Зачем мы это делаем? Принципы, ценности
E1  МЕТОДОЛОГИЯ     Как думать? Теория (Меркаба, 9 вопросов)
E2  СТАНДАРТЫ       Как делать? Правила, паттерны
E3  ПЛАТФОРМА       Чем делать? Движки, API, CLI
E4  БЛОКИ           Из чего? Коннекторы, функции, модули
E5  КОМПОНЕНТЫ      Как собрать? Готовые наборы
E6  РЕШЕНИЯ         Что получается? Проекты клиентов

$WORKSPACE/
├── architect/        ← E0–E2: Разум (философия, методология, стандарты)
│   ├── theory/       ← E0–E1: LOCKED
│   ├── concept/      ← E1: Концепции платформы
│   └── standards/    ← E2: Правила
├── system/           ← E3–E4: Платформа
│   ├── core/         ← E3: Движок
│   ├── agents/       ← E3: AI-агенты
│   └── modules/      ← E4: Модули
├── library/          ← E4–E5: Библиотека компонентов
├── projects/         ← E6: Проекты клиентов
└── infra/            ← Инфраструктура воркспейса

T0  ИНФРАСТРУКТУРА   Серверы, Docker, PostgreSQL, S3, Nginx
T1  ДАННЫЕ           ORM, миграции, схема БД, RLS
T2  БИЗНЕС-ЛОГИКА    FastAPI сервисы, state machines, guards
T3  API              REST, GraphQL, WebSocket, PostgREST
T4  КЛИЕНТ           UI фреймворк, компоненты, SDUI

T4  Jinja2 + HTMX          ← HTML рендер на сервере + partial updates
T3  FastAPI routes           ← REST + HTML endpoints
T2  FastAPI services         ← бизнес-логика Python
T1  SQLAlchemy + Alembic     ← ORM + миграции
T0  PostgreSQL + Nginx       ← БД + entry point

T4  Refine (React)           ← Data-driven UI, CRUD автоматически
T3  PostgREST + FastAPI      ← Auto REST из схемы + кастомная логика
T2  FastAPI + Celery         ← бизнес-логика + фоновые задачи
T1  Supabase core            ← PostgreSQL + GoTrue + RLS + Realtime + Storage
T0  Docker compose + Nginx   ← оркестрация сервисов

D1  БИБЛИОТЕКА ПОЛЕЙ    Field Library: типы полей и их параметры
D2  СТРОИТЕЛИ СХЕМ      13 классов конфигурации (EntityClass, FormClass...)
D3  КОНФИГУРАТОР        YAML профили: объявление поведения системы

# Примитивные
field_types:
  - string, text, integer, decimal, boolean, date, datetime, time

# Ссылочные
  - foreign_key       # ссылка на другую сущность
  - taxonomy_ref      # ссылка на справочник
  - enum              # фиксированный список значений

# Специальные
  - money             # decimal + валюта
  - phone             # строка + форматирование
  - file_ref          # ссылка на файл в Storage
  - geo_point         # широта + долгота
  - json_blob         # произвольная структура

EntityClass      → PostgreSQL: CREATE TABLE, колонки, индексы
TaxonomyClass    → PostgreSQL: справочные таблицы (brands, statuses)
EnumClass        → PostgreSQL: перечисления (ENUM type)
──────────────────────────────────────────────────────────
PipelineClass    → FastAPI + Refine: state machine, kanban, переходы
──────────────────────────────────────────────────────────
RoleClass        → GoTrue + PostgreSQL: роли в БД, JWT claims
PermissionClass  → FastAPI: guard декораторы (@require_permission)
VisibilityClass  → PostgreSQL RLS: POLICY per role per table
──────────────────────────────────────────────────────────
ValidationClass  → FastAPI + Refine: guard при переходах стадий
AutomationClass  → Celery + FastAPI: tasks, beat schedule, event triggers
NotifyClass      → Celery + elements: notification tasks, шаблоны
──────────────────────────────────────────────────────────
FormClass        → БД ui_config: конфиг формы (поля, порядок, секции)
LabelClass       → БД ui_config: терминология (i18n, нишевые названия)
ReportClass      → БД ui_config + FastAPI: виджеты дашборда, /analytics
──────────────────────────────────────────────────────────
FeatureClass     → PostHog: feature flags per tenant

1. EntityClass + TaxonomyClass + EnumClass   ← ФУНДАМЕНТ: схема данных
2. PipelineClass                              ← зависит от EntityClass
3. RoleClass                                 ← абстрактный, не зависит
4. PermissionClass + VisibilityClass         ← зависит от RoleClass + EntityClass
5. ValidationClass + AutomationClass         ← зависит от EntityClass + PipelineClass
6. FormClass + LabelClass + ReportClass      ← зависит от EntityClass + RoleClass → пишет в БД
7. NotifyClass                               ← зависит от AutomationClass + RoleClass
8. FeatureClass                              ← управляет всеми выше

# profiles/automotive.yaml
name: automotive
version: 1.0
type: industry
extends: base-crm

data:            # → EntityClass, TaxonomyClass
access:          # → RoleClass, PermissionClass, VisibilityClass
process:         # → PipelineClass, ValidationClass, AutomationClass
ui:              # → FormClass, LabelClass, ReportClass → в БД
features:        # → FeatureClass → PostHog

R0  ДВИЖОК СХЕМ         загружает EntityClass → маршруты, RLS, индексы
R1  ДВИЖОК ФОРМ         читает FormClass → рендерит UI без деплоя (SDUI)
R2  ДВИЖОК ЛОГИКИ       исполняет ValidationClass + AutomationClass
R3  ДВИЖОК ДАННЫХ       PostgREST + RLS → изолированные запросы per tenant
R4  ДВИЖОК ОТЧЁТОВ      читает ReportClass → генерирует виджеты, PDF

D3 (YAML профиль)
    ↓ profile.compile()
┌──────────────────────────────────────────────┐
│ migrations/001_entities.sql   → R0 (схема)  │
│ migrations/002_rls.sql        → R3 (данные) │
│ fastapi/generated/routes.py   → R2 (логика) │
│ celery/generated/tasks.py     → R2 (авто)   │
│ db_seed/ui_config_forms.json  → R1 (формы)  │
│ db_seed/ui_config_labels.json → R1 (лейблы) │
│ posthog/flags.json            → R4 (флаги)  │
└──────────────────────────────────────────────┘

ЧТО                              ГДЕ             ПОЧЕМУ
────────────────────────────────────────────────────────────────────
docker-compose, .env, nginx      файлы / git     секреты, деплой
Структура БД (CREATE TABLE)      SQL миграции    нужна миграция
FastAPI маршруты и логика        Python / git    требует деплой
Celery задачи                    Python / git    требует деплой
────────────────────────────────────────────────────────────────────
Конфигурация форм                БД ui_config    меняется без деплоя
Лейблы / терминология            БД ui_config    per-tenant
Порядок полей, навигация         БД ui_config    per-tenant
Отчёты / виджеты дашборда        БД ui_config    per-tenant
────────────────────────────────────────────────────────────────────
Feature flags                    PostHog         runtime вкл/выкл

M0  МЕТА-ТИПЫ          Что может быть типом поля (Field Library)
M1  СХЕМЫ              EntityClass, TaxonomyClass — структура данных
M2  КОНФИГУРАЦИЯ       FormClass, LabelClass, FeatureClass — поведение
M3  ДАННЫЕ             Записи в таблицах — то, с чем работает пользователь

M0  Тип поля: taxonomy_ref (из Field Library)
      ↓
M1  EntityClass Deal → field "truck_brand: taxonomy_ref → brands"
      ↓
M2  FormClass Deal → section "Грузовик" → show truck_brand; LabelClass → "Марка"
      ↓
M3  deals.truck_brand = "Volvo" (запись пользователя)

ПЛАТФОРМА (ядро — неизменно)
    └── base-crm / base-erp / base-fsm    ← БАЗОВЫЙ (обязательный)
            └── automotive / metrologia    ← ОТРАСЛЕВОЙ
                    └── ru-market          ← РЕГИОНАЛЬНЫЙ (опционально)
                            └── 1c-integration  ← ТЕМАТИЧЕСКИЙ (опционально)
                                    └── ТЕНАНТ (клиент)

profiles:
  - base-crm        # обязательно
  - metrologia      # отрасль
  - ru-market       # регион

extend  → можно оставить extend, override или lock
override → можно оставить override или lock
lock     → всегда lock, нельзя открыть ниже

# profiles/metrologia.yaml
data:
  taxonomy:
    - name: device_types           # типы приборов
      values: [Манометр, Термометр, Весы]
      mutability_down: extend      # тенант может добавить свои типы
  entities:
    - name: calibration_record
      fields:
        - name: gost_number
          type: string
          mutability_down: lock    # тенант НЕ может убрать поле ГОСТ

[base-crm] + [metrologia] + [ru-market]
    ↓ profile.compile()
    ↓
migrations/       ← SQL для PostgreSQL (EntityClass, RLS)
fastapi/          ← Python routes + guards + pipelines
celery/           ← tasks + schedule
db_seed/          ← ui_config (формы, лейблы, навигация) → БД
posthog/          ← feature flags → PostHog

V1  LAYOUT        Расположение блоков, сетка, структура страниц
V2  STYLES        Визуал компонентов (кнопки, карточки, таблицы)
V3  THEME         Дизайн-токены: цвета, шрифты, отступы, радиусы
V4  BRANDING      Айдентика: логотип, название, favicon, шрифты клиента

# layout/shell.yaml
shell:
  header:
    height: 56px
    position: fixed
    elements: [logo, search, notifications, user]
  sidebar:
    width: 240px
    collapsed_width: 64px
  main:
    padding: 24px

# layout/pages/list.yaml, form.yaml, dashboard.yaml...

# styles/buttons.yaml
buttons:
  base:
    border_radius: "{radius.md}"
    font_weight: 500
  variants:
    primary:
      background: "{color.primary}"
    danger:
      background: "{color.error}"

# theme/colors.yaml
colors:
  primary: "#FF6B00"
  background: "#FFFFFF"
  text: "#212121"
  success: "#4CAF50"
  error: "#F44336"

:root {
  --color-primary: #FF6B00;
  --font-family: 'Inter', sans-serif;
  --space-md: 16px;
  --radius-md: 8px;
}

# branding/branding.yaml
branding:
  name: "МетроCRM"
  logo:
    light: ./assets/logo.svg
  theme_overrides:
    primary: "#1565C0"

УРОВЕНЬ       LAYOUT        STYLES        THEME         BRANDING
────────────────────────────────────────────────────────────────────
ПЛАТФОРМА     базовый shell  все компон.  серые дефолты  placeholder
ПРОДУКТ       CRM dashboard  kanban/badge цвета отрасли  лого типа
КЛИЕНТ        (редко)        (редко)      accent-цвет    лого + favicon

design = merge(load("platform/design/"))       # V1–V4 базовые
design = merge(design, load("product/design/")) # V1–V4 продукта
design = merge(design, load("tenant/design/"))  # V1–V4 клиента

УНИВЕРСАЛЬНОЕ ЯДРО (7 архетипов — одинаковы для всех ниш):
  A1 Учёт объектов         → base-erp / base-fsm профиль
  A2 Диспетчеризация       → base-fsm профиль
  A3 Выездные работы       → mobile-module
  A6 Финансы               → base-billing профиль
  A7 Зарплата              → base-payroll профиль
  A8 ТО / CMMS             → base-cmms профиль
  A9 Отчётность            → base-reports профиль

НИШЕВЫЕ КОНФИГИ (2 архетипа — уникальны для ниши):
  A4 Регуляторные журналы  ← под конкретного регулятора (A4-metrologia, A4-fire, ...)
  A5 Расходные материалы   ← под специфику производства (A5-fuel, A5-reagents, ...)

B1  МОДУЛИ (A1–A9)         Универсальные кирпичи ядра
B2  НИШЕВЫЕ КОНФИГИ        YAML профили под отрасль (A4 + A5)
B3  ВЕРТИКАЛЬНЫЕ ПРОДУКТЫ  Ядро + нишевый конфиг = готовый продукт
B4  МОНЕТИЗАЦИЯ            Ценообразование, тарифы, деплой
B5  КАРТА НИШ              Куда идём, приоритеты

B1 ядро (A1+A2+A3+A6+A7+A8+A9)
    +
B2 нишевый конфиг (A4-metrologia + A5-reagents)
    =
B3 "МетроСофт" — SaaS для поверочных лабораторий

E4 (блоки воркспейса)
    ↕ реализуются как
T0–T4 (технический стек)
    ↕ конфигурируются через
D1–D3 (design-time) → компилируются → R0–R4 (runtime)
    ↕ уровень абстракции описывается через
M0–M3 (мета-абстракция)
    ↕ поведение определяется профилями
Профили (base → industry → region → tenant)
    ↕ UI настраивается через
V1–V4 (визуальный дизайн)
    ↕ продукт закрывает
A1–A9 (бизнес-архетипы)
    ↕ монетизируется как
B3 (вертикальные продукты) в нишах B5