docs: ввести DEVELOP.md как точку входа архива

- Удалена автогенерация README.md архива (buildArchiveReadme). - Добавлен DEVELOP.md — точка входа с обязательным порядком чтения: архитектура → базовые правила → прикладные по задаче. - Добавлен MAP.md — статичная карта со ссылками на все разделы. - DEVELOP.md и MAP.md исключены из веб-сборки (srcExclude). - DEVELOP.md исключён из копирования в docs/public/docs/. - Удалено копирование llms-full.txt в архив (только для сайта). - В CONTRIBUTING.md ссылка README.md заменена на MAP.md.
docs: уточнить правила и заголовки вложенных разделов
2026-04-28 20:28:01 +03:00 · 2026-04-28 16:02:00 +03:00 · 2026-04-28 15:35:10 +03:00 · 2026-04-28 10:52:09 +03:00 · 2026-04-27 12:04:34 +03:00 · 2026-04-27 12:04:31 +03:00
107 changed files with 3321 additions and 2551 deletions
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -1,93 +1,100 @@
 import { defineConfig } from 'vitepress';

-const ruSidebar = [
+const sidebar = [
  {
-    text: 'Workflow',
-    link: '/ru/workflow',
+    text: 'Главная',
+    link: '/docs/',
+  },
+  {
+    text: 'Подсказки',
+    link: '/docs/workflow',
  },
  {
    text: 'Базовые правила',
    items: [
-      { text: 'Технологии и библиотеки', link: '/ru/basics/tech-stack' },
-      { text: 'Именование', link: '/ru/basics/naming' },
+      { text: 'Технологии и библиотеки', link: '/docs/basics/tech-stack' },
+      { text: 'Именование', link: '/docs/basics/naming' },
      {
        text: 'Архитектура',
        collapsed: true,
        items: [
-          { text: 'Обзор', link: '/ru/basics/architecture/' },
-          { text: 'Слои', link: '/ru/basics/architecture/reference/layers' },
-          { text: 'Модули', link: '/ru/basics/architecture/reference/modules' },
-          { text: 'Сегменты', link: '/ru/basics/architecture/reference/segments' },
+          { text: 'Обзор', link: '/docs/basics/architecture/' },
+          { text: 'Слои', link: '/docs/basics/architecture/reference/layers' },
+          { text: 'Модули', link: '/docs/basics/architecture/reference/modules' },
+          { text: 'Сегменты', link: '/docs/basics/architecture/reference/segments' },
        ],
      },
-      { text: 'Стиль кода', link: '/ru/basics/code-style' },
-      { text: 'Документирование', link: '/ru/basics/documentation' },
-      { text: 'Типизация', link: '/ru/basics/typing' },
+      { text: 'Стиль кода', link: '/docs/basics/code-style' },
+      { text: 'Документирование', link: '/docs/basics/documentation' },
+      { text: 'Типизация', link: '/docs/basics/typing' },
    ],
  },
  {
-    text: 'Прикладные разделы',
+    text: 'Создание проекта',
    items: [
-      { text: 'Структура проекта', link: '/ru/applied/project-structure' },
-      { text: 'Компоненты', link: '/ru/applied/components' },
-      { text: 'Страницы (App Router)', link: '/ru/applied/page-level' },
-      { text: 'Шаблоны и генерация кода', link: '/ru/applied/templates-generation' },
-      { text: 'Стили', link: '/ru/applied/styles' },
-      { text: 'Изображения', link: '/ru/applied/images-sprites' },
-      { text: 'SVG-спрайты', link: '/ru/applied/svg-sprites' },
-      { text: 'Видео', link: '/ru/applied/video' },
-      { text: 'API', link: '/ru/applied/api' },
-      { text: 'Stores', link: '/ru/applied/stores' },
-      { text: 'Хуки', link: '/ru/applied/hooks' },
-      { text: 'Шрифты', link: '/ru/applied/fonts' },
-      { text: 'Локализация', link: '/ru/applied/localization' },
-      { text: 'Настройка VS Code', link: '/ru/applied/vscode' },
-    ],
-  },
-];
-
-const enSidebar = [
-  {
-    text: 'Processes',
-    items: [
-      { text: 'Getting Started', link: '/en/workflow/getting-started' },
-      { text: 'Creating an App', link: '/en/workflow/creating-app' },
-      { text: 'Creating Pages', link: '/en/workflow/creating-pages' },
-      { text: 'Creating Components', link: '/en/workflow/creating-components' },
-      { text: 'Styling', link: '/en/workflow/styling' },
-      { text: 'Data Fetching', link: '/en/workflow/data-fetching' },
-      { text: 'State Management', link: '/en/workflow/state-management' },
-      { text: 'Localization', link: '/en/workflow/localization' },
+      { text: 'Из шаблона', link: '/docs/creating-project/from-template' },
+      { text: 'По гайду вручную', link: '/docs/creating-project/manual' },
+      { text: 'Чистый Next.js', link: '/docs/creating-project/nextjs' },
    ],
  },
  {
-    text: 'Basic Rules',
+    text: 'Настройка',
    items: [
-      { text: 'Tech Stack', link: '/en/basics/tech-stack' },
-      { text: 'Architecture', link: '/en/basics/architecture' },
-      { text: 'Code Style', link: '/en/basics/code-style' },
-      { text: 'Naming', link: '/en/basics/naming' },
-      { text: 'Documentation', link: '/en/basics/documentation' },
-      { text: 'Typing', link: '/en/basics/typing' },
+      { text: 'Алиасы импортов', link: '/docs/setup/aliases' },
+      { text: 'Biome', link: '/docs/setup/biome' },
+      { text: 'PostCSS', link: '/docs/setup/postcss' },
+      { text: 'Стили', link: '/docs/setup/styles' },
+      { text: 'SVG-спрайты', link: '/docs/setup/svg-sprites' },
+      { text: 'Шаблоны генерации', link: '/docs/setup/templates' },
+      { text: 'VS Code', link: '/docs/setup/vscode' },
    ],
  },
  {
-    text: 'Applied Sections',
+    text: 'Использование',
    items: [
-      { text: 'VS Code Setup', link: '/en/applied/vscode' },
-      { text: 'Project Structure', link: '/en/applied/project-structure' },
-      { text: 'Components', link: '/en/applied/components' },
-      { text: 'Page-level Components', link: '/en/applied/page-level' },
-      { text: 'Templates & Code Generation', link: '/en/applied/templates-generation' },
-      { text: 'Styles', link: '/en/applied/styles' },
-      { text: 'Images', link: '/en/applied/images-sprites' },
-      { text: 'SVG Sprites', link: '/en/applied/svg-sprites' },
-      { text: 'Video', link: '/en/applied/video' },
-      { text: 'API', link: '/en/applied/api' },
-      { text: 'Stores', link: '/en/applied/stores' },
-      { text: 'Hooks', link: '/en/applied/hooks' },
-      { text: 'Fonts', link: '/en/applied/fonts' },
-      { text: 'Localization', link: '/en/applied/localization' },
+      { text: 'Структура проекта', link: '/docs/usage/project-structure' },
+      { text: 'Компоненты', link: '/docs/usage/components' },
+      { text: 'Страницы (App Router)', link: '/docs/usage/page-level' },
+      { text: 'Шаблоны и генерация кода', link: '/docs/usage/templates-generation' },
+      { text: 'Стили', link: '/docs/usage/styles' },
+      // Неактивные разделы: страницы существуют, но пока пустые.
+      // Оставляем в sidebar без `link`, чтобы видеть план, но без перехода.
+      { text: 'Изображения · в разработке' },
+      { text: 'SVG-спрайты', link: '/docs/usage/svg-sprites' },
+      { text: 'Видео · в разработке' },
+      { text: 'Stores · в разработке' },
+      { text: 'Хуки · в разработке' },
+      { text: 'Шрифты · в разработке' },
+      { text: 'Локализация · в разработке' },
+    ],
+  },
+  {
+    text: 'Данные',
+    items: [
+      { text: 'Введение', link: '/docs/usage/data/' },
+      {
+        text: 'REST',
+        collapsed: true,
+        items: [
+          {
+            text: 'Клиенты',
+            collapsed: true,
+            items: [
+              { text: 'Автоматическая генерация', link: '/docs/usage/data/rest/clients/auto' },
+              { text: 'Ручное создание', link: '/docs/usage/data/rest/clients/manual' },
+            ],
+          },
+          {
+            text: 'Получение данных',
+            collapsed: true,
+            items: [
+              { text: 'Серверные компоненты', link: '/docs/usage/data/rest/fetching/server' },
+              { text: 'Клиентские компоненты', link: '/docs/usage/data/rest/fetching/client' },
+            ],
+          },
+        ],
+      },
+      { text: 'Realtime', link: '/docs/usage/data/realtime' },
    ],
  },
 ];
@@ -114,9 +121,25 @@ export default defineConfig({
  // `docs/public/` содержит сгенерированные `.md`-копии и `llms.txt` для LLM
  // (попадают в корень `dist/` как статика). Исключаем из сканирования
  // страниц, иначе VitePress рендерит их как HTML-страницы.
-  srcExclude: ['public/**'],
+  //
+  // `DEVELOP.md` и `MAP.md` — файлы архива (точка входа и карта).
+  // Содержат относительные ссылки, на сайте им делать нечего —
+  // эту роль выполняют сайдбар и `llms.txt`.
+  srcExclude: ['public/**', '**/DEVELOP.md', '**/MAP.md'],
+  lang: 'ru-RU',
  title: 'NextJS Style Guide',
-  description: 'Правила и стандарты разработки на NextJS и TypeScript',
+  description: 'Стандарты разработки на Next.js + TypeScript с архитектурой SLM',
+
+  // Чистые URL без `.html` — канон для индексации.
+  // Серверная поддержка реализована в Caddyfile (try_files + редирект).
+  cleanUrls: true,
+
+  // Дублируем указатель на llms.txt в <head> — для агентов,
+  // которые читают HTML, но не парсят полный DOM/href.
+  head: [
+    ['link', { rel: 'alternate', type: 'text/plain', href: '/llms.txt', title: 'llms.txt' }],
+    ['link', { rel: 'alternate', type: 'text/plain', href: '/llms-full.txt', title: 'llms-full.txt' }],
+  ],

  vite: {
    plugins: [utf8TextPlugin],
@@ -125,38 +148,18 @@ export default defineConfig({
    },
  },

-  locales: {
-    root: {
-      label: 'Languages',
-      lang: 'en',
-    },
-    ru: {
-      label: 'Русский',
-      lang: 'ru-RU',
-      link: '/ru/',
-      description: 'Стандарты разработки на Next.js + TypeScript с архитектурой SLM',
  themeConfig: {
-        sidebar: ruSidebar,
+    sidebar,
+    socialLinks: [
+      { icon: 'github', link: 'https://gromlab.ru/docs/nextjs-style-guide' },
+    ],
  },
+
  // Расширенный блок описания для llms.txt — даёт LLM полный
  // технический контекст: стек, методология, охват тем.
+  // Используется в generate-llms.ts.
  llmsBlockquote:
    'Стандарты разработки frontend-приложений на Next.js (App Router) + TypeScript + React с архитектурой SLM (Scoped Layered Module Design — модульная архитектура со слоями ответственности, где каждый модуль содержит всё необходимое: компоненты, хуки, сторы, типы, стили).',
  llmsContext:
    'Стек: React, TypeScript, Next.js App Router, Mantine UI, SWR, Zustand, i18next, PostCSS Modules, Vitest, clsx.\n\nДокументация покрывает архитектуру SLM (слои, модули, сегменты, направление зависимостей, публичный API), правила оформления кода (именование, форматирование, импорты, типизация, JSDoc), реализацию компонентов и хуков, работу с App Router, кодогенерацию из шаблонов, стилизацию (Mobile First, токены), работу с API и сокетами, управление состоянием через Zustand, локализацию, ассеты (шрифты, изображения, SVG-спрайты) и настройку VS Code.',
-    },
-    en: {
-      label: 'English',
-      lang: 'en-US',
-      link: '/en/',
-      description: 'Next.js + TypeScript development standards with SLM architecture',
-      themeConfig: {
-        sidebar: enSidebar,
-      },
-      llmsBlockquote:
-        'Frontend development standards for Next.js (App Router) + TypeScript + React projects with SLM architecture (Scoped Layered Module Design — a modular architecture with responsibility layers, where each module contains everything it needs: components, hooks, stores, types, styles).',
-      llmsContext:
-        'Stack: React, TypeScript, Next.js App Router, Mantine UI, SWR, Zustand, i18next, PostCSS Modules, Vitest, clsx.\n\nThe documentation covers SLM architecture (layers, modules, segments, dependency direction, public API), code conventions (naming, formatting, imports, typing, JSDoc), component and hook implementation, App Router usage, code generation from templates, styling (Mobile First, design tokens), API and socket integration, state management via Zustand, localization, assets (fonts, images, SVG sprites), and VS Code setup.',
-    },
-  },
-});
+} as any);
--- a/.vitepress/theme/custom.css
+++ b/.vitepress/theme/custom.css
@@ -15,3 +15,5 @@
  max-width: 100%;
  overflow-wrap: anywhere;
 }
+
+
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -7,9 +7,8 @@
 Документационный сайт с правилами и стандартами фронтенд-разработки на Next.js + TypeScript.

 - Движок: VitePress
- Языки: русский (основной), английский
- Русская версия: `docs/ru/`
- Английская версия: `docs/en/`
+- Язык: русский
+- Контент: `docs/docs/`

 ## Команды

@@ -17,82 +16,140 @@
 |---------|-----------|
 | `npm run dev` | Локальный сервер разработки |
 | `npm run build` | Сборка статического сайта |
-| `npm run llms` | Генерация `generated/{lang}/llms.txt` (карта документации для LLM) и README |
+| `npm run llms` | Генерация `llms.txt` (карта документации для LLM) и README |

 ## Структура файлов

 ```
 docs/
-├── ru/                          # Русская версия (основная)
-│   ├── index.md                 # Главная страница
-│   ├── basics/                  # Базовые правила
-│   │   ├── tech-stack.md
-│   │   ├── architecture.md
-│   │   ├── code-style.md
-│   │   ├── naming.md
-│   │   ├── documentation.md
-│   │   └── typing.md
-│   └── applied/                 # Прикладные разделы
-│       ├── vscode.md
-│       ├── project-structure.md
-│       ├── components.md
-│       ├── page-level.md
-│       ├── templates-generation.md
+├── index.md                     # Лендинг (URL `/`)
+└── docs/                        # Контент документации (URL `/docs/...`)
+    ├── index.md                 # Главная страница
+    ├── workflow.md              # Подсказки
+    ├── basics/                  # Базовые правила: каким должен быть код
+    │   ├── tech-stack.md
+    │   ├── architecture/
+    │   ├── code-style.md
+    │   ├── naming.md
+    │   ├── documentation.md
+    │   └── typing.md
+    ├── creating-project/        # Создание проекта: как поднять новый проект
+    │   ├── from-template.md
+    │   ├── manual.md
+    │   └── nextjs.md
+    ├── setup/                   # Настройка: разовая настройка инструментов
+    │   ├── aliases.md
+    │   ├── biome.md
+    │   ├── postcss.md
    │   ├── styles.md
-│       ├── images-sprites.md
    │   ├── svg-sprites.md
-│       ├── video.md
-│       ├── api.md
-│       ├── stores.md
-│       ├── hooks.md
-│       ├── fonts.md
-│       └── localization.md
-├── en/                          # Английская версия (зеркало ru/)
+    │   ├── templates.md
+    │   └── vscode.md
+    └── usage/                   # Использование: повседневная работа
+        ├── project-structure.md
+        ├── components.md
+        ├── page-level.md
+        ├── templates-generation.md
+        ├── styles.md
+        ├── images-sprites.md
+        ├── svg-sprites.md
+        ├── video.md
+        ├── data/
+        ├── stores.md
+        ├── hooks.md
+        ├── fonts.md
+        └── localization.md
 .vitepress/
-├── config.ts                    # Конфигурация VitePress, сайдбары, локали
-generated/
-├── ru/llms.txt                  # Карта документации для LLM (ru, llmstxt.org)
-└── en/llms.txt                  # Карта документации для LLM (en, llmstxt.org)
+└── config.ts                    # Конфигурация VitePress, сайдбар
 generate-llms.ts                 # Скрипт генерации llms.txt и README
 ```

+Сгенерированные артефакты (`docs/public/`): `llms.txt`, `llms-full.txt`,
+`nextjs-style-guide.zip`, `manifest.json`, копии `.md` в `docs/public/docs/`.
+
 ### Добавление нового раздела

-1. Создать `.md`-файл в нужной папке (`basics/` или `applied/`).
-2. Добавить пункт в сайдбар — `.vitepress/config.ts` (оба языка, если есть перевод).
+1. Создать `.md`-файл в нужной папке: `basics/`, `creating-project/`,
+   `setup/` или `usage/`.
+2. Добавить пункт в сайдбар — `.vitepress/config.ts`.
   Сайдбар — единственный источник порядка и группировки для `llms.txt`.
-3. Запустить `npm run llms` для обновления `generated/{lang}/llms.txt`.
+3. Запустить `npm run llms` для обновления `llms.txt` и README.

-## Два типа документации
+## Типы разделов

-### Базовые правила
+Документация разделена на четыре группы. Каждая отвечает на свой вопрос
+и имеет свою природу — это влияет на содержимое и структуру страницы.
+
+### Базовые правила (`basics/`)

 **Отвечает на вопрос:** «Каким должен быть любой код?»

 Универсальные стандарты, **не привязанные к конкретной области**.
-Правило базовое, если оно применимо ко всему коду одинаково: именование переменных, оформление импортов, когда использовать `type` vs `interface`.
+Правило базовое, если оно применимо ко всему коду одинаково: именование
+переменных, оформление импортов, когда использовать `type` vs `interface`.

-Примеры в базовых правилах допускаются, но служат иллюстрацией принципа, а не инструкцией по конкретной области.
+Примеры в базовых правилах допускаются, но служат иллюстрацией принципа,
+а не инструкцией по конкретной области.

-**Граница:** если правило касается только одной области (только стили, только компоненты, только API) — оно живёт в прикладном разделе, не в базовых.
+**Граница:** если правило касается только одной области (только стили,
+только компоненты, только API) — оно живёт в прикладном разделе, не в базовых.

-### Прикладные разделы
+### Создание проекта (`creating-project/`)

-**Отвечает на вопрос:** «Как работать с X?»
+**Отвечает на вопрос:** «Как поднять новый проект?»

-Полное описание конкретной области: структура файлов, правила, именование, типизация, примеры.
+Сценарии запуска нового проекта целиком: из шаблона, вручную, чистая
+установка фреймворка. Раздел описывает порядок шагов на уровне всего
+проекта; детали отдельных инструментов лежат в `setup/`.

-**Граница:** прикладной раздел не дублирует базовые правила.
-Если правило уже описано в базовых — прикладной раздел ссылается на него, но не повторяет.
+**Граница:** не дублирует разделы `setup/`. Ссылается на них как на
+шаги в общем сценарии.
+
+### Настройка (`setup/`)
+
+**Отвечает на вопрос:** «Как поставить и сконфигурировать инструмент
+в новом проекте?»
+
+Разовая установка отдельного инструмента или подсистемы (линтер,
+CSS-процессор, генератор спрайтов, шаблоны). Каждый раздел —
+самостоятельная подсистема. Выполняется один раз при заведении
+проекта или при смене мажорной версии инструмента.
+
+Типичная структура `setup/`-страницы: требования → установка (шаги) →
+конфиг → проверка.
+
+**Граница:** `setup/` — про настройку, `usage/` — про написание кода
+с использованием уже настроенного инструмента.
+
+### Использование (`usage/`)
+
+**Отвечает на вопрос:** «Как этим пользоваться в коде?»
+
+Повседневная работа: как писать компоненты, стили, как получать данные,
+как работать со сторами, локализацией, ассетами. Полное описание
+конкретной области: структура файлов, правила, именование, типизация, примеры.
+
+Шаблон страницы описан ниже в секции «Структура прикладного раздела».
+
+**Граница:** прикладной раздел не дублирует базовые правила. Если правило
+уже описано в `basics/` — прикладной раздел ссылается на него, но не
+повторяет.

 ## Структура прикладного раздела

-Шаблон ниже описывает все допустимые секции. Раздел включает только те секции, которые для него релевантны — пустые секции не создаются.
+Шаблон ниже относится к разделам `usage/` (повседневная работа).
+Разделы `setup/` и `creating-project/` имеют другую структуру —
+ориентированную на пошаговую установку (требования → установка →
+проверка).
+
+Шаблон описывает все допустимые секции. Раздел включает только те,
+которые для него релевантны — пустые секции не создаются.

 ```markdown
 # {Название}

-Краткое описание: о чём раздел и какие аспекты работы с областью он охватывает.
+{Одно-два предложения, по которым читатель за секунду решает, нужен ли ему раздел.
+Правила оформления — секция «Заголовок и описание» ниже.}

 ## Что нужно знать

@@ -172,19 +229,152 @@ generate-llms.ts                 # Скрипт генерации llms.txt и R
 ```yaml
 ---
 title: Название раздела
