S2R Template

Тип репозитория: Format

Для AI-агентов: Этот репозиторий — промпт-шаблон для создания проектных хранилищ. Используйте документы из 0.OPS/ как инструкции для развёртывания структуры под конкретный проект пользователя.

SRR (Systems–Roles Repository): a multi-kernel systems×roles (3×3) project repository template aligned with FPF

S2R — имя метода. SRR — его формальная расшифровка: Systems–Roles Repository (Хранилище систем и ролей). Этот репозиторий — шаблон (Template) структуры SRR с поддержкой множества ядер.

S2R Template — шаблон репозитория для SRR: хранилища проекта по матрице Системы × Роли (3×3) с опорой на FPF и поддержкой графа создателей.

Позиционирование в экосистеме

S2R — это Format (протокол оформления), а не Pack или Framework.

Upstream (зависимости)

Репозиторий	Тип	Что берём
FPF	Framework	Мета-онтология, базовые различения
SPF	Framework	Принципы организации знаний

Downstream (кто использует S2R)

Репозиторий	Тип	Как использует
ecosystem-development	Downstream/governance	Инстанс S2R для экосистемы Aisystant

Роль S2R

FPF (Level 1)  →  мета-онтология
       ↓
SPF (Level 2)  →  форма + процесс для Pack
       ↓
S2R (Format)   →  структура downstream-репозиториев  ← ВЫ ЗДЕСЬ
       ↓
ecosystem-development  →  конкретный инстанс S2R

S2R — это	S2R — это НЕ
Протокол структуры репозиториев	Pack (source-of-truth области)
Матрица 3×3 (системы × роли)	Содержание предметной области
Шаблон для governance-репозиториев	Процесс создания знаний

Назначение для AI

Этот репозиторий предназначен для использования AI-агентами (Claude Code, GPT и др.) как инструкция для создания проектных хранилищ:

Изучите документы в 0.OPS/0.1.Knowledge-Logic/ — это модель знаний
Получите от пользователя описание его проекта
Создайте структуру на основе шаблонов, заменяя плейсхолдеры реальными именами систем
Заполните документы согласно правилам именования

Ключевые документы для AI

Документ	Назначение
01-kernels-model.md	Как создавать ядра, правила именования
02-document-families.md	9 семейств документов F1-F9
03-our-systems-map.md	Карта систем проекта
04-ontology.md	Общая онтология и запреты
05-glossary.md	Глоссарий терминов
08-anti-patterns.md	Анти-паттерны (типичные ошибки)
09-examples-library.md	Библиотека примеров для AI
01-value-chain.md	Цепочка создания ценности
roles-matrix.md	Матрица ролей 3×3
fpf-integration.md	Интеграция с FPF

Ключевые концепции

Ядра (Kernels)

Ядро — это полная системная перспектива относительно одной целевой системы (или "нашей системы"). Каждое ядро разворачивает свои 9 семейств документов (F1-F9).

Ядро A — всегда относительно главной целевой системы проекта
Ядра B, C, D... — относительно "наших систем"

Важно: Папки ядер именуются по имени целевой иили нашей системы, а не абстрактно. Например: A.Automobile/, а не A.Target-System/.

"Наши системы" (Our Systems)

"Наши системы" могут быть:

Подсистемами целевой системы — компоненты, входящие в целевую систему
Частями цепочки создания — системы, которые создают целевую систему (включая поддержку, ремонт, модернизацию) и которые образуют граф создателей.

Граф создателей

Системы связаны через цепочку создания ценности. Каждая команда работает со своим ядром, и ядра связаны между собой.

Пример: Автомобильное производство

                           [Такси]
                    (Водитель + Автомобиль)
                    Надсистема целевой системы
                                  ↑
                                  │ входит
                                  │
┌─────────────────────────────────────────────────────────────────────┐
│                       A. Автомобиль/                                │
│                   Целевая система проекта                          │
└─────────────────────────────────────────────────────────────────────┘
            ↑ создаёт                        ↑ входит как часть
            │                                │
┌───────────────────────────┐   ┌───────────────────────────┐
│      C. Конвейер/         │   │      B. Мотор/            │
│  "Наша система" команды-2 │   │  "Наша система" команды-1 │
└───────────────────────────┘   └───────────────────────────┘
            ↑
    ┌───────┴───────┐
    ↓               ↓
┌───────────────┐   ┌───────────────────────┐
│ D. Станок-    │   │    E. Команда-2/      │
│    ЧПУ/       │   │ "Наша система" ком.-4 │
│ "Наша сист."  │   │                       │
│  команды-3    │   │                       │
└───────────────┘   └───────────────────────┘

