@bonesofspring/ai-rules 0.1.42 → 0.2.1

package/presets/claude/next/rules/tooling-and-review/code-review-mr.md

@@ -1,67 +1,30 @@
-# Code review merge requests
-
-## Когда применять
-
-- Пользователь просит: «проведи ревью», «оценить MR/ветку/дифф», «посмотри изменения».
-- Опираться на локальный репозиторий: текущую ветку, `git diff` и открытые файлы, а не на данные внешнего API хостинга.
-
-## Что обязан проверить агент
-
-### Архитектура и слои
-
-Соблюдение `architecture/architecture-boundaries.md`, `stack/next-app-core.md` и при сетевых изменениях — `api-and-data/http-client.md`:
-
-- UI (`app/src/ui/**`) не ходит напрямую в HTTP‑клиент и не знает DTO.
-- Store (`app/src/store/**`) не зависит от UI; границы транспортных типов и ошибок — `api-and-data/store-rtk.md` / `api-and-data/http-client.md`.
-- API (`app/src/api/**`) не тянет UI/store, использует мапперы; без прямого `fetch` в сервисах (кроме оговорённых исключений).
-
-### Импорты и организация кода
+---
+paths:
+  - .claude/agents/code-reviewer.md
+  - .claude/commands/**/*
+  - .claude/team/**/*
+---
 
-- Использование алиаса `@/...` вместо относительных импортов выше по дереву.
-- Отсутствие deep‑импортов во внешние фичи; только public API; в файлах вне `app/src/api/**` импорты из API — только `from '@/api'` (`architecture/api-public-imports.md`, дублирует ESLint).
-- При новых/изменённых модулях в регламентированных слоях — реэкспорт публичных символов в корневой barrel по **`architecture/layer-barrel-exports.md`**.
-- Размещение новых файлов в корректных слоях и директориях фич.
-
-### Типы и TS‑строгость
-
-- Не допускать новых `any`; предпочитать доменные типы из `@/types` (barrel, см. `architecture/types-public-imports.md`).
-- Проверять корректность пропсов/возвращаемых типов, особенно в UI и API‑слое.
-
-### UI и стили
-
-Для компонентов и стилей сверяться с `ui-and-accessibility/react-ui.md` и `stack/next-app-core.md`:
-
-- Соблюдать принятый способ стилей и общие UI‑примитивы/токены, а не «магические» значения.
-- Сохранять консистентность с существующими компонентами и паттернами.
-
-### Тесты
-
-- Для нетривиальных изменений:
-  - либо обновлены/добавлены unit‑тесты (`testing/tests-unit.md`),
-  - либо e2e‑сценарии/спеки отражают новую логику (`testing/playwright-agents.md`, `testing/tests-e2e-structure.md`).
-- При правках **общего HTTP‑клиента** — наличие/актуальность **behavior‑тестов клиента** (`api-and-data/http-client.md`, `testing/tests-unit.md`).
-- **Указывать, какие именно тесты** стоит добавить или поправить.
+# Code review merge requests
 
-### Линтеры (обязательно)
+On-demand rule for review flows. **Procedure and output format:** skill `code-review`.
 
-**`tooling-and-review/post-change-lint.md`**:
+## Checklist references
 
-- Перед финализацией отчёта по ревью и после любых правок по итогам ревью: полный прогон **`lint:js`** и **`lint:css`** из `app/`.
-- В отчёт включить **все сообщения ESLint и Stylelint (errors и warnings)** по файлам из диффа MR/ветки; запуск — по всему проекту, **фильтрация вывода — к путям из `git diff`**.
-- Не считать ревью/правки завершёнными, пока линтеры не проходят или не зафиксирован блокер в ответе.
-- Полная валидация как в CI: **`lint`** (= `lint:js` + `lint:css` + `type-check`) — уместна перед итогом крупного MR.
+- Architecture layers: `architecture/architecture-boundaries.md`, `stack/next-app-core.md`; network: `api-and-data/http-client.md`
+- Imports: `architecture/public-imports.md`, `architecture/layer-barrel-exports.md`
+- UI: `ui-and-accessibility/react-ui.md`
+- Tests: `testing/tests-unit.md`, `testing/playwright-agents.md`, `testing/tests-e2e-structure.md`
+- Lint gate before final report: `tooling-and-review/post-change-lint.md`
 
