@bonesofspring/ai-rules 0.2.0 → 0.2.2

package/presets/cursor/next/rules/agent-team-orchestrator.mdc

@@ -1,139 +0,0 @@
----
-description: Orchestrates the agent team via task-router and pipeline.json. Use for /task, /task-continue, /feature-start, task decomposition, or when the user describes a feature, bug, or review request.
-alwaysApply: false
----
-
-# Agent team orchestrator
-
-Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.cursor/team/tasks/<slug>/`.
-
-Work request без `/task` — см. **`agent-team-intake.mdc`** (когда предлагать router вместо прямого кодинга).
-
-## Entry points
-
-| Command | When |
-|---------|------|
-| **`/task <desc>`** | **Preferred** — router → dynamic pipeline → first agent |
-| `/task-continue <slug>` | After human gate or pause |
-| `/feature-start <desc>` | Legacy: analyst-only start (no router) |
-| `/feature-continue <slug>` | Alias of task-continue |
-| `/technical-retro [slug]` | Retro with agent team block |
-
-## Roles
-
-| Agent | readonly | Typical intent |
-|-------|----------|----------------|
-| `task-router` | yes | Every `/task` — writes `pipeline.json` |
-| `task-analyst` | yes | feature, refactor, test-only, a11y, docs-only, migration |
-| `solution-architect` | yes | spike, complex cross-layer feature |
-| `migration-specialist` | yes | migration — phased upgrade plan |
-| `api-contract-reviewer` | yes | new/changed backend API contracts |
-| `debugger` | no | bugfix |
-| `ci-investigator` | no | ci-fix — minimal CI repair |
-| `feature-developer` | no | feature, bugfix, refactor, migration, a11y |
-| `build-verifier` | yes | lint/type-check/unit gate after developer |
-| `accessibility-reviewer` | yes | a11y, UI-heavy feature |
-| `performance-auditor` | yes | perf-audit, perf-sensitive feature |
-| `code-reviewer` | yes | most pipelines, review-only |
-| `security-reviewer` | yes | auth, forms, sensitive data |
-| `qa-tester` | no | feature, bugfix, test-only |
-| `unit-test-planner` | yes | unit-only — coverage plan |
-| `unit-test-generator` | no | unit-only — spec generation |
-| `unit-test-healer` | no | failing/flaky unit tests |
-| `playwright-test-planner` | no | e2e scenario planning |
-| `playwright-test-generator` | no | e2e spec generation |
-| `playwright-test-healer` | no | failing/flaky e2e fixes |
-| `tech-writer` | yes | docs-only, feature/migration docs |
-
-Full prompts: `.cursor/agents/*.md`. Artifact conventions: `.cursor/team/README.md`.
-
-## Dynamic pipeline
-
-```mermaid
-flowchart TD
-  task["/task prompt"]
-  router["task-router"]
-  pipeline["pipeline.json"]
-  step0["steps 0..N"]
-  gate{"humanGates?"}
-  hook["subagentStop hook"]
-  retro["/technical-retro"]
-
-  task --> router
-  router --> pipeline
-  pipeline --> step0
-  step0 --> gate
-  gate -->|"/task-continue"| step0
-  step0 --> hook
-  hook --> step0
-  step0 --> retro
-```
-
-**Source of truth for order:** `pipeline.json` → `steps[]`. Never hardcode analyst → dev → review → QA when `pipeline.json` exists.
-
-## status.json (pipeline mode)
-
-```json
-{
-  "slug": "...",
-  "intent": "feature",
-  "pipelineIndex": 0,
-  "currentAgent": "task-analyst",
-  "phase": "executing",
-  "state": "in_progress",
-  "awaitingHumanGate": false
-}
-```
-
-| state | Meaning |
-|-------|---------|
-| `in_progress` | Current step running |
-| `completed` | Current step done; hook advances |
-| `awaiting_approval` | Human gate; wait for `/task-continue` |
-| `changes_requested` | Reviewer blocked; re-run developer (`retryAfterFix`) |
-| `validation_failed` | build-verifier failed; re-run developer then build-verifier |
-
-## Pipeline step options
-
-| Field | Use |
-|-------|-----|
-| `skipIf` | `debugger.fixed` / `ci-investigator.resolved` — hook skips step when artifact says fix applied |
-| `parallel: true` | `agent` is array — invoke **all** agents in one parent turn; each appends to `parallelCompleted` |
-| `scope` | e.g. `unit-in-dev`, `e2e-only` — passed to developer/qa |
-
-## Rules (strict)
-
-1. **`/task` always starts with task-router** (except user says "skip router" with documented pipeline).
-2. Read `pipeline.json` before every subagent invocation.
-3. One role per Task call — **except** parallel steps: multiple Task calls in one message.
-4. **Never** skip `humanGates` without `/task-continue` or explicit user approval.
-5. Persist handoffs to disk (`brief.md`, `decomposition.md`, `debug-report.md`, `validation-report.md`, `architecture.md`, `migration-plan.md`, `ci-report.md`, `a11y-review.md`, `perf-report.md`, `security-review.md`, `api-contract-review.md`, `unit-test-plan.md`, `documentation.md`, `review.md`).
-6. On `changes_requested` from reviewers: hook sets `retryAfterFix` → developer → same reviewer.
-7. On `validation_failed` from `build-verifier`: hook sets `retryAfterFix: build-verifier` → developer → build-verifier.
-8. When all steps complete, suggest `/technical-retro <slug>`.
-9. If `autoChain: false` in pipeline, do not rely on hook — manual step only.
-
-## Invoking agents
-
-Use Task tool or `/agent-name`. Pass: slug, artifact paths, step `scope` if set.
-
-After each agent completes, ensure `status.json` has `state: completed` (or `awaiting_approval` if gate applies).
-
-## Legacy mode
-
-If `pipeline.json` is missing (old `/feature-start` tasks), fall back to fixed phases: analysis → development → review → testing. Hook supports both.
-
-## Skip pipeline when
-
-Do **not** run `/task` + router for:
-
-- Pure questions («как работает X», «объясни»).
-- Typo / one-file fix / trivial config with no architecture risk.
-- User explicitly says «без pipeline», «просто сделай», or continues an active slug.
-- Single-line `docs-only` with no code impact.
-
-Borderline work requests — см. **`agent-team-intake.mdc`**.
-
-## Auto-detection (optional)
-
-When user describes a **non-trivial task** (not a question), suggest `/task <message>` or run router if they agree.

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

@@ -1,8 +0,0 @@
----
-description: Moved to public-imports.mdc — read that file instead
-alwaysApply: false
----
-
-# Deprecated
-
-Содержимое перенесено в **`public-imports.mdc`** (раздел `@/api`).

package/presets/cursor/next/rules/arrow-functions.mdc

@@ -1,46 +0,0 @@
----
-description: Предпочитать стрелочные функции при написании кода
-globs: app/src/**/*.{ts,tsx,js,jsx}
-alwaysApply: false
----
-
-# Стрелочные функции
-
-При разработке **использовать стрелочный синтаксис** для функций, где это допустимо в TypeScript/JavaScript.
-
-## Что делать
-
-- Объявлять функции как **`const имя = (...) => { ... }`** вместо **`function имя(...) { ... }`**, если не нужны особенности объявления `function`.
-- Колбэки и обработчики — стрелочные функции: `.map((x) => ...)`, `onClick={() => ...}`.
-- React-компоненты и хуки — как стрелочные функции с явной типизацией пропсов/возврата по принятому в проекте стилю.
-
-## Исключения (допустимо не стрелка)
-
-- **Генераторы** (`function*`) — стрелкой не выразить.
-- **Методы класса** — если в коде используются классы, допустимы обычные методы (`method() {}`), а не стрелки в теле класса (из‑за `this`).
-- Когда осознанно нужны **подъём (hoisting)** или **имя функции в стеке** только у `function` — редкие случаи; иначе предпочитать стрелку.
-
-## Примеры
-
-```typescript
-// ❌ Избегать для нового кода
-function formatLabel(id: string): string {
-  return id.toUpperCase()
-}
-
-// ✅ Предпочтительно
-const formatLabel = (id: string): string => {
-  return id.toUpperCase()
-}
-```
-
-```tsx
-// ✅ Предпочтительно
-const UserCard = ({ name }: { name: string }) => {
-  return <span>{name}</span>
-}
-```
-
-## Требование к агенту
-
-При генерации и правке кода **по умолчанию выбирать стрелочные функции**; отступать к `function` только в случаях из раздела исключений.

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

