@bonesofspring/ai-rules 0.2.14 → 0.2.16

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

@@ -4,61 +4,61 @@ paths:
   - app/**/app/**/*
 ---
 
-# Навигация и роутинг: сначала стек проекта
+# Navigation and routing: project stack first
 
-Краткий ориентир для UI-компонентов: **`stack/navigation-router-ui.md`**.
+Short UI component guide: **`stack/navigation-router-ui.md`**.
 
-**При любой задаче, связанной с навигацией, переходами между страницами, URL, редиректами, хлебными крошками, защищёнными маршрутами или программной сменой маршрута** — перед предложением кода или импортов **нельзя** опираться на «типичный React» по умолчанию. Нужно **явно свериться со стеком целевого репозитория** и использовать **один** согласованный с проектом механизм.
+**For any task involving navigation, page transitions, URLs, redirects, breadcrumbs, protected routes, or programmatic route changes** — before proposing code or imports you **must not** default to “typical React.” **Explicitly verify the target repo’s stack** and use **one** mechanism consistent with the project.
 
-## Зависимости: что проверить в первую очередь
+## Dependencies: what to check first
 
-1. **`package.json`** в корне приложения (например `app/package.json` в монорепо — тот пакет, который реально собирается и деплоится). Смотреть **`dependencies`** и при необходимости **`peerDependencies`**:
-   - **`next`** — Next.js; версия важна для нюансов API (сверяться с документацией под эту major).
-   - **`react-router-dom`**, **`@remix-run/*`**, **`@tanstack/react-router`** и т.д. — отдельный роутинг; не подменять их API вызовами Next без проверки, что в проекте действительно используется этот стек.
-   - **`next`** и **`react-router-dom`** одновременно — возможно легаси или гибрид; **не** выбирать API по умолчанию — смотреть раздел «Реализация в коде» ниже.
+1. **`package.json`** at the app root (e.g. `app/package.json` in a monorepo — the package that is actually built and deployed). Check **`dependencies`** and if needed **`peerDependencies`**:
+   - **`next`** — Next.js; version matters for API nuances (check docs for that major).
+   - **`react-router-dom`**, **`@remix-run/*`**, **`@tanstack/react-router`**, etc. — separate routing; do not substitute Next APIs without confirming the project uses that stack.
+   - **`next`** and **`react-router-dom`** together — possible legacy or hybrid; **do not** pick APIs by default — see “Implementation in code” below.
 
-2. **Монорепо / workspaces** — роутинг может жить не в корневом `package.json`. Открыть **`package.json` того workspace**, где лежат страницы и `next.config.*` / точка входа SPA.
+2. **Monorepo / workspaces** — routing may live outside the root `package.json`. Open the **`package.json` of the workspace** where pages and `next.config.*` / SPA entry live.
 
-3. **Факт установки** — при сомнениях смотреть lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) или каталог `node_modules` у соответствующего пакета: убедиться, что заявленный пакет реально установлен, а не только прописан в документации.
+3. **Actual installation** — when in doubt, check the lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) or `node_modules` for the relevant package: confirm the declared package is installed, not only documented.
 
-## Реализация роутинга в проекте (код и структура)
+## Routing implementation in the project (code and structure)
 
-Перед предложением паттерна навигации **свериться с тем, как уже сделано в репозитории**:
+Before proposing a navigation pattern, **align with how the repo already does it**:
 
-1. **Дерево маршрутов**
-   - Next **App Router**: каталог **`app/`** (или `src/app/`) с `layout.tsx`, `page.tsx`, сегменты `[id]` и т.п.
-   - Next **Pages Router**: каталог **`pages/`** с `_app`, динамические `[slug].tsx`.
-   - Наличие **обоих** `app/` и `pages/` — уточнить по `next.config` и документации проекта, какой слой основной.
+1. **Route tree**
+   - Next **App Router**: **`app/`** (or `src/app/`) with `layout.tsx`, `page.tsx`, segments `[id]`, etc.
+   - Next **Pages Router**: **`pages/`** with `_app`, dynamic `[slug].tsx`.
+   - Both `app/` and `pages/` present — clarify via `next.config` and project docs which layer is primary.
 