-## Глубина и формат ревью
+## When to load
 
-- Фокус на **изменениях MR** (дифф относительно целевой ветки), а не на всём проекте.
-- Сначала **высокоуровневый обзор** (что делает MR, риски, архитектурные замечания), затем список конкретных комментариев.
-- Каждый комментарий:
-  - **конкретный** (файл/участок и проблема),
-  - **практичный** (вариант исправления по существующим паттернам),
-  - без «больших рефакторингов» в духе `tooling-and-review/code-quality.md`, если задача локальная.
+- User asks for review/MR/diff
+- Pipeline step `code-reviewer`
+- BUGBOT automated review
 
-## Ограничения для агента
+## Constraints
 
-- Не придумывать несуществующие метаданные из хостинга (лейблы MR, авторов, статусы CI), если их нет в локальных данных.
-- Не менять общую архитектуру фичи без прямого запроса пользователя.
-- Следовать принципу «boy scout rule»: предлагать улучшения, которые реально можно внести в рамках MR.
+- 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/claude/next/rules/tooling-and-review/package-manager.md

@@ -1,20 +1,11 @@
 # Менеджер пакетов (терминал)
 
-Перед **`npm install` / `yarn` / `pnpm` / `bun`** и любыми **`… run …`** (lint, test, dev, build) **сначала определи**, какой менеджер закреплён в этом репозитории, и **используй только его**.
+Перед **`npm install` / `yarn` / `pnpm` / `bun`** и **`… run …`** определи менеджер репозитория и **используй только его**.
 
-## Как определить (по убыванию надёжности)
+## Как определить
 
-1. Поле **`packageManager`** в `package.json` (корень монорепо или `app/package.json`) — `yarn@…`, `pnpm@…`, `npm@…`, `bun@…`.
-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.
+1. **`packageManager`** в `package.json` (корень или `app/package.json`).
+2. **Lockfile** рядом: `yarn.lock` → yarn; `pnpm-lock.yaml` → pnpm; `package-lock.json` → npm; `bun.lock(b)` → bun.
+3. Если неоднозначно — где `node_modules` и какой lockfile в CI.
 
-## Как запускать
-
-- Рабочий каталог — там, где **`package.json`** с нужными **scripts** (в этом репозитории — **`app/`**).
-- Примеры: `yarn lint`, `pnpm run test` — **в соответствии с обнаруженным менеджером**.
-
-Если менеджер неочевиден — **посмотри файлы** инструментами чтения, **не угадывай**.
+Рабочий каталог для scripts — **`app/`**. Примеры: `yarn lint`, `pnpm run test`. Не угадывай — проверь файлы.

package/presets/claude/next/rules/tooling-and-review/post-change-lint.md

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

package/presets/claude/next/rules/ui-and-accessibility/README.md

@@ -5,6 +5,5 @@
 | Файл | Содержание | Загрузка |
 |------|------------|----------|
 | `no-props-spread.md` | Явные пропсы, без `{...props}` | session start |
-| `component-styles.md` | Колокация стилей, `Root` | session start |
-| `css-property-order.md` | Порядок CSS (Stylelint idiomatic-order) | session start |
+| `css-property-order.md` | Порядок CSS (Stylelint idiomatic-order) | `paths: styles.ts`, `.css` |
 | `react-ui.md` | Структура компонентов, `.data.ts`, хуки | `paths: app/src/ui/**` |

package/presets/claude/next/rules/ui-and-accessibility/css-property-order.md

@@ -1,26 +1,14 @@
 ---
 paths:
-  - app/src/**/*.{css,ts,tsx}
+  - app/src/ui/**/*.styles.ts
+  - app/src/ui/**/*.styles.tsx
+  - app/src/ui/**/styles.ts
+  - app/src/ui/**/styles.tsx
   - app/**/*.css
 ---
 
 # Порядок CSS-свойств (как в Stylelint)
 