@@ -1,16 +0,0 @@
----
-description: Порядок CSS-свойств по Stylelint (idiomatic-order) — для любых стилей в проекте
-globs:
-  - app/src/ui/**/*.styles.ts
-  - app/src/ui/**/*.styles.tsx
-  - app/src/ui/**/styles.ts
-  - app/src/ui/**/styles.tsx
-  - app/**/*.css
-alwaysApply: false
----
-
-# Порядок CSS-свойств (как в Stylelint)
-
-Для CSS в `.css`, `styles.ts(x)`, `styled` / Linaria — порядок свойств как в **`app/.stylelintrc`** (`@sh/stylelint-config-react` → `stylelint-config-idiomatic-order`).
-
-Не дублировать список свойств вручную. Автоисправление из `app/`: **`yarn lint:css --fix`** (или менеджер пакетов репо). Полный прогон — **`post-change-lint.mdc`**.

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

@@ -1,76 +0,0 @@
----
-description: Сквозной чеклист новой фичи и матрица «слой → правило Cursor». Use when implementing features via feature-developer or feature-delivery skill.
-alwaysApply: false
----
-
-# Доставка фичи (сквозной порядок)
-
-Типичная фича с данными с backend и общим состоянием. Детали слоёв — `architecture-boundaries.mdc`, `next-app-core.mdc`.
-
-## Чеклист (порядок работ)
-
-1. **Доменные типы** — `app/src/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. **Сервисы** — клиенты `app/src/api/clients/**`, barrel `@/api` (`api-services.mdc`, `http-client.mdc`, **`layer-barrel-exports.mdc`**). Без `fetch` из UI/store.
-5. **Состояние** — `createSlice` / `createAsyncThunk` (`store-rtk.mdc`); thunk → сервисы из `@/api`.
-6. **UI** — типы из `@/types`, без DTO (`react-ui.mdc`, `architecture-boundaries.mdc`, `no-props-spread.mdc`).
-7. **Моки** — по схеме репо; регистрация в `app/src/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` + `type-check`; менеджер — `package-manager.mdc`.
-
-## Поток данных (ориентир)
-
-```mermaid
-flowchart LR
-  subgraph transport [Транспорт]
-    HttpClient[HttpClient]
-  end
-  DTO[DTO] --> Mappers[Мапперы]
-  Mappers --> Domain[Доменные типы]
-  Domain --> Service[API сервис]
-  Service --> HttpClient
-  Service --> Thunk[Thunk]
-  Thunk --> Store[Store]
-  Store --> UI[UI]
-```
-
-## Регистрация по слоям
-
-1. **Типы** — `app/src/types/**`; доменная модель — источник правды для UI и store.
-2. **API** — `app/src/api/services/<ServiceRoot>/<Segment>/`; публичные экспорты (в т.ч. **константы путей** для моков) → **`app/src/api/index.ts`**.
-3. **Моки (MSW)** — `app/src/mocks/data/<feature>/`; хендлеры в **`app/src/mocks/handlers.ts`**. Пути из `@/api`, не дублировать URL-строки. Проверить браузерный worker и Node `setupServer`, если оба используются.
-4. **Store** — `app/src/store/slices/<FeatureName>/`; редюсер в **`app/src/store/reducers.ts`**. Middleware → `app/src/store/middleware/**`, регистрация в **`app/src/store/index.ts`**.
-5. **UI** — `app/src/ui/pages/<FeatureName>Page/**` и/или `components/**`; данные через store/hooks.
-6. **Unit** — `*.spec.ts(x)`; мапперы и нетривиальная логика — обязательно.
-7. **E2E** — `app/__tests__/e2e/<Area>/<plan>.cases.md` + `*.spec.ts`.
-
-## Частичные сценарии
-
-| Задача | Минимум действий |
-|--------|------------------|
-| Только API + типы | Типы, сервис, мапперы, `@/api` barrel; unit на маппер. |
-| Только моки | Путь в `@/api`; handlers + `mocks/handlers.ts`. |
-| Только store | Thunk на `@/api`; slice + `reducers.ts`. |
-| Только UI | Store state; без HTTP/DTO. |
-| Только e2e | `*.cases.md` + spec; page object. |
-
-## Антипаттерны
-
-- DTO в UI или нетипизированном store.
-- HTTP-клиент из компонента/thunk в обход сервиса.
-- Deep-import `@/api/services/**` из UI/store.
-- `{...props}` в компоненты — `no-props-spread.mdc`.
-
-## Матрица: зона → правила
-
-| Зона | Правила |
-|------|---------|
-| `app/src/api/clients/**`, `app/src/lib/clients/**` | `http-client.mdc`, `tests-unit.mdc` (behavior) |
-| `app/src/api/services/**` | `api-services.mdc`, `layer-barrel-exports.mdc`, `http-client.mdc` |
-| `app/src/store/**` | `store-rtk.mdc`, `architecture-boundaries.mdc`, `public-imports.mdc` |
-| `app/src/ui/**` | `react-ui.mdc`, `no-props-spread.mdc`, `public-imports.mdc` |
-| `app/src/types/**` | `public-imports.mdc`, `types-jsdoc.mdc`, `layer-barrel-exports.mdc` |
-| `app/__tests__/e2e/**` | `tests-e2e-structure.mdc`, `playwright-agents.mdc` |
-
-При добавлении или расширении фичи **пройти чеклист** и правила из таблицы для затронутых зон.

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

@@ -1,42 +0,0 @@
----
-description: Единый HTTP-клиент, типы ошибок и ответов
-globs:
-  - app/src/lib/clients/HttpClient/**/*.ts
-  - app/src/api/clients/**/*.ts
-alwaysApply: false
----
-
-# HTTP-транспорт
-
-**Имена** фабрик, классов ошибок, типов ответа и конфига — **как в текущем коде репозитория** и в barrel `app/src/types/index.ts`. Ниже — **архитектурные правила**, а не спецификация переименований.
-
-## Роль слоя
-
-- Обычные REST‑вызовы к backend идут через **одну реализацию** в `app/src/lib/clients/**` (модуль общего клиента) и **преднастроенные экземпляры** в `app/src/api/clients/**`, по тому же паттерну, что уже принят в проекте.
-- Место транспорта в общей картине **порты и адаптеры** — в `architecture-boundaries.mdc` (раздел **«Порты и адаптеры»**).
-- **Не** вызывать `fetch` напрямую из `app/src/api/services/**`, store и UI (см. `architecture-boundaries.mdc`, `api-services.mdc`); из store/UI — только вызовы через сервисы из `@/api` (`public-imports.mdc`).
-- **Исключения** (узкие протоколы, отдельный транспорт) — только там, где в репозитории уже есть образец; повторять его, не плодить произвольные обходы общего клиента.
-
-## Типы
-
-- Всё, что относится к **контракту запроса/ответа/ошибки** приложения и реэкспортируется для HTTP‑слоя, импортировать **только** из barrel `@/types`, без deep‑импортов из внутренних файлов `app/src/types/**` (см. `public-imports.mdc`).
-- Не поднимать в новом коде **типы и зависимости от внешнего HTTP‑клиента**, от которого проект ушёл; ориентир — **`package.json`** и существующие вызовы.
-
-## Контракт ошибок
-
-- Ошибки сети и HTTP должны приходить в **едином виде**, который задаёт общий клиент (обычно класс/обёртка с полем вроде `response` для тела и статуса).
-- В **`catch`** ориентироваться на **фактическую форму** ошибки в этом репозитории (как в соседних слайсах/сервисах): доступ к телу ошибки, статусу, диагностическому коду — **по полям текущей реализации**, без выдумывания второго формата.
-
-## Поведение, которое остаётся в клиенте
-
-- Общие заголовки, `credentials`, загрузка файлов (**FormData** / снятие лишних заголовков), бинарные ответы (**blob** и аналоги), единообразный разбор JSON и прочих тел.
-- Перехват **401 / refresh**, обработка **404** и т.п. — **централизованно**, если так уже сделано в клиенте; не дублировать ту же логику в каждом сервисе.
-
-## Связь со store
-
-- Thunk может возвращать **тип обёртки успешного ответа**, если сервис так устроен; в **state** по возможности класть **доменные** типы после маппинга. Подробнее — `store-rtk.mdc`.
-
-## Требование к агенту
-
-- Меняя реализацию общего клиента — **обновить или добавить behavior‑тесты** рядом с модулем клиента (`tests-unit.mdc`).
-- Не вводить **второй полноценный HTTP‑стек** без явной задачи и согласования с архитектурой репозитория.

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

