@bonesofspring/ai-rules 0.1.37 → 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,12 @@ alwaysApply: true
   - сначала локально улучшить архитектуру минимальными шагами;
   - оставить код в консистентном состоянии.
 
-# ESLint и плагины
+# ESLint, Stylelint и плагины
 
 - Учитывать **все активные правила ESLint** и **подключённые плагины** проекта (конфиг: `app/eslint.config.mjs`, базовые пресеты в т.ч. `@sh/eslint-config-react`, `@sh/eslint-config-boundaries` и локальные overrides).
-- Новый или изменённый код не должен нарушать эти правила. Перед завершением правок по возможности прогонять ESLint на затронутых файлах.
+- Учитывать **Stylelint** для CSS и CSS-in-JS (конфиг: `app/.stylelintrc`; порядок свойств — `css-property-order-stylelint.mdc`).
+- Новый или изменённый код не должен нарушать эти правила.
+- После **каждого** изменения кода агент **обязан** выполнить **`post-change-lint.mdc`**: полный прогон **`lint:js`** и **`lint:css`**, анализ вывода, исправление срабатываний в зоне задачи.
 - Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) и с **кратким комментарием**, зачем это нужно; отключать «на весь файл» без веской причины не следует.
 
 # Требование к агенту
@@ -47,4 +49,5 @@ alwaysApply: true
 - Поддерживать принцип **“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/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/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

@@ -22,6 +22,16 @@ 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`

package/presets/cursor/next/rules/technical-retro.mdc

@@ -1,58 +1,12 @@
 ---
-description: Роль агента для проведения технического ретроспективы (retro) команды / спринта
+description: Роль агента для проведения технического ретроспективы (retro) команды / спринта. On-demand — предпочтительнее slash-команда /technical-retro.
 alwaysApply: false
 ---
 
-# Техническое ретро — роль агента
+# Техническое ретро — rule alias
 
-Агент выступает как **нейтральный фасилитатор технической ретроспективы**, а не как ревьюер кода или оценщик людей. Цель — вынести уроки, согласовать действия и улучшить процесс разработки.
+Полный сценарий (включая блок **«Работа агентов»** для slug из `.cursor/team/tasks/`) — в slash-комmand:
 
-## Когда включать
+**`.cursor/commands/technical-retro.md`** → `/technical-retro`
 
-- Пользователь просит: «ретро», «техническое ретро», «разбор спринта/итерации», «что пошло хорошо / плохо», «action items после релиза».
-- Есть контекст: период (спринт, квартал), тема (релиз, инцидент, миграция), или приложены заметки/линки.
-
-## Входные данные (запросить при нехватке)
-
-- **Период и фокус** (например: две недели, релиз X, постмортем).
-- **Участники/роли** (если важно для формулировок): только разработка или весь кросс‑функциональный поток.
-- **Ограничения**: время (15 / 30 / 60 мин), формат (async в чате vs синхронная повестка).
-- По желанию: список deliverables, метрики, ссылки на тикеты/MR — **без выдумывания** фактов, которых нет в сообщении или репозитории.
-
-Если контекста мало — задать **1–3 коротких уточняющих вопроса**, затем продолжить с явными допущениями в шапке вывода.
-
-## Принципы фасилитации
-
-- **Безопасность и нейтральность**: формулировки про процесс и систему, не про «виноватых»; избегать ярлыков к людям.
-- **Конкретика**: от абстрактного «надо лучше общаться» — к наблюдаемым событиям и договорённостям.
-- **Баланс**: зафиксировать и позитив (что усилить), и зоны роста.
-- **Один владелец и срок** у каждого action item; избегать списка «сделает команда» без имени/роли.
-- **Не смешивать с code review**: ретро не заменяет построчный разбор диффа; при запросе «и ретро, и ревью» — развести два блока в ответе.
-
-## Рекомендуемая структура сессии (по умолчанию)
-
-Подстроить под указанное время. Для короткого async‑формата — сжать до шагов 2–4.
-
-1. **Цель и рамки** (1–2 предложения): зачем встреча, что в фокусе / что вне скоупа.
-2. **Сбор фактов** (молча в чате — списком от пользователя; агент структурирует):
-   - что шло хорошо,
-   - что мешало / вызывало риски,
-   - сюрпризы (технический долг, узкие места, зависимости).
-3. **Группировка тем**: объединить дубли, выделить 3–7 тем для обсуждения (приоритет — влияние × изменяемость).
-4. **Корневые причины (легко)**: для 1–2 самых болезненных тем — кратко «5 почему» или «что в процессе/артефактах позволило этому случиться», без морализаторства.
-5. **Эксперименты на следующий цикл**: не больше 1–3 изменений процесса/инструментов; каждое — измеримое или с явным критерием «успех/не успех».
-6. **Action items**: таблица или список с **что / владелец / до когда / как поймём, что сработало**.
-
-## Формат ответа агента
-
-- Краткая **шапка**: период, фокус, допущения (если были).
-- **Повестка** или итог по этапам выше.
-- **Темы** — буллеты; по спорным местам — **вопросы команде**, а не окончательные выводы без данных.
-- **Решения и эксперименты** отдельным блоком.
-- **Action items** — в конце, каждый пункт с владельцем и дедлайном (или пометка «нужно назначить на встрече»).
-
-## Ограничения
-
-- Не приписывать команде цитаты или факты, которых не было во входе.
-- Не выдавать юридические/HR‑рекомендации; при явных конфликтах или токсичности — мягко предложить эскалацию человеку, ответственному за команду, без детализации «наказаний».
-- Если пользователь просит только шаблон — выдать **шаблон повестки и доски** (колонки, таймбоксы) без выдуманного контента.
+Используй rule только если command недоступен. Не дублируй содержимое command в ответе — следуй command-файлу.

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

@@ -27,3 +27,4 @@ import { TransportError } from '@/types/TransportError'
 ```
 
 При ревью и правках кода **не добавлять** новые импорты типов из `@/types/...` кроме `@/types` и `@/types/enums`.
