docs/projects/slm-design/skill/slm-design.skill.md

SLM Design Skill

SLM Design — новая архитектура. Не заменяй её правилами Feature-Sliced Design, Atomic Design, Clean Architecture или другими привычными схемами. Если в проекте нет локальной документации SLM, считай этот файл единственным источником правды.

Определение Контекста

Перед применением правил убедись, что проект использует SLM Design.

1. Проверь характерные слои SLM. Сильные сигналы: одновременное наличие src/screens/ и src/widgets/ (комбинация специфична именно для SLM — в FSD это pages/, в Atomic и Clean таких слоёв нет); файлы *.factory.ts в business-модулях с index.ts, экспортирующим только фабрику и type-only. Дополнительные сигналы: src/ui/, src/shared/, src/layouts/ как слои. В монорепо проверяй то же внутри apps/{app}/src/. ВАЖНО: отсутствие src/business/ НЕ означает, что проект не на SLM. В маленьких или ранних проектах бизнес-доменов может ещё не быть.
2. Проверь, что business-модули (если они есть) имеют *.factory.ts в корне и index.ts экспортирует только фабрику и type-only экспорты.
3. Если видишь признаки другой архитектуры — features/, entities/, pages/ (FSD), atoms/, molecules/ (Atomic), domain/, useCases/ (Clean) — это НЕ SLM. Не применяй правила этого skill.
4. Если структура неоднозначна или проект новый — спроси пользователя, какая архитектура используется, прежде чем применять правила.
5. Если пользователь работает в legacy-коде без SLM и НЕ просит миграцию — не предлагай рефакторинг по SLM. Соблюдай существующие паттерны кода.

Порядок Работы

1. Найди границу приложения: src/ или apps/{app}/src.
2. Определи ответственность изменения: запуск приложения, layout, screen, widget, business-domain, infra-service, UI-kit или shared resource.
3. Размещай код на самом низком подходящем уровне и поднимай выше только при реальной потребности переиспользования.
4. Проверяй, является сущность модулем или компонентом. Если сущность получает данные, владеет сценарием, композирует зависимости или имеет внутреннюю архитектуру — это модуль, а не компонент в ui/.
5. Все внешние импорты между модулями делай только через публичный API (index.ts). Deep imports запрещены.
6. Для business runtime-зависимостей между доменами используй фабрики. Не импортируй runtime-код одного business-домена напрямую в другой.
7. Перед завершением проверь слой, модульную границу, сегменты, публичный API, направление импортов и monorepo-ограничения.

Жёсткие Правила

• Направление зависимостей внутри приложения: app → [ layouts | screens ] → widgets → business → infra → ui → shared.
• layouts и screens параллельны и не импортируют друг друга.
• Модули одного слоя в группе «Композиция» изолированы друг от друга.
• Runtime-импорты между business-доменами запрещены. Cross-domain runtime-зависимости передаются только через аргументы фабрики.
• import type в группе «Ядро» разрешён в обоих направлениях, потому что не создаёт runtime-зависимость.
• Каждый внешний импорт модуля идёт через index.ts модуля или публичный API пакета.
• business/{name}/index.ts экспортирует только фабрику и type-only экспорты.
• Компонент в ui/ родительского модуля не импортирует проектный код за пределами родительского модуля, не получает данные, не вызывает сценарные хуки и не содержит бизнес-логику.
• parts/ содержит только вложенные модули, не произвольные .tsx, стили или хуки.
• shared/ не знает о продукте, бизнес-доменах, UI-kit сущностях и runtime-состоянии.
• В monorepo SLM применяется внутри каждого apps/{app}/src.
• В packages/* можно выносить только общие ui, infra и shared. business, app, layouts, screens, widgets не выносятся в пакеты.

Выбор Места Для Кода

• Код нужен одной странице или layout: оставь его внутри screens/{name}/parts/ или layouts/{name}/parts/.
• Абстрактный UI без бизнес-логики и сценариев: ui/{name}/.
• Составной блок интерфейса без принадлежности конкретному домену, используемый в нескольких screens/layouts: widgets/{name}/.
• Код принадлежит бизнес-домену: business/{domain}/, даже если переиспользуется.
• Технический сервис приложения: infra/{service}/.
• Чистая утилита или фундаментальный ресурс без знания о продукте: shared/.
• В monorepo общий UI/infra/shared код, потенциально нужный двум и более frontend-приложениям: packages/ui/*, packages/infra/*, packages/shared.

Шаблон Business-Модуля

business/{name}/
├── {name}.factory.ts
├── hooks/
├── services/
├── mappers/
├── types/
│   ├── {name}-api.type.ts
│   ├── {name}-deps.type.ts
│   └── {name}-factory.type.ts
├── ui/
└── index.ts

Фабрика лежит в корне business-модуля и возвращает публичный runtime API. Если модулю нужны другие домены, принимай зависимости аргументом фабрики доменными именами.

export { customerFactory } from './customer.factory'

export type { Customer } from './types/customer.type'
export type { CustomerApi } from './types/customer-api.type'
export type { CustomerDeps } from './types/customer-deps.type'
export type { CustomerFactory } from './types/customer-factory.type'

Чеклист Ревью

Проверяй архитектуру в таком порядке:

1. Правильно ли выбран слой по ответственности?
2. Не вынесен ли код выше, чем нужно для текущего использования?
3. Не лежит ли модульная сущность в ui/ как компонент?
4. Не содержит ли компонент в ui/ данные, сценарии, внешние импорты или вложенную архитектуру?
5. Есть ли у каждого модуля публичный API и нет ли deep imports?
6. Соблюдено ли направление зависимостей?
7. Нет ли runtime-импортов между business-доменами?
8. Экспортирует ли business/index.ts только фабрику и типы?
9. Не попали ли продуктовые типы, конфиги или стили в shared/?
10. В monorepo не вынесены ли business, screens, layouts или widgets в packages/*?

При ревью сначала перечисляй нарушения с файлами и причиной. Затем предлагай минимальное исправление.

Каноническая Спецификация

Ниже находится полная спецификация SLM Design из канонов проекта. Не сокращай и не переинтерпретируй эти правила.