@bonesofspring/ai-rules 0.2.0 → 0.2.2

package/presets/claude/next/rules/architecture/architecture-boundaries.md

@@ -1,72 +0,0 @@
----
-paths:
-  - app/src/**/*
----
-
-# Границы между слоями
-
-## UI (`app/src/ui/**`)
-
-- Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `architecture/public-imports.md`**), контракт к API — **только** `import … from '@/api'` (**`architecture/public-imports.md`**).
-- Не должен:
-  - обращаться к HTTP‑клиенту напрямую;
-  - знать детали DTO backend — только доменные типы.
-
-## Store (`app/src/store/**`)
-
-- Может импортировать: `@/store/**`, сервисы и публичные сущности API — **только** из `@/api` (**`architecture/public-imports.md`**), типы из `@/types` и enum из `@/types/enums` (**`architecture/public-imports.md`**).
-- Не должен:
-  - зависеть от конкретных UI‑компонентов;
-  - напрямую работать с global/window API.
-- Вызовы к backend — только через сервисы, импортируемые из `@/api`; **транспортные** типы ответа и ошибки (из `@/types`, в том же виде, что у прикладного HTTP‑клиента) во thunk допустимы, если так выстроен API‑слой (`api-and-data/http-client.md`, `api-and-data/store-rtk.md`).
-
-## API (`app/src/api/**`)
-
-Реализация в `services/**`, `clients/**`, реэкспорт в `app/src/api/index.ts`:
-
-- Внутри слоя: типы из `@/types` и enum из `@/types/enums` (**`architecture/public-imports.md`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`api-and-data/http-client.md`, `api-and-data/api-services.md`).
-- Не должен:
-  - тянуть в себя UI или store;
-  - смешивать HTTP‑слой и доменный слой — использовать мапперы.
-
-## UI и обращение к API (`@/api`)
-
-- По умолчанию сценарии с **изменением серверного состояния** и координация нескольких шагов — через **store** (`createAsyncThunk`, dispatch, паттерн фичи в репозитории).
-- Прямой вызов методов сервисов, импортированных из **`@/api`**, из UI допустим только в **узких случаях**: преимущественно **чтение** или действие **без необходимости держать результат в Redux**; те же **доменные типы**, что использовал бы thunk; **не** дублировать уже существующий сценарий из store и **не** протаскивать DTO в компоненты.
-- Предпочтительно оформлять такие вызовы так же, как в **соседних фичах** репозитория (хук‑фасад, отдельный хук и т.д.).
-
-## Порты и адаптеры (краткая карта)
-
-- **Входящий адаптер**: UI — ввод пользователя, отображение; зависит от store и доменных типов, не от транспорта.
-- **Оркестрация сценариев**: store (slices, thunk) — вызывает сервисы, кладёт в state **доменные** модели после маппинга.
-- **Исходящий порт (контракт к backend)**: публичный API **`@/api`** (barrel `app/src/api/index.ts`; реализация — в `app/src/api/services/**` и т.д., см. `architecture/public-imports.md`).
-- **Исходящий адаптер**: общая реализация HTTP в **`app/src/lib/clients/**`** и экземпляры в **`app/src/api/clients/**`**.
-
-## Фича как срез
-
-- Для сложной фичи выравниваются имена и термины (**единый язык** предметной области) в типах, селекторах, сервисах и UI; структура папок — как в соседних фичах репозитория.
-
-# Правила импортов
-
-- Всегда использовать алиас `@/...` для импортов между слоями.
-- Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`architecture/layer-barrel-exports.md`** и `architecture/public-imports.md`; для API‑слоя снаружи `app/src/api/**` — **`architecture/public-imports.md`** (только `@/api`).
-- При добавлении нового кода проверять:
-  - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
-
-# Организация фич
-
-- Для сложных фич (например, `OrderCheckout`):
-  - Страница: `app/src/ui/pages/OrderCheckoutPage/**`.
-  - Локальные компоненты: поддиректории `components/**` внутри страницы.
-  - Связанный store: `app/src/store/slices/OrderCheckout/**`.
-  - API: `app/src/api/services/OrdersApi/OrderCheckout/**` (имя корневого сервиса взять из принятой в проекте схемы).
-  - Типы: `app/src/types/**` с экспортом через barrel **`app/src/types/index.ts`** (`architecture/public-imports.md`).
-
-# Требование к агенту
-
-При добавлении новой функциональности:
-
-- Разместить файлы в **соответствующих слоях**.
-- Проверить существующие фичи с аналогичной структурой и **повторить их организацию**.
-- Не "коротить" слои (например, не вызывать API прямо из компонента только ради упрощения).