+- Новые публичные типы — реэкспорт в `app/src/types/index.ts` по **`layer-barrel-exports.mdc`**.

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

@@ -0,0 +1,106 @@
+# Agent team artifacts
+
+Каталог артефактов пайплайна «команда агентов» Cursor.
+
+## Layout
+
+```
+.cursor/team/
+  active-task.json              # { "slug": "current-task-slug" }
+  tasks/
+    <slug>/
+      pipeline.json             # Router: intent, steps, humanGates
+      status.json               # Current step and state machine
+      brief.md                  # Analyst: Definition of Ready
+      decomposition.md          # Analyst: task breakdown
+      debug-report.md           # Debugger (bugfix)
+      architecture.md           # Solution architect (spike / complex)
+```
+
+## Slug
+
+- kebab-case, derived from task title
+- max 48 characters
+- example: `order-history-date-filter`
+
+## pipeline.json schema
+
+```json
+{
+  "slug": "order-history-date-filter",
+  "intent": "feature",
+  "summary": "Add date filter to Order History",
+  "steps": [
+    { "agent": "task-analyst", "label": "Clarify and decompose" },
+    { "agent": "feature-developer", "label": "Implement" },
+    { "agent": "code-reviewer", "label": "Code review" },
+    { "agent": "qa-tester", "label": "Tests", "scope": "full" }
+  ],
+  "humanGates": ["after:task-analyst"],
+  "autoChain": true,
+  "skipped": []
+}
+```
+
+### intent values
+
+`feature` | `bugfix` | `review-only` | `test-only` | `refactor` | `spike` | `retro`
+
+## status.json schema (pipeline mode)
+
+```json
+{
+  "slug": "order-history-date-filter",
+  "intent": "feature",
+  "pipelineIndex": 0,
+  "currentAgent": "task-analyst",
+  "phase": "executing",
+  "state": "in_progress",
+  "awaitingHumanGate": false,
+  "updatedAt": "2026-05-29T12:00:00.000Z"
+}
+```
+
+### phase
+
+| Value | Description |
+|-------|-------------|
+| `executing` | Pipeline step in progress (preferred) |
+| `analysis` | Legacy: analyst phase |
+| `development` | Legacy: developer phase |
+| `review` | Legacy: review phase |
+| `testing` | Legacy: QA phase |
+| `done` | All steps complete |
+
+### state
+
+| Value | Description |
+|-------|-------------|
+| `in_progress` | Current step running |
+| `completed` | Current step finished |
+| `awaiting_approval` | Human gate; use `/task-continue` |
+| `changes_requested` | Reviewer requires fixes |
+| `approved` | Legacy: approved via continue |
+
+## Git
+
+Commit task artifacts if you want them to survive `ai-rules clean cursor`. Alternatively copy finished tasks to `docs/agent-workflow/tasks/<slug>/`.
+
+## Workflow entry
+
+```bash
+/task <описание задачи>
+# при human gate после analyst:
+/task-continue <slug>
+# или
+/feature-continue <slug>
+# после пайплайна:
+/technical-retro <slug>
+```
+
+Legacy:
+
+```bash
+/feature-start <описание>
+/feature-continue <slug>
+```