@bonesofspring/ai-rules 0.2.14 → 0.2.15

package/presets/cursor/nuxt/rules/agent-team-intake.mdc

@@ -11,6 +11,6 @@ When the user message looks like a **work request** (implement, add, fix, refact
 
 1. Prefer **`/task <their request>`** or invoke **task-router** first.
 2. Do not jump straight to coding without router + pipeline when scope is non-trivial.
-3. Pure questions («как работает X», «объясни») — prefer agent **`codebase-analyzer`** (explain-as-is); trivial one-liners may be answered inline. Do not open `/task`.
+3. Pure questions (“how does X work”, “explain”) — prefer agent **`codebase-analyzer`** (explain-as-is); trivial one-liners may be answered inline. Do not open `/task`.
 
-Exceptions: user explicitly says «без pipeline», «просто сделай», or continues an active slug.
+Exceptions: user explicitly says “no pipeline”, “just do it”, or continues an active slug.

package/presets/cursor/nuxt/rules/agent-team-orchestrator.mdc

@@ -9,7 +9,7 @@ alwaysApply: false
 
 Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.cursor/team/tasks/<slug>/`.
 
-Work request без `/task` — см. **`agent-team-intake.mdc`** (когда предлагать router вместо прямого кодинга).
+Work request without `/task` — see **`agent-team-intake.mdc`** (when to suggest the router instead of coding directly).
 
 ## Entry points
 
@@ -180,12 +180,12 @@ If `pipeline.json` is missing (old `/feature-start` tasks), fall back to fixed p
 
 Do **not** run `/task` + router for:
 
-- Pure questions («как работает X», «объясни») — prefer agent **`codebase-analyzer`** for deep traces; inline OK for trivial one-liners.
+- Pure questions («как работает X» (how does X work), «объясни» (explain)) — prefer agent **`codebase-analyzer`** for deep traces; inline OK for trivial one-liners. <!-- i18n-keep: E4 -->
 - Typo / one-file fix / trivial config with no architecture risk.
-- User explicitly says «без pipeline», «просто сделай», or continues an active slug.
+- User explicitly says «без pipeline» (no pipeline), «просто сделай» (just do it), or continues an active slug. <!-- i18n-keep: E4 -->
 - Single-line `docs-only` with no code impact.
 
-Borderline work requests — см. **`agent-team-intake.mdc`**.
+Borderline work requests — see **`agent-team-intake.mdc`**.
 
 ## Auto-detection (optional)
 

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

@@ -1,61 +1,61 @@
 ---
-description: Конвенции API сервисов и мапперов
+description: API services and mapper conventions
 globs: api/services/**/*.ts
 alwaysApply: false
 impact: HIGH
 ---
 
-# Роль API слоя
+# Role of the API layer
 
-- Инкапсулировать всё, что связано с:
-  - HTTP‑запросами через **экземпляры прикладных API‑клиентов** в `api/clients/**`, собранные на **общей реализации** из `lib/clients/**` (как в существующем коде); подробности — **`http-client.mdc`**; положение слоя в схеме **порты и адаптеры** — `architecture-boundaries.mdc`;
-  - URL/путями,
-  - заголовками и кодами ответов,
-  - DTO backend.
-- Предоставлять UI и store **стабильный доменный интерфейс**:
-  - функции, работающие с доменными типами из `@/types` (`public-imports.mdc`).
-  - мапперы между DTO и доменными типами.
+- Encapsulate everything related to:
+  - HTTP requests through **application API client instances** in `api/clients/**`, built on the **shared implementation** from `lib/clients/**` (as in existing code); details — **`http-client.mdc`**; layer placement in the **ports and adapters** scheme — `architecture-boundaries.mdc`;
+  - URLs/paths,
+  - headers and response codes,
+  - backend DTOs.
+- Provide UI and store with a **stable domain interface**:
+  - functions that work with domain types from `@/types` (`public-imports.mdc`).
+  - mappers between DTOs and domain types.
 
-# Структура модулей
+# Module structure
 
-- Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
-  - отдельный каталог в `api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
-- Внутри модуля:
-  - файлы с вызовами API (`index.ts` или `*.service.ts`);
-  - файлы мапперов (`*responseMappers.ts`);
-  - специфичные типы запросов/ответов (если не вынесены в `types/**` с экспортом через barrel `@/types`).
-  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `api/index.ts` (`import … from '@/api'`, **`public-imports.mdc`**).
+- For each domain area (for example, orders, billing, account settings):
+  - a separate directory in `api/services/<ServiceName or feature>/**` following repository convention.
+- Inside a module:
+  - files with API calls (`index.ts` or `*.service.ts`);
+  - mapper files (`*responseMappers.ts`);
+  - request/response-specific types (if not moved to `types/**` with export through the `@/types` barrel).
+  - when needed — local `index.ts` / barrel inside the module for structure **within** `api/**`; **outside** this layer UI, store, and other code import only from the root barrel `api/index.ts` (`import … from '@/api'`, **`public-imports.mdc`**).
 
-# Мапперы и типы
+# Mappers and types
 
-- Для каждого запроса/эндпоинта:
-  - описывать **response‑тип (DTO)**, точно соответствующий контракту backend;
-  - определять **целевой доменный тип** в `types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
-- Мапперы (например, `*responseMappers.ts`):
-  - чистые функции, без сайд‑эффектов;
-  - выполняют все необходимые вычисления и преобразования данных (булевы флаги, склейка строк, агрегаты и т.п.) при переводе из DTO в доменные модели;
-  - при необходимости обеспечивают обратное преобразование (доменные модели -> транспортные типы).
-- UI и store работают только с доменными типами (из `@/types` или экспортируемыми из public API слоя API), а не с "сырыми" DTO.
-- **Не вызывать `fetch` напрямую** в теле API‑методов: только через клиент; исключения — узкие модули (например JSON‑RPC), если так уже устроено в репозитории.
+- For each request/endpoint:
+  - describe the **response type (DTO)** that exactly matches the backend contract;
+  - define the **target domain type** in `types/**` that the application will use (including computed/aggregated fields).
+- Mappers (for example, `*responseMappers.ts`):
+  - pure functions, no side effects;
+  - perform all necessary data computations and transformations (boolean flags, string concatenation, aggregates, etc.) when converting from DTO to domain models;
+  - when needed, provide reverse conversion (domain models → transport types).
+- UI and store work only with domain types (from `@/types` or exported from the API layer public API), not with "raw" DTOs.
+- **Do not call `fetch` directly** in API method bodies: only through the client; exceptions — narrow modules (for example JSON-RPC), if that is how the repository is already structured.
 
-# Обработка ошибок
+# Error handling
 
-- API‑слой:
-  - не должен "глотать" ошибки без следа;
-  - либо бросает доменные/унифицированные ошибки;
-  - либо возвращает результат в `Result<T, E>`‑подобной форме (если такой паттерн принят в проекте).
-- Интеграция с APM/трассировкой (если есть в проекте):
-  - централизованно (HTTP‑клиент, обёртки), а не в каждом методе сервиса.
+- The API layer:
+  - must not "swallow" errors without a trace;
+  - either throws domain/unified errors;
+  - or returns a result in a `Result<T, E>`-like form (if that pattern is adopted in the project).
+- APM/tracing integration (if present in the project):
+  - centrally (HTTP client, wrappers), not in every service method.
 
-# Требование к агенту
+# Agent requirement
 
-При добавлении/изменении API‑метода:
-- Следовать существующим сервисам и мапперам как эталону.
-- Пройти чеклист barrel-экспортов (**`layer-barrel-exports.mdc`**): локальный `index.ts` → фасад слоя → корневой barrel.
-- Не смешивать слой API и UI/store:
-  - компоненты не должны зависеть от DTO;
-  - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы в **Pinia actions** при разборе `catch`/payload, если так выстроен сервис (см. `store-pinia.mdc`, `http-client.mdc`).
-- При использовании API‑сервисов в UI, store и утилитах **вне** `api/**` импортировать **только** из `@/api` (корневой barrel), см. **`public-imports.mdc`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.
+When adding/changing an API method:
+- Follow existing services and mappers as the reference.
+- Complete the barrel-export checklist (**`layer-barrel-exports.mdc`**): local `index.ts` → layer facade → root barrel.
+- Do not mix the API layer and UI/store:
+  - components must not depend on DTOs;
+  - store must not assemble URLs/endpoint codes itself or bypass services; **transport response type** and **error contract** from `@/types` (as with the application client) are acceptable in **Pinia actions** when parsing `catch`/payload, if the service is structured that way (see `store-pinia.mdc`, `http-client.mdc`).
+- When using API services in UI, store, and utilities **outside** `api/**`, import **only** from `@/api` (root barrel), see **`public-imports.mdc`**; inside the API layer — via relative paths or `@/api/services/**` / `@/api/clients/**`, without duplicating the public contract around the root barrel for external consumers.
 ## Incorrect
 
 ```ts

package/presets/cursor/nuxt/rules/architecture-boundaries-ui.mdc

@@ -1,15 +1,15 @@
 ---
-description: Границы слоя UI — slim rule для правок компонентов (без полной карты store/API)
+description: UI layer boundaries — slim rule for component edits (without the full store/API map)
 globs: components/**/*.vue,components/**/*.ts
 alwaysApply: false
 ---
 
 # UI layer boundaries (slim)
 
-- **Импорты:** `components/**`, `composables/**`, `stores/**` (public), типы из `~/types` / `@/types`, API — только `from '~/api'` / `from '@/api'` (`public-imports`).
-- **Запрещено:** прямой HTTP‑клиент (`$fetch` / ofetch вне `lib/clients`); знание DTO — только доменные типы.
-- **Состояние:** сценарии с записью и координация шагов — через Pinia actions (`store-pinia`); узкие прямые вызовы `~/api` для чтения — только как в соседних фичах.
-- **Организация:** алиасы `~/` / `@/`; без deep‑импортов в чужие фичи; только public API.
-- **Barrel:** при новых публичных символах — реэкспорт по `layer-barrel-exports` (правило грузится на `index.ts`).
+- **Imports:** `components/**`, `composables/**`, `stores/**` (public), types from `~/types` / `@/types`, API — only `from '~/api'` / `from '@/api'` (`public-imports`).
+- **Forbidden:** direct HTTP client (`$fetch` / ofetch outside `lib/clients`); DTO knowledge — domain types only.
+- **State:** write scenarios and multi-step coordination — via Pinia actions (`store-pinia`); narrow direct `~/api` reads — only as in neighboring features.
+- **Organization:** `~/` / `@/` aliases; no deep imports into other features; public API only.
+- **Barrel:** for new public symbols — re-export per `layer-barrel-exports` (rule loads on `index.ts`).
 
-Полная карта слоёв (store, API, порты‑адаптеры): **`architecture-boundaries`** — при правках `api`, `stores`, `types`, `lib`.
+Full layer map (store, API, ports/adapters): **`architecture-boundaries`** — when editing `api`, `stores`, `types`, `lib`.

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

@@ -1,70 +1,70 @@
 ---
-description: Архитектурные границы и правила импортов
+description: Architectural boundaries and import rules
 globs: api/**/*,stores/**/*,types/**/*,lib/**/*
 alwaysApply: false
 impact: CRITICAL
 ---
 
-# Границы между слоями
+# Layer boundaries
 
 - **UI (`pages/**`, `components/**`, `layouts/**`)**:
-  - Может импортировать: `components/**`, `composables/**`, `stores/**` (public), типы из `~/types` / `@/types` и enum из `~/types/enums` / `@/types/enums` (**только как в `public-imports.mdc`**), контракт к API — **только** `import … from '~/api'` / `from '@/api'` (**`public-imports.mdc`**).
-  - Не должен:
-    - обращаться к HTTP‑клиенту напрямую (`$fetch` / ofetch вне `lib/clients`);
-    - знать детали DTO backend — только доменные типы.
+  - May import: `components/**`, `composables/**`, `stores/**` (public), types from `~/types` / `@/types` and enums from `~/types/enums` / `@/types/enums` (**only as in `public-imports.mdc`**), API contract — **only** `import … from '~/api'` / `from '@/api'` (**`public-imports.mdc`**).
+  - Must not:
+    - call the HTTP client directly (`$fetch` / ofetch outside `lib/clients`);
+    - know backend DTO details — only domain types.
 - **Store (`stores/**`)** — Pinia `defineStore` only (`store-pinia.mdc`):
-  - Может импортировать: другие `stores/**` (public), сервисы и публичные сущности API — **только** из `~/api` / `@/api` (**`public-imports.mdc`**), типы из `~/types` / `@/types` и enum из `~/types/enums` / `@/types/enums` (**`public-imports.mdc`**).
-  - Не должен:
-    - зависеть от конкретных UI‑компонентов / страниц;
-    - напрямую работать с global/window API.
-  - Вызовы к backend — только через сервисы, импортируемые из `~/api` / `@/api`; **транспортные** типы ответа и ошибки (из `@/types`, в том же виде, что у прикладного HTTP‑клиента) в **Pinia actions** допустимы, если так выстроен API‑слой (`http-client.mdc`, `store-pinia.mdc`).
-- **API (`api/**`)** — реализация в `services/**`, `clients/**`, реэкспорт в `api/index.ts`:
-  - Внутри слоя: типы из `@/types` и enum из `@/types/enums` (**`public-imports.mdc`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`http-client.mdc`, `api-services.mdc`).
-  - Не должен:
-    - тянуть в себя UI или store;
-    - смешивать HTTP‑слой и доменный слой — использовать мапперы.
-
-## UI и обращение к API (`~/api` / `@/api`)
-
-- По умолчанию сценарии с **изменением серверного состояния** и координация нескольких шагов — через **Pinia actions** (`defineStore`, паттерн фичи в репозитории).
-- Прямой вызов методов сервисов, импортированных из **`~/api` / `@/api`**, из UI допустим только в **узких случаях**: преимущественно **чтение** или действие **без необходимости держать результат в Pinia**; те же **доменные типы**, что использовала бы store action; **не** дублировать уже существующий сценарий из store и **не** протаскивать DTO в компоненты.
-- Предпочтительно оформлять такие вызовы так же, как в **соседних фичах** репозитория (composable‑фасад, `use*` и т.д.).
-
-## Порты и адаптеры (краткая карта)
-
-- **Входящий адаптер**: UI — ввод пользователя, отображение; зависит от store и доменных типов, не от транспорта.
-- **Оркестрация сценариев**: store (Pinia actions) — вызывает сервисы, кладёт в state **доменные** модели после маппинга.
-- **Исходящий порт (контракт к backend)**: публичный API **`~/api` / `@/api`** (barrel `api/index.ts`; реализация — в `api/services/**` и т.д., см. `public-imports.mdc`).
-- **Исходящий адаптер**: общая реализация HTTP в **`lib/clients/**`** и экземпляры в **`api/clients/**`** (обёртка `$fetch` / ofetch).
-
-## Фича как срез
-
-- Для сложной фичи выравниваются имена и термины (**единый язык** предметной области) в типах, getters/actions, сервисах и UI; структура папок — как в соседних фичах репозитория.
-
-# Правила импортов
-
-- Всегда использовать алиас `~/` или `@/` для импортов между слоями (как принято в репо); уважать `#imports`.
-- Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, composables, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`layer-barrel-exports.mdc`** и `public-imports.mdc`; для API‑слоя снаружи `api/**` — **`public-imports.mdc`** (только `~/api` / `@/api`).
-- При добавлении нового кода проверять:
-  - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
-
-# Организация фич
-
-- Для сложных фич (например, `OrderCheckout`):
-  - Страница / route: `pages/**` и/или `components/pages/OrderCheckoutPage/**`.
-  - Локальные компоненты: поддиректории `components/**` внутри страницы.
-  - Связанный store: `stores/orderCheckout.ts` (или схема соседних Pinia‑модулей в репо).
-  - API: `api/services/OrdersApi/OrderCheckout/**` (имя корневого сервиса взять из принятой в проекте схемы).
-  - Типы: `types/**` с экспортом через barrel **`types/index.ts`** (`public-imports.mdc`).
-
-# Требование к агенту
-
-При добавлении новой функциональности:
-- Разместить файлы в **соответствующих слоях**.
-- Проверить существующие фичи с аналогичной структурой и **повторить их организацию**.
-- Не "коротить" слои (например, не вызывать API прямо из компонента только ради упрощения).
-- **Запрещено:** RTK / Redux (`createSlice`, `createAsyncThunk`, `useDispatch`, `stores/slices/**` как канон).
+  - May import: other `stores/**` (public), services and public API entities — **only** from `~/api` / `@/api` (**`public-imports.mdc`**), types from `~/types` / `@/types` and enums from `~/types/enums` / `@/types/enums` (**`public-imports.mdc`**).
+  - Must not:
+    - depend on specific UI components / pages;
+    - work with global/window API directly.
+  - Backend calls — only through services imported from `~/api` / `@/api`; **transport** response and error types (from `@/types`, same shape as the application HTTP client) in **Pinia actions** are acceptable if the API layer is structured that way (`http-client.mdc`, `store-pinia.mdc`).
+- **API (`api/**`)** — implementation in `services/**`, `clients/**`, re-export in `api/index.ts`:
+  - Inside the layer: types from `@/types` and enums from `@/types/enums` (**`public-imports.mdc`**); imports `@/api/services/**`, `@/api/clients/**`, relative paths between layer files (`http-client.mdc`, `api-services.mdc`).
+  - Must not:
+    - pull in UI or store;
+    - mix HTTP and domain layers — use mappers.
+
+## UI and API access (`~/api` / `@/api`)
+
+- By default, scenarios that **change server state** and coordinate multiple steps go through **Pinia actions** (`defineStore`, feature pattern in the repository).
+- Direct calls to service methods imported from **`~/api` / `@/api`** from UI are allowed only in **narrow cases**: mainly **reads** or actions **without needing the result in Pinia**; same **domain types** a store action would use; **do not** duplicate an existing store scenario and **do not** pass DTOs into components.
+- Prefer structuring such calls like **neighboring features** in the repository (composable facade, `use*`, etc.).
+
+## Ports and adapters (short map)
+
+- **Inbound adapter**: UI — user input, display; depends on store and domain types, not transport.
+- **Scenario orchestration**: store (Pinia actions) — calls services, puts **domain** models in state after mapping.
+- **Outbound port (backend contract)**: public API **`~/api` / `@/api`** (barrel `api/index.ts`; implementation — in `api/services/**`, etc., see `public-imports.mdc`).
+- **Outbound adapter**: shared HTTP implementation in **`lib/clients/**`** and instances in **`api/clients/**`** (wrap `$fetch` / ofetch).
+
+## Feature as a slice
+
+- For a complex feature, align names and terms (**ubiquitous language** of the domain) in types, getters/actions, services, and UI; folder structure — as in neighboring features in the repository.
+
+# Import rules
+
+- Always use the `~/` or `@/` alias for cross-layer imports (as established in the repo); respect `#imports`.
+- Within one module/feature, relative imports are OK, but **without climbing above the feature root** (avoid `../../../`).
+- When components, composables, utilities, and other modules reach into another layer or feature, use only **public API** (barrel/index files and explicitly exported entities); no deep imports into other features' internal files; for regulated layers — **`layer-barrel-exports.mdc`** and `public-imports.mdc`; for the API layer from outside `api/**` — **`public-imports.mdc`** (only `~/api` / `@/api`).
+- When adding new code, check:
+  - if the module is reusable — it should depend only on "lower" layers (types, utils, api), not on pages.
+
+# Feature organization
+
+- For complex features (for example, `OrderCheckout`):
+  - Page / route: `pages/**` and/or `components/pages/OrderCheckoutPage/**`.
+  - Local components: `components/**` subdirectories inside the page.
+  - Related store: `stores/orderCheckout.ts` (or the neighboring Pinia module scheme in the repo).
+  - API: `api/services/OrdersApi/OrderCheckout/**` (root service name from the project scheme).
+  - Types: `types/**` with export through barrel **`types/index.ts`** (`public-imports.mdc`).
+
+# Agent requirement
+
+When adding new functionality:
+- Place files in the **appropriate layers**.
+- Check existing features with similar structure and **repeat their organization**.
+- Do not "short-circuit" layers (for example, do not call API directly from a component just to simplify).
+- **Forbidden:** RTK / Redux (`createSlice`, `createAsyncThunk`, `useDispatch`, `stores/slices/**` as the canon).
 
 ## Incorrect
 

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

@@ -1,51 +1,52 @@
 ---
-description: Поддержка и улучшение качества кода и архитектуры
+description: Maintain and improve code quality and architecture
 alwaysApply: true
 ---
 
 <!-- shared-core: quality/code-quality-and-refactoring.md -->
 
-# Поддержка существующего стиля
+# Match existing style
 
-- Следовать существующим паттернам (имена, структура, типизация / DI / error handling); минимизировать стилистический шум (лишний format/rename).
-- Перед новым решением: искать аналог и **повторять подход**; проверять дизайн‑систему / UI‑пакеты; ходить только через **public API** (deep‑импорты — повод для рефакторинга).
+- Follow existing patterns (names, structure, typing / DI / error handling); avoid drive-by formatting or renames.
+- Before a new solution: find an analog and **repeat the approach**; check the design system / UI packages; go only through the **public API** (deep imports are a reason to refactor).
 
-# Принципы
+# Principles
 
-- **KISS:** самое простое изменение в паттернах репозитория.
-- **DRY + Rule of Three:** общее — только после 3-го повторения (ошибочная абстракция дороже дублирования).
-- **YAGNI:** без API, флагов, слоёв «на будущее» без текущего требования.
-- **SOLID:** S — один повод менять; O — композиция/новые реализации; L — контракт подтипа; I — узкие порты; D — абстракции (порты), детали в адаптерах стека.
-- **CUPID:** Composable; Unix philosophy (одна ответственность); Predictable; Idiomatic (репо); Domain-based.
-- **Composition over inheritance;** Law of Demeter — без цепочек `a.b.c.d`; через public API / facade.
+- **KISS:** the simplest change in the repository’s patterns.
+- **DRY + Rule of Three:** share only after the 3rd repetition (wrong abstraction costs more than duplication).
+- **YAGNI:** no APIs, flags, or “for later” layers without a current requirement.
+- **SOLID:** S — one reason to change; O — composition/new implementations; L — subtype contract; I — narrow ports; D — abstractions (ports), details in stack adapters.
+- **CUPID:** Composable; Unix philosophy (one responsibility); Predictable; Idiomatic (repo); Domain-based.
+- **Composition over inheritance;** Law of Demeter — no `a.b.c.d` chains; via public API / facade.
 
-# Рефакторинг при изменениях
+# Refactoring during changes
 
-- Лёгкий refactor OK, если меньше дублирования, выше читаемость, без ломки публичных контрактов.
-- Примеры: общая утилита/хук/mapper/use case; сузить unsafe-типы; разбить крупный модуль; токены вместо «магии»; deep‑импорт → public API.
-- Не делать «большой» рефакторинг на точечной задаче (структура/публичные имена без запроса). Крупное — минимальными шагами; код остаётся собираемым.
+- Light refactor is OK if it reduces duplication, improves readability, and does not break public contracts.
+- Examples: shared utility/hook/mapper/use case; narrow unsafe types; split a large module; tokens instead of “magic”; deep import → public API.
+- Do not do a “big” refactor on a point task (structure/public names without a request). Break large work into minimal steps; keep the repo buildable after each step.
 
-# Требование к агенту
+# Agent requirement
 
-- **Boy scout:** оставлять модуль немного лучше; не жертвовать архитектурой и слоями ради краткости.
+- **Boy scout:** leave the module a bit better; do not sacrifice architecture and layers for brevity.
 
 ## Agent discipline (anti-sycophancy)
 
 Essentials below. Full procedural set (~17 rules) → load **`anti-sycophancy-discipline`**.
 
 - Unverifiable third-party API → mark `// VERIFY: lib.symbol @ version` (or stack equivalent); never invent signatures.
-- Before «is this correct?» — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
+- Before "is this correct?" — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
 - Refactor without tests → propose characterization test; if declined, label `UNTESTED`.
-- Comments = WHY only when non-obvious; ban self-referential «added for issue Y».
+- Comments = WHY only when non-obvious; ban self-referential "added for issue Y".
 - Urgency/authority: name the trade-off once, then comply — no apology loops.
 - Match verification to risk; report by what was **verified**, not attempted.
 
 Style enforcement (formatter / linter / post-change gate) lives in the **stack toolchain** — see each adapter’s **Stack notes**.
 
-> Stack-specific lint gates, примеры и toolchain — в секции **Stack notes** адаптера пресета.
+> Stack-specific lint gates, examples, and toolchain — in the preset adapter **Stack notes** section.
+
 ## Stack notes
 
-- Перед новым UI‑контролом проверять существующий Vue/Nuxt UI‑код и пакеты проекта.
-- Public API: index/barrel‑файлы и явно экспортируемые сущности (`public-imports`, `layer-barrel-exports`).
-- Допустимые примеры: общий composable/утилита; типизация `any`/`unknown`; разделение крупного SFC; CSS‑токены вместо «магических» значений.
-- Lint/stylelint — только **`post-change-lint`**; ESLint (vue) + Stylelint configs at repo root (e.g. `eslint.config.mjs`, `.stylelintrc*`). Отключение правила (`eslint-disable`) — только **точечно** с кратким комментарием «зачем».
+- Before adding a new UI control, check existing Vue/Nuxt UI code and project packages.
+- Public API: index/barrel files and explicitly exported entities (`public-imports`, `layer-barrel-exports`).
+- Allowed examples: shared composable/utility; typing `any`/`unknown`; splitting a large SFC; CSS tokens instead of “magic” values.
+- Lint/stylelint — only **`post-change-lint`**; ESLint (vue) + Stylelint configs at repo root (e.g. `eslint.config.mjs`, `.stylelintrc*`). Disabling a rule (`eslint-disable`) — only **locally** with a short “why” comment.

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

@@ -1,5 +1,5 @@
 ---
-description: Требования к code review агентами Cursor для merge requests
+description: Requirements for Cursor agents reviewing merge requests
 alwaysApply: false
 ---
 
@@ -22,9 +22,9 @@ On-demand rule for review flows. **Procedure and output format:** skill `code-re
 - UI conventions of the stack
 - Unit and e2e/UI test conventions
 - Post-change lint/build gate before final report
-- Design smells **in MR diff scope** — load `design-guidance`; не разворачивать полный каталог Fowler вне диффа
-- Pattern name (GoF) — только если репозиторий уже использует эту форму или match минимален
-- Principles (KISS / DRY+Ro3 / YAGNI / SOLID / CUPID) — через always-on `code-quality-and-refactoring`, не дублировать эссе в review
+- Design smells **in MR diff scope** — load `design-guidance`; do not expand the full Fowler catalog outside the diff
+- Pattern name (GoF) — only if the repository already uses that shape or the match is minimal
+- Principles (KISS / DRY+Ro3 / YAGNI / SOLID / CUPID) — via always-on `code-quality-and-refactoring`, do not duplicate the essay in review
 
 Concrete rule stems — in **Stack notes**.
 
@@ -33,7 +33,7 @@ Concrete rule stems — in **Stack notes**.
 - Focus on MR diff, not the whole repo.
 - Use local `git diff` — do not invent hosting metadata.
 - Boy scout rule: suggest fixes feasible within the MR scope.
-- No «большие рефакторинги» without an explicit request (`code-quality-and-refactoring`).
+- No “big refactors” without an explicit request (`code-quality-and-refactoring`).
 
 ## Output contract