@bonesofspring/ai-rules 0.2.13 → 0.2.14

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

@@ -0,0 +1,97 @@
+---
+description: Архитектурные границы и правила импортов
+globs: api/**/*,stores/**/*,types/**/*,lib/**/*
+alwaysApply: false
+impact: CRITICAL
+---
+
+# Границы между слоями
+
+- **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 — только доменные типы.
+- **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/**` как канон).
+
+## Incorrect
+
+```ts
+// UI calling HTTP client / deep service path directly
+import { httpClient } from '@/lib/clients/HttpClient'
+import { fetchOrders } from '@/api/services/OrdersApi/orders.service'
+
+export const loadOrdersInPage = async () => {
+  // bypasses store and @/api barrel
+  await httpClient.get('/orders')
+}
+```
+
+## Correct
+
+```vue
+<script setup lang="ts">
+import { storeToRefs } from 'pinia'
+import { useOrdersStore } from '~/stores/orders'
+
+const ordersStore = useOrdersStore()
+const { orders } = storeToRefs(ordersStore)
+
+// UI → Pinia action → services from ~/api
+onMounted(() => {
+  void ordersStore.loadOrders()
+})
+</script>
+```

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

@@ -0,0 +1,51 @@
+---
+description: Поддержка и улучшение качества кода и архитектуры
+alwaysApply: true
+---
+
+<!-- shared-core: quality/code-quality-and-refactoring.md -->
+
+# Поддержка существующего стиля
+
+- Следовать существующим паттернам (имена, структура, типизация / DI / error handling); минимизировать стилистический шум (лишний format/rename).
+- Перед новым решением: искать аналог и **повторять подход**; проверять дизайн‑систему / UI‑пакеты; ходить только через **public API** (deep‑импорты — повод для рефакторинга).
+
+# Принципы
+
+- **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.
+
+# Рефакторинг при изменениях
+
+- Лёгкий refactor OK, если меньше дублирования, выше читаемость, без ломки публичных контрактов.
+- Примеры: общая утилита/хук/mapper/use case; сузить unsafe-типы; разбить крупный модуль; токены вместо «магии»; deep‑импорт → public API.
+- Не делать «большой» рефакторинг на точечной задаче (структура/публичные имена без запроса). Крупное — минимальными шагами; код остаётся собираемым.
+
+# Требование к агенту
+
+- **Boy scout:** оставлять модуль немного лучше; не жертвовать архитектурой и слоями ради краткости.
+
+## 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.
+- Refactor without tests → propose characterization test; if declined, label `UNTESTED`.
+- 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 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`) — только **точечно** с кратким комментарием «зачем».

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

@@ -0,0 +1,58 @@
+---
+description: Требования к code review агентами Cursor для merge requests
+alwaysApply: false
+---
+
+<!-- shared-core: review/code-review-mr.md -->
+
+# Code review merge requests
+
+On-demand rule for review flows. **Procedure and output format:** skill `code-review`.
+
+## When to load
+
+- User asks for review/MR/diff
+- Pipeline step `code-reviewer`
+- Platform automated review (e.g. BUGBOT) when present
+
+## Checklist references (abstract)
+
+- Architecture layers and stack core rules
+- Public imports / module boundaries
+- 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
+
+Concrete rule stems — in **Stack notes**.
+
+## Constraints
+
+- 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`).
+
+## Output contract
+
+Procedure details live in skill `code-review`. Required shape:
+
+- Each finding cites **`path:line`**, the problem, impact, and a concrete fix direction.
+- Rank by severity: **`blocker` | `important` | `nit`** (list blocker → nit).
+- Vague («looks risky») is not a finding — cite evidence or ask for surrounding file context.
+- End with a verdict on its own line: **`Safe to merge | needs changes | reject`**.
+
+## Stack notes
+
+On-demand rule for review flows. **Procedure and output format:** skill `code-review`.
+
+### Checklist references
+
+- Architecture layers: `architecture-boundaries.mdc`, `nuxt-app-core.mdc`; network: `http-client.mdc`
+- Imports: `public-imports.mdc`, `layer-barrel-exports.mdc`
+- UI: `vue-ui.mdc`
+- Security: `security-nuxt.mdc`
+- Tests: `tests-unit.mdc`, `playwright-agents.mdc`, `tests-e2e-structure.mdc`
+- Lint gate before final report: `post-change-lint.mdc`

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

@@ -0,0 +1,12 @@
+---
+description: CSS property order via Stylelint (Vue SFC styles included)
+globs: "**/*.{css,scss,vue}"
+alwaysApply: false
+---
+
+# CSS property order
+
+- Follow the repo Stylelint config (property order plugin if present).
+- Applies to plain CSS/SCSS and `<style>` blocks in `.vue` SFCs.
+- Do not hand-resort entire files unrelated to the task; fix order in touched rulesets.
+- Run via **`post-change-lint`** (`lint:css`).

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

