@bonesofspring/ai-rules 0.1.31 → 0.1.32

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bonesofspring/ai-rules",
-  "version": "0.1.31",
+  "version": "0.1.32",
   "description": "Presets of Cursor and Claude rules/commands for Revy Ross personal use",
   "license": "MIT",
   "author": "Revy Ross",

package/presets/claude/next/agents/playwright-test-generator.md

@@ -10,7 +10,7 @@ You are a Playwright Test Generator, an expert in browser automation and end-to-
 Your specialty is creating robust, reliable Playwright tests that accurately simulate user interactions and validate
 application behavior.
 
-## Project-specific test structure (emedcard-web)
+## Project-specific test structure (Next.js preset)
 
 In this project you MUST respect the existing e2e layout:
 
@@ -22,9 +22,9 @@ In this project you MUST respect the existing e2e layout:
 When you generate tests:
 
 - Use the corresponding `*.cases.md` file under `app/__tests__/e2e/**` as the source plan (for example,
-  `app/__tests__/e2e/MedcardRecords/medcard-records.cases.md`).
+  `app/__tests__/e2e/OrderHistory/order-history.cases.md`).
 - Write or update Playwright test files only under `app/__tests__/e2e/**` (for example,
-  `app/__tests__/e2e/MedcardRecords/medcard-records.spec.ts`) instead of creating files in a separate `tests/` folder.
+  `app/__tests__/e2e/OrderHistory/order-history.spec.ts`) instead of creating files in a separate `tests/` folder.
 
 # For each test you generate
 - Obtain the test plan with all the steps and verification specification

package/presets/claude/next/agents/playwright-test-healer.md

@@ -10,7 +10,7 @@ You are the Playwright Test Healer, an expert test automation engineer specializ
 resolving Playwright test failures. Your mission is to systematically identify, diagnose, and fix
 broken Playwright tests using a methodical approach.
 
-## Project-specific test structure (emedcard-web)
+## Project-specific test structure (Next.js preset)
 
 In this project you MUST respect the existing e2e layout:
 
@@ -23,8 +23,8 @@ When healing tests:
 
 - Only read and modify `*.spec.ts` files under `app/__tests__/e2e/**`.
 - Use the `*.cases.md` file in the same folder as the failing test as the source of truth for intended behavior
-  (for example, `app/__tests__/e2e/MedcardRecords/medcard-records.cases.md` for
-  `app/__tests__/e2e/MedcardRecords/medcard-records.spec.ts`).
+  (for example, `app/__tests__/e2e/OrderHistory/order-history.cases.md` for
+  `app/__tests__/e2e/OrderHistory/order-history.spec.ts`).
 
 Your workflow:
 1. **Initial Execution**: Run all tests using `test_run` tool to identify failing tests

package/presets/claude/next/agents/playwright-test-planner.md

@@ -10,7 +10,7 @@ You are an expert web test planner with extensive experience in quality assuranc
 scenario design. Your expertise includes functional testing, edge case identification, and comprehensive test coverage
 planning.
 
-## Project-specific test structure (emedcard-web)
+## Project-specific test structure (Next.js preset)
 
 In this project you MUST respect the existing e2e layout:
 
@@ -22,7 +22,7 @@ In this project you MUST respect the existing e2e layout:
 When you create or update a test plan:
 
 - Use the appropriate `*.cases.md` file under `app/__tests__/e2e/**` (for example,
-  `app/__tests__/e2e/MedcardRecords/medcard-records.cases.md`) instead of creating files in a separate `specs/` folder.
+  `app/__tests__/e2e/OrderHistory/order-history.cases.md`) instead of creating files in a separate `specs/` folder.
 - Treat these `*.cases.md` files as the canonical, human-readable test plans for the Generator and Healer agents.
 
 You will:

package/presets/cursor/next/rules/api-services.mdc

@@ -1,5 +1,5 @@
 ---
-description: Конвенции API сервисов и мапперов Medcard
+description: Конвенции API сервисов и мапперов
 globs: src/api/services/**/*.ts
 alwaysApply: false
 ---
