@bonesofspring/ai-rules 0.2.14 → 0.2.15

package/presets/cursor/nuxt/rules/design-guidance.mdc

@@ -9,98 +9,98 @@ alwaysApply: false
 
 # Design guidance (smells & patterns)
 
-Словарь **code smells** (Fowler) и **design patterns** (GoF) для агентов при implement / review / debug.
+Glossary of **code smells** (Fowler) and **design patterns** (GoF) for agents during implement / review / debug.
 
-Применять только в scope задачи или MR. Лёгкий refactor — да; «большой» rewrite без явного запроса — нет.
+Apply only within the task or MR scope. Light refactor — yes; a “big” rewrite without an explicit request — no.
 
-Называть паттерн **только если** репозиторий уже так делает или это минимальный match. Иначе — extract/split/move без ярлыка GoF.
+Name a pattern **only if** the repository already does it that way or the match is minimal. Otherwise — extract/split/move without a GoF label.
 
-Не заменяет always-on Principles в `code-quality-and-refactoring` (KISS, DRY + Rule of Three, YAGNI, SOLID, CUPID, composition, Demeter).
+Does not replace always-on Principles in `code-quality-and-refactoring` (KISS, DRY + Rule of Three, YAGNI, SOLID, CUPID, composition, Demeter).
 
 ## When to load
 
-- **Feature delivery / implement** — оценка структуры модулей, границ и дублирования.
-- **Code review** — smells и pattern fit **в диффе MR**, не по всему репо.
-- **Debug** — root-cause похож на wrong abstraction, Feature Envy, Message Chains, Shotgun Surgery.
-- **Light refactor only** — улучшения в рамках boy-scout / MR scope; не расширять задачу ради каталога.
+- **Feature delivery / implement** — assess module structure, boundaries, and duplication.
+- **Code review** — smells and pattern fit **in the MR diff**, not across the whole repo.
+- **Debug** — root cause looks like wrong abstraction, Feature Envy, Message Chains, Shotgun Surgery.
+- **Light refactor only** — improvements within boy-scout / MR scope; do not expand the task for the catalog.
 
-Агенты и skills подгружают stem по one-liner wiring — не копировать этот каталог в промпт агента.
+Agents and skills load this stem via one-liner wiring — do not copy this catalog into the agent prompt.
 
 ## How to use (agent rules of thumb)
 
-1. Сначала сверить с Principles (always-on): проще ли решение, нет ли ранней абстракции, соблюдён ли public API.
-2. Затем отметить smells **в изменённых файлах** задачи/MR; предложить fix только если он укладывается в light refactor.
-3. Паттерн GoF — опциональный ярлык после того, как структура уже ясна; не начинать дизайн с выбора паттерна.
-4. Если smell и паттерн конфликтуют с границами слоёв стека — побеждают stack boundaries и existing repo patterns.
-5. Не требовать переименования «под GoF», если поведение уже корректно и читаемо.
+1. First check against Principles (always-on): is the solution simpler, is there no premature abstraction, is the public API respected.
+2. Then mark smells **in the changed files** of the task/MR; propose a fix only if it fits a light refactor.
+3. A GoF pattern is an optional label after the structure is already clear; do not start design by picking a pattern.
+4. If a smell or pattern conflicts with stack layer boundaries — stack boundaries and existing repo patterns win.
+5. Do not require renaming “for GoF” if behavior is already correct and readable.
 
 ## Code smells (Fowler, curated ≤12)
 
-Таблица: smell → detect hint → fix hint (одна линия каждый). Без механических меню рефакторинга.
+Table: smell → detect hint → fix hint (one line each). No mechanical refactoring menus.
 
 | # | Smell | Detect | Fix hint |
 |---|-------|--------|----------|
