chore: Новый черновик DRAFT, удалить старые docs-v

DRAFT/rules/README.md

@@ -0,0 +1,117 @@
+# Правила SLM
+
+> Статус: системный черновик. Не является нормативной спецификацией.
+
+Эта директория является единственным местом объявления правил SLM. Остальные черновики объясняют архитектуру и ссылаются на канонические коды, но не повторяют формулировки правил.
+
+## Что считается правилом
+
+Правило задаёт один блокирующий архитектурный инвариант.
+
+Определения, рекомендации, разрешения, примеры и открытые вопросы не получают код правила.
+
+Нормативные определения объявляются в терминологии соответствующего уровня. Они обязательны для толкования правил, но нормативность определения сама по себе не превращает его в правило.
+
+## Код правила
+
+```text
+SLM-L{level}-{group}-{class}{number}
+```
+
+| Часть | Значение |
+|---|---|
+| `SLM` | Принадлежность архитектуре SLM |
+| `L{level}` | Уровень архитектуры |
+| `group` | Раздел правил |
+| `class` | Способ проверки: `A` или `R` |
+| `number` | Трёхзначный номер внутри уровня |
+
+## Способы проверки
+
+### `A`: автоматическая проверка
+
+Всё правило можно однозначно проверить программно без понимания предметного смысла кода. Нарушение такого правила должно блокировать автоматическую проверку.
+
+### `R`: проверка на ревью
+
+Для окончательного решения требуется понимание ответственности, владения или смысла зависимости. Линтер может проверять отдельные признаки, но не заменяет решение на ревью.
+
+Одно правило не разделяется на автоматическую и ручную копии только из-за разных способов проверки. Если существенная часть инварианта требует смыслового решения, всё правило получает класс `R`.
+
+## Разделы правил
+
+| Код | Раздел |
+|---|---|
+| `LAYER` | Слои |
+| `DEPENDENCY` | Зависимости |
+| `MODULE` | Модули |
+| `GROUP` | Группы |
+| `SEGMENT` | Сегменты |
+| `COMPONENT` | Компоненты |
+| `NESTED_MODULE` | Вложенные модули |
+| `LIFECYCLE` | Жизненный цикл |
+
+Код раздела записывается полным английским именем в `UPPER_SNAKE_CASE`. Новый код добавляется в таблицу до первого использования.
+
+## Формат записи
+
+```md
+### SLM-L1-MODULE-A004
+
+> **Публичный API модуля**
+>
+> Каждый модуль предоставляет единый публичный API; код за пределами модуля импортирует его содержимое только через этот API.
+```
+
+Код является заголовком третьего уровня и автоматически получает адрес для ссылки `#slm-l1-module-a004`.
+
+Название и описание входят в одну цитату. Название выделяется жирным и служит кратким именем правила. Описание полностью формулирует требование и занимает одну физическую строку.
+
+Ссылка из тематического черновика:
+
+```md
+[`SLM-L1-MODULE-A004`](../rules/level-1.md#slm-l1-module-a004)
+```
+
+## Как формулировать правила
+
+1. Правило понятно без чтения тематической главы и опирается только на нормативные термины своего уровня.
+2. Правило защищает один архитектурный инвариант.
+3. Один инвариант получает один код независимо от числа участников и способов проверки.
+4. Название является кратким и устойчивым именем правила.
+5. Название обозначает предмет правила, а описание полностью формулирует требование.
+6. Описание объясняет допустимую границу и то, что считается нарушением.
+7. Описание раскрывает названный инвариант и не вводит второе независимое требование.
+8. Описание использует нормативные определения и не пересказывает их без необходимости.
+9. Название и описание используют человеческий язык и только необходимые архитектурные термины.
+10. Обоснование, подробности, примеры и исключения размещаются в тематическом черновике, а не в описании.
+11. Правило не создаётся отдельно с позиции владельца и потребителя, если обе формулировки защищают одну границу.
+12. Перед добавлением правила реестр проверяется на дубли и противоречия.
+13. Код присваивается после проверки правила на примерах и контрпримерах.
+
+## Нумерация
+
+1. Номер уникален внутри уровня независимо от раздела и способа проверки.
+2. Номер не обозначает важность или порядок выполнения.
+3. Удалённый номер не переиспользуется для другого правила.
+4. При изменении способа проверки номер сохраняется, но меняется полный код.
+
+## Проверка качества
+
+Перед принятием правила нужно ответить «да»:
+
+- Понятно, о чём правило?
+- Название кратко и однозначно называет правило?
+- Понятно, что оно требует?
+- Понятно, что является нарушением?
+- Нельзя ли объединить его с существующим правилом?
+- Не содержит ли оно рекомендацию или разрешение?
+- Соответствует ли класс способу окончательной проверки?
+
+## Проверка документов
+
+Корневой скрипт `draft-rules.js` читает объявления только из этой директории, проверяет формат и уникальность кодов, валидирует ссылки из остальных черновиков и выводит правила разделами «Автоматические» и «Для ревью». Скрипт проверяет документы, а не архитектуру приложения.
+
+## Наборы правил
+
+- [Первый уровень](./level-1.md)