package/presets/claude/next/rules/architecture/feature-delivery-workflow.md

@@ -1,79 +0,0 @@
----
-paths:
-  - app/src/ui/**/*
-  - app/src/store/**/*
-  - app/src/api/**/*
-  - app/src/types/**/*
----
-
-# Доставка фичи (сквозной порядок)
-
-Типичная фича с данными с backend и общим состоянием. Детали слоёв — `architecture/architecture-boundaries.md`, `stack/next-app-core.md`.
-
-## Чеклист (порядок работ)
-
-1. **Доменные типы** — `app/src/types/**`, barrel (`architecture/public-imports.md`, **`architecture/layer-barrel-exports.md`**); JSDoc — `stack/types-jsdoc.md`.
-2. **Контракт API** — DTO там, где принято; доменные типы в `@/types`.
-3. **Мапперы** — DTO → домен (`api-and-data/api-services.md`).
-4. **Сервисы** — клиенты `app/src/api/clients/**`, barrel `@/api` (`api-and-data/api-services.md`, `api-and-data/http-client.md`, **`architecture/layer-barrel-exports.md`**).
-5. **Состояние** — slice/thunk (`api-and-data/store-rtk.md`); thunk → `@/api`.
-6. **UI** — `@/types`, без DTO (`ui-and-accessibility/react-ui.md`, `architecture/architecture-boundaries.md`, `ui-and-accessibility/no-props-spread.md`).
-7. **Моки** — `app/src/mocks/**`; регистрация в `handlers.ts` (см. ниже).
-8. **Тесты** — unit (`testing/tests-unit.md`); e2e (`testing/tests-e2e-structure.md`, `testing/playwright-agents.md`).
-9. **Завершение** — **`tooling-and-review/post-change-lint.md`**.
-
-## Поток данных
-
-```mermaid
-flowchart LR
-  subgraph transport [Транспорт]
-    HttpClient[HttpClient]
-  end
-  DTO[DTO] --> Mappers[Мапперы]
-  Mappers --> Domain[Доменные типы]
-  Domain --> Service[API сервис]
-  Service --> HttpClient
-  Service --> Thunk[Thunk]
-  Thunk --> Store[Store]
-  Store --> UI[UI]
-```
-
-## Регистрация по слоям
-
-1. **Типы** — `app/src/types/**`.
-2. **API** — `app/src/api/services/<ServiceRoot>/<Segment>/`; публичные экспорты → **`app/src/api/index.ts`**.
-3. **Моки** — `app/src/mocks/data/<feature>/`; **`app/src/mocks/handlers.ts`**; пути из `@/api`.
-4. **Store** — `app/src/store/slices/<FeatureName>/`; **`app/src/store/reducers.ts`**; middleware → **`app/src/store/index.ts`**.
-5. **UI** — pages/components; store/hooks.
-6. **Unit** — `*.spec.ts(x)`; мапперы обязательно.
-7. **E2E** — `app/__tests__/e2e/<Area>/<plan>.cases.md` + spec.
-
-## Частичные сценарии
-
-| Задача | Минимум действий |
-|--------|------------------|
-| Только API + типы | Типы, сервис, мапперы, `@/api` barrel; unit на маппер. |
-| Только моки | Путь в `@/api`; handlers + `mocks/handlers.ts`. |
-| Только store | Thunk на `@/api`; slice + `reducers.ts`. |
-| Только UI | Store state; без HTTP/DTO. |
-| Только e2e | `*.cases.md` + spec. |
-
-## Антипаттерны
-
-- DTO в UI или нетипизированном store.
-- HTTP-клиент из компонента/thunk в обход сервиса.
-- Deep-import `@/api/services/**` из UI/store.
-- `{...props}` — `ui-and-accessibility/no-props-spread.md`.
-
-## Матрица: зона → правила
-
-| Зона | Правила |
-|------|---------|
-| `app/src/api/clients/**`, `app/src/lib/clients/**` | `api-and-data/http-client.md`, `testing/tests-unit.md` |
-| `app/src/api/services/**` | `api-and-data/api-services.md`, `architecture/layer-barrel-exports.md` |
-| `app/src/store/**` | `api-and-data/store-rtk.md`, `architecture/architecture-boundaries.md`, `architecture/public-imports.md` |
-| `app/src/ui/**` | `ui-and-accessibility/react-ui.md`, `ui-and-accessibility/no-props-spread.md`, `architecture/public-imports.md` |
-| `app/src/types/**` | `architecture/public-imports.md`, `stack/types-jsdoc.md`, `architecture/layer-barrel-exports.md` |
-| `app/__tests__/e2e/**` | `testing/tests-e2e-structure.md`, `testing/playwright-agents.md` |
-
-При добавлении или расширении фичи **пройти чеклист** и правила из таблицы для затронутых зон.