-| 1 | Duplicate Code | одинаковая логика в ≥2 местах | dedupe после Rule of Three |
-| 2 | Long Method / Long Module | единица делает слишком много | extract в рамках scope; без big rewrite |
-| 3 | Feature Envy | метод чаще трогает чужие данные, чем свои | сдвинуть логику к данным / public API |
-| 4 | Data Clumps | одни и те же группы аргументов кочуют вместе | сгруппировать в type / value object |
-| 5 | Primitive Obsession | сырые string/int вместо доменных понятий | typed ids / value objects при нужде домена |
-| 6 | Speculative Generality | неиспользуемые хуки, флаги, абстракции «на будущее» | удалить (YAGNI) |
-| 7 | Message Chains | цепочки `a.b.c.d` | Demeter; facade / public API модуля |
-| 8 | Middle Man | класс почти только прокидывает вызовы | убрать pass-through **или** оставить как boundary |
-| 9 | Divergent Change | один модуль меняется по разным причинам | split по поводам изменения |
-| 10 | Shotgun Surgery | одно смысловое изменение разъезжается по многим файлам | consolidate ответственность |
-| 11 | Inappropriate Intimacy | доступ к чужим internals / private деталям | только public API / ports / facades |
-| 12 | Refused Bequest / Parallel Inheritance | подтип игнорирует базу; зеркальные иерархии классов | composition; не плодить параллельные деревья |
-
-**Skip Fowler (не в core):** Lazy Class, Incomplete Library Class, Comments-as-smell dogma, полный каталог 70+, пошаговые recipe-меню.
-
-Приоритет при конфликте smells: Inappropriate Intimacy и Message Chains (границы модулей) > Duplicate Code (после Rule of Three) > Long Method внутри уже правильного модуля.
+| 1 | Duplicate Code | same logic in ≥2 places | dedupe after Rule of Three |
+| 2 | Long Method / Long Module | unit does too much | extract within scope; no big rewrite |
+| 3 | Feature Envy | method touches foreign data more than its own | move logic toward the data / public API |
+| 4 | Data Clumps | the same argument groups travel together | group into a type / value object |
+| 5 | Primitive Obsession | raw string/int instead of domain concepts | typed ids / value objects when the domain needs them |
+| 6 | Speculative Generality | unused hooks, flags, “for later” abstractions | remove (YAGNI) |
+| 7 | Message Chains | `a.b.c.d` chains | Demeter; facade / module public API |
+| 8 | Middle Man | class almost only forwards calls | remove pass-through **or** keep as a boundary |
+| 9 | Divergent Change | one module changes for different reasons | split by reasons to change |
+| 10 | Shotgun Surgery | one semantic change spreads across many files | consolidate responsibility |
+| 11 | Inappropriate Intimacy | access to foreign internals / private details | public API / ports / facades only |
+| 12 | Refused Bequest / Parallel Inheritance | subtype ignores base; mirrored class hierarchies | composition; do not grow parallel trees |
+
+**Skip Fowler (not in core):** Lazy Class, Incomplete Library Class, Comments-as-smell dogma, full 70+ catalog, step-by-step recipe menus.
+
+Smell conflict priority: Inappropriate Intimacy and Message Chains (module boundaries) > Duplicate Code (after Rule of Three) > Long Method inside an already correct module.
 
 ## Design patterns (GoF, curated ≤8)
 
-Suggest only when repo already uses the shape or the match is minimal. Prefer extract-function over naming Strategy ради ярлыка.
+Suggest only when repo already uses the shape or the match is minimal. Prefer extract-function over naming Strategy for the label alone.
 
-Паттерны ниже — **разрешённый минимум** для агентов; остальной GoF по умолчанию в Skip.
+Patterns below are the **allowed minimum** for agents; the rest of GoF is Skip by default.
 
 | Pattern | When to suggest | Anti-trigger |
 |---------|-----------------|--------------|
-| Strategy | взаимозаменяемые алгоритмы уже (или явно скоро) выбираются политикой | один алгоритм без ветвления политики |
-| Adapter | обернуть внешний / чужой API под локальный port | лишняя обёртка вокруг своего же API |
-| Facade | упростить multi-step subsystem за public API | facade превращается в god-object |
-| Factory Method | полиморфное создание уже принято в стиле репо | factory на каждый тривиальный `new` |
-| Decorator | аддитивное поведение без взрыва subclass-иерархий | decorator «для слоёв» без реальной нужды |
-| Observer | events / subscriptions уже есть в архитектуре | самодельный pub/sub без прецедента в репо |
-| Template Method | общий algorithm skeleton + вариативные hooks | наследование ради пары отличающихся строк |
-| Composite | дерево однородных узлов (UI/domain), как уже в репо | Composite на плоский список без иерархии |
+| Strategy | interchangeable algorithms already (or clearly soon) chosen by policy | one algorithm with no policy branching |
+| Adapter | wrap external / foreign API under a local port | extra wrapper around your own API |
+| Facade | simplify a multi-step subsystem behind a public API | facade turns into a god-object |
+| Factory Method | polymorphic creation already accepted in repo style | factory for every trivial `new` |
+| Decorator | additive behavior without exploding subclass hierarchies | decorator “for layers” with no real need |
+| Observer | events / subscriptions already exist in the architecture | homemade pub/sub with no repo precedent |
+| Template Method | shared algorithm skeleton + variable hooks | inheritance for a couple of differing lines |
+| Composite | tree of homogeneous nodes (UI/domain), as already in the repo | Composite on a flat list with no hierarchy |
 
