@bonesofspring/ai-rules 0.2.2 → 0.2.4

package/presets/cursor/next/rules/layer-barrel-exports.mdc

@@ -0,0 +1,59 @@
+---
+description: Двухуровневые barrel-экспорты для слоёв с регламентированным public API
+globs: app/src/**/index.ts
+alwaysApply: false
+---
+
+# Barrel-экспорты слоёв с public API
+
+## Когда применять
+
+Для **любого слоя** (каталога, пакета, bounded context), у которого:
+
+- есть **корневой barrel** — единая точка импорта для внешних потребителей;
+- deep-импорты внутрь слоя **запрещены** снаружи (ESLint `no-restricted-imports`, правила `public-imports.mdc`).
+
+Примеры 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 (`public-imports.mdc`).
+2. Создать/обновить **локальный** `index.ts` — только публичные символы.
+3. Если в слое есть **фасад/агрегатор** (`*ApiService.ts`, `rootReducer`, …) — подключить модуль там.
+4. Добавить **реэкспорт** новых публичных символов в **корневой barrel** слоя.
+5. **Проверка:** grep по имени символа или пути `./<Module>` в корневом barrel; снаружи слоя нет deep-импортов.
+
+Модуль **не готов**, пока чеклист не пройден.
+
+## Как найти регламентированные слои в репозитории
+
+1. Правила `public-imports.mdc` в `.cursor/rules/`.
+2. ESLint `no-restricted-imports` — паттерны `@/<layer>/*` с исключением barrel.
+3. `architecture-boundaries.mdc`, README проекта.
+
+## В этом репозитории
+
+| Слой | Корневой barrel | Правило импортов |
+|------|-------------------|------------------|
+| API | `app/src/api/index.ts` | `public-imports.mdc` |
+| Types | `app/src/types/index.ts` | `public-imports.mdc` (+ `@/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/cursor/next/rules/navigation-router-stack.mdc

@@ -0,0 +1,62 @@
+---
+description: Выбор API навигации по стеку проекта (Next.js vs React Router)
+globs: app/src/app/**/*,app/**/app/**/*
+alwaysApply: false
+---
+
+# Навигация и роутинг: сначала стек проекта
+
+**При любой задаче, связанной с навигацией, переходами между страницами, 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.  
+- Для **этого** репозитория базовый ориентир — **`next-app-core.mdc`**: Next.js; предпочитать **`next/navigation`** и **`next/link`** там, где используется App Router.

package/presets/cursor/next/rules/navigation-router-ui.mdc

@@ -0,0 +1,16 @@
+---
+description: Навигация в UI-компонентах — краткий ориентир (полный аудит стека — navigation-router-stack.mdc)
+globs: app/src/ui/**/*.tsx
+alwaysApply: false
+---
+
+# Navigation in UI components
+
+Перед ссылками, программной навигацией или работой с URL в UI:
+
+1. **`package.json`** workspace приложения — `next` vs `react-router-dom`.
+2. **Соседние импорты** той же фичи (`next/navigation`, `next/link` vs `react-router-dom`).
+3. **Обёртки проекта** (`@/ui/...` Link) — предпочтительнее сырого API роутера.
+4. **По умолчанию (preset):** Next.js App Router → `next/navigation` + `next/link` (`next-app-core.mdc`, `next-app-router.mdc`).
+
+Полный аудит (дерево маршрутов, гибриды, lockfile): **`navigation-router-stack.mdc`** — при правках `app/src/app/**`.

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

@@ -5,73 +5,30 @@ alwaysApply: true
 
 # Стек и окружение
 
-Конкретные версии пакетов и инструментов — **из `package.json` и конфигов целевого репозитория**. Ниже — рамка preset (Next.js + React + TypeScript), без привязки к конкретному вендору UI, моков или APM:
+Конкретные версии — **из `package.json` и конфигов целевого репозитория**. Рамка preset: Next.js, React, TypeScript; runner/e2e/mocks/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 слой** (`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 | `app/src/ui/**` (pages, components) | `react-ui.mdc`, `architecture-boundaries-ui.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 знает только о доменных типах и публичных интерфейсах 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/**`.
+Границы слоёв, порты/адаптеры, UI→API — **`architecture-boundaries.mdc`**. Импорты `@/types`, `@/api` — **`public-imports.mdc`**.
 
 # Работа агента
 
-При генерации кода:
-- Определить целевой слой (UI/store/API/типизация/тесты).
-- Найти в соответствующей директории похожие примеры и **копировать архитектурный паттерн** (структура файлов, типы, именование).
-- Не упрощать архитектуру в ущерб существующим слоям (не тянуть API в UI, не описывать "DTO" прямо в компонентах).
- - Избегать использования `any` при типизации кода; при необходимости использовать `unknown` с последующим безопасным сужением типов.
- - После создания или редактирования любых файлов **обязательно проверять проект на ошибки TypeScript и ESLint** (либо точечно по изменённым файлам, либо по всему проекту) и устранять найденные проблемы, если это возможно без изменения бизнес‑логики).
-
+- Архитектура и импорты: `architecture-boundaries.mdc`, `public-imports.mdc`
+- Фичи: `feature-delivery-workflow.mdc` + skill `feature-delivery`
+- После правок: **вызвать** `post-change-lint.mdc` (requestable, обязателен после code edits); менеджер пакетов: `package-manager.mdc`
+- Копировать паттерны соседних файлов в целевом слое; не использовать `any` (предпочитать `unknown` + сужение)

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

@@ -0,0 +1,36 @@
+---
+description: Next.js App Router — Server/Client Components, data fetching, loading and error UI
+globs: app/src/app/**/*,app/**/app/**/*
+alwaysApply: false
+---
+
+# 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 согласован с дизайн-системой.
+- Навигация — `navigation-router-stack.mdc` + 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/**` и повтори структуру (`reference-features.mdc`).

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

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

package/presets/cursor/next/rules/no-type-assertion-as-import-export.mdc

@@ -0,0 +1,60 @@
+---
+description: Избегать приведения типов через as на границах модулей (импорт/экспорт)
+globs:
+  - app/src/api/**/*
+  - app/src/store/**/*
+  - app/src/types/**/*
+alwaysApply: false
+---
+
+# Не использовать `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 }` — алиас типа в импорте типов.
+
+## Требование
+
+- На **публичной границе модуля** (то, что **экспортируется** из файла / barrel, и то, что сразу **присваивается импортированным символам** с принудительным приведением) **не использовать** `as Тип` для «подгонки» типов, если можно обойтись нормальной типизацией.
+
+## Предпочитать вместо `as`
+
+- явную аннотацию: `const x: T = ...` / `function f(): T`;
+- **дженерики** у функций и классов;
+- **`satisfies`** (когда нужно проверить совместимость без сужения до `any`);
+- сужение **`unknown`** после проверки (type guards, `zod` и т.п.);
+- правку **исходных типов/DTO/мапперов**, а не assertion на выходе.
+
+## Когда `as` допустим
+
+- взаимодействие с **не типизированными** или некорректно типизированными внешними модулями, где нет разумной альтернативы;
+- узкие места после **валидации** данных, если типовый гард всё ещё не выразить без шума (предпочтительно всё же guard/`satisfies`);
+- **`as const`** — когда нужны литеральные типы и широкий вывод ломает контракт (это отдельный механизм; применять по делу, не как замену типизации API).
+- блок **`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 Тип` на экспортируемые сущности и на цепочку import → export без явной необходимости; по возможности исправлять контракт типов в источнике.
+- В слайсах и сервисах при обработке ошибок API сначала рассматривать **`instanceof`** на класс ошибки транспорта из `@/types` по образцу существующего кода (`http-client.mdc`, `store-rtk.mdc`).

package/presets/cursor/next/rules/package-manager.mdc

@@ -0,0 +1,16 @@
+---
+description: Перед командами в терминале определять менеджер пакетов репозитория и использовать только его
+alwaysApply: true
+---
+
+# Менеджер пакетов (терминал)
+
+Перед **`npm install` / `yarn` / `pnpm` / `bun`** и **`… run …`** определи менеджер репозитория и **используй только его**.
+
+## Как определить
+
+1. **`packageManager`** в `package.json` (корень или `app/package.json`).
+2. **Lockfile** рядом: `yarn.lock` → yarn; `pnpm-lock.yaml` → pnpm; `package-lock.json` → npm; `bun.lock(b)` → bun.
+3. Если неоднозначно — где `node_modules` и какой lockfile в CI.
+
+Рабочий каталог для scripts — **`app/`**. Примеры: `yarn lint`, `pnpm run test`. Не угадывай — проверь файлы.

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

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

package/presets/cursor/next/rules/post-change-lint.mdc

@@ -0,0 +1,40 @@
+---
+description: Прогон ESLint и Stylelint после изменений кода. Requestable — подгружать после правок app/**; агенты обязаны запускать после code edits.
+alwaysApply: false
+---
+
+# Линтеры после изменений кода
+
+**Requestable, но обязателен при изменениях кода:** правило не always-on (экономия контекста); после правок исходников агент **должен** следовать этому чеклисту.
+
+## Когда применять
+
+После **любого** изменения исходников в `app/**` (TS/TSX/JS/MJS, CSS, styled/Linaria в `.ts`/`.tsx`).
+
+Исключения: правки документации вне `app/`, конфигов CI, `.cursor/rules/**`, если исполняемый код приложения не менялся.
+
+**Pipeline exception:** если задача идёт через agent team и следующий шаг — `build-verifier`, developer может ограничиться lint/type-check **изменённых файлов**; полный прогон — обязанность `build-verifier`. В single-agent режиме (без pipeline) — всегда полный прогон.
+
+## Обязательные команды
+
+Рабочий каталог — **`app/`**. Менеджер пакетов — **`package-manager.mdc`**.
+
+1. **`lint:js`** — полный ESLint по проекту.
+2. **`lint:css`** — полный Stylelint (`**/*.{css,ts}`).
+
+Точечный lint на один файл **не заменяет** полный прогон перед завершением задачи (кроме pipeline exception выше).
+
+## Алгоритм
+
+1. Завершить правки кода.
+2. Запустить **`lint:js`** и **`lint:css`** из `app/`.
+3. Проанализировать весь вывод; исправить errors/warnings в изменённых файлах; для Stylelint — **`lint:css --fix`** если автоисправимо.
+4. Повторить до exit code 0 или зафиксировать блокер в ответе пользователю.
+5. **`type-check`** при изменениях TypeScript. CI-уровень: **`lint`** (= `lint:js` + `lint:css` + `type-check`).
+
+## Что исправлять
+
+- **Errors** — обязательно.
+- **Warnings** — обязательно в файлах задачи; вне скоупа — упомянуть, если мешают нулевому exit code.
+
+Конфиги: `app/eslint.config.mjs`, `app/.stylelintrc` (порядок CSS — `css-property-order-stylelint.mdc`).

package/presets/cursor/next/rules/public-imports.mdc

@@ -0,0 +1,48 @@
+---
+description: Импорт доменных типов и API только через публичные barrel @/types и @/api
+globs:
+  - app/src/ui/**/*
+  - app/src/store/**/*
+  - app/src/lib/**/*
+  - app/src/types/**/*
+  - app/src/api/**/*
+alwaysApply: false
+---
+
+# Публичные импорты (`@/types`, `@/api`)
+
+**Коллизии:** импорт типов — раздел `@/types` ниже; API вне `app/src/api/**` — раздел `@/api` ниже (дублирует ESLint `no-restricted-imports` в `app/eslint.config.mjs`).
+
+## `@/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` по **`layer-barrel-exports.mdc`**.
+
+## `@/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` по **`layer-barrel-exports.mdc`**.

package/presets/cursor/next/rules/react-a11y-coding.mdc

@@ -0,0 +1,37 @@
+---
+description: Accessibility при написании React UI — семантика, формы, focus, keyboard
+globs: app/src/ui/**/*.tsx,app/src/ui/**/*.ts
+alwaysApply: false
+---
+
+# A11y при разработке UI
+
+Reviewer (`accessibility-reviewer`) проверяет diff; эти правила — **при написании** кода.
+
+## Семантика и ARIA
+
+- Предпочитать **нативные элементы** (`button`, `a`, `label`, `input`) вместо `div` с `onClick`.
+- **`role` / `aria-*`** — только когда нативного аналога нет; не дублировать то, что даёт семантика.
+- Заголовки — иераархия `h1`–`h6` без пропусков уровней ради стилей.
+
+## Формы
+
+- Каждый input связан с **`label`** (`htmlFor` / `id` или обёртка).
+- Сообщения об ошибках — **`aria-describedby`**, `aria-invalid` при validation errors.
+- Кнопки submit vs button — явный `type`.
+
+## Клавиатура и focus
+
+- Все интерактивные элементы **достижимы с Tab** и активируются Enter/Space где ожидается.
+- **Modals/drawers** — focus trap, возврат focus на trigger при закрытии, Esc закрывает (если по UX).
+- Не удалять видимый **focus outline** без замены на доступный custom focus style.
+
+## Контент
+
+- Изображения — **`alt`** (пустой `alt` только для декора).
+- Иконки-кнопки — **`aria-label`** или visually hidden text.
+- Динамические обновления — `aria-live` для критичных status/error (умеренно).
+
+## Проверка
+
+- При сомнении — devtools a11y tree или `accessibility-reviewer` в pipeline для UI-heavy фич.