package/presets/claude/next/rules/architecture/layer-barrel-exports.md

@@ -1,58 +0,0 @@
----
-paths:
-  - app/src/**/*
----
-
-# Barrel-экспорты слоёв с public API
-
-## Когда применять
-
-Для **любого слоя** (каталога, пакета, bounded context), у которого:
-
-- есть **корневой barrel** — единая точка импорта для внешних потребителей;
-- deep-импорты внутрь слоя **запрещены** снаружи (ESLint `no-restricted-imports`, правила `architecture/public-imports.md`).
-
-Примеры alias/entry point в разных проектах: `@/api`, `@/types`, `@/core`, `@/store`, `packages/foo`.
-
-## Два уровня barrel
-
-1. **Локальный** — `index.ts` модуля/фичи внутри слоя.
-2. **Корневой public API** — barrel слоя (например `src/<layer>/index.ts`).
-
-**Внутри** слоя — относительные импорты и пути между подмодулями. **Снаружи** — только корневой barrel и **явно разрешённые** вторичные entry points (если зафиксированы в правилах проекта, напр. `@/types/enums`).
-
-## Что реэкспортировать наружу
-
-Только символы, которые **должны быть доступны** потребителям слоя: публичные функции/сервисы/фасады, типы контракта, константы и helpers, нужные другим слоям или тестам.
-
-**Не реэкспортировать:** внутренние адаптеры, мапперы, детали транспорта, промежуточные объекты для сборки фасада внутри слоя.
-
-Группировка в корневом barrel — **по конвенции репозитория** (ориентир — соседние модули того же слоя).
-
-## Чеклист агента (обязателен)
-
-При добавлении или существенном расширении **модуля внутри регламентированного слоя**:
-
-1. Определить слой, его **корневой barrel** и доп. entry points (`architecture/public-imports.md`).
-2. Создать/обновить **локальный** `index.ts` — только публичные символы.
-3. Если в слое есть **фасад/агрегатор** (`*ApiService.ts`, `rootReducer`, …) — подключить модуль там.
-4. Добавить **реэкспорт** новых публичных символов в **корневой barrel** слоя.
-5. **Проверка:** grep по имени символа или пути `./<Module>` в корневом barrel; снаружи слоя нет deep-импортов.
-
-Модуль **не готов**, пока чеклист не пройден.
-
-## Как найти регламентированные слои в репозитории
-
-1. Правила `architecture/public-imports.md` в `.claude/rules/architecture/`.
-2. ESLint `no-restricted-imports` — паттерны `@/<layer>/*` с исключением barrel.
-3. `architecture/architecture-boundaries.md`, README проекта.
-
-## В этом репозитории
-
-| Слой | Корневой barrel | Правило импортов |
-|------|-----------------|------------------|
-| API | `app/src/api/index.ts` | `architecture/public-imports.md` |
-| Types | `app/src/types/index.ts` | `architecture/public-imports.md` (+ `@/types/enums`) |
-| Core | `app/src/core/index.ts` | ESLint: `@/core/index` |
-
-Иллюстрация двух уровней (API): локальный `services/.../<Feature>/index.ts` → фасад `*ApiService.ts` → `app/src/api/index.ts`.