Ключевые особенности:

Команда	Ядро	"Наша система"	Пояснение
Команда-1	B	Мотор	подсистема целевой системы
Команда-2	C	Конвейер	система создания целевой системы
Команда-3	D	Станок ЧПУ	подсистема системы создания ЦС
Команда-4	E	Команда-2	система создания системы создания ЦС

Важно: Разные команды работают с разными ядрами. Для успешной работы необходимо:

Техническая интеграция — согласование интерфейсов между системами

Согласование онтологий — одинаковые термины могут означать разное в разных ядрах

Коммуникация — регулярная синхронизация между командами

Подробнее: 01-kernels-model.md → раздел "Развёрнутый пример"

Правило именования папок

Хорошо (на примере автомобиля):
A.Автомобиль/                   # Имя целевой системы
├── A1.Такси/                   # Имя надсистемы (Водитель+Автомобиль)
├── A2.Автомобиль/              # Имя SoI
└── A3.Конвейер/                # Имя системы создания

B.Мотор/                        # Ядро для подсистемы
├── B1.Автомобиль/              # Надсистема мотора
├── B2.Мотор/                   # SoI
└── B3.Моторный-цех/            # Система создания мотора

Плохо:
A.Target-System/                # Абстрактно, нет названия системы
├── A1.Suprasystem/             # Это роль, не имя
├── A2.System-of-Interest/      # Это роль, не имя
└── A3.Constructor/             # Это роль, не имя

Матрица 3×3 внутри каждого ядра

Каждое ядро (A, B, C...) содержит 9 семейств документов:

Краткая матрица: ключевые слова

Уровень \ Роль	Предприниматель (X.1)	Инженер (X.2)	Менеджер (X.3)
1.X. Надсистема	Спрос / Оффер	Сценарии / Прототип	Доверие / Репутация
2.X. Целевая система	Смысл / Границы	Архитектура / Интерфейсы	SLO / Incidents
3.X. Система создания	Стратегия / Инвестиции	CI/CD / Quality	Ресурсы / Регламенты

Матрица ролей

Уровень \ Роль	Предприниматель (X.1)	Инженер (X.2)	Менеджер (X.3)
1.X. Надсистема	FX1: Продвиженец	FX2: Владелец продукта	FX3: PR/GR
2.X. Целевая система	FX4: Визионер ЦС	FX5: Инженер ЦС	FX6: Оператор ЦС
3.X. Система создания	FX7: Бизнесмен	FX8: Организатор разработки	FX9: Администратор

Полное описание ролей с методами и метриками: roles-matrix.md

Краткая версия: roles-matrix-brief.md

F0 (0.OPS): Метаэпистема хранилища

F0 — метаэпистема, управляющая знаниями о знаниях в хранилище.

Почему OPS? OPS — коротко, стандартно, прямо означает "операционная логика и порядок работы". Туда естественно ложатся inbox/archive как операционные корзины.

F0 отвечает за:

Общую онтологию для всех ядер
Связи и мосты между ядрами
Стандарты и процессы
Интеграцию с FPF

Каждое ядро может иметь своё FX0 (Kernel Management) с локальной онтологией.

Структура репозитория

