# 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-Модуля

```text
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. Если модулю нужны другие домены, принимай зависимости аргументом фабрики доменными именами.

```ts
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 из канонов проекта. Не сокращай и не переинтерпретируй эти правила.

<!-- SLM_CANON_CONTENT -->