@bonesofspring/ai-rules 0.2.14 → 0.2.15

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

@@ -2,58 +2,58 @@
 paths: pages/**/*,layouts/**/*,middleware/**/*,nuxt.config.*
 ---
 
-# Навигация и роутинг: сначала стек проекта
+# Navigation and routing: project stack first
 
-**При любой задаче, связанной с навигацией, переходами между страницами, URL, редиректами, хлебными крошками, защищёнными маршрутами или программной сменой маршрута** — перед предложением кода или импортов **нельзя** опираться на «типичный Vue SPA» по умолчанию. Нужно **явно свериться со стеком целевого репозитория** и использовать **один** согласованный с проектом механизм.
+**For any task involving navigation, page transitions, URLs, redirects, breadcrumbs, protected routes, or programmatic route changes** — before proposing code or imports, **do not** default to a “typical Vue SPA”. You must **explicitly check the target repository stack** and use **one** mechanism consistent with the project.
 
-## Зависимости: что проверить в первую очередь
+## Dependencies: what to check first
 
-1. **`package.json`** в корне приложения (тот пакет, где `nuxt.config.*` / который собирается и деплоится). Смотреть **`dependencies`** и при необходимости **`peerDependencies`**:  
-   - **`nuxt`** — Nuxt 3 (file-based routing); версия важна для нюансов API (сверяться с документацией под эту major).  
-   - **`vue-router`** без Nuxt — отдельный SPA-роутинг; не подменять его API вызовами Nuxt (`navigateTo`, `<NuxtLink>`) без проверки.  
-   - **`nuxt`** и отдельный ручной `createRouter` одновременно — возможно легаси или гибрид; **не** выбирать API по умолчанию — смотреть раздел «Реализация в коде» ниже.
+1. **`package.json`** at the app root (the package with `nuxt.config.*` / the one that builds and deploys). Inspect **`dependencies`** and, if needed, **`peerDependencies`**:
+   - **`nuxt`** — Nuxt 3 (file-based routing); version matters for API nuances (check docs for that major).
+   - **`vue-router`** without Nuxt — separate SPA routing; do not replace its API with Nuxt calls (`navigateTo`, `<NuxtLink>`) without checking.
+   - **`nuxt`** and a separate manual `createRouter` at once — may be legacy or hybrid; **do not** pick an API by default — see “Routing implementation in the project” below.
 
-2. **Монорепо / workspaces** — роутинг может жить не в корневом `package.json`. Открыть **`package.json` того workspace**, где лежат `pages/` и `nuxt.config.*`.
+2. **Monorepo / workspaces** — routing may not live in the root `package.json`. Open **`package.json` of the workspace** that holds `pages/` and `nuxt.config.*`.
 
-3. **Факт установки** — при сомнениях смотреть lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) или `node_modules`: убедиться, что заявленный пакет реально установлен.
+3. **Installation fact** — when in doubt, check the lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) or `node_modules`: confirm the declared package is actually installed.
 
-## Реализация роутинга в проекте (код и структура)
+## Routing implementation in the project (code and structure)
 
-Перед предложением паттерна навигации **свериться с тем, как уже сделано в репозитории**:
+Before proposing a navigation pattern, **check how it is already done in the repository**:
 
-1. **Дерево маршрутов**  
-   - **Nuxt 3 file-based routing:** каталог **`pages/`** (`.vue`), layouts в **`layouts/`**, middleware в **`middleware/`**, `definePageMeta`.  
-   - **Nuxt 4 note:** возможен `app/` как `srcDir` — уточнить по `nuxt.config`; **не** путать с Next `app/` + `page.tsx`.  
-   - Чистый **Vue Router SPA:** конфиг маршрутов (`router/index.ts`, `createRouter`) без Nuxt file routing.
+1. **Route tree**
+   - **Nuxt 3 file-based routing:** **`pages/`** directory (`.vue`), layouts in **`layouts/`**, middleware in **`middleware/`**, `definePageMeta`.
+   - **Nuxt 4 note:** `app/` may be `srcDir` — confirm via `nuxt.config`; **do not** confuse with Next `app/` + `page.tsx`.
+   - Plain **Vue Router SPA:** route config (`router/index.ts`, `createRouter`) without Nuxt file routing.
 
