sync

2026-08-22 07:30:16 +03:00 · 2026-08-10 09:12:22 +03:00
parent b5db9e5158
commit 691069af8e
55 changed files with 1519 additions and 3383 deletions
--- a/DRAFT/architecture/README.md
+++ b/DRAFT/architecture/README.md
@@ -0,0 +1,42 @@
+# Архитектура SLM
+
+> Статус: рабочий черновик. Документы в этой папке не являются спецификацией.
+
+SLM задаёт структурную основу приложения: слои, модули, публичные границы, зависимости, фасеты сред выполнения и владение жизненным циклом.
+
+## Область SLM
+
+Черновик описывает слои, модули, группы, сегменты, компоненты, публичный API, зависимости и владение жизненным циклом ресурсов.
+
+SLM не задаёт обязательную внутреннюю форму модуля, обязательный поток данных, правила монорепозиториев или полный файловый стайлгайд. Форма модуля следует его ответственности и реальным потребителям.
+
+## Виды утверждений
+
+- **Определение** нормативно задаёт смысл архитектурного термина, но не получает код правила.
+- **Правило** задаёт блокирующий архитектурный инвариант и объявляется в каноническом реестре.
+- **Рекомендация** помогает принять решение, но не делает архитектуру невалидной.
+- **Пример** иллюстрирует модель и не задаёт обязательную структуру.
+
+Нормативные определения находятся в [терминологии](./terminology.md). Канонический набор требований находится в [реестре правил SLM](../rules/registry.md). Формат и требования к правилам описаны отдельно в разделе [Правила SLM](../rules/).
+
+Остальные документы объясняют и иллюстрируют модель, но не владеют точными формулировками определений и правил.
+
+## Основная идея
+
+Модуль является основной архитектурной единицей SLM. Слой задаёт его роль и направление зависимостей: модули слоя `domains` владеют предметными ответственностями на тех же основаниях, что и остальные модули. Группа помогает навигации, сегмент организует внутреннее содержимое, а компонент всегда принадлежит модулю.
+
+SLM требует отдельную папку и единый логический публичный API модуля. По умолчанию API представлен корневым `index`; при необходимости модуль добавляет environment-фасеты `client`, `browser` и `server`. Внутренняя файловая форма модулей, сегментов и компонентов определяется стайлгайдом проекта.
+
+## Карта черновика
+
+- [Терминология](./terminology.md)
+- [Слои](./layers.md)
+- [Модули слоя domains](./domains.md)
+- [Зависимости](./dependencies.md)
+- [Модули](./modules.md)
+- [Группы](./groups.md)
+- [Сегменты](./segments.md)
+- [Компоненты](./components.md)
+- [Вложенные модули](./nested-modules.md)
+- [Жизненный цикл](./lifecycle.md)
+- [Проверка](./validation.md)
--- a/DRAFT/architecture/components.md
+++ b/DRAFT/architecture/components.md
@@ -0,0 +1,65 @@
+# Компоненты SLM
+
+> Пояснение нормативной модели компонентов SLM.
+
+Компонент является строительным элементом интерфейса, а не самостоятельной архитектурной единицей.
+
+## Связанные правила
+
+- [`SLM-COMPONENT-R009`](../rules/registry.md#slm-component-r009)
+- [`SLM-LAYER-A002`](../rules/registry.md#slm-layer-a002)
+- [`SLM-MODULE-A004`](../rules/registry.md#slm-module-a004)
+- [`SLM-DEPENDENCY-A005`](../rules/registry.md#slm-dependency-a005)
+- [`SLM-MODULE-R011`](../rules/registry.md#slm-module-r011)
+- [`SLM-LIFECYCLE-R013`](../rules/registry.md#slm-lifecycle-r013)
+
+## Файловая форма
+
+Файловую форму компонента определяет стайлгайд. Компонент может быть одним файлом фреймворка или каталогом со вспомогательными файлами.
+
+```text
+landing/
+└── ui/
+    └── hero.tsx
+```
+
+```text
+landing/
+└── ui/
+    └── hero/
+        ├── hero.tsx
+        ├── styles/
+        │   └── hero.module.css
+        └── types/
+            └── hero-props.type.ts
+```
+
+Наличие каталога, типов, стилей или локального `index.ts` не превращает компонент в модуль.
+
+## Реализация
+
+Компонент может отображать входные данные, вызывать переданные обработчики, условно строить интерфейс и хранить локальное состояние представления.
+
+SLM не вводит отдельного запрета на импорты, выполняемые кодом компонента. Каждый такой импорт считается зависимостью родительского модуля и должен соблюдать направление слоёв, публичные фасеты и запрет циклов.
+
+Доступ к данным, состояние, контекст или код жизненного цикла внутри компонента сами по себе не создают новую архитектурную границу. Их источники, зависимости и область жизни определяет родительский модуль.
+
+Провайдер может технически реализовывать контекст и жизненный цикл фреймворка, но владельцем состояния и ресурсов остаётся родительский модуль.
+
+Файл в `app` может технически быть компонентом React или Vue. Архитектурно он является точкой входа фреймворка, а не компонентом SLM.
+
+## Компонент и модуль
+
+| Признак | Компонент | Модуль |
+|---|---|---|
+| Самостоятельная ответственность | Нет | Да |
+| Собственный публичный API | Нет | Да |
+| Собственная граница зависимостей | Нет | Да |
+| Вспомогательные файлы | Может иметь | Может иметь |
+| Сегменты и вложенные модули | Нет | Может иметь |
+
+Модуль может состоять всего из одного корневого компонента. Различие определяется владением, а не количеством файлов.
+
+## Когда нужен вложенный модуль
+
+Если часть интерфейса получает самостоятельную ответственность, публичный API, собственную границу зависимостей, область жизни или внутреннюю модульную декомпозицию, она является модулем. При локальном использовании такой модуль может размещаться как вложенный.
--- a/DRAFT/architecture/dependencies.md
+++ b/DRAFT/architecture/dependencies.md
@@ -0,0 +1,87 @@
+# Зависимости SLM
+
+> Пояснение нормативной модели зависимостей SLM.
+
+Матрица слоёв задаёт допустимые зависимости между модулями.
+
+## Что считается зависимостью
+
+- Обычный импорт, импорт типа и реэкспорт одинаково создают архитектурную зависимость.
+- Импорт между файлами одного модуля не пересекает модульную границу.
+- Импорт любого внутреннего файла, сегмента или компонента считается зависимостью ближайшего модуля-владельца.
+- Вложенный модуль имеет собственную границу зависимостей.
+- Группы, сегменты и компоненты не имеют самостоятельных границ зависимостей.
+
+Точка входа фреймворка не является модулем. Её импорты участвуют в проверке направления слоёв.
+
+Ресурс `shared` также не является модулем. Его прямой импорт участвует в проверке направления слоёв, но не нарушает требование о публичном API модуля.
+
+## Допустимые связи
+
+- Модуль может импортировать модули своего слоя и слоёв, разрешённых нормативной матрицей.
+- Модули одного слоя могут импортировать друг друга.
+- Промежуточный слой не является обязательным посредником.
+- `infra` может импортировать `ui` для визуального представления технической возможности; `ui` не импортирует `infra`.
+
+Модуль слоя `domains` может импортировать публичный API другого разрешённого модуля. Runtime- и type-only импорты одинаково создают архитектурную зависимость, а циклические зависимости запрещены.
+
+```ts
+// domains/orders
+import type { Product } from '@/domains/catalog'
+```
+
+SLM не требует отдельного механизма инъекции между модулями слоя `domains`.
+
+Матрица слоёв определена в [Слоях](./layers.md).
+
+## Связанные правила
+
+- [`SLM-LAYER-A002`](../rules/registry.md#slm-layer-a002)
+- [`SLM-MODULE-A004`](../rules/registry.md#slm-module-a004)
+- [`SLM-DEPENDENCY-A005`](../rules/registry.md#slm-dependency-a005)
+- [`SLM-NESTED_MODULE-A010`](../rules/registry.md#slm-nested_module-a010)
+- [`SLM-ENVIRONMENT-R016`](../rules/registry.md#slm-environment-r016)
+- [`SLM-ENVIRONMENT-R017`](../rules/registry.md#slm-environment-r017)
+- [`SLM-ENVIRONMENT-R018`](../rules/registry.md#slm-environment-r018)
+- [`SLM-ENVIRONMENT-R019`](../rules/registry.md#slm-environment-r019)
+
+## Публичный API
+
+```ts
+// Допустимо
+import { Button } from '@/ui/button'
+
+// Недопустимо
+import { Button } from '@/ui/button/button'
+```
+
+Если модуль объявляет специализированный фасет, его путь также является публичным:
+
+```ts
+import type { Session } from '@/domains/auth'
+import { AuthProvider } from '@/domains/auth/client'
+import { getServerSession } from '@/domains/auth/server'
+```
+
+## Фасеты сред выполнения
+
+Ограничения фасета распространяются на все его runtime-импорты и реэкспорты, включая транзитивные. Type-only import остаётся архитектурной зависимостью, но не добавляет исполняемый код в среду фасета.
+
+`index` не импортирует и не реэкспортирует `client`, `browser` или `server`. `client` может использовать универсальную внутреннюю реализацию модуля, но не импортирует `browser` или `server`. `browser` и `server` могут использовать универсальную внутреннюю реализацию, но не импортируют друг друга.
+
+```ts
+// Browser-only фасет подключается только за границей без SSR.
+const BrowserEditor = dynamic(
+  () => import('@/domains/editor/browser').then(({ BrowserEditor }) => BrowserEditor),
+  { ssr: false },
+)
+```
+
+Обычный статический импорт `@/domains/editor/browser` запрещён даже внутри Client Component. Tree shaking, проверка `typeof window` и обещание не вызывать экспорт при SSR не заменяют динамическую границу с отключённым SSR.
+
+## Циклы
+
+```text
+ui/modal → ui/button → ui/icon
+ui/icon -/→ ui/modal
+```
--- a/DRAFT/architecture/domains.md
+++ b/DRAFT/architecture/domains.md
@@ -0,0 +1,59 @@
+# Модули слоя domains
+
+> Пояснение размещения предметных ответственностей в обычных SLM-модулях.
+
+## Связанные правила
+
+- [`SLM-MODULE-A004`](../rules/registry.md#slm-module-a004)
+- [`SLM-MODULE-R006`](../rules/registry.md#slm-module-r006)
+- [`SLM-GROUP-R007`](../rules/registry.md#slm-group-r007)
+- [`SLM-LAYER-R001`](../rules/registry.md#slm-layer-r001)
+
+## Обычные модули SLM
+
+Модуль слоя `domains` является обычным SLM-модулем. Он отличается от модулей других слоёв только предметной ответственностью, а не отдельной архитектурной сущностью или обязательной файловой формой.
+
+```text
+domains/auth/
+├── hooks/
+├── services/
+├── stores/
+├── types/
+├── ui/
+└── index.ts
+```
+
+Показанные каталоги являются возможными сегментами, а не обязательным каркасом. Модуль может содержать предметные типы, сценарии, состояние, framework-код, компоненты и вложенные модули.
+
+## Публичный API
+
+Внешний код использует модуль через его обычный публичный API:
+
+```ts
+import { signOut, useSession } from '@/domains/auth'
+```
+
+Глубокий импорт во внутренний сегмент нарушает модульную границу:
+
+```ts
+import { useSession } from '@/domains/auth/hooks/use-session'
+```
+
+## Groups
+
+При большом количестве модулей слой `domains` может содержать обычные навигационные Groups:
+
+```text
+domains/
+├── shop/                 # Group
+│   ├── catalog/          # SLM-модуль
+│   └── orders/           # SLM-модуль
+└── cabinet/              # Group
+    └── profile/          # SLM-модуль
+```
+
+Group не имеет `index.ts`, реализации, состояния или публичного API. Она не создаёт dependency boundary и не реэкспортирует содержащиеся в ней модули.
+
+## Среды выполнения
+
+Если части публичного API модуля предназначены для разных сред выполнения, модуль сохраняет одну ответственность и разделяет доступ фасетами `client`, `browser` и `server`.
--- a/DRAFT/architecture/groups.md
+++ b/DRAFT/architecture/groups.md
@@ -0,0 +1,25 @@
+# Группы SLM
+
+> Пояснение нормативной модели групп SLM.
+
+Группа помогает ориентироваться в большом количестве модулей. Она классифицирует структуру, но ничего не реализует и не образует самостоятельную границу зависимостей.
+
+## Связанное правило
+
+- [`SLM-GROUP-R007`](../rules/registry.md#slm-group-r007)
+- [`SLM-MODULE-R011`](../rules/registry.md#slm-module-r011)
+
+## Пример
+
+```text
+compositions/
+├── pages/              # Группа
+│   ├── landing/        # Модуль
+│   └── contacts/       # Модуль
+└── layouts/            # Группа
+    └── main/           # Модуль
+```
+
+`pages` и `layouts` являются возможной группировкой проекта, а не обязательной структурой SLM.
+
+Рекомендуется создавать группу только при реальной навигационной потребности. Если папка начинает владеть файлами реализации, состоянием, жизненным циклом или публичным API, она является модулем и должна получить модульную границу.
--- a/DRAFT/architecture/layers.md
+++ b/DRAFT/architecture/layers.md
@@ -0,0 +1,99 @@
+# Слои SLM
+
+> Пояснение нормативной модели слоёв SLM.
+
+## Базовая структура
+
+```text
+src/
+├── app/
+├── compositions/
+├── domains/
+├── infra/
+├── ui/
+└── shared/
+```
+
+`src/` здесь является примером SLM root. Фактическую границу определяет устройство приложения.
+
+Отсутствующая в проекте роль не требует пустой папки. Слой является доступной архитектурной ролью, а не обязательным элементом каркаса.
+
+## Роли слоёв
+
+### App
+
+`app` связывает приложение с фреймворком: запускает его, объявляет маршруты, преобразует входные данные и подключает публичные API модулей разрешённых слоёв или ресурсы `shared`. Файлы `app` являются точками входа фреймворка, а не модулями SLM.
+
+Точка входа может напрямую использовать `compositions`, `domains`, `infra`, `ui` или `shared`, если зависимость разрешена матрицей слоёв. Такое использование не переносит ответственность импортируемого модуля в `app`.
+
+### Compositions
+
+`compositions` содержит продуктовый интерфейс: страницы, макеты, экраны, виджеты, точки входа и другие композиционные модули. Внутреннюю группировку слоя определяет проект.
+
+### Domains
+
+`domains` содержит обычные SLM-модули, владеющие предметными ответственностями приложения: моделями, правилами, сценариями и продуктовым состоянием.
+
+Предметная логика не принадлежит устройству одной страницы или маршрута. Конкретный visual outcome и сборка нескольких предметных ответственностей остаются в `compositions`.
+
+### Infra
+
+`infra` содержит технические сервисы приложения: аналитику, локализацию, тему, телеметрию и другие возможности среды выполнения без самостоятельной предметной модели.
+
+### UI
+
+`ui` содержит универсальные модули интерфейса, которые не зависят от конкретной страницы или продуктовой композиции.
+
+### Shared
+
+`shared` содержит независимый детерминированный фундамент без знания о продукте, изменяемого состояния и ввода-вывода.
+
+В `shared` допускаются обычные модули и специальные немодульные ресурсы: небольшие чистые утилиты, общие типы, стили, конфигурация и статические файлы. Ресурс не имеет самостоятельной ответственности, публичного API или жизненного цикла и может импортироваться напрямую по пути, установленному стайлгайдом.
+
+Если ресурсу нужны самостоятельная ответственность, собственные архитектурные зависимости, несколько файлов реализации, изменяемое состояние, ввод-вывод или область жизни, он оформляется как модуль. Каталог ресурсов не реэкспортирует модули и не используется для обхода их публичных API.
+
+## Матрица зависимостей
+
+```text
+app
+ |
+compositions
+ |
+domains
+ |
+infra
+ |
+ui
+ |
+shared
+```
+
+Код слоя может импортировать модули своего слоя и слоёв, разрешённых строкой матрицы. Разрешённая зависимость может пропускать промежуточные роли.
+
+| Слой | Может импортировать |
+|---|---|
+| `app` | `app`, `compositions`, `domains`, `infra`, `ui`, `shared` |
+| `compositions` | `compositions`, `domains`, `infra`, `ui`, `shared` |
+| `domains` | `domains`, `infra`, `ui`, `shared` |
+| `infra` | `infra`, `ui`, `shared` |
+| `ui` | `ui`, `shared` |
+| `shared` | `shared` |
+
+`infra` может импортировать `ui`, когда технической возможности требуется визуальное представление, например CAPTCHA, платёжный виджет, карта, uploader, уведомление или инструмент разработчика. Такое представление остаётся частью технической ответственности и не переносит в `infra` страницы, продуктовые тексты или композицию нескольких модулей.
+
+`ui` не импортирует `infra`. Универсальный UI получает локализованный текст, тему, callbacks аналитики и другие технические возможности через входной контракт. Если UI-модулю необходимо напрямую знать конкретный технический сервис приложения, интеграция размещается в `infra`, `domains` или `compositions`, а универсальная часть остаётся в `ui`.
+
+Импорты внутри слоя, публичный API и циклы описаны отдельно в [Зависимостях](./dependencies.md).
+
+## Связанные правила
+
+- [`SLM-LAYER-R001`](../rules/registry.md#slm-layer-r001)
+- [`SLM-LAYER-A002`](../rules/registry.md#slm-layer-a002)
+- [`SLM-LAYER-R003`](../rules/registry.md#slm-layer-r003)
+- [`SLM-MODULE-R011`](../rules/registry.md#slm-module-r011)
+
+## Граница слоя
+
+Разрешённый импорт не переносит владение. Например, модуль слоя `domains` может использовать `infra` и `ui`, но технический сервис и универсальный интерфейс сохраняют собственных владельцев.
+
+Если код определяет продуктовую модель, правило или сценарий, он принадлежит `domains`, а не `shared` или `infra`. Внутренняя форма домена определяется его ответственностью и реальными потребителями.
--- a/DRAFT/architecture/lifecycle.md
+++ b/DRAFT/architecture/lifecycle.md
@@ -0,0 +1,31 @@
+# Жизненный цикл
+
+> Пояснение нормативной модели владения ресурсами SLM.
+
+Жизненный цикл является частью ответственности модуля. Файл, компонент, провайдер или точка входа фреймворка могут технически создавать и останавливать ресурс, но архитектурным владельцем остаётся модуль.
+
+## Связанные правила
+
+- [`SLM-MODULE-R011`](../rules/registry.md#slm-module-r011)
+- [`SLM-LIFECYCLE-R013`](../rules/registry.md#slm-lifecycle-r013)
+
+## Граница ресурса
+
+Для ресурса определяются:
+
+- модуль-владелец;
+- место создания;
+- момент начала работы;
+- область жизни;
+- допустимое число экземпляров;
+- способ остановки и очистки.
+
+Ресурс начинает работу не раньше начала своей области жизни и не остаётся активным после её завершения. Подписки, слушатели, таймеры, наблюдатели, запросы и соединения рассматриваются одинаково, если требуют явного завершения или отмены.
+
+## Реализация
+
+Очистку может выполнять сам модуль, компонент, провайдер или фреймворк. Способ реализации не меняет владельца и не переносит ответственность в технический файл.
+
+Одиночный экземпляр на всё приложение допустим только тогда, когда модуль действительно владеет областью жизни приложения или процесса. Размещение экземпляра на уровне файла само по себе этого не доказывает.
+
+Точка входа `app` может запускать или подключать ресурс через публичный API импортируемого модуля, но не становится его владельцем.
--- a/DRAFT/architecture/modules.md
+++ b/DRAFT/architecture/modules.md
@@ -0,0 +1,66 @@
+# Модули SLM
+
+> Пояснение нормативной модели модулей SLM.
+
+Модуль является основной архитектурной единицей SLM. Он размещается в отдельной папке, но может состоять только из публичной точки входа и одного файла реализации.
+
+## Связанные правила
+
+- [`SLM-MODULE-A004`](../rules/registry.md#slm-module-a004)
+- [`SLM-MODULE-A014`](../rules/registry.md#slm-module-a014)
+- [`SLM-MODULE-R006`](../rules/registry.md#slm-module-r006)
+- [`SLM-MODULE-R011`](../rules/registry.md#slm-module-r011)
+- [`SLM-MODULE-R012`](../rules/registry.md#slm-module-r012)
+- [`SLM-ENVIRONMENT-R016`](../rules/registry.md#slm-environment-r016)
+- [`SLM-ENVIRONMENT-R017`](../rules/registry.md#slm-environment-r017)
+- [`SLM-ENVIRONMENT-R018`](../rules/registry.md#slm-environment-r018)
+- [`SLM-ENVIRONMENT-R019`](../rules/registry.md#slm-environment-r019)
+
+## Владение
+
+Каждая самостоятельная ответственность имеет одного модуля-владельца. Модуль определяет её публичный API, зависимости, состояние, область жизни и внутреннее устройство независимо от того, в каком файле выполняется конкретный код.
+
+Точки входа `app` и нормативные ресурсы `shared` являются единственными немодульными исключениями. Остальной код внутри SLM root либо принадлежит существующему модулю, либо образует новый модуль.
+
+## Публичный API
+
+Модуль предоставляет один логический публичный API. По умолчанию он представлен корневым `index`, который служит основным barrel. Если реальные потребители требуют разделить несовместимые среды выполнения, модуль добавляет один или несколько фасетов `client`, `browser` и `server`.
+
+Объявленные фасеты вместе образуют один публичный API и не считаются deep imports. Внешний код использует модуль только через них. Сам API открывает только контракт, необходимый реальным внешним потребителям; внутренние механизмы, изменяемое состояние и детали жизненного цикла остаются закрытыми.
+
+```text
+auth/
+├── index.ts       # Универсальный фасет
+├── client.ts      # Необязательная клиентская framework-граница
+├── browser.ts     # Необязательная browser-only граница
+├── server.ts      # Необязательная server-only граница
+└── ...            # Внутренняя реализация
+```
+
+`index` экспортирует публичные типы и runtime-код, который одинаково допустимо выполнять при серверном рендеринге, включая RSC, и в клиентском runtime. Он не реэкспортирует специализированные фасеты.
+
+`client` экспортирует Client Components, hooks, Providers и другой код, который не может выполняться как RSC. Такой код может быть отмечен директивой вроде `use client`.
+
+`browser` экспортирует browser-only возможности и lazy-функциональность. Потребитель подключает этот фасет только динамически через поддерживаемую фреймворком границу с отключённым SSR.
+
+`server` экспортирует только server-only возможности. `index`, `client` и `browser` не импортируют и не реэкспортируют его код.
+
+Фасет не создаётся для симметрии или будущей потребности. Один публичный runtime-export размещается в минимально подходящем фасете и не дублируется между фасетами.
+
+## Внутреннее устройство
+
+Модуль может содержать корневые файлы, сегменты, компоненты и [вложенные модули](./nested-modules.md). Внутри своей границы он может использовать относительные импорты и не обязан обращаться к собственному публичному API; точную форму внутренних импортов определяет стайлгайд.
+
+SLM не требует полного каркаса или обязательного каталога сегментов. Файлы фасетов являются публичными точками входа, а не сегментами или самостоятельными модулями.
+
+## Визуальный модуль
+
+Визуальный модуль обычно имеет корневой компонент, который экспортируется через публичный API.
+
+```text
+button/
+├── button.tsx
+└── index.ts
+```
+
+Корневой компонент остаётся компонентом, а владельцем ответственности является модуль `button`.
--- a/DRAFT/architecture/nested-modules.md
+++ b/DRAFT/architecture/nested-modules.md
@@ -0,0 +1,30 @@
+# Вложенные модули
+
+> Пояснение нормативной модели вложенных модулей SLM.
+
+Вложенный модуль является обычным модулем, размещённым внутри границы родительского модуля. Он имеет собственные ответственность, публичный API и границу зависимостей и подчиняется всем общим правилам модулей.
+
+## Связанные правила
+
+- [`SLM-MODULE-A004`](../rules/registry.md#slm-module-a004)
+- [`SLM-MODULE-R006`](../rules/registry.md#slm-module-r006)
+- [`SLM-DEPENDENCY-A005`](../rules/registry.md#slm-dependency-a005)
+- [`SLM-NESTED_MODULE-A010`](../rules/registry.md#slm-nested_module-a010)
+
+## Пример
+
+```text
+landing/
+├── landing.page.tsx
+├── parts/
+│   └── hero/
+│       ├── hero.tsx
+│       └── index.ts
+└── index.ts
+```
+
+`parts/` здесь является примером сегмента, а не обязательным именем.
+
+Код родительского модуля использует вложенный модуль через его собственный публичный API. Код за пределами родительского модуля получает доступ только через публичный API родителя.
+
+Если вложенный модуль становится нужен за пределами родителя, рекомендуется перенести его в минимальную общую область без изменения внутренней формы. Доступ через API родителя при этом остаётся допустимым и сам по себе не требует переноса.
--- a/DRAFT/architecture/segments.md
+++ b/DRAFT/architecture/segments.md
@@ -0,0 +1,29 @@
+# Сегменты SLM
+
+> Пояснение нормативной модели сегментов SLM.
+
+Сегмент организует внутреннее содержимое модуля. SLM определяет роль сегмента, но не задаёт обязательный список имён.
+
+## Связанное правило
+
+- [`SLM-SEGMENT-R008`](../rules/registry.md#slm-segment-r008)
+- [`SLM-MODULE-A004`](../rules/registry.md#slm-module-a004)
+
+## Файловая форма
+
+Названия, набор и содержимое сегментов определяет стайлгайд проекта. Сегмент может группировать файлы, компоненты или вложенные модули.
+
+Файлы и компоненты сегмента принадлежат родительскому модулю. Вложенный модуль внутри сегмента сохраняет собственные ответственность, публичный API и границу зависимостей.
+
+## Пример
+
+```text
+landing/                  # Модуль
+└── ui/                   # Сегмент модуля
+    └── hero/             # Каталог компонента
+        ├── hero.tsx
+        ├── styles/       # Вспомогательный каталог компонента
+        └── types/        # Вспомогательный каталог компонента
+```
+
+`styles/` и `types/` внутри каталога компонента не обязаны считаться сегментами SLM. Их форму определяет стайлгайд компонентов.
--- a/DRAFT/architecture/terminology.md
+++ b/DRAFT/architecture/terminology.md
@@ -0,0 +1,153 @@
+# Терминология SLM
+
+> Нормативные определения рабочего черновика. Этот раздел не объявляет правила.
+
+Определения задают обязательный смысл архитектурных терминов и используются при толковании всех правил. Код получают только блокирующие требования, а не сами определения.
+
+## Базовые понятия
+
+### SLM root
+
+Граница структурной архитектуры одного приложения. Внутри неё определяются слои, модули и зависимости SLM. Монорепозиторий, пакеты и отношения между несколькими SLM root находятся за пределами текущего черновика.
+
+### Ответственность
+
+Связная часть приложения с одной причиной изменяться. Ответственность является самостоятельной, когда ей нужны собственные публичный API, зависимости, состояние или область жизни.
+
+### Владелец
+
+Модуль, который определяет публичный API ответственности, её зависимости, состояние, область жизни и внутреннее устройство. Место выполнения кода не переносит владение.
+
+### Публичный API
+
+Единая логическая граница внешнего доступа к модулю. Публичный API скрывает внутреннее устройство и состоит из обязательного корневого фасета `index` и только реально необходимых environment-фасетов `client`, `browser` и `server`.
+
+### Фасет
+
+Объявленная публичная точка входа модуля, которая открывает часть его единого логического API для определённой среды или способа выполнения. Импорт объявленного фасета не является deep import. Любой другой путь внутрь модуля остаётся внутренним.
+
+Корневой фасет `index` является основным barrel модуля. Он экспортирует публичные типы и runtime-код, совместимый как с серверным рендерингом, включая React Server Components, так и с клиентским выполнением.
+
+Необязательные environment-фасеты имеют следующий нормативный смысл:
+
+| Фасет | Среда и способ выполнения |
+|---|---|
+| `client` | Клиентская framework-граница, которая может участвовать в server prerender и затем выполняться при hydration и в браузере |
+| `browser` | Browser-only код, подключаемый только динамически с отключённым SSR |
+| `server` | Server-only код, недоступный через универсальный, клиентский и браузерный фасеты |
+
+Client Component, импортированный Server Component, не становится универсальным кодом и не экспортируется через `index`. Совместимость фасета со средой определяется всеми его runtime-импортами и реэкспортами, включая транзитивные.
+
+### Зависимость
+
+Статическая связь внутри одного SLM root, которую импорт или реэкспорт создаёт между архитектурными границами. Обычный импорт, импорт типа и реэкспорт одинаково создают архитектурную зависимость.
+
+Зависимость любого внутреннего файла, сегмента или компонента относится к ближайшему модулю-владельцу. Вложенный модуль начинает собственную границу зависимостей.
+
+### Область жизни
+
+Период, в течение которого принадлежащие модулю состояние или долгоживущий ресурс должны оставаться активными.
+
+### Ресурс жизненного цикла
+
+Ресурс, работа которого продолжается после первоначального вызова и требует остановки, отмены, отписки или освобождения. Например, подписка, слушатель событий, таймер, наблюдатель, запрос или соединение.
+
+### Очистка
+
+Гарантированное прекращение работы ресурса не позже завершения его области жизни. Автоматическая очистка фреймворка считается очисткой владельца, если модуль устанавливает и контролирует соответствующую границу.
+
+## Структурные сущности
+
+### Нормативная матрица слоёв
+
+Отношение допустимой зависимости между слоями одного SLM root. Матрица определяет, код каких слоёв может импортировать исходный слой; она не обязана образовывать линейный порядок.
+
+Для SLM нормативно отношение `app → compositions → domains → infra → ui → shared`. `infra` может импортировать `ui`, а `ui` не импортирует `infra`. Промежуточный слой не является обязательным посредником.
+
+### Слой
+
+Одна из шести верхнеуровневых ролей внутри SLM root:
+
+| Слой | Роль |
+|---|---|
+| `app` | Связь приложения с фреймворком: запуск, маршруты и преобразование входных данных |
+| `compositions` | Сборка продуктового интерфейса: страницы, макеты, экраны, виджеты и другие композиции |
+| `domains` | Предметные области, их модели, правила, сценарии и продуктовое состояние |
+| `infra` | Технические сервисы и возможности приложения |
+| `ui` | Универсальные модули интерфейса без зависимости от конкретной продуктовой композиции |
+| `shared` | Независимый детерминированный фундамент без знания о продукте, изменяемого состояния и ввода-вывода |
+
+Полная матрица допустимых зависимостей:
+
+| Исходный слой | Допустимые целевые слои |
+|---|---|
+| `app` | `app`, `compositions`, `domains`, `infra`, `ui`, `shared` |
+| `compositions` | `compositions`, `domains`, `infra`, `ui`, `shared` |
+| `domains` | `domains`, `infra`, `ui`, `shared` |
+| `infra` | `infra`, `ui`, `shared` |
+| `ui` | `ui`, `shared` |
+| `shared` | `shared` |
+
+### Модуль
+
+Минимальная самостоятельная архитектурная единица SLM. Модуль владеет одной связной ответственностью, размещается в отдельной папке и предоставляет публичный API.
+
+### Предметная ответственность
+
+Связная предметная область приложения, которая может включать собственные модели, правила, сценарии и продуктовое состояние. Количество экранов, endpoint-ов, hooks или файлов само по себе не определяет её границу.
+
+### Группа
+
+Навигационная папка для модулей и других групп. Группа не является владельцем ответственности, состояния, области жизни, публичного API или границы зависимостей.
+
+### Сегмент
+
+Внутренняя часть одного модуля, которая группирует его содержимое по назначению. Сегмент не является самостоятельным владельцем, публичным API или границей зависимостей.
+
+### Компонент
+
+Сущность фреймворка, которая реализует часть интерфейса родительского модуля. Компонент не образует собственного владельца, публичного API или границы зависимостей.
+
+Импорты, состояние, доступ к данным и код жизненного цикла компонента принадлежат родительскому модулю. Их наличие само по себе не создаёт новый модуль; решающим признаком является самостоятельная ответственность.
+
+### Вложенный модуль
+
+Обычный модуль, размещённый внутри границы родительского модуля. Он имеет собственные ответственность, публичный API и границу зависимостей и подчиняется всем общим правилам модулей.
+
+Публичный API вложенного модуля доступен коду родительской границы. Для кода за пределами родительского модуля вложенный модуль остаётся внутренней реализацией родителя.
+
+### Точка входа фреймворка
+
+Специальная немодульная единица слоя `app`, которая непосредственно связывает приложение с фреймворком. Её импорты участвуют в проверке направления слоёв, но сама точка входа не является модулем.
+
+### Ресурс shared
+
+Специальная немодульная единица слоя `shared`: небольшая детерминированная утилита, общий тип, стиль, конфигурация или статический ресурс без продуктового знания, изменяемого состояния, ввода-вывода, области жизни и собственного публичного API.
+
+Ресурс `shared` может импортироваться напрямую по пути, установленному стайлгайдом, и не является модулем. Доступный по этому пути файл является всей единицей и не скрывает отдельное внутреннее устройство.
+
+Если ресурсу нужны самостоятельная ответственность, собственные архитектурные зависимости, несколько файлов реализации, изменяемое состояние, ввод-вывод или область жизни, он оформляется как модуль.
+
+## Структурная модель
+
+```text
+SLM root
+├── app
+│   └── точка входа фреймворка
+├── compositions | domains | infra | ui
+│   ├── группа
+│   │   └── модуль
+│   └── модуль
+│       ├── корневые файлы
+│       ├── сегмент
+│       │   ├── файлы
+│       │   ├── компоненты
+│       │   └── вложенные модули
+│       └── вложенный модуль
+└── shared
+    ├── группа
+    ├── модуль
+    └── ресурс shared
+```
+
+Путь и имя папки сами по себе не определяют сущность. Её определяют ответственность, владелец и публичная граница. Физическое сопоставление путей с сущностями задаётся стайлгайдом или конфигурацией проверки проекта.
--- a/DRAFT/architecture/validation.md
+++ b/DRAFT/architecture/validation.md
@@ -0,0 +1,51 @@
+# Проверка SLM
+
+> Граница автоматической проверки и архитектурного ревью SLM.
+
+## Автоматическая проверка
+
+Проект, заявляющий соответствие SLM, сопоставляет физические пути с SLM root, слоями, модулями, Groups, вложенными модулями, публичными фасетами, точками входа `app` и ресурсами `shared`. Такое сопоставление задаётся стайлгайдом или конфигурацией проверки и не изменяет нормативный смысл сущностей.
+
+Каждое правило класса `A` должно быть реализовано проверкой проекта и блокировать её при нарушении. SLM не навязывает конкретный инструмент.
+
+Скрипт `draft-rules.js` проверяет только целостность документов: формат и уникальность кодов, ссылки и наличие тематических упоминаний. Он не проверяет архитектуру приложения.
+
+Актуальный список правил скрипт получает из [канонического реестра](../rules/registry.md).
+
+## Архитектурное ревью
+
+Правила класса `R` проверяются вручную. Статический анализ может обнаружить подозрительный код, но не способен окончательно определить:
+
+- ответственность и её владельца;
+- связность ответственности модуля;
+- соответствие кода роли слоя;
+- необходимость экспортов публичного API;
+- область жизни ресурса и достаточность очистки;
+- наличие самостоятельной границы у компонента, группы или сегмента.
+
+## Проверка фасетов
+
+Автоматическая проверка сопоставляет публичные пути модуля с фасетами `index`, `client`, `browser` и `server`, запрещает остальные внешние пути и проверяет их runtime-импорты и реэкспорты, включая транзитивные.
+
+Для проверки сред инструмент различает runtime imports, type-only imports и dynamic imports. Окончательное решение о соответствии экспортируемого кода назначению фасета принимается на ревью.
+
+На ревью проверяется:
+
+- экспортирует ли `index` только универсальные типы и runtime-код;
+- остаётся ли `client` совместимым с server prerender и browser hydration;
+- достигается ли `browser` только через dynamic boundary с отключённым SSR;
+- остаётся ли `server` недоступным через `index`, `client` и `browser`;
+- существует ли каждый специализированный фасет ради реального потребителя;
+- не дублируется ли один runtime-export между фасетами.
+
+Название файла, директива `use client`, tree shaking или локальная проверка `typeof window` сами по себе не доказывают совместимость кода со средой выполнения.
+
+## Проверка слоя domains
+
+На ревью определяется:
+
+- соответствует ли ответственность модуля предметной роли слоя `domains`;
+- не разделена ли одна область на соседние модули без самостоятельных владельцев;
+- не объединены ли в одном модуле несвязанные предметные области;
+- остаются ли страницы, маршруты и UI нескольких предметных ответственностей в `compositions`;
+- остаются ли самостоятельные технические сервисы без предметной модели в `infra`.