-2. **Точки входа и обёртки**
-   - Поиск по коду импортов: **`from 'next/navigation'`**, **`from 'next/router'`**, **`from 'next/link'`**, **`from 'react-router-dom'`**, **`createBrowserRouter`**, **`RouterProvider`**, **`BrowserRouter`**.
-   - Где объявлены маршруты (файловая структура Next vs конфиг маршрутов / `routes.tsx` в SPA).
+2. **Entry points and wrappers**
+   - Search imports: **`from 'next/navigation'`**, **`from 'next/router'`**, **`from 'next/link'`**, **`from 'react-router-dom'`**, **`createBrowserRouter`**, **`RouterProvider`**, **`BrowserRouter`**.
+   - Where routes are declared (Next file structure vs SPA route config / `routes.tsx`).
 
-3. **Общие абстракции проекта**
-   - Обертки над ссылками (`@/ui/...`, `Link` из дизайн-системы), хелперы путей, константы роутов — **использовать их**, а не дублировать сырой роутер.
+3. **Project abstractions**
+   - Link wrappers (`@/ui/...`, design-system `Link`), path helpers, route constants — **use them**, do not duplicate raw router usage.
 
-4. **Соседние файлы фичи**
-   - Новый код навигации — в том же стиле, что страницы/хуки той же области (`next/navigation` vs `react-router-dom` как в соседних импортах).
+4. **Neighboring feature files**
+   - New navigation code — same style as pages/hooks in that area (`next/navigation` vs `react-router-dom` as in neighboring imports).
 
-## Как определить, что использовать (сводка)
+## How to decide what to use (summary)
 
-1. **Зависимости** — см. раздел выше; по ним задаётся допустимый набор пакетов.
-2. **Структура** — App Router vs Pages vs SPA по каталогам и конфигу.
-3. **Фактический код** — какие импорты и обёртки уже доминируют в приложении.
+1. **Dependencies** — see above; they define the allowed package set.
+2. **Structure** — App Router vs Pages vs SPA by directories and config.
+3. **Actual code** — which imports and wrappers dominate in the app.
 
-## Что использовать (краткая матрица)
+## What to use (quick matrix)
 
-| Стек | Программная навигация / чтение пути | Ссылки |
+| Stack | Programmatic navigation / path read | Links |
 |------|-------------------------------------|--------|
-| **Next.js App Router** | `next/navigation` (`useRouter`, `usePathname`, `useSearchParams`, `redirect` и т.д. по документации Next для вашей версии) | `next/link` |
+| **Next.js App Router** | `next/navigation` (`useRouter`, `usePathname`, `useSearchParams`, `redirect`, etc. per Next docs for your version) | `next/link` |
 | **Next.js Pages Router** | `next/router` | `next/link` |
-| **SPA + React Router** | `react-router-dom` (`useNavigate`, `useParams`, `useLocation`, …) | `<Link>` из `react-router-dom` |
+| **SPA + React Router** | `react-router-dom` (`useNavigate`, `useParams`, `useLocation`, …) | `<Link>` from `react-router-dom` |
 
-**Не делать:** подключать `react-router-dom` в проект на Next.js «по привычке»; импортировать хуки из `next/router` в компонентах App Router без проверки; смешивать два роутера в одном приложении без явной архитектурной причины в кодовой базе.
+**Do not:** add `react-router-dom` to a Next.js project “by habit”; import hooks from `next/router` in App Router components without checking; mix two routers in one app without an explicit architectural reason in the codebase.
 
-## Требование к агенту
+## Agent requirement
 
