@bonesofspring/ai-rules 0.2.14 → 0.2.16

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

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

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

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

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

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

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.