+description: Описание раздела одним предложением.
 ---
 ```

-Значение `title` совпадает с текстом `h1`-заголовка в файле.
+- `title` совпадает с текстом `h1`-заголовка в файле.
+- `description` совпадает с абзацем-описанием сразу под `h1`.

-### Заголовки
+Подробнее о требованиях к самому заголовку и описанию — секция
+«Заголовок и описание» ниже.

- Один `h1` на файл — совпадает с `title` из frontmatter.
- Сразу после `h1` — вводный абзац (одно-два предложения).
+### Заголовок и описание
+
+Каждая страница начинается с `h1`-заголовка и абзаца-описания сразу под ним.
+Эта пара — **навигационный маркер**: попадает в сайдбар, `llms.txt`,
+`MAP.md` архива и должна за секунду давать читателю или LLM понять,
+**когда сюда нужно идти**.
+
+#### Структура заголовков
+
+- Один `h1` на файл, совпадает с `title` во frontmatter.
+- Сразу после `h1` — описание (одно-два предложения, см. ниже).
 - Основные секции — `h2`.
 - Подсекции внутри `h2` — `h3`.
 - `h4` не используется.

+#### Имя `h1` (заголовок страницы)
+
+- Называет предметную область, а не реализацию.
+- Без имён пакетов, опций, конфигов и путей.
+- Самодостаточен — читается без контекста сайдбара.
+- Исключение: имя инструмента допустимо, если оно — единственное
+  устойчивое имя самой области (`PostCSS`, `Biome`, `VS Code`).
+- Если страница вложена в семантическую группу
+  (`Архитектура → Слои`, `Данные → REST → Серверные компоненты`)
+  и короткое имя теряет смысл при прямой ссылке — `h1` поднимает
+  имя родителя в заголовок: `Слои SLM`, `Сегменты SLM`. В сайдбаре
+  допустимо оставить короткий вариант (`Слои`, `Сегменты`) — там
+  путь группы виден через дерево.
+- Подъём в заголовок применяется только когда читается грамматически
+  естественно (`Слои SLM`, `Автогенерация REST-клиента`). Если
+  получается натянутая конструкция (`REST в серверных компонентах`) —
+  заголовок остаётся коротким, а контекст полностью переносится
+  в описание. Заголовок и описание — пара: если один не несёт
+  контекст, его обязательно несёт второй.
+
+**Хорошо:** «Алиасы импортов», «Структура проекта», «SVG-спрайты»,
+«Слои SLM», «Автогенерация REST-клиента».
+
+**Плохо:** «Установка и настройка» (что устанавливаем?),
+«Использование» (что используем?), «Введение» (во что?),
+«Сегменты» (чего сегменты?), «REST в серверных компонентах»
+(грамматически натянуто — лучше короткий h1 + контекст в описании).
+
+#### Описание
+
+Описание — короткий ответ на вопрос «у меня задача X, мне сюда?».
+Не аннотация. Не оглавление.
+
+**Запреты:**
+
+- Не упоминать конкретные пакеты, библиотеки, инструменты
+  (`@gromlab/svg-sprites`, `Mantine`, `Zustand`).
+- Не упоминать конкретные файлы и пути
+  (`postcss.config.mjs`, `.templates/`, `biome.json`).
+- Не упоминать конкретные опции, ключи API, имена функций
+  (`baseUrl`, `cl()`, `useStore`).
+- Не начинать с «Раздел описывает», «Этот раздел»,
+  «В этом разделе», «Здесь рассмотрено».
+- Не использовать дежурные префиксы как шаблон
+  («Правила работы с...», «Правила написания...») — само то,
+  что раздел про правила, и так понятно из секции и заголовка.
+- Не пересказывать содержимое перечислением подсекций
+  («организация, реализация, делегирование, метаданные»).
+- Не аргументировать пользу
+  («обеспечит единообразие», «упростит поддержку»).
+
+**Требования:**
+
+- 1 предложение, обычно 5–12 слов.
+- Звучит как ответ человека другу, а не как техспек.
+- Описание читается **самостоятельно**, без контекста сайдбара.
+- Если страница вложена в семантическую группу
+  (например, `Данные → REST → Клиенты → ...`) и её заголовок
+  без этой группы теряет смысл — описание явно содержит имя
+  родительской области, чтобы читалось без сайдбара.
+
+**Подходящие формы:**
+
+- «Как X.»
+- «Что такое X.»
+- «Из чего состоит X.»
+- «Установка X.»
+- «Какие X есть и как ими пользоваться.»
+
+Перечисление аспектов через двоеточие — только если без него читатель
+не сможет различить раздел от соседнего.
+
+**Тест навигации.** Читатель видит описание — за секунду должен понять
+«мне сюда» или «нет, не сюда». Если приходится перечитывать —
+описание слишком длинное.
+
+**Тест на изменение.** Если в разделе сменится пакет, переименуется
+файл или добавится правило — придётся ли править описание?
+Если да — оно слишком конкретное.
+
+**Хорошо:**
+
+```markdown
+Какие алиасы импортов есть в проекте и как ими пользоваться.
+```
+
+```markdown
+Установка и настройка линтера-форматтера в новом проекте.
+```
+
+```markdown
+Из чего состоит проект и где что лежит.
+```
+
+```markdown
+Получение REST-данных в серверных компонентах.
+```
+
+**Плохо:**
+
+```markdown
+Раздел описывает, какие алиасы используются в проекте: их полный список,
+где они объявлены и как ими пользоваться между модулями и внутри модуля.
+```
+
+_Начинается с «Раздел описывает», пересказывает содержимое._
+
+```markdown
+Установка и настройка CSS-процессора PostCSS в проекте: набор плагинов,
+конфиг `postcss.config.mjs`. Выполняется один раз при заведении проекта.
+```
+
+_Упомянут конкретный файл, перечисление аспектов превратилось в оглавление._
+
+```markdown
+Правила работы с React-компонентами: файловая структура,
+типизация пропсов, документирование, реализация.
+```
+
+_Дежурный префикс «Правила работы с...» плюс оглавление подсекций._
+
 ### Примеры кода

 - Блоки кода с указанием языка: ` ```tsx `, ` ```css `, ` ```bash `, ` ```text `.
--- a/42
+++ b/42
@@ -1,10 +1,44 @@
 :8080 {
 	root * /srv

-	# Кириллица в .txt и .md ломается без явного charset
-	@text path *.txt *.md
-	header @text Content-Type "text/plain; charset=utf-8"
+	# Устаревшие пути llms.txt в подпапках → корень.
+	# Без этого опечатка `/docs/llms.txt` уходит в SPA-фолбэк и
+	# отдаёт HTML под видом text/plain — агент верит, что получил llms.txt.
+	redir /docs/llms.txt /llms.txt 301
+	redir /docs/llms-full.txt /llms-full.txt 301
+
+	# Чистые URL: запросы вида `/docs/foo.html` редиректим на `/docs/foo`.
+	# Канон сайта — без `.html` (cleanUrls в VitePress).
+	# Не трогаем index.html в корне — он не имеет смысловой пары без расширения.
+	@legacyHtml {
+		path_regexp legacyHtml ^(/.+)\.html$
+		not path /index.html
+	}
+	redir @legacyHtml {re.legacyHtml.1} 301
+
+	# Подсказка агентам, где лежит карта документации (RFC 8288).
+	# Позволяет найти llms.txt без парсинга DOM — по HTTP-заголовку.
+	header Link "</llms.txt>; rel=\"llms\""
+
+	# Кириллица в .txt/.md ломается без явного charset.
+	# Применяем заголовок только к РЕАЛЬНО существующим файлам,
+	# иначе SPA-фолбэк (HTML) уезжает с Content-Type: text/plain.
+	@existingText {
+		path *.txt *.md
+		file
+	}
+	header @existingText Content-Type "text/plain; charset=utf-8"
+
+	# Несуществующие .txt/.md → 404, не HTML-фолбэк.
+	# Это критично для llms.txt: агент должен получить честный 404,
+	# а не валидный «как бы текст» с лендингом внутри.
+	@missingText {
+		path *.txt *.md
+		not file
+	}
+	respond @missingText 404

 	file_server
-	try_files {path} /index.html
+	# cleanUrls: пробуем точное совпадение → +.html → каталог → SPA-фолбэк.
+	try_files {path} {path}.html {path}/ /index.html
 }
--- a/2
+++ b/2
@@ -1,6 +1,6 @@
 FROM node:24-alpine AS build
 WORKDIR /app
-# zip нужен для упаковки nextjs-style-guide-{lang}.zip
+# zip нужен для упаковки nextjs-style-guide.zip
 RUN apk add --no-cache zip
 COPY package*.json ./
 RUN npm ci
--- a/OLD_parts/1-assistent.md
+++ b/OLD_parts/1-assistent.md
@@ -1,19 +0,0 @@
-# Ассистент
-
-## Для ассистента
-
- Всегда используй Русский язык для общения и генерации документации/комментариев/коммитов.
- Всегда следуй этим правилам при генерации кода и ответах.
- Всегда пиши план действий перед генерацией кода.
- Всегда спрашивай разрешения у пользователя перед генерацией кода.
- Всегда проверяй, что код соответствует линтингу и форматированию.
- Всегда сверяйся с чек-листом при генерации кода.
- Не предлагай решения, которые противоречат этим правилам этого файла.
- Если не уверен — уточни у пользователя, не гадай, не придумывай.
-
-## Обязательность чек-листов
-
- Все чек-листы, приведённые в правилах, обязательны к исполнению.
- Ассистент обязан сверяться с чек-листом при выполнении любой задачи, связанной с кодом.
- Нельзя сокращать, игнорировать или опускать пункты чек-листа — каждый пункт должен быть выполнен или явно отмечен как невыполнимый с объяснением причины.
- В каждом ответе, связанном с генерацией или изменением кода, ассистент обязан ссылаться на соответствующий чек-лист и подтверждать его выполнение.
--- a/OLD_parts/10-stores.md
+++ b/OLD_parts/10-stores.md
@@ -1,84 +0,0 @@
---
-title: Stores
---
-
-# Stores
-
-## Сторы (Stores)
-
-> В этом разделе собраны основные правила и рекомендации по созданию и оформлению сторов. Следуйте этим принципам, чтобы обеспечить чистую архитектуру, удобство поддержки и единый стиль работы с состоянием в проекте.
-> В проекте для организации состояния используется только библиотека Zustand. 
-
-### Структура
- Store размещается в файле `<store-name>.store.ts` в папке `stores/` на своём уровне абстракции согласно архитектуре проекта.
- Интерфейс состояния описывается в этом же файле с суффиксом `State` (PascalCase).
- Для каждого store создаётся отдельный хук доступа (например, `useTodoStore`).
- Для глобальных сторов используйте только `shared/store`.
-
-### Именование
- Соблюдайте [правила именования файлов и папок](#правила-именования-файлов-и-папок):
- Файл store — `<store-name>.store.ts` (kebab-case).
- Имя интерфейса состояния — PascalCase с суффиксом `State`.
- Имя хука — camelCase с префиксом `use`.
-
-### Требования
- В store допускается только хранение состояния и методы управления им, без бизнес-логики, асинхронных операций и side-effects (см. раздел "Правила организации и использовалья Store").
- Для методов, изменяющих состояние через set, если используется функция — тело функции в фигурных скобках, return с новой строки после стрелки.
- Не дублируйте логику между сторами.
-
-### Типизация
- Всегда указывайте типы для всех полей состояния и методов.
- Не используйте неявное приведение типов и не полагайтесь на автоматический вывод, если это может снизить читаемость или безопасность.
-
-### Документирование
- Документируйте только назначение store и смысл полей, строго по [правилам документирования кода](#правило-для-документирования-кода).
-
-### Экспорт
- Экспортируйте хук доступа к store и интерфейс состояния через `index.ts` слоя/компонента.
-
-### Примеры
-
-```ts
-import { create } from 'zustand';
-import { TodoItem } from './types/todo-item.interface';
-
-/**
- * Состояние хранилища задач.
- */
-export interface TodoStoreState {
-  /** Массив задач. */
-  items: TodoItem[];
-  /** Добавить задачу. */
-  addTodo: (item: TodoItem) => void;
-  /** Удалить задачу. */
-  removeTodo: (id: string) => void;
-}
-
-/**
- * Хук для доступа к хранилищу задач.
- */
-export const useTodoStore = create<TodoStoreState>((set) => ({
-  items: [],
-  addTodo: (item) => set((state) => {
-    return {
-      items: [...state.items, item],
-    };
-  }),
-  removeTodo: (id) => set((state) => {
-    return {
-      items: state.items.filter((t) => t.id !== id),
-    };
-  }),
-}));
-```
-
-### Чек-лист
-
- [ ] Store размещён в `stores/<store-name>.store.ts` на своём уровне абстракции согласно архитектуре проекта.
- [ ] Именование файлов и сущностей соответствует [правилам именования файлов и папок](#правила-именования-файлов-и-папок).
- [ ] Все поля и методы строго типизированы (см. [общие правила типизации](#общие-правила-типизации)).
- [ ] В store только состояние и методы управления им, без бизнес-логики и side-effects.
- [ ] Для методов, изменяющих состояние через set, используется функция с return с новой строки.
- [ ] Документировано только назначение store и смысл полей (см. [правила документирования кода](#правило-для-документирования-кода)).
- [ ] Нет неиспользуемого или невалидного кода.
- [ ] Экспорт через индексный файл. 
--- a/OLD_parts/11-css.md
+++ b/OLD_parts/11-css.md
@@ -1,227 +0,0 @@
---
-title: CSS
---
-
-# CSS
-
-## Правила оформления и стилизации CSS-кода
-
- **Препроцессоры**  
-  Используй PostCSS и модули для стилизации.
-
- **Архитектура написания стилей**  
-  Используй подход **Mobile First**  
-  Используй CSS переменные для стилизации.  
-  Используй Custom Media Queries для адаптивных стилей.  
-  Используй BEM для именования классов.  
-  Между каждым CSS-правилом (селектором) должен быть один пустой сброс строки, пример:
-  ```css
-  .todo-list {
-    max-width: 600px;
-    padding: var(--space-3);
-
-    @media (--md) {
-      max-width: 800px;
-    }
-  }
-
-  .todo-list__text {
-    font-size: 18px;
-
-    @media (--md) {
-      font-size: 22px;
-    }
-  }
-  ```
-  Запрещено писать правила подряд без пустой строки:
-  ```css
-  /* Так делать нельзя! */
-  .todo-list { ... }
-  .todo-list__text { ... }
-  ```
-
- **Методология именования классов**  
-  Использовать методологию **BEM** для именования классов.
-    - Блок: kebab-case, пример `.user-bar { }`
-    - Елемент: kebab-case, соеденный с блоком двойным нижним подчеркиванием, пример `.user-bar__slide { }`
-    - Модификатор: kebab-case, отдельный самостоятельный класс, **не соединяется** с блоком/елементом, имя модификатора всегда начинается с нижнего подчеркивания, пример: `._red { }`
-
- **Единицы измерения**  
-  Используй `px` как основная единица измирения, так-же допускается использовать остальные единицы измерения если того требует реализуемый дизайн.
-
- **Импорт стилей**  
-  Стили компонента должны импортироваться только внутри соответствующего компонента.  
-  Запрещено импортировать стили одного компонента в другой.
-  Запрещено импортировать `css переменные` в файлы стилей, они доступны глобально.
-  Запрещено импортировать `custom media` в файлы стилей, они доступны глобально.
-
- **Переменные**  
-  Все значения переменных нужно писать в `/shared/styles` или в Mantine ThemeProvider. 
-  Все что не является цветами, брекпоинтами, отступами, скруглением допускаются использоваться в компонентах.
-  Обязательное создавай CSS перменные для:
-   - "Цветов", пример: `--color-danger: red;`.  
-   - "Брекпоинты", описываем в (Сustom media) пример: `@custom-media --md (min-width: 62em);`.
-   - "Отспупы (--space)", , пример: `--space-1: 4px;`, `--space-2: 8px;`, `--space-3: 12px;` итд.. 
-   - "Скругление углов (--radius)", пример: `--radius-1: 4px;`,`--radius-2: 8px;`,`--radius-3: 12px;` итд..  
-
- **Вложенность селекторов**
-  Запрещено использовать вложенность селекторов.
-  Разрешено использовать вложенность только для:
-    - Псевдо-классов `:hover`, `:active` итд..
-    - Псевдо-елементов `::before`, `::after`
-    - Медиа запросов `@media`
-    - Классы **модификаторы** по методологии BEM
-  Каждый вложенный селектор отделяется 1 пустой строкой.
-
- **Медиа запросы**  
-  Строго запрещено использовать `@media` без вложения в селектор.  
-  Строго запрещено использовать в теле `@media` любые селекторы.  
-  Разрешено использовать только Custom Media Queries (например, `@media (--md) {}`).  
-  Запрещено использовать любые произвольные значения breakpoints (например, max-width: 768px).  
-  **Пример как правильно писать @media**
-  ```css
-  .todo-list {
-    max-width: 600px;
-    padding: 24px;
-
-    @media (--md) {
-      max-width: 800px;
-    }
-  }
-
-  .todo-list__text {
-    font-size: 18px;
-
-    @media (--md) {
-      font-size: 22px;
-    }
-  }
-  
-  ```
-  **Пример как неправильно писать @media**
-  ```css
-  // Медиа запрос не вложен в селектор
-  @media (--md) {
-    .todo-list {
-      max-width: 600px;
-      padding: 24px;
-    }
-    .todo-list__text {
-      font-size: 18px;
-    }
-  }
-  // Используется стандартный `min-width: 992px` вмето Custom Media Queries
-  @media (min-width: 992px) {
-    // Внутри @media запроса используются селекторы
-    .todo-list {
-      max-width: 600px;
-      padding: 24px;
-    }
-    .todo-list__text {
-      font-size: 18px;
-    }
-  }
-  ```
-
- **Глобальные стили и сбросы**  
-  Все глобальные стили (например, сбросы) должны располагаться в отдельном файле, например, `src/app/styles/global.css`.  
-
- **Использование Mantine и PostCSS**  
-  Для стандартных визуальных компонентов (кнопки, инпуты, layout, grid, notifications и т.д.) использовать только Mantine и его ThemeProvider.
-  Запрещено использовать в Mantine компонентах его props/styling, вмето этого нужно добавлять кастомные стили PostCSS.
-  Кастомные стили допускаются только в случае, если требуемый дизайн невозможно реализовать средствами Mantine.  
-  При написании кастомных стилей стараться использовать переменные и токены Mantine, если это возможно.
-
- **Порядок CSS-свойств**  
-  В стилях рекомендуется придерживаться логического порядка свойств:  
-  1. Позиционирование (position, top, left, z-index и т.д.)  
-  2. Блочная модель (display, width, height, margin, padding и т.д.)  
-  3. Оформление (background, border, box-shadow и т.д.)  
-  4. Текст (font, color, text-align и т.д.)  
-  5. Прочее (transition, animation и т.д.)
-
- **Комментарии**  
-  В стилях запрещено использовать комментарии.
-
- **Дублирования**  
-  Не дублировать стили между компонентами. Общие стили выносить в shared/styles или использовать переменные.
-
- **Примеры кода стилей**
-  Пример как хорошо:
-  ```css
-  /* Блок BEM */
-  .user-bar {
-    display: none;
-    color: black;
-
-    /* Медиа запрос custom media и отделяется 1 пустой строкой */
-    @media (--md) {
-      display: flex;
-    }
-  }
-
-  /* Елемент BEM отделяется 1 пустой строкой*/
-  .user-bar__button-next {
-    background-color: #f0f0f0;
-
-    /* Псевдо-класс отделяется 1 пустой строкой*/
-    &:hover {
-      background-color: #e0e0e0;
-    }
-
-    /* Модификатор BEM отделяется 1 пустой строкой*/
-    &._blue {
-      background-color: #2b2bbe;
-    }
-
-    /* Модификатор BEM отделяется 1 пустой строкой*/
-    &._green {
-      background-color: #29c53d;
-    }
-  }
-  ```
-  Пример как плохо писать:
-  ```css
-  .user-bar {
-    display: none;
-    color: black;
-    &__button {
-      &_next {
-        background-color: #f0f0f0;
-        &:hover {
-          background-color: #e0e0e0;
-        }
-        &._blue {
-          background-color: #2b2bbe;
-        }
-        &._green {
-          background-color: #29c53d;
-        }
-      }
-    } 
-  }
-  @media (min-width: 992px) {
-    .user-bar {
-      display: flex;
-    }
-  }
-  ```
-
-**Чек лист для проверки стилизации.**
- [ ] Используется PostCSS и CSS-модули для стилизации.
- [ ] Применён подход Mobile First.
- [ ] Именование классов строго по BEM:
-  - [ ] Модификатор — отдельный класс, начинается с нижнего подчёркивания (например, `._red`, `._active`)
- [ ] Все CSS-переменные (цвета, брейкпоинты, отступы, скругления) определены только в `/shared/styles` или через Mantine ThemeProvider.
- [ ] Для медиа-запросов используются только custom media переменные из `/shared/styles/media.css`.
- [ ] Соблюдается правила вложености селекторов.
- [ ] Соблюдается правила отступов селекторов.
- [ ] Глобальные стили (reset) вынесены в отдельный файл, остальные стили — модульные.
- [ ] Для стандартных UI-элементов используются только компоненты Mantine, кастомные стили — только при необходимости.
- [ ] В Mantine-компонентах не используются props/styling для стилизации, только PostCSS.
- [ ] Кастомные стили используют переменные и токены Mantine, если это возможно.
- [ ] В стилях нет комментариев.
- [ ] Стили компонента импортируются только внутри соответствующего компонента.
- [ ] Нет импорта стилей одного компонента в другой.
- [ ] Нет импорта файлов переменных и custom media — они доступны глобально.
- [ ] Нет дублирования стилей между компонентами, общие стили вынесены в shared/styles или используются переменные. 
--- a/OLD_parts/12-components.md
+++ b/OLD_parts/12-components.md
@@ -1,88 +0,0 @@
---
-title: Компоненты
---
-
-# Компоненты
-
-## Правила создания и работы с компонентами.
-
-### 1. Структура компонента
-Ассистент при создании/рефакторинге компонента должен **строго** придерживаться следующей структуры файлов и папок: 
-
-```
-component-name/
-  index.ts
-  component-name.tsx
-  styles/
-    component-name.module.css 
-  locales/
-    ru.json
-    en.json
-  types/
-    component-name.interface.ts
-    component-name.type.ts
-    component-name.enum.ts
-  schemas/
-    schema-name.schema.ts
-  utils/
-    util-name.util.ts
-  hooks/
-    use-hook-name.hook.ts
-  stores/
-    store-name.store.ts
-  ui/
-    ... # вложенные компоненты для component-name
-```
-
-Пояснения к структуре компонента:
-**Обязательные файлы** обязательны для всех компонентов, даже если они пустые.
-  - component-name/: Папка компонента корень для всего компонента.
-  - index.ts: экспортирует главный компонент, интерфейс и всё, что может быть переиспользовано.
-  - component-name.tsx: главный компонент.
-  - styles/component-name.module.css: стили компонента.
-  - locales/ru.json: локализация на русском языке.
-  - locales/en.json: локализация на английском языке.
-  - types/component-name.interface.ts: интерфейс пропсов компонента.
-**Не обязательные файлы** добавляются только при необходимости
-  - types/component-name.type.ts: типы компонента.
-  - types/component-name.enum.ts: enum компонента.
-  - schemas/schema-name.schema.ts: схемы валидации.
-  - utils/util-name.util.ts: утилиты компонента.
-  - hooks/use-hook-name.hook.ts: хуки компонента.
-  - stores/store-name.store.ts: хранилища состояния компонента.
-  - ui/: Папка для вложенных компонентов.
-
-### Требования к компоненту
- Использовать `memo()` для всех компонентов, которые принимают пропсы.
- Использовать `useMemo` для всех вычислений, которые передаются в пропсы других компонентов.
- Использовать `useCallback` для всех функций/методов, которые передаются в пропсы других компонентов.
-
-### Требования к вложенным компонентам
- Вложенный компонент — это полноценный компонент, который обязан полностью соблюдать все правила, описанные для компонентов (структура, именование, документация, типизация, стилизация и т.д.).
- Все вложенные компоненты размещаются только в папке ui/ основного компонента.
-
-**Пояснение**
-Нет необходимости повторять структуру и требования — вложенный компонент подчиняется тем же правилам, что и любой другой компонент, только располагается в папке ui/ родительского компонента.
-
-### Требования к локализации
- Все добавленные локализации обязательно подключать в экземпляр `app/i18n` (чтобы новые namespace были доступны для i18next).
-
---
-
-### Чек-лист для создания нового компонента
- [ ] Главный компонент размещён в корне и назван по правилу PascalCase.
- [ ] Создан файл стилей в папке `styles/`, имя в kebab-case, используется BEM.
- [ ] Все классы применяются через `className={styles['component-name']}`.
- [ ] Создана папка `locales/` с файлами `ru.json` и `en.json`.
- [ ] Создан файл интерфейса пропсов в папке `types/`, даже если интерфейс пустой.
- [ ] Создан файл `index.ts` с экспортом главного компонента и интерфейса.
- [ ] Внутренние компоненты (если есть) размещены в папке `ui/`.
- [ ] Все важные части кода документированы по TSDoc (см. раздел 16).
- [ ] Остальные файлы (schemas, дополнительные типы, enum) добавлены только при необходимости.
- [ ] Именование файлов и папок соответствует правилам (см. выше).
- [ ] Нет неиспользуемого или невалидного кода.
- [ ] Для компонентов с пропсами используется `React.memo`.
- [ ] Для вычислений, передаваемых в пропсы, используется `useMemo`.
- [ ] Для функций, передаваемых в пропсы, используется `useCallback`.
- [ ] Все тексты вынесены в локализационные файлы и используются через i18n.
- [ ] Новые namespace подключены в экземпляр i18n. 
--- a/OLD_parts/13-hooks.md
+++ b/OLD_parts/13-hooks.md
@@ -1,68 +0,0 @@
-# Хуки (React Hooks)
-
-> В проекте для создания пользовательских хуков используется только React (функциональные компоненты и хуки).  
-> В этом разделе собраны основные правила и рекомендации по созданию и оформлению хуков. Следуйте этим принципам, чтобы обеспечить чистую архитектуру, переиспользуемость и единый стиль работы с хуками в проекте.
-
-## Рекомендации по использованию сторонних хуков
- Если есть возможность, используйте хуки Mantine в компонентах и кастомных хуках для работы с состоянием, темизацией, медиа-запросами и другими возможностями библиотеки.
- Не дублируйте функциональность, уже реализованную в Mantine.
-
-## Структура
- Каждый хук размещается в отдельном файле с именем `use-<hook-name>.hook.ts` в папке `hooks/` на своём уровне абстракции согласно архитектуре проекта.
- Имя хука — в стиле camelCase с префиксом `use` (например, `useTodoFilter`).
- Для сложных возвращаемых структур использовать отдельные типы или интерфейсы, размещая их в папке `types/` на своём уровне абстракции.
-
-## Именование
- Соблюдайте [правила именования файлов и папок](#правила-именования-файлов-и-папок):
-  - Файл хука — `use-<hook-name>.hook.ts` (kebab-case).
-  - Имя хука — camelCase с префиксом `use`.
-
-## Требования
- Хук должен быть строго типизирован: все параметры, возвращаемые значения и внутренние переменные должны иметь явные типы.
- Не хранить бизнес-логику, связанную с несколькими слоями — хук должен быть изолирован в рамках своего слоя/feature.
- Не дублировать логику между хуками — общие части выносить в shared.
- Не использовать side-effects вне useEffect/useLayoutEffect.
- Для мемоизации возвращаемых значений и функций использовать useMemo и useCallback.
- Не использовать устаревшие или неразрешённые паттерны React.
-
-## Типизация
- Всегда явно указывать типы для всех параметров, возвращаемых значений и состояния внутри хука.
- Не используйте неявное приведение типов и не полагайтесь на автоматический вывод, если это может снизить читаемость или безопасность.
-
-## Документирование
- Документируйте только назначение хука (описание), строго по [правилам документирования кода](#правило-для-документирования-кода).
-
-## Экспорт
- Экспортируйте хук только именованным экспортом через `index.ts` слоя/компонента.
-
-## Примеры
-
-```ts
-import { useMemo } from 'react';
-import { TodoItem } from '../types/todo-item.interface';
-import { TodoStatus } from '../types/todo-status.enum';
-
-/**
- * Хук фильтрации задач по статусу.
- */
-export const useTodoFilter = (items: TodoItem[], filter: TodoStatus): TodoItem[] => {
-  return useMemo(() => {
-    if (filter === TodoStatus.ALL) return items;
-    if (filter === TodoStatus.ACTIVE) return items.filter((t) => !t.completed);
-    return items.filter((t) => t.completed);
-  }, [items, filter]);
-};
-```
-
-## Чек-лист
-
- [ ] Хук размещён в файле `use-<hook-name>.hook.ts` в папке `hooks/` на своём уровне абстракции согласно архитектуре проекта.
- [ ] Именование файлов и сущностей соответствует [правилам именования файлов и папок](#правила-именования-файлов-и-папок).
- [ ] Все параметры, возвращаемые значения и внутренние переменные строго типизированы.
- [ ] Вся бизнес-логика изолирована в рамках слоя/feature.
- [ ] Нет дублирования логики между хуками.
- [ ] Для мемоизации используется useMemo/useCallback.
- [ ] Не используются side-effects вне useEffect/useLayoutEffect.
- [ ] Документировано только назначение хука (см. [правила документирования кода](#правило-для-документирования-кода)).
- [ ] Нет неиспользуемого или невалидного кода.
- [ ] Экспорт только именованный через индексный файл. 
--- a/OLD_parts/14-api-hooks.md
+++ b/OLD_parts/14-api-hooks.md
@@ -1,124 +0,0 @@
-# Хуки API (React Hooks)
-
-> В проекте для работы с API-хуками используется только React и библиотека SWR для получения данных (GET-запросы).  
-> В этом разделе собраны основные правила и рекомендации по созданию и оформлению хуков для работы с API. Следуйте этим принципам, чтобы обеспечить чистую архитектуру, переиспользуемость и единый стиль работы с API-хуками в проекте.
-
-## Описание и назначение API-хуков
-
-API-хуки предназначены для получения данных с сервера (GET-запросы) и используются в компонентах или других хуках.  
-В проекте для этого применяется библиотека SWR, которая обеспечивает кэширование, автоматическое обновление и удобную работу с асинхронными запросами.
-
-**Fetcher** — это функция, которую использует SWR для выполнения запроса к API. В проекте fetcher обычно экспортируется из файла клиента (например, `backendFetcher` из `shared/api/backend/client.ts`) и инкапсулирует логику обращения к конкретному API-клиенту.
-
-**API-клиент** — это отдельный модуль (папка), отвечающий за взаимодействие с конкретным внешним или внутренним API.  
-API-клиент включает:
- инициализацию экземпляра HTTP-клиента (например, Axios),
- настройку базового URL, интерцепторов и общих обработчиков ошибок,
- организацию всех сущностей и методов для работы с этим API (например, users, auth, orders и т.д.),
- экспорт всех функций, типов и fetcher через индексные файлы.
-
-Каждый API-клиент размещается в папке `src/shared/api/<client-name>/` и имеет собственную структуру согласно архитектуре проекта.
-
-## Структура
- Каждый API-хук размещается в отдельном файле с именем `use-<method-name>.hook-api.ts` в папке `hooks/api/<client-name>/` на своём уровне абстракции согласно архитектуре проекта.
- Имя хука — в стиле camelCase с префиксом `use` (например, `useGetUser`).
- Для сложных возвращаемых структур используйте отдельные типы или интерфейсы, размещая их в папке `types/` на своём уровне абстракции.
-
-## Именование
- Соблюдайте [правила именования файлов и папок](#правила-именования-файлов-и-папок):
-  - Файл хука — `use-<method-name>.hook-api.ts` (kebab-case).
-  - Имя хука — camelCase с префиксом `use`.
-
-## Требования
- Хук должен быть строго типизирован: все параметры, возвращаемые значения и внутренние переменные должны иметь явные типы.
- Для получения данных используйте только SWR.
- Не дублируйте логику между хуками — общие части выносите в shared.
- Не используйте side-effects вне useEffect/useLayoutEffect.
-
-## Типизация
- Всегда явно указывайте типы для всех параметров, возвращаемых значений и состояния внутри хука.
- Придерживайтесь [общих правил типизации проекта](#общие-правила-типизации).
- Не используйте неявное приведение типов и не полагайтесь на автоматический вывод, если это может снизить читаемость или безопасность.
-
-## Документирование
- Документируйте только назначение хука (описание), строго по [правилам документирования кода](#правило-для-документирования-кода).
-
-## Экспорт
- Экспортируйте хук только именованным экспортом через `index.ts` слоя/компонента.
-
-## Пример API хука
-
-```ts
-// use-get-me.hook-api.ts
-import useSWR from 'swr';
-import { backendFetcher } from 'shared/api/backend/client';
-import { UserDto } from 'shared/api/backend/entities/users/get-me.api';
-
-/**
- * Хук для получения информации о текущем пользователе.
- */
-export const useGetMe = () => {
-  const { data, error, isLoading } = useSWR<UserDto>('/users/me', backendFetcher);
-
-  return {
-    data,
-    error,
-    isLoading,
-  };
-};
-```
-
-### Пример использования хука в компоненте
-
-```tsx
-import React from 'react';
-import { useGetMe } from 'shared/hooks/api/backend/use-get-me.hook-api';
-
-export const UserInfo: React.FC = () => {
-  const { data, error, isLoading } = useGetMe();
-
-  if (isLoading) {
-    return <div>Загрузка...</div>;
-  }
-
-  if (error) {
-    return <div>Ошибка загрузки данных</div>;
-  }
-
-  if (!data) {
-    return <div>Нет данных о пользователе</div>;
-  }
-
-  return (
-    <div>
-      <div>Имя: {data.name}</div>
-      <div>Email: {data.email}</div>
-    </div>
-  );
-};
-```
-
-## Чек-лист для создания API-хука
-
- [ ] Для каждого GET-запроса создан отдельный хук.
- [ ] Хук размещён в `hooks/api/<client-name>/use-<method-name>.hook-api.ts` на своём уровне абстракции согласно архитектуре проекта.
- [ ] Именование файлов и сущностей соответствует [правилам именования файлов и папок](#правила-именования-файлов-и-папок).
- [ ] Используется SWR для получения данных.
- [ ] Все параметры, возвращаемые значения и внутренние переменные строго типизированы.
- [ ] Нет дублирования логики между хуками.
- [ ] Не используются side-effects вне useEffect/useLayoutEffect.
- [ ] Документировано только назначение хука (см. [правила документирования кода](#правило-для-документирования-кода)).
- [ ] Нет неиспользуемого или невалидного кода.
- [ ] Экспорт только именованный через индексный файл.
-
---
-
-## Чек-лист для использования API-хука
-
- [ ] Импортируется только нужный хук через публичные экспорты (`index.ts`).
- [ ] Использование хука строго по назначению (только для получения данных).
- [ ] Если требуется получить данные через GET-запрос в компоненте — обязательно используется соответствующий API-хук.  
-      **Запрещено вызывать GET-методы API напрямую в компонентах, только через хуки.**
- [ ] Обработка состояний загрузки, ошибки и данных реализована корректно.
- [ ] Не происходит дублирования логики, связанной с получением данных.
- [ ] Нет неиспользуемого или невалидного кода. 
--- a/OLD_parts/15-api.md
+++ b/OLD_parts/15-api.md
@@ -1,242 +0,0 @@
-# API
-
-> В этом разделе собраны основные правила и рекомендации по созданию, оформлению и использованию API-клиентов и функций для работы с сервером. Следуйте этим принципам, чтобы обеспечить единый стиль, безопасность и удобство поддержки API-слоя в проекте.
-
-## Описание и назначение API-клиента
-
-API-клиент — это модуль (папка), отвечающий за взаимодействие с конкретным внешним или внутренним API.  
-В проекте для HTTP-запросов используется только Axios.  
-API-клиент инкапсулирует:
- инициализацию экземпляра Axios,
- настройку базового URL, интерцепторов, обработчиков ошибок,
- организацию всех сущностей и методов для работы с этим API (например, users, auth, orders и т.д.),
- экспорт всех функций, типов и fetcher через индексные файлы.
-
-Каждый API-клиент размещается в папке `src/shared/api/<client-name>/` и имеет собственную структуру согласно архитектуре проекта.
-
-
-## Использование методов API
-
- Все методы API должны использоваться строго внутри блока `try...catch`.
- При вызове методов API всегда используйте полный путь, например:  
-  `await api.backend.createUser({ email, password });`
- Запрещено вызывать методы API вне блока `try...catch` даже в тестах, утилитах и других вспомогательных функциях.
-
-
-## Структура клиента
-```text
-src/shared/api/backend/
-│
-├── client.ts
-├── index.ts
-└── entities/
-    ├── users/
-    │   ├── get-me.api.ts
-    │   ├── create-user.api.ts
-    │   ├── update-user.api.ts
-    │   └── index.ts
-    ├── auth/
-    │   ├── login.api.ts
-    │   ├── register.api.ts
-    │   └── index.ts
-    └── index.ts
-```
-
-## Описание ключевых элементов
-
- **client.ts**  
-  Экземпляр Axios с настройками, интерцепторами, экспортом fetcher для SWR.
-
- **index.ts**  
-  Главная точка экспорта: экспортирует client, fetcher, все сущности и их методы.
-
- **entities/**  
-  Папка для бизнес-сущностей (например, users, auth, orders и т.д.).
-
- **`<entity>/`**  
-  Папка для отдельной сущности. Имя — в kebab-case, отражает бизнес-область (например, users, auth).
-
- **`<operation>.api.ts`**  
-  Файл для каждой операции (CRUD, спец. действия).  
-  Внутри:
-  - DTO (интерфейсы запроса/ответа)
-  - Функция, реализующая запрос через client
-
- **index.ts (внутри `<entity>`/)**  
-  Экспортирует все методы и типы этой сущности.
-
- **index.ts (внутри entities/)**  
-  Экспортирует все сущности (users, auth и т.д.).
-
-
-## Именование
-
- Соблюдайте [правила именования файлов и папок](#правила-именования-файлов-и-папок):
-  - Файл клиента — `client.ts`.
-  - Файл функции — `<operation>-<entity>.api.ts` (например, `create-user.api.ts`).
-  - DTO — в папке `dto/` (например, `create-user.dto.ts`).
-  - Все функции и типы экспортируются через индексные файлы на каждом уровне (сущность, entities, клиент).
-
-
-## Требования
-
- Для каждого действия (CRUD, спец. действия) — отдельная функция и файл.
- Все функции используют общий экземпляр Axios из `client.ts`.
- Все функции строго типизированы (используются DTO).
- DTO объявляется в отдельном файле в папке `dto/` перед функцией, которая его использует.
- Для каждого GET метода обязательно должен быть создан API-хук.
- Все API-хуки должны создаваться строго по [документации раздела "Хуки для API"](#хуки-для-api-api-hooks).
-
-
-## Типизация
-
- Все функции и DTO строго типизированы.
- Все интерфейсы, типы и enum размещены в папке `types/` на своём уровне абстракции.
- Все DTO размещены в папке `dto/` на своём уровне абстракции.
- Придерживайтесь [общих правил типизации проекта](#общие-правила-типизации).
-
-
-## Документирование
-
- Документируйте только назначение функций и DTO.
- В описании указывается только смысл функции/типа.
-
-
-## Экспорт
-
- Все функции и типы экспортируются через индексные файлы на каждом уровне (сущность, entities, клиент).
-
-
-## Примеры
-
-### Пример клиента API
-
-```ts
-// client.ts
-import axios, { AxiosInstance } from "axios";
-export { AxiosError, isAxiosError } from 'axios';
-export type { AxiosResponse } from 'axios';
-
-/**
- * Экземпляр HTTP-клиента для работы с backend API.
- */
-export const backendHttpClient: AxiosInstance = axios.create({
-  baseURL: '/api',
-  timeout: 10000,
-});
-
-// Интерцептор запроса
-backendHttpClient.interceptors.request.use(
-  (config) => {
-    // Здесь можно добавить авторизационные заголовки или другую логику
-    return config;
-  },
-  (error) => Promise.reject(error)
-);
-
-// Интерцептор ответа
-backendHttpClient.interceptors.response.use(
-  (response) => response,
-  (error) => {
-    // Здесь можно обработать ошибки (например, показать уведомление)
-    return Promise.reject(error);
-  }
-);
-```
-
-### Пример DTO
-
-```ts
-// dto/create-user.dto.ts
-/**
- * DTO для создания пользователя.
- */
-export interface CreateUserDto {
-  /** Email пользователя. */
-  email: string;
-  /** Пароль пользователя. */
-  password: string;
-}
-```
-
-### Пример API-функции
-
-```ts
-// create-user.api.ts
-import { backendHttpClient } from '../client';
-import { CreateUserDto } from './dto/create-user.dto';
-
-/**
- * Создать пользователя.
- */
-export const createUser = (data: CreateUserDto) => backendHttpClient.post('/users', data);
-```
-
-### Пример index.ts (в папке сущности)
-
-```ts
-export * from './create-user.api';
-export * from './get-user.api';
-```
-
-### Пример использования API-функции в компоненте
-
-```tsx
-import React, { useState } from 'react';
-import { api } from 'shared/api';
-
-export const CreateUserForm: React.FC = () => {
-  const [email, setEmail] = useState('');
-  const [password, setPassword] = useState('');
-
-  const handleSubmit = async (e: React.FormEvent) => {
-    e.preventDefault();
-    try {
-      await api.backend.createUser({ email, password });
-      console.log('Пользователь создан!');
-    } catch {
-      console.log('Ошибка создания пользователя');
-    }
-  };
-
-  return (
-    <form onSubmit={handleSubmit}>
-      <input
-        type="email"
-        value={email}
-        onChange={e => setEmail(e.target.value)}
-        placeholder="Email"
-        required
-      />
-      <input
-        type="password"
-        value={password}
-        onChange={e => setPassword(e.target.value)}
-        placeholder="Пароль"
-        required
-      />
-      <button type="submit">Создать пользователя</button>
-    </form>
-  );
-};
-```
-
-
-## Чек-лист для создания клиента
- [ ] Новый клиент размещён в `src/shared/api/<client-name>/`.
- [ ] В корне клиента есть client.ts (экземпляр Axios) и index.ts (главный экспорт).
- [ ] Все бизнес-сущности размещены в entities/, каждая — в отдельной папке.
- [ ] Для каждой операции создан отдельный файл `<operation>`.api.ts с DTO и функцией.
- [ ] DTO объявлен непосредственно перед функцией.
- [ ] В каждой папке сущности есть свой index.ts для экспорта методов и типов.
- [ ] В папке entities/ есть общий index.ts для экспорта всех сущностей.
- [ ] Все экспорты организованы через индексные файлы.
- [ ] Для каждого GET-метода создан отдельный SWR-хук (см. правила API-хуков).
- [ ] Нет дублирования кода и неиспользуемых файлов.
-
-## Чек-лист для использования API
- [ ] Импортируется только нужный метод через публичные экспорты (index.ts).
- [ ] Все вызовы API обёрнуты в try...catch.
- [ ] Используются только строго типизированные методы.
- [ ] Не происходит обращения к Axios напрямую — только через client.
- [ ] Нет дублирования логики и неиспользуемого кода. 
--- a/OLD_parts/3-general-principles.md
+++ b/OLD_parts/3-general-principles.md
@@ -1,21 +0,0 @@
---
-title: Общие принципы
---
-
-# Общие принципы
-
-## Стек технологий и библиотеки
- Использовать **TypeScript** для всех файлов логики и компонентов.
- Использовать **FSD (Feature-Sliced Design)**: разделять код на features, entities, processes, widgets, shared.
- Использовать **React** (функциональные компоненты, хуки).
- Использовать **Mantine UI** для UI-компонентов.
- Использовать **Axios** в качестве клиента для работы с API.
- Использовать **SWR** для data fetching (GET-запросы).
- Использовать **Zustand** для глобального состояния.
- Использовать **i18n** для локализации.
- Использовать **Vitest** для тестирования.
- Использовать **PostCSS модули** для стилизации. 
- Использовать **BEM** для именований классов в стилях
- Использовать **Mobile First** подход для написания стилей.
- Использовать **Context7** примеров использования библиотек.
- Использовать **i18n** (i18next) для локализации всех пользовательских текстов.
--- a/OLD_parts/4-arkhitektura.md
+++ b/OLD_parts/4-arkhitektura.md
@@ -1,22 +0,0 @@
---
-title: Архитектура
---
-
-# Архитектура
-
-## Архитектура проекта
-В проекте используется FSD (Feature-Sliced Design) архитектура.  
-
- **FSD-границы**
-  - Не нарушать границы слоёв (например, feature не может импортировать из widgets).
-  - Бизнес-логика должна быть вынесена в хуки или сервисы.
- **Импорты**
-  - Внутри слоя — относительные импорты.
-  - Между слоями — абсолютные импорты.
- **Требования**
-  - Не смешивать логику разных слоёв.
-  - Не хранить бизнес-логику в UI-компонентах.
- **Именование**
-  - Файлы и папки kebab-case.
-
--- 
--- a/OLD_parts/5-code-style.md
+++ b/OLD_parts/5-code-style.md
@@ -1,74 +0,0 @@
---
-title: Стиль кода
---
-
-# Стиль кода
-
-## Отступы
-
-  Используем 2 пробела для отступов во всём проекте. Не используем табы.
-
-
-## Кавычки
-
-Используем **одинарные кавычки** для строк в JavaScript/TypeScript, и **двойные кавычки** для атрибутов в JSX/TSX.
-
-**Пример:**
-
-```ts
-// JavaScript/TypeScript
-const message = 'Привет, мир!';
-const name = 'ProjectName';
-```
-
-```tsx
-// JSX/TSX
-<input type="text" placeholder="Введите имя" />
-<button title="Сохранить">Сохранить</button>
-```
-
-## Строгая типизация
-
-всегда указывать типы для пропсов, возвращаемых значений, параметров функций.
-
-## Ранние возвраты
-
-(early return) для повышения читаемости.
-
-## Мемоизация
-
-Старайся оптимизировать код если это возможно.
-
-## Документирование
-
-Документируем ТОЛЬКО ОПИСАНИЕ (функций, компонентов, типов и их полей).
-
-## any, unknown
-
-запрещено использовать без крайней необходимости.
-
-## Классы в TSX
-
-Для стилизации компонентов используем CSS-модули и методологию BEM. Классы подключаются через объект стилей, импортированный из соответствующего `.module.css` файла.
-
-> Объект стилей всегда импортируется с именем `s` (сокращённо от style), а не `styles`.
-
-**Пример:**
-
-```tsx
-import s from './my-component.module.css';
-
-export const MyComponent = () => (
-  <div className={s['my-component']}>
-    <button className={s['my-component__button']}>Кнопка</button>
-    <span className={s['my-component__text']}>Текст</span>
-    <button className={s['my-component__button'] + ' ' + s._active}>
-      Активная кнопка
-    </button>
-  </div>
-);
-```
-
- Имя класса всегда берётся из объекта `s`.
- Для модификаторов используется отдельный класс с нижним подчёркиванием (например, `s._active`).
- Не используйте строковые литералы с классами напрямую — только через объект `s`.
--- a/OLD_parts/6-naming.md
+++ b/OLD_parts/6-naming.md
@@ -1,18 +0,0 @@
---
-title: Именование
---
-
-# Именование
-
-## Именование файлов и папок
- Папка компонента: kebab-case, совпадает с названием компонента, пример: `component-name`.
- React-компонент: kebab-case, совпадает с названием компонента, пример: `component-name.tsx`.
- Стили: kebab-case, шаблон: `<style-name>.module.css`, пример: `style-name.module.css`.
- Интерфейсы: kebab-case, шаблон: `<interface-name>.interface.ts`, пример: `interface-name.interface.ts`.
- Типы: kebab-case, шаблон: `<type-name>.type.ts`, пример: `type-name.type.ts`.
- Enum: kebab-case, шаблон: `<enum-name>.enum.ts`, пример: `enum-name.enum.ts`.
- Схемы: kebab-case, шаблон: `<schema-name>.schema.ts`, пример: `schema-name.schema.ts`.
- Локализация: kebab-case, пример: `ru.json`, `en.json`.
- Утилиты: kebab-case, шаблон: `<util-name>.util.ts`, пример: `util-name.util.ts`
- React Hooks: kebab-case, шаблон: `use-<hook-name>.hook.ts`, пример: `use-hook-name.hook.ts`
- Хранилища состояния компонента: kebab-case, шаблон: `<store-name>.store.ts`, пример: `store-name.store.ts`
--- a/OLD_parts/7-docs.md
+++ b/OLD_parts/7-docs.md
@@ -1,69 +0,0 @@
---
-title: Документирование
---
-
-# Документирование
-
-## Правило для документирования кода
-
- Документировать разрешено только описание (назначение) функций, компонентов, типов, интерфейсов, enum и их полей.
- Строго запрещено документировать параметры, возвращаемые значения, типы пропсов, аргументы, возвращаемые значения функций, компоненты, хуки и т.д.
- В интерфейсах, типах и enum разрешено документировать только смысл (описание) каждого поля или значения.
- В React-компонентах, функциях, хранилищах, схемах, утилитах разрешено документировать только назначение (описание), без детализации параметров и возвращаемых значений.
- Описание должно быть кратким, информативным и реально помогать понять структуру и бизнес-логику.
- Не допускается избыточная или дублирующая очевидное документация.
- В конце описания всегда ставить точку.
-
-**Примеры правильного документирования**
-```tsx
-/**
- * Список задач пользователя.
- */
-export const TodoList = memo(() => { ... });
-
-/**
- * Интерфейс задачи.
- */
-export interface TodoItem {
-  /** Уникальный идентификатор задачи. */
-  id: string;
-  /** Текст задачи. */
-  text: string;
-  /** Статус выполнения задачи. */
-  completed: boolean;
-}
-
-/**
- * Перечисление фильтров задач.
- */
-export enum TodoFilter {
-  /** Все задачи. */
-  All = 'all',
-  /** Только активные задачи. */
-  Active = 'active',
-  /** Только выполненные задачи. */
-  Completed = 'completed',
-}
-```
-
-**Примеры неправильного документирования**
-```ts
-// ❌ Не нужно:/
-/**
- * @param id - идентификатор задачи
- * @returns объект задачи
- */
-
-// ❌ Не нужно:/
-/**
- * @param props - пропсы компонента
- * @returns JSX.Element
- */
-
-// ❌ Не нужно:/
-/**
- * id — идентификатор задачи
- * text — текст задачи
- * completed — статус выполнения
- */
-``` 
--- a/OLD_parts/8-typing.md
+++ b/OLD_parts/8-typing.md
@@ -1,187 +0,0 @@
---
-title: Типизация
---
-
-# Типизация
-
-## Общие правила типизации
-
-> Данный раздел определяет единые требования к типизации для всего проекта. Соблюдение этих правил обеспечивает читаемость, предсказуемость и безопасность кода.
-
- Использовать только строгую типизацию TypeScript для всех файлов логики, компонентов, хуков, API, сторов и утилит.
- Всегда явно указывать типы для:
-  - Пропсов компонентов
-  - Параметров функций и методов
-  - Возвращаемых значений функций и методов
-  - Всех переменных состояния (в том числе в store)
-  - Всех значимых переменных и констант, если их тип не очевиден из присваивания
- Не использовать `any` и `unknown` без крайней необходимости. Если использование неизбежно — обязательно добавить комментарий с обоснованием.
- Все интерфейсы, типы и enum всегда размещать в папке `types/` на своём уровне абстракции (например, `features/todo/types/`).
- Для DTO всегда использовать отдельную папку `dto/` на уровне сущности или слоя.
- Для сложных структур использовать отдельные интерфейсы или типы, размещая их в соответствующих файлах в папке `types/`.
- Для DTO, enum, схем и других сущностей — всегда создавать отдельные типы/интерфейсы с осмысленными именами.
- Ключи enum всегда писать ЗАГЛАВНЫМИ_БУКВАМИ (SCREAMING_SNAKE_CASE).
- Не использовать неявное приведение типов и не полагаться на автоматический вывод, если это может снизить читаемость или безопасность.
- Для массивов и объектов всегда указывать тип элементов/ключей.
- Для возвращаемых значений асинхронных функций всегда указывать тип Promise.
- Типизацию коллбеков и функций, передаваемых в пропсы, указывать инлайн, не выносить в отдельные типы.
- Для типизации внешних библиотек использовать официальные типы или создавать собственные декларации при необходимости.
- Не использовать устаревшие или не рекомендуемые паттерны типизации (например, `Function`, `Object`, `{}`).
---
-
-### Примеры
-
-#### Интерфейс и типы для сущностей (всегда в папке types/)
-
-```ts
-// features/todo/types/todo-item.interface.ts
-
-/**
- * Интерфейс задачи.
- */
-export interface TodoItem {
-  /** Уникальный идентификатор задачи. */
-  id: string;
-  /** Текст задачи. */
-  text: string;
-  /** Статус выполнения задачи. */
-  completed: boolean;
-}
-```
-
-#### Типизация enum (всегда в папке types/)
-
-```ts
-// features/todo/types/todo-status.enum.ts
-
-/**
- * Перечисление статусов задачи.
- */
-export enum TodoStatus {
-  /** Активная задача. */
-  ACTIVE = 'active',
-  /** Выполненная задача. */
-  COMPLETED = 'completed',
-}
-```
-
-#### Типизация пропсов компонента
-
-```ts
-import { FC, memo } from 'react';
-import { TodoItem } from './types/todo-item.interface';
-
-/**
- * Список задач.
- */
-export interface TodoListProps {
-  /** Массив задач. */
-  items: TodoItem[];
-}
-
-export const TodoList: FC<TodoListProps> = memo(({ items }) => (
-  <ul>
-    {items.map((item) => (
-      <li key={item.id}>{item.text}</li>
-    ))}
-  </ul>
-));
-```
-
-#### Типизация функций и коллбеков (инлайн)
-
-```ts
-/**
- * Функция фильтрации задач.
- */
-export const getCompletedTodos = (items: TodoItem[]): TodoItem[] => {
-  return items.filter((t) => t.completed);
-};
-
-/**
- * Колбэк для обработки клика (инлайн).
- */
-const handleClick = (id: string): void => {
-  console.log('Clicked:', id);
-};
-```
-
-#### Типизация асинхронных функций
-
-```ts
-/**
- * Получить задачи с сервера.
- */
-export const fetchTodos = async (): Promise<TodoItem[]> => {
-  const response = await fetch('/api/todos');
-  return response.json();
-};
-```
-
-#### Типизация состояния в store (интерфейс в types/)
-
-```ts
-// features/todo/types/todo-store.interface.ts
-
-/**
- * Состояние хранилища задач.
- */
-export interface TodoStoreState {
-  /** Массив задач. */
-  items: TodoItem[];
-  /** Добавить задачу. */
-  addTodo: (item: TodoItem) => void;
-  /** Удалить задачу. */
-  removeTodo: (id: string) => void;
-}
-```
-
-#### Типизация DTO (всегда в папке dto/)
-
-```ts
-// features/todo/dto/create-todo.dto.ts
-
-/**
- * DTO для создания задачи.
- */
-export interface CreateTodoDto {
-  /** Текст задачи. */
-  text: string;
-}
-
-// features/todo/dto/todo-response.dto.ts
-
-/**
- * DTO ответа сервера.
- */
-export interface TodoResponseDto {
-  /** Созданная задача. */
-  todo: TodoItem;
-}
-```
-
-#### Типизация внешних библиотек
-
-```ts
-import type { AxiosResponse } from 'axios';
-
-export const getData = async (): Promise<AxiosResponse<TodoItem[]>> => {
-  // ...
-};
-```
-### Чек-лист проверки типизации
-
- [ ] Все пропсы компонентов явно типизированы через интерфейс или тип в папке `types/`.
- [ ] Все параметры и возвращаемые значения функций и методов явно типизированы.
- [ ] Все переменные состояния (в том числе в store) имеют явные типы.
- [ ] Все интерфейсы, типы и enum размещены в папке `types/` на своём уровне абстракции.
- [ ] Ключи всех enum написаны ЗАГЛАВНЫМИ_БУКВАМИ (SCREAMING_SNAKE_CASE).
- [ ] Все DTO размещены в папке `dto/` на своём уровне абстракции.
- [ ] Не используется `any` и `unknown` без крайней необходимости и поясняющего комментария.
- [ ] Для сложных структур используются отдельные интерфейсы или типы.
- [ ] Для массивов и объектов указан тип элементов/ключей.
- [ ] Для асинхронных функций указан тип Promise с конкретным типом результата.
- [ ] Типы коллбеков и функций, передаваемых в пропсы, указаны инлайн.
- [ ] Не используются устаревшие типы (`Function`, `Object`, `{}`).
- [ ] Для внешних библиотек используются официальные типы или собственные декларации.
- [ ] Нет неявного приведения типов, все типы читаемы и прозрачны. 
--- a/OLD_parts/9-localization.md
+++ b/OLD_parts/9-localization.md
@@ -1,12 +0,0 @@
---
-title: Локализация
---
-
-# Локализация
-
-## Правила использования локализации
-
- Все пользовательские тексты должны быть вынесены в локализационные файлы.
- Для каждого компонента создавать папку `locales/` с файлами `ru.json`, `en.json` и т.д.
- Новые namespace обязательно регистрировать в экземпляре i18n (см. `app/i18n.ts`).
- В коде использовать только функцию перевода из i18n, не использовать "жёстко" прописанные строки. 
--- a/README.md
+++ b/README.md
@@ -1,58 +1,94 @@
 # NextJS Style Guide

-Rules and standards for NextJS and TypeScript development: architecture, typing, styles, components, API, and infrastructure.
+Стандарты разработки фронтенд-приложений на Next.js и TypeScript.

-## Documentation Structure
+Сайт: https://nextjs-style-guide.gromlab.ru

-### Processes
+## Использование

-**What to do** in a specific situation — step-by-step instructions.
+**Для AI-агентов:**

-| Section | Answers the question |
-|---------|---------------------|
-| Getting Started | What tools to install before starting development? |
-| Creating an App | How to create a new project, where to get a template? |
-| Creating Pages | How to add a page: routing and screen? |
-| Creating Components | How to generate components using templates? |
-| Styling | What to use: Mantine, tokens, or PostCSS? |
-| Data Fetching | How to fetch data: SWR, codegen, sockets? |
-| State Management | When and how to create a store (Zustand)? |
-| Localization | How to add translations and work with i18next? |
+- [llms.txt](https://nextjs-style-guide.gromlab.ru/llms.txt) — Карта разделов, оглавление со ссылками на разделы.
+- [llms-full.txt](https://nextjs-style-guide.gromlab.ru/llms-full.txt) — Вся документация одним файлом.

-### Basic Rules
+**Для проекта:**

-**What the code should look like** — standards not tied to a specific technology.
+- [nextjs-style-guide.zip](https://nextjs-style-guide.gromlab.ru/nextjs-style-guide.zip) — Набор Markdown-файлов для распаковки в `./ai/nextjs-style-guide/` или другую папку проекта.

-| Section | Answers the question |
-|---------|---------------------|
-| Tech Stack | What stack do we use? |
-| Architecture | How are FSD layers, dependencies, and public API structured? |
-| Code Style | How to format code: indentation, quotes, imports, early return? |
-| Naming | How to name files, variables, components, hooks? |
-| Documentation | How to write JSDoc: what to document and what not? |
-| Typing | How to type: type vs interface, any/unknown? |
+## Структура документации

-### Applied Sections
+### Подсказки

-**How a specific area works** — rules, structure, and code examples for specific technologies and tools.
+[Подсказки](docs/docs/workflow.md) — короткие ответы на типовые вопросы и решения для спорных ситуаций.

-| Section | Answers the question |
-|---------|---------------------|
-| Project Structure | How are folders and files organized by FSD? |
-| Components | How is a component structured: files, props, clsx? |
-| Page-level Components | How to define layout, page, loading, error, not-found? |
-| Templates & Code Generation | How do templates work: syntax, variables, modifiers? |
-| Styles | How to write CSS: PostCSS Modules, nesting, media, tokens? |
-| Images | _(not filled)_ |
-| SVG Sprites | _(not filled)_ |
-| Video | _(not filled)_ |
-| API | _(not filled)_ |
-| Stores | _(not filled)_ |
-| Hooks | _(not filled)_ |
-| Fonts | _(not filled)_ |
-| Localization | _(not filled)_ |
+### Базовые правила

-## For Assistants
+**Каким должен быть код** — стандарты, не привязанные к конкретной технологии.

-Documentation map with links to all sections ([llmstxt.org](https://llmstxt.org) format):
-https://gromlab.ru/docs/nextjs-style-guide/raw/branch/main/generated/en/llms.txt
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Технологии и библиотеки | Какой стек используем? |
+| Именование | Как называть файлы, переменные, компоненты, хуки? |
+| SLM Design | Что такое SLM и зачем она нужна? |
+| Архитектура: Слои | Какие слои есть и как между ними устроены зависимости? |
+| Архитектура: Модули | Что такое модуль и как он устроен? |
+| Архитектура: Сегменты | Какие сегменты есть внутри модуля? |
+| Стиль кода | Как оформлять код: отступы, кавычки, импорты, early return? |
+| Документирование | Как писать JSDoc: что документировать, а что нет? |
+| Типизация | Как типизировать: type vs interface, any/unknown? |
+
+### Создание проекта
+
+**Как начать новый проект** — варианты установки и эталонный набор инструментов.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Создание проекта из шаблона | Как начать проект из готового шаблона? |
+| Создание проекта вручную | Как поднять проект с нуля без шаблона? |
+| Чистая установка Next.js | Как поставить голый Next.js под дальнейшую сборку? |
+
+### Настройка
+
+**Как сконфигурировать проект** — пошаговая настройка инструментов и инфраструктуры.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Алиасы импортов | Как настроить алиасы импортов? |
+| Biome | Как настроить линтер и форматтер? |
+| PostCSS | Какие плагины PostCSS нужны и как их настроить? |
+| Стили | Как подключить базовые стили и токены? |
+| SVG-спрайты | Как подключить генерацию SVG-спрайтов? |
+| Шаблоны генерации | Как подключить шаблоны для кодогенерации? |
+| VS Code | Как настроить редактор для проекта? |
+
+### Использование
+
+**Как это устроено и как этим пользоваться** — структура, примеры и правила для конкретных областей.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Структура проекта | Как организованы папки и файлы по SLM? |
+| Компоненты | Как устроен компонент: файлы, пропсы, clsx? |
+| Файлы роутинга | Как описывать layout, page, loading, error, not-found? |
+| Шаблоны и генерация кода | Как работают шаблоны, синтаксис и инструменты генерации? |
+| Стили | Как писать CSS: вложенность, медиа, токены? |
+| SVG-спрайты | Как использовать SVG-спрайты в коде? |
+| Изображения | _(не заполнен)_ |
+| Видео | _(не заполнен)_ |
+| Stores | _(не заполнен)_ |
+| Хуки | _(не заполнен)_ |
+| Шрифты | _(не заполнен)_ |
+| Локализация | _(не заполнен)_ |
+
+### Данные
+
+**Как работать с источниками данных** — REST, realtime и потребление в компонентах.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Источники данных | Как устроена работа с данными в проекте? |
+| REST: Автоматическая генерация | Как сгенерировать REST-клиент автоматически из OpenAPI? |
+| REST: Ручное создание | Как написать REST-клиент вручную? |
+| REST: Серверные компоненты | Как получать данные в серверных компонентах? |
+| REST: Клиентские компоненты | Как получать данные в клиентских компонентах? |
+| Realtime | Как работать с realtime-каналами и сокетами? |
--- a/README_RU.md
+++ b/README_RU.md
@@ -1,61 +0,0 @@
-# NextJS Style Guide
-
-Правила и стандарты разработки на NextJS и TypeScript: архитектура, типизация, стили, компоненты, API и инфраструктурные разделы.
-
-## Для ассистентов
-
-Карта документации со ссылками на все разделы (формат [llmstxt.org](https://llmstxt.org)):
-https://gromlab.ru/docs/nextjs-style-guide/raw/branch/main/generated/ru/llms.txt
-
-## Структура документации
-
-### Workflow
-
-**Что делать и в каком порядке** — пошаговые инструкции.
-
-| Раздел | Отвечает на вопрос |
-|--------|-------------------|
-| Начало работы | Что нужно знать перед началом разработки? |
-| Создание проекта | Как начать новый проект? |
-| Генерация кода | Какие модули должны генерироваться из шаблонов? |
-| Добавление страницы | Как добавить новую страницу в проект? |
-| Добавление UI-модуля | Как создать компонент, бизнес-модуль, виджет или layout? |
-| Стилизация | Как стилизовать компоненты в проекте? |
-| Получение данных | Как получать данные с сервера? |
-| Управление состоянием | Как работать с состоянием? |
-| Локализация | Как добавлять переводы и подключать локализацию? |
-
-### Базовые правила
-
-**Каким должен быть код** — стандарты, не привязанные к конкретной технологии.
-
-| Раздел | Отвечает на вопрос |
-|--------|-------------------|
-| Технологии и библиотеки | Какой стек используем? |
-| Архитектура | Как устроены слои SLM, зависимости, публичный API? |
-| Стиль кода | Как оформлять код: отступы, кавычки, импорты, early return? |
-| Именование | Как называть файлы, переменные, компоненты, хуки? |
-| Документирование | Как писать JSDoc: что документировать, а что нет? |
-| Типизация | Как типизировать: type vs interface, any/unknown? |
-
-### Прикладные разделы
-
-**Как это настроить и использовать** — конфигурация, структура и примеры кода для конкретных областей.
-
-| Раздел | Отвечает на вопрос |
-|--------|-------------------|
-| Настройка VS Code | Как настроить редактор для проекта? |
-| Структура проекта | Как организованы папки и файлы по SLM? |
-| Компоненты | Как устроен компонент: файлы, пропсы, clsx? |
-| Page-level компоненты | Как описывать layout, page, loading, error, not-found? |
-| Шаблоны и генерация кода | Как работают шаблоны, синтаксис и инструменты генерации? |
-| Стили | Как писать CSS: PostCSS Modules, вложенность, медиа, токены? |
-| Изображения | _(не заполнен)_ |
-| SVG-спрайты | _(не заполнен)_ |
-| Видео | _(не заполнен)_ |
-| API | _(не заполнен)_ |
-| Stores | _(не заполнен)_ |
-| Хуки | _(не заполнен)_ |
-| Шрифты | _(не заполнен)_ |
-| Локализация | _(не заполнен)_ |
-
--- a/docs-overview.md
+++ b/docs-overview.md
@@ -0,0 +1,174 @@
+# Обзор страниц документации
+
+Список всех `.md`-страниц в `docs/docs/` в порядке сайдбара (`.vitepress/config.ts`).
+Поля: путь к файлу, заголовок (`h1`), описание (абзац под заголовком).
+
+## Главная
+
+### docs/docs/index.md
+**Заголовок:** NextJS Style Guide
+**Описание:** Стандарты разработки фронтенд-приложений на Next.js и TypeScript.
+
+## Подсказки
+
+### docs/docs/workflow.md
+**Заголовок:** Подсказки
+**Описание:** Короткие ответы на типовые вопросы и решения для спорных ситуаций.
+
+## Базовые правила
+
+### docs/docs/basics/tech-stack.md
+**Заголовок:** Технологии и библиотеки
+**Описание:** Какие библиотеки и инструменты используются в проекте.
+
+### docs/docs/basics/naming.md
+**Заголовок:** Именование
+**Описание:** Как называть переменные, файлы и прочие сущности в коде.
+
+### docs/docs/basics/architecture/index.md
+**Заголовок:** SLM Design
+**Описание:** Архитектурный подход проекта: что такое SLM и как он устроен.
+
+### docs/docs/basics/architecture/reference/layers.md
+**Заголовок:** Слои SLM
+**Описание:** Из каких слоёв состоит SLM-архитектура и как они связаны.
+
+### docs/docs/basics/architecture/reference/modules.md
+**Заголовок:** Модули SLM
+**Описание:** Что такое модуль в SLM-архитектуре и как он устроен.
+
+### docs/docs/basics/architecture/reference/segments.md
+**Заголовок:** Сегменты SLM
+**Описание:** Что такое сегмент модуля в SLM-архитектуре и какие они бывают.
+
+### docs/docs/basics/code-style.md
+**Заголовок:** Стиль кода
+**Описание:** Как оформляется код в проекте.
+
+### docs/docs/basics/documentation.md
+**Заголовок:** Документирование
+**Описание:** Что и как документировать в коде.
+
+### docs/docs/basics/typing.md
+**Заголовок:** Типизация
+**Описание:** Как типизируется код в проекте.
+
+## Создание проекта
+
+### docs/docs/creating-project/from-template.md
+**Заголовок:** Создание проекта из шаблона
+**Описание:** Создание нового проекта на основе готового шаблона.
+
+### docs/docs/creating-project/manual.md
+**Заголовок:** Создание проекта вручную
+**Описание:** Поэтапное создание нового проекта без использования шаблона.
+
+### docs/docs/creating-project/nextjs.md
+**Заголовок:** Чистая установка Next.js
+**Описание:** Установка Next.js без лишнего шаблона — голый каркас под дальнейшую сборку.
+
+## Настройка
+
+### docs/docs/setup/aliases.md
+**Заголовок:** Алиасы импортов
+**Описание:** Какие алиасы импортов есть в проекте и как ими пользоваться.
+
+### docs/docs/setup/biome.md
+**Заголовок:** Biome
+**Описание:** Установка и настройка линтера-форматтера в новом проекте.
+
+### docs/docs/setup/postcss.md
+**Заголовок:** PostCSS
+**Описание:** Установка и настройка CSS-процессора в новом проекте.
+
+### docs/docs/setup/styles.md
+**Заголовок:** Стили
+**Описание:** Подготовка стилевой основы проекта: токены, медиа-запросы, глобальные стили.
+
+### docs/docs/setup/svg-sprites.md
+**Заголовок:** SVG-спрайты
+**Описание:** Подключение SVG-спрайтов в новом проекте.
+
+### docs/docs/setup/templates.md
+**Заголовок:** Шаблоны генерации
+**Описание:** Подключение шаблонов кодогенерации в новом проекте.
+
+### docs/docs/setup/vscode.md
+**Заголовок:** VS Code
+**Описание:** Единые настройки редактора и расширений для команды.
+
+## Использование
+
+### docs/docs/usage/project-structure.md
+**Заголовок:** Структура проекта
+**Описание:** Из чего состоит проект и где что лежит.
+
+### docs/docs/usage/components.md
+**Заголовок:** Компоненты
+**Описание:** Как устроен и пишется React-компонент в проекте.
+
+### docs/docs/usage/page-level.md
+**Заголовок:** Файлы роутинга
+**Описание:** Что должно лежать в файлах роутинга, а что — в экранах.
+
+### docs/docs/usage/templates-generation.md
+**Заголовок:** Шаблоны и генерация кода
+**Описание:** Как устроены шаблоны кодогенерации и как ими пользоваться.
+
+### docs/docs/usage/styles.md
+**Заголовок:** Стили
+**Описание:** Как пишутся стили в проекте.
+
+### docs/docs/usage/images-sprites.md
+**Заголовок:** —
+**Описание:** _(файл пустой)_
+
+### docs/docs/usage/svg-sprites.md
+**Заголовок:** SVG-спрайты
+**Описание:** Как добавлять и использовать SVG-иконки в коде.
+
+### docs/docs/usage/video.md
+**Заголовок:** —
+**Описание:** _(файл пустой)_
+
+### docs/docs/usage/stores.md
+**Заголовок:** —
+**Описание:** _(файл пустой)_
+
+### docs/docs/usage/hooks.md
+**Заголовок:** —
+**Описание:** _(файл пустой)_
+
+### docs/docs/usage/fonts.md
+**Заголовок:** —
+**Описание:** _(файл пустой)_
+
+### docs/docs/usage/localization.md
+**Заголовок:** —
+**Описание:** _(файл пустой)_
+
+## Данные
+
+### docs/docs/usage/data/index.md
+**Заголовок:** Источники данных
+**Описание:** Какие источники данных используются в проекте и как с ними работать.
+
+### docs/docs/usage/data/rest/clients/auto.md
+**Заголовок:** Автогенерация REST-клиента
+**Описание:** Генерация REST-клиента из OpenAPI-спецификации.
+
+### docs/docs/usage/data/rest/clients/manual.md
+**Заголовок:** Ручное создание REST-клиента
+**Описание:** Создание REST-клиента вручную, когда нет OpenAPI-спецификации.
+
+### docs/docs/usage/data/rest/fetching/server.md
+**Заголовок:** Серверные компоненты
+**Описание:** Получение REST-данных в серверных компонентах.
+
+### docs/docs/usage/data/rest/fetching/client.md
+**Заголовок:** Клиентские компоненты
+**Описание:** Получение REST-данных в клиентских компонентах.
+
+### docs/docs/usage/data/realtime.md
+**Заголовок:** Realtime
+**Описание:** Работа с push-данными от сервера: подписки и события.
--- a/docs/docs/DEVELOP.md
+++ b/docs/docs/DEVELOP.md
@@ -0,0 +1,103 @@
+---
+title: Гид для агента
+description: Что AI-агент обязан прочитать перед началом работы, а что — по задаче.
+---
+
+# Обязательное чтение перед началом работы
+
+Этот документ определяет **строгий порядок действий агента перед выполнением любых задач**.
+
+## Общее правило
+
+Перед началом работы над **любой задачей** агент **обязан ознакомиться с базовой документацией проекта**.
+
+Нарушение этого порядка считается ошибкой.
+
+---
+
+## Порядок обязательного чтения
+
+Агент должен читать документацию **строго в следующем порядке**:
+
+### 1. Архитектура (КРИТИЧЕСКИ ВАЖНО)
+
+* [Архитектура: Обзор](./basics/architecture/index.md)
+* [Архитектура: Слои](./basics/architecture/reference/layers.md)
+* [Архитектура: Модули](./basics/architecture/reference/modules.md)
+* [Архитектура: Сегменты](./basics/architecture/reference/segments.md)
+
+**Архитектура — это самое важное в проекте.**
+
+Агент обязан:
+
+* строго понимать архитектурный подход (SLM)
+* соблюдать архитектуру **на 100% без отклонений**
+* не предлагать решений, нарушающих архитектурные принципы
+* не упрощать архитектуру даже ради скорости выполнения задачи
+
+Любое нарушение архитектуры недопустимо.
+
+---
+
+### 2. Базовые правила
+
+После архитектуры необходимо изучить:
+
+* [Технологии и библиотеки](./basics/tech-stack.md)
+* [Именование](./basics/naming.md)
+* [Стиль кода](./basics/code-style.md)
+* [Документирование](./basics/documentation.md)
+* [Типизация](./basics/typing.md)
+
+Агент обязан применять эти правила во всех решениях.
+
+---
+
+## Использование карты документации
+
+Для поиска дополнительных сведений агент должен использовать:
+
+* [MAP.md](./MAP.md)
+
+MAP.md содержит ссылки на все прикладные и вспомогательные разделы.
+
+Агент может:
+
+* переходить к нужным разделам через MAP.md
+* уточнять детали реализации
+* искать примеры и частные случаи
+
+---
+
+## Запрещено
+
+Агенту запрещено:
+
+* начинать выполнение задачи без изучения архитектуры
+* игнорировать базовые правила
+* принимать решения, противоречащие архитектуре
+* придумывать собственные подходы, если они не описаны в документации
+
+---
+
+## Ожидаемое поведение агента
+
+Перед выполнением задачи агент должен:
+
+1. Изучить архитектуру
+2. Изучить базовые правила
+3. При необходимости открыть MAP.md и найти релевантные разделы
+4. Только после этого приступать к решению задачи
+
+---
+
+## Приоритеты
+
+При принятии решений агент должен руководствоваться следующим приоритетом:
+
+1. **Архитектура**
+2. Базовые правила
+3. Документация из MAP.md
+4. Задача пользователя
+
+Если задача противоречит архитектуре — задача должна быть переосмыслена, а не выполнена напрямую.
--- a/docs/docs/MAP.md
+++ b/docs/docs/MAP.md
@@ -0,0 +1,54 @@
+# Карта документации
+
+Список всех разделов архива с относительными ссылками. Точка входа
+— `DEVELOP.md` рядом с этим файлом.
+
+## Подсказки
+
+- [Подсказки](./workflow.md) — Короткие ответы на типовые вопросы и решения для спорных ситуаций.
+
+## Базовые правила
+
+- [Технологии и библиотеки](./basics/tech-stack.md) — Какие библиотеки и инструменты используются в проекте.
+- [Именование](./basics/naming.md) — Как называть переменные, файлы и прочие сущности в коде.
+- [Архитектура: Обзор](./basics/architecture/index.md) — Архитектурный подход проекта: что такое SLM и как он устроен.
+- [Архитектура: Слои](./basics/architecture/reference/layers.md) — Из каких слоёв состоит SLM-архитектура и как они связаны.
+- [Архитектура: Модули](./basics/architecture/reference/modules.md) — Что такое модуль в SLM-архитектуре и как он устроен.
+- [Архитектура: Сегменты](./basics/architecture/reference/segments.md) — Что такое сегмент модуля в SLM-архитектуре и какие они бывают.
+- [Стиль кода](./basics/code-style.md) — Как оформляется код в проекте.
+- [Документирование](./basics/documentation.md) — Что и как документировать в коде.
+- [Типизация](./basics/typing.md) — Как типизируется код в проекте.
+
+## Создание проекта
+
+- [Из шаблона](./creating-project/from-template.md) — Создание нового проекта на основе готового шаблона.
+- [По гайду вручную](./creating-project/manual.md) — Поэтапное создание нового проекта без использования шаблона.
+- [Чистый Next.js](./creating-project/nextjs.md) — Установка Next.js без лишнего шаблона — голый каркас под дальнейшую сборку.
+
+## Настройка
+
+- [Алиасы импортов](./setup/aliases.md) — Какие алиасы импортов есть в проекте и как ими пользоваться.
+- [Biome](./setup/biome.md) — Установка и настройка линтера-форматтера в новом проекте.
+- [PostCSS](./setup/postcss.md) — Установка и настройка CSS-процессора в новом проекте.
+- [Стили](./setup/styles.md) — Подготовка стилевой основы проекта: токены, медиа-запросы, глобальные стили.
+- [SVG-спрайты](./setup/svg-sprites.md) — Подключение SVG-спрайтов в новом проекте.
+- [Шаблоны генерации](./setup/templates.md) — Подключение шаблонов кодогенерации в новом проекте.
+- [VS Code](./setup/vscode.md) — Единые настройки редактора и расширений для команды.
+
+## Использование
+
+- [Структура проекта](./usage/project-structure.md) — Из чего состоит проект и где что лежит.
+- [Компоненты](./usage/components.md) — Как устроен и пишется React-компонент в проекте.
+- [Страницы (App Router)](./usage/page-level.md) — Что должно лежать в файлах роутинга, а что — в экранах.
+- [Шаблоны и генерация кода](./usage/templates-generation.md) — Как устроены шаблоны кодогенерации и как ими пользоваться.
+- [Стили](./usage/styles.md) — Как пишутся стили в проекте.
+- [SVG-спрайты](./usage/svg-sprites.md) — Как добавлять и использовать SVG-иконки в коде.
+
+## Данные
+
+- [Введение](./usage/data/index.md) — Какие источники данных используются в проекте и как с ними работать.
+- [REST: Клиенты: Автоматическая генерация](./usage/data/rest/clients/auto.md) — Генерация REST-клиента из OpenAPI-спецификации.
+- [REST: Клиенты: Ручное создание](./usage/data/rest/clients/manual.md) — Создание REST-клиента вручную, когда нет OpenAPI-спецификации.
+- [REST: Получение данных: Серверные компоненты](./usage/data/rest/fetching/server.md) — Получение REST-данных в серверных компонентах.
+- [REST: Получение данных: Клиентские компоненты](./usage/data/rest/fetching/client.md) — Получение REST-данных в клиентских компонентах.
+- [Realtime](./usage/data/realtime.md) — Работа с push-данными от сервера: подписки и события.
--- a/docs/docs/basics/architecture/index.md
+++ b/docs/docs/basics/architecture/index.md
@@ -1,10 +1,11 @@
 ---
-title: Архитектура
-description: "Раздел описывает архитектуру проекта: из каких слоёв состоит приложение, как организован код внутри слоёв и какие правила управляют зависимостями."
+title: SLM Design
+description: "Архитектурный подход проекта: что такое SLM и как он устроен."
 ---

 # SLM Design
-Scoped Layered Module Design — модульная архитектура фронтенд-приложений. Код организован по слоям ответственности, а модуль содержит всё, что ему нужно: компоненты, хуки, сторы, типы, стили.
+
+Архитектурный подход проекта: что такое SLM и как он устроен.

 ## Преимущества

--- a/docs/docs/basics/architecture/reference/layers.md
+++ b/docs/docs/basics/architecture/reference/layers.md
@@ -1,10 +1,11 @@
 ---
-title: Слои
+title: Слои SLM
+description: Из каких слоёв состоит SLM-архитектура и как они связаны.
 ---

-# Слои
+# Слои SLM

-Раздел описывает слои SLM: что такое слой, какие бывают, как между ними направлены зависимости и какие правила действуют на каждом.
+Из каких слоёв состоит SLM-архитектура и как они связаны.

 ## Определение

--- a/docs/docs/basics/architecture/reference/modules.md
+++ b/docs/docs/basics/architecture/reference/modules.md
@@ -1,10 +1,11 @@
 ---
-title: Модули
+title: Модули SLM
+description: Что такое модуль в SLM-архитектуре и как он устроен.
 ---

-# Модули
+# Модули SLM

-Раздел описывает модули SLM: что такое модуль, из чего он состоит и как взаимодействует с остальным кодом.
+Что такое модуль в SLM-архитектуре и как он устроен.

 ## Определение

@@ -52,7 +53,7 @@ auth/
 └── index.ts                     # публичный API
 ```