-- Перед генерацией или ревью кода навигации **коротко зафиксировать вывод** (например: «зависимости: `next` без `react-router-dom`; в коде везде `next/navigation` → используем то же») и следовать ему.
-- **Обязательная проверка:** актуальные **`dependencies`** в `package.json` нужного workspace + **как в проекте уже реализованы** маршруты и импорты (поиск по репозиторию, соседние файлы). Не полагаться только на предположение по одному признаку (например, только на наличие папки `app/`).
-- Если стек неочевиден (два роутера в зависимостях, гибрид) — **сверить lockfile / установленные пакеты** и **доминирующие импорты** в `src`/`app`, затем выбрать API.
-- Для **этого** пресета базовый ориентир — **`stack/next-app-core.md`**: Next.js; предпочитать **`next/navigation`** и **`next/link`** там, где используется App Router.
+- Before generating or reviewing navigation code, **briefly record the conclusion** (e.g. “dependencies: `next` without `react-router-dom`; code uses `next/navigation` everywhere → use the same”) and follow it.
+- **Mandatory 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 (e.g. only an `app/` folder).
+- If the stack is unclear (two routers in dependencies, hybrid) — **check lockfile / installed packages** and **dominant imports** in `src`/`app`, then choose the API.
+- For **this** preset the baseline is **`stack/next-app-core.md`**: Next.js; prefer **`next/navigation`** and **`next/link`** where App Router is used.

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

@@ -1,33 +1,33 @@
-# Стек и окружение
+# Stack and environment
 
-Конкретные версии — **из `package.json` и конфигов целевого репозитория**. Рамка preset: Next.js, React, TypeScript; runner/e2e/mocks/UI/APM — как заведено в репо.
+Concrete versions come **from `package.json` and configs of the target repository**. Preset frame: Next.js, React, TypeScript; runner/e2e/mocks/UI/APM — as established in the repo.
 
-# Структура проекта
+# Project structure
 
-- `app/` — корень Next.js; `app/src/**` — код; `app/__tests__/e2e/**` — e2e.
+- `app/` — Next.js root; `app/src/**` — code; `app/__tests__/e2e/**` — e2e.
 - `app/tsconfig.json`: `baseUrl: "."`, `paths: { "@/*": ["./src/*"] }`.
-- **Требование:** `@/*` вместо относительных импортов выше по дереву.
+- **Requirement:** `@/*` instead of relative imports that climb the tree.
 
-# Архитектурные слои
+# Architectural layers
 
-| Слой | Каталог | Детали |
-|------|---------|--------|
+| Layer | Directory | Details |
+|-------|-----------|---------|
 | UI | `app/src/ui/**` (pages, components) | `ui-and-accessibility/react-ui.md`, `architecture/architecture-boundaries-ui.md` |
 | Store | `app/src/store/**` (slices, middleware) | `api-and-data/store-rtk.md` |
 | API | `app/src/api/**` (services, clients, barrel) | `api-and-data/api-services.md`, `api-and-data/http-client.md` |
 | HTTP | `app/src/lib/clients/**`, `app/src/api/clients/**` | `api-and-data/http-client.md` |
 | Types | `app/src/types/**` | `architecture/public-imports.md`, `stack/types-jsdoc.md` |
-| Mocks | `app/src/mocks/**` | по схеме репозитория |
+| Mocks | `app/src/mocks/**` | per repository layout |
 
-Границы слоёв, порты/адаптеры, UI→API — **`architecture/architecture-boundaries.md`**. Импорты `@/types`, `@/api` — **`architecture/public-imports.md`**.
+Layer boundaries, ports/adapters, UI→API — **`architecture/architecture-boundaries.md`**. Imports of `@/types`, `@/api` — **`architecture/public-imports.md`**.
 
-# Работа агента
+# Agent work
 