-Действует для **любого** CSS в репозитории: `.css`, стилевые блоки в `styles.ts` / `styles.tsx`, `styled` / Linaria и другой CSS-in-JS в `.ts` / `.tsx`, если этот код попадает под `lint:css`.
+Порядок свойств — как в **`app/.stylelintrc`** (`stylelint-config-idiomatic-order`). Не дублировать список вручную.
 
-Источник: `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`: `lint:css --fix` (проверяет `**/*.{css,ts}`; менеджер пакетов — `tooling-and-review/package-manager.md`).
+Автоисправление из `app/`: **`lint:css --fix`**. Полный прогон — **`tooling-and-review/post-change-lint.md`**.

package/presets/claude/next/rules/ui-and-accessibility/react-ui.md

@@ -28,7 +28,7 @@ paths:
 - Локальные подкомпоненты, используемые только этим блоком, выносятся в **`./components/<ComponentName>/`** относительно папки родительского компонента (не оставлять крупные куски JSX и «внутренние» компоненты в том же файле, что и родитель).
 - У каждого такого подкомпонента — **своя** папка с тем же именем, что и публичное имя компонента:
   - `ComponentName.tsx` — разметка и композиция;
-  - `styles.ts` — только стили этого подкомпонента (см. `ui-and-accessibility/component-styles.md`: не тянуть `styles` соседних компонентов);
+  - `styles.ts` — только стили этого подкомпонента (не тянуть `styles` соседних компонентов — см. § Стили ниже);
   - при необходимости — `ComponentName.data.ts`, `ComponentName.utils.ts`, `ComponentName.hooks.ts` по тем же правилам префикса, что и у родителя;
   - опционально `index.ts` с реэкспортом.
 - Родитель импортирует подкомпонент из `./components/...`, а не держит его реализацию inline.
@@ -58,8 +58,9 @@ paths:
 
 # Стили и дизайн‑токены
 
-- **Корневой** styled-элемент компонента в соседнем `styles` — **`Root`** (`<s.Root>`). Подробнее: `ui-and-accessibility/component-styles.md`.
-- Порядок объявлений в CSS / `styled` — как требует Stylelint: см. `ui-and-accessibility/css-property-order.md`.
+- **Корневой** styled в соседнем `styles` — экспорт **`Root`**; в JSX: `<s.Root>` при `import * as s from './styles'`. Вложенные — `Title`, `List` и т.д. Не `Container`/`Wrapper` для единственной обёртки.
+- **Запрещено** импортировать `styles` другого компонента (`../Other/styles`, `../../styles`). Разрешено: `./styles`, общие примитивы из `@/ui/components/...` или пакетов дизайн-системы.
+- Порядок CSS / `styled` — Stylelint idiomatic-order: `ui-and-accessibility/css-property-order.md` (грузится на `styles.ts` / `.css`).
 - Для визуала использовать **тот стек стилей и токенов, который уже в проекте** (переменные, тема, общие классы, дизайн‑пакет).
 - Избегать:
   - inline‑стилей, кроме простых случаев;
@@ -72,7 +73,7 @@ paths:
 - **Не передавать пропы в компоненты через spread** (`<Foo {...x} />`). Только явные атрибуты; подробности — `ui-and-accessibility/no-props-spread.md` (в `app/src/ui` это дополнительно ловит ESLint).
 - Описывать пропсы через `type Props = { ... }` или `interface Props { ... }`.
 - Не использовать `any`; при необходимости — обобщения (`<T>`), `unknown`, type guards.
-- Для доменных сущностей использовать типы из `@/types` (и enum из `@/types/enums`), а не описывать их заново (`architecture/types-public-imports.md`).
+- Для доменных сущностей использовать типы из `@/types` (и enum из `@/types/enums`), а не описывать их заново (`architecture/public-imports.md`).
 
 # Логика и side effects
 

package/presets/claude/next/skills/feature-delivery/SKILL.md

@@ -5,26 +5,11 @@ description: Delivers Next.js frontend features end-to-end across domain types,
 
 # Feature Delivery
 