@@ -1,59 +0,0 @@
----
-description: Двухуровневые barrel-экспорты для слоёв с регламентированным public API
-globs: app/src/**/*
-alwaysApply: false
----
-
-# 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 | `app/src/api/index.ts` | `public-imports.mdc` |
-| Types | `app/src/types/index.ts` | `public-imports.mdc` (+ `@/types/enums`) |
-| Core | `app/src/core/index.ts` | ESLint: `@/core/index` |
-
-Иллюстрация двух уровней (API): локальный `services/.../<Feature>/index.ts` → фасад `*ApiService.ts` → `app/src/api/index.ts`.

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

@@ -1,62 +0,0 @@
----
-description: Выбор API навигации по стеку проекта (Next.js vs React Router)
-globs: app/src/ui/**/*
-alwaysApply: false
----
-
-# Навигация и роутинг: сначала стек проекта
-
-**При любой задаче, связанной с навигацией, переходами между страницами, 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-router.mdc

@@ -1,36 +0,0 @@
----
-description: Next.js App Router — Server/Client Components, data fetching, loading and error UI
-globs: app/src/app/**/*,app/**/app/**/*
-alwaysApply: false
----
-
-# Next.js App Router
-
-Применять при работе с `app/src/app/**` или маршрутами App Router в целевом репо.
-
-## Server vs Client
-
-- **Server Components по умолчанию** — без `'use client'`, если не нужны hooks, browser API, event handlers.
-- **`'use client'`** — только для интерактива, `useState`/`useEffect`, browser-only API.
-- Не тянуть store/RTK и тяжёлый client-state в Server Components без необходимости.
-
-## Data fetching
-
-- Предпочитать fetch/data-loader на **server** (RSC, route handlers, server actions — по принятому в репо паттерну).
-- **Не дублировать** один запрос в RSC и client без причины.
-- Кеш и revalidate — как в существующих страницах репо (`fetch` options, `revalidate`, tags).
-
-## Маршруты и UX
-
-- Для async routes использовать **`loading.tsx`**, **`error.tsx`**, **`not-found.tsx`** по образцу соседних routes.
-- **Suspense** — для медленных client/server секций; fallback согласован с дизайн-системой.
-- Навигация — `navigation-router-stack.mdc` + router/link паттерны проекта.
-
-## Границы слоёв
-
-- RSC/route handlers **не импортируют UI-компоненты с client-only зависимостями** напрямую в server tree без `'use client'` границы.
-- Доменные типы — `@/types`; вызовы backend — через `@/api` / services, не raw `fetch` из page.tsx без слоя API.
-
-## Эталон
-
-Смотри существующий route той же сложности в `app/src/app/**` и повтори структуру (`reference-features.mdc`).

