@bonesofspring/ai-rules 0.2.14 → 0.2.16

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

@@ -1,69 +1,69 @@
 ---
-description: Redux Toolkit и состояние приложения
+description: Redux Toolkit and application state
 globs: app/src/store/**/*.ts
 alwaysApply: false
 impact: HIGH
 ---
 
-# Общие принципы
-
-- Использовать **Redux Toolkit**:
-  - `createSlice`, `createAsyncThunk`, RTK Query (если используется).
-- Хранить в store **доменные модели**, не "сырые" DTO из API.
-- Все вычисления и преобразования данных (включая вычисляемые поля, булевые флаги, агрегаты, человеко‑читаемые строки и т.п.) должны выполняться **между ответом API и записью в store** — в мапперах или отдельном слое подготовки данных. Store хранит уже подготовленную доменную модель.
-- Разделять:
-  - "серверное" состояние (данные из API) и
-  - локальное UI‑состояние (выбор/фильтры/флаги).
-
-# Структура слайсов
-
-- Каждый доменный модуль — свой слайс в `app/src/store/slices/**`.
-- Слайс экспортирует:
-  - `reducer` по умолчанию;
-  - `actions` именованным экспортом;
-  - селекторы `selectSomething(state: RootState): Type`.
-- Состояние:
-  - явный тип для state;
-  - аккуратная инициализация initialState.
-
-# Асинхронность и сайд‑эффекты
-
-- Асинхронные запросы:
-  - через `createAsyncThunk` или RTK Query.
-  - внутри thunk:
-    - вызывать API через сервисы, импортированные из `@/api` (**`public-imports.mdc`**);
-    - не вызывать HTTP‑клиент напрямую — только через эти сервисы.
-- Сайд‑эффекты (логирование, аналитика, работа с файлами):
-  - выносить в middleware (`app/src/store/middleware/**`) или специализированные слайсы.
-
-# Типизация
-
-- Использовать `RootState`, `AppDispatch` и типизированные хуки `useAppDispatch`, `useAppSelector` (если есть).
-- **HTTP и ошибки API**:
-  - не импортировать типы **сторонних HTTP‑библиотек**, которых нет в актуальных зависимостях и существующих слайсах (ориентир — **`package.json`** и соседние файлы);
-  - когда сервис возвращает **обёртку ответа** прикладного клиента — использовать **соответствующий тип из `@/types`** (как в barrel и в аналогичных thunk’ах);
-  - при ошибках после вызова сервиса — опираться на **тот же класс/контракт ошибки транспорта**, что использует общий клиент (из `@/types`), и разбирать тело/статус **по полям текущей реализации**, а не по воображаемому API;
-  - в **`catch`** предпочитать **`instanceof`** на класс ошибки транспорта из `@/types` (если он есть в коде) вместо голого `as`, когда это выразимо без шума (см. `no-type-assertion-as-import-export.mdc`).
-- Для сущностей:
-  - доменные типы (включая вычисляемые поля) определять в `app/src/types/**`, экспортировать через barrel и импортировать в слайсы из `@/types` как **источник правды** для структуры данных (`public-imports.mdc`);
-  - избегать дублирования описаний сущностей в нескольких местах.
-- **Граница домена**: в **state** хранить доменные модели; тип **обёртки ответа клиента** допустим как тип **возвращаемого значения thunk** или промежуточно до маппинга — без дублирования DTO в полях state без нужды (согласовано с `api-services.mdc` и `http-client.mdc`).
-
-# Тестирование слайсов
-
-- Для важных слайсов:
-  - тестировать редюсеры (инициализация, основные переходы состояний).
-  - тестировать селекторы (включая edge cases).
-- Thunk‑и:
-  - по возможности покрывать тестами с моками API‑слоя.
-
-# Требование к агенту
-
-При изменении/создании слайса:
-- Не класть логику API внутрь редюсеров/компонентов.
-- Строго типизировать state и actions.
-- Использовать единый стиль именования actions и селекторов, как в существующих слайсах.
-- При работе с ошибками и ответами HTTP опираться на **`http-client.mdc`** и контракты из `@/types`, а не на типы внешних HTTP‑библиотек вне зависимостей проекта.
+# General principles
+
+- Use **Redux Toolkit**:
+  - `createSlice`, `createAsyncThunk`, RTK Query (if used).
+- Store **domain models**, not "raw" DTOs from the API.
+- All data computations and transformations (including computed fields, boolean flags, aggregates, human-readable strings, etc.) must happen **between the API response and writing to store** — in mappers or a separate data-preparation layer. Store holds the prepared domain model.
+- Separate:
+  - "server" state (data from API) and
+  - local UI state (selection/filters/flags).
+
+# Slice structure
+
+- Each domain module — its own slice in `app/src/store/slices/**`.
+- A slice exports:
+  - default `reducer`;
+  - `actions` as named exports;
+  - selectors `selectSomething(state: RootState): Type`.
+- State:
+  - explicit state type;
+  - careful `initialState` initialization.
+
+# Async and side effects
+
+- Async requests:
+  - via `createAsyncThunk` or RTK Query.
+  - inside thunks:
+    - call API through services imported from `@/api` (**`public-imports.mdc`**);
+    - do not call the HTTP client directly — only through those services.
+- Side effects (logging, analytics, file handling):
+  - move to middleware (`app/src/store/middleware/**`) or specialized slices.
+
+# Typing
+
+- Use `RootState`, `AppDispatch`, and typed hooks `useAppDispatch`, `useAppSelector` (if present).
+- **HTTP and API errors**:
+  - do not import types from **third-party HTTP libraries** that are not in current dependencies and existing slices (guide — **`package.json`** and neighboring files);
+  - when a service returns the application client's **response wrapper** — use the **matching type from `@/types`** (as in the barrel and similar thunks);
+  - on errors after a service call — rely on the **same transport error class/contract** the shared client uses (from `@/types`), and parse body/status **by fields of the current implementation**, not an imagined API;
+  - in **`catch`**, prefer **`instanceof`** on the transport error class from `@/types` (if present in code) over bare `as`, when expressible without noise (see `no-type-assertion-as-import-export.mdc`).
+- For entities:
+  - define domain types (including computed fields) in `app/src/types/**`, export through barrel, import in slices from `@/types` as **source of truth** for data shape (`public-imports.mdc`);
+  - avoid duplicating entity descriptions in multiple places.
+- **Domain boundary**: in **state**, store domain models; the client **response wrapper** type is acceptable as a thunk **return type** or interim before mapping — without duplicating DTOs in state fields unnecessarily (aligned with `api-services.mdc` and `http-client.mdc`).
+
+# Slice testing
+
+- For important slices:
+  - test reducers (initialization, main state transitions).
+  - test selectors (including edge cases).
+- Thunks:
+  - cover with tests and API-layer mocks when possible.
+
+# Agent requirement
+
+When changing/creating a slice:
+- Do not put API logic inside reducers/components.
+- Strictly type state and actions.
+- Use a consistent naming style for actions and selectors, as in existing slices.
+- For HTTP errors and responses, rely on **`http-client.mdc`** and contracts from `@/types`, not external HTTP library types outside project dependencies.
 ## Incorrect
 
 ```ts

package/presets/cursor/next/rules/technical-retro.mdc

@@ -1,16 +1,16 @@
 ---
-description: Роль агента для проведения технического ретроспективы (retro) команды / спринта. On-demand — предпочтительнее slash-команда /technical-retro.
+description: Agent role for running a technical retrospective (retro) for a team / sprint. On-demand — prefer the /technical-retro slash command.
 alwaysApply: false
 ---
 
 <!-- shared-core: review/technical-retro.md -->
 
-# Техническое ретро — rule alias
+# Technical retro — rule alias
 
-Полный сценарий (включая блок **«Работа агентов»** для slug из team tasks) — в slash-команде:
+Full scenario (including the **“Agent work”** block for a slug from team tasks) lives in the slash command:
 
 **`commands/technical-retro.md`** → `/technical-retro`
 
 When a task has `metrics.json`, use the local aggregation script and state the cohort, sample size, incomplete artifacts, attribution confidence, active attempt duration, and human-gate wait separately. Do not score malformed artifacts or gate wait as agent work.
 
-Используй rule только если command недоступен. Не дублируй содержимое command в ответе — следуй command-файлу и skill `technical-retro`.
+Use this rule only if the command is unavailable. Do not duplicate the command contents in the response — follow the command file and skill `technical-retro`.

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

@@ -1,51 +1,51 @@
 ---
-description: Структура e2e тестов и планов (Playwright)
+description: E2E test and plan structure (Playwright)
 globs: app/__tests__/e2e/**/*
 alwaysApply: false
 ---
 
-# Структура e2e в проекте
-
-- Папка e2e: `app/__tests__/e2e/**`.
-- Планы сценариев:
-  - `*.cases.md` файлы — **канонический источник сценариев**.
-- Тесты:
-  - `*.spec.ts` файлы — реализация сценариев на Playwright.
-- Общие утилиты и абстракции:
-  - `app/__tests__/e2e/_shared/**` — константы, fluent‑интерфейсы, хелперы.
-
-# Принципы
-
-- Каждый сценарий из `*.cases.md` должен иметь соответствующий тест (или набор тестов).
-- **Нельзя** ослаблять проверки в тестах, если это противоречит бизнес‑ожиданиям из планов.
-- Предпочтительно использовать:
-  - page‑objects (например, `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: `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.

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

@@ -1,5 +1,5 @@
 ---
-description: Unit и интеграционные тесты (Testing Library и runner проекта)
+description: Unit and integration tests (Testing Library and project runner)
 globs:
   - app/src/**/*.spec.{ts,tsx}
   - app/src/**/*.test.{ts,tsx}