DRAFT/rules/level-1.md

@@ -0,0 +1,102 @@
+# Правила SLM первого уровня
+Здесь собраны правила первого уровня. Это единственное место, где они формулируются; тематические черновики объясняют их и ссылаются на коды.
+
+## Размещение кода по слоям
+
+### SLM-L1-LAYER-R001
+
+> **Назначение слоёв**
+>
+> Код внутри SLM root размещается в слое, нормативная роль которого соответствует ответственности этого кода.
+
+### SLM-L1-LAYER-A002
+
+> **Направление зависимостей**
+>
+> Внутри одного SLM root код каждого слоя может зависеть только от кода этого же или любого нижнего слоя в порядке `app → compositions → infra → ui → shared`.
+
+### SLM-L1-LAYER-R003
+
+> **Граница слоя `app`**
+>
+> В `app` размещаются только точки входа фреймворка для запуска, маршрутов, преобразования входных данных и подключения публичных API нижних модулей или ресурсов `shared`; ответственности нижних слоёв остаются за пределами `app`.
+
+## Границы модулей
+
+### SLM-L1-MODULE-A004
+
+> **Публичный API модуля**
+>
+> Каждый модуль предоставляет единый публичный API; код за пределами модуля импортирует его содержимое только через этот API.
+
+### SLM-L1-MODULE-A014
+
+> **Папка модуля**
+>
+> Каждый модуль размещается в отдельной папке; его публичный API и внутренняя реализация находятся внутри этой границы, а вложенные модули образуют собственные папки.
+
+### SLM-L1-MODULE-R006
+
+> **Ответственность модуля**
+>
+> Одна модульная граница содержит код одной связной ответственности; части, которые изменяются по несвязанным причинам, размещаются в разных модулях.
+
+### SLM-L1-MODULE-R011
+
+> **Владелец ответственности**
+>
+> Каждая самостоятельная ответственность и относящийся к ней код принадлежат ровно одному модулю; вне модульной границы допускаются только точки входа `app` и нормативные ресурсы `shared`.
+
+### SLM-L1-MODULE-R012
+
+> **Состав публичного API**
+>
+> Публичный API модуля открывает только контракт, необходимый реальным внешним потребителям; детали реализации и изменяемые внутренние механизмы остаются закрытыми.
+
+## Зависимости между модулями
+
+### SLM-L1-DEPENDENCY-A005
+
+> **Циклические зависимости**
+>
+> Граф зависимостей модулей внутри одного SLM root, включая вложенные модули, не содержит циклов.
+
+## Назначение групп
+
+### SLM-L1-GROUP-R007
+
+> **Назначение группы**
+>
+> Группа содержит только модули и другие группы, не владеет файлами реализации, состоянием, жизненным циклом или публичным API и не импортируется внешним кодом.
+
+## Назначение сегментов
+
+### SLM-L1-SEGMENT-R008
+
+> **Граница сегмента**
+>
+> Сегмент организует код только внутри одного модуля и не имеет собственной ответственности, публичного API или узла графа зависимостей.
+
+## Ответственность компонентов
+
+### SLM-L1-COMPONENT-R009
+
+> **Ответственность компонента**
+>
+> Компонент реализует часть ответственности одного родительского модуля; все его зависимости, состояние и жизненный цикл принадлежат этому модулю и не образуют самостоятельную архитектурную границу.
+
+## Границы вложенных модулей
+
+### SLM-L1-NESTED_MODULE-A010
+
+> **Доступ к вложенному модулю**
+>
+> Код за пределами родительского модуля не импортирует вложенный модуль напрямую и получает его экспорты только через публичный API родителя.
+
+## Жизненный цикл
+
+### SLM-L1-LIFECYCLE-R013
+
+> **Жизненный цикл ресурсов**
+>
+> Для каждого ресурса жизненного цикла модуль-владелец определяет создание, область жизни, число экземпляров и очистку; ресурс активен только внутри своей области жизни.