-2. **Точки входа и обёртки**  
-   - Поиск по коду: **`navigateTo`**, **`<NuxtLink>`**, **`useRouter` / `useRoute`** (Nuxt auto-import), **`from 'vue-router'`**, **`createRouter`**, **`RouterLink`**.  
-   - Где объявлены маршруты (файловая структура Nuxt vs явный `routes` в SPA).
+2. **Entry points and wrappers**
+   - Search the code: **`navigateTo`**, **`<NuxtLink>`**, **`useRouter` / `useRoute`** (Nuxt auto-import), **`from 'vue-router'`**, **`createRouter`**, **`RouterLink`**.
+   - Where routes are declared (Nuxt file structure vs explicit `routes` in SPA).
 
-3. **Общие абстракции проекта**  
-   - Обёртки над ссылками (`~/components/...`, Link из дизайн-системы), хелперы путей, константы роутов — **использовать их**, а не дублировать сырой API.
+3. **Shared project abstractions**
+   - Link wrappers (`~/components/...`, design-system Link), path helpers, route constants — **use them**, do not duplicate raw API.
 
-4. **Соседние файлы фичи**  
-   - Новый код навигации — в том же стиле, что страницы/composables той же области (`navigateTo` / `<NuxtLink>` vs `vue-router` как в соседних импортах).
+4. **Neighboring feature files**
+   - New navigation code — same style as pages/composables in that area (`navigateTo` / `<NuxtLink>` vs `vue-router` as in neighboring imports).
 
-## Как определить, что использовать (сводка)
+## How to decide what to use (summary)
 
-1. **Зависимости** — см. раздел выше; по ним задаётся допустимый набор пакетов.  
-2. **Структура** — Nuxt `pages/` vs Vue Router SPA по каталогам и конфигу.  
-3. **Фактический код** — какие импорты и обёртки уже доминируют в приложении.
+1. **Dependencies** — see section above; they define the allowed package set.
+2. **Structure** — Nuxt `pages/` vs Vue Router SPA by directories and config.
+3. **Actual code** — which imports and wrappers already dominate in the app.
 
-## Что использовать (краткая матрица)
+## What to use (short matrix)
 
-| Стек | Программная навигация / чтение пути | Ссылки |
-|------|-------------------------------------|--------|
-| **Nuxt 3 file-based routing** | `navigateTo`, `useRouter`, `useRoute`, `useRouter().push` (по доке Nuxt для вашей версии) | `<NuxtLink>` |
-| **Vue Router SPA (без Nuxt)** | `vue-router` (`useRouter`, `useRoute`, `router.push`, …) | `<RouterLink>` / `<router-link>` |
+| Stack | Programmatic navigation / path read | Links |
+|-------|-------------------------------------|-------|
+| **Nuxt 3 file-based routing** | `navigateTo`, `useRouter`, `useRoute`, `useRouter().push` (per Nuxt docs for your version) | `<NuxtLink>` |
+| **Vue Router SPA (no Nuxt)** | `vue-router` (`useRouter`, `useRoute`, `router.push`, …) | `<RouterLink>` / `<router-link>` |
 
-**Не делать:** подключать `react-router-dom` или `next/navigation` / `next/link` в Nuxt-проект; импортировать Next-хуки (`usePathname`, `useSearchParams` из `next/navigation`); смешивать ручной `createRouter` и Nuxt file routing без явной причины в кодовой базе.
+**Do not:** add `react-router-dom` or `next/navigation` / `next/link` in a Nuxt project; import Next hooks (`usePathname`, `useSearchParams` from `next/navigation`); mix manual `createRouter` and Nuxt file routing without a clear reason in the codebase.
 
-## Требование к агенту
+## Agent requirement
 