-- Архитектура и импорты: `architecture/architecture-boundaries.md`, `architecture/public-imports.md`
-- Фичи: `architecture/feature-delivery-workflow.md` + skill `feature-delivery`
-- После правок: **вызвать** `tooling-and-review/post-change-lint.md` (requestable, обязателен после code edits); менеджер пакетов: `tooling-and-review/package-manager.md`
-- Копировать паттерны соседних файлов в целевом слое; не использовать `any` (предпочитать `unknown` + сужение)
+- Architecture and imports: `architecture/architecture-boundaries.md`, `architecture/public-imports.md`
+- Features: `architecture/feature-delivery-workflow.md` + skill `feature-delivery`
+- After edits: **invoke** `tooling-and-review/post-change-lint.md` (requestable, required after code edits); package manager: `tooling-and-review/package-manager.md`
+- Copy patterns from neighboring files in the target layer; do not use `any` (prefer `unknown` + narrowing)
 
-Задачи на **сеть, HTTP, новые эндпоинты**: `api-and-data/http-client.md` + `api-and-data/api-services.md` + `api-and-data/store-rtk.md`.
+Tasks involving **network, HTTP, new endpoints**: `api-and-data/http-client.md` + `api-and-data/api-services.md` + `api-and-data/store-rtk.md`.
 
-См. **`rules/README.md`** — полный каталог.
+See **`rules/README.md`** — full catalog.

package/presets/claude/next/rules/stack/next-app-router.md

@@ -6,34 +6,34 @@ paths:
 
 # Next.js App Router
 
-Применять при работе с `app/src/app/**` или маршрутами App Router в целевом репо.
+Apply when working with `app/src/app/**` or App Router routes in the target repo.
 
 ## Server vs Client
 
-- **Server Components по умолчанию** — без `'use client'`, если не нужны hooks, browser API, event handlers.
-- **`'use client'`** — только для интерактива, `useState`/`useEffect`, browser-only API.
-- Не тянуть store/RTK и тяжёлый client-state в Server Components без необходимости.
+- **Server Components by default** — no `'use client'` unless hooks, browser APIs, or event handlers are required.
+- **`'use client'`** — only for interactivity, `useState`/`useEffect`, and browser-only APIs.
+- Do not pull store/RTK and heavy client state into Server Components without a clear need.
 
 ## Data fetching
 
-- Предпочитать fetch/data-loader на **server** (RSC, route handlers, server actions — по принятому в репо паттерну).
-- **Не дублировать** один запрос в RSC и client без причины.
-- Кеш и revalidate — как в существующих страницах репо (`fetch` options, `revalidate`, tags).
+- Prefer fetch/data loading on the **server** (RSC, route handlers, server actions — per the repo’s established pattern).
+- **Do not duplicate** the same request in RSC and client without a reason.
+- Cache and revalidate — match existing pages in the repo (`fetch` options, `revalidate`, tags).
 
-## Маршруты и UX
+## Routes and UX
 
-- Для async data routes **обязательны** sibling **`loading.tsx`** и **`error.tsx`** (и `not-found.tsx` где уместно) — по образцу соседних routes.
-- **Suspense** — для медленных client/server секций; fallback согласован с дизайн-системой.
-- Навигация — `stack/navigation-router.md` + router/link паттерны проекта.
+- For async data routes, sibling **`loading.tsx`** and **`error.tsx`** are **required** (and `not-found.tsx` where appropriate) — follow neighboring routes.
+- **Suspense** — for slow client/server sections; fallback aligned with the design system.
+- Navigation — `stack/navigation-router.md` + project router/link patterns.
 
-## Границы слоёв
+## Layer boundaries
 
-- RSC/route handlers **не импортируют UI-компоненты с client-only зависимостями** напрямую в server tree без `'use client'` границы.
-- Доменные типы — `@/types`; вызовы backend — через `@/api` / services, не raw `fetch` из page.tsx без слоя API.
+- RSC/route handlers **must not import UI components with client-only dependencies** directly into the server tree without a `'use client'` boundary.
+- Domain types — `@/types`; backend calls — via `@/api` / services, not raw `fetch` from `page.tsx` without the API layer.
 
 ## Anti-hallucination (App Router)
 