-Если сомневаешься между двумя паттернами — выбери более простой extract/compose без имени; ярлык можно добавить на review, если репо уже так говорит.
+If unsure between two patterns — choose the simpler extract/compose without a name; the label may be added on review if the repo already speaks that way.
 
 ## Skip / avoid by default
 
 | Catalog | Skip |
 |---------|------|
 | GoF | Singleton, Abstract Factory, Flyweight, Memento, Interpreter, Visitor, Bridge, Prototype |
-| GoF (conditional) | Command, Chain of Responsibility, State — упоминать **только если** репо уже использует |
-| Fowler | всё сверх 12 smells выше |
-| DDD | Aggregates, bounded-context maps, event sourcing, CQRS — **не в core** |
-| DDD (pointer) | ubiquitous language anti-pattern — расширять в `feature-delivery-workflow`, не здесь |
-| GRASP | список Larman как отдельные правила — skip (перекрывается SOLID/CUPID) |
-| Clean Code dogma | жёсткие caps на строки функции / «ровно один assert» — skip |
+| GoF (conditional) | Command, Chain of Responsibility, State — mention **only if** the repo already uses them |
+| Fowler | everything beyond the 12 smells above |
+| DDD | Aggregates, bounded-context maps, event sourcing, CQRS — **not in core** |
+| DDD (pointer) | ubiquitous language anti-pattern — expand in `feature-delivery-workflow`, not here |
+| GRASP | Larman list as separate rules — skip (covered by SOLID/CUPID) |
+| Clean Code dogma | hard caps on function lines / “exactly one assert” — skip |
 
-Не вводить второй stem (`refactoring-smells` / `design-patterns-for-agents`) — один каталог: `design-guidance`.
+Do not introduce a second stem (`refactoring-smells` / `design-patterns-for-agents`) — one catalog: `design-guidance`.
 
 ## Out of scope for this stem
 
-- Полный GoF (23) и полный Fowler catalog.
-- Stack-specific рецепты (пути модулей, lint-команды) — только в **Stack notes** адаптера.
-- Security, a11y, perf — отдельные review-правила; здесь только структурные smells/patterns.
-- Четвёртое always-on правило — запрещено; этот stem только requestable / agent-load.
+- Full GoF (23) and full Fowler catalog.
+- Stack-specific recipes (module paths, lint commands) — only in the adapter **Stack notes**.
+- Security, a11y, perf — separate review rules; here only structural smells/patterns.
+- A fourth always-on rule — forbidden; this stem is requestable / agent-load only.
 
 ## Cross-refs
 
 - Always-on Principles: `code-quality-and-refactoring`.
-- DIP / ports vs adapters: stack `architecture-boundaries` (детали стека — в Stack notes адаптеров).
+- DIP / ports vs adapters: stack `architecture-boundaries` (stack details — in adapter Stack notes).
 - Ubiquitous language: `feature-delivery-workflow` (lineage).
 - MR checklist (smells in scope; pattern name only if repo uses it): `code-review-mr`.
 - Token / twin policy for authors: `preset-token-budget`, `preset-twin-sync` (meta, not consumer always-on).

package/presets/cursor/nuxt/rules/feature-delivery-workflow.mdc

@@ -1,78 +1,78 @@
 ---
