@bonesofspring/ai-rules 0.1.0 → 0.1.1

package/bin/cli.js

@@ -17,6 +17,10 @@ const PRESETS = {
     rulesDir: '.claude/rules',
     commandsDir: '.claude/commands',
     relBase: ['presets', 'claude'],
+    /** Optional dirs under preset root → under `.claude/` (recursive copy). */
+    optionalClaudeDirs: ['skills', 'agents', 'hooks'],
+    /** Copied from preset root to `.claude/CLAUDE.md` when present. */
+    claudeMdSrc: 'CLAUDE.md',
   },
 };
 
@@ -73,6 +77,31 @@ function removeDirIfExists(dir) {
   }
 }
 
+function removeFileIfExists(filePath) {
+  if (fs.existsSync(filePath)) {
+    fs.unlinkSync(filePath);
+  }
+}
+
+function presetHasAnySource(base, cfg) {
+  const rulesSrc = path.join(base, 'rules');
+  const commandsSrc = path.join(base, 'commands');
+  if (fs.existsSync(rulesSrc) || fs.existsSync(commandsSrc)) {
+    return true;
+  }
+  if (cfg.optionalClaudeDirs) {
+    for (const name of cfg.optionalClaudeDirs) {
+      if (fs.existsSync(path.join(base, name))) {
+        return true;
+      }
+    }
+  }
+  if (cfg.claudeMdSrc && fs.existsSync(path.join(base, cfg.claudeMdSrc))) {
+    return true;
+  }
+  return false;
+}
+
 function cmdInit(tool, preset) {
   const cfg = PRESETS[tool];
   if (!cfg) {
@@ -88,11 +117,21 @@ function cmdInit(tool, preset) {
   const commandsSrc = path.join(base, 'commands');
   const cwd = process.cwd();
 
-  if (!fs.existsSync(rulesSrc) && !fs.existsSync(commandsSrc)) {
+  if (!presetHasAnySource(base, cfg)) {
     console.error(`Preset "${preset}" for ${tool} not found under ${base}`);
     process.exit(1);
   }
 
+  if (tool === 'claude' && cfg.claudeMdSrc) {
+    const mdFrom = path.join(base, cfg.claudeMdSrc);
+    if (fs.existsSync(mdFrom)) {
+      const claudeRoot = path.join(cwd, '.claude');
+      fs.mkdirSync(claudeRoot, { recursive: true });
+      fs.copyFileSync(mdFrom, path.join(claudeRoot, 'CLAUDE.md'));
+      console.log('Copied CLAUDE.md → .claude/CLAUDE.md');
+    }
+  }
+
   if (fs.existsSync(rulesSrc)) {
     copyDir(rulesSrc, path.join(cwd, cfg.rulesDir));
     console.log(`Copied rules → ${cfg.rulesDir}`);
@@ -101,6 +140,16 @@ function cmdInit(tool, preset) {
     copyDir(commandsSrc, path.join(cwd, cfg.commandsDir));
     console.log(`Copied commands → ${cfg.commandsDir}`);
   }
+
+  if (tool === 'claude' && cfg.optionalClaudeDirs) {
+    for (const name of cfg.optionalClaudeDirs) {
+      const src = path.join(base, name);
+      if (fs.existsSync(src)) {
+        copyDir(src, path.join(cwd, '.claude', name));
+        console.log(`Copied ${name}/ → .claude/${name}/`);
+      }
+    }
+  }
 }
 
 function cmdClean(tool) {
@@ -112,7 +161,19 @@ function cmdClean(tool) {
   const cwd = process.cwd();
   removeDirIfExists(path.join(cwd, cfg.rulesDir));
   removeDirIfExists(path.join(cwd, cfg.commandsDir));
-  console.log(`Removed ${cfg.rulesDir} and ${cfg.commandsDir} (if present)`);
+  if (tool === 'claude' && cfg.optionalClaudeDirs) {
+    for (const name of cfg.optionalClaudeDirs) {
+      removeDirIfExists(path.join(cwd, '.claude', name));
+    }
+    removeFileIfExists(path.join(cwd, '.claude', 'CLAUDE.md'));
+  }
+  console.log(
+    `Removed ${cfg.rulesDir} and ${cfg.commandsDir}` +
+      (tool === 'claude' && cfg.optionalClaudeDirs
+        ? `, optional .claude/{${cfg.optionalClaudeDirs.join(',')}}, and .claude/CLAUDE.md`
+        : '') +
+      ' (if present)',
+  );
 }
 
 function main() {

package/package.json

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

package/presets/claude/next/CLAUDE.md

@@ -0,0 +1,11 @@
+# Next.js stack — project instructions
+
+Краткая точка входа для Claude Code. Подробные правила лежат в модульных файлах под `rules/` (подпапки по темам).
+
+See @rules/README.md for how this preset splits instructions.
+
+## Conventions
+
+- Держите **одну тему на файл**; для больших областей — подпапки в `rules/<topic>/`.
+- Скоуп по путям проекта — через frontmatter `paths:` в отдельных `.md` (см. официальные docs по path-specific rules).
+- Slash-команды — в `commands/`; переиспользуемые сценарии — в `skills/`.

package/presets/claude/next/README.md

@@ -0,0 +1,14 @@
+# Preset `next` (Claude Code)
+
+Структура отличается от пресета Cursor: здесь повторяется типичный **layout проекта Claude Code** под `.claude/`, а не плоский список `.mdc` в `rules/`.
+
+| В пресете | Куда копирует `ai-rules init claude --preset next` |
+|-----------|-----------------------------------------------------|
+| `CLAUDE.md` | `.claude/CLAUDE.md` (точка входа, грузится в начале сессии) |
+| `rules/**` | `.claude/rules/**` (рекурсивно: подпапки по темам, см. [документацию](https://code.claude.com/docs/en/memory#organize-rules-with-clauderules)) |
+| `commands/**` | `.claude/commands/**` |
+| `skills/**` | `.claude/skills/**` (если папка есть) |
+| `agents/**` | `.claude/agents/**` (если папка есть) |
+| `hooks/**` | `.claude/hooks/**` (если папка есть) |
+
+Файлы правил — обычный Markdown с опциональным YAML frontmatter (`paths:` для скоупа по путям), не формат `.mdc` Cursor.

package/presets/claude/next/agents/README.md

@@ -0,0 +1,5 @@
+# `.claude/agents` (preset next)
+
+Специализированные подагенты (personas) — по [документации Claude Code](https://code.claude.com/docs), если используете их в проекте.
+
+Папка копируется в `.claude/agents/` при `ai-rules init claude --preset next`, если существует.

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

@@ -0,0 +1,75 @@
+---
+name: playwright-test-generator
+description: 'Use this agent when you need to create automated browser tests using Playwright Examples: <example>Context: User wants to generate a test for the test plan item. <test-suite><!-- Verbatim name of the test spec group w/o ordinal like "Multiplication tests" --></test-suite> <test-name><!-- Name of the test case without the ordinal like "should add two numbers" --></test-name> <test-file><!-- Name of the file to save the test into, like tests/multiplication/should-add-two-numbers.spec.ts --></test-file> <seed-file><!-- Seed file path from test plan --></seed-file> <body><!-- Test case content including steps and expectations --></body></example>'
+tools: Glob, Grep, Read, LS, mcp__playwright-test__browser_click, mcp__playwright-test__browser_drag, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_file_upload, mcp__playwright-test__browser_handle_dialog, mcp__playwright-test__browser_hover, mcp__playwright-test__browser_navigate, mcp__playwright-test__browser_press_key, mcp__playwright-test__browser_select_option, mcp__playwright-test__browser_snapshot, mcp__playwright-test__browser_type, mcp__playwright-test__browser_verify_element_visible, mcp__playwright-test__browser_verify_list_visible, mcp__playwright-test__browser_verify_text_visible, mcp__playwright-test__browser_verify_value, mcp__playwright-test__browser_wait_for, mcp__playwright-test__generator_read_log, mcp__playwright-test__generator_setup_page, mcp__playwright-test__generator_write_test
+model: sonnet
+color: blue
+---
+
+You are a Playwright Test Generator, an expert in browser automation and end-to-end testing.
+Your specialty is creating robust, reliable Playwright tests that accurately simulate user interactions and validate
+application behavior.
+
+## Project-specific test structure (emedcard-web)
+
+In this project you MUST respect the existing e2e layout:
+
+- Test root: `app/__tests__/e2e`
+- Test plans/specs: `*.cases.md` files under `app/__tests__/e2e/**`
+- Executable tests: `*.spec.ts` files under `app/__tests__/e2e/**`
+- Seed test: `app/__tests__/e2e/seed.spec.ts`
+
+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`).
+- 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.
+
+# For each test you generate
+- Obtain the test plan with all the steps and verification specification
+- Run the `generator_setup_page` tool to set up page for the scenario
+- For each step and verification in the scenario, do the following:
+  - Use Playwright tool to manually execute it in real-time.
+  - Use the step description as the intent for each Playwright tool call.
+- Retrieve generator log via `generator_read_log`
+- Immediately after reading the test log, invoke `generator_write_test` with the generated source code
+  - File should contain single test
+  - File name must be fs-friendly scenario name
+  - Test must be placed in a describe matching the top-level test plan item
+  - Test title must match the scenario name
+  - Includes a comment with the step text before each step execution. Do not duplicate comments if step requires
+    multiple actions.
+  - Always use best practices from the log when generating tests.
+
+   <example-generation>
+   For following plan:
+
+   ```markdown file=specs/plan.md
+   ### 1. Adding New Todos
+   **Seed:** `tests/seed.spec.ts`
+
+   #### 1.1 Add Valid Todo
+   **Steps:**
+   1. Click in the "What needs to be done?" input field
+
+   #### 1.2 Add Multiple Todos
+   ...
+   ```
+
+   Following file is generated:
+
+   ```ts file=add-valid-todo.spec.ts
+   // spec: specs/plan.md
+   // seed: tests/seed.spec.ts
+
+   test.describe('Adding New Todos', () => {
+     test('Add Valid Todo', async { page } => {
+       // 1. Click in the "What needs to be done?" input field
+       await page.click(...);
+
+       ...
+     });
+   });
+   ```
+   </example-generation>

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

@@ -0,0 +1,61 @@
+---
+name: playwright-test-healer
+description: Use this agent when you need to debug and fix failing Playwright tests
+tools: Glob, Grep, Read, LS, Edit, MultiEdit, Write, mcp__playwright-test__browser_console_messages, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_generate_locator, mcp__playwright-test__browser_network_requests, mcp__playwright-test__browser_snapshot, mcp__playwright-test__test_debug, mcp__playwright-test__test_list, mcp__playwright-test__test_run
+model: sonnet
+color: red
+---
+
+You are the Playwright Test Healer, an expert test automation engineer specializing in debugging and
+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)
+
+In this project you MUST respect the existing e2e layout:
+
+- Test root: `app/__tests__/e2e`
+- Test plans/specs: `*.cases.md` files under `app/__tests__/e2e/**`
+- Executable tests: `*.spec.ts` files under `app/__tests__/e2e/**`
+- Seed test: `app/__tests__/e2e/seed.spec.ts`
+
+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`).
+
+Your workflow:
+1. **Initial Execution**: Run all tests using `test_run` tool to identify failing tests
+2. **Debug failed tests**: For each failing test run `test_debug`.
+3. **Error Investigation**: When the test pauses on errors, use available Playwright MCP tools to:
+   - Examine the error details
+   - Capture page snapshot to understand the context
+   - Analyze selectors, timing issues, or assertion failures
+4. **Root Cause Analysis**: Determine the underlying cause of the failure by examining:
+   - Element selectors that may have changed
+   - Timing and synchronization issues
+   - Data dependencies or test environment problems
+   - Application changes that broke test assumptions
+5. **Code Remediation**: Edit the test code to address identified issues, focusing on:
+   - Updating selectors to match current application state
+   - Fixing assertions and expected values
+   - Improving test reliability and maintainability
+   - For inherently dynamic data, utilize regular expressions to produce resilient locators
+6. **Verification**: Restart the test after each fix to validate the changes
+7. **Iteration**: Repeat the investigation and fixing process until the test passes cleanly
+
+Key principles:
+- Be systematic and thorough in your debugging approach
+- Document your findings and reasoning for each fix
+- Prefer robust, maintainable solutions over quick hacks
+- Use Playwright best practices for reliable test automation
+- If multiple errors exist, fix them one at a time and retest
+- Provide clear explanations of what was broken and how you fixed it
+- You will continue this process until the test runs successfully without any failures or errors.
+- If the error persists and you have high level of confidence that the test is correct, mark this test as test.fixme()
+  so that it is skipped during the execution. Add a comment before the failing step explaining what is happening instead
+  of the expected behavior.
+- Do not ask user questions, you are not interactive tool, do the most reasonable thing possible to pass the test.
+- Never wait for networkidle or use other discouraged or deprecated apis

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

@@ -0,0 +1,67 @@
+---
+name: playwright-test-planner
+description: Use this agent when you need to create comprehensive test plan for a web application or website
+tools: Glob, Grep, Read, LS, mcp__playwright-test__browser_click, mcp__playwright-test__browser_close, mcp__playwright-test__browser_console_messages, mcp__playwright-test__browser_drag, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_file_upload, mcp__playwright-test__browser_handle_dialog, mcp__playwright-test__browser_hover, mcp__playwright-test__browser_navigate, mcp__playwright-test__browser_navigate_back, mcp__playwright-test__browser_network_requests, mcp__playwright-test__browser_press_key, mcp__playwright-test__browser_run_code, mcp__playwright-test__browser_select_option, mcp__playwright-test__browser_snapshot, mcp__playwright-test__browser_take_screenshot, mcp__playwright-test__browser_type, mcp__playwright-test__browser_wait_for, mcp__playwright-test__planner_setup_page, mcp__playwright-test__planner_save_plan
+model: sonnet
+color: green
+---
+
+You are an expert web test planner with extensive experience in quality assurance, user experience testing, and test
+scenario design. Your expertise includes functional testing, edge case identification, and comprehensive test coverage
+planning.
+
+## Project-specific test structure (emedcard-web)
+
+In this project you MUST respect the existing e2e layout:
+
+- Test root: `app/__tests__/e2e`
+- Test plans/specs: `*.cases.md` files under `app/__tests__/e2e/**`
+- Executable tests: `*.spec.ts` files under `app/__tests__/e2e/**`
+- Seed test: `app/__tests__/e2e/seed.spec.ts`
+
+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.
+- Treat these `*.cases.md` files as the canonical, human-readable test plans for the Generator and Healer agents.
+
+You will:
+
+1. **Navigate and Explore**
+   - Invoke the `planner_setup_page` tool once to set up page before using any other tools
+   - Explore the browser snapshot
+   - Do not take screenshots unless absolutely necessary
+   - Use `browser_*` tools to navigate and discover interface
+   - Thoroughly explore the interface, identifying all interactive elements, forms, navigation paths, and functionality
+
+2. **Analyze User Flows**
+   - Map out the primary user journeys and identify critical paths through the application
+   - Consider different user types and their typical behaviors
+
+3. **Design Comprehensive Scenarios**
+
+   Create detailed test scenarios that cover:
+   - Happy path scenarios (normal user behavior)
+   - Edge cases and boundary conditions
+   - Error handling and validation
+
+4. **Structure Test Plans**
+
+   Each scenario must include:
+   - Clear, descriptive title
+   - Detailed step-by-step instructions
+   - Expected outcomes where appropriate
+   - Assumptions about starting state (always assume blank/fresh state)
+   - Success criteria and failure conditions
+
+5. **Create Documentation**
+
+   Submit your test plan using `planner_save_plan` tool.
+
+**Quality Standards**:
+- Write steps that are specific enough for any tester to follow
+- Include negative testing scenarios
+- Ensure scenarios are independent and can be run in any order
+
+**Output Format**: Always save the complete test plan as a markdown file with clear headings, numbered steps, and
+professional formatting suitable for sharing with development and QA teams.

package/presets/claude/next/commands/README.md

@@ -1,3 +1,5 @@
-# Claude commands (next preset)
+# `.claude/commands` (preset next)
 
-Add slash command definitions for this preset. They are copied to `.claude/commands` when you run `ai-rules init claude --preset next`.
+Определения slash-команд для проекта. Копируются в `.claude/commands/` при `ai-rules init claude --preset next`.
+
+См. также корневой `README.md` пресета — у Claude Code помимо `rules/` и `commands/` часто используются `skills/`, `agents/`, `hooks/`.

package/presets/claude/next/hooks/README.md

@@ -0,0 +1,5 @@
+# `.claude/hooks` (preset next)
+
+Событийные хуки автоматизации Claude Code — по документации продукта, если включены в репозитории.
+
+Папка копируется в `.claude/hooks/` при `ai-rules init claude --preset next`, если существует.

package/presets/claude/next/rules/README.md

@@ -1,3 +1,16 @@
-# Claude rules (next preset)
+# `.claude/rules` (preset next)
 
-Add markdown instruction files for this preset. They are copied to `.claude/rules` when you run `ai-rules init claude --preset next`.
+В Claude Code все `.md` под `rules/` **обнаруживаются рекурсивно** — подпапки по темам уместнее, чем один длинный файл.
+
+Соответствие темам из пресета Cursor (для переноса смысла из `.mdc`):
+
+| Папка | О чём |
+|-------|--------|
+| `stack/` | Next.js, React, TypeScript |
+| `architecture/` | границы слоёв, модули |
+| `api-and-data/` | сервисы, API, данные |
+| `testing/` | unit, e2e, Playwright |
+| `ui-and-accessibility/` | UI, a11y, без spread props там, где это правило команды |
+| `tooling-and-review/` | качество кода, ревью MR |
+
+Добавляйте сюда `.md` файлы с осмысленными именами (`testing.md`, `api-design.md`, …).

package/presets/claude/next/rules/api-and-data/README.md

@@ -0,0 +1,3 @@
+# API and data
+
+Конвенции сервисов, API-слоя и работы с данными.

package/presets/claude/next/rules/architecture/README.md

@@ -0,0 +1,3 @@
+# Architecture
+
+Границы модулей, слоёв и зависимостей (аналог темы architecture / boundaries в Cursor-пресете).

package/presets/claude/next/rules/stack/README.md

@@ -0,0 +1,3 @@
+# Stack (Next.js, React, TypeScript)
+
+Правила уровня фреймворка и языка для пресета `next`.

package/presets/claude/next/rules/testing/README.md

@@ -0,0 +1,3 @@
+# Testing
+
+Unit-тесты, e2e, структура Playwright-агентов — по отдельным `.md` при необходимости.

package/presets/claude/next/rules/tooling-and-review/README.md

@@ -0,0 +1,3 @@
+# Tooling and review
+
+Рефакторинг, качество кода, процесс ревью MR.

package/presets/claude/next/rules/ui-and-accessibility/README.md

@@ -0,0 +1,3 @@
+# UI and accessibility
+
+Компоненты, стили, доступность, паттерны React UI.

package/presets/claude/next/skills/README.md

@@ -0,0 +1,5 @@
+# `.claude/skills` (preset next)
+
+[Skills](https://code.claude.com/docs/en/skills) в Claude Code — сценарии, которые подгружаются по необходимости, а не в каждой сессии целиком. Добавьте сюда `SKILL.md` или структуру skills по документации инструмента.
+
+Папка копируется в `.claude/skills/` при `ai-rules init claude --preset next`, если существует.

package/presets/cursor/next/rules/README.md

@@ -0,0 +1,12 @@
+### Разница .mdc и .md в .cursor/rules
+
+#### .md
+Обычный markdown‑файл. Cursor видит его как документацию/контент, но не как правило, которое нужно автоматически применять.
+
+#### .mdc
+Специальный формат Cursor Rule:
+- сверху обязателен YAML‑frontmatter с полями вроде description, globs, alwaysApply;
+- файл лежит в .cursor/rules/;
+- Cursor интерпретирует его как конфигурацию поведения ассистента для этого репо (автоматически подмешивает содержимое в контекст, когда правило подходит).
+
+- То есть .mdc = “markdown + config для Cursor”, .md = просто текст без управляющего смысла для ассистента.

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

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

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

@@ -0,0 +1,47 @@
+---
+description: Архитектурные границы и правила импортов
+alwaysApply: true
+---
+
+# Границы между слоями
+
+- **UI (src/ui/**)**:
+  - Может импортировать: `@/ui/**`, `@/store/**`, `@/types/**`, `@/api/services/**` (через публичные интерфейсы).
+  - Не должен:
+    - обращаться к HTTP/axios напрямую;
+    - знать детали DTO backend — только доменные типы.
+- **Store (src/store/**)**:
+  - Может импортировать: `@/store/**`, `@/api/services/**`, `@/types/**`.
+  - Не должен:
+    - зависеть от конкретных UI‑компонентов;
+    - напрямую работать с global/window API.
+- **API (src/api/services/**)**:
+  - Может импортировать: `@/types/**`, общие утилиты.
+  - Не должен:
+    - тянуть в себя UI или store;
+    - смешивать HTTP‑слой и доменный слой — использовать мапперы.
+
+# Правила импортов
+
+- Всегда использовать алиас `@/...` для импортов между слоями.
+- Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
+- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич.
+- При добавлении нового кода проверять:
+  - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
+
+# Организация фич
+
+- Для сложных фич (например, OfflineConsultation):
+  - Страница: `src/ui/pages/OfflineConsultationPage/**`.
+  - Локальные компоненты: поддиректории `components/**` внутри страницы.
+  - Связанный store: `src/store/slices/OfflineConsultation/**`.
+  - API: `src/api/services/MedcardApiService/OfflineConsultation/**`.
+  - Типы: `src/types/OfflineConsultation.types.ts` или аналогичный файл.
+
+# Требование к агенту
+
+При добавлении новой функциональности:
+- Разместить файлы в **соответствующих слоях**.
+- Проверить существующие фичи с аналогичной структурой и **повторить их организацию**.
+- Не "коротить" слои (например, не вызывать API прямо из компонента только ради упрощения).
+

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

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

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

@@ -0,0 +1,47 @@
+---
+description: Требования к code review агентами Cursor для GitLab merge requests в emedcard-web
+alwaysApply: true
+---
+
+# Code review merge requests
+
+- **Когда применять**
+  - Если пользователь просит: "проведи ревью", "оценить MR/ветку/дифф", "посмотри изменения".
+  - Опираться на локальный репозиторий: текущую ветку, `git diff` и открытые файлы, а не на данные GitLab API.
+
+- **Что обязан проверить агент**
+  - **Архитектура и слои**:
+    - Соблюдение правил из `architecture-boundaries.mdc` и `emedcard-core.mdc`:
+      - UI (`src/ui/**`) не ходит напрямую в HTTP/axios и не знает DTO.
+      - Store (`src/store/**`) не зависит от UI и не работает с "сырыми" HTTP.
+      - API (`src/api/services/**`) не тянет UI/store, использует мапперы.
+  - **Импорты и организация кода**:
+    - Использование алиаса `@/...` вместо относительных импортов выше по дереву.
+    - Отсутствие deep‑импортов во внешние фичи; использование только public API.
+    - Размещение новых файлов в корректных слоях и директориях фич.
+  - **Типы и TS‑строгость**:
+    - Не допускать новых `any`; предпочитать доменные типы из `src/types/**`.
+    - Проверять корректность пропсов/возвращаемых типов, особенно в UI и API‑слое.
+  - **UI, стили и SDS**:
+    - Для компонентов и стилей сверяться с `react-ui.mdc` и `emedcard-core.mdc`:
+      - Использовать Linaria и компоненты/токены `@sds/*`, а не "магические" значения.
+      - Сохранять консистентность с существующими компонентами и паттернами.
+  - **Тесты**:
+    - Проверять, что для нетривиальных изменений:
+      - либо обновлены/добавлены unit‑тесты (`tests-unit.mdc`),
+      - либо e2e‑сценарии/спеки отражают новую логику (`playwright-agents.mdc`, `tests-e2e-structure.mdc`).
+    - Указывать, какие именно тесты стоит добавить или поправить.
+
+- **Глубина и формат ревью**
+  - Фокус на **изменениях MR** (дифф относительно целевой ветки), а не на всём проекте.
+  - Сначала дать **высокоуровневый обзор** (что делает MR, риски, архитектурные замечания), затем список конкретных комментариев.
+  - Каждый комментарий делать:
+    - **конкретным** (указать файл/участок и проблему),
+    - **практичным** (предложить вариант исправления, опираясь на существующие паттерны),
+    - без "больших рефакторингов" в духе `code-quality-and-refactoring.mdc`, если задача локальная.
+
+- **Ограничения для агента**
+  - Не придумывать несуществующие GitLab сущности (лейблы, авторов, статусы пайплайнов).
+  - Не менять общую архитектуру фичи без прямого запроса пользователя.
+  - Следовать принципу "boy scout rule": предлагать улучшения, которые реально можно внести в рамках MR.
+

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

@@ -0,0 +1,77 @@
+---
+description: Базовые принципы, стек и архитектура emedcard-web
+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.
+
+# Структура проекта (верхний уровень)
+
+- `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/**` — Redux Toolkit слайсы.
+  - `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.
+- **Никаких "проникновений" слоёв**:
+  - UI не обращается к API напрямую — только через store или абстракции сервисов.
+  - Store не работает напрямую с "сырыми" HTTP‑ответами — только через мапперы.
+- **Типы — источник правды**:
+  - Новые сущности описывать в `src/types/**`, переиспользовать, а не дублировать типы по слоям.
+  - Не использовать `any`; при необходимости — `unknown` + безопасное сужение типа.
+
+# Кодстайл и качества кода
+
+- Следовать конфигам `eslint.config.mjs`, `.prettierrc`, `.stylelintrc`.
+- Поддерживать:
+  - KISS, DRY, SOLID (в разумных пределах для фронта).
+  - Модульность и переиспользование через компоненты, хуки, слайсы, сервисы.
+  - Консистентный визуальный стиль за счёт использования готовых компонентов `@sds/*` и дизайн‑токенов @sds вместо локальных "магических" значений.
+- При добавлении нового кода **искать и копировать существующие паттерны**:
+  - Для страниц — аналогичные файлы в `src/ui/pages/**`.
+  - Для блоков — компоненты в `src/ui/components/**`.
+  - Для API — сервисы в `src/api/services/**`.
+  - Для состояния — слайсы в `src/store/slices/**`.
+
+# Работа агента
+
+При генерации кода:
+- Определить целевой слой (UI/store/API/типизация/тесты).
+- Найти в соответствующей директории похожие примеры и **копировать архитектурный паттерн** (структура файлов, типы, именование).
+- Не упрощать архитектуру в ущерб существующим слоям (не тянуть API в UI, не описывать "DTO" прямо в компонентах).
+ - Избегать использования `any` при типизации кода; при необходимости использовать `unknown` с последующим безопасным сужением типов.
+ - После создания или редактирования любых файлов **обязательно проверять проект на ошибки TypeScript и ESLint** (либо точечно по изменённым файлам, либо по всему проекту) и устранять найденные проблемы, если это возможно без изменения бизнес‑логики.
+

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

@@ -0,0 +1,39 @@
+---
+description: Избегать спред-а пропов при передаче в компоненты
+alwaysApply: true
+---
+
+# Не использовать спред пропов при передаче в компоненты
+
+При вызове React-компонентов **передавать пропы явно**, а не через spread (`{...props}`).
+
+## Почему
+
+- Явная передача делает зависимости компонента очевидными при чтении кода.
+- Упрощает рефакторинг и поиск использований.
+- Снижает риск случайно пробросить лишние или устаревшие пропы.
+
+## Примеры
+
+```tsx
+// ❌ Плохо
+const commonProps = { a, b, c }
+return <Child {...commonProps} />
+
+// ❌ Плохо
+return <Child {...props} />
+
+// ✅ Хорошо
+return (
+  <Child
+    a={a}
+    b={b}
+    c={c}
+  />
+)
+```
+
+## Исключения
+
+- Передача всех пропов в нативный DOM-элемент (`<div {...rest} />`) допустима, если `rest` содержит только валидные HTML-атрибуты.
+- Делегирование пропов в обёртку (wrapper) допустимо, если это явно документировано и обосновано.

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

@@ -0,0 +1,72 @@
+---
+description: Playwright Agents (planner/generator/healer) configuration for e2e structure in app/__tests__/e2e
+alwaysApply: true
+---
+
+# Playwright Agents in this project
+
+In this repository, Playwright Agents (planner, generator, healer) **must follow the existing e2e structure**:
+
+- **Test directory**: `app/__tests__/e2e`
+- **Test plans (specs)**: `*.cases.md` files under `app/__tests__/e2e/**`
+- **Executable tests**: `*.spec.ts` files under `app/__tests__/e2e/**`
+- **Seed test**: `app/__tests__/e2e/seed.spec.ts`
+
+Do **not** introduce separate top-level `specs/` and `tests/` folders for real test coverage. Those may be used only as temporary sandboxes if explicitly requested.
+
+## Planner (test plans)
+
+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`
+- **Content requirements**:
+  - Group scenarios by feature and subfeature using headings.
+  - For each scenario include:
+    - clear title,
+    - preconditions,
+    - ordered steps,
+    - expected results.
+  - Write in concise business language, but precise enough for automatic test generation.
+- **Seed**:
+  - Assume environment is prepared by `app/__tests__/e2e/seed.spec.ts` (login, baseURL, mocks, etc.).
+
+When asked to "generate a test plan" for a feature, **create or update the appropriate `*.cases.md` file in `app/__tests__/e2e/**`**, not in a separate `specs/` folder.
+
+## Generator (tests from plans)
+
+When acting as a **Generator** (or working with the Playwright generator agent):
+
+- **Source of truth for scenarios**:
+  - 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).
+- **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`
+    - 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.
+
+Do **not** generate Playwright tests into a separate `tests/` folder by default. Keep all e2e tests under `app/__tests__/e2e/**` to respect project conventions.
+
+## Healer (fixing tests)
+
+When acting as a **Healer** (or working with the Playwright healer agent):
+
+- Operate only on `*.spec.ts` files under `app/__tests__/e2e/**`.
+- Use `*.cases.md` in the same folder as **documentation of the intended behavior**:
+  - Do not weaken or change business assertions in tests in a way that conflicts with the corresponding `*.cases.md`.
+  - Prefer updating locators, waits, and flow details to match the UI while keeping the scenario semantics intact.
+- When multiple specs are involved, prioritize:
+  - the spec file in the same folder as the failing test,
+  - then shared utilities in `app/__tests__/e2e/_shared/`.
+
+Healer should keep tests aligned with the existing test plans (`*.cases.md`) and with the page objects and helpers already used in the project.

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

@@ -0,0 +1,67 @@
+---
+description: Паттерны React/Next UI и Linaria в emedcard-web
+globs: src/ui/**/*.tsx
+alwaysApply: false
+---
+
+# Общие правила компонентов
+
+- Использовать **функциональные компоненты** с хуками, без классов.
+- Компонент должен:
+  - быть максимально "тонким" по бизнес‑логике;
+  - делегировать состояние в store/хуки, если оно нужно в нескольких местах;
+  - использовать SDS‑компоненты как строительные блоки.
+- Перед созданием нового UI‑контрола агент должен явно рассмотреть существующие компоненты `@sds/*` и, если есть близкий по назначению, переиспользовать или расширить его вместо написания кастомного с нуля.
+- Для повторяемой логики создавать `useSomething`‑хуки рядом или в `src/ui/hooks/**`.
+ - При обращении к store, API, общим хелперам и утилитам компоненты и хуки должны использовать только их **public API** (например, `@/store`, `@/store/slices/Foo`, `@/lib/utils`), а не импортировать внутренние файлы реализации других модулей.
+
+# Структура файлов
+
+Для страницы/крупного блока:
+- `FeatureBlock.tsx` — JSX и композиция.
+- `styles.ts` — Linaria‑стили (`styled`, `css`).
+- `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 при первой возможности.
+
+# Пропсы и типизация
+
+- Описывать пропсы через `type Props = { ... }` или `interface Props { ... }`.
+- Не использовать `any`; при необходимости:
+  - обобщения (`<T>`), `unknown`, тип‑предикаты и user‑defined type guards.
+- Для доменных сущностей использовать типы из `@/types/**`, а не описывать их заново.
+
+# Логика и side effects
+
+- Side effects и асинхронщина:
+  - по возможности выносить в store (thunk‑и, middleware) или в отдельные хуки.
+- Компоненты не должны:
+  - напрямую знать детали API (URL, структура DTO);
+  - заниматься маппингом "сырых" DTO — только доменные типы;
+  - содержать нетривиальные вычисления и преобразования данных (булевы флаги, сложная склейка строк, агрегаты и т.п.). В большинстве случаев данные для отображения должны быть подготовлены на этапах маппинга/подготовки данных (API -> доменная модель -> store), а компоненты использовать уже готовые поля.
+
+# Тестирование UI
+
+- Для нетривиальных компонентов добавлять тесты:
+  - использовать `@testing-library/react` и `@testing-library/jest-dom`.
+  - проверять поведение и бизнес‑правила, а не конкретные CSS‑классы.
+- В тестах ориентироваться на текст, роли и aria‑атрибуты.
+

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

@@ -0,0 +1,59 @@
+---
+description: Redux Toolkit и состояние приложения
+globs: src/store/**/*.ts
+alwaysApply: false
+---
+
+# Общие принципы
+
+- Использовать **Redux Toolkit**:
+  - `createSlice`, `createAsyncThunk`, RTK Query (если используется).
+- Хранить в store **доменные модели**, не "сырые" DTO из API.
+- Все вычисления и преобразования данных (включая вычисляемые поля, булевые флаги, агрегаты, человеко‑читаемые строки и т.п.) должны выполняться **между ответом API и записью в store** — в мапперах или отдельном слое подготовки данных. Store хранит уже подготовленную доменную модель.
+- Разделять:
+  - "серверное" состояние (данные из API) и
+  - локальное UI‑состояние (выбор/фильтры/флаги).
+
+# Структура слайсов
+
+- Каждый доменный модуль — свой слайс в `src/store/slices/**`.
+- Слайс экспортирует:
+  - `reducer` по умолчанию;
+  - `actions` именованным экспортом;
+  - селекторы `selectSomething(state: RootState): Type`.
+- Состояние:
+  - явный тип для state;
+  - аккуратная инициализация initialState.
+
+# Асинхронность и сайд‑эффекты
+
+- Асинхронные запросы:
+  - через `createAsyncThunk` или RTK Query.
+  - внутри thunk:
+    - вызывать API через сервисы из `@/api/services/**`;
+    - не использовать `fetch`/`axios` напрямую.
+- Сайд‑эффекты (логирование, аналитика, работа с файлами):
+  - выносить в middleware (`src/store/middleware/**`) или специализированные слайсы.
+
+# Типизация
+
+- Использовать `RootState`, `AppDispatch` и типизированные хуки `useAppDispatch`, `useAppSelector` (если есть).
+- Для сущностей:
+  - доменные типы (включая вычисляемые поля) определять в `@/types/**` и импортировать в слайсы как **источник правды** для структуры данных;
+  - избегать дублирования описаний сущностей в нескольких местах.
+
+# Тестирование слайсов
+
+- Для важных слайсов:
+  - тестировать редюсеры (инициализация, основные переходы состояний).
+  - тестировать селекторы (включая edge cases).
+- Thunk‑и:
+  - по возможности покрывать тестами с моками API‑слоя.
+
+# Требование к агенту
+
+При изменении/создании слайса:
+- Не класть логику API внутрь редюсеров/компонентов.
+- Строго типизировать state и actions.
+- Использовать единый стиль именования actions и селекторов, как в существующих слайсах.
+

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

@@ -0,0 +1,51 @@
+---
+description: Структура e2e тестов и планов (Playwright)
+globs: app/__tests__/e2e/**/*
+alwaysApply: false
+---
+
+# Структура e2e в проекте
+
+- Папка e2e: `app/__tests__/e2e/**`.
+- Планы сценариев:
+  - `*.cases.md` файлы — **канонический источник сценариев**.
+- Тесты:
+  - `*.spec.ts` файлы — реализация сценариев на Playwright.
+- Общие утилиты и абстракции:
+  - `app/__tests__/e2e/_shared/**` — константы, fluent‑интерфейсы, хелперы.
+
+# Принципы
+
+- Каждый сценарий из `*.cases.md` должен иметь соответствующий тест (или набор тестов).
+- **Нельзя** ослаблять проверки в тестах, если это противоречит бизнес‑ожиданиям из планов.
+- Предпочтительно использовать:
+  - page‑objects (например, `MedcardRecordsPage.ts`);
+  - общие хелперы из `_shared`.
+
+# Именование e2e‑тестов
+
+- Язык:
+  - все названия `test` / `it`, `describe`‑блоков и шагов в `*.cases.md` должны быть сформулированы **на русском языке**, описывая поведение и ожидаемый результат.
+- Формат заголовков e2e‑тестов (`test(...)` / `it(...)`):
+  - перед текстовым описанием сценария указывается **префикс с номером** в формате: `ПРЕФИКС-XXX Описание сценария`.
+  - `ПРЕФИКС` — аббревиатура из **первых букв слов** тестируемой сущности, записанная **латиницей в верхнем регистре**.
+    - пример: `MedcardRecords` → `MR`, `RequestForAnalysis` → `RFA`.
+  - `XXX` — порядковый номер теста **с тремя разрядами и лидирующими нулями**: `001`, `002`, `010`, `123` и т.д.
+  - пример полного названия e2e‑теста:
+    - `test('MR-001 Отображается список записей медкарты', async ({ page }) => { ... })`
+  - внутри одной сущности (`ПРЕФИКС`) номера тестов должны образовывать **непротиворечивую последовательность**, без дубликатов номеров.
+
+# data-testid для e2e
+
+- **Приоритет селекторов:** `data-testid` для стабильных элементов; `getByRole` и `getByLabel` для форм и доступных элементов.
+- **Именование:** схема `{parent}__{element}` (например, `history-page__title`, `history-page__recognition-banner__attach-files-button`).
+- **Где добавлять:** на корневые контейнеры страниц и ключевые интерактивные элементы (кнопки, ссылки, поля), к которым обращаются page objects.
+- **При изменении UI:** обновлять data-testid в компонентах и соответствующие селекторы в page objects; сверять с `*.cases.md`.
+
+# Требование к агенту
+
+При добавлении/изменении e2e‑тестов:
+- Сначала смотреть соответствующий `*.cases.md` и синхронизировать названия сценариев.
+- Размещать спеки рядом с планами в той же директории.
+- Переиспользовать общие page‑objects и хелперы, а не копировать селекторы напрямую в каждый тест.
+

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

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

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

@@ -1,9 +0,0 @@
----
-description: Next.js stack conventions (placeholder — extend this preset)
-globs: **/*.{ts,tsx}
-alwaysApply: false
----
-
-# Next.js preset
-
-This file is a placeholder for the **next** Cursor preset. Replace with your project rules.