-- Перед генерацией или ревью кода навигации **коротко зафиксировать вывод** (например: «зависимости: `nuxt`; в коде везде `<NuxtLink>` / `navigateTo` → используем то же») и следовать ему.  
-- **Обязательная проверка:** актуальные **`dependencies`** в `package.json` нужного workspace + **как в проекте уже реализованы** маршруты и импорты (поиск по репозиторию, соседние файлы). Не полагаться только на предположение по одному признаку (например, только на наличие папки `pages/`).  
-- Если стек неочевиден (гибрид) — **сверить lockfile / установленные пакеты** и **доминирующие импорты**, затем выбрать API.  
-- Для **этого** пресета базовый ориентир — **`stack/nuxt-app-core.md`** + **`stack/nuxt-pages-routing.md`**: Nuxt 3; предпочитать **`navigateTo`**, **`useRouter` / `useRoute`**, **`<NuxtLink>`**.
+- Before generating or reviewing navigation code, **briefly state the conclusion** (e.g. “dependencies: `nuxt`; code uses `<NuxtLink>` / `navigateTo` everywhere → use the same”) and follow it.
+- **Required check:** current **`dependencies`** in the relevant workspace `package.json` + **how routes and imports are already implemented** (repo search, neighboring files). Do not rely on a single signal alone (e.g. only the presence of a `pages/` folder).
+- If the stack is unclear (hybrid) — **check lockfile / installed packages** and **dominant imports**, then pick the API.
+- For **this** preset the baseline is **`nuxt-app-core.mdc`** + **`nuxt-pages-routing.mdc`**: Nuxt 3; prefer **`navigateTo`**, **`useRouter` / `useRoute`**, **`<NuxtLink>`**.

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

@@ -1,5 +1,5 @@
 ---
-description: Избегать приведения типов через as на границах модулей (импорт/экспорт)
+description: Avoid type assertions via as at module boundaries (import/export)
 paths:
   - pages/**/*
   - components/**/*
@@ -8,54 +8,55 @@ paths:
   - composables/**/*
   - types/**/*
 ---
-# Не использовать `as` для приведения типов при экспорте и импорте (кроме необходимых случаев)
 
-## О чём речь
+# Do not use `as` for type assertion on export and import (except necessary cases)
 
-Речь о **type assertion** в TypeScript: выражение вида `значение as Тип`.
+## What this is about
 
-**Не относится к правилу** (это не assertion, а синтаксис модулей):
+This is about TypeScript **type assertion**: expressions like `value as Type`.
 
-- переименование при экспорте: `export { foo as bar }`, `export { default as Baz } from '...'`;
-- переименование при импорте: `import { foo as bar } from '...'`;
-- `import type { Foo as Bar }` — алиас типа в импорте типов.
+**Not covered by this rule** (not assertion — module syntax):
 
-## Требование
+- rename on export: `export { foo as bar }`, `export { default as Baz } from '...'`;
+- rename on import: `import { foo as bar } from '...'`;
+- `import type { Foo as Bar }` — type alias in a type import.
 
-- На **публичной границе модуля** (то, что **экспортируется** из файла / barrel, и то, что сразу **присваивается импортированным символам** с принудительным приведением) **не использовать** `as Тип` для «подгонки» типов, если можно обойтись нормальной типизацией.
+## Requirement
 
-## Предпочитать вместо `as`
+- On the **public module boundary** (what is **exported** from a file / barrel, and what is immediately **assigned from imported symbols** with a forced cast) **do not use** `as Type` to “force-fit” types when normal typing would work.
 
-- явную аннотацию: `const x: T = ...` / `function f(): T`;
-- **дженерики** у функций и классов;
-- **`satisfies`** (когда нужно проверить совместимость без сужения до `any`);
-- сужение **`unknown`** после проверки (type guards, `zod` и т.п.);
-- правку **исходных типов/DTO/мапперов**, а не assertion на выходе.
+## Prefer instead of `as`
 
-## Когда `as` допустим
+- an explicit annotation: `const x: T = ...` / `function f(): T`;
+- **generics** on functions and classes;
+- **`satisfies`** (when you need to check compatibility without narrowing to `any`);
+- narrowing **`unknown`** after checks (type guards, `zod`, etc.);
+- fixing **source types/DTOs/mappers**, not an assertion on the way out.
 
-- взаимодействие с **не типизированными** или некорректно типизированными внешними модулями, где нет разумной альтернативы;
-- узкие места после **валидации** данных, если типовый гард всё ещё не выразить без шума (предпочтительно всё же guard/`satisfies`);
-- **`as const`** — когда нужны литеральные типы и широкий вывод ломает контракт (это отдельный механизм; применять по делу, не как замену типизации API).
-- блок **`catch (error)`** после вызова HTTP через общий клиент: по возможности сужать через **`instanceof`** на **класс ошибки транспорта** из `@/types` (какой именно — по существующей реализации) и работать с уже суженным типом; голый **`as` к тому же типу** — только если `instanceof` недоступен (иной источник выброса) и осознанно.
+## When `as` is allowed
 