-description: Сквозной чеклист новой фичи и матрица «слой → правило Cursor». Use when implementing features via feature-developer or feature-delivery skill.
+description: End-to-end checklist for a new feature and the “layer → Cursor rule” matrix. Use when implementing features via feature-developer or feature-delivery skill.
 alwaysApply: false
 ---
 
 <!-- shared-core: architecture/feature-delivery-workflow.md -->
 
-# Доставка фичи (сквозной порядок)
+# Feature delivery (end-to-end order)
 
 ## Stack notes
 
-Типичная фича с данными с backend и общим состоянием. Детали слоёв — `architecture-boundaries.mdc`, `nuxt-app-core.mdc`.
+Typical feature with backend data and shared state. Layer details — `architecture-boundaries.mdc`, `nuxt-app-core.mdc`.
 
-## Чеклист (порядок работ)
+## Checklist (work order)
 
-1. **Доменные типы** — `types/**`, экспорт через barrel (`public-imports.mdc`, **`layer-barrel-exports.mdc`**); JSDoc — `types-jsdoc.mdc`.
-2. **Контракт API** — DTO там, где принято; доменные типы в `@/types`.
-3. **Мапперы** — DTO → домен в `*responseMappers.ts` (`api-services.mdc`).
-4. **Сервисы** — клиенты `api/clients/**`, barrel `@/api` (`api-services.mdc`, `http-client.mdc`, **`layer-barrel-exports.mdc`**). Без `fetch` из UI/store.
-5. **Состояние** — `defineStore` / Pinia actions (`store-pinia.mdc`); actions → сервисы из `~/api` / `@/api`.
-6. **UI** — типы из `@/types`, без DTO (`vue-ui.mdc`, `architecture-boundaries-ui.mdc`, `no-v-bind-spread.mdc`).
-7. **Моки** — по схеме репо; регистрация в `mocks/handlers.ts` (см. ниже).
-8. **Тесты** — unit для мапперов (`tests-unit.mdc`); e2e по `*.cases.md` (`tests-e2e-structure.mdc`, `playwright-agents.mdc`).
-9. **Завершение** — **`post-change-lint.mdc`**: `lint:js` + `lint:css` + `typecheck`; менеджер — `package-manager.mdc`.
+1. **Domain types** — `types/**`, export via barrel (`public-imports.mdc`, **`layer-barrel-exports.mdc`**); JSDoc — `types-jsdoc.mdc`.
+2. **API contract** — DTOs where the repo uses them; domain types in `@/types`.
+3. **Mappers** — DTO → domain in `*responseMappers.ts` (`api-services.mdc`).
+4. **Services** — clients `api/clients/**`, barrel `@/api` (`api-services.mdc`, `http-client.mdc`, **`layer-barrel-exports.mdc`**). No `fetch` from UI/store.
+5. **State** — `defineStore` / Pinia actions (`store-pinia.mdc`); actions → services from `~/api` / `@/api`.
+6. **UI** — types from `@/types`, no DTOs (`vue-ui.mdc`, `architecture-boundaries-ui.mdc`, `no-v-bind-spread.mdc`).
+7. **Mocks** — per repo layout; register in `mocks/handlers.ts` (see below).
+8. **Tests** — unit for mappers (`tests-unit.mdc`); e2e from `*.cases.md` (`tests-e2e-structure.mdc`, `playwright-agents.mdc`).
+9. **Completion** — **`post-change-lint.mdc`**: `lint:js` + `lint:css` + `typecheck`; package manager — `package-manager.mdc`.
 
-## Поток данных (ориентир)
+## Data flow (orientation)
 
 ```mermaid
 flowchart LR
-  subgraph transport [Транспорт]
+  subgraph transport [Transport]
     HttpClient[HttpClient]
   end
-  DTO[DTO] --> Mappers[Мапперы]
-  Mappers --> Domain[Доменные типы]
-  Domain --> Service[API сервис]
+  DTO[DTO] --> Mappers[Mappers]
+  Mappers --> Domain[Domain types]
+  Domain --> Service[API service]
   Service --> HttpClient
   Service --> Action[Pinia action]
   Action --> Store[Store]
   Store --> UI[UI]
 ```
 
-## Регистрация по слоям
+## Registration by layer
 