-Меньше угаданного кода лучше, чем больше. Сверяй API с версией Next в `package.json` и соседними routes.
+Less guessed code is better than more. Verify APIs against the Next version in `package.json` and neighboring routes.
 
 | ❌ Avoid | ✅ Prefer |
 |---------|----------|
@@ -45,6 +45,6 @@ paths:
 
 See also: **`react-next-anti-hallucination`** — broader React / RTK / Next phantom-import banlist (requestable; `anti-hallucination/react-next-anti-hallucination.md`).
 
-## Эталон
+## Reference
 
-Смотри существующий route той же сложности в `app/src/app/**` и повтори структуру (`architecture/reference-features.md`).
+Find an existing route of similar complexity in `app/src/app/**` and repeat its structure (`architecture/reference-features.md`).

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

@@ -5,55 +5,55 @@ paths:
   - app/src/types/**/*
 ---
 
-# Не использовать `as` для приведения типов при экспорте и импорте
+# Do not use `as` for type assertions on export and import boundaries
 
-## О чём речь
+## Scope
 
-Речь о **type assertion** в TypeScript: выражение вида `значение as Тип`.
+This is about **type assertion** in TypeScript: an expression like `value as Type`.
 
-**Не относится к правилу** (это не assertion, а синтаксис модулей):
+**Out of scope** (module syntax, not assertion):
 
-- переименование при экспорте: `export { foo as bar }`, `export { default as Baz } from '...'`;
-- переименование при импорте: `import { foo as bar } from '...'`;
-- `import type { Foo as Bar }` — алиас типа в импорте типов.
+- 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-only import.
 
-## Требование
+## Requirement
 
-- На **публичной границе модуля** (экспорт, присваивание импортированным символам с принудительным приведением) **не использовать** `as Тип` для «подгонки» типов, если можно обойтись нормальной типизацией.
+- On the **public module boundary** (export, assigning imported symbols with forced casting) **do not use** `as Type` to “fit” types when normal typing suffices.
 
-## Предпочитать вместо `as`
+## Prefer instead of `as`
 
-- явную аннотацию: `const x: T = ...` / `function f(): T`;
-- **дженерики** у функций и классов;
-- **`satisfies`** (когда нужно проверить совместимость без сужения до `any`);
-- сужение **`unknown`** после проверки (type guards, `zod` и т.п.);
-- правку **исходных типов/DTO/мапперов**, а не assertion на выходе.
+- explicit annotation: `const x: T = ...` / `function f(): T`;
+- **generics** on functions and classes;
+- **`satisfies`** (when you need compatibility check without narrowing to `any`);
+- narrowing **`unknown`** after checks (type guards, `zod`, etc.);
+- fix **source types/DTO/mappers**, not assertion at the output.
 
-## Когда `as` допустим
+## When `as` is acceptable
 
-- взаимодействие с **не типизированными** или некорректно типизированными внешними модулями;
-- узкие места после **валидации** данных;
-- **`as const`** — литеральные типы;
-- блок **`catch (error)`** после HTTP: по возможности **`instanceof`** на **класс ошибки транспорта** из `@/types`; голый **`as`** — только если `instanceof` недоступен.
+- interaction with **untyped** or incorrectly typed external modules;
+- narrow spots after data **validation**;
+- **`as const`** — literal types;
+- **`catch (error)`** block after HTTP: prefer **`instanceof`** on the **transport error class** from `@/types`; bare **`as`** — only when `instanceof` is unavailable.
 
-## Примеры
+## 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: breaks type immediately after import
 import { getData } from './api'
 export const data = getData() as MyDto[]
 