-## Примеры
+- interaction with **untyped** or incorrectly typed external modules where there is no reasonable alternative;
+- narrow spots after **validation**, if a type guard still cannot be expressed without noise (prefer guard/`satisfies` anyway);
+- **`as const`** — when literal types are needed and wide inference breaks the contract (a separate mechanism; use on purpose, not as a substitute for API typing).
+- a **`catch (error)`** block after HTTP via the shared client: prefer narrowing with **`instanceof`** on the **transport error class** from `@/types` (which one — follow the existing implementation) and work with the narrowed type; bare **`as` to the same type** — only if `instanceof` is unavailable (different throw source) and deliberately.
+
+## Examples
 
 ```typescript
-// ❌ Плохо: assertion на экспортируемом API
+// ❌ Bad: assertion on exported API
 export const config = loadRaw() as AppConfig
 
-// ✅ Лучше: аннотация + проверка или маппер
+// ✅ Better: annotation + check or mapper
 export const config: AppConfig = mapToAppConfig(loadRaw())
 
-// ❌ Плохо: сразу после импорта «ломаем» тип
+// ❌ Bad: immediately after import we “break” the type
 import { getData } from './api'
 export const data = getData() as MyDto[]
 
-// ✅ Лучше: типизировать getData / обернуть типобезопасной функцией
+// ✅ Better: type getData / wrap with a type-safe function
 ```
 
-## Требование к агенту
+## Agent requirement
 
-При ревью и генерации кода **не добавлять** новые `as Тип` на экспортируемые сущности и на цепочку import → export без явной необходимости; по возможности исправлять контракт типов в источнике.
-- В слайсах и сервисах при обработке ошибок API сначала рассматривать **`instanceof`** на класс ошибки транспорта из `@/types` по образцу существующего кода (`http-client.mdc`, `store-pinia.mdc`).
+On review and code generation **do not add** new `as Type` on exported entities and on the import → export chain without clear need; when possible fix the type contract at the source.
+- In stores and services when handling API errors, first consider **`instanceof`** on the transport error class from `@/types` following existing code (`http-client.mdc`, `store-pinia.mdc`).

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

@@ -1,14 +1,15 @@
 ---
-description: Базовые принципы, стек и архитектура Nuxt 3 приложения (preset)
+description: Baseline principles, stack, and architecture for a Nuxt 3 application (preset)
 ---
-# Стек и окружение
 
-Конкретные версии — **из `package.json` и конфигов целевого репозитория**. Рамка preset: Nuxt 3, Vue 3, TypeScript; runner/e2e/mocks/UI/APM — как заведено в репо.
+# Stack and environment
 
-# Структура проекта
+Concrete versions — **from `package.json` and configs of the target repository**. Preset frame: Nuxt 3, Vue 3, TypeScript; runner/e2e/mocks/UI/APM — as established in the repo.
 
-| Путь | Назначение |
-|------|------------|
+# Project structure
+
+| Path | Purpose |
+|------|---------|
 | `pages/**` | File-based routes |
 | `components/**` | UI components (SFC) |
 | `composables/**` | Vue `use*` facades |
@@ -19,12 +20,12 @@ description: Базовые принципы, стек и архитектура
 | `types/**` | Domain types (barrel) |
 | `tests/e2e/**` | Playwright e2e |
 
-**Aliases:** prefer `~/`, accept `@/`, respect `#imports` (не изобретать auto-import символы). Scripts cwd — **корень репозитория** (где `nuxt.config.*`), не Next-обёртка `app/`.
+**Aliases:** prefer `~/`, accept `@/`, respect `#imports` (do not invent auto-import symbols). Scripts cwd — **repository root** (where `nuxt.config.*` lives), not a Next-style `app/` wrapper.
 
-# Архитектурные слои
+# Architectural layers
 
-| Слой | Каталог | Детали |
-|------|---------|--------|
+| Layer | Directory | Details |
+|-------|-----------|---------|
 | UI | `pages/**`, `components/**`, `layouts/**` | `vue-ui`, `architecture-boundaries-ui` |
 | Composables | `composables/**` | thin orchestration; no raw HTTP |
 | Store | `stores/**` | `store-pinia` — `defineStore` only |
@@ -33,11 +34,11 @@ description: Базовые принципы, стек и архитектура
 | Server | `server/api/**` | `security-nuxt`; not a substitute for `api/**` |
 | Types | `types/**` | `public-imports`, `types-jsdoc` |
 