s2r/
├── 0.OPS/         # F0: Метаэпистема хранилища
│   ├── 0.1.Knowledge-Logic/         # Онтология, модель ядер
│   │   ├── README.md
│   │   ├── 01-kernels-model.md      # ⭐ Модель ядер
│   │   ├── 02-document-families.md  # ⭐ Семейства F1-F9
│   │   ├── 03-our-systems-map.md    # ⭐ Карта систем
│   │   ├── 04-ontology.md
│   │   ├── 05-glossary.md
│   │   ├── 06-taxonomy.md
│   │   ├── 07-naming.md             # ⭐ Правила именования
│   │   ├── 08-anti-patterns.md      # ⭐ Анти-паттерны (типичные ошибки)
│   │   └── 09-examples-library.md   # ⭐ Библиотека примеров для AI
│   ├── 0.2.Kernels-Bridge/          # Связи между ядрами
│   │   ├── README.md
│   │   ├── 01-value-chain.md        # ⭐ Цепочка ценности
│   │   ├── 02-kernels-relations.md  # Матрица связей
│   │   └── 03-systems-relations.md  # Структура связанности систем
│   ├── 0.3.Roles-Matrix-3x3/        # ⭐ Матрица ролей 3×3
│   │   ├── roles-matrix.md          # Полная версия
│   │   └── roles-matrix-brief.md    # Краткая версия
│   ├── 0.4.FPF-Integration/         # ⭐ Интеграция с FPF
│   │   ├── fpf/                     # Копия FPF-Spec
│   │   ├── fpf-integration.md
│   │   └── fpf-patterns-map.md
│   ├── 0.5.AI-Reports/              # AI-проверки и отчёты
│   │   ├── Validation-Specs/        # ТЗ на проверки
│   │   └── Validation-Results/      # Результаты проверок
│   ├── 0.6.Repository-Processes/    # Стандарты, процессы
│   │   ├── README.md
│   │   ├── 01-project-description-template.md  # ⭐ Шаблон описания проекта
│   │   ├── 02-standards.md          # Стандарты оформления
│   │   ├── 03-structure.md          # Структура репозитория
│   │   ├── 04-document-creation.md  # Создание документов
│   │   ├── 05-frontmatter-spec.md   # Спецификация метаданных
│   │   ├── 06-workflows.md          # Рабочие процессы
│   │   ├── 07-roles.md              # Роли и ответственность
│   │   └── 08-deployment-guide.md   # ⭐ Руководство по развёртыванию
│   ├── 0.7.Plans-and-Meetings/      # Планирование
│   ├── 0.9.Inbox/                   # Входящие идеи
│   └── 0.99.Archive/                # Архив
│
├── A.SOI-Name/                      # Ядро A: ШАБЛОН (переименовать!)
│   ├── A0.SOI-Name-Management/      # FA0: Управление ядром
│   ├── A1.Suprasystem-Name/         # Надсистема (переименовать!)
│   │   ├── A1.1.Meaning/            # FA1
│   │   ├── A1.2.Architecture/       # FA2
│   │   └── A1.3.Operations/         # FA3
│   ├── A2.SOI-Name/                 # Целевая система (переименовать!)
│   │   ├── A2.1.Meaning/            # FA4
│   │   ├── A2.2.Architecture/       # FA5
│   │   └── A2.3.Operations/         # FA6
│   └── A3.Constructor-Name/         # Система создания (переименовать!)
│       ├── A3.1.Meaning/            # FA7
│       ├── A3.2.Architecture/       # FA8
│       └── A3.3.Operations/         # FA9
│
├── B.Our-System-Name/               # Ядро B: ШАБЛОН (переименовать!)
│   └── ... (аналогичная структура)
│
├── CLAUDE.md                        # ⭐ Инструкции для AI
├── README.md                        # Этот файл
└── CONTRIBUTING.md                  # Правила участия

Быстрый старт (для людей)

⭐ Полное руководство по развёртыванию: 08-deployment-guide.md

Шаг 0: Подключите Claude Code

Для эффективной работы с хранилищем рекомендуется использовать Claude Code:

# Клонируйте репозиторий
git clone https://github.com/TserenTserenov/s2r.git my-project
cd my-project
rm -rf .git && git init

# Запустите Claude Code
claude

Claude Code автоматически прочитает CLAUDE.md и поможет с развёртыванием.

Шаг 1: Опишите проект

Заполните 01-project-description-template.md — это поможет определить системы.

Шаг 2: Переименуйте папки ядер

Важно: X1 (надсистема) — это физическая система, не контекст или процесс!

# Пример для автомобиля
mv A.SOI-Name A.Automobile
mv A.Automobile/A1.Suprasystem-Name A.Automobile/A1.Taxi
mv A.Automobile/A2.SOI-Name A.Automobile/A2.Automobile
mv A.Automobile/A3.Constructor-Name A.Automobile/A3.Assembly-Line

Шаг 3: Обновите связи

Заполните 0.1.Knowledge-Logic/03-our-systems-map.md
Заполните 0.2.Kernels-Bridge/01-value-chain.md

Что оставить без изменений

Папка/Файл	Действие
`0.3.Roles-Matrix-3x3/`	✅ Оставить (методология)
`0.4.FPF-Integration/`	✅ Оставить (методология)
`CLAUDE.md`	✅ Оставить (инструкции для AI)
`0.1.Knowledge-Logic/01-09`	✅ Оставить (методология)

Что заполнить

Файл	Действие
`0.1/03-our-systems-map.md`	📝 Заполнить картой систем
`0.2/01-value-chain.md`	📝 Заполнить цепочкой ценности
`0.6/01-project-description-template.md`	📝 Заполнить описанием проекта

Что переименовать