package/presets/cursor/next/rules/no-cross-component-styles-import.mdc

@@ -1,58 +0,0 @@
----
-description: Стили компонентов — колокация, импорты, корневой styled как Root
-globs:
-  - app/src/ui/**/*.ts
-  - app/src/ui/**/*.tsx
-alwaysApply: false
----
-
-# Стили только рядом с компонентом
-
-## Имя корневого styled-элемента: `Root`
-
-- В `styles.ts` (или аналоге) **корневой** styled-элемент — тот, что оборачивает весь JSX компонента — экспортируется как **`Root`**.
-- В разметке: `<s.Root>...</s.Root>` при `import * as s from './styles'`.
-- Вложенные и соседние примитивы именуются по смыслу: `Title`, `List`, `Item`, `Header` и т.д.
-- Если нет одной styled-обёртки на весь компонент (только фрагмент или один нативный тег без своего styled), экспорта `Root` может не быть. Когда вводится **одна** внешняя styled-обёртка всего JSX — она называется **`Root`**, а не `Container`, `Wrapper`, `Block` и т.п.
-
-```tsx
-// ✅ Хорошо
-export const Root = styled.div` ... `
-// в компоненте: <s.Root>...</s.Root>
-
-// ❌ Плохо для единственной обёртки всего компонента
-export const Service = styled.div` ... `
-```
-
-## Правило
-
-**Запрещено** импортировать модули стилей, которые лежат в каталоге **другого** UI-компонента или блока (не в том же каталоге, что и текущий файл).
-
-Под «модулями стилей» имеются в виду в первую очередь:
-
-- `styles.ts` / `styles.tsx` рядом с компонентом;
-- `*.module.css`, `*.module.scss` и аналоги, принадлежащие конкретному компоненту;
-- любые файлы, которые **экспортируют только styled-примитивы** для одного компонента.
-
-## Разрешено
-
-- `import * as s from './styles'` — стили **в той же папке**, что и компонент.
-- Импорты **общих** примитивов дизайн-системы, токенов, общих UI из `@/ui/components/...` или пакетов, если это **не** приватный `styles` чужой фичи.
-- Повторное использование визуала через **сам компонент** (композиция), а не через его `styles`.
-
-## Примеры
-
-```tsx
-// ✅ Хорошо — локальный styles
-import * as s from './styles'
-
-// ❌ Плохо — стили родителя/соседа
-import * as s from '../../styles'
-import * as s from '../RequestForAnalysisServices/styles'
-```
-
-## Почему
-
-- Единое имя **`Root`** ускоряет чтение: сразу видно входную точку разметки компонента.
-- Стили и разметка компонента должны меняться вместе, без скрытой связи через чужие файлы.
-- Упрощается рефакторинг и поиск владельца стилей.