-## Workflow
-
-1. Read the task brief, acceptance criteria, and decomposition if present.
-2. Read **`architecture/reference-features.md`** and mirror the closest reference feature.
-3. Work in layer order: types -> API -> store -> UI -> **unit tests** -> e2e (if in scope).
-4. Keep DTOs out of UI/store; expose domain types through `@/types` and API calls through `@/api`.
-5. Prefer small, reviewable edits; update barrels when adding public symbols.
-6. Add or update focused tests for changed behavior.
-7. Run project validation from `app/`: `lint:js`, `lint:css`, and `type-check` when TypeScript changed.
-
-## Rule Map
-
-- Core stack and layers: `rules/stack/next-app-core.md`, `rules/architecture/architecture-boundaries.md`.
-- Data/API: `rules/api-and-data/http-client.md`, `rules/api-and-data/api-services.md`, `rules/api-and-data/store-rtk.md`.
-- Public imports: `rules/architecture/types-public-imports.md`, `rules/architecture/api-public-imports.md`, `rules/architecture/layer-barrel-exports.md`.
-- UI: `rules/ui-and-accessibility/react-ui.md`, `react-a11y-coding.md`, `no-props-spread.md`, `component-styles.md`.
-- App Router: `rules/stack/next-app-router.md`.
-- Tests: `rules/testing/tests-unit.md`, `rules/testing/tests-e2e-structure.md`, `rules/testing/playwright-agents.md`.
-- Finish: `rules/tooling-and-review/post-change-lint.md`, `rules/tooling-and-review/package-manager.md`.
+1. Read task brief, acceptance criteria, and decomposition if present.
+2. Read **`rules/architecture/feature-delivery-workflow.md`** and **`rules/architecture/reference-features.md`** — follow layer order and mirror closest reference feature.
+3. Add or update focused tests for changed behavior.
+4. Validation from `app/`: see **`rules/tooling-and-review/post-change-lint.md`** (pipeline: scoped lint OK if next step is `build-verifier`).
 
 ## Handoff
 
-Summarize completed work by layer, validation results, and known gaps. If this is part of an agent team task, update `.claude/team/tasks/<slug>/status.json`.
+Summarize by layer, validation results, and known gaps. Agent team: update `.claude/team/tasks/<slug>/status.json`.

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