Папка	Действие
`A.SOI-Name/`	✏️ Переименовать в `A.{Ваша-Система}/`
`B.Our-System-Name/`	✏️ Переименовать или удалить
Подпапки `A1`, `A2`, `A3`	✏️ Переименовать с именами систем

Быстрый старт (для AI)

При развёртывании репозитория для пользователя:

Запросите описание проекта — что создаёт пользователь?
Определите целевую систему — что является "A"?
Определите "наши системы" — что является "B", "C"?
Постройте цепочку ценности — кто кого создаёт?
Переименуйте папки — используя имена систем
Заполните шаблоны — README, карта систем, value-chain

Смотрите инструкции в CLAUDE.md.

Для кого этот шаблон

Проектные команды — организация знаний о сложных системах
Стартапы — структурирование знаний о продукте
Корпорации — управление знаниями с множеством подсистем и команд
Разработчики — документация архитектуры и процессов
AI-агенты — промпт для создания проектных хранилищ

Чем S2R НЕ является

Это не процесс разработки и не "жизненный цикл проекта"
Это схема организации знаний + операционная дисциплина
Это не замена архитектурным фреймворкам, а способ организовать их результаты

S2R в архитектуре знаний

S2R — это методология организации репозиториев (измерение "Форма"), а не уровень знаний.

Три ортогональных измерения

Измерение	Что определяет	Кто определяет
Содержание	Терминология, понятия	FPF → SPF
Форма	Структура репозитория	S2R
Процесс	Как производить знания	SPF

S2R определяет

Структуру ядер (A/B/C/D...)
Матрицу 3×3 (система × роль)
Семейства документов (F1-F9)
Правила именования и навигации

S2R НЕ определяет

Что является знанием (это FPF/SPF)
Как производить знания (это SPF)
Какие термины использовать (это FPF)

S2R и Pack: различение формы и содержания

S2R организует проектные документы. Pack хранит доменное знание (source-of-truth).

Документ в ячейке S2R (например, FA5 — архитектура целевой системы) — это проектный артефакт, который:

описывает конкретную систему этого проекта
ссылается на один или несколько Pack'ов как источники доменного знания
использует универсальные компетенции (инженерия, менеджмент) из образования

S2R-документ — downstream по отношению к Pack. Pack — source-of-truth.

Один объект — много предметных областей. Один и тот же объект (автомобиль, ИТ-система, человек) может появляться в разных ячейках S2R и в разных Pack'ах под разными именами — потому что в разных bounded context'ах он описан с разным словарём и разными различениями. Это не дублирование, а разные модели одной реальности.

Пример	В одном Pack	В другом Pack	Почему разные
Автомобиль	«Транспортное средство» (логистика)	«Предмет роскоши» (luxury)	Разные характеристики важны
Человек	«Созидатель» (личное развитие)	«Пользователь» (ИТ-платформа)	Разные объекты внимания
ИТ-система	«Платформа» (архитектура)	«Среда мастерской» (методика)	Разные bounded context'ы

Место S2R в иерархии

FPF (Level 1)  →  мета-онтология, различения
 ├──▶ SPF (Level 2)  →  форма + процесс → Pack (source-of-truth знания)
 │                                            │
 └──▶ S2R (Format)   →  структура проектных   │
       документов                              │
       │                                       │
       └── S2R-документы ССЫЛАЮТСЯ на ─────────┘

SPF и S2R — параллельные downstream от FPF, работающие в разных измерениях. SPF про знание (содержание), S2R про организацию документов (форма). Они встречаются, когда проектный документ (S2R) ссылается на доменное знание (Pack).

Терминология

Термин	Описание
S2R	Имя метода (бренд)
SRR	Systems–Roles Repository (формальная расшифровка)
Kernel (Ядро)	Системная перспектива с 9 семействами
Our System	Наша система — за которую мы отвечаем
F0-F9	Семейства документов
FPF	First Principles Framework — эпистемологический фундамент

Ссылки

Введение в системное мышление: docs.system-school.ru
FPF: github.com/ailev/FPF
CLAUDE.md — инструкции для работы с Claude Code
CONTRIBUTING.md — правила участия

Лицензия

MIT License — используйте свободно для своих проектов.

Name		Name	Last commit message	Last commit date
.obsidian		.obsidian
0.OPS		0.OPS
A.SOI-Name		A.SOI-Name
B.Our-System-Name		B.Our-System-Name
.gitignore		.gitignore
CLAUDE.md		CLAUDE.md
CONTRIBUTING.md		CONTRIBUTING.md
README.md		README.md
REPO-TYPE.md		REPO-TYPE.md

Latest commit

History

Folders and files

Repository files navigation