-Границы — **`architecture-boundaries`**. Импорты `~/types` / `@/types`, `~/api` / `@/api` — **`public-imports`**. **Запрещено:** RTK / `store-rtk`, React/RSC defaults, пути `app/src/**` как канон.
+Boundaries — **`architecture-boundaries`**. Imports `~/types` / `@/types`, `~/api` / `@/api` — **`public-imports`**. **Forbidden:** RTK / `store-rtk`, React/RSC defaults, `app/src/**` paths as the canon.
 
-# Работа агента
+# Agent work
 
-- Архитектура и импорты: `architecture-boundaries`, `public-imports`
-- Фичи: `feature-delivery-workflow` + skill `feature-delivery`
-- После правок: **вызвать** `post-change-lint` (requestable); менеджер пакетов: `package-manager`
-- Копировать паттерны соседей; предпочитать `unknown` вместо `any`
+- Architecture and imports: `architecture-boundaries`, `public-imports`
+- Features: `feature-delivery-workflow` + skill `feature-delivery`
+- After edits: **invoke** `post-change-lint` (requestable); package manager: `package-manager`
+- Copy neighbor patterns; prefer `unknown` over `any`

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

@@ -1,40 +1,41 @@
 ---
-description: Стиль JSDoc для доменных и транспортных типов в types
+description: JSDoc style for domain and transport types under types
 paths: types/**/*.ts
 ---
-# Документация типов в `types`
 
