@bonesofspring/ai-rules 0.2.14 → 0.2.16

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

@@ -1,61 +1,61 @@
 ---
-description: Конвенции API сервисов и мапперов
+description: API services and mapper conventions
 globs: app/src/api/services/**/*.ts
 alwaysApply: false
 impact: HIGH
 ---
 
-# Роль API слоя
+# Role of the API layer
 
-- Инкапсулировать всё, что связано с:
-  - HTTP‑запросами через **экземпляры прикладных API‑клиентов** в `app/src/api/clients/**`, собранные на **общей реализации** из `app/src/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 `app/src/api/clients/**`, built on the **shared implementation** from `app/src/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
 
-- Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
-  - отдельный каталог в `app/src/api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
-- Внутри модуля:
-  - файлы с вызовами API (`index.ts` или `*.service.ts`);
-  - файлы мапперов (`*responseMappers.ts`);
-  - специфичные типы запросов/ответов (если не вынесены в `app/src/types/**` с экспортом через barrel `@/types`).
-  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `app/src/api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `app/src/api/index.ts` (`import … from '@/api'`, **`public-imports.mdc`**).
+- For each domain area (for example, orders, billing, account settings):
+  - a separate directory in `app/src/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 `app/src/types/**` with export through the `@/types` barrel).
+  - when needed — local `index.ts` / barrel inside the module for structure **within** `app/src/api/**`; **outside** this layer UI, store, and other code import only from the root barrel `app/src/api/index.ts` (`import … from '@/api'`, **`public-imports.mdc`**).
 
-# Мапперы и типы
+# Mappers and types
 
-- Для каждого запроса/эндпоинта:
-  - описывать **response‑тип (DTO)**, точно соответствующий контракту backend;
-  - определять **целевой доменный тип** в `app/src/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 `app/src/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` (как у прикладного клиента) допустимы во thunk при разборе `catch`/payload, если так выстроен сервис (см. `store-rtk.mdc`, `http-client.mdc`).
-- При использовании API‑сервисов в UI, store и утилитах **вне** `app/src/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 thunks when parsing `catch`/payload, if the service is structured that way (see `store-rtk.mdc`, `http-client.mdc`).
+- When using API services in UI, store, and utilities **outside** `app/src/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/next/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: app/src/ui/**/*.tsx,app/src/ui/**/*.ts
 alwaysApply: false
 ---
 
 # UI layer boundaries (slim)
 
-- **Импорты:** `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums`, API — только `from '@/api'` (`public-imports.mdc`).
-- **Запрещено:** прямой HTTP‑клиент; знание DTO — только доменные типы.
-- **Состояние:** сценарии с записью и координация шагов — через store/thunk; узкие прямые вызовы `@/api` для чтения — только как в соседних фичах.
-- **Организация:** алиас `@/`; без deep‑импортов в чужие фичи; только public API.
-- **Barrel:** при новых публичных символах — реэкспорт по `layer-barrel-exports.mdc` (правило грузится на `index.ts`).
+- **Imports:** `@/ui/**`, `@/store/**`, types from `@/types` and enums from `@/types/enums`, API — only `from '@/api'` (`public-imports.mdc`).
+- **Forbidden:** direct HTTP client; DTO knowledge — domain types only.
+- **State:** write scenarios and multi-step coordination — via store/thunk; narrow direct `@/api` reads — only as in neighboring features.
+- **Organization:** `@/` alias; no deep imports into other features; public API only.
+- **Barrel:** for new public symbols — re-export per `layer-barrel-exports.mdc` (rule loads on `index.ts`).
 
-Полная карта слоёв (store, API, порты‑адаптеры): **`architecture-boundaries.mdc`** — при правках `app/src/api`, `store`, `types`, `lib`.
+Full layer map (store, API, ports/adapters): **`architecture-boundaries.mdc`** — when editing `app/src/api`, `store`, `types`, `lib`.

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