package/presets/claude/next/rules/architecture/public-imports.md

@@ -1,46 +0,0 @@
----
-paths:
-  - app/src/ui/**/*
-  - app/src/store/**/*
-  - app/src/lib/**/*
-  - app/src/types/**/*
-  - app/src/api/**/*
----
-
-# Публичные импорты (`@/types`, `@/api`)
-
-**Коллизии:** импорт типов — раздел `@/types`; API вне `app/src/api/**` — раздел `@/api` (дублирует ESLint `no-restricted-imports`).
-
-## `@/types`
-
-- **Публичный API типов** — barrel `app/src/types/index.ts`; импортировать типы только как `@/types` (или `@/types/index`).
-- **Запрещено** обходить barrel: `@/types/<что‑угодно>`, кроме enum.
-- **Enum** — только `@/types/enums` / `@/types/enums.ts`.
-- Внутри `app/src/types/**` — относительные импорты между файлами слоя.
-
-```typescript
-// ✅
-import type { TUserProfile } from '@/types'
-import { SomeEnum } from '@/types/enums'
-
-// ❌
-import type { TUserProfile } from '@/types/User.types'
-```
-
-Новые публичные типы — реэкспорт в `app/src/types/index.ts` по **`architecture/layer-barrel-exports.md`**.
-
-## `@/api`
-
-- **Публичный API** — barrel `app/src/api/index.ts`. Вне `app/src/api/**` — только `import … from '@/api'` (или `@/api/index`).
-- **Запрещено** снаружи слоя: `@/api/<что‑угодно>`, кроме `@/api/index`.
-- Внутри `app/src/api/**` — относительные импорты и `@/api/services/**`, `@/api/clients/**`.
-
-```typescript
-// ✅ в store, UI, lib вне app/src/api
-import { MedcardApiService } from '@/api'
-
-// ❌ снаружи app/src/api
-import { MedcardApiService } from '@/api/services/MedcardApiService/MedcardApiService'
-```
-
-Новые публичные символы API — реэкспорт в `app/src/api/index.ts` по **`architecture/layer-barrel-exports.md`**.

package/presets/claude/next/rules/architecture/reference-features.md

@@ -1,37 +0,0 @@
----
-paths:
-  - app/src/ui/**/*
-  - app/src/store/**/*
-  - app/src/api/**/*
-  - app/src/types/**/*
----
-
-# Эталонные фичи (reference features)
-
-Перед реализацией найди фичу того же типа и **повтори её структуру**, не изобретая новую организацию файлов.
-
-## Таблица эталонов
-
-Замени **TBD** на реальные пути после договорённости в команде (или при `ai-rules init` в целевом репо):
-
-| Слой | Эталон | Что копировать |
-|------|--------|----------------|
-| UI page | **TBD** `app/src/ui/pages/<Example>/` | `components/`, `*.data.ts`, `styles.ts`, barrel |
-| Store slice | **TBD** `app/src/store/slices/<example>/` | slice, thunks, selectors, types |
-| API service | **TBD** `app/src/api/services/<example>/` | service, mappers, barrel |
-| Types module | **TBD** `app/src/types/<example>/` | domain types, JSDoc, barrel export |
-| Unit tests | **TBD** рядом с эталонным mapper/service | `*.spec.ts`, describe/it naming |
-| E2E area | **TBD** `app/__tests__/e2e/<Area>/` | `*.cases.md`, page objects, `_shared/` |
-
-## Как использовать
-
-1. Определи затронутые слои из `decomposition.md` или задачи.
-2. Открой эталон из таблицы (после заполнения путей).
-3. Зеркаль именование, порядок файлов, паттерны импортов и тестов.
-4. Если эталона нет — выбери **самую близкую** существующую фичу того же слоя и зафиксируй выбор в handoff.
-
-## Связанные правила
-
-- `tooling-and-review/code-quality.md` — повторять паттерны, не deep-import.
-- `architecture/feature-delivery-workflow.md` — порядок слоёв.
-- skill `feature-delivery` — end-to-end сценарий.