-1. **Типы** — `types/**`; доменная модель — источник правды для UI и store.
-2. **API** — `api/services/<ServiceRoot>/<Segment>/`; публичные экспорты (в т.ч. **константы путей** для моков) → **`api/index.ts`**.
-3. **Моки (MSW)** — `mocks/data/<feature>/`; хендлеры в **`mocks/handlers.ts`**. Пути из `@/api`, не дублировать URL-строки. Проверить браузерный worker и Node `setupServer`, если оба используются.
-4. **Store** — `stores/<featureName>.ts` (`defineStore`); опционально composable‑фасад в `composables/**`. Регистрация через `@pinia/nuxt` / принятый в репо паттерн — **не** RTK `reducers.ts` / `middleware/**`.
-5. **UI** — `pages/**`, `components/pages/<FeatureName>Page/**` и/или `components/**`; данные через store / composables.
-6. **Unit** — `*.spec.ts`; мапперы и нетривиальная логика — обязательно.
+1. **Types** — `types/**`; domain model is the source of truth for UI and store.
+2. **API** — `api/services/<ServiceRoot>/<Segment>/`; public exports (incl. **path constants** for mocks) → **`api/index.ts`**.
+3. **Mocks (MSW)** — `mocks/data/<feature>/`; handlers in **`mocks/handlers.ts`**. Paths from `@/api`; do not duplicate URL strings. Check browser worker and Node `setupServer` if both are used.
+4. **Store** — `stores/<featureName>.ts` (`defineStore`); optional composable facade in `composables/**`. Registration via `@pinia/nuxt` / the repo’s accepted pattern — **not** RTK `reducers.ts` / `middleware/**`.
+5. **UI** — `pages/**`, `components/pages/<FeatureName>Page/**` and/or `components/**`; data via store / composables.
+6. **Unit** — `*.spec.ts`; mappers and non-trivial logic are required.
 7. **E2E** — `tests/e2e/<Area>/<plan>.cases.md` + `*.spec.ts`.
 
-## Частичные сценарии
+## Partial scenarios
 
-| Задача | Минимум действий |
-|--------|------------------|
-| Только API + типы | Типы, сервис, мапперы, `@/api` barrel; unit на маппер. |
-| Только моки | Путь в `@/api`; handlers + `mocks/handlers.ts`. |
-| Только store | Pinia actions на `@/api`; `stores/<feature>.ts`. |
-| Только UI | Store state; без HTTP/DTO. |
-| Только e2e | `*.cases.md` + spec; page object. |
+| Task | Minimum actions |
+|------|-----------------|
+| API + types only | Types, service, mappers, `@/api` barrel; unit for mapper. |
+| Mocks only | Path in `@/api`; handlers + `mocks/handlers.ts`. |
+| Store only | Pinia actions via `@/api`; `stores/<feature>.ts`. |
+| UI only | Store state; no HTTP/DTO. |
+| E2E only | `*.cases.md` + spec; page object. |
 
-## Антипаттерны
+## Anti-patterns
 
-- DTO в UI или нетипизированном store.
-- HTTP-клиент из компонента/Pinia action в обход сервиса.
-- Deep-import `@/api/services/**` из UI/store.
-- `{...props}` / `v-bind="$attrs"` spread без явного списка — `no-v-bind-spread.mdc`.
-- RTK / Redux (`createSlice`, `createAsyncThunk`, `stores/slices/**` как канон).
-- **Ubiquitous language:** имена Domain/типов отражают предметную область фичи — не смешивать транспорт/фреймворк-термины в домен без нужды.
+- DTO in UI or untyped store.
+- HTTP client from a component/Pinia action bypassing the service.
+- Deep-import `@/api/services/**` from UI/store.
+- `{...props}` / `v-bind="$attrs"` spread without an explicit list — `no-v-bind-spread.mdc`.
+- RTK / Redux (`createSlice`, `createAsyncThunk`, `stores/slices/**` as the canon).
+- **Ubiquitous language:** Domain/type names reflect the feature’s subject domain — do not mix transport/framework terms into the domain without need.
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
 
-## Матрица: зона → правила
+## Matrix: zone → rules
 
-| Зона | Правила |
-|------|---------|
+| Zone | Rules |
+|------|-------|
 | `api/clients/**`, `lib/clients/**` | `http-client.mdc`, `tests-unit.mdc` (behavior) |
 | `api/services/**` | `api-services.mdc`, `layer-barrel-exports.mdc`, `http-client.mdc` |
 | `stores/**` | `store-pinia.mdc`, `architecture-boundaries.mdc`, `public-imports.mdc` |
