@bonesofspring/ai-rules 0.1.36 → 0.1.39

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

@@ -0,0 +1,102 @@
+---
+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>/`.
+
+## 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 |
+| `solution-architect` | yes | spike, complex cross-layer feature |
+| `debugger` | no | bugfix |
+| `feature-developer` | no | feature, bugfix, refactor |
+| `code-reviewer` | yes | most pipelines, review-only |
+| `qa-tester` | no | feature, bugfix, test-only |
+
+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 |
+
+## 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/subagent call.
+4. **Never** skip `humanGates` without `/task-continue` or explicit user approval.
+5. Persist handoffs to disk (`brief.md`, `decomposition.md`, `debug-report.md`, `architecture.md`).
+6. On `changes_requested`: re-invoke `feature-developer`, then `code-reviewer` — do not advance `pipelineIndex` until review passes.
+7. When all steps complete, suggest `/technical-retro <slug>`.
+8. 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.
+
+## Auto-detection (optional)
+
+When user describes a **task** (not a question "how does X work"), suggest `/task <their message>` or run router proactively if they agree.

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

@@ -7,6 +7,7 @@ alwaysApply: true
 
 - **Публичный 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`).
+- При **добавлении** публичного символа в регламентированный слой — реэкспорт в корневой barrel по **`layer-barrel-exports.mdc`**.
 
 ## Внутри слоя `app/src/api/**`
 

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

@@ -50,6 +50,7 @@ alwaysApply: false
 
 При добавлении/изменении API‑метода:
 - Следовать существующим сервисам и мапперам как эталону.
+- Пройти чеклист barrel-экспортов (**`layer-barrel-exports.mdc`**): локальный `index.ts` → фасад слоя → корневой barrel.
 - Не смешивать слой API и UI/store:
   - компоненты не должны зависеть от DTO;
   - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы во thunk при разборе `catch`/payload, если так выстроен сервис (см. `store-rtk.mdc`, `http-client.mdc`).

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

@@ -43,7 +43,7 @@ alwaysApply: true
 
 - Всегда использовать алиас `@/...` для импортов между слоями.
 - Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для API‑слоя снаружи `app/src/api/**` — **`api-public-imports.mdc`** (только `@/api`).
+- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`layer-barrel-exports.mdc`** и `*-public-imports.mdc`; для API‑слоя снаружи `app/src/api/**` — **`api-public-imports.mdc`** (только `@/api`).
 - При добавлении нового кода проверять:
   - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
 

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

@@ -35,10 +35,19 @@ alwaysApply: true
   - сначала локально улучшить архитектуру минимальными шагами;
   - оставить код в консистентном состоянии.
 
+# ESLint, Stylelint и плагины
+
+- Учитывать **все активные правила ESLint** и **подключённые плагины** проекта (конфиг: `app/eslint.config.mjs`, базовые пресеты в т.ч. `@sh/eslint-config-react`, `@sh/eslint-config-boundaries` и локальные overrides).
+- Учитывать **Stylelint** для CSS и CSS-in-JS (конфиг: `app/.stylelintrc`; порядок свойств — `css-property-order-stylelint.mdc`).
+- Новый или изменённый код не должен нарушать эти правила.
+- После **каждого** изменения кода агент **обязан** выполнить **`post-change-lint.mdc`**: полный прогон **`lint:js`** и **`lint:css`**, анализ вывода, исправление срабатываний в зоне задачи.
+- Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) и с **кратким комментарием**, зачем это нужно; отключать «на весь файл» без веской причины не следует.
+
 # Требование к агенту
 
 При каждом изменении:
 - Поддерживать принцип **“boy scout rule”**:
   - оставлять модуль в немного лучшем состоянии, чем до изменения (простые, безопасные улучшения).
 - Не жертвовать архитектурой и слоями ради краткости реализации.
+- **Не завершать задачу**, пока не пройдены обязательные линтеры (`post-change-lint.mdc`).
 

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