package/presets/claude/next/rules/architecture/types-public-imports.md

@@ -1,8 +0,0 @@
----
-paths:
-  - app/src/types/**/*
----
-
-# Deprecated
-
-Содержимое перенесено в **`architecture/public-imports.md`** (раздел `@/types`).

package/presets/claude/next/rules/stack/arrow-functions.md

@@ -1,45 +0,0 @@
----
-paths:
-  - app/src/**/*.{ts,tsx,js,jsx}
----
-
-# Стрелочные функции
-
-При разработке **использовать стрелочный синтаксис** для функций, где это допустимо в TypeScript/JavaScript.
-
-## Что делать
-
-- Объявлять функции как **`const имя = (...) => { ... }`** вместо **`function имя(...) { ... }`**, если не нужны особенности объявления `function`.
-- Колбэки и обработчики — стрелочные функции: `.map((x) => ...)`, `onClick={() => ...}`.
-- React-компоненты и хуки — как стрелочные функции с явной типизацией пропсов/возврата по принятому в проекте стилю.
-
-## Исключения (допустимо не стрелка)
-
-- **Генераторы** (`function*`) — стрелкой не выразить.
-- **Методы класса** — если в коде используются классы, допустимы обычные методы (`method() {}`).
-- Когда осознанно нужны **подъём (hoisting)** или **имя функции в стеке** только у `function` — редкие случаи.
-
-## Примеры
-
-```typescript
-// ❌ Избегать для нового кода
-function formatLabel(id: string): string {
-  return id.toUpperCase()
-}
-
-// ✅ Предпочтительно
-const formatLabel = (id: string): string => {
-  return id.toUpperCase()
-}
-```
-
-```tsx
-// ✅ Предпочтительно
-const UserCard = ({ name }: { name: string }) => {
-  return <span>{name}</span>
-}
-```
-
-## Требование к агенту
-
-При генерации и правке кода **по умолчанию выбирать стрелочные функции**; отступать к `function` только в случаях из раздела исключений.

package/presets/claude/next/rules/stack/navigation-router.md