@@ -1,69 +1,69 @@
 ---
-description: Архитектурные границы и правила импортов
+description: Architectural boundaries and import rules
 globs: app/src/api/**/*,app/src/store/**/*,app/src/types/**/*,app/src/lib/**/*
 alwaysApply: false
 impact: CRITICAL
 ---
 
-# Границы между слоями
+# Layer boundaries
 
 - **UI (app/src/ui/**)**:
-  - Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `public-imports.mdc`**), контракт к API — **только** `import … from '@/api'` (**`public-imports.mdc`**).
-  - Не должен:
-    - обращаться к HTTP‑клиенту напрямую;
-    - знать детали DTO backend — только доменные типы.
+  - May import: `@/ui/**`, `@/store/**`, types from `@/types` and enums from `@/types/enums` (**only as in `public-imports.mdc`**), API contract — **only** `import … from '@/api'` (**`public-imports.mdc`**).
+  - Must not:
+    - call the HTTP client directly;
+    - know backend DTO details — only domain types.
 - **Store (app/src/store/**)**:
-  - Может импортировать: `@/store/**`, сервисы и публичные сущности API — **только** из `@/api` (**`public-imports.mdc`**), типы из `@/types` и enum из `@/types/enums` (**`public-imports.mdc`**).
-  - Не должен:
-    - зависеть от конкретных UI‑компонентов;
-    - напрямую работать с global/window API.
-  - Вызовы к backend — только через сервисы, импортируемые из `@/api`; **транспортные** типы ответа и ошибки (из `@/types`, в том же виде, что у прикладного HTTP‑клиента) во thunk допустимы, если так выстроен API‑слой (`http-client.mdc`, `store-rtk.mdc`).
-- **API (`app/src/api/**`)** — реализация в `services/**`, `clients/**`, реэкспорт в `app/src/api/index.ts`:
-  - Внутри слоя: типы из `@/types` и enum из `@/types/enums` (**`public-imports.mdc`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`http-client.mdc`, `api-services.mdc`).
-  - Не должен:
-    - тянуть в себя UI или store;
-    - смешивать HTTP‑слой и доменный слой — использовать мапперы.
+  - May import: `@/store/**`, services and public API entities — **only** from `@/api` (**`public-imports.mdc`**), types from `@/types` and enums from `@/types/enums` (**`public-imports.mdc`**).
+  - Must not:
+    - depend on specific UI components;
+    - work with global/window API directly.
+  - Backend calls — only through services imported from `@/api`; **transport** response and error types (from `@/types`, same shape as the application HTTP client) in thunks are acceptable if the API layer is structured that way (`http-client.mdc`, `store-rtk.mdc`).
+- **API (`app/src/api/**`)** — implementation in `services/**`, `clients/**`, re-export in `app/src/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 и обращение к API (`@/api`)
+## UI and API access (`@/api`)
 
-- По умолчанию сценарии с **изменением серверного состояния** и координация нескольких шагов — через **store** (`createAsyncThunk`, dispatch, паттерн фичи в репозитории).
-- Прямой вызов методов сервисов, импортированных из **`@/api`**, из UI допустим только в **узких случаях**: преимущественно **чтение** или действие **без необходимости держать результат в Redux**; те же **доменные типы**, что использовал бы thunk; **не** дублировать уже существующий сценарий из store и **не** протаскивать DTO в компоненты.
-- Предпочтительно оформлять такие вызовы так же, как в **соседних фичах** репозитория (хук‑фасад, отдельный хук и т.д.).
+- By default, scenarios that **change server state** and coordinate multiple steps go through **store** (`createAsyncThunk`, dispatch, feature pattern in the repository).
+- Direct calls to service methods imported from **`@/api`** from UI are allowed only in **narrow cases**: mainly **reads** or actions **without needing the result in Redux**; same **domain types** a thunk 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 (hook facade, dedicated hook, etc.).
 
-## Порты и адаптеры (краткая карта)
+## Ports and adapters (short map)
 
-- **Входящий адаптер**: UI — ввод пользователя, отображение; зависит от store и доменных типов, не от транспорта.
-- **Оркестрация сценариев**: store (slices, thunk) — вызывает сервисы, кладёт в state **доменные** модели после маппинга.
-- **Исходящий порт (контракт к backend)**: публичный API **`@/api`** (barrel `app/src/api/index.ts`; реализация — в `app/src/api/services/**` и т.д., см. `public-imports.mdc`).
-- **Исходящий адаптер**: общая реализация HTTP в **`app/src/lib/clients/**`** и экземпляры в **`app/src/api/clients/**`**.
+- **Inbound adapter**: UI — user input, display; depends on store and domain types, not transport.
+- **Scenario orchestration**: store (slices, thunk) — calls services, puts **domain** models in state after mapping.
+- **Outbound port (backend contract)**: public API **`@/api`** (barrel `app/src/api/index.ts`; implementation — in `app/src/api/services/**`, etc., see `public-imports.mdc`).
+- **Outbound adapter**: shared HTTP implementation in **`app/src/lib/clients/**`** and instances in **`app/src/api/clients/**`**.
 
-## Фича как срез
+## Feature as a slice
 
-- Для сложной фичи выравниваются имена и термины (**единый язык** предметной области) в типах, селекторах, сервисах и UI; структура папок — как в соседних фичах репозитория.
+- For a complex feature, align names and terms (**ubiquitous language** of the domain) in types, selectors, services, and UI; folder structure — as in neighboring features in the repository.
 
-# Правила импортов
+# Import rules
 
-- Всегда использовать алиас `@/...` для импортов между слоями.
-- Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`layer-barrel-exports.mdc`** и `public-imports.mdc`; для API‑слоя снаружи `app/src/api/**` — **`public-imports.mdc`** (только `@/api`).
-- При добавлении нового кода проверять:
-  - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
+- Always use the `@/...` alias for cross-layer imports.
+- Within one module/feature, relative imports are OK, but **without climbing above the feature root** (avoid `../../../`).
+- When components, hooks, 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 `app/src/api/**` — **`public-imports.mdc`** (only `@/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
 
-- Для сложных фич (например, `OrderCheckout`):
-  - Страница: `app/src/ui/pages/OrderCheckoutPage/**`.
-  - Локальные компоненты: поддиректории `components/**` внутри страницы.
-  - Связанный store: `app/src/store/slices/OrderCheckout/**`.
-  - API: `app/src/api/services/OrdersApi/OrderCheckout/**` (имя корневого сервиса взять из принятой в проекте схемы).
-  - Типы: `app/src/types/**` с экспортом через barrel **`app/src/types/index.ts`** (`public-imports.mdc`).
+- For complex features (for example, `OrderCheckout`):
+  - Page: `app/src/ui/pages/OrderCheckoutPage/**`.
+  - Local components: `components/**` subdirectories inside the page.
+  - Related store: `app/src/store/slices/OrderCheckout/**`.
+  - API: `app/src/api/services/OrdersApi/OrderCheckout/**` (root service name from the project scheme).
+  - Types: `app/src/types/**` with export through barrel **`app/src/types/index.ts`** (`public-imports.mdc`).
 
-# Требование к агенту
+# Agent requirement
 
-При добавлении новой функциональности:
-- Разместить файлы в **соответствующих слоях**.
-- Проверить существующие фичи с аналогичной структурой и **повторить их организацию**.
-- Не "коротить" слои (например, не вызывать API прямо из компонента только ради упрощения).
+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).
 ## Incorrect
 
 ```ts

package/presets/cursor/next/rules/arrow-functions.mdc

@@ -1,20 +1,20 @@
 ---
-description: Предпочитать стрелочные функции при написании кода
+description: Prefer arrow functions when writing code
 globs: app/src/**/*.{ts,tsx,js,jsx}
 alwaysApply: false
 impact: LOW
 ---
-# Стрелочные функции
+# Arrow functions
 
-Предпочитать стрелочный синтаксис для нового кода в `app/src/**`, где это допустимо в TypeScript/JavaScript.
+Prefer arrow syntax for new code in `app/src/**` where TypeScript/JavaScript allows it.
 
-**Style enforcement:** детальные pref — в ESLint (`app/eslint.config.mjs`) и Stylelint; после правок — **`post-change-lint`**. Это правило — краткий intent, не дублировать линтер.
+**Style enforcement:** detailed prefs live in ESLint (`app/eslint.config.mjs`) and Stylelint; after edits — **`post-change-lint`**. This rule is short intent — do not duplicate the linter.
 
-## Исключения
+## Exceptions
 
-- Генераторы (`function*`)
-- Методы класса, где нужен `this` прототипа
-- Редкие случаи hoisting / именованного `function` в стеке
+- Generators (`function*`)
+- Class methods that need prototype `this`
+- Rare hoisting / named `function` cases in the stack
 
 ## Incorrect
 

package/presets/cursor/next/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‑контролом проверять существующий UI‑код и пакеты проекта.
-- Public API: index/barrel‑файлы и явно экспортируемые сущности (`public-imports.mdc`, `layer-barrel-exports.mdc`).
-- Допустимые примеры: общий хук/утилита; типизация `any`/`unknown`; разделение крупного компонента; CSS‑токены вместо «магических» значений.
-- Lint/stylelint — только **`post-change-lint.mdc`**; ESLint config: `app/eslint.config.mjs`. Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) с кратким комментарием «зачем». Style prose in domain rules stays thin — prefer ESLint/Stylelint over duplicating formatter recipes.
+- Before adding a new UI control, check existing UI code and project packages.
+- Public API: index/barrel files and explicitly exported entities (`public-imports.mdc`, `layer-barrel-exports.mdc`).
+- Allowed examples: shared hook/utility; typing `any`/`unknown`; splitting a large component; CSS tokens instead of “magic” values.
+- Lint/stylelint — only **`post-change-lint.mdc`**; ESLint config: `app/eslint.config.mjs`. Disabling a rule (`eslint-disable`) — only **locally** (line/small block) with a short “why” comment. Style prose in domain rules stays thin — prefer ESLint/Stylelint over duplicating formatter recipes.

