@bonesofspring/ai-rules 0.2.0 → 0.2.2

package/presets/cursor/next/rules/architecture-boundaries.mdc

@@ -1,61 +1,42 @@
 ---
 description: Архитектурные границы и правила импортов
-globs: app/src/**/*
-alwaysApply: false
+alwaysApply: true
 ---
 
 # Границы между слоями
 
-- **UI (app/src/ui/**)**:
-  - Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `public-imports.mdc`**), контракт к API — **только** `import … from '@/api'` (**`public-imports.mdc`**).
+- **UI (src/ui/**)**:
+  - Может импортировать: `@/ui/**`, `@/store/**`, `@/types/**`, `@/api/services/**` (через публичные интерфейсы).
   - Не должен:
     - обращаться к HTTP‑клиенту напрямую;
     - знать детали DTO backend — только доменные типы.
-- **Store (app/src/store/**)**:
-  - Может импортировать: `@/store/**`, сервисы и публичные сущности API — **только** из `@/api` (**`public-imports.mdc`**), типы из `@/types` и enum из `@/types/enums` (**`public-imports.mdc`**).
+- **Store (src/store/**)**:
+  - Может импортировать: `@/store/**`, `@/api/services/**`, `@/types/**`.
   - Не должен:
     - зависеть от конкретных UI‑компонентов;
     - напрямую работать с global/window API.
-  - Вызовы к backend — только через сервисы, импортируемые из `@/api`; **транспортные** типы ответа и ошибки (из `@/types`, в том же виде, что у прикладного HTTP‑клиента) во thunk допустимы, если так выстроен API‑слой (`http-client.mdc`, `store-rtk.mdc`).
-- **API (`app/src/api/**`)** — реализация в `services/**`, `clients/**`, реэкспорт в `app/src/api/index.ts`:
-  - Внутри слоя: типы из `@/types` и enum из `@/types/enums` (**`public-imports.mdc`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`http-client.mdc`, `api-services.mdc`).
+- **API (src/api/services/**)**:
+  - Может импортировать: `@/types/**`, общие утилиты.
   - Не должен:
     - тянуть в себя 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/**` и т.д., см. `public-imports.mdc`).
-- **Исходящий адаптер**: общая реализация HTTP в **`app/src/lib/clients/**`** и экземпляры в **`app/src/api/clients/**`**.
-
-## Фича как срез
-
-- Для сложной фичи выравниваются имена и термины (**единый язык** предметной области) в типах, селекторах, сервисах и UI; структура папок — как в соседних фичах репозитория.
-
 # Правила импортов
 
 - Всегда использовать алиас `@/...` для импортов между слоями.
 - Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`layer-barrel-exports.mdc`** и `public-imports.mdc`; для API‑слоя снаружи `app/src/api/**` — **`public-imports.mdc`** (только `@/api`).
+- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич.
 - При добавлении нового кода проверять:
   - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
 
 # Организация фич
 
 - Для сложных фич (например, `OrderCheckout`):
-  - Страница: `app/src/ui/pages/OrderCheckoutPage/**`.
+  - Страница: `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`** (`public-imports.mdc`).
+  - Связанный store: `src/store/slices/OrderCheckout/**`.
+  - API: `src/api/services/OrdersApi/OrderCheckout/**` (имя корневого сервиса взять из принятой в проекте схемы).
+  - Типы: `src/types/OrderCheckout.types.ts` или аналогичный файл.
 
 # Требование к агенту
 

package/presets/cursor/next/rules/code-quality-and-refactoring.mdc

@@ -35,11 +35,10 @@ alwaysApply: true
   - сначала локально улучшить архитектуру минимальными шагами;
   - оставить код в консистентном состоянии.
 
-# Линтеры
-
-Lint/stylelint — только **`post-change-lint.mdc`**; ESLint config: `app/eslint.config.mjs`. Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) с кратким комментарием «зачем».
-
 # Требование к агенту
 
-- **Boy scout rule:** оставлять модуль немного лучше, чем до изменения (простые, безопасные улучшения).
+При каждом изменении:
+- Поддерживать принцип **“boy scout rule”**:
+  - оставлять модуль в немного лучшем состоянии, чем до изменения (простые, безопасные улучшения).
 - Не жертвовать архитектурой и слоями ради краткости реализации.
+

package/presets/cursor/next/rules/code-review-mr.mdc

@@ -1,6 +1,6 @@
 ---
 description: Требования к code review агентами Cursor для merge requests
-alwaysApply: false
+alwaysApply: true
 ---
 
 # Code review merge requests
@@ -11,17 +11,16 @@ alwaysApply: false
 
 - **Что обязан проверить агент**
   - **Архитектура и слои**:
-    - Соблюдение правил из `architecture-boundaries.mdc`, `next-app-core.mdc` и при сетевых изменениях — `http-client.mdc`:
-      - UI (`app/src/ui/**`) не ходит напрямую в HTTP‑клиент и не знает DTO.
-      - Store (`app/src/store/**`) не зависит от UI; границы транспортных типов и ошибок — `store-rtk.mdc` / `http-client.mdc`.
-      - API (`app/src/api/**`) не тянет UI/store, использует мапперы; без прямого `fetch` в сервисах (кроме оговорённых исключений).
+    - Соблюдение правил из `architecture-boundaries.mdc` и `next-app-core.mdc`:
+      - UI (`src/ui/**`) не ходит напрямую в HTTP‑клиент и не знает DTO.
+      - Store (`src/store/**`) не зависит от UI и не работает с "сырыми" HTTP.
+      - API (`src/api/services/**`) не тянет UI/store, использует мапперы.
   - **Импорты и организация кода**:
     - Использование алиаса `@/...` вместо относительных импортов выше по дереву.
-    - Отсутствие deep‑импортов во внешние фичи; использование только public API; в файлах вне `app/src/api/**` импорты из API — только `from '@/api'` (`public-imports.mdc`, дублирует ESLint).
-    - При новых/изменённых модулях в регламентированных слоях — реэкспорт публичных символов в корневой barrel по **`layer-barrel-exports.mdc`**.
+    - Отсутствие deep‑импортов во внешние фичи; использование только public API.
     - Размещение новых файлов в корректных слоях и директориях фич.
   - **Типы и TS‑строгость**:
-    - Не допускать новых `any`; предпочитать доменные типы из `@/types` (barrel, см. `public-imports.mdc`).
+    - Не допускать новых `any`; предпочитать доменные типы из `src/types/**`.
     - Проверять корректность пропсов/возвращаемых типов, особенно в UI и API‑слое.
   - **UI и стили**:
     - Для компонентов и стилей сверяться с `react-ui.mdc` и `next-app-core.mdc`:
@@ -31,13 +30,7 @@ alwaysApply: false
     - Проверять, что для нетривиальных изменений:
       - либо обновлены/добавлены unit‑тесты (`tests-unit.mdc`),
       - либо e2e‑сценарии/спеки отражают новую логику (`playwright-agents.mdc`, `tests-e2e-structure.mdc`).
-    - При правках **общего HTTP‑клиента** — наличие/актуальность **behavior‑тестов клиента** (`http-client.mdc`, `tests-unit.mdc`).
     - Указывать, какие именно тесты стоит добавить или поправить.
-  - **Линтеры (обязательно)** — **`post-change-lint.mdc`**:
-    - Перед финализацией отчёта по ревью и после любых правок по итогам ревью: полный прогон **`lint:js`** и **`lint:css`** из `app/`.
-    - В отчёт включить **все сообщения ESLint и Stylelint (errors и warnings)** по файлам из диффа MR/ветки; запуск — по всему проекту, фильтрация вывода — к путям из `git diff`.
-    - Не считать ревью/правки завершёнными, пока линтеры не проходят или не зафиксирован блокер в ответе.
-    - Полная валидация как в CI: **`lint`** (= `lint:js` + `lint:css` + `type-check`) — уместна перед итогом крупного MR.
 
 - **Глубина и формат ревью**
   - Фокус на **изменениях MR** (дифф относительно целевой ветки), а не на всём проекте.

package/presets/cursor/next/rules/next-app-core.mdc

@@ -5,30 +5,73 @@ alwaysApply: true
 
 # Стек и окружение
 
-Конкретные версии — **из `package.json` и конфигов целевого репозитория**. Рамка preset: Next.js, React, TypeScript; runner/e2e/mocks/UI/APM — как заведено в репо.
+Конкретные версии пакетов и инструментов — **из `package.json` и конфигов целевого репозитория**. Ниже — рамка preset (Next.js + React + TypeScript), без привязки к конкретному вендору UI, моков или APM:
 
-# Структура проекта
+- **Фреймворк:** Next.js, React, TypeScript (strict — если включён в проекте).
+- **Сборка и Node:** как задано в репозитории.
+- **Тесты:** unit/integration — runner и библиотеки проекта; e2e — инструмент проекта (правила для агентов Playwright — в отдельных файлах preset).
+- **Моки HTTP/API:** если приняты в репо — повторять существующую схему (каталоги, регистрация, точка входа).
+- **Стили и UI:** способ стилизации и **дизайн‑система / токены** — как уже заведено в коде; приоритет общим примитивам и токенам вместо разрозненных «магических» значений.
+- **Наблюдаемость:** только если уже подключена в проекте — централизованно (клиент, обёртки), без дублирования в каждом методе.
 
-- `app/` — корень Next.js; `app/src/**` — код; `app/__tests__/e2e/**` — e2e.
-- `app/tsconfig.json`: `baseUrl: "."`, `paths: { "@/*": ["./src/*"] }`.
-- **Требование:** `@/*` вместо относительных импортов выше по дереву.
+# Структура проекта (верхний уровень)
+
+- `app/` — корень Next.js приложения.
+  - `app/src/**` — исходный код приложения.
+  - `app/__tests__/e2e/**` — e2e‑тесты и планы.
+- `app/tsconfig.json`:
+  - `baseUrl: "."`
+  - `paths: { "@/*": ["./src/*"] }`
+
+**Требование:** во всех новых изменениях использовать алиас `@/*` вместо относительных импортов выше по дереву.
 
 # Архитектурные слои
 
-| Слой | Каталог | Детали |
-|------|---------|--------|
-| UI | `app/src/ui/**` (pages, components) | `react-ui.mdc`, `architecture-boundaries.mdc` |
-| Store | `app/src/store/**` (slices, middleware) | `store-rtk.mdc` |
-| API | `app/src/api/**` (services, clients, barrel) | `api-services.mdc`, `http-client.mdc` |
-| HTTP | `app/src/lib/clients/**`, `app/src/api/clients/**` | `http-client.mdc` |
-| Types | `app/src/types/**` | `public-imports.mdc`, `types-jsdoc.mdc` |
-| Mocks | `app/src/mocks/**` | по схеме репозитория |
+- **UI слой** (`src/ui/**`):
+  - `src/ui/pages/**` — страницы и контейнеры.
+  - `src/ui/components/**` — переиспользуемые компоненты.
+- **Store слой** (`src/store/**`):
+  - `src/store/slices/**` — модули состояния (в этом preset — Redux Toolkit; подробности в `store-rtk.mdc`).
+  - `src/store/middleware/**` — middleware для сайд‑эффектов (например, файлы, аналитика).
+- **API слой** (`src/api/services/**`):
+  - Сервисы и мапперы, инкапсулирующие HTTP‑логику.
+- **Типы** (`src/types/**`):
+  - Общие доменные типы продукта (сущности предметной области, агрегаты и т.д.).
+- **Моки и тестовые данные** (`src/mocks/**`):
+  - По структуре и назначению — как принято в репозитории.
+
+# Общие архитектурные принципы
 
-Границы слоёв, порты/адаптеры, UI→API — **`architecture-boundaries.mdc`**. Импорты `@/types`, `@/api` — **`public-imports.mdc`**.
+- **Чёткое разделение слоёв**:
+  - UI знает только о доменных типах и публичных интерфейсах store/API.
+  - Store знает о доменных типах и API‑сервисах.
+  - API знает о транспортном слое (HTTP, выбранный клиент) и DTO.
+- **Никаких "проникновений" слоёв**:
+  - UI не обращается к API напрямую — только через store или абстракции сервисов.
+  - Store не работает напрямую с "сырыми" HTTP‑ответами — только через мапперы.
+- **Типы — источник правды**:
+  - Новые сущности описывать в `src/types/**`, переиспользовать, а не дублировать типы по слоям.
+  - Не использовать `any`; при необходимости — `unknown` + безопасное сужение типа.
+
+# Кодстайл и качества кода
+
+- Следовать конфигам линтеров и форматтера **проекта** (`eslint`, `prettier`, `stylelint` — какие есть в репо).
+- Поддерживать:
+  - KISS, DRY, SOLID (в разумных пределах для фронта).
+  - Модульность и переиспользование через компоненты, хуки, слайсы, сервисы.
+  - Визуальную консистентность за счёт принятых в проекте UI‑примитивов и токенов, а не разовых литералов в стилях.
+- При добавлении нового кода **искать и копировать существующие паттерны**:
+  - Для страниц — аналогичные файлы в `src/ui/pages/**`.
+  - Для блоков — компоненты в `src/ui/components/**`.
+  - Для API — сервисы в `src/api/services/**`.
+  - Для состояния — слайсы в `src/store/slices/**`.
 
 # Работа агента
 
-- Архитектура и импорты: `architecture-boundaries.mdc`, `public-imports.mdc`
-- Фичи: `feature-delivery-workflow.mdc` + skill `feature-delivery`
-- После правок: `post-change-lint.mdc`; менеджер пакетов: `package-manager.mdc`
-- Копировать паттерны соседних файлов в целевом слое; не использовать `any` (предпочитать `unknown` + сужение)
+При генерации кода:
+- Определить целевой слой (UI/store/API/типизация/тесты).
+- Найти в соответствующей директории похожие примеры и **копировать архитектурный паттерн** (структура файлов, типы, именование).
+- Не упрощать архитектуру в ущерб существующим слоям (не тянуть API в UI, не описывать "DTO" прямо в компонентах).
+ - Избегать использования `any` при типизации кода; при необходимости использовать `unknown` с последующим безопасным сужением типов.
+ - После создания или редактирования любых файлов **обязательно проверять проект на ошибки TypeScript и ESLint** (либо точечно по изменённым файлам, либо по всему проекту) и устранять найденные проблемы, если это возможно без изменения бизнес‑логики).
+

package/presets/cursor/next/rules/no-props-spread.mdc

@@ -1,14 +1,11 @@
 ---
 description: Избегать спред-а пропов при передаче в компоненты
-globs: app/src/**/*.tsx
-alwaysApply: false
+alwaysApply: true
 ---
 
 # Не использовать спред пропов при передаче в компоненты
 
-При вызове **пользовательских** React-компонентов (имя с заглавной буквы: `IconBox`, `TextField`, ваши `FooBar`) **передавать пропы явно**, а не через spread (`{...props}`, `{...obj}`).
-
-**Агентам и при ревью:** не «упрощать» JSX через объект с последующим spread — это нарушение. Если ветвление по пропам длинное, используйте два явных JSX-блока (`condition ? <A … /> : <B … />`) или отдельные маленькие компоненты, а не `{...mergedProps}`.
+При вызове React-компонентов **передавать пропы явно**, а не через spread (`{...props}`).
 
 ## Почему
 
@@ -16,11 +13,6 @@ alwaysApply: false
 - Упрощает рефакторинг и поиск использований.
 - Снижает риск случайно пробросить лишние или устаревшие пропы.
 
-## Проверка в репозитории
-
-- Для файлов `app/src/ui/**/*.tsx` включено ESLint-правило `react/jsx-props-no-spreading` (`app/eslint.config.mjs`): несоблюдение увидит линтер и CI.
-- Легитимное исключение в конкретном месте — **однострочный** `eslint-disable-next-line react/jsx-props-no-spreading` с кратким комментарием «почему»; для редких обёрток допустим disable на файл (как в `PromocodeInput`).
-
 ## Примеры
 
 ```tsx
@@ -31,10 +23,6 @@ return <Child {...commonProps} />
 // ❌ Плохо
 return <Child {...props} />
 
-// ❌ Плохо (spread из соседнего модуля стилей тоже не оправдание)
-const iconProps = cond ? { name, size: 'm' } : { name, size: 'm', ...styles.IconBoxAccent }
-return <IconBox {...iconProps} />
-
 // ✅ Хорошо
 return (
   <Child
@@ -43,20 +31,9 @@ return (
     c={c}
   />
 )
-
-// ✅ Хорошо — явные пропсы по веткам
-return cond ? (
-  <IconBox name={name} size="m" variant="warning" />
-) : (
-  <IconBox
-    customColors={styles.IconBoxAccent.customColors}
-    name={name}
-    size="m"
-  />
-)
 ```
 
 ## Исключения
 
-- Передача пропов в **нативный** DOM-элемент (`<div {...rest} />`) допустима, если `rest` содержит только валидные HTML-атрибуты.
-- Делегирование пропов в обёртку (wrapper) допустимо, если это явно документировано и обосновано; при необходимости пометьте файл или строку через ESLint-disable, как выше.
+- Передача всех пропов в нативный DOM-элемент (`<div {...rest} />`) допустима, если `rest` содержит только валидные HTML-атрибуты.
+- Делегирование пропов в обёртку (wrapper) допустимо, если это явно документировано и обосновано.

package/presets/cursor/next/rules/playwright-agents.mdc

@@ -1,7 +1,6 @@
 ---
 description: Playwright Agents (planner/generator/healer) configuration for e2e structure in app/__tests__/e2e
-globs: app/__tests__/e2e/**/*
-alwaysApply: false
+alwaysApply: true
 ---
 
 # Playwright Agents in this project

package/presets/cursor/next/rules/react-ui.mdc

@@ -1,6 +1,6 @@
 ---
 description: Паттерны React/Next UI и стилей (preset)
-globs: app/src/ui/**/*.tsx,app/src/ui/**/*.ts
+globs: src/ui/**/*.tsx
 alwaysApply: false
 ---
 
@@ -22,42 +22,14 @@ alwaysApply: false
 - `styles.ts` или соседний модуль стилей — по конвенции репозитория (CSS Modules, CSS-in-JS, и т.д.).
 - `index.ts` — реэкспорт (если нужно наружу).
 
-## Дочерние компоненты (`./components`)
-
-- Локальные подкомпоненты, используемые только этим блоком, выносятся в **`./components/<ComponentName>/`** относительно папки родительского компонента (не оставлять крупные куски JSX и «внутренние» компоненты в том же файле, что и родитель).
-- У каждого такого подкомпонента — **своя** папка с тем же именем, что и публичное имя компонента:
-  - `ComponentName.tsx` — разметка и композиция;
-  - `styles.ts` — только стили этого подкомпонента (см. `no-cross-component-styles-import.mdc`: не тянуть `styles` соседних компонентов);
-  - при необходимости — `ComponentName.data.ts`, `ComponentName.utils.ts`, `ComponentName.hooks.ts` по тем же правилам префикса, что и у родителя;
-  - опционально `index.ts` с реэкспортом.
-- Родитель импортирует подкомпонент из `./components/...`, а не держит его реализацию inline.
-
 Для переиспользуемого компонента:
 - Папка с именем компонента:
   - `ComponentName.tsx`
   - файлы стилей по принятой схеме;
-  - опционально: `types.ts`, `ComponentName.hooks.ts` (см. ниже про префикс).
-
-## Вспомогательные модули рядом с компонентом (именование)
-
-**Префикс имени файла = публичное имя компонента** (как у `ComponentName.tsx` в этой папке), в **PascalCase**. Не вводить отдельные «говорящие» имена файлов по смыслу содержимого (`analysisPreparationIconMap.ts`, `buildAnalysisIdToNameMap.ts` и т.п.) — так теряется связь с компонентом и плодятся одноразовые названия.
-
-**Суффикс по роли:**
-
-| Суффикс | Назначение | Примеры содержимого |
-|--------|------------|---------------------|
-| `ComponentName.data.ts` | Статические данные и конфигурация для UI | мапы `id → иконка/лейбл`, константы списков, таблицы соответствий для отображения |
-| `ComponentName.utils.ts` | Чистые функции без React | форматирование, предобработка пропсов/данных для рендера, `build…`/`map…`‑хелперы |
-| `ComponentName.hooks.ts` | Хуки, используемые только этим блоком | локальные `use…` (если не вынесены в `src/ui/hooks/**`) |
-
-- Несколько констант/мапов или несколько функций — **по-прежнему один** `.data.ts` и один `.utils.ts`, не дробить по «темам» отдельными файлами без веской причины (размер, разные зоны ответственности на уровне подкомпонентов).
-- Если логика принадлежит **подкомпоненту** в подпапке (`components/Child/Child.tsx`), те же правила применяются к **`Child.data.ts`**, **`Child.utils.ts`** относительно этого подкомпонента.
-- Тесты для утилит и данных — рядом в `__tests__/` или с суффиксом `.test.ts`, согласно `tests-unit.mdc`, с тем же префиксом (`RequestForAnalysisRecommendations.utils.test.ts` и т.д.).
+  - опционально: `types.ts`, `hooks.ts`.
 
 # Стили и дизайн‑токены
 
-- **Корневой** styled-элемент компонента в соседнем `styles` — **`Root`** (`<s.Root>`). Подробнее: `no-cross-component-styles-import.mdc`.
-- Порядок объявлений в CSS / `styled` — как требует Stylelint: см. `css-property-order-stylelint.mdc`.
 - Для визуала использовать **тот стек стилей и токенов, который уже в проекте** (переменные, тема, общие классы, дизайн‑пакет).
 - Избегать:
   - inline‑стилей, кроме простых случаев;
@@ -67,11 +39,10 @@ alwaysApply: false
 
 # Пропсы и типизация
 
-- **Не передавать пропы в компоненты через spread** (`<Foo {...x} />`). Только явные атрибуты; подробности и исключения — `no-props-spread.mdc` (в `app/src/ui` это дополнительно ловит ESLint).
 - Описывать пропсы через `type Props = { ... }` или `interface Props { ... }`.
 - Не использовать `any`; при необходимости:
   - обобщения (`<T>`), `unknown`, тип‑предикаты и user‑defined type guards.
-- Для доменных сущностей использовать типы из `@/types` (и enum из `@/types/enums`), а не описывать их заново (`public-imports.mdc`).
+- Для доменных сущностей использовать типы из `@/types/**`, а не описывать их заново.
 
 # Логика и side effects
 

package/presets/cursor/next/rules/store-rtk.mdc

@@ -1,6 +1,6 @@
 ---
 description: Redux Toolkit и состояние приложения
-globs: app/src/store/**/*.ts
+globs: src/store/**/*.ts
 alwaysApply: false
 ---
 
@@ -16,7 +16,7 @@ alwaysApply: false
 
 # Структура слайсов
 
-- Каждый доменный модуль — свой слайс в `app/src/store/slices/**`.
+- Каждый доменный модуль — свой слайс в `src/store/slices/**`.
 - Слайс экспортирует:
   - `reducer` по умолчанию;
   - `actions` именованным экспортом;
@@ -30,23 +30,17 @@ alwaysApply: false
 - Асинхронные запросы:
   - через `createAsyncThunk` или RTK Query.
   - внутри thunk:
-    - вызывать API через сервисы, импортированные из `@/api` (**`public-imports.mdc`**);
-    - не вызывать HTTP‑клиент напрямую — только через эти сервисы.
+    - вызывать API через сервисы из `@/api/services/**`;
+    - не вызывать HTTP‑клиент напрямую — только через сервисы `@/api/services/**`.
 - Сайд‑эффекты (логирование, аналитика, работа с файлами):
-  - выносить в middleware (`app/src/store/middleware/**`) или специализированные слайсы.
+  - выносить в middleware (`src/store/middleware/**`) или специализированные слайсы.
 
 # Типизация
 
 - Использовать `RootState`, `AppDispatch` и типизированные хуки `useAppDispatch`, `useAppSelector` (если есть).
-- **HTTP и ошибки API**:
-  - не импортировать типы **сторонних HTTP‑библиотек**, которых нет в актуальных зависимостях и существующих слайсах (ориентир — **`package.json`** и соседние файлы);
-  - когда сервис возвращает **обёртку ответа** прикладного клиента — использовать **соответствующий тип из `@/types`** (как в barrel и в аналогичных thunk’ах);
-  - при ошибках после вызова сервиса — опираться на **тот же класс/контракт ошибки транспорта**, что использует общий клиент (из `@/types`), и разбирать тело/статус **по полям текущей реализации**, а не по воображаемому API;
-  - в **`catch`** предпочитать **`instanceof`** на класс ошибки транспорта из `@/types` (если он есть в коде) вместо голого `as`, когда это выразимо без шума (см. `no-type-assertion-as-import-export.mdc`).
 - Для сущностей:
-  - доменные типы (включая вычисляемые поля) определять в `app/src/types/**`, экспортировать через barrel и импортировать в слайсы из `@/types` как **источник правды** для структуры данных (`public-imports.mdc`);
+  - доменные типы (включая вычисляемые поля) определять в `@/types/**` и импортировать в слайсы как **источник правды** для структуры данных;
   - избегать дублирования описаний сущностей в нескольких местах.
-- **Граница домена**: в **state** хранить доменные модели; тип **обёртки ответа клиента** допустим как тип **возвращаемого значения thunk** или промежуточно до маппинга — без дублирования DTO в полях state без нужды (согласовано с `api-services.mdc` и `http-client.mdc`).
 
 # Тестирование слайсов
 
@@ -62,5 +56,4 @@ alwaysApply: false
 - Не класть логику API внутрь редюсеров/компонентов.
 - Строго типизировать state и actions.
 - Использовать единый стиль именования actions и селекторов, как в существующих слайсах.
-- При работе с ошибками и ответами HTTP опираться на **`http-client.mdc`** и контракты из `@/types`, а не на типы внешних HTTP‑библиотек вне зависимостей проекта.
 

package/presets/cursor/next/rules/tests-unit.mdc

@@ -1,31 +1,17 @@
 ---
 description: Unit и интеграционные тесты (Testing Library и runner проекта)
-globs:
-  - app/src/**/*.spec.{ts,tsx}
-  - app/src/**/*.test.{ts,tsx}
+globs: src/**/*.test.{ts,tsx}
 alwaysApply: false
 ---
 
 # Общие правила тестирования
 
-- **Имена файлов:** для **новых** тестов использовать суффикс **`*.spec.ts` / `*.spec.tsx`**. Существующие **`*.test.ts` / `*.test.tsx`** не переименовывать без отдельной задачи (легаси).
 - **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@testing-library/react**.
 - Основная цель тестов:
   - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
-- **Именование unit‑тестов** (строки в `describe` / `it` / `test`):
-  - формулировки **только на русском языке** — понятные бизнес‑фразы (что проверяется и какой ожидается результат);
-  - **каждое предложение** в названии **начинается с заглавной буквы** (в том числе после `.`, `!`, `?` и при нескольких предложениях в одной строке); первая буква всей строки — тоже заглавная.
-  - **Проверка в CI:** ESLint (`jest/valid-title` в `app/eslint.config.mjs`) требует, чтобы строка начиналась с русской заглавной (А–Я, Ё), и запрещает пробел после точки, за которым сразу идёт строчная буква (типичный случай нарушения «с заглавной после точки»).
-
-```typescript
-// ✅ Хорошо
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-it('При ошибке сети показывается сообщение об ошибке', () => {})
-
-// ❌ Плохо (не с заглавной после точки; или не русский)
-it('Возвращает пустой список. пользователь не авторизован', () => {})
-it('Returns empty list when user is guest', () => {})
-```
+ - Именование:
+  - названия `describe` / `it` / `test` и любые человекочитаемые описания в тестах **должны быть на русском языке**, формулироваться как понятные бизнес‑фразы (что именно ожидается от системы).
+  - строки в `describe` / `it` / `test` **должны начинаться с заглавной буквы**.
 
 # Тесты компонентов
 
@@ -41,11 +27,6 @@ it('Returns empty list when user is guest', () => {})
   - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
 - Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
 
-# HTTP‑клиент
-
-- При изменении **реализации общего HTTP‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `app/src/lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
-- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
-
 # Мапперы и преобразование данных
 
 - Функции маппинга данных (DTO -> доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
@@ -54,13 +35,12 @@ it('Returns empty list when user is guest', () => {})
 # Требование к агенту
 
 При добавлении тестов:
-- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
+- Следовать существующей структуре и паттернам тестов в `src/**/__tests__/**` или рядом с компонентом.
 - Добавлять тесты для критичных веток логики и edge‑кейсов.
  - При работе с данными:
-   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
-   - по возможности опираться на данные и обработчики из `app/src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
- - Размещение:
-   - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.tsx`.
-   - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
-   - **новые** файлы — `*.spec.ts` / `*.spec.tsx` (см. блок «Имена файлов» выше).
+   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types/**`, не дублировать интерфейсы в тестах;
+   - по возможности опираться на данные и обработчики из `src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
+ - При написании unit‑тестов рядом с компонентом или модулем:
+   - **не создавать** поддиректорию `__tests__` внутри папки компонента;
+   - именовать файлы тестов с суффиксом `*.spec.ts` / `*.spec.tsx`, а не `*.test.ts` / `*.test.tsx`.
 

package/CHANGELOG.md

@@ -1,22 +0,0 @@
-# Changelog
-
-## 0.2.0
-
-### Breaking
-
-- **Import rules merged:** `types-public-imports.mdc` and `api-public-imports.mdc` → **`public-imports.mdc`** (Claude: `architecture/public-imports.md`). Old filenames remain as deprecated stubs for one release cycle.
-- **`feature-delivery-flow.mdc` removed** — content merged into `feature-delivery-workflow.mdc`.
-- **`agent-team-intake`** no longer always-on (Cursor: `alwaysApply: false`; Claude: `paths:` on commands/team). Use orchestrator or `/task`.
-
-### Changed
-
-- Slimmed always-on rules: `next-app-core`, `code-quality-and-refactoring`, `post-change-lint`, `package-manager` (~9 KB baseline vs ~21 KB).
-- Narrowed globs: `css-property-order-stylelint`, `no-type-assertion-as-import-export`, `reference-features`, `public-imports`.
-- `css-property-order` stub — property list delegated to Stylelint `--fix`.
-- Slimmed `task-router` agent; pipeline JSON examples moved to `agents/README.md`.
-- Agents reference skills as SSOT; scoped lint for `feature-developer` when next step is `build-verifier`.
-- Orchestrator: explicit fast-path when to skip pipeline.
-
-## 0.1.42
-
-Prior releases — see git history.

package/presets/claude/next/agents/accessibility-reviewer.md

@@ -1,65 +0,0 @@
----
-name: accessibility-reviewer
-description: Accessibility review specialist. Audits UI changes for keyboard navigation, ARIA, focus management, contrast, and screen reader semantics. Writes a11y-review.md only; never edits production code.
-model: inherit
----
-
-You are an accessibility reviewer for a Next.js React frontend.
-
-## Inputs
-
-1. `.claude/team/tasks/<slug>/brief.md` — acceptance criteria and UI scope.
-2. `.claude/team/tasks/<slug>/decomposition.md` — UI-related tasks.
-3. Git diff for changed UI files under `app/src/ui/**`.
-4. `rules/ui-and-accessibility/react-ui.md` and project a11y conventions.
-
-## Review scope
-
-- Keyboard navigation and focus order (Tab, Shift+Tab, Escape, Enter).
-- Focus trap in modals/drawers; focus return on close.
-- ARIA roles, labels, `aria-*` attributes, live regions.
-- Semantic HTML vs div-only interactive elements.
-- Form labels, error announcements, required field indication.
-- Color contrast and non-color-only state indicators (where inferable from code/styles).
-- Skip links, heading hierarchy, landmark regions.
-
-## Output
-
-Write `.claude/team/tasks/<slug>/a11y-review.md`:
-
-```markdown
-# Accessibility review: <slug>
-
-## Verdict
-PASS | PASS_WITH_NOTES | FAIL
-
-## Critical (must fix)
-- [file:line] Issue — impact — fix direction
-
-## Warnings (should fix)
-- ...
-
-## Suggestions
-- ...
-
-## AC coverage
-| Criterion | Status | Notes |
-|-----------|--------|-------|
-```
-
-## On completion
-
-Update `status.json`:
-
-```json
-{
-  "slug": "<slug>",
-  "currentAgent": "accessibility-reviewer",
-  "state": "completed",
-  "updatedAt": "<ISO8601>"
-}
-```
-
-If **FAIL**, set `"state": "changes_requested"` and list specific fixes for `feature-developer`.
-
-Do not modify production code or tests.