@@ -1,61 +0,0 @@
----
-paths:
-  - app/src/ui/**/*
----
-
-# Навигация и роутинг: сначала стек проекта
-
-**При любой задаче, связанной с навигацией, переходами между страницами, URL, редиректами, хлебными крошками, защищёнными маршрутами или программной сменой маршрута** — перед предложением кода или импортов **нельзя** опираться на «типичный React» по умолчанию. Нужно **явно свериться со стеком целевого репозитория** и использовать **один** согласованный с проектом механизм.
-
-## Зависимости: что проверить в первую очередь
-
-1. **`package.json`** в корне приложения (например `app/package.json` в монорепо — тот пакет, который реально собирается и деплоится). Смотреть **`dependencies`** и при необходимости **`peerDependencies`**:
-   - **`next`** — Next.js; версия важна для нюансов API (сверяться с документацией под эту major).
-   - **`react-router-dom`**, **`@remix-run/*`**, **`@tanstack/react-router`** и т.д. — отдельный роутинг; не подменять их API вызовами Next без проверки, что в проекте действительно используется этот стек.
-   - **`next`** и **`react-router-dom`** одновременно — возможно легаси или гибрид; **не** выбирать API по умолчанию — смотреть раздел «Реализация в коде» ниже.
-
-2. **Монорепо / workspaces** — роутинг может жить не в корневом `package.json`. Открыть **`package.json` того workspace**, где лежат страницы и `next.config.*` / точка входа SPA.
-
-3. **Факт установки** — при сомнениях смотреть lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) или каталог `node_modules` у соответствующего пакета: убедиться, что заявленный пакет реально установлен, а не только прописан в документации.
-
-## Реализация роутинга в проекте (код и структура)
-
-Перед предложением паттерна навигации **свериться с тем, как уже сделано в репозитории**:
-
-1. **Дерево маршрутов**
-   - Next **App Router**: каталог **`app/`** (или `src/app/`) с `layout.tsx`, `page.tsx`, сегменты `[id]` и т.п.
-   - Next **Pages Router**: каталог **`pages/`** с `_app`, динамические `[slug].tsx`.
-   - Наличие **обоих** `app/` и `pages/` — уточнить по `next.config` и документации проекта, какой слой основной.
-
-2. **Точки входа и обёртки**
-   - Поиск по коду импортов: **`from 'next/navigation'`**, **`from 'next/router'`**, **`from 'next/link'`**, **`from 'react-router-dom'`**, **`createBrowserRouter`**, **`RouterProvider`**, **`BrowserRouter`**.
-   - Где объявлены маршруты (файловая структура Next vs конфиг маршрутов / `routes.tsx` в SPA).
-
-3. **Общие абстракции проекта**
-   - Обертки над ссылками (`@/ui/...`, `Link` из дизайн-системы), хелперы путей, константы роутов — **использовать их**, а не дублировать сырой роутер.
-
-4. **Соседние файлы фичи**
-   - Новый код навигации — в том же стиле, что страницы/хуки той же области (`next/navigation` vs `react-router-dom` как в соседних импортах).
-
-## Как определить, что использовать (сводка)
-
-1. **Зависимости** — см. раздел выше; по ним задаётся допустимый набор пакетов.
-2. **Структура** — App Router vs Pages vs SPA по каталогам и конфигу.
-3. **Фактический код** — какие импорты и обёртки уже доминируют в приложении.
-
-## Что использовать (краткая матрица)
-
-| Стек | Программная навигация / чтение пути | Ссылки |
-|------|-------------------------------------|--------|
-| **Next.js App Router** | `next/navigation` (`useRouter`, `usePathname`, `useSearchParams`, `redirect` и т.д. по документации Next для вашей версии) | `next/link` |
-| **Next.js Pages Router** | `next/router` | `next/link` |
-| **SPA + React Router** | `react-router-dom` (`useNavigate`, `useParams`, `useLocation`, …) | `<Link>` из `react-router-dom` |
-
-**Не делать:** подключать `react-router-dom` в проект на Next.js «по привычке»; импортировать хуки из `next/router` в компонентах App Router без проверки; смешивать два роутера в одном приложении без явной архитектурной причины в кодовой базе.
-
-## Требование к агенту
-
-- Перед генерацией или ревью кода навигации **коротко зафиксировать вывод** (например: «зависимости: `next` без `react-router-dom`; в коде везде `next/navigation` → используем то же») и следовать ему.
-- **Обязательная проверка:** актуальные **`dependencies`** в `package.json` нужного workspace + **как в проекте уже реализованы** маршруты и импорты (поиск по репозиторию, соседние файлы). Не полагаться только на предположение по одному признаку (например, только на наличие папки `app/`).
-- Если стек неочевиден (два роутера в зависимостях, гибрид) — **сверить lockfile / установленные пакеты** и **доминирующие импорты** в `src`/`app`, затем выбрать API.
-- Для **этого** пресета базовый ориентир — **`stack/next-app-core.md`**: Next.js; предпочитать **`next/navigation`** и **`next/link`** там, где используется App Router.

package/presets/claude/next/rules/stack/next-app-core.md