@@ -80,4 +80,4 @@ flowchart LR
 | `types/**` | `public-imports.mdc`, `types-jsdoc.mdc`, `layer-barrel-exports.mdc` |
 | `tests/e2e/**` | `tests-e2e-structure.mdc`, `playwright-agents.mdc` |
 
-При добавлении или расширении фичи **пройти чеклист** и правила из таблицы для затронутых зон.
+When adding or extending a feature, **walk the checklist** and the rules from the table for affected zones.

package/presets/cursor/nuxt/rules/layer-barrel-exports.mdc

@@ -1,63 +1,63 @@
 ---
-description: Двухуровневые barrel-экспорты для слоёв с регламентированным public API
+description: Two-level barrel exports for layers with a regulated public API
 globs: **/index.ts
 alwaysApply: false
 impact: MEDIUM
 ---
 
-# Barrel-экспорты слоёв с public API
+# Barrel exports for layers with a public API
 
-## Когда применять
+## When to apply
 
-Для **любого слоя** (каталога, пакета, bounded context), у которого:
+For **any layer** (directory, package, bounded context) that has:
 
-- есть **корневой barrel** — единая точка импорта для внешних потребителей;
-- deep-импорты внутрь слоя **запрещены** снаружи (ESLint `no-restricted-imports`, правила `public-imports.mdc`).
+- a **root barrel** — single import point for external consumers;
+- deep imports into the layer **forbidden** from outside (ESLint `no-restricted-imports`, `public-imports.mdc` rules).
 
-Примеры alias/entry point в разных проектах: `@/api`, `@/types`, `@/core`, `@/store`, `packages/foo`.
+Example alias/entry points across projects: `@/api`, `@/types`, `@/core`, `@/store`, `packages/foo`.
 
-## Два уровня barrel
+## Two barrel levels
 
-1. **Локальный** — `index.ts` модуля/фичи внутри слоя.
-2. **Корневой public API** — barrel слоя (например `src/<layer>/index.ts`).
+1. **Local** — `index.ts` of a module/feature inside the layer.
+2. **Root public API** — layer barrel (e.g. `src/<layer>/index.ts`).
 
-**Внутри** слоя — относительные импорты и пути между подмодулями. **Снаружи** — только корневой barrel и **явно разрешённые** вторичные entry points (если зафиксированы в правилах проекта, напр. `@/types/enums`).
+**Inside** the layer — relative imports and paths between submodules. **Outside** — only the root barrel and **explicitly allowed** secondary entry points (if fixed in project rules, e.g. `@/types/enums`).
 
-## Что реэкспортировать наружу
+## What to re-export outward
 
-Только символы, которые **должны быть доступны** потребителям слоя: публичные функции/сервисы/фасады, типы контракта, константы и helpers, нужные другим слоям или тестам.
+Only symbols that **must be available** to layer consumers: public functions/services/facades, contract types, constants and helpers needed by other layers or tests.
 
-**Не реэкспортировать:** внутренние адаптеры, мапперы, детали транспорта, промежуточные объекты для сборки фасада внутри слоя.
+**Do not re-export:** internal adapters, mappers, transport details, intermediate objects used to assemble a facade inside the layer.
 
-Группировка в корневом barrel — **по конвенции репозитория** (ориентир — соседние модули того же слоя).
+Grouping in the root barrel — **per repository convention** (orient on neighboring modules of the same layer).
 
-## Чеклист агента (обязателен)
+## Agent checklist (required)
 
-При добавлении или существенном расширении **модуля внутри регламентированного слоя**:
+When adding or substantially extending a **module inside a regulated layer**:
 