-Подробное описание каждого сегмента — в разделе [Сегменты](/ru/basics/architecture/reference/segments).
+Подробное описание каждого сегмента — в разделе [Сегменты](/docs/basics/architecture/reference/segments).

 ## Публичный API

--- a/docs/docs/basics/architecture/reference/segments.md
+++ b/docs/docs/basics/architecture/reference/segments.md
@@ -1,10 +1,11 @@
 ---
-title: Сегменты
+title: Сегменты SLM
+description: Что такое сегмент модуля в SLM-архитектуре и какие они бывают.
 ---

-# Сегменты
+# Сегменты SLM

-Раздел описывает сегменты SLM: что такое сегмент, какие бывают и что в каждом из них лежит.
+Что такое сегмент модуля в SLM-архитектуре и какие они бывают.

 ## Определение

--- a/docs/docs/basics/code-style.md
+++ b/docs/docs/basics/code-style.md
@@ -1,10 +1,11 @@
 ---
 title: Стиль кода
+description: Как оформляется код в проекте.
 ---

 # Стиль кода

-Раздел описывает единые правила оформления кода: отступы, переносы, кавычки, порядок импортов и базовую читаемость.
+Как оформляется код в проекте.

 ## Отступы

--- a/docs/docs/basics/documentation.md
+++ b/docs/docs/basics/documentation.md
@@ -1,11 +1,11 @@
 ---
 title: Документирование