@@ -7,6 +7,7 @@
 ```
 .claude/team/
   active-task.json
+  fixtures/                  # pipeline profile examples (feature-full, feature-light, bugfix-standard)
   tasks/
     <slug>/
       pipeline.json

package/presets/claude/next/team/fixtures/bugfix-standard.json

@@ -0,0 +1,15 @@
+{
+  "slug": "example-bugfix-standard",
+  "intent": "bugfix",
+  "profile": "standard",
+  "summary": "Regression fix with review",
+  "steps": [
+    { "agent": "debugger", "label": "Root cause" },
+    { "agent": "feature-developer", "label": "Fix if needed", "skipIf": "debugger.fixed" },
+    { "agent": "build-verifier", "label": "Validation gate" },
+    { "agent": "code-reviewer", "label": "Code review" }
+  ],
+  "humanGates": [],
+  "autoChain": true,
+  "skipped": []
+}

package/presets/claude/next/team/fixtures/feature-full.json

@@ -0,0 +1,16 @@
+{
+  "slug": "example-feature-full",
+  "intent": "feature",
+  "profile": "full",
+  "summary": "Multi-layer feature with e2e coverage",
+  "steps": [
+    { "agent": "task-analyst", "label": "Clarify and decompose" },
+    { "agent": "feature-developer", "label": "Implement + unit tests", "scope": "unit-in-dev" },
+    { "agent": "build-verifier", "label": "Validation gate" },
+    { "agent": "code-reviewer", "label": "Code review" },
+    { "agent": "qa-tester", "label": "E2E", "scope": "e2e-only" }
+  ],
+  "humanGates": ["after:task-analyst"],
+  "autoChain": true,
+  "skipped": []
+}

package/presets/claude/next/team/fixtures/feature-light.json

@@ -0,0 +1,17 @@
+{
+  "slug": "example-feature-light",
+  "intent": "feature",
+  "profile": "light",
+  "summary": "Trivial single-file change with explicit AC",
+  "steps": [
+    { "agent": "feature-developer", "label": "Implement" },
+    { "agent": "build-verifier", "label": "Validation gate" }
+  ],
+  "humanGates": [],
+  "autoChain": true,
+  "skipped": [
+    { "agent": "task-analyst", "reason": "Explicit AC and single-file scope" },
+    { "agent": "code-reviewer", "reason": "Light profile — non-trivial app changes should use standard" },
+    { "agent": "qa-tester", "reason": "No e2e AC" }
+  ]
+}

package/presets/cursor/next/AGENTS.md

@@ -8,7 +8,7 @@ See `.cursor/rules/README.md` for the full catalog and loading strategy.
 
 | Задача | Куда смотреть |
 |--------|----------------|
-| Любая новая work-задача | `/task` → `commands/task.md` + `agent-team-orchestrator.mdc` |
+| Любая новая work-задача | `/task` → `commands/task.md` + `agent-team-orchestrator.mdc` (+ `agent-team-intake.mdc` on-demand) |
 | Новая фича end-to-end | skill `feature-delivery` + `feature-delivery-workflow.mdc` |
 | Стек и слои | `next-app-core.mdc` |
 | Эталонные фичи | `reference-features.mdc` (заполнить пути в репо) |
@@ -23,16 +23,9 @@ See `.cursor/rules/README.md` for the full catalog and loading strategy.
 - Простой one-liner без архитектурного риска — можно без pipeline, если пользователь явно просит.
 - Вопросы «как работает X» — ответ без `/task`.
 
-## Intent → pipeline (кратко)
+## Pipeline routing
 
-| intent | Типичный pipeline |
-|--------|-------------------|
-| `feature` | analyst → developer (+ unit) → build-verifier → reviewer → e2e/QA |
-| `bugfix` | debugger → developer (skip if fixed) → build-verifier → reviewer |
-| `ci-fix` | ci-investigator → developer (skip if resolved) → build-verifier |
-| `migration` | analyst → migration-specialist → developer → build-verifier → reviewer → QA |
-
-Полная таблица — `agents/README.md`, router — `agents/task-router.md`.
+Intent detection, profiles (`full` / `standard` / `light`), and default steps — **only** in `agents/task-router.md`. Schema and examples — `agents/README.md`.
 
 ## Install
 

package/presets/cursor/next/BUGBOT.md

@@ -12,3 +12,5 @@ Follow the **`code-review` skill** and **`code-review-mr.mdc`** for the full che
 ## Review style
 
 Lead with concrete findings: file, impact, fix direction. Skip style-only nits unless they violate lint rules or project conventions.
+
+**Source of truth:** `packages/ai-rules/fragments/BUGBOT.md` — sync manually when updating.

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

@@ -60,18 +60,100 @@
 
 Правило: `agent-team-orchestrator.mdc`. План: `pipeline.json` в `.cursor/team/tasks/<slug>/`.
 
-## Intent → pipeline (кратко)
-
-| intent | Типичный pipeline |
-|--------|-------------------|
-| `feature` | analyst → developer (+ unit) → build-verifier → reviewer → e2e/QA |
-| `bugfix` | debugger → developer (skipIf fixed) → build-verifier → reviewer |
-| `ci-fix` | ci-investigator → developer (skipIf resolved) → build-verifier |
-| `migration` | analyst → migration-specialist → developer → reviewer → QA |
-| `perf-audit` | performance-auditor |
-| `a11y` | analyst → developer → a11y-reviewer → code-reviewer |
-| `unit-only` | unit-planner → unit-generator (или healer) |
-| `e2e-only` | playwright planner → generator (или healer) |
-| `docs-only` | analyst → tech-writer |
-
-Опциональные шаги (router добавляет по контексту): `api-contract-reviewer`, `accessibility-reviewer`, `security-reviewer`, `performance-auditor`, `tech-writer`.
+## Pipeline routing
+
+**Source of truth:** intent table, profiles (`full` / `standard` / `light`), and default steps — **`task-router.md`** only. Do not duplicate intent→pipeline tables in entry docs.
+
+## pipeline.json reference
+
+### Top-level fields
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `slug` | yes | Task identifier |
+| `intent` | yes | From router intent detection |
+| `profile` | no | `full` \| `standard` \| `light` — see `task-router.md` § Pipeline profiles |
+| `summary` | yes | One-line task summary |
+| `steps` | yes | Ordered agent steps |
+| `humanGates` | no | e.g. `["after:task-analyst"]` |
+| `autoChain` | no | Default `true` |
+| `skipped` | no | Roles skipped with reason |
+
+### Step fields
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `agent` | yes | Subagent name (kebab-case) or array for `parallel: true` |
+| `label` | yes | Short human-readable step name |
+| `scope` | no | e.g. `unit-in-dev`, `e2e-only`, `regression`, `full` |
+| `skipIf` | no | `debugger.fixed` \| `ci-investigator.resolved` |
+| `parallel` | no | When `true` and `agent` is array — invoke all in one turn |
+
+### Minimal template
+
+```json
+{
+  "slug": "<slug>",
+  "intent": "feature",
+  "summary": "One-line task summary",
+  "steps": [
+    { "agent": "task-analyst", "label": "Clarify and decompose" },
+    { "agent": "feature-developer", "label": "Implement + unit tests", "scope": "unit-in-dev" },
+    { "agent": "build-verifier", "label": "Lint, type-check, unit smoke" },
+    { "agent": "code-reviewer", "label": "Code review" }
+  ],
+  "humanGates": ["after:task-analyst"],
+  "autoChain": true,
+  "skipped": []
+}
+```
+
+### Example: parallel reviewers
+
+```json
+{
+  "intent": "feature",
+  "steps": [
+    { "agent": "task-analyst", "label": "Clarify" },
+    { "agent": "feature-developer", "label": "Implement", "scope": "unit-in-dev" },
+    { "agent": "build-verifier", "label": "Validation gate" },
+    {
+      "agent": ["accessibility-reviewer", "security-reviewer"],
+      "parallel": true,
+      "label": "A11y and security"
+    },
+    { "agent": "code-reviewer", "label": "Review" }
+  ],
+  "humanGates": ["after:task-analyst"]
+}
+```
+
+### Example: bugfix skipIf
+
+```json
+{
+  "intent": "bugfix",
+  "steps": [
+    { "agent": "debugger", "label": "Root cause" },
+    { "agent": "feature-developer", "label": "Fix if needed", "skipIf": "debugger.fixed" },
+    { "agent": "build-verifier", "label": "Validation" },
+    { "agent": "code-reviewer", "label": "Review" }
+  ],
+  "humanGates": []
+}
+```
+
+### Initial status.json
+
+```json
+{
+  "slug": "<slug>",
+  "intent": "<intent>",
+  "pipelineIndex": 0,
+  "currentAgent": "<steps[0].agent>",
+  "phase": "executing",
+  "state": "in_progress",
+  "awaitingHumanGate": false,
+  "updatedAt": "<ISO8601>"
+}
+```

package/presets/cursor/next/agents/api-contract-reviewer.md

@@ -13,7 +13,7 @@ You are an API contract reviewer for a layered Next.js frontend (`@/types`, `@/a
 2. OpenAPI/Swagger spec, ticket API description, or backend contract docs from the user.
 3. Changed files in `app/src/types/**`, `app/src/api/**`, mocks, store thunks.
 