@@ -18,6 +18,7 @@ alwaysApply: true
   - **Импорты и организация кода**:
     - Использование алиаса `@/...` вместо относительных импортов выше по дереву.
     - Отсутствие deep‑импортов во внешние фичи; использование только public API; в файлах вне `app/src/api/**` импорты из API — только `from '@/api'` (`api-public-imports.mdc`, дублирует ESLint).
+    - При новых/изменённых модулях в регламентированных слоях — реэкспорт публичных символов в корневой barrel по **`layer-barrel-exports.mdc`**.
     - Размещение новых файлов в корректных слоях и директориях фич.
   - **Типы и TS‑строгость**:
     - Не допускать новых `any`; предпочитать доменные типы из `@/types` (barrel, см. `types-public-imports.mdc`).
@@ -32,13 +33,11 @@ alwaysApply: true
       - либо e2e‑сценарии/спеки отражают новую логику (`playwright-agents.mdc`, `tests-e2e-structure.mdc`).
     - При правках **общего HTTP‑клиента** — наличие/актуальность **behavior‑тестов клиента** (`http-client.mdc`, `tests-unit.mdc`).
     - Указывать, какие именно тесты стоит добавить или поправить.
-  - **Линтеры (обязательно)**:
-    - Рабочий каталог: `app/` (там `package.json` с скриптами линта).
-    - Перед финализацией отчёта по ревью **запустить полный прогон** 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.
+  - **Линтеры (обязательно)** — **`post-change-lint.mdc`**:
+    - Перед финализацией отчёта по ревью и после любых правок по итогам ревью: полный прогон **`lint:js`** и **`lint:css`** из `app/`.
+    - В отчёт включить **все сообщения ESLint и Stylelint (errors и warnings)** по файлам из диффа MR/ветки; запуск — по всему проекту, фильтрация вывода — к путям из `git diff`.
+    - Не считать ревью/правки завершёнными, пока линтеры не проходят или не зафиксирован блокер в ответе.
+    - Полная валидация как в CI: **`lint`** (= `lint:js` + `lint:css` + `type-check`) — уместна перед итогом крупного MR.
 
 - **Глубина и формат ревью**
   - Фокус на **изменениях MR** (дифф относительно целевой ветки), а не на всём проекте.

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

@@ -0,0 +1,25 @@
+---
+description: Порядок CSS-свойств по Stylelint (idiomatic-order) — для любых стилей в проекте
+alwaysApply: true
+---
+
+# Порядок CSS-свойств (как в Stylelint)
+
+Действует для **любого** CSS в репозитории: `.css`, стилевые блоки в `styles.ts` / `styles.tsx`, `styled` / Linaria и другой CSS-in-JS в `.ts` / `.tsx`, если этот код попадает под `yarn lint:css`.
+
+Источник: `app/.stylelintrc` → `@sh/stylelint-config-react` → пакет **`stylelint-config-idiomatic-order`** (правило `order/properties-order`). Свойства, не попавшие в список, идут **в конце блока в алфавитном порядке** (`unspecified: bottomAlphabetical`).
+
+Пиши объявления в **одном** блоке в такой последовательности групп:
+
+1. **`composes`** — только для CSS Modules (если есть).
+2. **`all`**
+3. **Позиционирование:** `position`, `z-index`, затем `top`, `right`, `bottom`, `left`.
+4. **Отображение и раскладка:** `display`, `overflow`.
+5. **Размеры:** `width`, `min-width`, `max-width`, `height`, `min-height`, `max-height`, `box-sizing`.
+6. **Flex:** `flex`, `flex-basis`, `flex-direction`, `flex-flow`, `flex-grow`, `flex-shrink`, `flex-wrap`, `align-content`, `align-items`, `align-self`, `justify-content`, `order`.
+7. **Внутренние отступы:** `padding-top`, `padding-right`, `padding-bottom`, `padding-left`.
+8. **Рамка:** общие `border`, `border-width`, `border-style`, `border-color`, `border-radius`; затем для сторон **сверху по часовой** — `border-top` и его `-width`, `-style`, `-color`, `-radius`, то же для `right`, `bottom`, `left`.
+9. **Внешние отступы:** `margin-top`, `margin-right`, `margin-bottom`, `margin-left`.
+10. **Остальные свойства** — после перечисленных, **по алфавиту** (типографика, фон, анимации, `cursor`, и т.д.).
+
+Автоисправление из каталога `app`: `yarn lint:css --fix` (проверяет `**/*.{css,ts}`).

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

