@bonesofspring/ai-rules 0.2.2 → 0.2.4

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

@@ -0,0 +1,147 @@
+---
+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 | App / prod writes | Typical intent |
+|-------|-------------------|----------------|
+| `task-router` | no (team only) | Every `/task` — writes `pipeline.json` |
+| `task-analyst` | no (team only) | feature, refactor, test-only, a11y, docs-only, migration |
+| `solution-architect` | no (team only) | spike, complex cross-layer feature |
+| `migration-specialist` | no (team only) | migration — phased upgrade plan |
+| `api-contract-reviewer` | no (team only) | new/changed backend API contracts |
+| `debugger` | minimal fix | bugfix |
+| `ci-investigator` | minimal CI fix | ci-fix — minimal CI repair |
+| `feature-developer` | yes | feature, bugfix, refactor, migration, a11y |
+| `build-verifier` | no (team only) | lint/type-check/unit gate after developer |
+| `accessibility-reviewer` | no (team only) | a11y, UI-heavy feature |
+| `performance-auditor` | no (team only) | perf-audit, perf-sensitive feature |
+| `code-reviewer` | no (team only) | most pipelines, review-only |
+| `security-reviewer` | no (team only) | auth, forms, sensitive data |
+| `qa-tester` | tests only | feature, bugfix, test-only |
+| `unit-test-planner` | no (team only) | unit-only — coverage plan |
+| `unit-test-generator` | tests only | unit-only — spec generation |
+| `unit-test-healer` | tests only | failing/flaky unit tests |
+| `playwright-test-planner` | e2e plans | e2e scenario planning |
+| `playwright-test-generator` | e2e tests | e2e spec generation |
+| `playwright-test-healer` | e2e fixes | failing/flaky e2e fixes |
+| `tech-writer` | docs / team | docs-only, feature/migration docs |
+
+**Cursor frontmatter:** all team pipeline agents use `readonly: false` so they can write `.cursor/team/**`. Production/app restrictions live in the agent prompt body — do **not** set `readonly: true` (Cursor blocks *all* file writes, including team artifacts).
+
+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.
+
+## Team artifact I/O (Cursor Shell sandbox)
+
+- Create/update `.cursor/team/tasks/<slug>/**` with the **Write** tool (parents are created automatically). Do **not** bootstrap slug dirs with Shell `mkdir -p` — default sandbox returns `Operation not permitted` (worse on macOS Desktop/Documents with TCC `com.apple.macl`).
+- If Shell must touch team paths and fails with EPERM, retry with `required_permissions: ["all"]`. Prefer Write for artifacts.
+- Prefer repo under `~/Projects` / `WebstormProjects` over `~/Desktop` when using agent team heavily.
+
+## 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-services.mdc

@@ -1,40 +1,41 @@
 ---
 description: Конвенции API сервисов и мапперов
-globs: src/api/services/**/*.ts
+globs: app/src/api/services/**/*.ts
 alwaysApply: false
 ---
 
 # Роль API слоя
 
 - Инкапсулировать всё, что связано с:
-  - HTTP‑запросами (через принятый в проекте клиент),
+  - HTTP‑запросами через **экземпляры прикладных API‑клиентов** в `app/src/api/clients/**`, собранные на **общей реализации** из `app/src/lib/clients/**` (как в существующем коде); подробности — **`http-client.mdc`**; положение слоя в схеме **порты и адаптеры** — `architecture-boundaries.mdc`;
   - URL/путями,
   - заголовками и кодами ответов,
   - DTO backend.
 - Предоставлять UI и store **стабильный доменный интерфейс**:
-  - функции, работающие с доменными типами из `@/types/**`.
+  - функции, работающие с доменными типами из `@/types` (`public-imports.mdc`).
   - мапперы между DTO и доменными типами.
 
 # Структура модулей
 
 - Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
-  - отдельный каталог в `src/api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
+  - отдельный каталог в `app/src/api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
 - Внутри модуля:
   - файлы с вызовами API (`index.ts` или `*.service.ts`);
   - файлы мапперов (`*responseMappers.ts`);