+description: Что и как документировать в коде.
 ---

 # Документирование

-Этот раздел описывает правила документирования кода: когда и как писать
-комментарии к компонентам, функциям, типам и интерфейсам.
+Что и как документировать в коде.

 ## Общие правила

--- a/docs/docs/basics/naming.md
+++ b/docs/docs/basics/naming.md
@@ -1,10 +1,11 @@
 ---
 title: Именование
+description: Как называть переменные, файлы и прочие сущности в коде.
 ---

 # Именование

-Этот раздел описывает соглашения об именовании в проекте. Единые правила делают код предсказуемым и упрощают навигацию по проекту.
+Как называть переменные, файлы и прочие сущности в коде.

 ## Базовые правила

--- a/docs/docs/basics/tech-stack.md
+++ b/docs/docs/basics/tech-stack.md
@@ -1,10 +1,11 @@
 ---
 title: Технологии и библиотеки
+description: Какие библиотеки и инструменты используются в проекте.
 ---

 # Технологии и библиотеки

-Этот раздел описывает базовый стек технологий и библиотек, принятый в проекте.
+Какие библиотеки и инструменты используются в проекте.

 ## Что используем

@@ -13,7 +14,7 @@ title: Технологии и библиотеки
 - `Next.js` — для продуктовых сайтов.

 ### Архитектура
- `SLM Design` — собственная модульная архитектура проекта. Подробнее в разделе [Архитектура](/ru/basics/architecture/).
+- `SLM Design` — собственная модульная архитектура проекта. Подробнее в разделе [Архитектура](/docs/basics/architecture/).

 ### UI компоненты
 - `Mantine UI` — базовые UI-компоненты.
--- a/docs/docs/basics/typing.md
+++ b/docs/docs/basics/typing.md
@@ -1,10 +1,11 @@
 ---
 title: Типизация
+description: Как типизируется код в проекте.
 ---

 # Типизация

-Этот раздел описывает правила типизации: как типизировать компоненты, функции и работу с `any`/`unknown`.
+Как типизируется код в проекте.

 ## Общие правила