@@ -7,72 +7,71 @@ alwaysApply: false
 impact: MEDIUM
 ---
 
-# Общие правила тестирования
-
-- **Имена файлов:** для **новых** тестов использовать суффикс **`*.spec.ts` / `*.spec.tsx`**. Существующие **`*.test.ts` / `*.test.tsx`** не переименовывать без отдельной задачи (легаси).
-- **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@testing-library/react**.
-- Основная цель тестов:
-  - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
-- **Именование unit‑тестов** (строки в `describe` / `it` / `test`):
-  - формулировки **только на русском языке** — понятные бизнес‑фразы (что проверяется и какой ожидается результат);
-  - **каждое предложение** в названии **начинается с заглавной буквы** (в том числе после `.`, `!`, `?` и при нескольких предложениях в одной строке); первая буква всей строки — тоже заглавная.
-  - **Проверка в CI:** ESLint (`jest/valid-title` в `app/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.tsx`** 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 — **@testing-library/react**.
+- 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 `app/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):
 
-# Тесты компонентов
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+- `it('Returns empty list when user is guest', () => {})`
 
-- Использовать `render` из `@testing-library/react`.
-- Ассерты:
-  - матчеры DOM для Testing Library, как подключены в проекте (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
-- Взаимодействия:
-  - `userEvent` из `@testing-library/user-event`.
+# Component tests
 
-# Изоляция и моки
+- Use `render` from `@testing-library/react`.
+- Assertions:
+  - DOM matchers for Testing Library as wired in the project (`toBeInTheDocument`, `toHaveTextContent`, etc.).
+- Interactions:
+  - `userEvent` from `@testing-library/user-event`.
 
-- Для работы с API/store:
-  - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
-- Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
+# Isolation and mocks
 
-# 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‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `app/src/lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
-- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
+# HTTP client
 
-# Мапперы и преобразование данных
+- 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 `app/src/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.
 
-- Функции маппинга данных (DTO -> доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
-- В тестах мапперов особое внимание уделять edge‑кейсам и регрессии бизнес‑правил (например, граничные значения, отсутствие полей, неожиданные комбинации значений).
+# Mappers and data transformation
 
-# Требование к агенту
+- 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).
 
-При добавлении тестов:
-- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
-- Добавлять тесты для критичных веток логики и edge‑кейсов.
- - При работе с данными:
-   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
-   - по возможности опираться на данные и обработчики из `app/src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
- - Размещение:
-   - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.tsx`.
-   - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
-   - **новые** файлы — `*.spec.ts` / `*.spec.tsx` (см. блок «Имена файлов» выше).
+# 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 `app/src/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.tsx`.
+   - 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.tsx` (see "File names" above).
 ## Incorrect
 
 ```ts
 it('returns empty list when guest', () => {})
-it('Возвращает пустой список. пользователь не авторизован', () => {})
 ```
 
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+
 ## Correct
 
-```ts
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-```
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->

package/presets/cursor/next/rules/types-jsdoc.mdc

@@ -1,42 +1,49 @@
 ---
-description: Стиль JSDoc для доменных и транспортных типов в app/src/types
+description: JSDoc style for domain and transport types in app/src/types
 globs: app/src/types/**/*.ts
 alwaysApply: false
 ---
 
-# Документация типов в `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
 
-- Текст комментариев — **на русском**, кратко и по делу: что означает тип или поле в предметной области или в контракте с API.
-- **Не опираться** на теги в духе `@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`
 
-- Сразу **перед объявлением** — блок `/** … */`.
-- Если нужно пояснить источник данных, ограничения или неочевидности — **второй абзац** в том же блоке (в JSDoc для абзаца — пустая строка между строками текста).
-- Для **вложенных** объектов в том же файле каждый такой тип документируется отдельным блоком над своим объявлением.
+- 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
 
-- У **каждого** публичного свойства — **однострочный** `/** … */` на строке непосредственно **над** полем.
-- Если поле **не приходит с бэкенда «как есть»**, а вычисляется или дополняется на фронте (маппер, селектор, UI) — начать описание с префикса **`[computed]`** (как в `TUserProfile`, типах плана лечения).
-- Для форматов данных указывать это **в тексте**: например дата `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.
 
-## Классы и прочие объявления
+Example field comment (Russian locale — keep Cyrillic in type docs): <!-- i18n-keep: E5 -->
 
-- Для **классов** (например ошибки транспорта) при изменении публичного API — краткий блок над классом и **комментарии к публичным полям** по тем же правилам, что у свойств интерфейса.
+```ts
+/** Дата рождения в формате YYYY-MM-DD */ <!-- i18n-keep: E5 -->
+birthDate: string
+```
+
+## Classes and other declarations
+
+- 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.
 
 ## `enum`
 
-- В `enums.ts` исторически часто **без JSDoc** на каждом члене; для новых enum допустимо короткое описание **над самим enum**, если назначение неочевидно из имени. Подписи для UI — как принято, через объекты `*Names` рядом с 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
 
-- Добавляя новый тип или поле, **не оставлять** новые публичные поля без пояснения, если смысл не равен имени на 100%.
-- Правя файл, где уже есть такие комментарии, **поддерживать тот же стиль**, а не смешивать с англоязычными или «теговыми» блоками.
-- Не раздувать комментарии: одна-две фразы на тип, одна строка на поле — норма; исключение — действительно сложная доменная оговорка.
+- 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.
 
-См. также импорты и barrel: `public-imports.mdc`.
+See also imports and barrel: `public-imports.mdc`.

package/presets/cursor/next/skills/feature-delivery/SKILL.md

@@ -8,7 +8,7 @@ description: Delivers Next.js frontend features end-to-end across domain types,
 1. Read task brief, acceptance criteria, and decomposition if present.
 2. Read **`feature-delivery-workflow.mdc`** and **`reference-features.mdc`** — follow layer order and mirror closest reference feature.
 3. Add or update focused tests for changed behavior.
-4. Validation from `app/`: **invoke** **`post-change-lint.mdc`** after code edits (requestable, not always-on — but mandatory when code changed). Pipeline: scoped lint OK if next step is `build-verifier`.
+4. Validation from `app/`: **invoke** **`post-change-lint.mdc`** after code edits (requestable, not always-on — but **must** when code changed). Pipeline: scoped lint OK if next step is `build-verifier`.
 
 ## Scope discipline
 

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

@@ -1,6 +1,6 @@
 # Agent team artifacts
 
-Каталог артефактов пайплайна «команда агентов» Cursor.
+Artifact directory for the Cursor “agent team” pipeline.
 
 ## Layout
 
@@ -97,7 +97,7 @@ Prefer **`executing`** for pipeline mode. Legacy: `analysis`, `development`, `re
 ## Workflow entry
 
 ```bash
-/task <описание задачи>
+/task <task description>
 /task-continue <slug>
 /technical-retro <slug>
 ```

package/presets/cursor/nuxt/AGENTS.md

@@ -1,6 +1,6 @@
 # Nuxt 3 stack — Cursor agent team
 
-Краткая точка входа для Cursor. Подробные правила — `.cursor/rules/*.mdc`; сценарии — `.cursor/skills/**`.
+Short Cursor entry point. Detailed rules — `.cursor/rules/*.mdc`; scenarios — `.cursor/skills/**`.
 
 **Repo-root agents:** see [`AGENTS.md`](../../AGENTS.md) at the project root (cross-tool setup, commands, security, living conventions pointers).
 
@@ -8,23 +8,23 @@ See `.cursor/rules/README.md` for the full catalog and loading strategy.
 
 ## Quick start
 
-| Задача | Куда смотреть |
-|--------|----------------|
-| Любая новая work-задача | `/task` → `commands/task.md` + `agent-team-orchestrator.mdc` (+ `agent-team-intake.mdc` on-demand) |
-| Новая фича end-to-end | skill `feature-delivery` + `feature-delivery-workflow.mdc` |
-| Стек и слои | `nuxt-app-core.mdc` |
-| Эталонные фичи | `reference-features.mdc` (заполнить пути в репо) |
-| После правок кода | `post-change-lint.mdc` (**requestable**, но обязателен после edits; полный gate — `build-verifier`) |
+| Task | Where to look |
+|------|----------------|
+| Any new work task | `/task` → `commands/task.md` + `agent-team-orchestrator.mdc` (+ `agent-team-intake.mdc` on-demand) |
+| New end-to-end feature | skill `feature-delivery` + `feature-delivery-workflow.mdc` |
+| Stack and layers | `nuxt-app-core.mdc` |
+| Reference features | `reference-features.mdc` (fill in repo paths) |
+| After code edits | `post-change-lint.mdc` (**requestable**, but required after edits; full gate — `build-verifier`) |
 | Code review MR | skill `code-review` + `code-review-mr.mdc` |
 | Security (auth/forms/env) | `security-nuxt.mdc` + agent `security-reviewer` |
-| Валидация перед review | agent `build-verifier` |
-| Техническое ретро | `/technical-retro` + skill `technical-retro` |
+| Validation before review | agent `build-verifier` |
+| Technical retro | `/technical-retro` + skill `technical-retro` |
 
-## Когда использовать `/task`
+## When to use `/task`
 
-- Реализация, багфикс, миграция, тесты, ревью MR, CI-fix — **предпочтительно через `/task`**.
-- Простой one-liner без архитектурного риска — можно без pipeline, если пользователь явно просит.
-- Вопросы «как работает X» — agent `codebase-analyzer` (explain-as-is) или ответ без `/task`.
+- Implementation, bugfix, migration, tests, MR review, CI-fix — **prefer `/task`**.
+- Simple one-liner with no architecture risk — may skip the pipeline if the user explicitly asks.
+- “How does X work?” questions — agent `codebase-analyzer` (explain-as-is) or answer without `/task`.
 
 ## Pipeline routing
 
@@ -36,4 +36,4 @@ Intent detection, profiles (`full` / `standard` / `light`), and default steps
 npx @bonesofspring/ai-rules init cursor --preset nuxt
 ```
 
-Копирует rules, commands, agents, hooks, skills, team, `hooks.json`, `BUGBOT.md`, `AGENTS.md` → `.cursor/AGENTS.md`, `MCP.md`, `mcp.json` → `.cursor/mcp.json`, плюс `REPO_AGENTS.md` → корневой `AGENTS.md`. Skills: `write-adr`, `vue-performance` (on-demand).
+Copies rules, commands, agents, hooks, skills, team, `hooks.json`, `BUGBOT.md`, `AGENTS.md` → `.cursor/AGENTS.md`, `MCP.md`, `mcp.json` → `.cursor/mcp.json`, plus `REPO_AGENTS.md` → root `AGENTS.md`. Skills: `write-adr`, `vue-performance` (on-demand).