-При добавлении или существенном изменении типов в этом слое **следовать уже принятому в репозитории стилю JSDoc** (см. примеры: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
+# Type documentation in `types`
 
-## Язык и форма
+When adding or substantially changing types in this layer **follow the JSDoc style already used in the repository** (see examples: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
 
-- Текст комментариев — **на русском**, кратко и по делу: что означает тип или поле в предметной области или в контракте с API.
-- **Не опираться** на теги в духе `@param`, `@returns`, `@see`, `@deprecated` для описания типов — в этом слое они **не используются**; достаточно обычного текста в `/** … */`.
+## Language and form
 
-## Экспортируемый `type` / `interface`
+- Comment text — **in Russian**, short and to the point: what the type or field means in the domain or API contract.
+- **Do not rely** on tags like `@param`, `@returns`, `@see`, `@deprecated` for type descriptions — they are **not used** in this layer; plain `/** … */` text is enough.
 
-- Сразу **перед объявлением** — блок `/** … */`.
-- Если нужно пояснить источник данных, ограничения или неочевидности — **второй абзац** в том же блоке (в JSDoc для абзаца — пустая строка между строками текста).
-- Для **вложенных** объектов в том же файле каждый такой тип документируется отдельным блоком над своим объявлением.
+## Exported `type` / `interface`
 
-## Поля
+- Immediately **before the declaration** — a `/** … */` block.
+- If you need to explain data source, constraints, or non-obvious bits — a **second paragraph** in the same block (blank line between paragraphs in JSDoc).
+- For **nested** objects in the same file, each such type gets its own block above its declaration.
 
-- У **каждого** публичного свойства — **однострочный** `/** … */` на строке непосредственно **над** полем.
-- Если поле **не приходит с бэкенда «как есть»**, а вычисляется или дополняется на фронте (маппер, селектор, UI) — начать описание с префикса **`[computed]`** (как в `TUserProfile`, типах плана лечения).
-- Для форматов данных указывать это **в тексте**: например дата `YYYY-MM-DD`, пример отображаемой строки в кавычках.
+## Fields
 
-## Классы и прочие объявления
+- Every **public** property — a **one-line** `/** … */` on the line immediately **above** the field.
+- If a field **does not come from the backend “as is”** but is computed or enriched on the frontend (mapper, selector, UI) — start the description with the **`[computed]`** prefix (as in `TUserProfile`, treatment-plan types).
+- For data formats, state that **in the text**: e.g. date `YYYY-MM-DD`, example display string in quotes.
 
-- Для **классов** (например ошибки транспорта) при изменении публичного API — краткий блок над классом и **комментарии к публичным полям** по тем же правилам, что у свойств интерфейса.
+## Classes and other declarations
+
+- For **classes** (e.g. transport errors), when changing the public API — a short block above the class and **comments on public fields** by the same rules as interface properties.
 
 ## `enum`
 
-- В `enums.ts` исторически часто **без JSDoc** на каждом члене; для новых enum допустимо короткое описание **над самим enum**, если назначение неочевидно из имени. Подписи для UI — как принято, через объекты `*Names` рядом с enum.
+- In `enums.ts` historically often **without JSDoc** on each member; for new enums a short description **above the enum itself** is OK if purpose is not obvious from the name. UI labels — as usual, via `*Names` objects next to the enum.
 
-## Практика для агента
+## Agent practice
 
-- Добавляя новый тип или поле, **не оставлять** новые публичные поля без пояснения, если смысл не равен имени на 100%.
-- Правя файл, где уже есть такие комментарии, **поддерживать тот же стиль**, а не смешивать с англоязычными или «теговыми» блоками.
-- Не раздувать комментарии: одна-две фразы на тип, одна строка на поле — норма; исключение — действительно сложная доменная оговорка.
+- When adding a new type or field, **do not leave** new public fields unexplained if the meaning is not 100% equal to the name.
+- When editing a file that already has such comments, **keep the same style**, do not mix with English or “tag-style” blocks.
+- Do not inflate comments: one–two phrases per type, one line per field — normal; exception — a truly complex domain caveat.
 
-См. также импорты и barrel: `public-imports.mdc`.
+See also imports and barrel: `public-imports.mdc`.

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

@@ -2,10 +2,10 @@
 
 Unit, e2e, Playwright agents.
 
-| Файл | Содержание | Загрузка |
-|------|------------|----------|
-| `playwright-agents.md` | Planner / generator / healer — структура e2e | session start |
-| `tests-unit.md` | Unit/integration, именование на русском | `paths: **/*.spec.*`, `*.test.*` |
+| File | Contents | Loading |
+|------|----------|---------|
+| `playwright-agents.md` | Planner / generator / healer — e2e structure | session start |
+| `tests-unit.md` | Unit/integration, Russian locale naming | `paths: **/*.spec.*`, `*.test.*` |
 | `tests-e2e-structure.md` | `*.cases.md`, page objects, data-testid | `paths: tests/e2e/**` |
 
-См. также `.claude/agents/playwright-test-*.md` после `ai-rules init`.
+See also `.claude/agents/playwright-test-*.md` after `ai-rules init`.

package/presets/claude/nuxt/rules/testing/tests-e2e-structure.md

@@ -1,49 +1,49 @@
 ---
-description: Структура e2e тестов и планов (Playwright)
+description: Structure of e2e tests and plans (Playwright)
 paths: tests/e2e/**/*
 ---
-# Структура e2e в проекте
-
-- Папка e2e: `tests/e2e/**`.
-- Планы сценариев:
-  - `*.cases.md` файлы — **канонический источник сценариев**.
-- Тесты:
-  - `*.spec.ts` файлы — реализация сценариев на Playwright.
-- Общие утилиты и абстракции:
-  - `tests/e2e/_shared/**` — константы, fluent‑интерфейсы, хелперы.
-
-# Принципы
-
-- Каждый сценарий из `*.cases.md` должен иметь соответствующий тест (или набор тестов).
-- **Нельзя** ослаблять проверки в тестах, если это противоречит бизнес‑ожиданиям из планов.
-- Предпочтительно использовать:
-  - page‑objects (например, `OrderHistoryPage.ts`);
-  - общие хелперы из `_shared`.
-
-# Именование e2e‑тестов
-
-- Язык:
-  - все названия `test` / `it`, `describe`‑блоков и шагов в `*.cases.md` должны быть сформулированы **на русском языке**, описывая поведение и ожидаемый результат.
-- Формат заголовков e2e‑тестов (`test(...)` / `it(...)`):
-  - перед текстовым описанием сценария указывается **префикс с номером** в формате: `ПРЕФИКС-XXX Описание сценария`.
-  - `ПРЕФИКС` — аббревиатура из **первых букв слов** тестируемой сущности, записанная **латиницей в верхнем регистре**.
-    - пример: `OrderHistory` → `OH`, `BillingReport` → `BR`.
-  - `XXX` — порядковый номер теста **с тремя разрядами и лидирующими нулями**: `001`, `002`, `010`, `123` и т.д.
-  - пример полного названия e2e‑теста:
-    - `test('OH-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 и хелперы, а не копировать селекторы напрямую в каждый тест.
 
+# E2E structure in the project
+
+- E2E folder: `tests/e2e/**`.
+- Scenario plans:
+  - `*.cases.md` files — **canonical source of scenarios**.
+- Tests:
+  - `*.spec.ts` files — Playwright scenario implementation.
+- Shared utilities and abstractions:
+  - `tests/e2e/_shared/**` — constants, fluent interfaces, helpers.
+
+# Principles
+
+- Every scenario from `*.cases.md` must have a matching test (or set of tests).
+- **Do not** weaken assertions in tests if that contradicts business expectations from the plans.
+- Prefer:
+  - page objects (e.g. `OrderHistoryPage.ts`);
+  - shared helpers from `_shared`.
+
+# E2E test naming
+
+- Language:
+  - all `test` / `it` names, `describe` blocks, and steps in `*.cases.md` must be formulated **in Russian**, describing behavior and the expected result. <!-- i18n-keep: E5 -->
+- E2E title format (`test(...)` / `it(...)`):
+  - before the scenario description, put a **numbered prefix** in the form: `PREFIX-XXX Scenario description`.
+  - `PREFIX` — abbreviation from the **first letters of the words** of the entity under test, written in **Latin uppercase**.
+    - example: `OrderHistory` → `OH`, `BillingReport` → `BR`.
+  - `XXX` — sequential test number **with three digits and leading zeros**: `001`, `002`, `010`, `123`, etc.
+  - full e2e title example:
+    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })` <!-- i18n-keep: E5 -->
+  - within one entity (`PREFIX`), test numbers must form a **consistent sequence** without duplicate numbers.
+
+# data-testid for e2e
+
+- **Selector priority:** `data-testid` for stable elements; `getByRole` and `getByLabel` for forms and accessible elements.
+- **Naming:** scheme `{parent}__{element}` (e.g. `history-page__title`, `history-page__recognition-banner__attach-files-button`).
+- **Where to add:** on page root containers and key interactive elements (buttons, links, fields) that page objects target.
+- **When UI changes:** update data-testid in components and matching selectors in page objects; align with `*.cases.md`.
+
+# Agent requirement
+
+When adding/changing e2e tests:
+- First look at the matching `*.cases.md` and sync scenario names.
+- Place specs next to plans in the same directory.
+- Reuse shared page objects and helpers; do not copy selectors into every test.

package/presets/claude/nuxt/rules/testing/tests-unit.md

@@ -1,75 +1,75 @@
 ---
-description: Unit и интеграционные тесты (Testing Library и runner проекта)
+description: Unit and integration tests (Testing Library and project runner)
 paths:
   - "**/*.spec.{ts,tsx}"
   - "**/*.test.{ts,tsx}"
 ---
-# Общие правила тестирования
-
-- **Имена файлов:** для **новых** тестов использовать суффикс **`*.spec.ts` / `*.spec.ts`**. Существующие **`*.test.ts` / `*.test.tsx`** не переименовывать без отдельной задачи (легаси).
-- **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@vue/test-utils**.
-- Основная цель тестов:
-  - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
-- **Именование unit‑тестов** (строки в `describe` / `it` / `test`):
-  - формулировки **только на русском языке** — понятные бизнес‑фразы (что проверяется и какой ожидается результат);
-  - **каждое предложение** в названии **начинается с заглавной буквы** (в том числе после `.`, `!`, `?` и при нескольких предложениях в одной строке); первая буква всей строки — тоже заглавная.
-  - **Проверка в CI:** ESLint (`jest/valid-title` в `eslint.config.mjs`) требует, чтобы строка начиналась с русской заглавной (А–Я, Ё), и запрещает пробел после точки, за которым сразу идёт строчная буква (типичный случай нарушения «с заглавной после точки»).
-
-```typescript
-// ✅ Хорошо
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-it('При ошибке сети показывается сообщение об ошибке', () => {})
-
-// ❌ Плохо (не с заглавной после точки; или не русский)
-it('Возвращает пустой список. пользователь не авторизован', () => {})
-it('Returns empty list when user is guest', () => {})
-```
 
-# Тесты компонентов
+# General testing rules
+
+- **File names:** for **new** tests use the **`*.spec.ts` / `*.spec.ts`** suffix. Do not rename existing **`*.test.ts` / `*.test.tsx`** without a separate task (legacy).
+- **Runner and matchers** — as in the project (often Jest or Vitest); for components — **@vue/test-utils**.
+- Primary goal of tests:
+  - verify **behavior and business rules**, not implementation or internal details.
+- **Unit test naming** (strings in `describe` / `it` / `test`):
+  - consumer apps **may use Russian locale** for titles — clear business phrases (what is checked and expected outcome);
+  - when ESLint enforces Russian (see below), each sentence in the title **must start with a capital letter** (including after `.`, `!`, `?` and with multiple sentences on one line); the first letter of the whole string is capitalized too.
+  - **CI check (when configured):** ESLint (`jest/valid-title` in `eslint.config.mjs`) may require titles to start with a Russian capital letter and forbid a space after `.` followed immediately by a lowercase letter (typical "capital after period" violation).
+
+Good (Russian locale in consumer app):
+
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 --> (Returns empty list. User is not authorized)
+- `it('При ошибке сети показывается сообщение об ошибке', () => {})` <!-- i18n-keep: E5 --> (On network error, an error message is shown)
+
+Bad (no capital after period; or wrong locale for configured ESLint):
 
-- Использовать `render` из `@vue/test-utils`.
-- Ассерты:
-  - матчеры DOM для Testing Library, как подключены в проекте (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
-- Взаимодействия:
-  - `userEvent` из `@testing-library/user-event`.
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+- `it('Returns empty list when user is guest', () => {})`
 
-# Изоляция и моки
+# Component tests
 
-- Для работы с API/store:
-  - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
-- Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
+- Use `render` from `@vue/test-utils`.
+- Assertions:
+  - DOM matchers for Testing Library as wired in the project (`toBeInTheDocument`, `toHaveTextContent`, etc.).
+- Interactions:
+  - `userEvent` from `@testing-library/user-event`.
 
-# HTTP‑клиент
+# Isolation and mocks
 
-- При изменении **реализации общего HTTP‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
-- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
+- For API/store work:
+  - mock the store (via test-store) or use the project's accepted HTTP/API mock approach.
+- Do not mock what is part of the feature's public contract if that breaks the test's meaning.
 
-# Мапперы и преобразование данных
+# HTTP client
 
-- Функции маппинга данных (DTO -> доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
-- В тестах мапперов особое внимание уделять edge‑кейсам и регрессии бизнес‑правил (например, граничные значения, отсутствие полей, неожиданные комбинации значений).
+- When changing the **shared HTTP client implementation** (body parsing, headers, error branches, 401/refresh, `FormData`, `blob`, etc.) — **update or add behavior tests** next to the client module in `lib/clients/**` (prefer `*.spec.ts`; legacy `*.test.ts` — do not touch without a task).
+- Cover meaningful branches: successful JSON, HTTP error, network, auth scenarios relevant to the project.
 
-# Требование к агенту
+# Mappers and data transformation
 
-При добавлении тестов:
-- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
-- Добавлять тесты для критичных веток логики и edge‑кейсов.
- - При работе с данными:
-   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
-   - по возможности опираться на данные и обработчики из `mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
- - Размещение:
-   - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.ts`.
-   - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
-   - **новые** файлы — `*.spec.ts` / `*.spec.ts` (см. блок «Имена файлов» выше).
+- Data mapping functions (DTO → domain model and back), especially with computed fields and branches, must have unit tests.
+- In mapper tests, pay special attention to edge cases and business-rule regression (for example, boundary values, missing fields, unexpected value combinations).
+
+# Agent requirement
+
+When adding tests:
+- Follow existing test structure and patterns in the repository: `*.spec.ts(x)` next to the module or in a shared test directory — as in neighboring features.
+- Add tests for critical logic branches and edge cases.
+ - When working with data:
+   - use **response types** from the API (DTO types) and **target domain types** from `@/types`; do not duplicate interfaces in tests;
+   - when possible, rely on data and handlers from `mocks/**` (or repo equivalent), not ad-hoc random test data.
+ - Placement:
+   - for **UI components** — **do not create** a `__tests__` subdirectory inside the component folder; the test is a sibling `*.spec.ts`.
+   - in **other modules** (for example `api/services`) an existing `__tests__` layout is acceptable — do not break it for UI uniformity.
+   - **new** files — `*.spec.ts` / `*.spec.ts` (see "File names" above).
 ## Incorrect
 
 ```ts
 it('returns empty list when guest', () => {})
-it('Возвращает пустой список. пользователь не авторизован', () => {})
 ```
 
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+
 ## Correct
 
-```ts
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-```
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->