@@ -1,33 +0,0 @@
-# Стек и окружение
-
-Конкретные версии — **из `package.json` и конфигов целевого репозитория**. Рамка preset: Next.js, React, TypeScript; runner/e2e/mocks/UI/APM — как заведено в репо.
-
-# Структура проекта
-
-- `app/` — корень Next.js; `app/src/**` — код; `app/__tests__/e2e/**` — e2e.
-- `app/tsconfig.json`: `baseUrl: "."`, `paths: { "@/*": ["./src/*"] }`.
-- **Требование:** `@/*` вместо относительных импортов выше по дереву.
-
-# Архитектурные слои
-
-| Слой | Каталог | Детали |
-|------|---------|--------|
-| UI | `app/src/ui/**` (pages, components) | `ui-and-accessibility/react-ui.md`, `architecture/architecture-boundaries.md` |
-| Store | `app/src/store/**` (slices, middleware) | `api-and-data/store-rtk.md` |
-| API | `app/src/api/**` (services, clients, barrel) | `api-and-data/api-services.md`, `api-and-data/http-client.md` |
-| HTTP | `app/src/lib/clients/**`, `app/src/api/clients/**` | `api-and-data/http-client.md` |
-| Types | `app/src/types/**` | `architecture/public-imports.md`, `stack/types-jsdoc.md` |
-| Mocks | `app/src/mocks/**` | по схеме репозитория |
-
-Границы слоёв, порты/адаптеры, UI→API — **`architecture/architecture-boundaries.md`**. Импорты `@/types`, `@/api` — **`architecture/public-imports.md`**.
-
-# Работа агента
-
-- Архитектура и импорты: `architecture/architecture-boundaries.md`, `architecture/public-imports.md`
-- Фичи: `architecture/feature-delivery-workflow.md` + skill `feature-delivery`
-- После правок: `tooling-and-review/post-change-lint.md`; менеджер пакетов: `tooling-and-review/package-manager.md`
-- Копировать паттерны соседних файлов в целевом слое; не использовать `any` (предпочитать `unknown` + сужение)
-
-Задачи на **сеть, HTTP, новые эндпоинты**: `api-and-data/http-client.md` + `api-and-data/api-services.md` + `api-and-data/store-rtk.md`.
-
-См. **`rules/README.md`** — полный каталог.

package/presets/claude/next/rules/stack/next-app-router.md

@@ -1,36 +0,0 @@
----
-paths:
-  - app/src/app/**/*
-  - app/**/app/**/*
----
-
-# Next.js App Router
-
-Применять при работе с `app/src/app/**` или маршрутами App Router в целевом репо.
-
-## Server vs Client
-
-- **Server Components по умолчанию** — без `'use client'`, если не нужны hooks, browser API, event handlers.
-- **`'use client'`** — только для интерактива, `useState`/`useEffect`, browser-only API.
-- Не тянуть store/RTK и тяжёлый client-state в Server Components без необходимости.
-
-## Data fetching
-
-- Предпочитать fetch/data-loader на **server** (RSC, route handlers, server actions — по принятому в репо паттерну).
-- **Не дублировать** один запрос в RSC и client без причины.
-- Кеш и revalidate — как в существующих страницах репо (`fetch` options, `revalidate`, tags).
-
-## Маршруты и UX
-
-- Для async routes использовать **`loading.tsx`**, **`error.tsx`**, **`not-found.tsx`** по образцу соседних routes.
-- **Suspense** — для медленных client/server секций; fallback согласован с дизайн-системой.
-- Навигация — `stack/navigation-router.md` + router/link паттерны проекта.
-
-## Границы слоёв
-
-- RSC/route handlers **не импортируют UI-компоненты с client-only зависимостями** напрямую в server tree без `'use client'` границы.
-- Доменные типы — `@/types`; вызовы backend — через `@/api` / services, не raw `fetch` из page.tsx без слоя API.
-
-## Эталон
-
-Смотри существующий route той же сложности в `app/src/app/**` и повтори структуру (`architecture/reference-features.md`).

package/presets/claude/next/rules/stack/no-type-assertion.md

