chore: sync

docs/README.md

@@ -1,75 +1,107 @@
 ---
 layout: home
-title: SLM Design
-description: Архитектура фронтенд-приложений с явным владением ответственностями
+title: Архитектура фронтенд-приложений
+description: SLM Design помогает командам сохранять понятную структуру и предсказуемо развивать фронтенд-приложения по мере роста продукта.
 
 hero:
   name: SLM Design
-  text: Архитектура владения ответственностями
-  tagline: Сначала определяется ответственность и её владелец. Слои, группы, модули и сегменты выражают уже принятое архитектурное решение.
+  text: Архитектура фронтенд-приложений
+  tagline: Практичная модель для растущих команд и продуктов. Меньше споров о структуре, безопаснее изменения и понятнее код.
   image:
     src: /logo.svg
     alt: SLM Design
   actions:
     - theme: brand
-      text: Изучить архитектуру
+      text: Узнать, как это работает
       link: /architecture/
     - theme: alt
-      text: Открыть правила
+      text: Посмотреть правила
       link: /rules/registry
 
 features:
-  - title: Ответственность раньше структуры
-    details: Модуль появляется из самостоятельной ответственности, а не из размера каталога, количества файлов или выбранного фреймворка.
-  - title: Явная структурная модель
-    details: Слой определяет роль, группа классифицирует модули, модуль владеет ответственностью, сегмент организует реализацию.
-  - title: Проверяемые границы
-    details: Публичные API, направление зависимостей и правила жизненного цикла делают архитектурное решение наблюдаемым и проверяемым.
+  - title: Один язык для всей команды
+    details: Разработчики одинаково понимают границы, ответственность и место нового кода. Архитектурные решения перестают зависеть от личных предпочтений.
+  - title: Предсказуемые изменения
+    details: Локальная правка остаётся локальной. Команда может развивать внутреннюю реализацию, не переписывая половину приложения.
+  - title: Рост без хаоса
+    details: Структура усложняется только вместе с продуктом, а не из-за количества файлов, компонентов или выбранных библиотек.
+  - title: Архитектура видна в репозитории
+    details: Правила выражены кодом и структурой проекта, поэтому документация не расходится с реальным приложением.
+  - title: Независимость от стека
+    details: SLM не требует конкретного фреймворка, state manager или способа работы с данными и не ограничивает внутреннюю реализацию.
+  - title: Постепенное внедрение
+    details: Начните с одного спорного участка и расширяйте модель по мере необходимости, без полной перестройки приложения.
 ---
 
-SLM Design (Scoped Layered Module Design) — структурная архитектура фронтенд-приложений, основанная на явном владении ответственностями.
+## Папки перестают быть архитектурой, когда продукт начинает расти
 
-Архитектурное решение начинается не с папки или имени файла. Сначала определяется ответственность, затем её владелец, роль владельца в приложении и только после этого физическое размещение кода.
+На старте почти любая структура выглядит понятной. Затем появляются десятки компонентов, общие hooks, Providers, stores, глубокие импорты и модули, которые знают друг о друге слишком много. Папки остаются на месте, но границы ответственности исчезают.
 
-## Основа
+SLM возвращает архитектуре наблюдаемый смысл:
 
-SLM использует четыре структурных понятия:
+> **Модуль владеет ответственностью. Весь код внутри ближайшей модульной границы реализует её.**
 