@@ -7,7 +7,7 @@ alwaysApply: false
 # Роль API слоя
 
 - Инкапсулировать всё, что связано с:
-  - HTTP/axios запросами,
+  - HTTP‑запросами (через принятый в проекте клиент),
   - URL/путями,
   - заголовками и кодами ответов,
   - DTO backend.
@@ -17,8 +17,8 @@ alwaysApply: false
 
 # Структура модулей
 
-- Для каждой доменной области (Medcard, OfflineConsultation, RequestForAnalysis и т.п.):
-  - отдельный каталог в `src/api/services/MedcardApiService/**`.
+- Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
+  - отдельный каталог в `src/api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
 - Внутри модуля:
   - файлы с вызовами API (`index.ts` или `*.service.ts`);
   - файлы мапперов (`*responseMappers.ts`);
@@ -42,8 +42,8 @@ alwaysApply: false
   - не должен "глотать" ошибки без следа;
   - либо бросает доменные/унифицированные ошибки;
   - либо возвращает результат в `Result<T, E>`‑подобной форме (если такой паттерн принят в проекте).
-- Интеграция с Sentry / OpenTelemetry:
-  - если используется — делать её централизованно (например, в HTTP‑клиенте или обёртках), а не в каждом методе.
+- Интеграция с APM/трассировкой (если есть в проекте):
+  - централизованно (HTTP‑клиент, обёртки), а не в каждом методе сервиса.
 
 # Требование к агенту
 
@@ -52,5 +52,5 @@ alwaysApply: false
 - Не смешивать слой API и UI/store:
   - компоненты не должны зависеть от DTO;
   - store не должен знать о HTTP‑деталях (URL, коды).
-- При использовании API‑сервисов в UI, store и утилитах импортировать только из public API файлов модуля (например, `@/api/services/MedcardApiService/.../index`), а не из внутренних файлов‑реализаций.
+- При использовании API‑сервисов в UI, store и утилитах импортировать только из public API файлов модуля (например, `@/api/services/OrdersApi/.../index`), а не из внутренних файлов‑реализаций.
 

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

@@ -8,7 +8,7 @@ alwaysApply: true
 - **UI (src/ui/**)**:
   - Может импортировать: `@/ui/**`, `@/store/**`, `@/types/**`, `@/api/services/**` (через публичные интерфейсы).
   - Не должен:
-    - обращаться к HTTP/axios напрямую;
+    - обращаться к HTTP‑клиенту напрямую;
     - знать детали DTO backend — только доменные типы.
 - **Store (src/store/**)**:
   - Может импортировать: `@/store/**`, `@/api/services/**`, `@/types/**`.
@@ -31,12 +31,12 @@ alwaysApply: true
 
 # Организация фич
 
-- Для сложных фич (например, OfflineConsultation):
-  - Страница: `src/ui/pages/OfflineConsultationPage/**`.
+- Для сложных фич (например, `OrderCheckout`):
+  - Страница: `src/ui/pages/OrderCheckoutPage/**`.
   - Локальные компоненты: поддиректории `components/**` внутри страницы.
-  - Связанный store: `src/store/slices/OfflineConsultation/**`.
-  - API: `src/api/services/MedcardApiService/OfflineConsultation/**`.
-  - Типы: `src/types/OfflineConsultation.types.ts` или аналогичный файл.
+  - Связанный 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

@@ -10,7 +10,7 @@ alwaysApply: true
   - минимизировать "стилистический шум" (лишние правки форматирования, rename без нужды).
 - Перед добавлением нового решения:
   - искать аналогичное в коде и **повторять подход**, а не изобретать новый.
-  - проверять, нет ли уже подходящего компонента или паттерна в `@sds/*` или существующем UI‑коде, прежде чем добавлять новый кастомный контрол.
+  - проверять, нет ли уже подходящего компонента или паттерна в существующем UI‑коде и пакетах проекта, прежде чем добавлять новый кастомный контрол.
   - использовать при обращении к чужим модулям только их **public API** (index/barrel‑файлы и явно экспортируемые сущности), а deep‑импорты внутренних файлов рассматривать как повод для рефакторинга.
 
 # Рефакторинг при изменениях
@@ -23,7 +23,7 @@ alwaysApply: true
   - вынести дублирующуюся логику в общий хук/утилиту;
   - типизировать `any` и `unknown`, если это безболезненно;
   - разделить слишком крупный компонент на несколько более простых;
-  - заменить локальные «магические» CSS‑значения (цвета, отступы, размеры) на токены из `@sds/tokens-*`, `@sds/brand-colors`, `@sds/tokens-typography` или централизованные UI‑примитивы;
+  - заменить локальные «магические» CSS‑значения (цвета, отступы, размеры) на токены/примитивы дизайна проекта;
   - заменить deep‑импорты внутренних файлов других модулей на обращения к их public API.
 
 # Ограничения

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

@@ -1,5 +1,5 @@
 ---
-description: Требования к code review агентами Cursor для GitLab merge requests в emedcard-web
+description: Требования к code review агентами Cursor для merge requests
 alwaysApply: true
 ---
 
@@ -7,12 +7,12 @@ alwaysApply: true
 
 - **Когда применять**
   - Если пользователь просит: "проведи ревью", "оценить MR/ветку/дифф", "посмотри изменения".
-  - Опираться на локальный репозиторий: текущую ветку, `git diff` и открытые файлы, а не на данные GitLab API.
+  - Опираться на локальный репозиторий: текущую ветку, `git diff` и открытые файлы, а не на данные внешнего API хостинга.
 
 - **Что обязан проверить агент**
   - **Архитектура и слои**:
-    - Соблюдение правил из `architecture-boundaries.mdc` и `emedcard-core.mdc`:
-      - UI (`src/ui/**`) не ходит напрямую в HTTP/axios и не знает DTO.
+    - Соблюдение правил из `architecture-boundaries.mdc` и `next-app-core.mdc`:
+      - UI (`src/ui/**`) не ходит напрямую в HTTP‑клиент и не знает DTO.
       - Store (`src/store/**`) не зависит от UI и не работает с "сырыми" HTTP.
       - API (`src/api/services/**`) не тянет UI/store, использует мапперы.
   - **Импорты и организация кода**:
@@ -22,9 +22,9 @@ alwaysApply: true
   - **Типы и TS‑строгость**:
     - Не допускать новых `any`; предпочитать доменные типы из `src/types/**`.
     - Проверять корректность пропсов/возвращаемых типов, особенно в UI и API‑слое.
-  - **UI, стили и SDS**:
-    - Для компонентов и стилей сверяться с `react-ui.mdc` и `emedcard-core.mdc`:
-      - Использовать Linaria и компоненты/токены `@sds/*`, а не "магические" значения.
+  - **UI и стили**:
+    - Для компонентов и стилей сверяться с `react-ui.mdc` и `next-app-core.mdc`:
+      - Соблюдать принятый в проекте способ стилей и общие UI‑примитивы/токены, а не "магические" значения.
       - Сохранять консистентность с существующими компонентами и паттернами.
   - **Тесты**:
     - Проверять, что для нетривиальных изменений:
@@ -41,7 +41,7 @@ alwaysApply: true
     - без "больших рефакторингов" в духе `code-quality-and-refactoring.mdc`, если задача локальная.
 
 - **Ограничения для агента**
-  - Не придумывать несуществующие GitLab сущности (лейблы, авторов, статусы пайплайнов).
+  - Не придумывать несуществующие метаданные из хостинга (лейблы MR, авторов, статусы CI), если их нет в локальных данных.
   - Не менять общую архитектуру фичи без прямого запроса пользователя.
   - Следовать принципу "boy scout rule": предлагать улучшения, которые реально можно внести в рамках MR.
 

package/presets/cursor/next/rules/{emedcard-core.mdc → next-app-core.mdc}

@@ -1,18 +1,18 @@
 ---
-description: Базовые принципы, стек и архитектура emedcard-web
+description: Базовые принципы, стек и архитектура Next.js приложения (preset)
 alwaysApply: true
 ---
 
 # Стек и окружение
 
-- Проект: **Next.js 16**, **React 19**, **TypeScript 5 (strict)**.
-- Сборка: Webpack/Rspack, Node >= 24.
-- Тесты: Jest + Testing Library, e2e — Playwright.
-- Моки: **MSW** (`msw`, `public/mockServiceWorker.js`).
-- Стили и UI:
-  - CSS-in-JS: **Linaria** (`@linaria/core`, `@linaria/react`).
-  - Дизайн‑система: **SDS** (`@sds/*`) и набор дизайн‑токенов (`@sds/tokens-*`, `@sds/brand-colors`, `@sds/tokens-typography`).
-- Трассировка и мониторинг: Sentry, OpenTelemetry.
+Конкретные версии пакетов и инструментов — **из `package.json` и конфигов целевого репозитория**. Ниже — рамка preset (Next.js + React + TypeScript), без привязки к конкретному вендору UI, моков или APM:
+
+- **Фреймворк:** Next.js, React, TypeScript (strict — если включён в проекте).
+- **Сборка и Node:** как задано в репозитории.
+- **Тесты:** unit/integration — runner и библиотеки проекта; e2e — инструмент проекта (правила для агентов Playwright — в отдельных файлах preset).
+- **Моки HTTP/API:** если приняты в репо — повторять существующую схему (каталоги, регистрация, точка входа).
+- **Стили и UI:** способ стилизации и **дизайн‑система / токены** — как уже заведено в коде; приоритет общим примитивам и токенам вместо разрозненных «магических» значений.
+- **Наблюдаемость:** только если уже подключена в проекте — централизованно (клиент, обёртки), без дублирования в каждом методе.
 
 # Структура проекта (верхний уровень)
 
@@ -31,21 +31,21 @@ alwaysApply: true
   - `src/ui/pages/**` — страницы и контейнеры.
   - `src/ui/components/**` — переиспользуемые компоненты.
 - **Store слой** (`src/store/**`):
-  - `src/store/slices/**` — Redux Toolkit слайсы.
+  - `src/store/slices/**` — модули состояния (в этом preset — Redux Toolkit; подробности в `store-rtk.mdc`).
   - `src/store/middleware/**` — middleware для сайд‑эффектов (например, файлы, аналитика).
 - **API слой** (`src/api/services/**`):
   - Сервисы и мапперы, инкапсулирующие HTTP‑логику.
 - **Типы** (`src/types/**`):
-  - Общие доменные типы (OfflineConsultation, Medcard, Conclusion и т.д.).
+  - Общие доменные типы продукта (сущности предметной области, агрегаты и т.д.).
 - **Моки и тестовые данные** (`src/mocks/**`):
-  - Моковые данные и обработчики для MSW.
+  - По структуре и назначению — как принято в репозитории.
 
 # Общие архитектурные принципы
 
 - **Чёткое разделение слоёв**:
   - UI знает только о доменных типах и публичных интерфейсах store/API.
   - Store знает о доменных типах и API‑сервисах.
-  - API знает о транспортном слое (HTTP, axios и пр.) и DTO.
+  - API знает о транспортном слое (HTTP, выбранный клиент) и DTO.
 - **Никаких "проникновений" слоёв**:
   - UI не обращается к API напрямую — только через store или абстракции сервисов.
   - Store не работает напрямую с "сырыми" HTTP‑ответами — только через мапперы.
@@ -55,11 +55,11 @@ alwaysApply: true
 
 # Кодстайл и качества кода
 
-- Следовать конфигам `eslint.config.mjs`, `.prettierrc`, `.stylelintrc`.
+- Следовать конфигам линтеров и форматтера **проекта** (`eslint`, `prettier`, `stylelint` — какие есть в репо).
 - Поддерживать:
   - KISS, DRY, SOLID (в разумных пределах для фронта).
   - Модульность и переиспользование через компоненты, хуки, слайсы, сервисы.
-  - Консистентный визуальный стиль за счёт использования готовых компонентов `@sds/*` и дизайн‑токенов @sds вместо локальных "магических" значений.
+  - Визуальную консистентность за счёт принятых в проекте UI‑примитивов и токенов, а не разовых литералов в стилях.
 - При добавлении нового кода **искать и копировать существующие паттерны**:
   - Для страниц — аналогичные файлы в `src/ui/pages/**`.
   - Для блоков — компоненты в `src/ui/components/**`.
@@ -73,5 +73,5 @@ alwaysApply: true
 - Найти в соответствующей директории похожие примеры и **копировать архитектурный паттерн** (структура файлов, типы, именование).
 - Не упрощать архитектуру в ущерб существующим слоям (не тянуть API в UI, не описывать "DTO" прямо в компонентах).
  - Избегать использования `any` при типизации кода; при необходимости использовать `unknown` с последующим безопасным сужением типов.
- - После создания или редактирования любых файлов **обязательно проверять проект на ошибки TypeScript и ESLint** (либо точечно по изменённым файлам, либо по всему проекту) и устранять найденные проблемы, если это возможно без изменения бизнес‑логики.
+ - После создания или редактирования любых файлов **обязательно проверять проект на ошибки TypeScript и ESLint** (либо точечно по изменённым файлам, либо по всему проекту) и устранять найденные проблемы, если это возможно без изменения бизнес‑логики).
 

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

@@ -21,8 +21,8 @@ When acting as a **Planner** (or working with the Playwright planner agent):
 - **Treat `*.cases.md` as the canonical test plan files**, equivalent to Playwright's `specs/*.md`.
 - **Location**:
   - For a feature/domain, use the corresponding `*.cases.md` file under `app/__tests__/e2e`, e.g.:
-    - `app/__tests__/e2e/MedcardRecords/medcard-records.cases.md`
-    - `app/__tests__/e2e/RequestForAnalysis/schedule-display.cases.md`
+    - `app/__tests__/e2e/OrderHistory/order-history.cases.md`
+    - `app/__tests__/e2e/BillingReport/invoice-list.cases.md`
 - **Content requirements**:
   - Group scenarios by feature and subfeature using headings.
   - For each scenario include:
@@ -44,13 +44,13 @@ When acting as a **Generator** (or working with the Playwright generator agent):
   - Use the relevant `*.cases.md` file under `app/__tests__/e2e/**` as the test plan.
 - **Target for tests**:
   - Generate or update `*.spec.ts` files under the same folder, e.g.:
-    - plan: `app/__tests__/e2e/MedcardRecords/medcard-records.cases.md`
-    - tests: `app/__tests__/e2e/MedcardRecords/medcard-records.spec.ts` (or additional `*.spec.ts` in that folder if needed).
+    - plan: `app/__tests__/e2e/OrderHistory/order-history.cases.md`
+    - tests: `app/__tests__/e2e/OrderHistory/order-history.spec.ts` (or additional `*.spec.ts` in that folder if needed).
 - **Structure**:
   - Use `test.describe` to group by top-level plan sections (feature / user flow).
   - Use `test(...)` titles that match scenario names from the plan.
   - Prefer Page Object and fluent interfaces that already exist in this project, for example:
-    - `app/__tests__/e2e/MedcardRecords/MedcardRecordsPage.ts`
+    - `app/__tests__/e2e/OrderHistory/OrderHistoryPage.ts`
     - shared helpers under `app/__tests__/e2e/_shared/`.
 - **Seed**:
   - If a seed test is needed, use `app/__tests__/e2e/seed.spec.ts` as the reference for environment setup.

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

@@ -1,5 +1,5 @@
 ---
-description: Паттерны React/Next UI и Linaria в emedcard-web
+description: Паттерны React/Next UI и стилей (preset)
 globs: src/ui/**/*.tsx
 alwaysApply: false
 ---