@@ -0,0 +1,111 @@
+---
+description: Design smells (Fowler) and curated GoF patterns for agents. Load when assessing structure, smells, or pattern fit.
+globs:
+  - **/*.{ts,tsx}
+alwaysApply: false
+---
+
+<!-- shared-core: quality/design-guidance.md -->
+
+# Design guidance (smells & patterns)
+
+Словарь **code smells** (Fowler) и **design patterns** (GoF) для агентов при implement / review / debug.
+
+Применять только в scope задачи или MR. Лёгкий refactor — да; «большой» rewrite без явного запроса — нет.
+
+Называть паттерн **только если** репозиторий уже так делает или это минимальный match. Иначе — extract/split/move без ярлыка GoF.
+
+Не заменяет always-on Principles в `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; не расширять задачу ради каталога.
+
+Агенты и skills подгружают stem по one-liner wiring — не копировать этот каталог в промпт агента.
+
+## 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», если поведение уже корректно и читаемо.
+
+## Code smells (Fowler, curated ≤12)
+
+Таблица: smell → detect hint → fix hint (одна линия каждый). Без механических меню рефакторинга.
+
+| # | 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 внутри уже правильного модуля.
+
+## Design patterns (GoF, curated ≤8)
+
+Suggest only when repo already uses the shape or the match is minimal. Prefer extract-function over naming Strategy ради ярлыка.
+
+Паттерны ниже — **разрешённый минимум** для агентов; остальной GoF по умолчанию в Skip.
+
+| 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 на плоский список без иерархии |
+
+Если сомневаешься между двумя паттернами — выбери более простой extract/compose без имени; ярлык можно добавить на review, если репо уже так говорит.
+
+## 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 |
+
+Не вводить второй stem (`refactoring-smells` / `design-patterns-for-agents`) — один каталог: `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.
+
+## Cross-refs
+
+- Always-on Principles: `code-quality-and-refactoring`.
+- DIP / ports vs adapters: stack `architecture-boundaries` (детали стека — в 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).
+
+## Stack notes
+
+- Prefer hooks/mappers over HOC or new pattern names when the repo already extracts that way.
+- Suggest Strategy/Adapter only when ports or policy branching already exist in `**`.

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

@@ -0,0 +1,83 @@
+---
+description: Сквозной чеклист новой фичи и матрица «слой → правило Cursor». Use when implementing features via feature-developer or feature-delivery skill.
+alwaysApply: false
+---
+
+<!-- shared-core: architecture/feature-delivery-workflow.md -->
+
+# Доставка фичи (сквозной порядок)
+
+## Stack notes
+
+Типичная фича с данными с backend и общим состоянием. Детали слоёв — `architecture-boundaries.mdc`, `nuxt-app-core.mdc`.
+
+## Чеклист (порядок работ)
+
+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`.
+
+## Поток данных (ориентир)
+
+```mermaid
+flowchart LR
+  subgraph transport [Транспорт]
+    HttpClient[HttpClient]
+  end
+  DTO[DTO] --> Mappers[Мапперы]
+  Mappers --> Domain[Доменные типы]
+  Domain --> Service[API сервис]
+  Service --> HttpClient
+  Service --> Action[Pinia action]
+  Action --> Store[Store]
+  Store --> UI[UI]
+```
+
+## Регистрация по слоям
+
+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`; мапперы и нетривиальная логика — обязательно.
+7. **E2E** — `tests/e2e/<Area>/<plan>.cases.md` + `*.spec.ts`.
+
+## Частичные сценарии
+
+| Задача | Минимум действий |
+|--------|------------------|
+| Только 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. |
+
+## Антипаттерны
+
+- 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/типов отражают предметную область фичи — не смешивать транспорт/фреймворк-термины в домен без нужды.
+- Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
+
+## Матрица: зона → правила
+
+| Зона | Правила |
+|------|---------|
+| `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` |
+| `components/**` | `vue-ui.mdc`, `no-v-bind-spread.mdc`, `public-imports.mdc` |
+| `types/**` | `public-imports.mdc`, `types-jsdoc.mdc`, `layer-barrel-exports.mdc` |
+| `tests/e2e/**` | `tests-e2e-structure.mdc`, `playwright-agents.mdc` |
+
+При добавлении или расширении фичи **пройти чеклист** и правила из таблицы для затронутых зон.

package/presets/cursor/nuxt/rules/http-client.mdc

@@ -0,0 +1,15 @@
+---
+description: HTTP client wrapper for Nuxt — $fetch/ofetch, one stack, error contracts
+globs: lib/clients/**/*.ts,api/clients/**/*.ts,api/**/*.ts
+alwaysApply: false
+---
+
+# HTTP client
+
+- One HTTP stack for the app: wrap **`$fetch` / ofetch** (or the client already used in `lib/clients/**`).
+- Do not mix ad-hoc `fetch`/`axios` in features if a shared client exists.
+- Services in `api/**` call the wrapper — UI/stores do not own transport.
+- Map responses to domain models in services/mappers before Pinia.
+- Errors: use project transport error types from `~/types` / `@/types`; narrow with `instanceof` when available.
+- Base URL / auth headers: from `runtimeConfig` / existing client factories — do not hardcode secrets.
+- Calling Nitro `/api/*` from the client is fine when that is the BFF pattern — still through services.

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