-1. **Слой** классифицирует код по архитектурной роли и ограничивает направление зависимостей.
-2. **Группа** помогает классифицировать модули внутри слоя, но ничего не реализует и ничем не владеет.
-3. **Модуль** владеет самостоятельной ответственностью, её публичным API, зависимостями, состоянием и жизненным циклом.
-4. **Сегмент** организует внутреннее содержимое одного модуля и не создаёт нового владельца.
+Это правило одинаково работает для страницы, доменного сценария, UI-библиотеки, инфраструктурного сервиса и небольшого внутреннего модуля.
+
+## Что меняется для команды
+
+| Когда границ нет | С SLM Design |
+|---|---|
+| Решение о размещении кода принимается по похожей папке | Сначала определяется ответственность и её владелец |
+| Компоненты и services становятся скрытыми архитектурными центрами | Любой внутренний механизм остаётся реализацией ближайшего модуля |
+| Потребители импортируют удобный внутренний файл | Чужой модуль доступен только через публичный фасет |
+| Циклы обнаруживаются во время большого рефакторинга | Модульный граф можно проверять lint-инструментами |
+| Новые уровни создаются из-за размера каталога | Вложенный модуль появляется только для самостоятельной подответственности |
+
+Результат: меньше случайной связанности, меньше споров о папках и предсказуемый радиус каждого изменения.
+
+## Не ещё один шаблон директорий
+
+SLM не диктует, какие библиотеки, state managers или framework-механизмы использовать. Внутри модуля могут находиться компоненты, Providers, Guards, hooks, stores, services, utilities и сторонние SDK.
+
+Архитектура отвечает на другие вопросы:
+
+1. За какой результат отвечает этот код?
+2. Какой модуль владеет его контрактом и состоянием?
+3. Что действительно нужно внешним потребителям?
+4. Какие зависимости допустимы и не создают ли они цикл?
+5. Где заканчивается область жизни ресурсов?
+
+Файловая структура появляется после ответов, а не заменяет их.
+
+## От одного файла до дерева владельцев
+
+Модуль может начинаться с одного главного файла и расти без смены архитектурной сущности:
 
 ```text
-Слой → [Группа*] → Модуль → [Сегмент*]
+checkout/
+├── index.ts                    # Публичный контракт
+├── checkout.tsx                # Главная реализация
+├── components/                 # Внутренний код checkout
+├── hooks/
+├── services/
+└── modules/
+    └── form-session/           # Самостоятельная подответственность
+        ├── index.ts
+        ├── form-session.provider.tsx
+        └── hooks/
 ```
 
-Знак `*` означает, что элементов может не быть или их может быть несколько. Группы могут быть вложены друг в друга внутри одного слоя. Сегменты всегда остаются внутри одного модуля.
+Размер, количество файлов и framework-роли не создают владельца. Только отдельно сформулированная ответственность получает модульную границу.
 
-## Документация
+## Правила, которые можно проверить
 
-### Архитектура
+SLM разделяет смысловые решения и структурные инварианты:
 
-- [Обзор архитектуры](./architecture/)
-- [Слои](./architecture/layers.md)
-- [Модули](./architecture/modules.md)
-- [Сегменты](./architecture/segments.md)
+- ответственность, владелец и минимальный публичный контракт проверяются на архитектурном ревью;
+- направления между слоями, глубокие импорты, публичные фасеты и модульные циклы проверяются автоматически;
+- каждый rule имеет стабильный код и одно место нормативной формулировки;
+- framework-компоненты не образуют бесконечную файловую рекурсию, а новые уровни появляются только через вложенные модули.
 
-### Правила
+Вы получаете не абстрактный набор рекомендаций, а модель, которую можно обсуждать одинаковыми терминами, видеть в репозитории и постепенно автоматизировать.
 
-- [Как устроены правила](./rules/)
-- [Реестр правил](./rules/registry.md)
+## Начните с одной ответственности
 
-### Справочные материалы
+Не нужно переписывать приложение целиком. Выберите один спорный участок, сформулируйте его ответственность, назначьте владельца и закройте внутреннюю реализацию публичным API. Этого достаточно, чтобы увидеть разницу между папкой и архитектурной границей.
 
-- [Терминология](./reference/terminology.md)
-- [Проверка архитектуры](./reference/validation.md)
-
-## Порядок принятия решения
-
-1. Сформулировать ответственность без упоминания папок, файлов и библиотек.
-2. Назначить одного владельца ответственности.
-3. Выбрать слой по роли владельца.
-4. Определить публичный контракт, зависимости, состояние и жизненный цикл.
-5. Организовать реализацию сегментами, если это упрощает навигацию.
-6. Представить принятое решение папками, файлами и публичными точками входа.
+[Спроектировать первый модуль](./architecture/modules.md) · [Разобрать зависимости](./architecture/dependencies.md) · [Проверить существующую структуру](./reference/validation.md)