--- a/docs/docs/creating-project/from-template.md
+++ b/docs/docs/creating-project/from-template.md
@@ -0,0 +1,51 @@
+---
+title: Создание проекта из шаблона
+description: Создание нового проекта на основе готового шаблона.
+keywords: [создать проект из шаблона, шаблон, template, tiged, degit, клонировать шаблон, эталонный шаблон, быстрый старт, scaffold, новый проект]
+---
+
+# Создание проекта из шаблона
+
+Создание нового проекта на основе готового шаблона.
+
+## Что внутри
+
+Шаблон — готовый скелет проекта с применёнными правилами стайлгайда:
+
+- **Стек:** Next.js (App Router), TypeScript, React.
+- **Архитектура:** структура папок по SLM, алиасы импортов.
+- **Качество кода:** Biome (линтер и форматер), настройки VS Code.
+- **Стили:** PostCSS Modules с плагинами, токены, медиа-брейкпоинты.
+- **Ассеты:** генерация SVG-спрайтов.
+- **Кодогенерация:** шаблоны для страниц, компонентов, хуков, сторов.
+в
+## Установка
+
+1. Склонировать шаблон в родительском каталоге будущего проекта:
+
+   ```bash
+   npx tiged git@gromlab.ru:templates/nextjs.git my-app
+   ```
+
+   `tiged` копирует снимок репозитория без истории git. Имя каталога (`my-app`) заменяется на нужное.
+
+2. Установить зависимости:
+
+   ```bash
+   cd my-app
+   npm install
+   ```
+
+3. Проверить сборку:
+
+   ```bash
+   npm run build
+   ```
+
+   Сборка должна завершиться без ошибок.
+
+## Правила
+
+- **Шаблон — источник истины.** Не добавлять, не удалять и не переименовывать файлы шаблона «для приведения к канону»: шаблон уже канонический. Любое несоответствие — баг шаблона, а не проекта.
+- **Менеджер пакетов — npm.** Отклонение (pnpm, yarn, bun) — только по явному решению с пониманием, что стайлгайд этого не предусматривает.
+- **Не инициализировать git заново** автоматически. `tiged` намеренно не создаёт `.git/` — решение о репозитории принимает разработчик.
--- a/docs/docs/creating-project/manual.md
+++ b/docs/docs/creating-project/manual.md
@@ -0,0 +1,90 @@
+---
+title: Создание проекта вручную
+description: Поэтапное создание нового проекта без использования шаблона.
+keywords: [создать проект, новый проект, с нуля, init, initialize, scaffold, create-next-app, начать проект, поднять проект, эталонный проект, ручная установка]
+---
+
+# Создание проекта вручную
+
+Поэтапное создание нового проекта без использования шаблона.
+
+## Состав эталонного проекта
+
+| Компонент | Роль | Раздел |
+|-----------|------|--------|
+| Next.js | Фреймворк (роутинг, сборка, SSR) | [Next.js](/docs/creating-project/nextjs) |
+| Алиасы | Импорты по слоям SLM | [Алиасы](/docs/setup/aliases) |
+| Biome | Линтер и форматтер (замена ESLint + Prettier) | [Biome](/docs/setup/biome) |
+| Стили | Глобальные токены и breakpoints | [Стили](/docs/setup/styles) |
+| PostCSS | CSS-процессор для custom-media и вложенности | [PostCSS](/docs/setup/postcss) |
+| SVG-спрайты | Иконки через `<SvgSprite/>`, управление цветом | [SVG-спрайты](/docs/setup/svg-sprites) |
+| VS Code | Настройки редактора и расширения | [VS Code](/docs/setup/vscode) |
+| Шаблоны генерации | `.templates/` для `@gromlab/create` | [Шаблоны генерации](/docs/setup/templates) |
+
+Убрать компонент из состава — значит согласованно отказаться от части стайлгайда. Частичные проекты возможны (только Next.js, Next.js + стили и т.п.), но не являются эталоном.
+
+## Канон раскладки
+
+В `src/` допустимы только слои SLM: `app/`, `layouts/`, `screens/`, `widgets/`, `business/`, `infrastructure/`, `ui/`, `shared/`. Любая другая папка в `src/` — нарушение канона ([Структура проекта](/docs/usage/project-structure), [Архитектура](/docs/basics/architecture/)).
+
+В частности: `src/app/` содержит только файлы роутинга Next.js и инициализации, без каталогов `styles/`, `assets/`, `components/`.
+
+## Порядок установки
+
+Подсистемы ставятся в фиксированном порядке — он отражает зависимости между шагами.
+
+### 1. Next.js
+
+Скелет фреймворка — обязательный первый шаг, остальное опирается на него.
+
+См. [Next.js](/docs/creating-project/nextjs). После выполнения проверки этого раздела `npm run build` должен проходить.
+
+### 2. Алиасы
+
+Заменить дефолтный `"@/*"` в `tsconfig.json` на канонический список из восьми слой-префиксов.
+
+См. [Алиасы](/docs/setup/aliases).
+
+### 3. Biome
+
+Линтер и форматтер. Подключается **до** написания кода, иначе в проекте копятся несогласованные правки.
+
+См. [Biome](/docs/setup/biome).
+
+### 4. Стили (базовая инфраструктура)
+
+Файлы `variables.css`, `media.css`, `global.css` в `src/shared/styles/` и подключение `global.css` в `src/app/layout.tsx`. CSS-процессор на этом шаге не ставится.
+
+См. [Стили](/docs/setup/styles).
+
+### 5. PostCSS
+
+CSS-процессор поверх базовых стилей: `@custom-media`, вложенность, autoprefixer. Ставится **только после шага 4** — опирается на `src/shared/styles/media.css`.
+
+См. [PostCSS](/docs/setup/postcss).
+
+### 6. SVG-спрайты
+
+Пакет `@gromlab/svg-sprites`, генерация спрайт-файла и React-компонента `<SvgSprite/>`.
+
+См. [SVG-спрайты](/docs/setup/svg-sprites).
+
+### 7. VS Code
+
+Расширения и настройки редактора. Опирается на установленный Biome (форматирование при сохранении) и PostCSS (ассоциация `*.css`).
+
+См. [VS Code](/docs/setup/vscode).
+
+### 8. Шаблоны генерации
+
+Папка `.templates/` для генератора модулей `@gromlab/create`.
+
+См. [Шаблоны генерации](/docs/setup/templates).
+
+## Правила
+
+- **Порядок шагов фиксирован.** Перестановка ломает зависимости (PostCSS требует базовых стилей, VS Code — установленного Biome).
+- **Между шагами обязательна проверка** из соответствующего раздела. Не переходить дальше, пока чеклист текущего шага не пройден.
+- **Слои `src/`** (`layouts/`, `screens/`, `widgets/`, `business/`, `infrastructure/`, `ui/`) не создавать авансом. Появляются по мере первого модуля. Исключения — `src/app/` (создаётся `create-next-app`), `src/shared/styles/` (шаг 1) и `src/shared/sprites/icons/` (шаг 6).
+- **Посторонние каталоги в `src/`** (`assets/`, `utils/`, `lib/`, `components/` и т.п.) — запрещены.
+- **Подмножество шагов допустимо.** Можно ставить только Next.js и часть инструментов; полный набор — это эталон, а не обязательство.
--- a/docs/docs/creating-project/nextjs.md
+++ b/docs/docs/creating-project/nextjs.md
@@ -0,0 +1,112 @@
+---
+title: Чистая установка Next.js
+description: "Установка Next.js без лишнего шаблона — голый каркас под дальнейшую сборку."
+keywords: [next.js, create-next-app, npx, установка, инициализация, фреймворк, скаффолдинг, app router, typescript]
+---
+
+# Чистая установка Next.js
+
+Установка Next.js без лишнего шаблона — голый каркас под дальнейшую сборку.
+
+## Требования
+
+- Node.js 18.18+ (рекомендуется LTS 20+).
+- npm 10+.
+- Рабочая папка пуста, либо для установки выбрана подпапка (`create-next-app@16+` отказывается ставиться в непустую директорию).
+
+## Установка
+
+### 1. Инициализация через `create-next-app`
+
+Флаги зафиксированы и не согласовываются — это канон стайлгайда:
+
+```bash
+npx create-next-app@latest my-app \
+  --typescript \
+  --app \
+  --src-dir \
+  --import-alias "@/*" \
+  --no-eslint \
+  --no-tailwind \
+  --use-npm
+```
+
+| Флаг | Значение | Почему так |
+|------|----------|------------|
+| `--typescript` | TS включён | Стайлгайд требует TypeScript ([Типизация](/docs/basics/typing)) |
+| `--app` | App Router | Pages Router не используется |
+| `--src-dir` | Код в `src/` | Архитектура SLM требует `src/` ([Структура проекта](/docs/usage/project-structure)) |
+| `--import-alias "@/*"` | Placeholder | Требуется флагом; после установки `paths` полностью переписывается на слой-префиксы (см. [Алиасы](/docs/setup/aliases)) |
+| `--no-eslint` | ESLint не ставится | Линтер и форматтер — Biome ([Biome](/docs/setup/biome)) |
+| `--no-tailwind` | Tailwind не ставится | Стилизация — PostCSS Modules ([Стили](/docs/usage/styles)) |
+| `--use-npm` | Пакетный менеджер — npm | Единый инструмент в проектах |
+
+### 2. Очистить дефолтный шаблон
+
+`create-next-app` генерирует демо-страницу со стилями и ассетами, а Next.js 16+ дополнительно кладёт в корень собственные `AGENTS.md` и `CLAUDE.md` — всё это удаляется.
+
+```bash
+rm src/app/page.module.css
+rm src/app/globals.css
+rm public/next.svg public/vercel.svg public/file.svg public/globe.svg public/window.svg
+rm -f AGENTS.md CLAUDE.md
+```
+
+Заменить `src/app/page.tsx` на минимальный:
+
+```tsx
+// src/app/page.tsx
+export default function HomePage() {
+  return <h1>Home</h1>
+}
+```
+
+Очистить `src/app/layout.tsx` от импорта шрифтов и `globals.css`:
+
+```tsx
+// src/app/layout.tsx
+import type { Metadata } from 'next'
+
+export const metadata: Metadata = {
+  title: 'App',
+  description: '',
+}
+
+export default function RootLayout({ children }: { children: React.ReactNode }) {
+  return (
+    <html lang="ru">
+      <body>{children}</body>
+    </html>
+  )
+}
+```
+
+### 3. Создать папку `src/shared/styles/`
+
+Глобальные стили в SLM-архитектуре живут в слое `shared`, а не в `src/app/` ([Структура проекта](/docs/usage/project-structure)).
+
+```bash
+mkdir -p src/shared/styles
+```
+
+Остальные слои (`layouts/`, `screens/`, `widgets/`, `business/`, `infrastructure/`, `ui/`) заводятся при появлении первого модуля в них. `src/shared/styles/` — единственный подкаталог `shared/`, который заводится сразу: без него не настроить стили на следующих шагах.
+
+## Правила
+
+- **Конфликт с непустой директорией** — не удалять файлы пользователя автоматически. Ставить в подпапку или временно перенести посторонние файлы.
+- **Отклонение от канонических флагов** (pnpm, Tailwind, ESLint и т.п.) — только осознанное, с пониманием, что стайлгайд этого не предусматривает.
+- **Слои `src/`** не создавать авансом — появляются при первом модуле. Алиасы прописываются сразу на все восемь слоёв (см. [Алиасы](/docs/setup/aliases)).
+- **`AGENTS.md` от Next.js** удаляется в шаге 2. Повторно не создаётся.
+- **Biome, стили, PostCSS, SVG-спрайты, VS Code** — отдельные шаги установки, не в этом разделе.
+
+## Проверка установки
+
+- В корне проекта: `next.config.ts`, `tsconfig.json`, `package.json`.
+- В `package.json`: Next.js установлен, нет `eslint`, `tailwindcss`.
+- В `src/app/` присутствуют минимальные `page.tsx` и `layout.tsx`. `globals.css`, `page.module.css` отсутствуют. Каталогов `styles/`, `assets/`, `providers/`, `components/` в `src/app/` нет.
+- Папка `src/shared/styles/` создана (пустая).
+- В `src/` из слоёв SLM присутствуют только `app/` и `shared/` (с `styles/`). Посторонних каталогов нет.
+- В `public/` удалены `next.svg`, `vercel.svg`, `file.svg`, `globe.svg`, `window.svg`.
+- В корне проекта нет `AGENTS.md` и `CLAUDE.md` от Next.js.
+- `npm run build` завершается успешно.
+- Пакетный менеджер — npm (нет `pnpm-lock.yaml`, `yarn.lock`, `bun.lockb`).
--- a/docs/docs/index.md
+++ b/docs/docs/index.md
@@ -0,0 +1,97 @@
+---
+title: NextJS Style Guide
+description: Стандарты разработки фронтенд-приложений на Next.js и TypeScript.
+---
+
+# NextJS Style Guide
+
+Стандарты разработки фронтенд-приложений на Next.js и TypeScript.
+
+## Использование
+
+**Для AI-агентов:**
+
+- [llms.txt](/llms.txt) — Карта разделов, оглавление со ссылками на разделы.
+- [llms-full.txt](/llms-full.txt) — Вся документация одним файлом.
+
+**Для проекта:**
+
+- [nextjs-style-guide.zip](/nextjs-style-guide.zip) — Набор Markdown-файлов для распаковки в `./ai/nextjs-style-guide/` или другую папку проекта.
+
+## Структура документации
+
+### Подсказки
+
+[Подсказки](/docs/workflow) — короткие ответы на типовые вопросы и решения для спорных ситуаций.
+
+### Базовые правила
+
+**Каким должен быть код** — стандарты, не привязанные к конкретной технологии.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Технологии и библиотеки | Какой стек используем? |
+| Именование | Как называть файлы, переменные, компоненты, хуки? |
+| SLM Design | Что такое SLM и зачем она нужна? |
+| Архитектура: Слои | Какие слои есть и как между ними устроены зависимости? |
+| Архитектура: Модули | Что такое модуль и как он устроен? |
+| Архитектура: Сегменты | Какие сегменты есть внутри модуля? |
+| Стиль кода | Как оформлять код: отступы, кавычки, импорты, early return? |
+| Документирование | Как писать JSDoc: что документировать, а что нет? |
+| Типизация | Как типизировать: type vs interface, any/unknown? |
+
+### Создание проекта
+
+**Как начать новый проект** — варианты установки и эталонный набор инструментов.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Создание проекта из шаблона | Как начать проект из готового шаблона? |
+| Создание проекта вручную | Как поднять проект с нуля без шаблона? |
+| Чистая установка Next.js | Как поставить голый Next.js под дальнейшую сборку? |
+
+### Настройка
+
+**Как сконфигурировать проект** — пошаговая настройка инструментов и инфраструктуры.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Алиасы импортов | Как настроить алиасы импортов? |
+| Biome | Как настроить линтер и форматтер? |
+| PostCSS | Какие плагины PostCSS нужны и как их настроить? |
+| Стили | Как подключить базовые стили и токены? |
+| SVG-спрайты | Как подключить генерацию SVG-спрайтов? |
+| Шаблоны генерации | Как подключить шаблоны для кодогенерации? |
+| VS Code | Как настроить редактор для проекта? |
+
+### Использование
+
+**Как это устроено и как этим пользоваться** — структура, примеры и правила для конкретных областей.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Структура проекта | Как организованы папки и файлы по SLM? |
+| Компоненты | Как устроен компонент: файлы, пропсы, clsx? |
+| Файлы роутинга | Как описывать layout, page, loading, error, not-found? |
+| Шаблоны и генерация кода | Как работают шаблоны, синтаксис и инструменты генерации? |
+| Стили | Как писать CSS: вложенность, медиа, токены? |
+| SVG-спрайты | Как использовать SVG-спрайты в коде? |
+| Изображения | _(не заполнен)_ |
+| Видео | _(не заполнен)_ |
+| Stores | _(не заполнен)_ |
+| Хуки | _(не заполнен)_ |
+| Шрифты | _(не заполнен)_ |
+| Локализация | _(не заполнен)_ |
+
+### Данные
+
+**Как работать с источниками данных** — REST, realtime и потребление в компонентах.
+
+| Раздел | Отвечает на вопрос |
+|--------|-------------------|
+| Источники данных | Как устроена работа с данными в проекте? |
+| REST: Автоматическая генерация | Как сгенерировать REST-клиент автоматически из OpenAPI? |
+| REST: Ручное создание | Как написать REST-клиент вручную? |
+| REST: Серверные компоненты | Как получать данные в серверных компонентах? |
+| REST: Клиентские компоненты | Как получать данные в клиентских компонентах? |
+| Realtime | Как работать с realtime-каналами и сокетами? |
--- a/docs/docs/setup/aliases.md
+++ b/docs/docs/setup/aliases.md
@@ -0,0 +1,77 @@
+---
+title: Алиасы импортов
+description: Какие алиасы импортов есть в проекте и как ими пользоваться.
+keywords: [алиасы, aliases, paths, tsconfig, импорты, baseUrl, app, layouts, screens, widgets, business, infrastructure, ui, shared]
+---
+
+# Алиасы импортов
+
+Какие алиасы импортов есть в проекте и как ими пользоваться.
+
+## Конфиг
+
+`tsconfig.json` в корне проекта:
+
+```json
+{
+  "compilerOptions": {
+    "paths": {
+      "app/*":            ["./src/app/*"],
+      "layouts/*":        ["./src/layouts/*"],
+      "screens/*":        ["./src/screens/*"],
+      "widgets/*":        ["./src/widgets/*"],
+      "business/*":       ["./src/business/*"],
+      "infrastructure/*": ["./src/infrastructure/*"],
+      "ui/*":             ["./src/ui/*"],
+      "shared/*":         ["./src/shared/*"]
+    }
+  }
+}
+```
+
+Восемь алиасов — ровно по числу слоёв. Других алиасов в проекте нет.
+
+## Правила
+
+- **Каждый импорт между модулями — через алиас слоя.** Относительные пути (`../../`) запрещены за пределами своего модуля.
+- **Внутри одного модуля** допустимы относительные импорты (`./model`, `./ui/button`) — это часть инкапсуляции модуля.
+- **Префикс `@/` не используется.** Имя слоя — само по себе адрес.
+- **Направление импортов** определяется архитектурой, не алиасами. Алиас разрешает импорт технически, но не отменяет правила слоёв (→ [Слои](/docs/basics/architecture/reference/layers)).
+
+**Хорошо**
+
+```ts
+import { Button } from 'ui/button'
+import { useUser } from 'business/user'
+import { formatDate } from 'shared/utils/date'
+```
+
+**Плохо**
+
+```ts
+// Относительный путь между модулями
+import { Button } from '../../../ui/button'
+
+// Префикс @/, которого нет в paths
+import { Button } from '@/ui/button'
+
+// Алиас на src — не предусмотрен
+import { Button } from 'src/ui/button'
+```
+
+## Внутри модуля
+
+Внутри своего модуля — относительные пути:
+
+```ts
+// src/ui/button/button.tsx
+import styles from './button.module.css'
+import { Icon } from './icon'
+```
+
+Не использовать алиас на самого себя:
+
+```ts
+// Плохо — алиас вместо относительного пути внутри модуля
+import { Icon } from 'ui/button/icon'
+```
--- a/docs/docs/setup/biome.md
+++ b/docs/docs/setup/biome.md
@@ -0,0 +1,81 @@
+---
+title: Biome
+description: Установка и настройка линтера-форматтера в новом проекте.
+keywords: [biome, линтер, форматтер, lint, format, biome.json, "@biomejs/biome", замена eslint, замена prettier]
+---
+
+# Biome
+
+Установка и настройка линтера-форматтера в новом проекте.
+
+## Требования
+
+- Node.js 18+.
+- Проект без установленного ESLint и Prettier (они конфликтуют с Biome).
+
+## Установка
+
+1. Установить пакет:
+
+   ```bash
+   npm install --save-dev --save-exact @biomejs/biome
+   ```
+
+2. Инициализировать конфиг:
+
+   ```bash
+   npx @biomejs/biome init
+   ```
+
+   В корне появится `biome.json` с дефолтными настройками.
+
+3. Привести `biome.json` к стандартному виду — добавить override для `*.css` (см. «Стандартный `biome.json`»). Делается сразу после `init`, до первого запуска `lint`/`check`.
+
+4. Добавить скрипты в `package.json`:
+
+   ```json
+   {
+     "scripts": {
+       "lint": "biome lint .",
+       "format": "biome format --write .",
+       "check": "biome check --write ."
+     }
+   }
+   ```
+
+   | Скрипт | Что делает |
+   |--------|-----------|
+   | `lint` | Проверка правил без правок |
+   | `format` | Автоформатирование всех файлов |
+   | `check` | Lint + format + organize imports в один проход (основная команда) |
+
+## Стандартный `biome.json`
+
+Дефолтный `biome.json`, созданный `biome init`, кастомизируется ровно одним блоком — `overrides` для `*.css` с отключённым правилом `suspicious/noUnknownAtRules`. Этот override **обязателен по умолчанию во всех проектах**, независимо от того, подключены ли уже стили: проектный CSS-стек использует `@custom-media` и другие нестандартные at-правила, которые Biome не распознаёт; без override `npm run lint` падает.
+
+Фрагмент, который добавляется в `biome.json`:
+
+```jsonc
+{
+  "overrides": [
+    {
+      "includes": ["**/*.css"],
+      "linter": {
+        "rules": {
+          "suspicious": {
+            "noUnknownAtRules": "off"
+          }
+        }
+      }
+    }
+  ]
+}
+```
+
+Если в `biome.json` уже есть массив `overrides` — добавить элемент в него; не дублировать массив.
+
+Прочая настройка правил Biome — отдельная задача, не входит в стандартный канон.
+
+## Интеграция с VS Code
+
+Расширение `biomejs.biome` и автоформатирование при сохранении настраиваются в [Настройка VS Code](/docs/setup/vscode).
--- a/docs/docs/setup/postcss.md
+++ b/docs/docs/setup/postcss.md
@@ -0,0 +1,70 @@
+---
+title: PostCSS
+description: Установка и настройка CSS-процессора в новом проекте.
+keywords: [postcss, postcss.config.mjs, postcss-custom-media, postcss-nesting, autoprefixer, postcss-global-data, csstools, "@custom-media", "@nest", css-процессор]
+---
+
+# PostCSS
+
+Установка и настройка CSS-процессора в новом проекте.
+
+## Зачем PostCSS
+
+Подключаем ради двух вещей:
+
+- **Вложенность** — `&:hover`, `&::before`, `&._active` и `@media` внутри селектора. Без процессора нативный CSS не покрывает всех нужных кейсов вложенности.
+- **`@custom-media`** — единые breakpoints проекта (`@media (--md)`) вместо магических `min-width`. Определяются в одном месте, переиспользуются везде.
+
+Autoprefixer и `@csstools/postcss-global-data` идут довеском под эти две задачи.
+
+## Требования
+
+- Next.js 14+ (App Router).
+- Node.js 18+.
+
+CSS Modules поддерживаются Next.js из коробки — отдельной установки не требуют.
+
+## Установка
+
+1. Установить PostCSS-плагины как devDependencies:
+
+   ```bash
+   npm install -D postcss-custom-media postcss-nesting autoprefixer @csstools/postcss-global-data
+   ```
+
+2. Создать `postcss.config.mjs` в корне проекта (см. «Конфиг»).
+
+## Конфиг
+
+Файл `postcss.config.mjs` в корне проекта.
+
+```js
+// postcss.config.mjs
+export default {
+  plugins: {
+    '@csstools/postcss-global-data': {
+      files: ['src/shared/styles/media.css'],
+    },
+    'postcss-custom-media': {},
+    'postcss-nesting': {},
+    autoprefixer: {},
+  },
+}
+```
+
+### Разбор плагинов
+
+| Плагин | Назначение |
+|--------|------------|
+| `@csstools/postcss-global-data` | Подгружает определения `@custom-media` из `src/shared/styles/media.css` перед обработкой каждого CSS-модуля. Семантика — «глобальный файл определений, который не импортируется в исходники» |
+| `postcss-custom-media` | Поддержка `@custom-media --md (...)` и использования `@media (--md) {}`. Определения берутся из файла, который подгрузил `postcss-global-data` |
+| `postcss-nesting` | Нативная CSS-вложенность: `&:hover`, `&::before`, `&._active` |
+| `autoprefixer` | Добавление вендорных префиксов по browserslist |
+
+### Почему внешний файл с `@custom-media`, а не `@import`
+
+`@custom-media` — глобальные определения, одинаковые для всего проекта. Держим их в `src/shared/styles/media.css`. `@csstools/postcss-global-data` подгружает этот файл перед каждым модулем, а `postcss-custom-media` заменяет `@media (--md)` на конкретные `@media (min-width: ...)` на этапе сборки. Сами определения в бандл не попадают.
+
+Опция `importFrom` у `postcss-custom-media` удалена в v10+; её роль теперь выполняет `@csstools/postcss-global-data`.
+
+Импортировать `media.css` в файлы компонентов **не нужно** и запрещено правилами (см. [Использование](/docs/usage/styles), раздел «Импорт стилей»).
--- a/docs/docs/setup/styles.md
+++ b/docs/docs/setup/styles.md
@@ -0,0 +1,177 @@
+---
+title: Стили
+description: "Подготовка стилевой основы проекта: токены, медиа-запросы, глобальные стили."
+keywords: [variables.css, media.css, global.css, shared/styles, токены, переменные, custom-media, breakpoints, подключение стилей, базовые стили, инициализация]
+---
+
+# Стили
+
+Подготовка стилевой основы проекта: токены, медиа-запросы, глобальные стили.
+
+## Требования
+
+- Структура `src/` соответствует SLM ([Структура проекта](/docs/usage/project-structure)). Глобальные стили живут в `src/shared/styles/`, не в `src/app/`.
+- В проекте нет `globals.css` с кастомным содержимым и не установлен `tailwindcss`.
+
+## Файлы
+
+Состав глобальных стилей — три файла:
+
+| Файл | Роль |
+|------|------|
+| `variables.css` | Токены проекта (цвета, отступы, радиусы) |
+| `media.css` | Custom media queries (брейкпоинты по ширине и высоте) |
+| `global.css` | Точка сборки глобальных стилей: через `@import` тянет все остальные глобалы, импортируется в приложение один раз |
+
+Правила подключения:
+
+- В приложение импортируется **только** `global.css`.
+- `variables.css` и будущие глобальные файлы (резеты, темы, типографика) подключаются в `global.css` через `@import`.
+- `media.css` **не импортируется** — ни в `global.css`, ни в компоненты, ни в точку инициализации. Его читает CSS-процессор на этапе сборки (см. [PostCSS](/docs/setup/postcss)).
+
+## Корневой `font-size`
+
+Базовая единица `rem` в проекте привязана к **16px**: корневой `font-size` не переопределяется. `html { font-size: ... }` писать запрещено — пользовательская настройка размера шрифта в браузере должна работать (a11y). Все `rem`-значения в `media.css` и других стилях трактуются как `1rem = 16px по умолчанию`.
+
+Reset браузерных дефолтов (`box-sizing`, сброс `margin`, типографика) каноном не задаётся — каждый проект решает сам. Если заводится — подключается через `global.css`.
+
+## Установка
+
+### 1. Создать файлы
+
+```bash
+mkdir -p src/shared/styles
+touch src/shared/styles/variables.css src/shared/styles/media.css src/shared/styles/global.css
+```
+
+### 2. Заполнить `media.css`
+
+Файл `src/shared/styles/media.css`. Стандартный набор брейкпоинтов проекта; редактировать только при согласованном изменении шкалы.
+
+Единица — `rem` (реагирует на корневой `font-size`). Перевод исходит из дефолтного `html { font-size: 16px }`, т.е. `1rem = 16px`.
+
+```css
+/* src/shared/styles/media.css */
+
+/* Ширина — Mobile First (min-width), кроме --xs (max-width) */
+@custom-media --xs  (max-width: 35.9375rem);  /* 575px  — до sm */
+@custom-media --sm  (min-width: 36rem);       /* 576px  — телефон альбом / малый планшет */
+@custom-media --md  (min-width: 48rem);       /* 768px  — планшет */
+@custom-media --lg  (min-width: 62rem);       /* 992px  — малый десктоп */
+@custom-media --xl  (min-width: 75rem);       /* 1200px — десктоп */
+@custom-media --2xl (min-width: 88rem);       /* 1408px — широкий десктоп */
+@custom-media --3xl (min-width: 120rem);      /* 1920px — full HD+ */
+
+/* Высота — min-height */
+@custom-media --h-xs  (min-height: 41.6875rem); /* 667px  — iPhone SE портрет */
+@custom-media --h-sm  (min-height: 43.875rem);  /* 702px */
+@custom-media --h-md  (min-height: 50.625rem);  /* 810px  — iPad портрет */
+@custom-media --h-lg  (min-height: 56.25rem);   /* 900px */
+@custom-media --h-xl  (min-height: 62.5rem);    /* 1000px */
+@custom-media --h-2xl (min-height: 68.75rem);   /* 1100px */
+@custom-media --h-3xl (min-height: 75rem);      /* 1200px */
+```
+
+Правила:
+
+- только `@custom-media` на верхнем уровне;
+- имена короткие, по шкале (`--xs` … `--3xl`); высотные — с префиксом `--h-`;
+- единица — `rem`, не `em`/`px`; пиксельное значение указывается комментарием;
+- значения ширины — `min-width` (Mobile First), исключение `--xs` — `max-width` (блок «строго меньше `--sm`»);
+- значения высоты — `min-height`.
+
+### 3. Заполнить `variables.css`
+
+Файл `src/shared/styles/variables.css`. Набор токенов под проект расширяется по мере роста дизайн-системы.
+
+```css
+/* src/shared/styles/variables.css */
+:root {
+  /* Цвета */
+  --color-primary: #3b82f6;
+  --color-bg: #ffffff;
+  --color-bg-hover: #f5f5f5;
+  --color-text: #1a1a1a;
+
+  /* Отступы */
+  --space-1: 4px;
+  --space-2: 8px;
+  --space-3: 12px;
+  --space-4: 16px;
+
+  /* Скругления */
+  --radius-1: 4px;
+  --radius-2: 8px;
+}
+```
+
+Правила:
+
+- все токены определяются в `:root` — без вложенных селекторов;
+- именование — `kebab-case` по ролям: `--color-*`, `--space-*`, `--radius-*`;
+- `px` — основная единица для пространственных токенов;
+- темы накладываются поверх через `[data-theme="..."] { ... }` — в отдельном файле темы или здесь же.
+
+`variables.css` напрямую в приложение не импортируется — только через `global.css`.
+
+### 4. Заполнить `global.css`
+
+Файл `src/shared/styles/global.css`. Единственный глобальный файл, импортируемый в точку инициализации приложения. Внутри — `@import` остальных глобалов относительным путём.
+
+```css
+/* src/shared/styles/global.css */
+@import './variables.css';
+
+/* Сюда же подключаются будущие глобалы через @import:
+ * @import './reset.css';
+ * @import './typography.css';
+ * @import './themes.css';
+ * media.css НЕ импортируется — он работает через PostCSS.
+ */
+```
+
+Правила:
+
+- пути в `@import` — относительные (`./variables.css`), не через алиасы; нативный CSS `@import` не понимает tsconfig-paths;
+- `media.css` в `global.css` **не импортируется**;
+- собственные глобальные правила (`html { ... }`, `body { ... }`) писать **не здесь**, а в отдельных файлах рядом (`reset.css`, `typography.css`) и подключать через `@import`. `global.css` — только точка сборки;
+- порядок `@import` определяет порядок каскада: токены первыми, дальше резеты / темы / типографика.
+
+### 5. Подключить `global.css` в layout
+
+Импорт делается **один раз** — в корневом layout приложения:
+
+```tsx
+// src/app/layout.tsx
+import 'shared/styles/global.css'
+
+import type { Metadata } from 'next'
+
+export const metadata: Metadata = {
+  title: 'App',
+  description: '',
+}
+
+export default function RootLayout({ children }: { children: React.ReactNode }) {
+  return (
+    <html lang="ru">
+      <body>{children}</body>
+    </html>
+  )
+}
+```
+
+`variables.css` и `media.css` в layout **не импортируются напрямую** — только через `global.css` (variables) или через PostCSS на сборке (media).
+
+## Проверка установки
+
+- В `src/shared/styles/` присутствуют три файла: `variables.css`, `media.css`, `global.css`. В `src/app/` папки `styles/` нет.
+- В `src/app/layout.tsx` есть `import 'shared/styles/global.css'`. Импортов `variables.css` и `media.css` там нет.
+- В проекте **не появились** PostCSS-пакеты и `postcss.config.*` — этот раздел их не ставит.
+- `npm run build` завершается успешно.
+
+## Дальше
+
+- [PostCSS](/docs/setup/postcss) — подключить процессор, чтобы заработали `@media (--md)` и вложенность.
+- [Стили: использование](/docs/usage/styles) — правила написания CSS в компонентах.
+- [SVG-спрайты](/docs/setup/svg-sprites) — стили иконок отдельно от глобальных.
--- a/docs/docs/setup/svg-sprites.md
+++ b/docs/docs/setup/svg-sprites.md
@@ -0,0 +1,107 @@
+---
+title: SVG-спрайты
+description: Подключение SVG-спрайтов в новом проекте.
+keywords: [svg-sprites, установка, настройка, config, пакет, "@gromlab/svg-sprites", svg-sprites.config.ts]
+---
+
+# SVG-спрайты
+
+Подключение SVG-спрайтов в новом проекте.
+
+## Требования
+
+- Node.js 18+
+- React 18+
+
+## Установка
+
+1. Установить пакет:
+
+   ```bash
+   npm install @gromlab/svg-sprites
+   ```
+
+2. Создать `svg-sprites.config.ts` в корне проекта (см. «Стандартный конфиг»).
+
+3. Создать папку входа для SVG-файлов в слое `shared`:
+
+   ```bash
+   mkdir -p src/shared/sprites/icons
+   ```
+
+   Источники спрайтов живут в `src/shared/sprites/<group>/` — это слой `shared` SLM-архитектуры (см. [Структура проекта](/docs/usage/project-structure), [Архитектура](/docs/basics/architecture/)). В `src/` посторонних каталогов вне слоёв не заводим.
+
+4. Добавить скрипты в `package.json`:
+
+   ```json
+   {
+     "scripts": {
+       "sprite": "svg-sprites",
+       "predev": "svg-sprites",
+       "prebuild": "svg-sprites"
+     }
+   }
+   ```
+
+   Хуки `predev` и `prebuild` гарантируют, что спрайты и типы всегда актуальны перед запуском и сборкой.
+
+5. Добавить сгенерированные артефакты в `.gitignore`:
+
+   ```text
+   # Сгенерированные спрайты и React-компонент
+   /public/sprites/
+   /src/ui/svg-sprite/
+   ```
+
+6. Выполнить первую генерацию:
+
+   ```bash
+   npm run sprite
+   ```
+
+## Стандартный конфиг
+
+Файл `svg-sprites.config.ts` в корне проекта. Это канон — отклонения только по явной причине.
+
+```ts
+// svg-sprites.config.ts
+import { defineConfig } from '@gromlab/svg-sprites'
+
+export default defineConfig({
+  output: 'public/sprites',
+  publicPath: '/sprites',
+  react: 'src/ui/svg-sprite',
+  sprites: [
+    { name: 'icons', input: 'src/shared/sprites/icons' },
+  ],
+})
+```
+
+### Фиксированные значения
+
+| Опция | Значение | Почему так |
+|-------|----------|------------|
+| `output` | `public/sprites` | Единая папка статики Next.js |
+| `publicPath` | `/sprites` | URL-путь без `public/` (Next.js раздаёт `public/` как `/`) |
+| `react` | `src/ui/svg-sprite` | Слой `ui/` из архитектуры проекта (→ [Архитектура](/docs/basics/architecture/)) |
+| `sprites[0].name` | `icons` | Основной спрайт всегда называется `icons` |
+
+### Трансформации
+
+Все значения по умолчанию оставлять включёнными:
+
+```ts
+transform: {
+  removeSize: true,
+  replaceColors: true,
+  addTransition: true,
+}
+```
+
+Явно прописывать блок `transform` не нужно — пакет применяет эти значения по умолчанию.
+
+Отключать `replaceColors` — только для отдельного спрайта с фиксированной палитрой (например, брендовые логотипы). Делать это на уровне спрайта, не глобально.
+
+### Режим
+
+По умолчанию `mode: 'stack'` — не указывать явно. Переход на `symbol` требует обоснования: превью и примеры в пакете оптимизированы под `stack`.
--- a/docs/docs/setup/templates.md
+++ b/docs/docs/setup/templates.md
@@ -0,0 +1,105 @@
+---
+title: Шаблоны генерации
+description: Подключение шаблонов кодогенерации в новом проекте.
+keywords: [шаблоны, templates, .templates, tiged, generator, генератор шаблонов, добавить шаблон, скачать шаблоны, scaffold]
+---
+
+# Шаблоны генерации
+
+Подключение шаблонов кодогенерации в новом проекте.
+
+## Требования
+
+- Доступен `npx` (ставится вместе с npm).
+- Доступ к `gromlab.ru` (SSH-ключ добавлен) — для скачивания эталонного набора.
+
+## Развилка
+
+Сценарий зависит от состояния проекта:
+
+| Состояние | Что делать |
+|-----------|------------|
+| В корне проекта **нет** `.templates/` | [Скачать стандартный набор](#скачать-стандартный-набор) |
+| `.templates/` **есть**, нужен новый специфический шаблон | [Создать шаблон вручную](#создать-шаблон-вручную) |
+| `.templates/` **есть**, нужно обновить до эталона | Скачать заново с подтверждением перезаписи |
+
+## Скачать стандартный набор
+
+### Установка
+
+1. Проверить, что `.templates/` отсутствует (или согласовать перезапись, если папка уже есть).
+
+2. Скачать папку из эталонного репозитория:
+
+   ```bash
+   npx tiged git@gromlab.ru:templates/nextjs-template.git/.templates .templates
+   ```
+
+3. Если `tiged` падает в default-режиме (HTTP-tarball у Gitea) — повторить с явным git-режимом:
+
+   ```bash
+   npx tiged --mode=git git@gromlab.ru:templates/nextjs-template.git/.templates .templates
+   ```
+
+4. Проверить генерацию:
+
+   ```bash
+   npx @gromlab/create component test-widget src/ui
+   ```
+
+   После проверки — удалить тестовый модуль.
+
+### Правила
+
+- **Скачанные файлы не править.** Источник истины — репозиторий `templates/nextjs-template`. Изменения стандартных шаблонов делаются в нём, не в отдельных проектах.
+- **Расположение — только `.templates/` в корне проекта.** Это требование расширения VS Code и CLI ([Шаблоны и генерация кода](/docs/usage/templates-generation)).
+- **Если доступа к `gromlab.ru` нет** — не восстанавливать содержимое из памяти: разойдётся с каноном. Запросить шаблоны иным путём.
+
+## Создать шаблон вручную
+
+Если стандартного набора недостаточно и нужен специфический шаблон под проект.
+
+### Установка
+
+1. Прочитать [Шаблоны и генерация кода](/docs/usage/templates-generation) — секции «Структура шаблонов», «Синтаксис шаблонов», «Как создать новый шаблон».
+
+2. Определить:
+   - имя шаблона (папка внутри `.templates/`);
+   - состав файлов;
+   - слой SLM предполагаемых потребителей ([Архитектура: слои](/docs/basics/architecture/reference/layers));
+   - минимальное содержимое каждого файла.
+
+3. Проверить, что имя шаблона не конфликтует с существующей папкой в `.templates/`.
+
+4. Создать структуру `.templates/{name}/` по канону из [Шаблоны и генерация кода](/docs/usage/templates-generation) — синтаксис переменных, правила именования файлов и содержимого.
+
+5. Проверить генерацию:
+
+   ```bash
+   npx @gromlab/create {name} test-entity {целевой путь}
+   ```
+
+   После проверки — удалить тестовый артефакт.
+
+### Правила
+
+- **Если запрос покрыт стандартными шаблонами** (`component`, `widget`, `store`, `layout`, `screen`, `business`) — не создавать копию.
+- **Стандартные шаблоны не трогать.** Правка стандарта — задача репозитория `templates/nextjs-template`, не отдельного проекта.
+- **Синтаксис переменных, правила регистра, минимальный boilerplate** — в [Шаблоны и генерация кода](/docs/usage/templates-generation). Здесь не дублируется.
+
+## Общие правила
+
+- VS Code-расширение `gromlab.vscode-templateFileGenerator` устанавливается разово на машину разработчика, а не через этот раздел ([Шаблоны и генерация кода](/docs/usage/templates-generation)).
+- CLI `@gromlab/create` вызывается через `npx`, в `package.json` отдельно не добавляется.
+- Менеджер пакетов (npm/pnpm/yarn/bun) не влияет: `tiged` и `@gromlab/create` запускаются через `npx`.
+
+## Проверка установки
+
+- В корне проекта есть папка `.templates/`.
+- Внутри `.templates/` присутствуют стандартные шаблоны (или согласованный кастомный набор).
+- В корне проекта нет каталогов `.git/` и `.github/` из репозитория-шаблона.
+- Пробная генерация через `npx @gromlab/create ...` отрабатывает без ошибок.
+
+## Дальше
+
+- [Шаблоны и генерация кода](/docs/usage/templates-generation) — синтаксис, использование, создание новых шаблонов.
--- a/docs/docs/setup/vscode.md
+++ b/docs/docs/setup/vscode.md
@@ -1,10 +1,11 @@
 ---
-title: Настройка VS Code
+title: VS Code
+description: Единые настройки редактора и расширений для команды.
 ---

-# Настройка VS Code
+# VS Code

-Каждый проект содержит папку `.vscode/` с конфигурацией редактора. Это гарантирует, что все участники команды работают с одинаковыми настройками форматирования, линтинга и расширениями.
+Единые настройки редактора и расширений для команды.

 ## Структура `.vscode/`

--- a/docs/docs/usage/components.md
+++ b/docs/docs/usage/components.md
@@ -1,13 +1,11 @@
 ---
 title: Компоненты
+description: Как устроен и пишется React-компонент в проекте.
 ---

 # Компоненты

-Правила написания React-компонентов: файловая структура модуля, типизация пропсов, документирование и реализация. Раздел охватывает компоненты всех слоёв — от `shared/ui` до `screens`.
-
-Архитектурные слои и их назначение описаны в разделе [Архитектура](/ru/basics/architecture/).
-
+Как устроен и пишется React-компонент в проекте.

 ## Правила организации

@@ -43,7 +41,7 @@ container/
 - **`type` вместо `interface`** — гибче для пропсов: поддерживает union, intersection, mapped types. Declaration merging пропсам не нужно.
 - **Без `FC`** — неявно добавляет `children`, усложняет дженерики, не даёт преимуществ перед аннотацией параметра.
 - **Типы в `types/`, а не в `.tsx`** — предотвращает циклические зависимости (компонент импортирует хук, хук импортирует тип из компонента) и разделяет ответственность: `.tsx` для рендера, `.type.ts` для данных.
- **Без возвращаемого типа** — TypeScript выводит из JSX. Осознанное исключение из [базового правила](/ru/basics/typing).
+- **Без возвращаемого типа** — TypeScript выводит из JSX. Осознанное исключение из [базового правила](/docs/basics/typing).

 ## Реализация

--- a/docs/docs/usage/data/index.md
+++ b/docs/docs/usage/data/index.md
@@ -0,0 +1,51 @@
+---
+title: Источники данных
+description: Какие источники данных используются в проекте и как с ними работать.
+keywords: [данные, api, rest, realtime, клиент, swr, infrastructure, введение, карта раздела]
+---
+
+# Источники данных
+
+Какие источники данных используются в проекте и как с ними работать.
+
+## Принципы раздела
+
+- **Клиент — в `infrastructure/`.** Каждый внешний сервис — отдельный модуль слоя `infrastructure/{service-name}/`.
+- **Прямой `fetch` запрещён.** Запросы идут только через клиент модуля. Исключения — точечные и обоснованные.
+- **Источник данных диктует канал.** REST, realtime и т.п. — независимые подразделы, у каждого своя модель клиента и своё потребление.
+- **Серверные и клиентские компоненты потребляют по-разному.** Server Components — прямой `await` метода клиента, клиентские — через готовые хуки модуля API (`useUserList`, `usePostDetail` и т.п.). SWR инкапсулирован в хуке, компонент про него не знает.
+
+## Карта раздела
+
+### REST
+
+Канал «запрос-ответ» по HTTP. Покрывает большинство API.
+
+- **Клиенты** — как создаётся клиент REST API:
+  - [Автоматическая генерация](/docs/usage/data/rest/clients/auto) — для API с OpenAPI-спецификацией, через `@gromlab/api-codegen`.
+  - [Ручное создание](/docs/usage/data/rest/clients/manual) — для API без схемы, клиент пишется и поддерживается руками.
+- **Получение данных** — как клиент используется в приложении:
+  - [Серверные компоненты](/docs/usage/data/rest/fetching/server) — прямой `await` метода клиента в Server Components.
+  - [Клиентские компоненты](/docs/usage/data/rest/fetching/client) — через готовые хуки модуля API; SWR с кешем, дедупликацией и ревалидацией скрыт внутри хука.
+
+### Realtime
+
+Канал push-данных: WebSocket, SSE, событийные шины. Транспорт не зашит в правила — важна абстракция «подписка».
+
+- [Realtime](/docs/usage/data/realtime) — клиент realtime в `infrastructure/`, потребление через `useSWRSubscription` или прямые подписки.
+
+## Что даёт раздел
+
+После прочтения раздела понятно:
+
+- Где живёт код работы с API и почему именно там.
+- Когда генерировать клиент автоматически, а когда писать вручную, и как структурирован каждый из вариантов.
+- Как получать данные на сервере и на клиенте, чтобы не ломать кеш и не плодить лишние запросы.
+- Как подключать realtime-источники в общую модель работы с данными.
+- Какие правила обязательны и какие отклонения допустимы.
+
+## Что не входит в раздел
+
+- **Глобальное состояние UI** — Stores, формы, фичефлаги. Это [Stores](/docs/usage/stores).
+- **Доменная логика** — как данные превращаются в сценарии бизнеса. Это слой `business/` в [Архитектуре](/docs/basics/architecture/).
+- **Хуки общего назначения** — переиспользуемые хуки UI, не привязанные к конкретному API. Это [Хуки](/docs/usage/hooks).
--- a/docs/docs/usage/data/realtime.md
+++ b/docs/docs/usage/data/realtime.md
@@ -0,0 +1,79 @@
+---
+title: Realtime
+description: "Работа с push-данными от сервера: подписки и события."
+keywords: [realtime, websocket, sse, подписка, swr subscription, useSWRSubscription, push, события]
+---
+
+# Realtime
+
+Работа с push-данными от сервера: подписки и события.
+
+## Принципы
+
+- **Клиент realtime — в `infrastructure/`** отдельным модулем по имени канала. То же правило, что и для REST: никаких прямых соединений в коде приложения.
+- **Подписка — единица потребления.** Клиент даёт функцию `subscribe(topic, handler) → unsubscribe`. Внутри — конкретный транспорт.
+- **Использование на клиенте — два сценария:**
+  - **`useSWRSubscription`** — для данных, которые показываются в UI и должны кешироваться/синхронизироваться с REST.
+  - **Прямая подписка** — для побочных эффектов (тосты, нотификации, аналитика), не привязанных к рендеру.
+
+## Размещение клиента
+
+```text
+src/infrastructure/
+└── {channel-name}/
+    ├── connection.ts       # установление соединения, реконнект
+    ├── subscribe.ts        # subscribe(topic, handler) → unsubscribe
+    ├── types.ts
+    └── index.ts
+```
+
+## Использование через SWR
+
+```tsx
+'use client'
+
+import useSWRSubscription from 'swr/subscription'
+import { subscribe } from 'infrastructure/notifications'
+
+export function NotificationCounter() {
+  const { data: count } = useSWRSubscription(
+    ['notifications', 'count'],
+    (key, { next }) =>
+      subscribe('notifications.count', (value: number) => next(null, value)),
+  )
+
+  return <span>{count ?? 0}</span>
+}
+```
+
+Плюсы: кеш и дедупликация подписки между несколькими местами рендера; единая модель данных с REST.
+
+## Прямая подписка
+
+Для побочных эффектов, которые не влияют на состояние UI напрямую:
+
+```tsx
+'use client'
+
+import { useEffect } from 'react'
+import { subscribe } from 'infrastructure/notifications'
+import { showToast } from 'ui/toast'
+
+export function NotificationsToaster() {
+  useEffect(() => {
+    return subscribe('notifications.new', (notification) => {
+      showToast(notification.message)
+    })
+  }, [])
+
+  return null
+}
+```
+
+Возврат `unsubscribe` из `useEffect` обязателен — иначе утечка подписки.
+
+## Запрет прямых соединений
+
+Создавать `new WebSocket(...)`, `new EventSource(...)` или подписываться на событийные шины напрямую в коде приложения — запрещено. Все соединения проходят через клиент в `infrastructure/`.
+
+Исключения — точечные и обоснованные (например, диагностический скрипт), помечаются комментарием.
--- a/docs/docs/usage/data/rest/clients/auto.md
+++ b/docs/docs/usage/data/rest/clients/auto.md
@@ -0,0 +1,279 @@
+---
+title: Автогенерация REST-клиента
+description: Генерация REST-клиента из OpenAPI-спецификации.
+keywords: [api, rest, openapi, codegen, генерация, клиент, api-codegen, gromlab, infrastructure, swagger-typescript-api]
+---
+
+# Автогенерация REST-клиента
+
+Генерация REST-клиента из OpenAPI-спецификации.
+
+В примерах ниже используется условный API `pet-project-api` (kebab-case в путях) / `petProjectApi` (camelCase в коде). В реальном проекте имена выбираются по конкретному API.
+
+## Установка
+
+```bash
+npm install -D @gromlab/api-codegen
+```
+
+Скрипт генерации в `package.json` — по одному на каждый API:
+
+```json
+{
+  "scripts": {
+    "codegen:pet-project-api": "api-codegen --config src/infrastructure/pet-project-api/config/pet-project-api.config.ts"
+  }
+}
+```
+
+Конфиг и опции — в репозитории [@gromlab/api-codegen](https://gromlab.ru/gromov/api-codegen).
+
+## Структура модуля
+
+Клиент кладётся в слой `infrastructure/` отдельным модулем по имени API (kebab-case):
+
+```text
+src/infrastructure/
+└── pet-project-api/
+    ├── generated/                          # сегмент сгенерированного кода
+    │   └── pet-project-api.generated.ts    # сгенерировано — не править
+    ├── types/                              # расширения сгенерированных типов
+    │   ├── user.ts                         # declare module + Extended-тип
+    │   └── index.ts                        # реэкспорт расширений
+    ├── hooks/                              # SWR-хуки для клиентских компонентов
+    │   ├── use-user-list.hook.ts
+    │   ├── use-user-detail.hook.ts
+    │   └── index.ts                        # реэкспорт хуков
+    ├── config/                             # конфиги модуля
+    │   └── pet-project-api.config.ts        # конфиг генерации клиента
+    ├── client.ts                           # настройка HttpClient, инстанс Api
+    └── index.ts                            # публичный API модуля
+```
+
+| Файл | Роль | Кто правит |
+|------|------|-----------|
+| `generated/{service-name}.generated.ts` | Сгенерированный код: типы, `class Api`, `class HttpClient` | codegen, не править |
+| `types/{сущность}.ts` | `declare module` + `Extended`-типы по сущности | разработчик |
+| `types/index.ts` | Реэкспорт публичных расширений | разработчик |
+| `hooks/use-{action}.hook.ts` | SWR-хук поверх метода клиента | разработчик |
+| `hooks/index.ts` | Реэкспорт хуков | разработчик |
+| `config/{service-name}.config.ts` | Параметры генерации для конкретного API | разработчик |
+| `client.ts` | `baseUrl` из env, конфиг `HttpClient`, инстанс `new Api(...)` | разработчик |
+| `index.ts` | Публичный API: инстанс сервиса, расширенные типы, хуки | разработчик |
+
+`client.ts` и `index.ts` — единственные корневые файлы модуля. Все остальные файлы живут в сегментах (`generated/`, `types/`, `hooks/`, `config/`).
+
+Имя сгенерированного файла — `{service-name}.generated.ts` (имя сервиса в kebab-case + суффикс `.generated.ts`). Суффикс сигнализирует «не править руками».
+
+## `client.ts`
+
+Тонкий ручной слой поверх сгенерированного кода. Делает три вещи: читает и нормализует `baseUrl`, конфигурирует `HttpClient`, создаёт **именованный инстанс** сервиса.
+
+```ts
+// src/infrastructure/pet-project-api/client.ts
+import { Api, HttpClient } from './generated/pet-project-api.generated'
+
+const resolvedBaseUrl = process.env.NEXT_PUBLIC_API_URL
+  .replace(/\/+$/, '')   // убираем хвостовой слэш
+  .replace(/\/v1$/, '')  // версия уже в путях методов — режем дубль
+
+const httpClient = new HttpClient({
+  baseApiParams: {
+    secure: false,
+    headers: {
+      'Content-Type': 'application/json',
+      // кастомные заголовки API — если требуются
+      // 'X-App-Key': '...',
+    },
+  },
+})
+
+httpClient.baseUrl = resolvedBaseUrl
+
+export const petProjectApi = new Api(httpClient)
+```
+
+### Имя инстанса = имя сервиса
+
+Инстанс называется по имени API в camelCase, не унифицированно `api`/`client`. Это даёт **процедурное обращение** и однозначность при работе с несколькими сервисами:
+
+```ts
+import { petProjectApi } from 'infrastructure/pet-project-api'
+
+const user = await petProjectApi.user.getUser(id)
+```
+
+При нескольких API — каждый со своим именем:
+
+```ts
+import { petProjectApi } from 'infrastructure/pet-project-api'
+import { paymentsApi } from 'infrastructure/payments-api'
+
+const user = await petProjectApi.user.list()
+const invoice = await paymentsApi.invoices.list()
+```
+
+### Нормализация `baseUrl`
+
+`@gromlab/api-codegen` может включать версию (`/v1`) в `baseUrl` сгенерированного кода, а пути методов уже содержат её — отсюда дубль. Стандартный приём:
+
+```ts
+.replace(/\/+$/, '')   // хвостовой слэш
+.replace(/\/v1$/, '')  // версия (если фигурирует в путях)
+```
+
+Подгоняется под конкретный API: если версия в путях не повторяется — второй `replace` не нужен.
+
+## Расширения типов
+
+Автогенерация не покрывает все реальные поля API: иногда тип `object`, иногда поле просто отсутствует. Расширения живут в `types/`, по файлу на сущность.
+
+Две техники:
+
+### `declare module` — добавление полей
+
+Дополняет существующий интерфейс из `generated.ts`. Сама сгенерированная декларация не трогается.
+
+```ts
+// src/infrastructure/pet-project-api/types/user.ts
+import type { User } from '../generated/pet-project-api.generated'
+
+declare module '../generated/pet-project-api.generated' {
+  interface User {
+    avatar?: {
+      file?: string
+      title?: string
+      url?: string
+    }
+  }
+}
+```
+
+### `Extended` через `Omit & {...}` — переопределение полей
+
+Когда автогенерация даёт `object` или общий тип, а реально структура известна — создаётся отдельный тип `UserExtended` (по имени сущности + суффикс `Extended`).
+
+```ts
+// src/infrastructure/pet-project-api/types/user.ts
+export type UserExtended = Omit<User, 'roles' | 'tags' | 'fields'> & {
+  roles?: Array<{ _id?: string; id?: string; slug?: string; name?: string }>
+  tags?: Array<{ _id?: string; id?: string; slug?: string; name?: string }>
+  fields?: Record<string, unknown>
+}
+```
+
+### Реэкспорт
+
+```ts
+// src/infrastructure/pet-project-api/types/index.ts
+export type { UserExtended } from './user'
+```
+
+### Правила
+
+- Расширения — **только в `types/`**, не в `client.ts` и не в сгенерированном файле.
+- Один файл на сущность (имя файла — kebab-case по сущности: `user.ts`, `order.ts`, `invoice.ts`).
+- При регенерации `generated/{service-name}.generated.ts` файлы в `types/` не затрагиваются.
+- Если сломался `Extended`-тип после regen — синхронизировать руками.
+
+## Хуки для клиентских компонентов
+
+В клиентских компонентах вызовы клиента не делаются напрямую — компонент получает готовый хук, который инкапсулирует SWR + метод клиента. Хуки живут в сегменте `hooks/`, по файлу на операцию.
+
+```ts
+// src/infrastructure/pet-project-api/hooks/use-user-list.hook.ts
+import useSWR from 'swr'
+import type { SWRConfiguration } from 'swr'
+import { petProjectApi } from '../client'
+import type { User } from '../generated/pet-project-api.generated'
+
+/**
+ * Получение списка пользователей.
+ */
+export const useUserList = (
+  query?: { limit?: number; offset?: number },
+  config?: SWRConfiguration,
+) => {
+  return useSWR<User[]>(
+    ['pet-project-api', 'user', 'list', query],
+    () => petProjectApi.user.list(query ?? {}),
+    config,
+  )
+}
+```
+
+```ts
+// src/infrastructure/pet-project-api/hooks/use-user-detail.hook.ts
+import useSWR from 'swr'
+import type { SWRConfiguration } from 'swr'
+import { petProjectApi } from '../client'
+import type { UserExtended } from '../types'
+
+/**
+ * Получение пользователя по идентификатору.
+ */
+export const useUserDetail = (
+  id: string | null,
+  config?: SWRConfiguration,
+) => {
+  const key = id ? ['pet-project-api', 'user', 'detail', id] : null
+  const fetcher = () => petProjectApi.user.getUser(id!) as Promise<UserExtended>
+
+  return useSWR<UserExtended>(key, fetcher, config)
+}
+```
+
+```ts
+// src/infrastructure/pet-project-api/hooks/index.ts
+export { useUserList } from './use-user-list.hook'
+export { useUserDetail } from './use-user-detail.hook'
+```
+
+### Правила хуков
+
+- **Один файл — один хук**, имя файла `use-{action}.hook.ts` ([Именование](/docs/basics/naming)).
+- **Тонкая обёртка над SWR.** Внутри — построение ключа, fetcher через метод клиента, возврат `useSWR(...)`. Никакой бизнес-логики.
+- **Ключ начинается с имени сервиса** (`['pet-project-api', ...]`) — изолирует кеш между разными API.
+- **Условный ключ для опциональных параметров:** `id ? [...key, id] : null`. `null` приостанавливает запрос, пока параметры не готовы.
+- **Параметр `config?: SWRConfiguration`** — даёт потребителю переопределить ревалидацию, `fallbackData`, `suspense` и т.п. без обёрток.
+
+## Публичный API модуля
+
+Из `index.ts` экспортируются инстанс, расширенные типы и хуки. Сырые типы из `generated/` экспортируются по необходимости — точечно.
+
+```ts
+// src/infrastructure/pet-project-api/index.ts
+export { petProjectApi } from './client'
+export type { UserExtended } from './types'
+export * from './hooks'
+```
+
+## Регенерация
+
+При изменении OpenAPI-схемы:
+
+```bash
+npm run codegen:pet-project-api
+```
+
+Что меняется:
+
+- `generated/{service-name}.generated.ts` — перезаписывается полностью, изменения коммитятся.
+- `client.ts`, `types/`, `config/`, `index.ts` — **не трогаются** автоматически.
+
+Поломка контракта (изменение типов в схеме) ловится TypeScript при сборке проекта. Если ломаются `Extended`-типы — синхронизировать вручную в соответствующих файлах `types/`.
+
+## Сгенерированный файл коммитится
+
+Файл `generated/{service-name}.generated.ts` **не добавляется в `.gitignore`** — попадает в репозиторий вместе с остальным кодом.
+
+Причины:
+
+- **Детерминированная сборка.** `npm run build` не зависит от доступности OpenAPI-схемы (обычно она на удалённом сервере). Сервис лёг — прод собирается.
+- **Видимость изменений в PR.** Diff показывает, что именно поменялось в контракте API между версиями.
+- **Простой онбординг.** После `git clone` IDE сразу видит типы, без предварительной генерации.
+- **Фиксация версии контракта.** Пересборка старого коммита даёт ровно тот клиент, что был тогда.
+
+Регенерация — **ручная команда** при обновлении схемы, не хук `predev`/`prebuild`. Запускается осознанно.
+
+Исключение возможно, только если OpenAPI-схема лежит **в этом же репозитории** и генерация быстрая, без сети — тогда допустимо добавить сегмент `generated/` в `.gitignore` и хук `prebuild`, по аналогии со спрайтами. На практике встречается редко.
--- a/docs/docs/usage/data/rest/clients/manual.md
+++ b/docs/docs/usage/data/rest/clients/manual.md
@@ -0,0 +1,365 @@
+---
+title: Ручное создание REST-клиента
+description: "Создание REST-клиента вручную, когда нет OpenAPI-спецификации."
+keywords: [api, rest, клиент, ручной, fetch, infrastructure, api-клиент]
+---
+
+# Ручное создание REST-клиента
+
+Создание REST-клиента вручную, когда нет OpenAPI-спецификации.
+
+В примерах ниже используется условный API `pet-project-api` / `petProjectApi`. В реальном проекте имена выбираются по конкретному API.
+
+## Структура модуля
+
+Клиент живёт в слое `infrastructure/` отдельным модулем по имени API (kebab-case):
+
+```text
+src/infrastructure/
+└── pet-project-api/
+    ├── methods/                            # методы по сущностям API
+    │   ├── pages.ts
+    │   ├── posts.ts
+    │   └── forms.ts
+    ├── hooks/                              # SWR-хуки для клиентских компонентов
+    │   ├── use-post-detail.hook.ts
+    │   ├── use-post-filter.hook.ts
+    │   └── index.ts
+    ├── types/                              # типы клиента и доменные типы
+    │   ├── client.ts                       # типы клиента: RequestOptions, ParamValue
+    │   ├── post.ts                         # доменные типы сущности post
+    │   ├── form.ts                         # доменные типы сущности form
+    │   └── index.ts                        # реэкспорт публичных типов
+    ├── errors/                             # доменные ошибки API
+    │   └── pet-project-api.error.ts
+    ├── client.ts                           # класс клиента: baseUrl, headers, get/post
+    └── index.ts                            # публичный API модуля
+```
+
+| Файл | Роль |
+|------|------|
+| `client.ts` | Класс `PetProjectApiClient`: `baseUrl`, общие заголовки, `buildUrl`, базовые `get`/`post` |
+| `methods/{entity}.ts` | Методы по сущности, экспортируются фабрикой `{entity}Methods(client)` |
+| `hooks/use-{action}.hook.ts` | SWR-хук поверх метода клиента |
+| `hooks/index.ts` | Реэкспорт хуков |
+| `types/client.ts` | Типы инфраструктуры клиента: `RequestOptions`, `PostOptions`, `ParamValue` |
+| `types/{entity}.ts` | Доменные типы: запросы, ответы, фильтры по сущности |
+| `types/index.ts` | Реэкспорт публичных типов |
+| `errors/{service-name}.error.ts` | Доменный класс ошибок API |
+| `index.ts` | Публичный API: инстанс клиента, хуки, доменные ошибки, типы |
+
+`methods/`, `hooks/`, `types/`, `errors/` — сегменты модуля по канону SLM. `client.ts` и `index.ts` — единственные корневые файлы.
+
+## Типы клиента
+
+Типы, описывающие саму инфраструктуру запросов (опции, параметры) — выносятся в `types/client.ts`. Это держит `client.ts` коротким и не смешивает декларации типов с реализацией класса.
+
+```ts
+// src/infrastructure/pet-project-api/types/client.ts
+export type ParamValue = string | number | (string | number)[]
+
+export type RequestOptions = {
+  params?: Record<string, ParamValue>
+  headers?: Record<string, string>
+  revalidate?: number | false
+}
+
+export type PostOptions = RequestOptions & {
+  type?: 'json' | 'formdata'
+}
+```
+
+## Базовый клиент
+
+Класс с конфигурацией (`baseUrl`, общие заголовки) и базовыми методами `get` / `post`. Конкретные методы API размещаются в сегменте `methods/`, а не на самом классе — это держит `client.ts` коротким и не плодит «бога-класс».
+
+```ts
+// src/infrastructure/pet-project-api/client.ts
+import { PetProjectApiError } from './errors/pet-project-api.error'
+import type { ParamValue, RequestOptions, PostOptions } from './types/client'
+
+export class PetProjectApiClient {
+  constructor(
+    private readonly baseUrl: string,
+    private readonly defaultHeaders: Record<string, string> = {},
+  ) {
+    this.defaultHeaders = {
+      Accept: 'application/json',
+      ...defaultHeaders,
+    }
+  }
+
+  buildUrl(path: string, params?: Record<string, ParamValue>): string {
+    const base = this.baseUrl.replace(/\/+$/, '')
+    const tail = path.replace(/^\/+/, '')
+    const url = `${base}/${tail}`
+
+    if (!params) {
+      return url
+    }
+
+    const search = new URLSearchParams()
+    for (const [key, value] of Object.entries(params)) {
+      if (Array.isArray(value)) {
+        value.forEach((v) => search.append(key, String(v)))
+      } else {
+        search.set(key, String(value))
+      }
+    }
+
+    return `${url}?${search}`
+  }
+
+  async get<T>(path: string, options: RequestOptions = {}): Promise<T> {
+    const { params, headers, revalidate } = options
+    const response = await fetch(this.buildUrl(path, params), {
+      headers: { ...this.defaultHeaders, ...headers },
+      ...(revalidate !== undefined && { next: { revalidate } }),
+    })
+
+    if (!response.ok) {
+      throw await PetProjectApiError.fromResponse(response)
+    }
+
+    return response.json() as Promise<T>
+  }
+
+  async post<T>(path: string, body: unknown, options: PostOptions = {}): Promise<T> {
+    const { params, headers, revalidate, type = 'json' } = options
+    const isJson = type === 'json'
+
+    const response = await fetch(this.buildUrl(path, params), {
+      method: 'POST',
+      headers: {
+        ...this.defaultHeaders,
+        ...(isJson && { 'Content-Type': 'application/json' }),
+        ...headers,
+      },
+      body: isJson ? JSON.stringify(body) : (body as BodyInit),
+      ...(revalidate !== undefined && { next: { revalidate } }),
+    })
+
+    if (!response.ok) {
+      throw await PetProjectApiError.fromResponse(response)
+    }
+
+    return response.json() as Promise<T>
+  }
+}
+```
+
+### Ключевые требования к клиенту
+
+- **Класс с приватным состоянием** (`baseUrl`, `defaultHeaders`) — конфигурация инкапсулирована.
+- **Типы клиента — в `types/client.ts`**, не в `client.ts`. Реализация и контракты разделены.
+- **Базовые методы дженерик `<T>` без дефолта.** Вызов без типа невозможен — потребитель обязан указать форму ответа.
+- **Доменная ошибка вместо `null`.** При не-`ok` бросается `PetProjectApiError`. Возврат `null` глотает причины (404 vs 500 vs 401) — не использовать.
+- **Дефолт POST — `json`.** `formdata` указывается явно, на конкретных методах (загрузка файлов, отправка форм).
+- **Нормализация слэшей** в `buildUrl` — `baseUrl` без хвостового `/`, `path` без ведущего `/`.
+- **`async/await`**, не `.then()` — линейное чтение, простая обработка ошибок.
+- **Поддержка `next.revalidate`** — клиент знает о Next.js App Router и пробрасывает кеш-флаги.
+
+## Доменная ошибка
+
+Сетевая ошибка превращается в класс ошибки модуля. Наружу не выходит сырой `Response`.
+
+```ts
+// src/infrastructure/pet-project-api/errors/pet-project-api.error.ts
+export class PetProjectApiError extends Error {
+  constructor(
+    public readonly status: number,
+    public readonly body: string,
+  ) {
+    super(`PetProjectApi ${status}: ${body.slice(0, 200)}`)
+    this.name = 'PetProjectApiError'
+  }
+
+  static async fromResponse(response: Response): Promise<PetProjectApiError> {
+    const body = await response.text().catch(() => '')
+    return new PetProjectApiError(response.status, body)
+  }
+}
+```
+
+Дополнительные подклассы по необходимости: `PetProjectApiValidationError` (400), `PetProjectApiAuthError` (401/403), `PetProjectApiNotFoundError` (404). Вводятся когда у потребителя есть **разная реакция** на разные коды; иначе хватает базового класса.
+
+## Доменные типы
+
+Типы запросов, ответов и фильтров — по файлу на сущность. Типы должны лежать рядом по смыслу: всё, что относится к `posts`, — в `types/post.ts`.
+
+```ts
+// src/infrastructure/pet-project-api/types/post.ts
+export type Post = {
+  id: string
+  slug: string
+  title: string
+  content: string
+  publishedAt: string
+}
+
+export type PostFilter = {
+  limit?: number
+  categories?: number[]
+}
+```
+
+```ts
+// src/infrastructure/pet-project-api/types/index.ts
+export type * from './post'
+export type * from './form'
+// типы клиента — внутренние, наружу не реэкспортируются
+```
+
+Типы клиента (`RequestOptions`, `PostOptions`, `ParamValue`) **не реэкспортируются** через `types/index.ts` — они нужны только внутри модуля.
+
+## Методы
+
+Методы группируются по сущностям в сегменте `methods/`, экспортируются фабрикой, принимающей клиент. Это даёт **процедурное обращение** в стиле автогенерированного клиента (`petProjectApi.posts.get(slug)`), а не плоский список (`petProjectApi.getPost(slug)`).
+
+```ts
+// src/infrastructure/pet-project-api/methods/posts.ts
+import type { PetProjectApiClient } from '../client'
+import type { Post, PostFilter } from '../types/post'
+
+export function postsMethods(client: PetProjectApiClient) {
+  return {
+    /** GET /posts/{slug} */
+    get: (slug: string, options?: { revalidate?: number | false }) =>
+      client.get<Post>(`posts/${slug}`, options),
+
+    /** POST /posts/filter */
+    filter: (body: PostFilter) =>
+      client.post<Post[]>('posts/filter', body),
+  }
+}
+```
+
+```ts
+// src/infrastructure/pet-project-api/methods/forms.ts
+import type { PetProjectApiClient } from '../client'
+import type { Form, FormSubmissionResult } from '../types/form'
+
+export function formsMethods(client: PetProjectApiClient) {
+  return {
+    /** GET /forms/{id} */
+    get: (id: string) => client.get<Form>(`forms/${id}`),
+
+    /** POST /forms/{id} — multipart/form-data */
+    submit: (id: string, data: FormData) =>
+      client.post<FormSubmissionResult>(`forms/${id}`, data, { type: 'formdata' }),
+  }
+}
+```
+
+### Правила методов
+
+- **Группировка по сущности** (`pages`, `posts`, `forms`), не плоский список.
+- **Имя метода — глагол действия**: `get`, `list`, `filter`, `create`, `update`, `delete`, `submit`. Не `getPost`/`getPosts` — сущность уже в имени группы.
+- **Типы запросов и ответов — в `types/{entity}.ts`**, импортируются в файл методов. В `methods/` лежит только композиция вызовов клиента, без объявлений типов.
+- **Фабрика принимает клиент** — это даёт тестируемость (моковый клиент в юнит-тестах) и единый источник конфигурации.
+- **Никаких знаний об UI.** Клиент не знает про React, SWR, тосты — только данные и ошибки.
+
+## Сборка инстанса
+
+Группы методов соединяются в один объект на уровне `index.ts`. Это даёт процедурный доступ `petProjectApi.posts.get(...)`.
+
+```ts
+// src/infrastructure/pet-project-api/index.ts
+import { PetProjectApiClient } from './client'
+import { pagesMethods } from './methods/pages'
+import { postsMethods } from './methods/posts'
+import { formsMethods } from './methods/forms'
+
+const client = new PetProjectApiClient(process.env.NEXT_PUBLIC_API_URL, {
+  'X-App-Key': process.env.NEXT_PUBLIC_APP_KEY,
+})
+
+export const petProjectApi = {
+  pages: pagesMethods(client),
+  posts: postsMethods(client),
+  forms: formsMethods(client),
+}
+
+export { PetProjectApiError } from './errors/pet-project-api.error'
+export type { Post, PostFilter, Page, Form } from './types'
+export * from './hooks'
+```
+
+## Хуки для клиентских компонентов
+
+В клиентских компонентах вызовы клиента не делаются напрямую — компонент получает готовый хук, который инкапсулирует SWR + метод клиента. Хуки живут в сегменте `hooks/`, по файлу на операцию.
+
+```ts
+// src/infrastructure/pet-project-api/hooks/use-post-detail.hook.ts
+import useSWR from 'swr'
+import type { SWRConfiguration } from 'swr'
+import { petProjectApi } from '..'
+import type { Post } from '../types/post'
+
+/**
+ * Получение поста по slug.
+ */
+export const usePostDetail = (
+  slug: string | null,
+  config?: SWRConfiguration,
+) => {
+  const key = slug ? ['pet-project-api', 'post', 'detail', slug] : null
+  const fetcher = () => petProjectApi.posts.get(slug!)
+
+  return useSWR<Post>(key, fetcher, config)
+}
+```
+
+```ts
+// src/infrastructure/pet-project-api/hooks/use-post-filter.hook.ts
+import useSWR from 'swr'
+import type { SWRConfiguration } from 'swr'
+import { petProjectApi } from '..'
+import type { Post, PostFilter } from '../types/post'
+
+/**
+ * Получение списка постов по фильтру.
+ */
+export const usePostFilter = (
+  filter: PostFilter,
+  config?: SWRConfiguration,
+) => {
+  return useSWR<Post[]>(
+    ['pet-project-api', 'post', 'filter', filter],
+    () => petProjectApi.posts.filter(filter),
+    config,
+  )
+}
+```
+
+```ts
+// src/infrastructure/pet-project-api/hooks/index.ts
+export { usePostDetail } from './use-post-detail.hook'
+export { usePostFilter } from './use-post-filter.hook'
+```
+
+### Правила хуков
+
+- **Один файл — один хук**, имя файла `use-{action}.hook.ts` ([Именование](/docs/basics/naming)).
+- **Тонкая обёртка над SWR.** Внутри — построение ключа, fetcher через метод клиента, возврат `useSWR(...)`. Никакой бизнес-логики.
+- **Ключ начинается с имени сервиса** (`['pet-project-api', ...]`) — изолирует кеш между разными API.
+- **Условный ключ для опциональных параметров:** `id ? [...key, id] : null`. `null` приостанавливает запрос, пока параметры не готовы.
+- **Параметр `config?: SWRConfiguration`** — даёт потребителю переопределить ревалидацию, `fallbackData`, `suspense` и т.п. без обёрток.
+
+## Запрет прямого `fetch`
+
+В коде приложения (слои выше `infrastructure`) прямые вызовы `fetch` к API запрещены. Все запросы идут через клиент.
+
+Исключение допускается точечно — например, разовая отладочная проверка эндпоинта в скрипте — и требует обоснования в коде (комментарий с причиной).
+
+## Использование
+
+```ts
+import { petProjectApi } from 'infrastructure/pet-project-api'
+
+const post = await petProjectApi.posts.get('my-post')
+const list = await petProjectApi.posts.filter({ limit: 10, categories: [1, 2] })
+const form = await petProjectApi.forms.get('contact')
+```
+
+Стиль вызовов совпадает с автогенерированным клиентом — потребитель не различает, ручной API или сгенерирован.
--- a/docs/docs/usage/data/rest/fetching/client.md
+++ b/docs/docs/usage/data/rest/fetching/client.md
@@ -0,0 +1,164 @@
+---
+title: Клиентские компоненты
+description: Получение REST-данных в клиентских компонентах.
+keywords: [swr, клиентские компоненты, useSWR, хук, мутация, useSWRMutation, кеш, ревалидация]
+---
+
+# Клиентские компоненты
+
+Получение REST-данных в клиентских компонентах.
+
+## Правила
+
+- **Только готовые хуки.** В компоненте — `usePostDetail(slug)`, не `useSWR(['post', slug], () => api.posts.get(slug))`.
+- **`useSWR` пишется один раз — в `hooks/`** модуля API. В клиентских компонентах никогда напрямую.
+- **Прямой вызов методов клиента в `useEffect` запрещён.** Это потеря кеша, повторные запросы и гонки.
+- **Мутации — через `useSWRMutation`**, тоже инкапсулированный в хуке. В компоненте вызывается готовый `trigger`.
+
+## Чтение
+
+```tsx
+'use client'
+
+import { usePostDetail } from 'infrastructure/pet-project-api'
+
+export function PostView({ slug }: { slug: string }) {
+  const { data: post, error, isLoading } = usePostDetail(slug)
+
+  if (isLoading) return <Spinner />
+  if (error) return <ErrorView error={error} />
+
+  return <article>{post?.title}</article>
+}
+```
+
+В компоненте нет `useSWR`, нет ключей, нет fetcher — только готовый хук.
+
+## Параметризованный запрос
+
+Хук сам обрабатывает «нет параметра — нет запроса». В компоненте можно безопасно передавать `null`:
+
+```tsx
+'use client'
+
+import { useUserDetail } from 'infrastructure/pet-project-api'
+
+export function UserProfile({ userId }: { userId: string | null }) {
+  const { data: user } = useUserDetail(userId)
+
+  if (!userId) return <EmptyState />
+  return <UserCard user={user} />
+}
+```
+
+Внутри `useUserDetail` ключ становится `null`, когда `userId` не задан, и SWR не делает запрос — это поведение зашито в хук, потребитель об этом не думает.
+
+## Мутации
+
+Мутации тоже оборачиваются в хук модуля API:
+
+```ts
+// src/infrastructure/pet-project-api/hooks/use-create-user.hook.ts
+import useSWRMutation from 'swr/mutation'
+import { mutate } from 'swr'
+import { petProjectApi } from '..'
+import type { User, UserCreateInput } from '../types'
+
+/**
+ * Создание пользователя с инвалидацией списка.
+ */
+export const useCreateUser = () => {
+  return useSWRMutation<User, Error, [string, string, string], UserCreateInput>(
+    ['pet-project-api', 'user', 'create'],
+    (_key, { arg }) => petProjectApi.user.create(arg),
+    {
+      onSuccess: () => mutate(['pet-project-api', 'user', 'list']),
+    },
+  )
+}
+```
+
+```tsx
+'use client'
+
+import { useCreateUser } from 'infrastructure/pet-project-api'
+
+export function CreateUserForm() {
+  const { trigger, isMutating } = useCreateUser()
+
+  return (
+    <Form
+      onSubmit={(input) => trigger(input)}
+      disabled={isMutating}
+    />
+  )
+}
+```
+
+В компоненте — снова только хук. Логика инвалидации кеша зашита внутрь, потребитель её не дублирует.
+
+## Передача config из компонента
+
+Каждый хук принимает второй (или третий) параметр `config?: SWRConfiguration` — он пробрасывается в `useSWR`. Это даёт потребителю точечно настроить ревалидацию, `fallbackData`, `suspense` и т.п.:
+
+```tsx
+'use client'
+
+import { usePostDetail } from 'infrastructure/pet-project-api'
+
+export function PostView({ slug, initialPost }: Props) {
+  const { data: post } = usePostDetail(slug, { fallbackData: initialPost })
+  // ...
+}
+```
+
+## Начальное состояние с сервера
+
+Если данные пришли из серверного компонента (см. [Серверные компоненты](/docs/usage/data/rest/fetching/server)) — передаются в `fallbackData` через `config` хука:
+
+```tsx
+// page.tsx (server)
+import { petProjectApi } from 'infrastructure/pet-project-api'
+
+export default async function Page({ params }: { params: { slug: string } }) {
+  const initialPost = await petProjectApi.posts.get(params.slug)
+  return <PostView slug={params.slug} initialPost={initialPost} />
+}
+```
+
+```tsx
+// post-view.tsx ('use client')
+import { usePostDetail } from 'infrastructure/pet-project-api'
+
+export function PostView({ slug, initialPost }: Props) {
+  const { data: post } = usePostDetail(slug, { fallbackData: initialPost })
+  return <article>{post?.title}</article>
+}
+```
+
+Для массового заполнения кеша на странице с несколькими хуками — используется `<SWRConfig fallback>` обёртка. Серверный компонент собирает данные и передаёт сериализованную карту ключей в провайдер; все вложенные хуки сразу видят кеш.
+
+## Запрет прямых вызовов
+
+```tsx
+// Плохо — прямой fetch в обход клиента
+useEffect(() => {
+  fetch('/api/users').then(...)
+}, [])
+
+// Плохо — клиент без SWR: нет кеша, нет дедупликации
+useEffect(() => {
+  petProjectApi.user.list().then(setUsers)
+}, [])
+
+// Плохо — useSWR в компоненте: SWR должен быть в хуке модуля
+const { data } = useSWR(
+  ['pet-project-api', 'user', 'list'],
+  () => petProjectApi.user.list(),
+)
+
+// Хорошо — готовый хук модуля
+const { data } = useUserList()
+```
+
+Если для нужной операции хука ещё нет — он добавляется в `hooks/` модуля API, не в компонент.
--- a/docs/docs/usage/data/rest/fetching/server.md
+++ b/docs/docs/usage/data/rest/fetching/server.md
@@ -0,0 +1,66 @@
+---
+title: Серверные компоненты
+description: Получение REST-данных в серверных компонентах.
+keywords: [server components, rsc, серверные компоненты, fetch, api, app router, прямой вызов]
+---
+
+# Серверные компоненты
+
+Получение REST-данных в серверных компонентах.
+
+## Правила
+
+- **Прямой `await` метода клиента.** Никаких хуков, обёрток состояний, `useEffect` — серверный компонент не имеет жизненного цикла React-клиента.
+- **Ошибки бросаются.** Не оборачивать `try/catch` без необходимости — Next.js поднимет ближайший `error.tsx`.
+- **Параллельные запросы — через `Promise.all`.** Последовательный `await` за `await` блокирует рендер.
+
+## Шаблон
+
+```tsx
+// src/app/(routes)/users/page.tsx
+import { petProjectApi } from 'infrastructure/pet-project-api'
+
+export default async function UsersPage() {
+  const users = await petProjectApi.user.list()
+
+  return (
+    <ul>
+      {users.map((user) => (
+        <li key={user.id}>{user.name}</li>
+      ))}
+    </ul>
+  )
+}
+```
+
+## Параллельные запросы
+
+```tsx
+export default async function DashboardPage() {
+  const [users, orders] = await Promise.all([
+    petProjectApi.user.list(),
+    petProjectApi.order.list(),
+  ])
+
+  return <Dashboard users={users} orders={orders} />
+}
+```
+
+## Передача данных в клиентский компонент
+
+Серверный компонент получает данные и передаёт их пропсами в клиентский. На клиенте данные становятся начальным состоянием — при необходимости перезапрашиваются через SWR (см. [Клиентские компоненты](/docs/usage/data/rest/fetching/client)).
+
+```tsx
+// page.tsx (server)
+import { petProjectApi } from 'infrastructure/pet-project-api'
+import { UsersList } from 'widgets/users-list'
+
+export default async function UsersPage() {
+  const initialUsers = await petProjectApi.user.list()
+  return <UsersList initialUsers={initialUsers} />
+}
+```
+
+## Запрет прямого `fetch`
+
+Серверный компонент тоже использует только клиент из `infrastructure/`. Прямой `fetch` в `page.tsx` или в server-action запрещён теми же правилами, что и на клиенте.
--- a/docs/docs/usage/fonts.md
+++ b/docs/docs/usage/fonts.md
--- a/docs/docs/usage/hooks.md
+++ b/docs/docs/usage/hooks.md
--- a/docs/docs/usage/images-sprites.md
+++ b/docs/docs/usage/images-sprites.md
--- a/docs/docs/usage/localization.md
+++ b/docs/docs/usage/localization.md
--- a/docs/docs/usage/page-level.md
+++ b/docs/docs/usage/page-level.md
@@ -1,10 +1,11 @@
 ---
 title: Файлы роутинга
+description: "Что должно лежать в файлах роутинга, а что — в экранах."
 ---

 # Файлы роутинга

-Правила для специальных файлов App Router (`page.tsx`, `layout.tsx`, `error.tsx`, `not-found.tsx` и др.) — чем наш подход отличается от дефолтного.
+Что должно лежать в файлах роутинга, а что — в экранах.

 ## Организация

--- a/docs/docs/usage/project-structure.md
+++ b/docs/docs/usage/project-structure.md
@@ -1,10 +1,11 @@
 ---
 title: Структура проекта
+description: Из чего состоит проект и где что лежит.
 ---

 # Структура проекта

-Раздел описывает расположение файлов и папок в проекте Next.js (App Router).
+Из чего состоит проект и где что лежит.

 ## Корень репозитория

--- a/docs/docs/usage/stores.md
+++ b/docs/docs/usage/stores.md
--- a/docs/docs/usage/styles.md
+++ b/docs/docs/usage/styles.md
@@ -1,10 +1,11 @@
 ---
 title: Стили
+description: Как пишутся стили в проекте.
 ---

 # Стили

-Раздел описывает правила написания CSS: PostCSS Modules, вложенность, медиа-запросы, переменные, форматирование.
+Как пишутся стили в проекте.

 ## Общие правила

--- a/docs/docs/usage/svg-sprites.md
+++ b/docs/docs/usage/svg-sprites.md
@@ -0,0 +1,56 @@
+---
+title: SVG-спрайты
+description: Как добавлять и использовать SVG-иконки в коде.
+keywords: [svg, спрайт, sprite, иконка, icon, SvgSprite, превью, preview, цвет, color]
+---
+
+# SVG-спрайты
+
+Как добавлять и использовать SVG-иконки в коде.
+
+## Шаги
+
+1. **Положить SVG в папку спрайта:**
+
+   ```text
+   src/shared/sprites/icons/new-icon.svg
+   ```
+
+2. **Импортировать компонент.** Компонент `<SvgSprite/>` генерируется пакетом вместе с типами имён иконок — автодополнение работает без ручных описаний:
+
+   ```tsx
+   import { SvgSprite } from 'ui/svg-sprite'
+
+   <SvgSprite icon="new-icon" />
+   ```
+
+3. **Посмотреть и пощупать иконку — в превью.** Пакет генерирует HTML-превью рядом со спрайтом (`public/sprites/icons.preview.html`). Там виден набор иконок, имена и поведение цвета.
+
+## Управление цветом
+
+При сборке цвета в SVG заменяются на CSS-переменные `--icon-color-N`. Управление — через обычный CSS родителя.
+
+**Моно-иконка** наследует `color` родителя (`--icon-color-1` по умолчанию `currentColor`):
+
+```css
+.button {
+  color: var(--color-primary);
+}
+```
+
+**Точечное переопределение** — через переменную:
+
+```css
+.icon-danger {
+  --icon-color-1: var(--color-danger);
+}
+```
+
+**Мульти-иконка** — переменные задаются явно, порядок виден в превью:
+
+```css
+.folder {
+  --icon-color-1: var(--color-folder-bg);
+  --icon-color-2: var(--color-folder-accent);
+}
+```
--- a/docs/docs/usage/templates-generation.md
+++ b/docs/docs/usage/templates-generation.md
@@ -1,5 +1,6 @@
 ---
 title: Шаблоны и генерация кода
+description: Как устроены шаблоны кодогенерации и как ими пользоваться.
 ---

 <!-- @formatter:off -->
@@ -7,7 +8,7 @@ title: Шаблоны и генерация кода

 # Шаблоны и генерация кода

-Как работают шаблоны, как их создавать, синтаксис переменных и как генерировать код с помощью расширения VS Code и CLI.
+Как устроены шаблоны кодогенерации и как ими пользоваться.

 ## Структура шаблонов

--- a/docs/docs/usage/video.md
+++ b/docs/docs/usage/video.md
--- a/docs/docs/workflow.md
+++ b/docs/docs/workflow.md
@@ -0,0 +1,8 @@
+---
+title: Подсказки
+description: Короткие ответы на типовые вопросы и решения для спорных ситуаций.
+---
+
+# Подсказки
+
+Короткие ответы на типовые вопросы и решения для спорных ситуаций.
--- a/docs/en/applied/api.md
+++ b/docs/en/applied/api.md
@@ -1,5 +0,0 @@
---
-title: API
---
-
-# API
--- a/docs/en/applied/components.md
+++ b/docs/en/applied/components.md
@@ -1,7 +0,0 @@
---
-title: Components
---
-
-# Components
-
-Rules for creating UI components across all FSD layers.
--- a/docs/en/applied/fonts.md
+++ b/docs/en/applied/fonts.md
@@ -1,5 +0,0 @@
---
-title: Fonts
---
-
-# Fonts
--- a/docs/en/applied/hooks.md
+++ b/docs/en/applied/hooks.md
@@ -1,5 +0,0 @@
---
-title: Hooks
---
-
-# Hooks
--- a/docs/en/applied/images-sprites.md
+++ b/docs/en/applied/images-sprites.md
@@ -1,5 +0,0 @@
---
-title: Images
---
-
-# Images
--- a/docs/en/applied/localization.md
+++ b/docs/en/applied/localization.md
@@ -1,5 +0,0 @@
---
-title: Localization
---
-
-# Localization
--- a/docs/en/applied/page-level.md
+++ b/docs/en/applied/page-level.md
@@ -1,7 +0,0 @@
---
-title: Page-level Components
---
-
-# Page-level Components
-
-Next.js App Router special files used by the framework by convention: `layout.tsx`, `page.tsx`, `loading.tsx`, `error.tsx`, `not-found.tsx`, `template.tsx`.
--- a/docs/en/applied/project-structure.md
+++ b/docs/en/applied/project-structure.md
@@ -1,7 +0,0 @@
---
-title: Project Structure
---
-
-# Project Structure
-
-Base project structure and principles of module organization at folder and file level.
--- a/docs/en/applied/stores.md
+++ b/docs/en/applied/stores.md
@@ -1,5 +0,0 @@
---
-title: Stores
---
-
-# Stores
--- a/docs/en/applied/styles.md
+++ b/docs/en/applied/styles.md
@@ -1,7 +0,0 @@
---
-title: Styles
---
-
-# Styles
-
-CSS writing rules: PostCSS Modules, nesting, media queries, variables, formatting.
--- a/docs/en/applied/svg-sprites.md
+++ b/docs/en/applied/svg-sprites.md
@@ -1,5 +0,0 @@
---
-title: SVG Sprites
---
-
-# SVG Sprites
--- a/docs/en/applied/templates-generation.md
+++ b/docs/en/applied/templates-generation.md
@@ -1,7 +0,0 @@
---
-title: Templates & Code Generation
---
-
-# Templates & Code Generation
-
-Template tools, syntax, and examples for code generation.
--- a/docs/en/applied/video.md
+++ b/docs/en/applied/video.md
@@ -1,5 +0,0 @@
---
-title: Video
---
-
-# Video
--- a/docs/en/basics/architecture.md
+++ b/docs/en/basics/architecture.md
@@ -1,7 +0,0 @@
---
-title: Architecture
---
-
-# Architecture
-
-Architecture based on FSD (Feature-Sliced Design) and strict module boundaries.
--- a/docs/en/basics/code-style.md
+++ b/docs/en/basics/code-style.md
@@ -1,7 +0,0 @@
---
-title: Code Style
---
-
-# Code Style
-
-Unified code formatting rules: indentation, line breaks, quotes, import order, and readability.
--- a/docs/en/basics/documentation.md
+++ b/docs/en/basics/documentation.md
@@ -1,7 +0,0 @@
---
-title: Documentation
---
-
-# Documentation
-
-Documentation should help understand the purpose of an entity, not duplicate its types or obvious details.
--- a/docs/en/basics/naming.md
+++ b/docs/en/basics/naming.md
@@ -1,7 +0,0 @@
---
-title: Naming
---
-
-# Naming
-
-Naming should be predictable, concise, and reflect the meaning of the entity.
--- a/docs/en/basics/tech-stack.md
+++ b/docs/en/basics/tech-stack.md
@@ -1,7 +0,0 @@
---
-title: Tech Stack
---
-
-# Tech Stack
-
-Base technology stack and libraries used in projects.
--- a/docs/en/basics/typing.md
+++ b/docs/en/basics/typing.md
@@ -1,7 +0,0 @@
---
-title: Typing
---
-
-# Typing
-
-Typing is required for all public interfaces, functions, and components.
--- a/docs/en/index.md
+++ b/docs/en/index.md
@@ -1,58 +0,0 @@
-# NextJS Style Guide
-
-Rules and standards for NextJS and TypeScript development: architecture, typing, styles, components, API, and infrastructure.
-
-## Documentation Structure
-
-### Processes
-
-**What to do** in a specific situation — step-by-step instructions.
-
-| Section | Answers the question |
-|---------|---------------------|
-| Getting Started | What tools to install before starting development? |
-| Creating an App | How to create a new project, where to get a template? |
-| Creating Pages | How to add a page: routing and screen? |
-| Creating Components | How to generate components using templates? |
-| Styling | What to use: Mantine, tokens, or PostCSS? |
-| Data Fetching | How to fetch data: SWR, codegen, sockets? |
-| State Management | When and how to create a store (Zustand)? |
-| Localization | How to add translations and work with i18next? |
-
-### Basic Rules
-
-**What the code should look like** — standards not tied to a specific technology.
-
-| Section | Answers the question |
-|---------|---------------------|
-| Tech Stack | What stack do we use? |
-| Architecture | How are FSD layers, dependencies, and public API structured? |
-| Code Style | How to format code: indentation, quotes, imports, early return? |
-| Naming | How to name files, variables, components, hooks? |
-| Documentation | How to write JSDoc: what to document and what not? |
-| Typing | How to type: type vs interface, any/unknown? |
-
-### Applied Sections
-
-**How a specific area works** — rules, structure, and code examples for specific technologies and tools.
-
-| Section | Answers the question |
-|---------|---------------------|
-| Project Structure | How are folders and files organized by FSD? |
-| Components | How is a component structured: files, props, clsx? |
-| Page-level Components | How to define layout, page, loading, error, not-found? |
-| Templates & Code Generation | How do templates work: syntax, variables, modifiers? |
-| Styles | How to write CSS: PostCSS Modules, nesting, media, tokens? |
-| Images | _(not filled)_ |
-| SVG Sprites | _(not filled)_ |
-| Video | _(not filled)_ |
-| API | _(not filled)_ |
-| Stores | _(not filled)_ |
-| Hooks | _(not filled)_ |
-| Fonts | _(not filled)_ |
-| Localization | _(not filled)_ |
-
-## For Assistants
-
-Documentation map with links to all sections ([llmstxt.org](https://llmstxt.org) format):
-https://gromlab.ru/docs/nextjs-style-guide/raw/branch/main/generated/en/llms.txt
--- a/docs/en/workflow/creating-app.md
+++ b/docs/en/workflow/creating-app.md
@@ -1,7 +0,0 @@
---
-title: Creating an App
---
-
-# Creating an App
-
-How to create a new application: choosing a project template and initialization.
--- a/docs/en/workflow/creating-components.md
+++ b/docs/en/workflow/creating-components.md
@@ -1,7 +0,0 @@
---
-title: Creating Components
---
-
-# Creating Components
-
-Generating components using templates, working with child components.
--- a/docs/en/workflow/creating-pages.md
+++ b/docs/en/workflow/creating-pages.md
@@ -1,7 +0,0 @@
---
-title: Creating Pages
---
-
-# Creating Pages
-
-Page creation pattern: routing (page.tsx) and screen.
--- a/docs/en/workflow/data-fetching.md
+++ b/docs/en/workflow/data-fetching.md
@@ -1,7 +0,0 @@
---
-title: Data Fetching
---
-
-# Data Fetching
-
-How to fetch data: SWR, API client codegen, sockets.
--- a/docs/en/workflow/getting-started.md
+++ b/docs/en/workflow/getting-started.md
@@ -1,7 +0,0 @@
---
-title: Getting Started
---
-
-# Getting Started
-
-Setting up the environment and installing tools before starting development.
--- a/docs/en/workflow/localization.md
+++ b/docs/en/workflow/localization.md
@@ -1,7 +0,0 @@
---
-title: Localization
---
-
-# Localization
-
-How to add translations and work with i18next.
--- a/docs/en/workflow/state-management.md
+++ b/docs/en/workflow/state-management.md
@@ -1,7 +0,0 @@
---
-title: State Management
---
-
-# State Management
-
-When and how to create a store (Zustand), what to store locally vs globally.
--- a/docs/en/workflow/styling.md
+++ b/docs/en/workflow/styling.md
@@ -1,7 +0,0 @@
---
-title: Styling
---
-
-# Styling
-
-Styling tools priority and rules for their application.
--- a/docs/index.md
+++ b/docs/index.md
@@ -3,96 +3,21 @@ layout: false
 ---

 <script setup>
-import { ref, computed, onMounted } from 'vue'
+import { ref, onMounted } from 'vue'

-const STORAGE_KEY = 'nsg-landing-lang'
 const THEME_KEY = 'vitepress-theme-appearance'

 // __BUILD_VERSION__ подставляется Vite-define из ENV `BUILD_VERSION`
 // (см. .vitepress/config.ts). В dev и build всегда определена.
 const buildVersion = __BUILD_VERSION__

-const dict = {
-  ru: {
-    tagline: 'Готовые соглашения по архитектуре, коду, компонентам и инфраструктуре для Next.js + TypeScript-проектов — чтобы команда писала одинаково, а новые разработчики включались в проект быстрее.',
-    langLabel: 'Язык',
-    themeLabel: 'Тема',
-    themes: { auto: 'Авто', light: 'Светлая', dark: 'Тёмная' },
-    cards: {
-      docs: {
-        title: 'Документация',
-        desc: 'Все разделы: процессы разработки, базовые правила, прикладные руководства.',
-        href: './ru/',
-        cta: 'Открыть',
-      },
-      ai: {
-        title: 'Ассистенту',
-        desc: 'Карта документации в формате llms.txt для AI-агентов.',
-        href: './ru/llms.txt',
-        cta: 'Открыть',
-      },
-      zip: {
-        title: 'Скачать правила',
-        desc: 'Архив всех Markdown-файлов одним ZIP.',
-        href: './nextjs-style-guide-ru.zip',
-        cta: 'Скачать',
-      },
-    },
-  },
-  en: {
-    tagline: 'Ready-made standards for architecture, code, components, and infrastructure in Next.js + TypeScript projects — so your team writes consistently and new developers ramp up faster.',
-    langLabel: 'Language',
-    themeLabel: 'Theme',
-    themes: { auto: 'Auto', light: 'Light', dark: 'Dark' },
-    cards: {
-      docs: {
-        title: 'Documentation',
-        desc: 'All sections: development processes, basic rules, applied guides.',
-        href: '#',
-        cta: 'Open',
-        badge: 'in development',
-      },
-      ai: {
-        title: 'For Assistant',
-        desc: 'Documentation map in llms.txt format for AI agents.',
-        href: '#',
-        cta: 'Open',
-        badge: 'in development',
-      },
-      zip: {
-        title: 'Download rules',
-        desc: 'Archive of all Markdown files and llms.txt in a single ZIP.',
-        href: '#',
-        cta: 'Download',
-        badge: 'soon',
-      },
-    },
-  },
-}
-
-const lang = ref('ru')
 const theme = ref('auto')

 onMounted(() => {
-  const savedLang = localStorage.getItem(STORAGE_KEY)
-  if (savedLang === 'ru' || savedLang === 'en') {
-    lang.value = savedLang
-  } else {
-    const nav = (navigator.language || 'ru').toLowerCase()
-    lang.value = nav.startsWith('ru') ? 'ru' : 'en'
-  }
-
  const savedTheme = localStorage.getItem(THEME_KEY)
  theme.value = savedTheme === 'dark' || savedTheme === 'light' ? savedTheme : 'auto'
 })

-const t = computed(() => dict[lang.value])
-
-function setLang(value) {
-  lang.value = value
-  localStorage.setItem(STORAGE_KEY, value)
-}
-
 function setTheme(value) {
  theme.value = value
  if (value === 'auto') {
@@ -118,31 +43,26 @@ function toggleTheme(value) {
  <section class="landing__hero">
    <h1 class="landing__title">NextJS Style Guide</h1>
    <ClientOnly>
-      <p class="landing__tagline">{{ t.tagline }}</p>
+      <p class="landing__tagline">Соглашения по разработке Next.js проектов: архитектура и слои приложения, структура кода, организация модулей, стилизация, типизация и инфраструктура.</p>
      <div class="landing__controls">
-        <div class="seg" role="group" :aria-label="t.langLabel">
-          <button
-            type="button"
-            class="seg__btn"
-            :class="{ 'seg__btn--active': lang === 'ru' }"
-            :aria-pressed="lang === 'ru'"
-            @click="setLang('ru')"
-          >Русский</button>
-          <button
-            type="button"
-            class="seg__btn"
-            :class="{ 'seg__btn--active': lang === 'en' }"
-            :aria-pressed="lang === 'en'"
-            @click="setLang('en')"
-          >English</button>
-        </div>
-        <div class="seg seg--icons" role="group" :aria-label="t.themeLabel">
+        <a
+          class="landing__repo"
+          href="https://gromlab.ru/docs/nextjs-style-guide"
+          target="_blank"
+          rel="noopener"
+        >
+          <svg width="16" height="16" viewBox="0 0 24 24" fill="currentColor" aria-hidden="true">
+            <path d="M12 .3a12 12 0 0 0-3.8 23.38c.6.12.83-.26.83-.57L9 21.07c-3.34.72-4.04-1.61-4.04-1.61-.55-1.39-1.34-1.76-1.34-1.76-1.08-.74.09-.73.09-.73 1.2.09 1.83 1.24 1.83 1.24 1.08 1.83 2.81 1.3 3.5 1 .1-.78.42-1.31.76-1.61-2.67-.3-5.47-1.33-5.47-5.93 0-1.31.47-2.38 1.24-3.22-.14-.3-.54-1.52.1-3.18 0 0 1-.32 3.3 1.23a11.5 11.5 0 0 1 6 0c2.28-1.55 3.29-1.23 3.29-1.23.64 1.66.24 2.88.12 3.18a4.65 4.65 0 0 1 1.23 3.22c0 4.61-2.8 5.63-5.48 5.92.42.36.81 1.1.81 2.22l-.01 3.29c0 .31.2.69.82.57A12 12 0 0 0 12 .3Z"/>
+          </svg>
+          <span>Репозиторий</span>
+        </a>
+        <div class="seg seg--icons" role="group" aria-label="Тема">
          <button
            type="button"
            class="seg__btn"
            :class="{ 'seg__btn--active': theme === 'light' }"
            :aria-pressed="theme === 'light'"
-            :title="t.themes.light"
+            title="Светлая"
            @click="toggleTheme('light')"
          >
            <svg width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="4"/><path d="M12 2v2M12 20v2M4.93 4.93l1.41 1.41M17.66 17.66l1.41 1.41M2 12h2M20 12h2M4.93 19.07l1.41-1.41M17.66 6.34l1.41-1.41"/></svg>
@@ -152,7 +72,7 @@ function toggleTheme(value) {
            class="seg__btn"
            :class="{ 'seg__btn--active': theme === 'dark' }"
            :aria-pressed="theme === 'dark'"
-            :title="t.themes.dark"
+            title="Тёмная"
            @click="toggleTheme('dark')"
          >
            <svg width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1 1 11.21 3 7 7 0 0 0 21 12.79z"/></svg>
@@ -162,25 +82,29 @@ function toggleTheme(value) {
    </ClientOnly>
  </section>

-  <ClientOnly>
  <section class="landing__cards">
-      <a
-        v-for="key in ['docs', 'ai', 'zip']"
-        :key="key"
-        class="landing__card"
-        :class="{ 'landing__card--soon': t.cards[key].badge }"
-        :href="t.cards[key].href"
-        :aria-disabled="t.cards[key].badge ? 'true' : null"
-      >
-        <h3>
-          {{ t.cards[key].title }}
-          <span v-if="t.cards[key].badge" class="landing__badge">{{ t.cards[key].badge }}</span>
-        </h3>
-        <p>{{ t.cards[key].desc }}</p>
-        <span class="landing__cta">{{ t.cards[key].cta }} →</span>
+    <a class="landing__card" href="/docs/">
+      <h3>Документация</h3>
+      <p>Все разделы: процессы разработки, базовые правила, прикладные руководства.</p>
+      <span class="landing__cta">Открыть →</span>
+    </a>
+    <div class="landing__card landing__card--multi">
+      <h3>Ассистенту</h3>
+      <p>
+        Карта документации для AI-агентов:
+        <code>/llms.txt</code>, <code>/llms-full.txt</code>.
+      </p>
+      <div class="landing__buttons">
+        <a class="landing__button" href="/llms.txt">llms.txt</a>
+        <a class="landing__button" href="/llms-full.txt">llms-full.txt</a>
+      </div>
+    </div>
+    <a class="landing__card" href="/nextjs-style-guide.zip">
+      <h3>Скачать правила</h3>
+      <p>Архив всех Markdown-файлов одним ZIP.</p>
+      <span class="landing__cta">Скачать →</span>
    </a>
  </section>
-  </ClientOnly>

  <p class="landing__version">v{{ buildVersion }}</p>
 </div>
@@ -207,6 +131,35 @@ function toggleTheme(value) {
  flex-wrap: wrap;
 }

+.landing__controls > * {
+  height: 36px;
+  box-sizing: border-box;
+}
+
+.landing__repo {
+  display: inline-flex;
+  align-items: center;
+  gap: 8px;
+  padding: 0 14px;
+  border: 1px solid var(--vp-c-divider);
+  border-radius: 999px;
+  background: var(--vp-c-bg-soft);
+  color: var(--vp-c-text-2);
+  font-size: 13px;
+  font-weight: 500;
+  text-decoration: none;
+  transition: color 0.15s, border-color 0.15s;
+}
+
+.landing__repo:hover {
+  color: var(--vp-c-text-1);
+  border-color: var(--vp-c-brand-1);
+}
+
+.landing__repo svg {
+  flex-shrink: 0;
+}
+
 .seg {
  display: inline-flex;
  align-items: stretch;
@@ -305,12 +258,6 @@ function toggleTheme(value) {
  transform: translateY(-2px);
 }

-.landing__card--soon {
-  opacity: 0.55;
-  cursor: not-allowed;
-  pointer-events: none;
-}
-
 .landing__card h3 {
  margin: 0;
  font-size: 18px;
@@ -332,6 +279,33 @@ function toggleTheme(value) {
  color: var(--vp-c-brand-1);
 }

+.landing__buttons {
+  margin-top: auto;
+  display: flex;
+  flex-wrap: wrap;
+  gap: 8px;
+}
+
+.landing__button {
+  display: inline-flex;
+  align-items: center;
+  padding: 6px 12px;
+  font-size: 13px;
+  font-weight: 500;
+  font-family: var(--vp-font-family-mono, monospace);
+  color: var(--vp-c-text-1);
+  background: var(--vp-c-bg);
+  border: 1px solid var(--vp-c-divider);
+  border-radius: 8px;
+  text-decoration: none;
+  transition: border-color 0.15s, color 0.15s;
+}
+
+.landing__button:hover {
+  border-color: var(--vp-c-brand-1);
+  color: var(--vp-c-brand-1);
+}
+
 .landing__version {
  text-align: center;
  margin: 24px 0 0;
@@ -340,33 +314,58 @@ function toggleTheme(value) {
  font-family: var(--vp-font-family-mono, monospace);
 }

-.landing__badge {
-  display: inline-block;
-  margin-left: 8px;
-  padding: 2px 8px;
-  font-size: 11px;
-  font-weight: 500;
-  text-transform: uppercase;
-  letter-spacing: 0.04em;
-  border-radius: 999px;
-  background: var(--vp-c-bg-mute);
-  color: var(--vp-c-text-3);
-  vertical-align: middle;
-}
-
@media (max-width: 768px) {
  .landing {
-    padding: 16px 16px 48px;
-    gap: 32px;
+    padding: 48px 20px 56px;
+    gap: 40px;
+    justify-content: flex-start;
  }
  .landing__title {
    font-size: 36px;
  }
+  .landing__tagline {
+    font-size: 16px;
+  }
  .landing__cards {
    grid-template-columns: 1fr;
+    gap: 16px;
  }
  .landing__controls {
    gap: 8px;
+    margin-top: 36px;
+  }
+}
+
+@media (max-width: 480px) {
+  .landing {
+    padding: 44px 16px 48px;
+    gap: 36px;
+  }
+  .landing__title {
+    font-size: 30px;
+  }
+  .landing__tagline {
+    font-size: 15px;
+    line-height: 1.5;
+  }
+  .landing__controls {
+    margin-top: 32px;
+  }
+  /* Репозиторий — только иконка, без текста, чтобы все контролы влезли в строку */
+  .landing__repo {
+    width: 36px;
+    padding: 0;
+    justify-content: center;
+  }
+  .landing__repo span {
+    display: none;
+  }
+  .seg__btn {
+    padding: 6px 12px;
+    font-size: 12px;
+  }
+  .landing__card {
+    padding: 20px;
  }
 }
 </style>
--- a/docs/ru/applied/api.md
+++ b/docs/ru/applied/api.md
--- a/docs/ru/applied/svg-sprites.md
+++ b/docs/ru/applied/svg-sprites.md
@@ -1,5 +0,0 @@
---
-title: SVG-спрайты
---
-
-# SVG-спрайты
--- a/docs/ru/index.md
+++ b/docs/ru/index.md
@@ -1,61 +0,0 @@
-# NextJS Style Guide
-
-Правила и стандарты разработки на NextJS и TypeScript: архитектура, типизация, стили, компоненты, API и инфраструктурные разделы.
-
-## Для ассистентов
-
-Карта документации со ссылками на все разделы (формат [llmstxt.org](https://llmstxt.org)):
-https://gromlab.ru/docs/nextjs-style-guide/raw/branch/main/generated/ru/llms.txt
-
-## Структура документации
-
-### Workflow
-
-**Что делать и в каком порядке** — пошаговые инструкции.
-
-| Раздел | Отвечает на вопрос |
-|--------|-------------------|
-| Начало работы | Что нужно знать перед началом разработки? |
-| Создание проекта | Как начать новый проект? |
-| Генерация кода | Какие модули должны генерироваться из шаблонов? |
-| Добавление страницы | Как добавить новую страницу в проект? |
-| Добавление UI-модуля | Как создать компонент, бизнес-модуль, виджет или layout? |
-| Стилизация | Как стилизовать компоненты в проекте? |
-| Получение данных | Как получать данные с сервера? |
-| Управление состоянием | Как работать с состоянием? |
-| Локализация | Как добавлять переводы и подключать локализацию? |
-
-### Базовые правила
-
-**Каким должен быть код** — стандарты, не привязанные к конкретной технологии.
-
-| Раздел | Отвечает на вопрос |
-|--------|-------------------|
-| Технологии и библиотеки | Какой стек используем? |
-| Архитектура | Как устроены слои SLM, зависимости, публичный API? |
-| Стиль кода | Как оформлять код: отступы, кавычки, импорты, early return? |
-| Именование | Как называть файлы, переменные, компоненты, хуки? |
-| Документирование | Как писать JSDoc: что документировать, а что нет? |
-| Типизация | Как типизировать: type vs interface, any/unknown? |
-
-### Прикладные разделы
-
-**Как это настроить и использовать** — конфигурация, структура и примеры кода для конкретных областей.
-
-| Раздел | Отвечает на вопрос |
-|--------|-------------------|
-| Настройка VS Code | Как настроить редактор для проекта? |
-| Структура проекта | Как организованы папки и файлы по SLM? |
-| Компоненты | Как устроен компонент: файлы, пропсы, clsx? |
-| Page-level компоненты | Как описывать layout, page, loading, error, not-found? |
-| Шаблоны и генерация кода | Как работают шаблоны, синтаксис и инструменты генерации? |
-| Стили | Как писать CSS: PostCSS Modules, вложенность, медиа, токены? |
-| Изображения | _(не заполнен)_ |
-| SVG-спрайты | _(не заполнен)_ |
-| Видео | _(не заполнен)_ |
-| API | _(не заполнен)_ |
-| Stores | _(не заполнен)_ |
-| Хуки | _(не заполнен)_ |
-| Шрифты | _(не заполнен)_ |
-| Локализация | _(не заполнен)_ |
-
--- a/docs/ru/workflow.md
+++ b/docs/ru/workflow.md
@@ -1,86 +0,0 @@
---
-title: Workflow
---
-
-# Workflow
-
-Порядок действий при разработке — от создания проекта до реализации фич.
-
-## Создание проекта
-
-Инициализация нового проекта из готового шаблона.
-
-1. Создать проект из шаблона:
-   ```bash
-   npx tiged git@gromlab.ru:templates/nextjs.git my-app
-   cd my-app
-   npm install
-   ```
-2. Проект готов к разработке — стек, структура SLM, конфигурация
-   редактора и шаблоны генерации уже настроены.
-
-## Генерация кода
-
-Создание модулей из шаблонов `.templates/` вместо ручного создания файлов.
-
-1. Определить тип модуля и соответствующий шаблон:
-
-   | Модуль     | Слой         | Шаблон      |
-   |------------|--------------|-------------|
-   | Компонент       | `ui/`             | `component` |
-   | Бизнес-модуль   | `business/`       | `module`    |
-   | Виджет          | `widgets/`        | `widget`    |
-   | Layout          | `layouts/`        | `layout`    |
-   | Экран           | `screens/`        | `screen`    |
-   | Стор            | `stores/`         | `store`     |
-
-2. Сгенерировать модуль из шаблона.
-3. Если подходящего шаблона нет — сначала создать шаблон, затем использовать.
-
-Ручное создание файловой структуры модулей запрещено.
-
-## Добавление страницы
-
-Создание нового маршрута: экран + точка входа для роутинга.
-
-1. Сгенерировать экран из шаблона `screen` в `src/screens/`.
-2. Заполнить экран логикой и стилями.
-3. Создать `page.tsx` в нужном маршруте `src/app/`.
-
-`page.tsx` — тонкая обёртка: только `metadata` и рендер экрана.
-Логика, стили и хуки размещаются в экране, не в `page.tsx`.
-
-## Добавление UI-модуля
-
-Создание компонента, бизнес-модуля, виджета или layout.
-
-1. Сгенерировать модуль из соответствующего шаблона в целевой слой.
-2. Заполнить модуль логикой и стилями.
-3. Дочерние компоненты — генерировать из шаблона `component` в папку `ui/`
-   внутри родителя.
-
-Дочерние компоненты не экспортируются через `index.ts` родителя.
-
-## Стилизация
-
-Выбор инструмента стилизации по приоритету.
-
-1. Использовать Mantine-компоненты и их пропсы.
-2. Если Mantine не покрывает — использовать CSS-токены
-   (`--color-*`, `--space-*`, `--radius-*`).
-3. Если нужна кастомная стилизация — PostCSS Modules.
-
-Инлайн-стили (`style`), магические значения и глобальные стили
-вне `app/styles/` запрещены.
-
-## Получение данных
-
-*Раздел в разработке* — SWR, генерация API-клиентов, сокеты.
-
-## Управление состоянием
-
-*Раздел в разработке* — когда создавать стор, что хранить локально и глобально.
-
-## Локализация
-
-*Раздел в разработке* — переводы и i18next.
--- a/docs/ru/workflow/code-generation.md
+++ b/docs/ru/workflow/code-generation.md
@@ -1,31 +0,0 @@
---
-title: Генерация кода
---
-
-# Генерация кода
-
-Как создавать модули в проекте с помощью шаблонов — какие модули покрыты генерацией и когда стоит создавать новые шаблоны.
-
-## Какие модули генерируются из шаблонов
-
-| Модуль | Слой | Шаблон |
-|---|---|---|
-| Компонент | `ui/` | `component` |
-| Бизнес-модуль | `business/` | `module` |
-| Виджет | `widgets/` | `widget` |
-| Layout | `layouts/` | `layout` |
-| Экран | `screens/` | `screen` |
-| Стор | `stores/` | `store` |
-
-## Что нужно знать
-
-В проекте принято создавать модули из шаблонов `.templates/`. Шаблоны задают единообразную файловую структуру и сокращают рутину — не нужно вручную создавать папки, файлы типов, стилей и экспорты.
-
-Если для нужного модуля нет подходящего шаблона — стоит сначала создать шаблон, а затем использовать его.
-
-## Когда создавать новый шаблон
-
- Повторяющаяся структура появляется больше одного раза.
- Существующий шаблон не покрывает нужный тип модуля.
-
-Инструменты и синтаксис шаблонов — [Шаблоны и генерация кода](/ru/applied/templates-generation).
--- a/docs/ru/workflow/creating-app.md
+++ b/docs/ru/workflow/creating-app.md
@@ -1,31 +0,0 @@
---
-title: Создание проекта
---
-
-# Создание проекта
-
-Как начать новый проект, соответствующий стандартам этого руководства.
-
-## Что нужно знать
-
-Новый проект создаётся из готового шаблона. Шаблон содержит настроенный стек, структуру SLM, конфигурацию редактора и шаблоны генерации кода — проект готов к разработке сразу после установки зависимостей.
-
-### Создание из шаблона
-
-```bash
-npx tiged git@gromlab.ru:templates/nextjs.git my-app
-cd my-app
-npm install
-```
-
-## Что входит в шаблон
-
- Next.js + TypeScript (App Router)
- Mantine UI + PostCSS Modules
- Biome (линтинг и форматирование)
- Zustand, SWR
- Структура SLM (`layouts/`, `screens/`, `widgets/`, `business/`, `infrastructure/`, `ui/`, `shared/`)
- Шаблоны генерации (`.templates/`)
- Конфигурация VS Code (`.vscode/`)
- CSS-токены (цвета, отступы, радиусы, медиа)
- Open Graph метаданные
--- a/docs/ru/workflow/creating-components.md
+++ b/docs/ru/workflow/creating-components.md
@@ -1,22 +0,0 @@
---
-title: Добавление UI-модуля
---
-
-# Добавление UI-модуля
-
-Как создать компонент, бизнес-модуль, виджет или layout в проекте.
-
-## Что нужно знать
-
-Все UI-модули создаются только из шаблонов `.templates/`. Ручное создание файловой структуры запрещено. Если подходящего шаблона нет — сначала создать шаблон в `.templates/`, затем использовать его.
-
-## Порядок действий
-
-1. [Сгенерировать](/ru/applied/templates-generation) модуль из соответствующего шаблона в целевой слой.
-2. Заполнить модуль логикой и стилями.
-
-## Дочерние компоненты
-
-Если модулю нужны внутренние подкомпоненты — [генерировать](/ru/applied/templates-generation) их из шаблона `component` в папку `ui/` внутри родительского модуля. Дочерние компоненты не экспортируются через `index.ts` родителя.
-
-Правила написания компонентов — [Компоненты](/ru/applied/components).
--- a/docs/ru/workflow/creating-pages.md
+++ b/docs/ru/workflow/creating-pages.md
@@ -1,27 +0,0 @@
---
-title: Добавление страницы
---
-
-# Добавление страницы
-
-Как добавить новую страницу в проект по стандартам этого руководства.
-
-## Что нужно знать
-
-Страница в проекте — это два файла: экран в `src/screens/` (вся логика, стили, зависимости) и `page.tsx` в `src/app/` (точка входа для роутинга Next.js). Экран генерируется из шаблона, `page.tsx` создаётся вручную.
-
-## Порядок действий
-
-1. [Сгенерировать](/ru/applied/templates-generation) экран из шаблона `screen` в папку `src/screens/`.
-
-2. Заполнить экран логикой и стилями.
-
-3. Создать `page.tsx` в нужном маршруте `src/app/`. Файл страницы должен быть тонким — только `metadata` и рендер экрана. Никакой логики, стилей и хуков в `page.tsx` не размещается — всё это живёт в экране.
-
-## Правила
-
- Ручное создание файловой структуры экрана запрещено — только [генерация](/ru/applied/templates-generation) из шаблона.
- Логика, стили и зависимости размещаются в экране, не в `page.tsx`.
- Каждая страница содержит `metadata` с `title` и `description`.
-
-Примеры `page.tsx` и `metadata` — [Page-level компоненты](/ru/applied/page-level).
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
S.Gromov	a6cd14585b	docs: ввести DEVELOP.md как точку входа архива All checks were successful CI/CD Pipeline / docker (push) Successful in 1m18s Details CI/CD Pipeline / deploy (push) Successful in 7s Details - Удалена автогенерация README.md архива (buildArchiveReadme). - Добавлен DEVELOP.md — точка входа с обязательным порядком чтения: архитектура → базовые правила → прикладные по задаче. - Добавлен MAP.md — статичная карта со ссылками на все разделы. - DEVELOP.md и MAP.md исключены из веб-сборки (srcExclude). - DEVELOP.md исключён из копирования в docs/public/docs/. - Удалено копирование llms-full.txt в архив (только для сайта). - В CONTRIBUTING.md ссылка README.md заменена на MAP.md.	2026-04-28 20:28:01 +03:00
S.Gromov	1195c7b75d	docs: уточнить правила и заголовки вложенных разделов - Подзаголовки архитектуры подняты до самодостаточных: Слои SLM, Модули SLM, Сегменты SLM - Подзаголовки REST-клиентов подняты до самодостаточных: Автогенерация REST-клиента, Ручное создание REST-клиента - Для серверных/клиентских компонентов h1 оставлен коротким, контекст полностью переносится в описание - Лендинг docs/docs/index.md актуализирован под новые имена; «Создание проекта» и «Данные» вынесены в отдельные группы - В CONTRIBUTING описана отдельная группа разделов «Настройка» и весь набор типов: basics, creating-project, setup, usage - Зафиксирован принцип: подъём контекста в h1 — только грамматически естественный, иначе контекст переносится в описание - Frontmatter дополнен обязательным полем description - Удалены устаревшие OLD_parts/ и notes	2026-04-28 16:02:00 +03:00
S.Gromov	028a69f3ac	docs: переработать заголовки и описания разделов All checks were successful CI/CD Pipeline / docker (push) Successful in 51s Details CI/CD Pipeline / deploy (push) Successful in 9s Details - Зафиксированы новые правила в CONTRIBUTING.md: заголовок и описание как навигационный маркер, запреты, тесты и подходящие формы - Описания во всех 26 разделах переписаны как короткий ответ на вопрос «когда сюда нужно?» - Заголовки приведены к самодостаточному виду: SLM Design, SVG-спрайты, VS Code, Чистая установка Next.js, Источники данных, Создание проекта вручную, Стили, Алиасы импортов - Описания добавлены в frontmatter (description) для согласованности с llms.txt и SEO - Удалены навигационные ссылки сразу после описания - Добавлен docs-overview.md — сводный обзор всех страниц - Обновлён сайдбар: ссылка «Алиасы» → «Алиасы импортов»	2026-04-28 15:35:10 +03:00
S.Gromov	a9ea898220	sync (черновик)	2026-04-28 10:52:09 +03:00
S.Gromov	7965ec2a96	docs: актуализировать структуру разделов и заблокировать пустые All checks were successful CI/CD Pipeline / docker (push) Successful in 47s Details CI/CD Pipeline / deploy (push) Successful in 7s Details - sidebar: «Данные» поднят сразу после «Страницы (App Router)» - sidebar: пустые разделы (Изображения, Видео, Stores, Хуки, Шрифты, Локализация) оставлены без link с пометкой «· в разработке» - index.md приведён к актуальной структуре sidebar (Workflow, Базовые правила, Установка и настройка, Использование) - README.md перегенерирован	2026-04-27 12:04:34 +03:00
S.Gromov	7c224fed99	fix(generate-llms): корректные ссылки в корневом README - ссылки /docs/... преобразованы в относительные пути docs/docs/.md - корневые ресурсы (/llms.txt, .zip и т.п.) переписаны на абсолютный SITE_URL - после описания добавлена строка с URL сайта	2026-04-27 12:04:31 +03:00
S.Gromov	74cbd43a23	feat: чистые URL без .html All checks were successful CI/CD Pipeline / docker (push) Successful in 46s Details CI/CD Pipeline / deploy (push) Successful in 7s Details - VitePress: включён cleanUrls - Caddyfile: try_files пробует .html для запросов без расширения - Caddyfile: 301-редирект /foo.html → /foo для совместимости - sitemap.xml: канонические URL без .html	2026-04-27 10:12:30 +03:00
S.Gromov	ef58a02609	fix: унифицировать ссылки на лендинге для краулеров All checks were successful CI/CD Pipeline / docker (push) Successful in 53s Details CI/CD Pipeline / deploy (push) Successful in 7s Details - относительные пути (./docs/, ./nextjs-style-guide.zip) заменены на абсолютные - убраны target="_blank" и rel="noopener" у llms-кнопок: некоторые краулеры считают такие ссылки внешними и не следуют по ним	2026-04-27 09:54:37 +03:00
S.Gromov	e265799c26	fix: устранить проблемы доступности llms.txt для AI-агентов All checks were successful CI/CD Pipeline / docker (push) Successful in 51s Details CI/CD Pipeline / deploy (push) Successful in 8s Details - Caddyfile: text/plain применяется только к существующим .txt/.md - Caddyfile: несуществующие .txt/.md отдают 404 вместо HTML-фолбэка - Caddyfile: добавлены редиректы /docs/llms.txt → /llms.txt - Caddyfile: добавлен HTTP-заголовок Link с rel="llms" (RFC 8288) - лендинг: относительные ссылки на llms.txt заменены на абсолютные - лендинг: добавлено явное упоминание путей в тексте карточки - config: добавлены <link rel="alternate"> на llms.txt в <head> - generate-llms: добавлена генерация robots.txt и sitemap.xml	2026-04-27 09:37:23 +03:00
S.Gromov	781efc52f1	docs: добавить разделы установки проекта, Next.js, стилей и шаблонов All checks were successful CI/CD Pipeline / docker (push) Successful in 45s Details CI/CD Pipeline / deploy (push) Successful in 5s Details - Создание проекта: «Из шаблона» (clone через tiged) и «Вручную» (пошаговая сборка) — оформлены подгруппой - Next.js: `create-next-app` с каноническими флагами, очистка демо-шаблона, минимальный layout - Стили: базовая инфраструктура `variables.css` / `media.css` / `global.css` в `src/shared/styles/` без PostCSS - Шаблоны генерации: установка `.templates/` через tiged + создание шаблона вручную - Сайдбар «Установка и настройка» расширен новыми пунктами в порядке зависимости установки	2026-04-27 01:27:43 +03:00
S.Gromov	ec01ae2e1c	fix: рекурсивный обход sidebar для вложенных групп - flattenSidebar поддерживал максимум два уровня вложенности — группы глубже теряли страницы в llms.txt и архиве - Переписан на рекурсивный обход с накоплением префикса групп через `: ` - Раздел «Данные» (4 уровня вложенности) теперь полностью попадает в карту документации	2026-04-27 01:27:35 +03:00
S.Gromov	3d93efd90a	docs: добавить раздел «Данные» и реорганизовать документацию All checks were successful CI/CD Pipeline / docker (push) Successful in 44s Details CI/CD Pipeline / deploy (push) Successful in 6s Details - Добавлен раздел «Данные»: REST (автоматическая и ручная генерация клиентов, получение данных в server и client компонентах с инкапсуляцией SWR в хуках), Realtime, введение - Прикладные разделы переименованы в «Использование», папка перенесена в `docs/docs/usage/` - Создана группа «Установка и настройка» с папкой `docs/docs/setup/` — туда вынесены PostCSS, Biome, VS Code, алиасы и установка SVG-спрайтов - Подгруппы «Стили» и «SVG-спрайты» в сайдбаре упразднены — страницы установки и использования разнесены по верхнеуровневым группам - Удалён устаревший раздел `applied/api.md` - Перекрёстные ссылки в workflow-разделах и внутри новых страниц синхронизированы с новыми путями - CONTRIBUTING.md обновлён под новую структуру папок	2026-04-27 00:54:26 +03:00
S.Gromov	e5e4ace91a	docs: добавить раздел «Алиасы» All checks were successful CI/CD Pipeline / docker (push) Successful in 46s Details CI/CD Pipeline / deploy (push) Successful in 6s Details - Добавлен прикладной раздел с конфигом tsconfig.paths и правилами использования - Зафиксирован отказ от префикса @/ - Пункт «Алиасы» добавлен в сайдбар после «Структуры проекта»	2026-04-26 23:00:00 +03:00
S.Gromov	5a773a5b4f	docs: добавить разделы biome, svg-спрайтов и сгруппировать стили - Добавлен раздел «Biome» в прикладные разделы - Раздел «SVG-спрайты» преобразован в группу: установка, использование - Раздел «Стили» преобразован в группу: PostCSS, использование - Обновлён сайдбар VitePress с новыми группами - Перегенерирован README из главной страницы документации	2026-04-26 22:50:51 +03:00
S.Gromov	f645b2ad40	refactor: удалить английскую локаль и упростить структуру All checks were successful CI/CD Pipeline / docker (push) Successful in 48s Details CI/CD Pipeline / deploy (push) Successful in 7s Details - Удалена английская версия документации (docs/en/) и артефакты en - Контент перенесён docs/ru/ → docs/docs/, URL /ru/ заменён на /docs/ - Из .vitepress/config.ts убраны locales и enSidebar, оставлен один sidebar - Из лендинга удалён переключатель языка ru/en и en-словарь - generate-llms.ts переписан без параметра lang; llms.txt, llms-full.txt и nextjs-style-guide.zip генерируются в корень docs/public/ - README_RU.md занял место корневого README.md - Обновлены CONTRIBUTING.md, custom.css, комментарий в Dockerfile	2026-04-26 15:04:10 +03:00
S.Gromov	90bf360c06	docs: добавить раздел «Использование» на главных локалей All checks were successful CI/CD Pipeline / docker (push) Successful in 58s Details CI/CD Pipeline / deploy (push) Successful in 7s Details - блок поднят над «Структура документации» — это первое что видит читатель после описания - разделён на две аудитории: * «Для AI-агентов»: llms.txt (карта) и llms-full.txt (полный текст) * «Для проекта»: ZIP-архив с распаковкой в ./ai/nextjs-style-guide/ - прямые URL на nextjs-style-guide.gromlab.ru - README.md и README_RU.md (генерируются из docs/{ru,en}/index.md) обновлены автоматически	2026-04-25 21:26:45 +03:00
S.Gromov	5cf0f0f8ba	fix: переключатель языка и иконка репозитория в шапке - восстановлены link для локалей: ru → /ru/, en → /en/ (были сломаны на /) - добавлена иконка GitHub в socialLinks шапки VitePress для ru и en со ссылкой на https://gromlab.ru/docs/nextjs-style-guide - root-локаль скрыта из переключателя языка через CSS (display: none для href="/"): в дропдауне теперь только Русский и English - pill-кнопка «Репозиторий» добавлена в блок controls лендинга с иконкой GitHub, открывается в новой вкладке - мобильная вёрстка лендинга переработана: контролы стопкой, репозиторий на ≤480px сжимается до иконки 36x36, увеличены отступы между блоками (hero / controls / cards) для разделения	2026-04-25 21:14:17 +03:00
S.Gromov	464c709859	docs: убрать «воду» из вводных абзацев разделов All checks were successful CI/CD Pipeline / docker (push) Successful in 54s Details CI/CD Pipeline / deploy (push) Successful in 6s Details - удалены обороты «Раздел описывает», «Этот раздел описывает» из 10 файлов docs/ru - вводные абзацы переписаны в формате «тема: категории/области» без перечисления конкретного содержимого раздела - удалён frontmatter description из basics/architecture/index.md (подтягивается первый абзац после h1 — про SLM Design) - в CONTRIBUTING.md добавлен раздел «Вводный абзац» с правилами и блоками «Хорошо/Плохо»: что делать, чего избегать, проверка на излишнюю конкретику	2026-04-25 20:15:10 +03:00
S.Gromov	64db18917b	fix: синхронизировать EN-лендинг с русским All checks were successful CI/CD Pipeline / docker (push) Successful in 54s Details CI/CD Pipeline / deploy (push) Successful in 6s Details - обновлён EN tagline на лендинге под новый стиль (RU уже был обновлён) - английская карточка «For Assistant» приведена к структуре русской: две кнопки llms.txt и llms-full.txt с заглушечными ссылками (#) и бейджем «in development» - шаблон карточки теперь поддерживает badge при наличии buttons: карточка приглушается, кнопки не кликаются	2026-04-25 20:00:52 +03:00
S.Gromov	ae103e962e	feat: llms-full.txt, README архива и доработка лендинга All checks were successful CI/CD Pipeline / docker (push) Successful in 46s Details CI/CD Pipeline / deploy (push) Successful in 8s Details - добавлен генератор llms-full.txt: вся документация локали в одном файле с мета-якорями, порядок повторяет sidebar - архив теперь содержит README.md как точку входа: карта документации с относительными ссылками, описаниями и метаинфо сборки - ссылки /ru/... в .md-файлах архива преобразуются в относительные пути (через path.relative) — внутренняя навигация работает локально - веб-index.md удаляется из архива (его роль выполняет README.md) - llms-full.txt добавлен в архив для одноразового чтения LLM - в sidebar добавлен пункт «Главная» / «Home» со ссылкой на корень локали - карточка «Ассистенту» на лендинге: две кнопки llms.txt и llms-full.txt с открытием в новой вкладке - активирована карточка «Скачать правила» (ru) с ссылкой на zip-архив - удалён устаревший блок «Для ассистентов» из docs/{ru,en}/index.md - обновлены описания на главных локалей и заменён FSD на SLM в EN - в манифесте появилось поле llmsFull рядом с llms	2026-04-25 19:56:44 +03:00