-Apply **`types-public-imports.mdc`**, **`api-public-imports.mdc`**, **`api-services.mdc`**, **`http-client.mdc`**.
+Apply **`public-imports.mdc`**, **`api-services.mdc`**, **`http-client.mdc`**.
 
 ## Review scope
 

package/presets/cursor/next/agents/build-verifier.md

@@ -7,6 +7,8 @@ model: fast
 
 You are a build verification specialist. You **validate** implementation quality before code review — you do not edit production code or tests.
 
+**SSOT for full validation in pipeline:** run complete **`lint:js`**, **`lint:css`**, and **`type-check`** from `app/` even if feature-developer ran scoped checks.
+
 ## Inputs
 
 1. `.cursor/team/tasks/<slug>/brief.md` and `decomposition.md`.

package/presets/cursor/next/agents/code-reviewer.md

@@ -2,7 +2,7 @@
 name: code-reviewer
 description: Expert code review specialist. Reviews after feature development using code-review-mr checklist. Use proactively after feature-developer completes or when the user asks for MR/diff review on a team task slug. Writes only review artifacts/status; never edits production code.
 readonly: true
-model: inherit
+model: fast
 ---
 
 You are a senior code reviewer. You may write only review artifacts under `.cursor/team/**` and update task `status.json`; do not modify production code.