-// ✅ Лучше: типизировать getData / обернуть типобезопасной функцией
+// ✅ Better: type getData / wrap in a type-safe function
 ```
 
-## Требование к агенту
+## Agent requirement
 
-При ревью и генерации кода **не добавлять** новые `as Тип` на экспортируемые сущности без явной необходимости.
+When reviewing and generating code, **do not add** new `as Type` on exported symbols without explicit need.
 
-В слайсах и сервисах при обработке ошибок API сначала рассматривать **`instanceof`** на класс ошибки транспорта из `@/types` (`api-and-data/http-client.md`, `api-and-data/store-rtk.md`).
+In slices and services handling API errors, consider **`instanceof`** on the transport error class from `@/types` first (`api-and-data/http-client.md`, `api-and-data/store-rtk.md`).

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

@@ -3,35 +3,46 @@ paths:
   - app/src/types/**/*.ts
 ---
 
-# Документация типов в `app/src/types`
+# Type documentation in `app/src/types`
 
-При добавлении или существенном изменении типов в этом слое **следовать уже принятому в репозитории стилю JSDoc** (см. примеры: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
+When adding or substantially changing types in this layer, **follow the JSDoc style already adopted in the repo** (see examples: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
 
-## Язык и форма
+## Language and form
 
-- Текст комментариев — **на русском**, кратко и по делу.
-- **Не использовать** `@param`, `@returns`, `@see`, `@deprecated` для описания типов — достаточно обычного текста в `/** … */`.
+- Comment text — **in Russian** (repo locale convention for domain/API field descriptions), brief 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 in `/** … */` is enough.
 
-## Экспортируемый `type` / `interface`
+## Exported `type` / `interface`
 
-- Сразу **перед объявлением** — блок `/** … */`.
-- Для вложенных объектов — отдельный блок над каждым объявлением.
+- Immediately **before the declaration** — a `/** … */` block.
+- If you need to explain data source, constraints, or non-obvious details — a **second paragraph** in the same block (in JSDoc, separate paragraphs with a blank line between text lines).
+- For **nested** objects in the same file, document each type with its own block above its declaration.
 
-## Поля
+## Fields
 
-- У **каждого** публичного свойства — **однострочный** `/** … */` над полем.
-- Если поле **вычисляется на фронте** — префикс **`[computed]`**.
-- Форматы данных указывать **в тексте** (например дата `YYYY-MM-DD`).
+- For **every** public property — a **single-line** `/** … */` on the line directly **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 this **in the text**: e.g. date `YYYY-MM-DD`, a display string example in quotes.
 
-## Классы и enum
+Example field comment (Russian locale — keep Cyrillic in type docs): <!-- i18n-keep: E5 -->
 
-- Для **классов** — блок над классом и комментарии к публичным полям.
-- В `enums.ts` исторически часто **без JSDoc** на каждом члене; для новых enum допустимо описание **над enum**.
+```ts
+/** Дата рождения в формате YYYY-MM-DD */ <!-- i18n-keep: E5 -->
+birthDate: string
+```
 
-## Практика для агента
+## Classes and other declarations
 
-- Не оставлять новые публичные поля без пояснения, если смысл не равен имени на 100%.
-- Поддерживать **тот же стиль**, что в файле.
-- Одна-две фразы на тип, одна строка на поле — норма.
+- For **classes** (e.g. transport errors), when changing public API — a brief block above the class and **comments on public fields** using the same rules as interface properties.
 
-См. также импорты и barrel: `architecture/public-imports.md`.
+## `enum`
+
+- In `enums.ts`, members are often **without JSDoc** historically; for new enums a short description **above the enum** is acceptable if purpose is not obvious from the name. UI labels — as established, via `*Names` objects next to the enum.
+
+## Agent practice
+
+- When adding a new type or field, **do not leave** new public fields unexplained if meaning is not 100% clear from the name.
+- When editing a file that already has such comments, **maintain the same style**, not mixed with English-only or tag-heavy blocks.
+- Do not bloat comments: one or two sentences per type, one line per field is normal; exception — a genuinely complex domain caveat.
+
+See also imports and barrel: `architecture/public-imports.md`.

package/presets/claude/next/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: app/src/**/*.spec.*`, `*.test.*` |
+| File | Contents | Loading |
+|------|----------|---------|
+| `playwright-agents.md` | Planner / generator / healer — e2e structure | session start |
+| `tests-unit.md` | Unit/integration; describe/it naming in Russian (locale) | `paths: app/src/**/*.spec.*`, `*.test.*` |
 | `tests-e2e-structure.md` | `*.cases.md`, page objects, data-testid | `paths: app/__tests__/e2e/**` |
 
