@bonesofspring/ai-rules 0.1.35 → 0.1.36

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bonesofspring/ai-rules",
-  "version": "0.1.35",
+  "version": "0.1.36",
   "description": "Presets of Cursor and Claude rules/commands for Revy Ross personal use",
   "license": "MIT",
   "author": "Revy Ross",

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

@@ -25,17 +25,18 @@
 |------|------------|
 | `feature-delivery-workflow.mdc` | Сквозной порядок работ по фиче, mermaid‑поток, матрица слой → правило `.mdc` |
 | `next-app-core.mdc` | Стек, слои, порты‑адаптеры (кратко), доменная логика vs state, общие требования к агенту и линтам |
-| `architecture-boundaries.mdc` | Границы UI / store / API, импорты (`@/types` по `types-public-imports`), UI→services, порты‑адаптеры, фича как срез |
+| `architecture-boundaries.mdc` | Границы UI / store / API, импорты (`@/types`, `@/api`), порты‑адаптеры, фича как срез |
 | `http-client.mdc` | Один HTTP‑стек, контракты из `@/types`, без разбросанного низкоуровневого API |
 | `api-services.mdc` | Сервисы, мапперы, вызовы через прикладные API‑клиенты |
 | `store-rtk.mdc` | Redux Toolkit, thunk’и, типизация ошибок/ответов как в коде репо |
 | `types-public-imports.mdc` | Импорты только через barrel `@/types` |
+| `api-public-imports.mdc` | Импорты только через barrel `@/api` (вне `app/src/api/**`) |
 | `types-jsdoc.mdc` | JSDoc для типов в `app/src/types` (русский текст, `[computed]`, без `@param`/`@returns`) |
 | `no-type-assertion-as-import-export.mdc` | Ограничение `as`, в т.ч. `instanceof` для ошибок транспорта в `catch` |
 | `code-review-mr.mdc` | Чеклист ревью MR, в т.ч. HTTP‑клиент и тесты |
 | `tests-unit.mdc` | Unit‑тесты и behavior‑тесты HTTP‑клиента |
 | `playwright-agents.mdc`, `tests-e2e-structure.mdc` | E2E |
 
-**Коллизии формулировок:** если в разных `.mdc` расходятся детали **импорта типов**, источник правды — **`types-public-imports.mdc`** (`@/types`, `@/types/enums`).
+**Коллизии формулировок:** если в разных `.mdc` расходятся детали **импорта типов**, источник правды — **`types-public-imports.mdc`** (`@/types`, `@/types/enums`); по **импорту из API‑слоя** (store, UI, прочий код вне `app/src/api/**`) — **`api-public-imports.mdc`** (`@/api`), в том же смысле что правило ESLint `no-restricted-imports` в `app/eslint.config.mjs`.
 
 Задачи на **сеть, замену HTTP‑библиотеки, новые эндпоинты**: опираться на **`http-client.mdc`** + **`api-services.mdc`** + **`store-rtk.mdc`**.

package/presets/cursor/next/rules/api-public-imports.mdc

@@ -0,0 +1,27 @@
+---
+description: Импорт из API-слоя только через публичный barrel @/api
+alwaysApply: true
+---
+
+# Импорты из `@/api`
+
+- **Публичный API слоя API** — barrel `app/src/api/index.ts`. Для файлов **вне** `app/src/api/**` импортировать сервисы, клиенты, эндпоинты и публичные типы API **только** как `import … from '@/api'` (или `from '@/api/index'` при необходимости явного пути).
+- **Запрещено** для таких потребителей обходить barrel: любой импорт вида `@/api/<что‑угодно>`, кроме `@/api/index`. Это дублирует правило ESLint `no-restricted-imports` в `app/eslint.config.mjs` (паттерн `@/api/*` с исключением `@/api/index`).
+
+## Внутри слоя `app/src/api/**`
+
+- При реализации сервисов, клиентов и barrel допустимы **относительные** импорты и пути вида `@/api/services/**`, `@/api/clients/**` между файлами этого слоя. Это не относится к потребителям снаружи `app/src/api/**`.
+
+## Примеры
+
+```typescript
+// ✅ Допустимо в store, UI, lib вне app/src/api — только barrel
+import { MedcardApiService, MarketplaceApiService } from '@/api'
+import type { TReferenceRequest } from '@/api'
+
+// ❌ Запрещено снаружи app/src/api (сработает ESLint)
+import { MedcardApiService } from '@/api/services/MedcardApiService/MedcardApiService'
+import { MedcardApiClient } from '@/api/clients/MedcardApiClient'
+```
+
+При ревью и правках кода **не добавлять** новые импорты из `@/api/...` кроме `@/api` / `@/api/index` в файлах вне `app/src/api/**`.

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