@@ -13,7 +13,7 @@ You are a senior code reviewer. You may write only review artifacts under `.curs
 2. `.cursor/team/tasks/<slug>/decomposition.md` — check coverage of planned tasks.
 3. Git diff for changed files (`git diff`, `git status`).
 
-Apply the **`code-review` skill** and checklist from **`code-review-mr.mdc`**: architecture, imports (`@/types`, `@/api`), types, UI patterns, tests, HTTP client usage.
+Apply the **`code-review` skill** and **`code-review-mr.mdc`** checklist.
 
 ## Tests gate
 

package/presets/cursor/next/agents/feature-developer.md

@@ -8,41 +8,20 @@ You are a senior frontend developer working in a Next.js monorepo with strict la
 
 ## Before coding
 
-1. Read `.cursor/team/tasks/<slug>/brief.md` and `decomposition.md`.
-2. Read `architecture.md`, `migration-plan.md`, `api-contract-review.md`, `debug-report.md`, `validation-report.md`, and `review.md` if present.
-3. Read `status.json` — proceed if `state` is `in_progress`, `approved`, or continuing after `/task-continue` / fix loop (`retryAfterFix`).
-4. Read `pipeline.json` if present for step context and scope.
-5. Read **`reference-features.mdc`** and mirror the closest reference feature structure.
-6. Use the **`feature-delivery` skill** and **`feature-delivery-workflow.mdc`** for layer order.
+1. Read `.cursor/team/tasks/<slug>/brief.md`, `decomposition.md`, and prior artifacts if present (`architecture.md`, `debug-report.md`, `validation-report.md`, `review.md`, …).
+2. Read `status.json` — proceed if `in_progress`, `approved`, or `retryAfterFix`.
+3. Read `pipeline.json` for step context and scope.
+4. Follow the **`feature-delivery` skill** (layer order, reference features, validation handoff).
 
 ## Task execution rules
 
-- Do **not** start a task marked blocked or whose dependencies are incomplete.
-- Work tasks in dependency order (types → api → mocks → store → ui → **unit** → e2e).
-- **Unit tests are mandatory before handoff** for mappers, store logic, and non-trivial pure functions (`tests-unit.mdc`). E2E is usually a later pipeline step.
-- Mark completed tasks in `decomposition.md` with `[x]` or a **Done** column update.
-- After all code changes run **`post-change-lint.mdc`**: `lint:js`, `lint:css`, `type-check` from `app/`.
+- Do **not** start blocked tasks or tasks with incomplete dependencies.
+- **Unit tests mandatory before handoff** for mappers, store logic, and non-trivial pure functions.
+- Mark completed tasks in `decomposition.md`.
+- Validation: **`post-change-lint.mdc`**. If pipeline next step is **`build-verifier`**, scoped lint/type-check on **changed files** is enough; full project lint is build-verifier's job.
 
 ## On completion
 
-Update `status.json`:
-
-```json
-{
-  "slug": "<slug>",
-  "currentAgent": "feature-developer",
-  "phase": "executing",
-  "state": "completed",
-  "updatedAt": "<ISO8601>"
-}
-```
-
-Provide a short handoff summary:
-
-- Tasks completed vs remaining
-- Files changed (by layer)
-- Unit specs added/updated
-- Lint/type-check result
-- Known gaps for build-verifier or reviewer
+Update `status.json` (`currentAgent`: `feature-developer`, `state`: `completed`). Handoff: tasks done, files by layer, unit specs, validation result, gaps for build-verifier/reviewer.
 
 Do not perform formal code review — that is the code-reviewer subagent's job.

package/presets/cursor/next/agents/task-analyst.md

@@ -2,7 +2,7 @@
 name: task-analyst
 description: Task analysis specialist. Clarifies requirements, validates acceptance criteria, and decomposes work into concrete tasks. Use for /feature-start, task intake, or when the user asks to analyze or decompose a feature before coding. Writes only team artifacts; never writes production code.
 readonly: true
-model: inherit
+model: fast
 ---
 
 You are a senior business/technical analyst for a Next.js frontend team.