architect/concept/platform-layers.md

type: concept
title: "Слои платформы — знания и исполнение"
status: approved
version: 1.0.0
date: 2026-04-09
owner: architect


Слои платформы — знания и исполнение

Платформа состоит из двух иерархий: знания и исполнение.
Они независимы по структуре, но связаны: исполнение опирается на знания.


Иерархия знаний

Знания каскадны — каждый слой вытекает из предыдущего.
Чем выше слой — тем стабильнее, тем меньше людей его меняет,
тем больше людей на него опирается.

ПРИНЦИПЫ
    ↓ вытекает
КОНЦЕПЦИЯ
    ↓ вытекает
ПРАВИЛА
    ↓ вытекает
РЕЦЕПТЫ
    ↓ вытекает
АРТЕФАКТЫ

+ ВНЕШНИЕ (не наши)

Слой 1 — Принципы

Что Фундамент — почему платформа существует, базовые ценности
Меняется Никогда
Создаёт Архитектор (один раз)
Читают Все — чтобы принимать решения в духе платформы

Слой 2 — Концепция

Что Что такое платформа, как устроена семья, роли, видение
Меняется Редко (только большие решения)
Создаёт Архитектор
Читают Все — чтобы понимать контекст и своё место

Слой 3 — Правила

Что Как должно быть сделано: именование, форматы, протоколы, запреты
Меняется При эволюции платформы
Создаёт Архитектор
Читают Проектор, Кодер, Инфра — чтобы делать правильно

Слой 4 — Рецепты

Что Как сделать конкретную вещь: задеплоить Drupal, подключить API, настроить nginx
Меняется Часто, растёт с опытом
Создаёт Кодер + Инфра (из опыта), Архитектор (фиксирует как стандарт)
Читают Кодер, Инфра — чтобы не изобретать велосипед

Слой 5 — Артефакты

Что Готовые вещи которые можно взять и использовать: шаблоны, сборки, модули, коннекторы
Меняется Постоянно растёт
Создаёт Кодер (результат работы)
Читают Кодер, Проектор — чтобы переиспользовать

Внешние знания

Что Документация языков, фреймворков, внешних API
Создаёт Внешний мир
Читают Кодер, Инфра — по запросу через WebSearch

Иерархия исполнения

Исполнение каскадно — каждый слой получает задачу сверху
и опирается на знания соответствующего уровня.

Слой 1 — Намерение

Кто Оператор (человек)
Что Хочет результат: продукт, компонент, изменение
Выход Цель сформулирована
Режимы Проектный (→ Проектор) / Ручной (→ Кодер/Инфра напрямую)

Слой 2 — Планирование

Кто Проектор: PRO-SYS или PRO-PRO
Что Декомпозирует цель на задачи, строит роадмап, фазы, контекст-блоки
Читает Концепция, Правила, Рецепты
Инструмент project-processor (рекурсивный алгоритм)
Выход Очередь конкретных задач

Два режима Проектора — определяется адресом проекта:

Путь Режим Заказчик Результат
projects/org/* PRO-PRO Оператор / клиент остаётся в проекте
projects/sys/* PRO-SYS Архитектор library/, system/

Слой 3 — Исполнение

Кто Кодер / Инфра
Что Берёт задачу из очереди, читает Правила + Рецепты + Артефакты
При пробеле Запрос вверх: Кодер → Проектор → Архитектор
Кодер Пишет код, модули, тесты, API
Инфра Деплоит, настраивает Docker, сети, cron
Выход Готовый артефакт / задеплоенный сервис

Слой 4 — Ресурсы

Что Физическое пространство — не агент
$WORKSPACE Код и документы (git)
$DATASPACE Данные и файлы (S3)
Серверы Вычисления и сеть
Кодер использует $WORKSPACE, БД
Инфра управляет Серверами, сетью, $DATASPACE

Связь иерархий

Слои знаний питают слои исполнения:

Слой знаний Кто читает в исполнении
Принципы Архитектор — при принятии решений
Концепция Проектор — при планировании
Правила Кодер + Инфра — при исполнении
Рецепты Кодер + Инфра — готовые решения
Артефакты Кодер — берёт и переиспользует
Внешние Кодер + Инфра — по запросу

Обратный поток — знания растут снизу вверх

Кодер нашёл решение
  → фиксирует как Рецепт
    → Архитектор поднимает до Правила (если универсально)
      → Банк знаний пополнен для всех дочек

Знания создаются снизу (из опыта), но авторитет сверху (Архитектор утверждает).


Поток знаний в семье серверов

ОТЕЦ (Архитектор на Матери)
  │ создаёт и хранит все слои знаний
  ▼
БАНК ЗНАНИЙ
  │ отдаёт нужное по запросу
  ├──────────────────────┐
  ▼                      ▼
СЫН на Матери         СЫН на Дочке
  │                      │
  └── нет знания? ──► запрос к Отцу
                         │
                    Отец генерирует
                    → в Банк
                    → доступно всем Сыновьям

Следствие для дистрибуции:
- Клиент получает СЫН (движок исполнения) — on-premise
- Банк знаний остаётся у Отца — как сервис
- Без Отца Сын работает, но не умнеет и не получает новые стандарты


Связанные документы:
- family-architecture.md — семья серверов
- AGENTS.md — архитектура агентов
- ROLES.md — роли в платформе
- ../standards/structure/structure-workspace.md — структура workspace