-  - специфичные типы запросов/ответов (если не вынесены в `@/types/**`).
-  - один или несколько **public API** файлов (`index.ts` или barrel‑файлы), через которые к модулю обращаются UI, store и другие слои.
+  - специфичные типы запросов/ответов (если не вынесены в `app/src/types/**` с экспортом через barrel `@/types`).
+  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `app/src/api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `app/src/api/index.ts` (`import … from '@/api'`, **`public-imports.mdc`**).
 
 # Мапперы и типы
 
 - Для каждого запроса/эндпоинта:
   - описывать **response‑тип (DTO)**, точно соответствующий контракту backend;
-  - определять **целевой доменный тип** в `src/types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
+  - определять **целевой доменный тип** в `app/src/types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
 - Мапперы (например, `*responseMappers.ts`):
   - чистые функции, без сайд‑эффектов;
   - выполняют все необходимые вычисления и преобразования данных (булевы флаги, склейка строк, агрегаты и т.п.) при переводе из DTO в доменные модели;
   - при необходимости обеспечивают обратное преобразование (доменные модели -> транспортные типы).
-- UI и store работают только с доменными типами (из `@/types/**` или экспортируемыми из API слоя), а не с "сырыми" DTO.
+- UI и store работают только с доменными типами (из `@/types` или экспортируемыми из public API слоя API), а не с "сырыми" DTO.
+- **Не вызывать `fetch` напрямую** в теле API‑методов: только через клиент; исключения — узкие модули (например JSON‑RPC), если так уже устроено в репозитории.
 
 # Обработка ошибок
 
@@ -49,8 +50,9 @@ alwaysApply: false
 
 При добавлении/изменении API‑метода:
 - Следовать существующим сервисам и мапперам как эталону.
+- Пройти чеклист barrel-экспортов (**`layer-barrel-exports.mdc`**): локальный `index.ts` → фасад слоя → корневой barrel.
 - Не смешивать слой API и UI/store:
   - компоненты не должны зависеть от DTO;
-  - store не должен знать о HTTP‑деталях (URL, коды).
-- При использовании API‑сервисов в UI, store и утилитах импортировать только из public API файлов модуля (например, `@/api/services/OrdersApi/.../index`), а не из внутренних файлов‑реализаций.
+  - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы во thunk при разборе `catch`/payload, если так выстроен сервис (см. `store-rtk.mdc`, `http-client.mdc`).
+- При использовании API‑сервисов в UI, store и утилитах **вне** `app/src/api/**` импортировать **только** из `@/api` (корневой barrel), см. **`public-imports.mdc`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.
 

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

@@ -0,0 +1,15 @@
+---
+description: Границы слоя UI — slim rule для правок компонентов (без полной карты store/API)
+globs: app/src/ui/**/*.tsx,app/src/ui/**/*.ts
+alwaysApply: false
+---
+
+# UI layer boundaries (slim)
+
+- **Импорты:** `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums`, API — только `from '@/api'` (`public-imports.mdc`).
+- **Запрещено:** прямой HTTP‑клиент; знание DTO — только доменные типы.
+- **Состояние:** сценарии с записью и координация шагов — через store/thunk; узкие прямые вызовы `@/api` для чтения — только как в соседних фичах.
+- **Организация:** алиас `@/`; без deep‑импортов в чужие фичи; только public API.
+- **Barrel:** при новых публичных символах — реэкспорт по `layer-barrel-exports.mdc` (правило грузится на `index.ts`).
+
+Полная карта слоёв (store, API, порты‑адаптеры): **`architecture-boundaries.mdc`** — при правках `app/src/api`, `store`, `types`, `lib`.

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

@@ -1,42 +1,61 @@
 ---
 description: Архитектурные границы и правила импортов
-alwaysApply: true
+globs: app/src/api/**/*,app/src/store/**/*,app/src/types/**/*,app/src/lib/**/*
+alwaysApply: false
 ---
 
 # Границы между слоями
 
