Files
slm-design/DRAFT/rules/README.md
S. Gromov 691069af8e sync
2026-08-10 09:12:22 +03:00

8.1 KiB
Raw Blame History

Правила SLM

Статус: системный черновик. Не является нормативной спецификацией.

Эта директория является единственным местом объявления правил SLM. Остальные черновики объясняют архитектуру и ссылаются на канонические коды, но не повторяют формулировки правил.

Что считается правилом

Правило задаёт один блокирующий архитектурный инвариант.

Определения, рекомендации, разрешения, примеры и открытые вопросы не получают код правила.

Нормативные определения объявляются в терминологии SLM. Они обязательны для толкования правил, но нормативность определения сама по себе не превращает его в правило.

Код правила

SLM-{group}-{class}{number}
Часть Значение
SLM Принадлежность архитектуре SLM
group Раздел правил
class Способ проверки: A или R
number Глобально уникальный трёхзначный номер правила

Способы проверки

A: автоматическая проверка

Всё правило можно однозначно проверить программно без понимания предметного смысла кода. Нарушение такого правила должно блокировать автоматическую проверку.

R: проверка на ревью

Для окончательного решения требуется понимание ответственности, владения или смысла зависимости. Линтер может проверять отдельные признаки, но не заменяет решение на ревью.

Одно правило не разделяется на автоматическую и ручную копии только из-за разных способов проверки. Если существенная часть инварианта требует смыслового решения, всё правило получает класс R.

Разделы правил

Код Раздел
LAYER Слои
DEPENDENCY Зависимости
MODULE Модули
GROUP Группы
SEGMENT Сегменты
COMPONENT Компоненты
NESTED_MODULE Вложенные модули
LIFECYCLE Жизненный цикл
ENVIRONMENT Границы сред выполнения

Код раздела записывается полным английским именем в UPPER_SNAKE_CASE. Новый код добавляется в таблицу до первого использования.

Формат записи

### SLM-MODULE-A004

> **Публичный API модуля**
>
> Каждый модуль предоставляет единый логический публичный API через обязательный корневой фасет `index` и, при необходимости, фасеты `client`, `browser` и `server`; код за пределами модуля импортирует его содержимое только через эти фасеты.

Код является заголовком третьего уровня и автоматически получает адрес для ссылки #slm-module-a004.

Название и описание входят в одну цитату. Название выделяется жирным и служит кратким именем правила. Описание полностью формулирует требование и занимает одну физическую строку.

Ссылка из тематического черновика:

[`SLM-MODULE-A004`](./registry.md#slm-module-a004)

Как формулировать правила

  1. Правило понятно без чтения тематической главы и опирается только на нормативные термины SLM.
  2. Правило защищает один архитектурный инвариант.
  3. Один инвариант получает один код независимо от числа участников и способов проверки.
  4. Название является кратким и устойчивым именем правила.
  5. Название обозначает предмет правила, а описание полностью формулирует требование.
  6. Описание объясняет допустимую границу и то, что считается нарушением.
  7. Описание раскрывает названный инвариант и не вводит второе независимое требование.
  8. Описание использует нормативные определения и не пересказывает их без необходимости.
  9. Название и описание используют человеческий язык и только необходимые архитектурные термины.
  10. Обоснование, подробности, примеры и исключения размещаются в тематическом черновике, а не в описании.
  11. Правило не создаётся отдельно с позиции владельца и потребителя, если обе формулировки защищают одну границу.
  12. Перед добавлением правила реестр проверяется на дубли и противоречия.
  13. Код присваивается после проверки правила на примерах и контрпримерах.

Нумерация

  1. Номер глобально уникален независимо от раздела и способа проверки.
  2. Номер не обозначает важность или порядок выполнения.
  3. Удалённый номер не переиспользуется для другого правила.
  4. При изменении способа проверки номер сохраняется, но меняется полный код.

Проверка качества

Перед принятием правила нужно ответить «да»:

  • Понятно, о чём правило?
  • Название кратко и однозначно называет правило?
  • Понятно, что оно требует?
  • Понятно, что является нарушением?
  • Нельзя ли объединить его с существующим правилом?
  • Не содержит ли оно рекомендацию или разрешение?
  • Соответствует ли класс способу окончательной проверки?

Проверка документов

Корневой скрипт draft-rules.js читает объявления только из этой директории, проверяет формат и уникальность кодов, валидирует ссылки из остальных черновиков и выводит правила разделами «Автоматические» и «Для ревью». Скрипт проверяет документы, а не архитектуру приложения.

Реестр