@@ -0,0 +1,74 @@
+---
+description: Двухуровневые barrel-экспорты для слоёв с регламентированным public API
+globs: **/index.ts
+alwaysApply: false
+impact: MEDIUM
+---
+
+# Barrel-экспорты слоёв с public API
+
+## Когда применять
+
+Для **любого слоя** (каталога, пакета, bounded context), у которого:
+
+- есть **корневой barrel** — единая точка импорта для внешних потребителей;
+- deep-импорты внутрь слоя **запрещены** снаружи (ESLint `no-restricted-imports`, правила `public-imports.mdc`).
+
+Примеры alias/entry point в разных проектах: `@/api`, `@/types`, `@/core`, `@/store`, `packages/foo`.
+
+## Два уровня barrel
+
+1. **Локальный** — `index.ts` модуля/фичи внутри слоя.
+2. **Корневой public API** — barrel слоя (например `src/<layer>/index.ts`).
+
+**Внутри** слоя — относительные импорты и пути между подмодулями. **Снаружи** — только корневой barrel и **явно разрешённые** вторичные entry points (если зафиксированы в правилах проекта, напр. `@/types/enums`).
+
+## Что реэкспортировать наружу
+
+Только символы, которые **должны быть доступны** потребителям слоя: публичные функции/сервисы/фасады, типы контракта, константы и helpers, нужные другим слоям или тестам.
+
+**Не реэкспортировать:** внутренние адаптеры, мапперы, детали транспорта, промежуточные объекты для сборки фасада внутри слоя.
+
+Группировка в корневом barrel — **по конвенции репозитория** (ориентир — соседние модули того же слоя).
+
+## Чеклист агента (обязателен)
+
+При добавлении или существенном расширении **модуля внутри регламентированного слоя**:
+
+1. Определить слой, его **корневой barrel** и доп. entry points (`public-imports.mdc`).
+2. Создать/обновить **локальный** `index.ts` — только публичные символы.
+3. Если в слое есть **фасад/агрегатор** (`*ApiService.ts`, `rootReducer`, …) — подключить модуль там.
+4. Добавить **реэкспорт** новых публичных символов в **корневой barrel** слоя.
+5. **Проверка:** grep по имени символа или пути `./<Module>` в корневом barrel; снаружи слоя нет deep-импортов.
+
+Модуль **не готов**, пока чеклист не пройден.
+
+## Как найти регламентированные слои в репозитории
+
+1. Правила `public-imports.mdc` в `.cursor/rules/`.
+2. ESLint `no-restricted-imports` — паттерны `@/<layer>/*` с исключением barrel.
+3. `architecture-boundaries.mdc`, README проекта.
+
+## В этом репозитории
+
+| Слой | Корневой barrel | Правило импортов |
+|------|-------------------|------------------|
+| 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`.
+## Incorrect
+
+```ts
+// api/index.ts — leaking internals
+export { mapCardResponse } from './services/CardsApi/cardResponseMappers'
+export { rawCardsClient } from './clients/rawCardsClient'
+```
+
+## Correct
+
+```ts
+// api/index.ts — public facade only
+export { cardsApi } from './services/CardsApi'
+```

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

@@ -0,0 +1,61 @@
+---
+description: Выбор API навигации по стеку проекта (Nuxt 3 vs Vue Router SPA)
+globs: pages/**/*,layouts/**/*,middleware/**/*,nuxt.config.*
+alwaysApply: false
+---
+
+# Навигация и роутинг: сначала стек проекта
+
+**При любой задаче, связанной с навигацией, переходами между страницами, URL, редиректами, хлебными крошками, защищёнными маршрутами или программной сменой маршрута** — перед предложением кода или импортов **нельзя** опираться на «типичный Vue SPA» по умолчанию. Нужно **явно свериться со стеком целевого репозитория** и использовать **один** согласованный с проектом механизм.
+
+## Зависимости: что проверить в первую очередь
+
+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 по умолчанию — смотреть раздел «Реализация в коде» ниже.
+
+2. **Монорепо / workspaces** — роутинг может жить не в корневом `package.json`. Открыть **`package.json` того workspace**, где лежат `pages/` и `nuxt.config.*`.
+
+3. **Факт установки** — при сомнениях смотреть lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) или `node_modules`: убедиться, что заявленный пакет реально установлен.
+
+## Реализация роутинга в проекте (код и структура)
+
+Перед предложением паттерна навигации **свериться с тем, как уже сделано в репозитории**:
+
+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.
+
+2. **Точки входа и обёртки**  
+   - Поиск по коду: **`navigateTo`**, **`<NuxtLink>`**, **`useRouter` / `useRoute`** (Nuxt auto-import), **`from 'vue-router'`**, **`createRouter`**, **`RouterLink`**.  
+   - Где объявлены маршруты (файловая структура Nuxt vs явный `routes` в SPA).
+
+3. **Общие абстракции проекта**  
+   - Обёртки над ссылками (`~/components/...`, Link из дизайн-системы), хелперы путей, константы роутов — **использовать их**, а не дублировать сырой API.
+
+4. **Соседние файлы фичи**  
+   - Новый код навигации — в том же стиле, что страницы/composables той же области (`navigateTo` / `<NuxtLink>` vs `vue-router` как в соседних импортах).
+
+## Как определить, что использовать (сводка)
+
+1. **Зависимости** — см. раздел выше; по ним задаётся допустимый набор пакетов.  
+2. **Структура** — Nuxt `pages/` vs Vue Router SPA по каталогам и конфигу.  
+3. **Фактический код** — какие импорты и обёртки уже доминируют в приложении.
+
+## Что использовать (краткая матрица)
+
+| Стек | Программная навигация / чтение пути | Ссылки |
+|------|-------------------------------------|--------|
+| **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>` |
+
+**Не делать:** подключать `react-router-dom` или `next/navigation` / `next/link` в Nuxt-проект; импортировать Next-хуки (`usePathname`, `useSearchParams` из `next/navigation`); смешивать ручной `createRouter` и Nuxt file routing без явной причины в кодовой базе.
+
+## Требование к агенту
+
+- Перед генерацией или ревью кода навигации **коротко зафиксировать вывод** (например: «зависимости: `nuxt`; в коде везде `<NuxtLink>` / `navigateTo` → используем то же») и следовать ему.  
+- **Обязательная проверка:** актуальные **`dependencies`** в `package.json` нужного workspace + **как в проекте уже реализованы** маршруты и импорты (поиск по репозиторию, соседние файлы). Не полагаться только на предположение по одному признаку (например, только на наличие папки `pages/`).  
+- Если стек неочевиден (гибрид) — **сверить lockfile / установленные пакеты** и **доминирующие импорты**, затем выбрать API.  
+- Для **этого** пресета базовый ориентир — **`nuxt-app-core.mdc`** + **`nuxt-pages-routing.mdc`**: Nuxt 3; предпочитать **`navigateTo`**, **`useRouter` / `useRoute`**, **`<NuxtLink>`**.

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

@@ -0,0 +1,16 @@
+---
+description: Навигация в UI-компонентах — краткий ориентир (полный аудит стека — navigation-router-stack.mdc)
+globs: pages/**/*,layouts/**/*,middleware/**/*,components/**/*
+alwaysApply: false
+---
+
+# Navigation in UI components
+
+Перед ссылками, программной навигацией или работой с URL в 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`).
+
+Полный аудит (дерево маршрутов, гибриды, lockfile): **`navigation-router-stack.mdc`** — при правках `pages/**`, `layouts/**`, `middleware/**`, `nuxt.config.*`.