package/presets/cursor/next/rules/no-type-assertion-as-import-export.mdc

@@ -1,60 +0,0 @@
----
-description: Избегать приведения типов через as на границах модулей (импорт/экспорт)
-globs:
-  - app/src/api/**/*
-  - app/src/store/**/*
-  - app/src/types/**/*
-alwaysApply: false
----
-
-# Не использовать `as` для приведения типов при экспорте и импорте (кроме необходимых случаев)
-
-## О чём речь
-
-Речь о **type assertion** в TypeScript: выражение вида `значение as Тип`.
-
-**Не относится к правилу** (это не assertion, а синтаксис модулей):
-
-- переименование при экспорте: `export { foo as bar }`, `export { default as Baz } from '...'`;
-- переименование при импорте: `import { foo as bar } from '...'`;
-- `import type { Foo as Bar }` — алиас типа в импорте типов.
-
-## Требование
-
-- На **публичной границе модуля** (то, что **экспортируется** из файла / barrel, и то, что сразу **присваивается импортированным символам** с принудительным приведением) **не использовать** `as Тип` для «подгонки» типов, если можно обойтись нормальной типизацией.
-
-## Предпочитать вместо `as`
-
-- явную аннотацию: `const x: T = ...` / `function f(): T`;
-- **дженерики** у функций и классов;
-- **`satisfies`** (когда нужно проверить совместимость без сужения до `any`);
-- сужение **`unknown`** после проверки (type guards, `zod` и т.п.);
-- правку **исходных типов/DTO/мапперов**, а не assertion на выходе.
-
-## Когда `as` допустим
-
-- взаимодействие с **не типизированными** или некорректно типизированными внешними модулями, где нет разумной альтернативы;
-- узкие места после **валидации** данных, если типовый гард всё ещё не выразить без шума (предпочтительно всё же guard/`satisfies`);
-- **`as const`** — когда нужны литеральные типы и широкий вывод ломает контракт (это отдельный механизм; применять по делу, не как замену типизации API).
-- блок **`catch (error)`** после вызова HTTP через общий клиент: по возможности сужать через **`instanceof`** на **класс ошибки транспорта** из `@/types` (какой именно — по существующей реализации) и работать с уже суженным типом; голый **`as` к тому же типу** — только если `instanceof` недоступен (иной источник выброса) и осознанно.
-
-## Примеры
-
-```typescript
-// ❌ Плохо: assertion на экспортируемом API
-export const config = loadRaw() as AppConfig
-
-// ✅ Лучше: аннотация + проверка или маппер
-export const config: AppConfig = mapToAppConfig(loadRaw())
-
-// ❌ Плохо: сразу после импорта «ломаем» тип
-import { getData } from './api'
-export const data = getData() as MyDto[]
-
-// ✅ Лучше: типизировать getData / обернуть типобезопасной функцией
-```
-
-## Требование к агенту
-
-При ревью и генерации кода **не добавлять** новые `as Тип` на экспортируемые сущности и на цепочку import → export без явной необходимости; по возможности исправлять контракт типов в источнике.
-- В слайсах и сервисах при обработке ошибок API сначала рассматривать **`instanceof`** на класс ошибки транспорта из `@/types` по образцу существующего кода (`http-client.mdc`, `store-rtk.mdc`).

package/presets/cursor/next/rules/package-manager.mdc

@@ -1,16 +0,0 @@
----
-description: Перед командами в терминале определять менеджер пакетов репозитория и использовать только его
-alwaysApply: true
----
-
-# Менеджер пакетов (терминал)
-
-Перед **`npm install` / `yarn` / `pnpm` / `bun`** и **`… run …`** определи менеджер репозитория и **используй только его**.
-
-## Как определить
-
-1. **`packageManager`** в `package.json` (корень или `app/package.json`).
-2. **Lockfile** рядом: `yarn.lock` → yarn; `pnpm-lock.yaml` → pnpm; `package-lock.json` → npm; `bun.lock(b)` → bun.
-3. Если неоднозначно — где `node_modules` и какой lockfile в CI.
-
-Рабочий каталог для scripts — **`app/`**. Примеры: `yarn lint`, `pnpm run test`. Не угадывай — проверь файлы.