@@ -23,7 +23,7 @@ alwaysApply: false
   - файлы с вызовами API (`index.ts` или `*.service.ts`);
   - файлы мапперов (`*responseMappers.ts`);
   - специфичные типы запросов/ответов (если не вынесены в `app/src/types/**` с экспортом через barrel `@/types`).
-  - один или несколько **public API** файлов (`index.ts` или barrel‑файлы), через которые к модулю обращаются UI, store и другие слои.
+  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `app/src/api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `app/src/api/index.ts` (`import … from '@/api'`, **`api-public-imports.mdc`**).
 
 # Мапперы и типы
 
@@ -53,5 +53,5 @@ alwaysApply: false
 - Не смешивать слой API и UI/store:
   - компоненты не должны зависеть от DTO;
   - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы во thunk при разборе `catch`/payload, если так выстроен сервис (см. `store-rtk.mdc`, `http-client.mdc`).
-- При использовании API‑сервисов в UI, store и утилитах импортировать только из public API файлов модуля (например, `@/api/services/OrdersApi/.../index`), а не из внутренних файлов‑реализаций.
+- При использовании API‑сервисов в UI, store и утилитах **вне** `app/src/api/**` импортировать **только** из `@/api` (корневой barrel), см. **`api-public-imports.mdc`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.
 

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

@@ -6,33 +6,33 @@ alwaysApply: true
 # Границы между слоями
 
 - **UI (app/src/ui/**)**:
-  - Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `types-public-imports.mdc`**), `@/api/services/**` только через **public API** модулей сервисов.
+  - Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `types-public-imports.mdc`**), контракт к API — **только** `import … from '@/api'` (**`api-public-imports.mdc`**).
   - Не должен:
     - обращаться к HTTP‑клиенту напрямую;
     - знать детали DTO backend — только доменные типы.
 - **Store (app/src/store/**)**:
-  - Может импортировать: `@/store/**`, `@/api/services/**` (public API), типы из `@/types` и enum из `@/types/enums` (**`types-public-imports.mdc`**).
+  - Может импортировать: `@/store/**`, сервисы и публичные сущности API — **только** из `@/api` (**`api-public-imports.mdc`**), типы из `@/types` и enum из `@/types/enums` (**`types-public-imports.mdc`**).
   - Не должен:
     - зависеть от конкретных UI‑компонентов;
     - напрямую работать с global/window API.
-  - Вызовы к backend — только через сервисы; **транспортные** типы ответа и ошибки (из `@/types`, в том же виде, что у прикладного HTTP‑клиента) во thunk допустимы, если так выстроен API‑слой (`http-client.mdc`, `store-rtk.mdc`).
-- **API (app/src/api/services/**)**:
-  - Может импортировать: типы из `@/types` и enum из `@/types/enums` (**`types-public-imports.mdc`**); **`@/api/clients/**`** — преднастроенные экземпляры HTTP‑клиента (`http-client.mdc`); общие утилиты проекта (как в соседних сервисах репозитория).
+  - Вызовы к backend — только через сервисы, импортируемые из `@/api`; **транспортные** типы ответа и ошибки (из `@/types`, в том же виде, что у прикладного HTTP‑клиента) во thunk допустимы, если так выстроен API‑слой (`http-client.mdc`, `store-rtk.mdc`).
+- **API (`app/src/api/**`)** — реализация в `services/**`, `clients/**`, реэкспорт в `app/src/api/index.ts`:
+  - Внутри слоя: типы из `@/types` и enum из `@/types/enums` (**`types-public-imports.mdc`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`http-client.mdc`, `api-services.mdc`).
   - Не должен:
     - тянуть в себя UI или store;
     - смешивать HTTP‑слой и доменный слой — использовать мапперы.
 
-## UI и обращение к `@/api/services`
+## UI и обращение к API (`@/api`)
 
 - По умолчанию сценарии с **изменением серверного состояния** и координация нескольких шагов — через **store** (`createAsyncThunk`, dispatch, паттерн фичи в репозитории).
-- Прямой вызов функций из **`@/api/services/**` из UI допустим только в **узких случаях**: преимущественно **чтение** или действие **без необходимости держать результат в Redux**; тот же **public API** сервиса и те же **доменные типы**, что использовал бы thunk; **не** дублировать уже существующий сценарий из store и **не** протаскивать DTO в компоненты.
+- Прямой вызов методов сервисов, импортированных из **`@/api`**, из UI допустим только в **узких случаях**: преимущественно **чтение** или действие **без необходимости держать результат в Redux**; те же **доменные типы**, что использовал бы thunk; **не** дублировать уже существующий сценарий из store и **не** протаскивать DTO в компоненты.
 - Предпочтительно оформлять такие вызовы так же, как в **соседних фичах** репозитория (хук‑фасад, отдельный хук и т.д.).
 
 ## Порты и адаптеры (краткая карта)
 
 - **Входящий адаптер**: UI — ввод пользователя, отображение; зависит от store и доменных типов, не от транспорта.
 - **Оркестрация сценариев**: store (slices, thunk) — вызывает сервисы, кладёт в state **доменные** модели после маппинга.
-- **Исходящий порт (контракт к backend)**: публичный API **`@/api/services/...`**.
+- **Исходящий порт (контракт к backend)**: публичный API **`@/api`** (barrel `app/src/api/index.ts`; реализация — в `app/src/api/services/**` и т.д., см. `api-public-imports.mdc`).
 - **Исходящий адаптер**: общая реализация HTTP в **`app/src/lib/clients/**`** и экземпляры в **`app/src/api/clients/**`**.
 
 ## Фича как срез
@@ -43,7 +43,7 @@ alwaysApply: true
 
 - Всегда использовать алиас `@/...` для импортов между слоями.
 - Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич.
+- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для API‑слоя снаружи `app/src/api/**` — **`api-public-imports.mdc`** (только `@/api`).
 - При добавлении нового кода проверять:
   - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
 

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

@@ -14,10 +14,10 @@ alwaysApply: true
     - Соблюдение правил из `architecture-boundaries.mdc`, `next-app-core.mdc` и при сетевых изменениях — `http-client.mdc`:
       - UI (`app/src/ui/**`) не ходит напрямую в HTTP‑клиент и не знает DTO.
       - Store (`app/src/store/**`) не зависит от UI; границы транспортных типов и ошибок — `store-rtk.mdc` / `http-client.mdc`.
-      - API (`app/src/api/services/**`) не тянет UI/store, использует мапперы; без прямого `fetch` в сервисах (кроме оговорённых исключений).
+      - API (`app/src/api/**`) не тянет UI/store, использует мапперы; без прямого `fetch` в сервисах (кроме оговорённых исключений).
   - **Импорты и организация кода**:
     - Использование алиаса `@/...` вместо относительных импортов выше по дереву.
-    - Отсутствие deep‑импортов во внешние фичи; использование только public API.
+    - Отсутствие deep‑импортов во внешние фичи; использование только public API; в файлах вне `app/src/api/**` импорты из API — только `from '@/api'` (`api-public-imports.mdc`, дублирует ESLint).
     - Размещение новых файлов в корректных слоях и директориях фич.
   - **Типы и TS‑строгость**:
     - Не допускать новых `any`; предпочитать доменные типы из `@/types` (barrel, см. `types-public-imports.mdc`).
@@ -34,11 +34,11 @@ alwaysApply: true
     - Указывать, какие именно тесты стоит добавить или поправить.
   - **Линтеры (обязательно)**:
     - Рабочий каталог: `app/` (там `package.json` с скриптами линта).
-    - Перед финализацией отчёта по ревью **запустить полный прогон** ESLint по проекту: `yarn lint:js` (эквивалент `eslint .` с расширениями из скрипта — без точечного запуска только на один файл, чтобы не пропустить косвенные срабатывания).
-    - Если в MR менялись стили (css/linaria и т.п.) — дополнительно `yarn lint:css`.
-    - В отчёт включить **все сообщения ESLint (errors и warnings)** по файлам, попадающим в дифф MR/ветки; если полный вывод огромный, сфокусироваться на диффе, но **не** пропускать проверку из‑за «только изменённые файлы» на этапе запуска — сначала полный `yarn lint:js`, затем фильтрация вывода к путям из `git diff`.
-    - При **имплементации правок** по итогам ревью или любой работе «как к MR»: после изменений снова выполнить `yarn lint:js` (и при необходимости `yarn lint:css`); не считать задачу завершённой, пока в изменённых файлах остаются исправимые предупреждения ESLint, которые относятся к этой задаче (исключение — явно устаревший легаси вне скоупа, с пометкой в ответе).
-    - При желании полной валидации, как в CI: `yarn lint` (ESLint + Stylelint + `type-check`) — уместно перед итогом крупного MR.
+    - Перед финализацией отчёта по ревью **запустить полный прогон** ESLint по проекту: `bun run lint:js` (эквивалент `eslint .` с расширениями из скрипта — без точечного запуска только на один файл, чтобы не пропустить косвенные срабатывания).
+    - Если в MR менялись стили (css/linaria и т.п.) — дополнительно `bun run lint:css`.
+    - В отчёт включить **все сообщения ESLint (errors и warnings)** по файлам, попадающим в дифф MR/ветки; если полный вывод огромный, сфокусироваться на диффе, но **не** пропускать проверку из‑за «только изменённые файлы» на этапе запуска — сначала полный `bun run lint:js`, затем фильтрация вывода к путям из `git diff`.
+    - При **имплементации правок** по итогам ревью или любой работе «как к MR»: после изменений снова выполнить `bun run lint:js` (и при необходимости `bun run lint:css`); не считать задачу завершённой, пока в изменённых файлах остаются исправимые предупреждения ESLint, которые относятся к этой задаче (исключение — явно устаревший легаси вне скоупа, с пометкой в ответе).
+    - При желании полной валидации, как в CI: `bun run lint` (ESLint + Stylelint + `type-check`) — уместно перед итогом крупного MR.
 
 - **Глубина и формат ревью**
   - Фокус на **изменениях MR** (дифф относительно целевой ветки), а не на всём проекте.

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

@@ -13,11 +13,11 @@ alwaysApply: true
 2. **Контракт API** — DTO ответов/запросов там, где принято в репо; целевые доменные типы в `@/types`.
 3. **Мапперы** — DTO → домен в `*responseMappers.ts` или аналоге; чистые функции (`api-services.mdc`).
 4. **Сервисы** — вызовы только через прикладные клиенты `app/src/api/clients/**`, public API модуля (`api-services.mdc`, `http-client.mdc`). Без `fetch` из UI/store.
-5. **Состояние** — `createSlice` / `createAsyncThunk`, доменные модели в state (`store-rtk.mdc`); thunk вызывает сервисы из `@/api/services/**`.
+5. **Состояние** — `createSlice` / `createAsyncThunk`, доменные модели в state (`store-rtk.mdc`); thunk вызывает сервисы, импортированные из `@/api` (`api-public-imports.mdc`).
 6. **UI** — тонкие компоненты, типы из `@/types`, без DTO (`react-ui.mdc`, `architecture-boundaries.mdc`, `no-props-spread.mdc`).
 7. **Моки** — по схеме репозитория, точка входа регистрации моков (например `app/src/mocks/index.js`).
 8. **Тесты** — unit для мапперов и критичной логики (`tests-unit.mdc`); при смене HTTP‑клиента — behavior‑тесты клиента (`http-client.mdc`); e2e по `*.cases.md` (`tests-e2e-structure.mdc`, `playwright-agents.mdc`).
-9. **Завершение** — из каталога `app/`: `yarn lint:js`, при стилях `yarn lint:css`, `yarn type-check` (`next-app-core.mdc`).
+9. **Завершение** — из каталога `app/`: `bun run lint:js`, при стилях `bun run lint:css`, `bun run type-check` (`next-app-core.mdc`).
 
 ## Поток данных (ориентир)
 
@@ -41,8 +41,8 @@ flowchart LR
 |--------------------|-----------------------------------|
 | `app/src/api/clients/**`, `app/src/lib/clients/**` | `http-client.mdc`; при изменении клиента — `tests-unit.mdc` (behavior‑тесты) |
 | `app/src/api/services/**` | `api-services.mdc`; при необходимости `http-client.mdc` |
-| `app/src/store/**` | `store-rtk.mdc`, `architecture-boundaries.mdc` |
-| `app/src/ui/**` | `react-ui.mdc`, `no-props-spread.mdc`, `types-public-imports.mdc` |
+| `app/src/store/**` | `store-rtk.mdc`, `architecture-boundaries.mdc`, `api-public-imports.mdc` |
+| `app/src/ui/**` | `react-ui.mdc`, `no-props-spread.mdc`, `types-public-imports.mdc`, `api-public-imports.mdc` |
 | `app/src/types/**` | `types-public-imports.mdc`, `types-jsdoc.mdc` |
 | `app/__tests__/e2e/**` | `tests-e2e-structure.mdc`, `playwright-agents.mdc` |
 

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

@@ -14,7 +14,7 @@ alwaysApply: false
 
 - Обычные REST‑вызовы к backend идут через **одну реализацию** в `app/src/lib/clients/**` (модуль общего клиента) и **преднастроенные экземпляры** в `app/src/api/clients/**`, по тому же паттерну, что уже принят в проекте.
 - Место транспорта в общей картине **порты и адаптеры** — в `architecture-boundaries.mdc` (раздел **«Порты и адаптеры»**).
-- **Не** вызывать `fetch` напрямую из `api/services`, store и UI (см. `architecture-boundaries.mdc`, `api-services.mdc`).
+- **Не** вызывать `fetch` напрямую из `app/src/api/services/**`, store и UI (см. `architecture-boundaries.mdc`, `api-services.mdc`); из store/UI — только вызовы через сервисы из `@/api` (`api-public-imports.mdc`).
 - **Исключения** (узкие протоколы, отдельный транспорт) — только там, где в репозитории уже есть образец; повторять его, не плодить произвольные обходы общего клиента.
 
 ## Типы

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

@@ -0,0 +1,61 @@
+---
+description: Выбор API навигации по стеку проекта (Next.js vs React Router)
+alwaysApply: true
+---
+
+# Навигация и роутинг: сначала стек проекта
+
+**При любой задаче, связанной с навигацией, переходами между страницами, URL, редиректами, хлебными крошками, защищёнными маршрутами или программной сменой маршрута** — перед предложением кода или импортов **нельзя** опираться на «типичный React» по умолчанию. Нужно **явно свериться со стеком целевого репозитория** и использовать **один** согласованный с проектом механизм.
+
+## Зависимости: что проверить в первую очередь
+
+1. **`package.json`** в корне приложения (например `app/package.json` в монорепо — тот пакет, который реально собирается и деплоится). Смотреть **`dependencies`** и при необходимости **`peerDependencies`**:  
+   - **`next`** — Next.js; версия важна для нюансов API (сверяться с документацией под эту major).  
+   - **`react-router-dom`**, **`@remix-run/*`**, **`@tanstack/react-router`** и т.д. — отдельный роутинг; не подменять их API вызовами Next без проверки, что в проекте действительно используется этот стек.  
+   - **`next`** и **`react-router-dom`** одновременно — возможно легаси или гибрид; **не** выбирать API по умолчанию — смотреть раздел «Реализация в коде» ниже.
+
+2. **Монорепо / workspaces** — роутинг может жить не в корневом `package.json`. Открыть **`package.json` того workspace**, где лежат страницы и `next.config.*` / точка входа SPA.
+
+3. **Факт установки** — при сомнениях смотреть lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) или каталог `node_modules` у соответствующего пакета: убедиться, что заявленный пакет реально установлен, а не только прописан в документации.
+
+## Реализация роутинга в проекте (код и структура)
+
+Перед предложением паттерна навигации **свериться с тем, как уже сделано в репозитории**:
+
+1. **Дерево маршрутов**  
+   - Next **App Router**: каталог **`app/`** (или `src/app/`) с `layout.tsx`, `page.tsx`, сегменты `[id]` и т.п.  
+   - Next **Pages Router**: каталог **`pages/`** с `_app`, динамические `[slug].tsx`.  
+   - Наличие **обоих** `app/` и `pages/` — уточнить по `next.config` и документации проекта, какой слой основной.
+
+2. **Точки входа и обёртки**  
+   - Поиск по коду импортов: **`from 'next/navigation'`**, **`from 'next/router'`**, **`from 'next/link'`**, **`from 'react-router-dom'`**, **`createBrowserRouter`**, **`RouterProvider`**, **`BrowserRouter`**.  
+   - Где объявлены маршруты (файловая структура Next vs конфиг маршрутов / `routes.tsx` в SPA).
+
+3. **Общие абстракции проекта**  
+   - Обертки над ссылками (`@/ui/...`, `Link` из дизайн-системы), хелперы путей, константы роутов — **использовать их**, а не дублировать сырой роутер.
+
+4. **Соседние файлы фичи**  
+   - Новый код навигации — в том же стиле, что страницы/хуки той же области (`next/navigation` vs `react-router-dom` как в соседних импортах).
+
+## Как определить, что использовать (сводка)
+
+1. **Зависимости** — см. раздел выше; по ним задаётся допустимый набор пакетов.  
+2. **Структура** — App Router vs Pages vs SPA по каталогам и конфигу.  
+3. **Фактический код** — какие импорты и обёртки уже доминируют в приложении.
+
+## Что использовать (краткая матрица)
+
+| Стек | Программная навигация / чтение пути | Ссылки |
+|------|-------------------------------------|--------|
+| **Next.js App Router** | `next/navigation` (`useRouter`, `usePathname`, `useSearchParams`, `redirect` и т.д. по документации Next для вашей версии) | `next/link` |
+| **Next.js Pages Router** | `next/router` | `next/link` |
+| **SPA + React Router** | `react-router-dom` (`useNavigate`, `useParams`, `useLocation`, …) | `<Link>` из `react-router-dom` |
+
+**Не делать:** подключать `react-router-dom` в проект на Next.js «по привычке»; импортировать хуки из `next/router` в компонентах App Router без проверки; смешивать два роутера в одном приложении без явной архитектурной причины в кодовой базе.
+
+## Требование к агенту
+
+- Перед генерацией или ревью кода навигации **коротко зафиксировать вывод** (например: «зависимости: `next` без `react-router-dom`; в коде везде `next/navigation` → используем то же») и следовать ему.  
+- **Обязательная проверка:** актуальные **`dependencies`** в `package.json` нужного workspace + **как в проекте уже реализованы** маршруты и импорты (поиск по репозиторию, соседние файлы). Не полагаться только на предположение по одному признаку (например, только на наличие папки `app/`).  
+- Если стек неочевиден (два роутера в зависимостях, гибрид) — **сверить lockfile / установленные пакеты** и **доминирующие импорты** в `src`/`app`, затем выбрать API.  
+- Для **этого** репозитория базовый ориентир — **`next-app-core.mdc`**: Next.js; предпочитать **`next/navigation`** и **`next/link`** там, где используется App Router.

package/presets/cursor/next/rules/next-app-core.mdc

@@ -33,8 +33,8 @@ alwaysApply: true
 - **Store слой** (`app/src/store/**`):
   - `app/src/store/slices/**` — модули состояния (в этом preset — Redux Toolkit; подробности в `store-rtk.mdc`).
   - `app/src/store/middleware/**` — middleware для сайд‑эффектов (например, файлы, аналитика).
-- **API слой** (`app/src/api/services/**`):
-  - Сервисы и мапперы, инкапсулирующие HTTP‑логику.
+- **API слой** (`app/src/api/**` — прежде всего `services/**`, плюс `clients/**`, корневой barrel `index.ts`):
+  - Сервисы и мапперы, инкапсулирующие HTTP‑логику; **потребители вне этого каталога** импортируют только через `@/api` (`api-public-imports.mdc`).
 - **HTTP‑транспорт** (модуль общего клиента под `app/src/lib/clients/**`, экземпляры под `app/src/api/clients/**` — как в репозитории):
   - Один механизм запросов, без разбросанного «сырого» `fetch`/`XMLHttpRequest` по фичам. Детали и исключения — **`http-client.mdc`**.
 - **Типы** (`app/src/types/**`):
@@ -44,13 +44,13 @@ alwaysApply: true
 
 ## Порты и адаптеры (сопоставление с каталогами)
 
-Та же идея, что в `architecture-boundaries.mdc` (раздел **«Порты и адаптеры»**): UI и store зависят от **контракта** к backend (сервисы + доменные типы), а **реализация HTTP** изолирована в **`app/src/lib/clients/**`** и **`app/src/api/clients/**`**. Детали транспорта — `http-client.mdc`.
+Та же идея, что в `architecture-boundaries.mdc` (раздел **«Порты и адаптеры»**): UI и store зависят от **контракта** к backend (публичный API `@/api` + доменные типы), а **реализация HTTP** изолирована в **`app/src/lib/clients/**`** и **`app/src/api/clients/**`**. Детали транспорта — `http-client.mdc`; импорты `@/api` — `api-public-imports.mdc`.
 
 # Общие архитектурные принципы
 
 - **Чёткое разделение слоёв**:
-  - UI знает о доменных типах (из `@/types` / `@/types/enums`) и публичных API store и при необходимости **`@/api/services`** — см. политику в `architecture-boundaries.mdc` (**«UI и обращение к `@/api/services`»**).
-  - Store знает о доменных типах и API‑сервисах.
+  - UI знает о доменных типах (из `@/types` / `@/types/enums`) и публичных API store и при необходимости импортирует из **`@/api`** — см. `api-public-imports.mdc` и `architecture-boundaries.mdc` (**«UI и обращение к API»**).
+  - Store знает о доменных типах и вызывает API‑сервисы через импорты из **`@/api`**.
   - API‑сервисы знают о DTO, мапперах и вызовах через клиенты из `app/src/api/clients/**` (`http-client.mdc`).
 - **Никаких "проникновений" слоёв**:
   - UI не вызывает HTTP‑клиент и не работает с DTO; сценарии с записью в общий state — через store; узкие исключения для вызова сервисов из UI — только по правилам `architecture-boundaries.mdc`.
@@ -83,5 +83,5 @@ alwaysApply: true
 - Найти в соответствующей директории похожие примеры и **копировать архитектурный паттерн** (структура файлов, типы, именование).
 - Не упрощать архитектуру в ущерб существующим слоям (не тянуть DTO и HTTP в UI; вызовы сервисов из UI — только в рамках `architecture-boundaries.mdc`).
 - Избегать использования `any` при типизации кода; при необходимости использовать `unknown` с последующим безопасным сужением типов.
-- После создания или редактирования файлов **обязательно** устранять проблемы линтера и типов: из каталога `app/` минимум **`yarn lint:js`** (полный прогон ESLint по проекту, как в `package.json`), при правках стилей — ещё **`yarn lint:css`**; для проверки типов — **`yarn type-check`**. Точечный ESLint только на один файл не заменяет полный прогон при завершении задачи/MR. Устранять найденное в зоне изменений, если это возможно без искажения бизнес‑логики.
+- После создания или редактирования файлов **обязательно** устранять проблемы линтера и типов: из каталога `app/` минимум **`bun run lint:js`** (полный прогон ESLint по проекту, как в `package.json`), при правках стилей — ещё **`bun run lint:css`**; для проверки типов — **`bun run type-check`**. Точечный ESLint только на один файл не заменяет полный прогон при завершении задачи/MR. Устранять найденное в зоне изменений, если это возможно без искажения бизнес‑логики.
 

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

@@ -30,8 +30,8 @@ alwaysApply: false
 - Асинхронные запросы:
   - через `createAsyncThunk` или RTK Query.
   - внутри thunk:
-    - вызывать API через сервисы из `@/api/services/**`;
-    - не вызывать HTTP‑клиент напрямую — только через сервисы `@/api/services/**`.
+    - вызывать API через сервисы, импортированные из `@/api` (**`api-public-imports.mdc`**);
+    - не вызывать HTTP‑клиент напрямую — только через эти сервисы.
 - Сайд‑эффекты (логирование, аналитика, работа с файлами):
   - выносить в middleware (`app/src/store/middleware/**`) или специализированные слайсы.