type: concept
title: "Метамодель платформы — как платформа описывает себя"
status: draft
version: 0.1.0
date: 2026-04-09
owner: architect
Как платформа устроена, как описывается, как изменяется.
Это мета-уровень — описание описания.
1. ЗАЧЕМ Видение, цели, принципы существования платформы
2. ЧТО Состав платформы (5 подсистем, семья серверов)
3. КТО Роли (Архитектор, Проектор, Кодер, Инфра, Оператор)
4. КАК Процессы, процедуры, изменения платформы
5. ЧЕМ Серверы, OS, Docker, сеть (физика)
6. ГДЕ $WORKSPACE (git) / $DATASPACE (S3) — пространства
7. СТРУКТУРА Папки и их назначение (architect/, library/, projects/...)
8. КЛАССЫ Служебные / Содержательные / Технические файлы
9. ТИПЫ Теория→Концепция→Стандарт→Инструкция→Практика→Артефакт
10. СОДЕРЖАНИЕ Форматы, шаблоны, правила оформления
ОПЕРАТОР
/ | \
▼ ▼ ▼
АРХИТЕКТОР ПРОЕКТОР ПРОЕКТ
│ │ │
▼ ▼ │
ЗНАНИЯ РАБОТА ◄───┘
│
▼
РЕСУРСЫ
| Вертикаль | Цепочка | Суть |
|---|---|---|
| Знания | Оператор → Архитектор → Библиотека | Создаёт и управляет знаниями |
| Работа | Оператор → Проектор → Кодер/Инфра → Ресурсы | Исполняет через проекты |
| Проект | Оператор → Проект (сам) | Конкретный объект работы |
ИНФРАСТРУКТУРА (чужое железо) НАШИ ПРОДУКТЫ (живут на инфра)
────────────────────────────── ──────────────────────────────
МАТЬ = главный сервер ОТЕЦ = Архитектор
ДОЧКА = дочерний сервер СЫН = Проектор + Кодер
Мать "рожает" дочек Отец "воспитывает" сына
(деплой дочерних серверов) (знания → исполнение)
Правило: МАТЬ и ДОЧКА — инфраструктура. ОТЕЦ и СЫН — наши продукты поверх неё.
Отец — единственный источник платформенных знаний.
ОТЕЦ (Архитектор на Матери)
│ создаёт и хранит
▼
БАНК ЗНАНИЙ
│ отдаёт нужное по запросу
├──────────────┐
▼ ▼
СЫН на Матери СЫН на Дочке (клиент)
│ │
└── нет знания → запрос к Отцу
│
Отец генерирует → в Банк → доступно всем Сыновьям
Следствие для дистрибуции:
- Клиент получает СЫН (движок) on-premise
- Банк знаний остаётся у Отца как сервис
- Защита — через knowledge lock-in, не сокрытие кода
Адрес проекта автоматически определяет режим:
| Путь | Режим | Заказчик | Результат |
|---|---|---|---|
projects/org/* |
PRO-PRO | Оператор / клиент | остаётся в проекте |
projects/sys/* |
PRO-SYS | Архитектор | → library/, system/ |
PRO-SYS строит платформу → пополняет банк знаний.
PRO-PRO использует банк знаний → производит продукт клиента.
Каскад: каждый слой вытекает из предыдущего.
ПРИНЦИПЫ Вечные, Архитектор создаёт раз и навсегда
↓
КОНЦЕПЦИЯ Годами, описывает платформу
↓
ПРАВИЛА Месяцами, как должно быть сделано
↓
ИНСТРУКЦИИ Как сделать X + что ожидать
↓
ПРАКТИКИ Как реально работает X (из опыта)
↓
АРТЕФАКТЫ Готовые вещи — взять и использовать
+ ВНЕШНИЕ Документация языков/фреймворков (интернет)
| Слой | Создаёт | Читают |
|---|---|---|
| Принципы | Архитектор | Все |
| Концепция | Архитектор | Все |
| Правила | Архитектор | Проектор, Кодер, Инфра |
| Инструкции | Кодер + Инфра | Кодер, Инфра |
| Практики | Кодер + Инфра | Кодер, Инфра |
| Артефакты | Кодер | Кодер, Проектор |
Обратный поток: знания растут снизу (из опыта Кодера), авторитет сверху (Архитектор утверждает).
НАМЕРЕНИЕ Оператор хочет результат
Режимы: Проектный / Ручной
↓
ПЛАНИРОВАНИЕ Проектор декомпозирует
Инструмент: project-processor
Читает: Концепция, Правила, Инструкции
↓
ИСПОЛНЕНИЕ Кодер / Инфра делает
При пробеле → запрос вверх: Кодер→Проектор→Архитектор
↓
РЕСУРСЫ $WORKSPACE (код/git) / $DATASPACE (данные/S3) / Серверы
Любой содержательный документ описывается тремя координатами:
1. УРОВЕНЬ Платформа → Проект → Компонент → Подкомпонент
Фрактал: на каждом уровне одна структура
2. СТАДИЯ Концепт → Решение → ТЗ → Реализация → Артефакт
Каждая стадия производит свой тип документа:
Концепт → Концепция, Теория
Решение → ADR, Политика, Стандарт
ТЗ → Спецификация, Инструкция
Реализация → Практика
Артефакт → Артефакт, Шаблон
3. СТАТУС draft → review → approved → active → deprecated → archived
Пример: operation-drupal-docker.md = (Платформа, Реализация, active)
┌─────────────────────────────────────────────────────┐
│ СФСП — Служебные Файлы Системы Платформы │
│ Описывают место/сущность для обрабатывающей системы │
│ README.md INDEX.md CLAUDE.md AI.md .gitignore │
│ .cache .lock .tmp __pycache__/ │
├─────────────────────────────────────────────────────┤
│ СОДЕРЖАТЕЛЬНЫЕ │
│ Несут знание и смысл │
│ Концепция, Стандарт, Инструкция, Практика │
│ STATUS.md, TODO.md, LICENSE, Шаблоны-документы │
├─────────────────────────────────────────────────────┤
│ ТЕХНИЧЕСКИЕ │
│ Являются реализацией — создаются агентами │
│ Код (.py .js .php), Конфигурация (.yml) │
│ Данные (.csv .json), Тесты, Бинарные │
└─────────────────────────────────────────────────────┘
| Класс | Для кого | Без них |
|---|---|---|
| СФСП | Система (git, AI, ФС) | Система не ориентируется |
| Содержательные | Люди / агенты | Нет знаний |
| Технические | Инструменты (docker, python) | Ничего не работает |
Изменение — это каскад сверху вниз:
1. Инициатива → обсуждение с Архитектором
2. Изменение Концепции (concept/) если нужно
3. Изменение Стандарта (standards/)
4. Изменение Инструкций/Практик
5. Изменение Технических файлов (код, конфиг)
6. Обновление СФСП (CLAUDE.md, INDEX.md)
7. Коммит + документирование в CHANGELOG
Правила:
- Новый файл — только обоснованно, нет дублей
- Стандарты создаёт только Архитектор
- Технические файлы создаёт Кодер/Инфра по заданию PRO-SYS
- Изменение снизу без концепции — запрещено
| Документ | Уровень | Что описывает |
|---|---|---|
| PLATFORM.md | Концепция | Что такое платформа, 5 подсистем |
| family-architecture.md | Концепция | Семья серверов |
| platform-layers.md | Концепция | Слои знаний и исполнения |
| ../standards/format/format-file-types.md | Стандарт | Правила хранения файлов |
| ../standards/structure/structure-workspace.md | Стандарт | Структура workspace |
Версия: 0.1.0 (черновик)
Дата: 2026-04-09
Статус: draft — требует проверки и дополнения