@@ -9,15 +9,15 @@ alwaysApply: true
 
 ## Чеклист (порядок работ)
 
-1. **Доменные типы** — `app/src/types/**`, экспорт через barrel `app/src/types/index.ts` (`types-public-imports.mdc`); JSDoc полей — `types-jsdoc.mdc`.
+1. **Доменные типы** — `app/src/types/**`, экспорт через barrel `app/src/types/index.ts` (`types-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/**`, public API модуля (`api-services.mdc`, `http-client.mdc`). Без `fetch` из UI/store.
+4. **Сервисы** — вызовы только через прикладные клиенты `app/src/api/clients/**`, public API модуля (`api-services.mdc`, `http-client.mdc`, **`layer-barrel-exports.mdc`**). Без `fetch` из UI/store.
 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/`: `bun run lint:js`, при стилях `bun run lint:css`, `bun run type-check` (`next-app-core.mdc`).
+9. **Завершение** — **`post-change-lint.mdc`**: из каталога `app/` обязательно `lint:js` + `lint:css` (полный прогон, исправить срабатывания), затем `type-check`; менеджер пакетов — `package-manager.mdc`.
 
 ## Поток данных (ориентир)
 
@@ -40,10 +40,10 @@ flowchart LR
 | Зона в репозитории | Правила Cursor (`.cursor/rules/`) |
 |--------------------|-----------------------------------|
 | `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/api/services/**` | `api-services.mdc`, `layer-barrel-exports.mdc`; при необходимости `http-client.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/src/types/**` | `types-public-imports.mdc`, `types-jsdoc.mdc`, `layer-barrel-exports.mdc` |
 | `app/__tests__/e2e/**` | `tests-e2e-structure.mdc`, `playwright-agents.mdc` |
 
 Специализированные `.mdc` с `globs` подмешиваются при работе с соответствующими файлами; эта матрица нужна, когда открыт другой файл или идёт общий чат.

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

@@ -0,0 +1,58 @@
+---
+description: Двухуровневые barrel-экспорты для слоёв с регламентированным public API
+alwaysApply: true
+---
+
+# 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` | `api-public-imports.mdc` |
+| Types | `app/src/types/index.ts` | `types-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/next-app-core.mdc

@@ -83,5 +83,5 @@ alwaysApply: true
 - Найти в соответствующей директории похожие примеры и **копировать архитектурный паттерн** (структура файлов, типы, именование).
 - Не упрощать архитектуру в ущерб существующим слоям (не тянуть DTO и HTTP в UI; вызовы сервисов из UI — только в рамках `architecture-boundaries.mdc`).
 - Избегать использования `any` при типизации кода; при необходимости использовать `unknown` с последующим безопасным сужением типов.
-- После создания или редактирования файлов **обязательно** устранять проблемы линтера и типов: из каталога `app/` минимум **`bun run lint:js`** (полный прогон ESLint по проекту, как в `package.json`), при правках стилей — ещё **`bun run lint:css`**; для проверки типов — **`bun run type-check`**. Точечный ESLint только на один файл не заменяет полный прогон при завершении задачи/MR. Устранять найденное в зоне изменений, если это возможно без искажения бизнес‑логики.
+- После **любых** изменений кода — **`post-change-lint.mdc`**: из каталога `app/` обязательно запустить **`lint:js`** и **`lint:css`** (полный прогон), проанализировать вывод, исправить errors/warnings в зоне задачи; задача не завершена, пока оба линтера не проходят. Дополнительно — **`type-check`** при правках TypeScript. Менеджер пакетов — **`package-manager.mdc`**.
 

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

@@ -0,0 +1,55 @@
+---
+description: Стили компонентов — колокация, импорты, корневой styled как Root
+alwaysApply: true
+---
+
+# Стили только рядом с компонентом
+
+## Имя корневого 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-props-spread.mdc

@@ -1,11 +1,14 @@
 ---
 description: Избегать спред-а пропов при передаче в компоненты
 alwaysApply: true
+globs: app/src/**/*.tsx
 ---
 
 # Не использовать спред пропов при передаче в компоненты
 
-При вызове React-компонентов **передавать пропы явно**, а не через spread (`{...props}`).
+При вызове **пользовательских** React-компонентов (имя с заглавной буквы: `IconBox`, `TextField`, ваши `FooBar`) **передавать пропы явно**, а не через spread (`{...props}`, `{...obj}`).
+
+**Агентам и при ревью:** не «упрощать» JSX через объект с последующим spread — это нарушение. Если ветвление по пропам длинное, используйте два явных JSX-блока (`condition ? <A … /> : <B … />`) или отдельные маленькие компоненты, а не `{...mergedProps}`.
 
 ## Почему
 
@@ -13,6 +16,11 @@ alwaysApply: true
 - Упрощает рефакторинг и поиск использований.
 - Снижает риск случайно пробросить лишние или устаревшие пропы.
 
+## Проверка в репозитории
+
+- Для файлов `app/src/ui/**/*.tsx` включено ESLint-правило `react/jsx-props-no-spreading` (`app/eslint.config.mjs`): несоблюдение увидит линтер и CI.
+- Легитимное исключение в конкретном месте — **однострочный** `eslint-disable-next-line react/jsx-props-no-spreading` с кратким комментарием «почему»; для редких обёрток допустим disable на файл (как в `PromocodeInput`).
+
 ## Примеры
 
 ```tsx
@@ -23,6 +31,10 @@ return <Child {...commonProps} />
 // ❌ Плохо
 return <Child {...props} />
 
+// ❌ Плохо (spread из соседнего модуля стилей тоже не оправдание)
+const iconProps = cond ? { name, size: 'm' } : { name, size: 'm', ...styles.IconBoxAccent }
+return <IconBox {...iconProps} />
+
 // ✅ Хорошо
 return (
   <Child
@@ -31,9 +43,20 @@ return (
     c={c}
   />
 )
+
+// ✅ Хорошо — явные пропсы по веткам
+return cond ? (
+  <IconBox name={name} size="m" variant="warning" />
+) : (
+  <IconBox
+    customColors={styles.IconBoxAccent.customColors}
+    name={name}
+    size="m"
+  />
+)
 ```
 
 ## Исключения
 
-- Передача всех пропов в нативный DOM-элемент (`<div {...rest} />`) допустима, если `rest` содержит только валидные HTML-атрибуты.
-- Делегирование пропов в обёртку (wrapper) допустимо, если это явно документировано и обосновано.
+- Передача пропов в **нативный** DOM-элемент (`<div {...rest} />`) допустима, если `rest` содержит только валидные HTML-атрибуты.
+- Делегирование пропов в обёртку (wrapper) допустимо, если это явно документировано и обосновано; при необходимости пометьте файл или строку через ESLint-disable, как выше.

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

@@ -0,0 +1,25 @@
+---
+description: Перед командами в терминале определять менеджер пакетов репозитория и использовать только его
+alwaysApply: true
+---
+
+# Менеджер пакетов (терминал)
+
+Перед **`npm install` / `yarn` / `pnpm` / `bun`** и любыми **`… run …`** (lint, test, dev, build) **сначала определи**, какой менеджер закреплён в этом репозитории, и **используй только его** — не подставляй npm или другой инструмент «по привычке».
+
+## Как определить (по убыванию надёжности)
+
+1. Поле **`packageManager`** в `package.json` у корня монорепо или в каталоге приложения (например `app/package.json`) — строка вида `yarn@…`, `pnpm@…`, `npm@…`, `bun@…` (Corepack).
+2. **Lockfile** рядом с тем `package.json`, откуда ставятся зависимости:
+   - `yarn.lock` → **yarn**
+   - `pnpm-lock.yaml` → **pnpm**
+   - `package-lock.json` → **npm**
+   - `bun.lock` / `bun.lockb` → **bun**
+3. Если структура неоднозначна — критерий: где лежат **`node_modules`** и какой lockfile обновляют в CI / документации репо.
+
+## Как запускать
+
+- Рабочий каталог — тот, где **`package.json`** с нужными **scripts** (в этом репозитории зависимости и скрипты в **`app/`**).
+- Примеры: `yarn lint`, `pnpm run test` — **в соответствии с обнаруженным менеджером**, без смешения разных CLI в одной задаче.
+
+Если менеджер неочевиден — **посмотри файлы** (`package.json`, lockfile) инструментами чтения/списка каталога, **не угадывай**.

package/presets/cursor/next/rules/post-change-lint.mdc

@@ -0,0 +1,48 @@
+---
+description: Обязательный прогон ESLint и Stylelint после любых изменений кода
+alwaysApply: true
+---
+
+# Линтеры после изменений кода
+
+## Когда применять
+
+После **любого** изменения исходников в репозитории: правка, создание или удаление файлов в `app/**` (TS/TSX/JS/MJS, CSS, styled/Linaria в `.ts`/`.tsx`, markdown с ESLint и т.д.).
+
+Исключения без прогона линтеров: только правки **документации вне `app/`**, конфигов CI, `.cursor/rules/**`, если **не** менялся исполняемый код приложения.
+
+## Обязательные команды
+
+Рабочий каталог — **`app/`** (там `package.json` со скриптами). Менеджер пакетов — **`package-manager.mdc`**.
+
+1. **`lint:js`** — полный ESLint по проекту (`eslint .` с расширениями из скрипта).
+2. **`lint:css`** — полный Stylelint (`**/*.{css,ts}`).
+
+**Всегда запускать обе команды**, даже если задача не касалась стилей: Stylelint проверяет и CSS-in-JS в `.ts`.
+
+Точечный ESLint/Stylelint только на один файл **не заменяет** полный прогон перед завершением задачи.
+
+## Алгоритм для агента
+
+1. Завершить правки кода.
+2. Запустить **`lint:js`** и **`lint:css`** из `app/` (через терминал, не «на глаз»).
+3. **Проанализировать весь вывод**: errors и warnings.
+4. **Исправить** все срабатывания в **изменённых файлах** и связанных с задачей; для Stylelint сначала пробовать **`lint:css --fix`**, если правило автоисправимо.
+5. При ненулевом exit code — повторить шаги 2–4 до успешного прогона или явного блокера.
+6. **Не считать задачу выполненной**, пока оба линтера не завершились с кодом 0 **или** в ответе пользователю не зафиксирован блокер (например, легаси вне скоупа) с перечислением оставшихся замечаний.
+
+## Что исправлять
+
+- **Errors** — обязательно.
+- **Warnings** — обязательно в файлах из текущей задачи; вне скоупа — не чинить «заодно», но **упомянуть** в ответе, если мешают нулевому exit code.
+- **`eslint-disable`** — только точечно, с кратким комментарием «зачем» (`code-quality-and-refactoring.mdc`).
+
+## Связанные проверки
+
+- **`type-check`** — обязателен при изменениях TypeScript (`next-app-core.mdc`); не подменяет ESLint/Stylelint.
+- Полная валидация как в CI: **`lint`** (= `lint:js` + `lint:css` + `type-check`) — уместна перед крупным MR.
+
+## Конфиги
+
+- ESLint: `app/eslint.config.mjs`
+- Stylelint: `app/.stylelintrc` (порядок свойств — `css-property-order-stylelint.mdc`)

package/presets/cursor/next/rules/react-ui.mdc

@@ -1,6 +1,6 @@
 ---
 description: Паттерны React/Next UI и стилей (preset)
-globs: app/src/ui/**/*.tsx
+globs: app/src/ui/**/*.tsx,app/src/ui/**/*.ts
 alwaysApply: false
 ---
 
@@ -22,14 +22,42 @@ alwaysApply: false
 - `styles.ts` или соседний модуль стилей — по конвенции репозитория (CSS Modules, CSS-in-JS, и т.д.).
 - `index.ts` — реэкспорт (если нужно наружу).
 
+## Дочерние компоненты (`./components`)
+
+- Локальные подкомпоненты, используемые только этим блоком, выносятся в **`./components/<ComponentName>/`** относительно папки родительского компонента (не оставлять крупные куски JSX и «внутренние» компоненты в том же файле, что и родитель).
+- У каждого такого подкомпонента — **своя** папка с тем же именем, что и публичное имя компонента:
+  - `ComponentName.tsx` — разметка и композиция;
+  - `styles.ts` — только стили этого подкомпонента (см. `no-cross-component-styles-import.mdc`: не тянуть `styles` соседних компонентов);
+  - при необходимости — `ComponentName.data.ts`, `ComponentName.utils.ts`, `ComponentName.hooks.ts` по тем же правилам префикса, что и у родителя;
+  - опционально `index.ts` с реэкспортом.
+- Родитель импортирует подкомпонент из `./components/...`, а не держит его реализацию inline.
+
 Для переиспользуемого компонента:
 - Папка с именем компонента:
   - `ComponentName.tsx`
   - файлы стилей по принятой схеме;
-  - опционально: `types.ts`, `hooks.ts`.
+  - опционально: `types.ts`, `ComponentName.hooks.ts` (см. ниже про префикс).
+
+## Вспомогательные модули рядом с компонентом (именование)
+
+**Префикс имени файла = публичное имя компонента** (как у `ComponentName.tsx` в этой папке), в **PascalCase**. Не вводить отдельные «говорящие» имена файлов по смыслу содержимого (`analysisPreparationIconMap.ts`, `buildAnalysisIdToNameMap.ts` и т.п.) — так теряется связь с компонентом и плодятся одноразовые названия.
+
+**Суффикс по роли:**
+
+| Суффикс | Назначение | Примеры содержимого |
+|--------|------------|---------------------|
+| `ComponentName.data.ts` | Статические данные и конфигурация для UI | мапы `id → иконка/лейбл`, константы списков, таблицы соответствий для отображения |
+| `ComponentName.utils.ts` | Чистые функции без React | форматирование, предобработка пропсов/данных для рендера, `build…`/`map…`‑хелперы |
+| `ComponentName.hooks.ts` | Хуки, используемые только этим блоком | локальные `use…` (если не вынесены в `src/ui/hooks/**`) |
+
+- Несколько констант/мапов или несколько функций — **по-прежнему один** `.data.ts` и один `.utils.ts`, не дробить по «темам» отдельными файлами без веской причины (размер, разные зоны ответственности на уровне подкомпонентов).
+- Если логика принадлежит **подкомпоненту** в подпапке (`components/Child/Child.tsx`), те же правила применяются к **`Child.data.ts`**, **`Child.utils.ts`** относительно этого подкомпонента.
+- Тесты для утилит и данных — рядом в `__tests__/` или с суффиксом `.test.ts`, согласно `tests-unit.mdc`, с тем же префиксом (`RequestForAnalysisRecommendations.utils.test.ts` и т.д.).
 
 # Стили и дизайн‑токены
 
+- **Корневой** styled-элемент компонента в соседнем `styles` — **`Root`** (`<s.Root>`). Подробнее: `no-cross-component-styles-import.mdc`.
+- Порядок объявлений в CSS / `styled` — как требует Stylelint: см. `css-property-order-stylelint.mdc`.
 - Для визуала использовать **тот стек стилей и токенов, который уже в проекте** (переменные, тема, общие классы, дизайн‑пакет).
 - Избегать:
   - inline‑стилей, кроме простых случаев;
@@ -39,6 +67,7 @@ alwaysApply: false
 
 # Пропсы и типизация
 
+- **Не передавать пропы в компоненты через spread** (`<Foo {...x} />`). Только явные атрибуты; подробности и исключения — `no-props-spread.mdc` (в `app/src/ui` это дополнительно ловит ESLint).
 - Описывать пропсы через `type Props = { ... }` или `interface Props { ... }`.
 - Не использовать `any`; при необходимости:
   - обобщения (`<T>`), `unknown`, тип‑предикаты и user‑defined type guards.