package/presets/cursor/next/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
 

package/presets/cursor/next/rules/css-property-order-stylelint.mdc

@@ -1,5 +1,5 @@
 ---
-description: Порядок CSS-свойств по Stylelint (idiomatic-order) — для любых стилей в проекте
+description: CSS property order per Stylelint (idiomatic-order) — for any styles in the project
 globs:
   - app/src/ui/**/*.styles.ts
   - app/src/ui/**/*.styles.tsx
@@ -9,8 +9,8 @@ globs:
 alwaysApply: false
 ---
 
-# Порядок CSS-свойств (как в Stylelint)
+# CSS property order (as in Stylelint)
 
-Для CSS в `.css`, `styles.ts(x)`, `styled` / Linaria — порядок свойств как в **`app/.stylelintrc`** (`@sh/stylelint-config-react` → `stylelint-config-idiomatic-order`).
+For CSS in `.css`, `styles.ts(x)`, `styled` / Linaria — property order matches **`app/.stylelintrc`** (`@sh/stylelint-config-react` → `stylelint-config-idiomatic-order`).
 
-Не дублировать список свойств вручную. Автоисправление из `app/`: **`yarn lint:css --fix`** (или менеджер пакетов репо). Полный прогон — **`post-change-lint.mdc`**.
+Do not duplicate the property list by hand. Auto-fix from `app/`: **`yarn lint:css --fix`** (or the repo package manager). Full gate — **`post-change-lint.mdc`**.