-- **UI (src/ui/**)**:
-  - Может импортировать: `@/ui/**`, `@/store/**`, `@/types/**`, `@/api/services/**` (через публичные интерфейсы).
+- **UI (app/src/ui/**)**:
+  - Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `public-imports.mdc`**), контракт к API — **только** `import … from '@/api'` (**`public-imports.mdc`**).
   - Не должен:
     - обращаться к HTTP‑клиенту напрямую;
     - знать детали DTO backend — только доменные типы.
-- **Store (src/store/**)**:
-  - Может импортировать: `@/store/**`, `@/api/services/**`, `@/types/**`.
+- **Store (app/src/store/**)**:
+  - Может импортировать: `@/store/**`, сервисы и публичные сущности API — **только** из `@/api` (**`public-imports.mdc`**), типы из `@/types` и enum из `@/types/enums` (**`public-imports.mdc`**).
   - Не должен:
     - зависеть от конкретных UI‑компонентов;
     - напрямую работать с global/window API.
-- **API (src/api/services/**)**:
-  - Может импортировать: `@/types/**`, общие утилиты.
+  - Вызовы к 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` (**`public-imports.mdc`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`http-client.mdc`, `api-services.mdc`).
   - Не должен:
     - тянуть в себя UI или store;
     - смешивать HTTP‑слой и доменный слой — использовать мапперы.
 
+## UI и обращение к API (`@/api`)
+
+- По умолчанию сценарии с **изменением серверного состояния** и координация нескольких шагов — через **store** (`createAsyncThunk`, dispatch, паттерн фичи в репозитории).
+- Прямой вызов методов сервисов, импортированных из **`@/api`**, из UI допустим только в **узких случаях**: преимущественно **чтение** или действие **без необходимости держать результат в Redux**; те же **доменные типы**, что использовал бы thunk; **не** дублировать уже существующий сценарий из store и **не** протаскивать DTO в компоненты.
+- Предпочтительно оформлять такие вызовы так же, как в **соседних фичах** репозитория (хук‑фасад, отдельный хук и т.д.).
+
+## Порты и адаптеры (краткая карта)
+
+- **Входящий адаптер**: UI — ввод пользователя, отображение; зависит от store и доменных типов, не от транспорта.
+- **Оркестрация сценариев**: store (slices, thunk) — вызывает сервисы, кладёт в state **доменные** модели после маппинга.
+- **Исходящий порт (контракт к backend)**: публичный API **`@/api`** (barrel `app/src/api/index.ts`; реализация — в `app/src/api/services/**` и т.д., см. `public-imports.mdc`).
+- **Исходящий адаптер**: общая реализация HTTP в **`app/src/lib/clients/**`** и экземпляры в **`app/src/api/clients/**`**.
+
+## Фича как срез
+
+- Для сложной фичи выравниваются имена и термины (**единый язык** предметной области) в типах, селекторах, сервисах и UI; структура папок — как в соседних фичах репозитория.
+
 # Правила импортов
 
 - Всегда использовать алиас `@/...` для импортов между слоями.
 - Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич.
+- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`layer-barrel-exports.mdc`** и `public-imports.mdc`; для API‑слоя снаружи `app/src/api/**` — **`public-imports.mdc`** (только `@/api`).
 - При добавлении нового кода проверять:
   - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
 
 # Организация фич
 
 - Для сложных фич (например, `OrderCheckout`):
-  - Страница: `src/ui/pages/OrderCheckoutPage/**`.
+  - Страница: `app/src/ui/pages/OrderCheckoutPage/**`.
   - Локальные компоненты: поддиректории `components/**` внутри страницы.
-  - Связанный store: `src/store/slices/OrderCheckout/**`.
-  - API: `src/api/services/OrdersApi/OrderCheckout/**` (имя корневого сервиса взять из принятой в проекте схемы).
-  - Типы: `src/types/OrderCheckout.types.ts` или аналогичный файл.
+  - Связанный store: `app/src/store/slices/OrderCheckout/**`.
+  - API: `app/src/api/services/OrdersApi/OrderCheckout/**` (имя корневого сервиса взять из принятой в проекте схемы).
+  - Типы: `app/src/types/**` с экспортом через barrel **`app/src/types/index.ts`** (`public-imports.mdc`).
 
 # Требование к агенту
 

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

@@ -0,0 +1,46 @@
+---
+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/code-quality-and-refactoring.mdc

@@ -35,10 +35,11 @@ alwaysApply: true
   - сначала локально улучшить архитектуру минимальными шагами;
   - оставить код в консистентном состоянии.
 
+# Линтеры
+
+Lint/stylelint — только **`post-change-lint.mdc`**; ESLint config: `app/eslint.config.mjs`. Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) с кратким комментарием «зачем».
+
 # Требование к агенту
 
-При каждом изменении:
-- Поддерживать принцип **“boy scout rule”**:
-  - оставлять модуль в немного лучшем состоянии, чем до изменения (простые, безопасные улучшения).
+- **Boy scout rule:** оставлять модуль немного лучше, чем до изменения (простые, безопасные улучшения).
 - Не жертвовать архитектурой и слоями ради краткости реализации.
-

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

@@ -1,47 +1,28 @@
 ---
 description: Требования к code review агентами Cursor для merge requests
-alwaysApply: true
+alwaysApply: false
 ---
 
 # Code review merge requests
 
-- **Когда применять**
-  - Если пользователь просит: "проведи ревью", "оценить MR/ветку/дифф", "посмотри изменения".
-  - Опираться на локальный репозиторий: текущую ветку, `git diff` и открытые файлы, а не на данные внешнего API хостинга.
-
-- **Что обязан проверить агент**
-  - **Архитектура и слои**:
-    - Соблюдение правил из `architecture-boundaries.mdc` и `next-app-core.mdc`:
-      - UI (`src/ui/**`) не ходит напрямую в HTTP‑клиент и не знает DTO.
-      - Store (`src/store/**`) не зависит от UI и не работает с "сырыми" HTTP.
-      - API (`src/api/services/**`) не тянет UI/store, использует мапперы.
-  - **Импорты и организация кода**:
-    - Использование алиаса `@/...` вместо относительных импортов выше по дереву.
-    - Отсутствие deep‑импортов во внешние фичи; использование только public API.
-    - Размещение новых файлов в корректных слоях и директориях фич.
-  - **Типы и TS‑строгость**:
-    - Не допускать новых `any`; предпочитать доменные типы из `src/types/**`.
-    - Проверять корректность пропсов/возвращаемых типов, особенно в UI и API‑слое.
-  - **UI и стили**:
-    - Для компонентов и стилей сверяться с `react-ui.mdc` и `next-app-core.mdc`:
-      - Соблюдать принятый в проекте способ стилей и общие UI‑примитивы/токены, а не "магические" значения.
-      - Сохранять консистентность с существующими компонентами и паттернами.
-  - **Тесты**:
-    - Проверять, что для нетривиальных изменений:
-      - либо обновлены/добавлены unit‑тесты (`tests-unit.mdc`),
-      - либо e2e‑сценарии/спеки отражают новую логику (`playwright-agents.mdc`, `tests-e2e-structure.mdc`).
-    - Указывать, какие именно тесты стоит добавить или поправить.
-
-- **Глубина и формат ревью**
-  - Фокус на **изменениях MR** (дифф относительно целевой ветки), а не на всём проекте.
-  - Сначала дать **высокоуровневый обзор** (что делает MR, риски, архитектурные замечания), затем список конкретных комментариев.
-  - Каждый комментарий делать:
-    - **конкретным** (указать файл/участок и проблему),
-    - **практичным** (предложить вариант исправления, опираясь на существующие паттерны),
-    - без "больших рефакторингов" в духе `code-quality-and-refactoring.mdc`, если задача локальная.
-
-- **Ограничения для агента**
-  - Не придумывать несуществующие метаданные из хостинга (лейблы MR, авторов, статусы CI), если их нет в локальных данных.
-  - Не менять общую архитектуру фичи без прямого запроса пользователя.
-  - Следовать принципу "boy scout rule": предлагать улучшения, которые реально можно внести в рамках MR.
+On-demand rule for review flows. **Procedure and output format:** skill `code-review`.
 
+## Checklist references
+
+- Architecture layers: `architecture-boundaries.mdc`, `next-app-core.mdc`; network: `http-client.mdc`
+- Imports: `public-imports.mdc`, `layer-barrel-exports.mdc`
+- UI: `react-ui.mdc`
+- Tests: `tests-unit.mdc`, `playwright-agents.mdc`, `tests-e2e-structure.mdc`
+- Lint gate before final report: `post-change-lint.mdc`
+
+## When to load
+
+- User asks for review/MR/diff
+- Pipeline step `code-reviewer`
+- BUGBOT automated review
+
+## 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.

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

@@ -0,0 +1,16 @@
+---
+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

@@ -0,0 +1,76 @@
+---
+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-ui.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

@@ -0,0 +1,42 @@
+---
+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‑стек** без явной задачи и согласования с архитектурой репозитория.