@@ -10,8 +10,8 @@ alwaysApply: false
 - Компонент должен:
   - быть максимально "тонким" по бизнес‑логике;
   - делегировать состояние в store/хуки, если оно нужно в нескольких местах;
-  - использовать SDS‑компоненты как строительные блоки.
-- Перед созданием нового UI‑контрола агент должен явно рассмотреть существующие компоненты `@sds/*` и, если есть близкий по назначению, переиспользовать или расширить его вместо написания кастомного с нуля.
+  - опираться на **общие UI‑примитивы дизайна проекта** (пакеты или локальная библиотека компонентов), если они есть.
+- Перед новым кастомным контролом — поискать готовый или близкий компонент в репозитории / пакетах UI проекта и переиспользовать или расширить его.
 - Для повторяемой логики создавать `useSomething`‑хуки рядом или в `src/ui/hooks/**`.
  - При обращении к store, API, общим хелперам и утилитам компоненты и хуки должны использовать только их **public API** (например, `@/store`, `@/store/slices/Foo`, `@/lib/utils`), а не импортировать внутренние файлы реализации других модулей.
 
@@ -19,28 +19,23 @@ alwaysApply: false
 
 Для страницы/крупного блока:
 - `FeatureBlock.tsx` — JSX и композиция.
-- `styles.ts` — Linaria‑стили (`styled`, `css`).
+- `styles.ts` или соседний модуль стилей — по конвенции репозитория (CSS Modules, CSS-in-JS, и т.д.).
 - `index.ts` — реэкспорт (если нужно наружу).
 
 Для переиспользуемого компонента:
 - Папка с именем компонента:
   - `ComponentName.tsx`