@@ -1,59 +0,0 @@
----
-paths:
-  - app/src/api/**/*
-  - app/src/store/**/*
-  - app/src/types/**/*
----
-
-# Не использовать `as` для приведения типов при экспорте и импорте
-
-## О чём речь
-
-Речь о **type assertion** в TypeScript: выражение вида `значение as Тип`.
-
-**Не относится к правилу** (это не assertion, а синтаксис модулей):
-
-- переименование при экспорте: `export { foo as bar }`, `export { default as Baz } from '...'`;
-- переименование при импорте: `import { foo as bar } from '...'`;
-- `import type { Foo as Bar }` — алиас типа в импорте типов.
-
-## Требование
-
-- На **публичной границе модуля** (экспорт, присваивание импортированным символам с принудительным приведением) **не использовать** `as Тип` для «подгонки» типов, если можно обойтись нормальной типизацией.
-
-## Предпочитать вместо `as`
-
-- явную аннотацию: `const x: T = ...` / `function f(): T`;
-- **дженерики** у функций и классов;
-- **`satisfies`** (когда нужно проверить совместимость без сужения до `any`);
-- сужение **`unknown`** после проверки (type guards, `zod` и т.п.);
-- правку **исходных типов/DTO/мапперов**, а не assertion на выходе.
-
-## Когда `as` допустим
-
-- взаимодействие с **не типизированными** или некорректно типизированными внешними модулями;
-- узкие места после **валидации** данных;
-- **`as const`** — литеральные типы;
-- блок **`catch (error)`** после HTTP: по возможности **`instanceof`** на **класс ошибки транспорта** из `@/types`; голый **`as`** — только если `instanceof` недоступен.
-
-## Примеры
-
-```typescript
-// ❌ Плохо: assertion на экспортируемом API
-export const config = loadRaw() as AppConfig
-
-// ✅ Лучше: аннотация + проверка или маппер
-export const config: AppConfig = mapToAppConfig(loadRaw())
-
-// ❌ Плохо: сразу после импорта «ломаем» тип
-import { getData } from './api'
-export const data = getData() as MyDto[]
-
-// ✅ Лучше: типизировать getData / обернуть типобезопасной функцией
-```
-
-## Требование к агенту
-
-При ревью и генерации кода **не добавлять** новые `as Тип` на экспортируемые сущности без явной необходимости.
-
-В слайсах и сервисах при обработке ошибок API сначала рассматривать **`instanceof`** на класс ошибки транспорта из `@/types` (`api-and-data/http-client.md`, `api-and-data/store-rtk.md`).

package/presets/claude/next/rules/stack/types-jsdoc.md

@@ -1,37 +0,0 @@
----
-paths:
-  - app/src/types/**/*.ts
----
-
-# Документация типов в `app/src/types`
-
-При добавлении или существенном изменении типов в этом слое **следовать уже принятому в репозитории стилю JSDoc** (см. примеры: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
-
-## Язык и форма
-
-- Текст комментариев — **на русском**, кратко и по делу.
-- **Не использовать** `@param`, `@returns`, `@see`, `@deprecated` для описания типов — достаточно обычного текста в `/** … */`.
-
-## Экспортируемый `type` / `interface`
-
-- Сразу **перед объявлением** — блок `/** … */`.
-- Для вложенных объектов — отдельный блок над каждым объявлением.
-
-## Поля
-
-- У **каждого** публичного свойства — **однострочный** `/** … */` над полем.
-- Если поле **вычисляется на фронте** — префикс **`[computed]`**.
-- Форматы данных указывать **в тексте** (например дата `YYYY-MM-DD`).
-
-## Классы и enum
-
-- Для **классов** — блок над классом и комментарии к публичным полям.
-- В `enums.ts` исторически часто **без JSDoc** на каждом члене; для новых enum допустимо описание **над enum**.
-
-## Практика для агента
-
-- Не оставлять новые публичные поля без пояснения, если смысл не равен имени на 100%.
-- Поддерживать **тот же стиль**, что в файле.
-- Одна-две фразы на тип, одна строка на поле — норма.
-
-См. также импорты и barrel: `architecture/public-imports.md`.