-1. Определить слой, его **корневой barrel** и доп. entry points (`public-imports.mdc`).
-2. Создать/обновить **локальный** `index.ts` — только публичные символы.
-3. Если в слое есть **фасад/агрегатор** (`*ApiService.ts`, `rootReducer`, …) — подключить модуль там.
-4. Добавить **реэкспорт** новых публичных символов в **корневой barrel** слоя.
-5. **Проверка:** grep по имени символа или пути `./<Module>` в корневом barrel; снаружи слоя нет deep-импортов.
+1. Identify the layer, its **root barrel**, and extra entry points (`public-imports.mdc`).
+2. Create/update the **local** `index.ts` — public symbols only.
+3. If the layer has a **facade/aggregator** (`*ApiService.ts`, `rootReducer`, …) — wire the module there.
+4. Add a **re-export** of new public symbols in the layer’s **root barrel**.
+5. **Verify:** grep for the symbol name or path `./<Module>` in the root barrel; no deep imports from outside the layer.
 
-Модуль **не готов**, пока чеклист не пройден.
+The module is **not ready** until the checklist passes.
 
-## Как найти регламентированные слои в репозитории
+## How to find regulated layers in the repository
 
-1. Правила `public-imports.mdc` в `.cursor/rules/`.
-2. ESLint `no-restricted-imports` — паттерны `@/<layer>/*` с исключением barrel.
-3. `architecture-boundaries.mdc`, README проекта.
+1. `public-imports.mdc` rules in `.cursor/rules/`.
+2. ESLint `no-restricted-imports` — `@/<layer>/*` patterns with barrel exception.
+3. `architecture-boundaries.mdc`, project README.
 
-## В этом репозитории
+## In this repository
 
-| Слой | Корневой barrel | Правило импортов |
-|------|-------------------|------------------|
+| Layer | Root barrel | Import rule |
+|-------|-------------|-------------|
 | API | `api/index.ts` | `public-imports.mdc` |
 | Types | `types/index.ts` | `public-imports.mdc` (+ `@/types/enums`) |
 | Core | `core/index.ts` | ESLint: `@/core/index` |
 
-Иллюстрация двух уровней (API): локальный `services/.../<Feature>/index.ts` → фасад `*ApiService.ts` → `api/index.ts`.
+Two-level illustration (API): local `services/.../<Feature>/index.ts` → facade `*ApiService.ts` → `api/index.ts`.
 ## Incorrect
 
 ```ts

package/presets/cursor/nuxt/rules/navigation-router-stack.mdc

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

package/presets/cursor/nuxt/rules/navigation-router-ui.mdc

@@ -1,16 +1,16 @@
 ---
-description: Навигация в UI-компонентах — краткий ориентир (полный аудит стека — navigation-router-stack.mdc)
+description: Navigation in UI components — short guide (full stack audit — navigation-router-stack.mdc)
 globs: pages/**/*,layouts/**/*,middleware/**/*,components/**/*
 alwaysApply: false
 ---
 
 # Navigation in UI components
 
-Перед ссылками, программной навигацией или работой с URL в UI:
+Before links, programmatic navigation, or URL work in UI:
 
-1. **`package.json`** workspace приложения — `nuxt` vs чистый `vue-router` SPA.
-2. **Соседние импорты** той же фичи (`navigateTo`, `<NuxtLink>`, `useRouter` / `useRoute` vs `from 'vue-router'`).
-3. **Обёртки проекта** (`~/components/...` Link) — предпочтительнее сырого API роутера.
-4. **По умолчанию (preset):** Nuxt 3 file-based routing → `navigateTo` + `<NuxtLink>` + `useRouter` / `useRoute` (`nuxt-app-core.mdc`, `nuxt-pages-routing.mdc`).
+1. **`package.json`** of the app workspace — `nuxt` vs plain `vue-router` SPA.
+2. **Neighboring imports** in the same feature (`navigateTo`, `<NuxtLink>`, `useRouter` / `useRoute` vs `from 'vue-router'`).
+3. **Project wrappers** (`~/components/...` Link) — preferred over raw router API.
+4. **Default (preset):** Nuxt 3 file-based routing → `navigateTo` + `<NuxtLink>` + `useRouter` / `useRoute` (`nuxt-app-core.mdc`, `nuxt-pages-routing.mdc`).
 
-Полный аудит (дерево маршрутов, гибриды, lockfile): **`navigation-router-stack.mdc`** — при правках `pages/**`, `layouts/**`, `middleware/**`, `nuxt.config.*`.
+Full audit (route tree, hybrids, lockfile): **`navigation-router-stack.mdc`** — when editing `pages/**`, `layouts/**`, `middleware/**`, `nuxt.config.*`.