-  - `styles.ts`
+  - файлы стилей по принятой схеме;
   - опционально: `types.ts`, `hooks.ts`.
 
-# Использование SDS и Linaria
+# Стили и дизайн‑токены
 
-- Для UI‑контролов использовать компоненты из `@sds/*`:
-  - кнопки, чекбоксы, поля ввода и т.д.
-- Стили:
-  - Использовать Linaria (`@linaria/react`, `@linaria/core`) со статическими стилями.
-  - Стили располагать в `styles.ts` рядом с компонентом.
-  - Применять дизайн‑токены из `@sds/tokens-*`, `@sds/brand-colors` и `@sds/tokens-typography` для цветов, типографики, отступов, размеров, радиусов, теней и т.д., а не “магические” значения.
+- Для визуала использовать **тот стек стилей и токенов, который уже в проекте** (переменные, тема, общие классы, дизайн‑пакет).
 - Избегать:
-  - inline‑стилей, кроме самых простых случаев;
-  - дублирования CSS, уже представленного в дизайн‑системе;
-  - «сырого» CSS вида `#xxxxxx`, `rgb(...)`, произвольных `padding: 17px`, `margin: 23px`, нестандартизированных размеров и теней.
-  - Если подходящего токена пока нет, допускается ввод локальных примитивов (например, `const spacingMedium = '16px'`) **в одном месте** с последующим переездом на официальные токены @sds при первой возможности.
+  - inline‑стилей, кроме простых случаев;
+  - дублирования оформления, уже закрытого общими примитивами;
+  - «магических» литералов (`#xxxxxx`, произвольные `17px` / `23px`), если в проекте есть токены или масштаб.
+- Если подходящего токена нет — локальный примитив **в одном месте** с последующим выравниванием под систему дизайна при возможности.
 
 # Пропсы и типизация
 