-См. также `.claude/agents/playwright-test-*.md` после `ai-rules init`.
+See also `.claude/agents/playwright-test-*.md` after `ai-rules init`.

package/presets/claude/next/rules/testing/playwright-agents.md

@@ -71,4 +71,4 @@ When acting as a **Healer** (or working with the Playwright healer agent):
 
 Healer should keep tests aligned with the existing test plans (`*.cases.md`) and with the page objects and helpers already used in the project.
 
-См. также агенты в `.claude/agents/` пресета и **`testing/tests-e2e-structure.md`**.
+See also agents under the preset’s `.claude/agents/` and **`testing/tests-e2e-structure.md`**.

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

@@ -3,50 +3,51 @@ paths:
   - app/__tests__/e2e/**
 ---
 
-# Структура e2e в проекте
-
-- Папка e2e: `app/__tests__/e2e/**`.
-- Планы сценариев:
-  - `*.cases.md` файлы — **канонический источник сценариев**.
-- Тесты:
-  - `*.spec.ts` файлы — реализация сценариев на Playwright.
-- Общие утилиты и абстракции:
-  - `app/__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 и хелперы, а не копировать селекторы напрямую в каждый тест.
-
-См. также **`testing/playwright-agents.md`** для planner/generator/healer.
+# E2E structure in the project
+
+- E2E folder: `app/__tests__/e2e/**`.
+- Scenario plans:
+  - `*.cases.md` files — **canonical source of scenarios**.
+- Tests:
+  - `*.spec.ts` files — Playwright scenario implementations.
+- Shared utilities and abstractions:
+  - `app/__tests__/e2e/_shared/**` — constants, fluent interfaces, helpers.
+
+# Principles
+
+- Every scenario from `*.cases.md` must have a corresponding test (or set of tests).
+- **Do not** weaken assertions in tests if that contradicts business expectations from the plans.
+- Prefer:
+  - page objects (for example, `OrderHistoryPage.ts`);
+  - shared helpers from `_shared`.
+
+# E2E test naming
+
+- Language:
+  - in consumer apps, `test` / `it`, `describe` block titles, and steps in `*.cases.md` **may use the project locale** (often Russian) — phrasing behavior and expected outcome;
+  - when the repo ESLint or team convention requires Russian titles, follow that; otherwise use clear English business phrases.
+- E2E test title format (`test(...)` / `it(...)`):
+  - before the scenario description, include a **numbered prefix** in the form: `PREFIX-XXX Scenario description`.
+  - `PREFIX` — abbreviation from the **first letters of words** in 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 test title example (Russian locale in consumer app):
+    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })` <!-- i18n-keep: E5 --> (Order list is displayed)
+  - within one entity (`PREFIX`), test numbers must form a **consistent sequence** with no duplicate numbers.
+
+# data-testid for e2e
+
+- **Selector priority:** `data-testid` for stable elements; `getByRole` and `getByLabel` for forms and accessible elements.
+- **Naming:** `{parent}__{element}` scheme (for example, `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 changing UI:** update data-testid in components and matching selectors in page objects; cross-check with `*.cases.md`.
+
+# Agent requirement
+
+When adding/changing e2e tests:
+
+- First read the matching `*.cases.md` and sync scenario titles.
+- Place specs next to plans in the same directory.
+- Reuse shared page objects and helpers instead of copying selectors directly into every test.
+
+See also **`testing/playwright-agents.md`** for planner/generator/healer.