@@ -61,7 +56,7 @@ alwaysApply: false
 # Тестирование UI
 
 - Для нетривиальных компонентов добавлять тесты:
-  - использовать `@testing-library/react` и `@testing-library/jest-dom`.
+  - **Testing Library** для React, как принято в проекте;
   - проверять поведение и бизнес‑правила, а не конкретные CSS‑классы.
 - В тестах ориентироваться на текст, роли и aria‑атрибуты.
 

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

@@ -31,7 +31,7 @@ alwaysApply: false
   - через `createAsyncThunk` или RTK Query.
   - внутри thunk:
     - вызывать API через сервисы из `@/api/services/**`;
-    - не использовать `fetch`/`axios` напрямую.
+    - не вызывать HTTP‑клиент напрямую — только через сервисы `@/api/services/**`.
 - Сайд‑эффекты (логирование, аналитика, работа с файлами):
   - выносить в middleware (`src/store/middleware/**`) или специализированные слайсы.
 

package/presets/cursor/next/rules/tests-e2e-structure.mdc

@@ -19,7 +19,7 @@ alwaysApply: false
 - Каждый сценарий из `*.cases.md` должен иметь соответствующий тест (или набор тестов).
 - **Нельзя** ослаблять проверки в тестах, если это противоречит бизнес‑ожиданиям из планов.
 - Предпочтительно использовать:
-  - page‑objects (например, `MedcardRecordsPage.ts`);
+  - page‑objects (например, `OrderHistoryPage.ts`);
   - общие хелперы из `_shared`.
 
 # Именование e2e‑тестов
@@ -29,10 +29,10 @@ alwaysApply: false
 - Формат заголовков e2e‑тестов (`test(...)` / `it(...)`):
   - перед текстовым описанием сценария указывается **префикс с номером** в формате: `ПРЕФИКС-XXX Описание сценария`.
   - `ПРЕФИКС` — аббревиатура из **первых букв слов** тестируемой сущности, записанная **латиницей в верхнем регистре**.
-    - пример: `MedcardRecords` → `MR`, `RequestForAnalysis` → `RFA`.
+    - пример: `OrderHistory` → `OH`, `BillingReport` → `BR`.
   - `XXX` — порядковый номер теста **с тремя разрядами и лидирующими нулями**: `001`, `002`, `010`, `123` и т.д.
   - пример полного названия e2e‑теста:
-    - `test('MR-001 Отображается список записей медкарты', async ({ page }) => { ... })`
+    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })`
   - внутри одной сущности (`ПРЕФИКС`) номера тестов должны образовывать **непротиворечивую последовательность**, без дубликатов номеров.
 
 # data-testid для e2e

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

@@ -1,12 +1,12 @@
 ---
-description: Unit и интеграционные тесты (Jest, Testing Library)
+description: Unit и интеграционные тесты (Testing Library и runner проекта)
 globs: src/**/*.test.{ts,tsx}
 alwaysApply: false
 ---
 
 # Общие правила тестирования
 
-- Фреймворк: **Jest** + **@testing-library/react**.
+- **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@testing-library/react**.
 - Основная цель тестов:
   - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
  - Именование:
@@ -17,14 +17,14 @@ alwaysApply: false
 
 - Использовать `render` из `@testing-library/react`.
 - Ассерты:
-  - `@testing-library/jest-dom` (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
+  - матчеры DOM для Testing Library, как подключены в проекте (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
 - Взаимодействия:
   - `userEvent` из `@testing-library/user-event`.
 
 # Изоляция и моки
 
 - Для работы с API/store:
-  - мокать store (через test‑store) или использовать MSW, если это принято.
+  - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
 - Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
 
 # Мапперы и преобразование данных
@@ -39,7 +39,7 @@ alwaysApply: false
 - Добавлять тесты для критичных веток логики и edge‑кейсов.
  - При работе с данными:
    - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types/**`, не дублировать интерфейсы в тестах;
-   - по возможности опираться на данные и хендлеры мок‑сервера **MSW** из `app/src/mocks/**`, а не плодить случайные тестовые данные "с нуля".
+   - по возможности опираться на данные и обработчики из `src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
  - При написании unit‑тестов рядом с компонентом или модулем:
    - **не создавать** поддиректорию `__tests__` внутри папки компонента;
    - именовать файлы тестов с суффиксом `*.spec.ts` / `*.spec.tsx`, а не `*.test.ts` / `*.test.tsx`.