@bonesofspring/ai-rules 0.1.36 → 0.1.39

package/presets/claude/next/agents/task-router.md

@@ -0,0 +1,105 @@
+---
+name: task-router
+description: Task routing specialist. Analyzes user prompt, detects intent (feature, bugfix, review-only, test-only, refactor, spike, retro), and writes pipeline.json with ordered agent steps. Use first for /task or when determining which subagents to run and in what order. Writes only team artifacts; never writes production code.
+model: inherit
+---
+
+You are a task router for a Next.js frontend agent team. You **do not** implement tasks — you classify intent and plan the agent pipeline.
+
+## Inputs
+
+- User task description (from `/task` or orchestrator).
+- Optional: existing files under `.claude/team/tasks/<slug>/`.
+
+## Intent detection
+
+| intent | Signals in prompt | Default steps |
+|--------|-------------------|---------------|
+| `feature` | «добавь», «новая», «реализуй», «сделай», new UI/API/store | task-analyst → feature-developer → code-reviewer → qa-tester |
+| `bugfix` | «баг», «fix», «не работает», «падает», «ошибка», regression | debugger → feature-developer → code-reviewer → qa-tester (scope regression) |
+| `review-only` | «ревью», «review MR», «проверь diff», «code review» | code-reviewer |
+| `test-only` | «e2e», «покрой тестами», «напиши тесты» (no impl) | task-analyst → qa-tester |
+| `refactor` | «рефакторинг», «без изменения поведения», «почисти» | task-analyst → feature-developer → code-reviewer |
+| `spike` | «исследуй», «оцени», «можно ли», «spike», proof of concept | task-analyst → solution-architect |
+| `retro` | «ретро», «разбор», «postmortem» | no pipeline — orchestrator runs `/technical-retro` |
+
+Adjust steps when context is clear:
+
+- **Skip task-analyst** if AC and scope are fully specified in the prompt (document reason in `skipped`).
+- **Add solution-architect** for cross-layer features (API + store + UI), new public APIs, or architecture uncertainty.
+- **Skip qa-tester** for review-only, spike (no code), or trivial one-line fixes (document risk).
+- **Skip feature-developer** for review-only, test-only (tests only), retro.
+
+## Output: pipeline.json
+
+Write to `.claude/team/tasks/<slug>/pipeline.json`:
+
+```json
+{
+  "slug": "<slug>",
+  "intent": "feature",
+  "summary": "One-line task summary",
+  "steps": [
+    { "agent": "task-analyst", "label": "Clarify and decompose" },
+    { "agent": "feature-developer", "label": "Implement" },
+    { "agent": "code-reviewer", "label": "Code review" },
+    { "agent": "qa-tester", "label": "Unit and e2e tests", "scope": "full" }
+  ],
+  "humanGates": ["after:task-analyst"],
+  "autoChain": true,
+  "skipped": []
+}
+```
+
+### Step fields
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `agent` | yes | Subagent name (kebab-case) |
+| `label` | yes | Short human-readable step name |
+| `scope` | no | e.g. `full`, `regression`, `e2e-only` — passed to qa-tester |
+
+### humanGates
+
+Values: `after:<agent-name>` — orchestrator stops after that agent; user runs `/task-continue <slug>` or `/feature-continue <slug>`.
+
+- Default for `feature`, `refactor`, `test-only`: `["after:task-analyst"]`
+- Default for `bugfix`, `review-only`: `[]` (unless analyst added)
+- `spike`: `["after:solution-architect"]`
+
+### skipped (optional)
+
+```json
+"skipped": [{ "agent": "task-analyst", "reason": "AC provided in ticket" }]
+```
+
+## Initial status.json
+
+After writing pipeline.json, write:
+
+```json
+{
+  "slug": "<slug>",
+  "intent": "<intent>",
+  "pipelineIndex": 0,
+  "currentAgent": "<steps[0].agent>",
+  "phase": "executing",
+  "state": "in_progress",
+  "awaitingHumanGate": false,
+  "updatedAt": "<ISO8601>"
+}
+```
+
+Also write `.claude/team/active-task.json` → `{ "slug": "<slug>" }`.
+
+## Handoff to orchestrator
+
+Respond with:
+
+1. **Intent** and one-line summary.
+2. **Planned steps** (table: #, agent, label).
+3. **Skipped roles** and why.
+4. **Human gates** (if any).
+5. Tell orchestrator to invoke `steps[0].agent` now (unless intent is `retro` — then run `/technical-retro`).
+
+Do not invoke implementation agents yourself.

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

@@ -1,5 +1,9 @@
 # `.claude/commands` (preset next)
 
-Определения slash-команд для проекта. Копируются в `.claude/commands/` при `ai-rules init claude --preset next`.
+Определения slash-команд и on-demand сценариев. Копируются в `.claude/commands/` при `ai-rules init claude --preset next`.
+
+| Файл | Назначение |
+|------|------------|
+| `technical-retro.md` | Фасилитация технического ретро (не дублируется в `rules/` — экономия контекста) |
 
 См. также корневой `README.md` пресета — у Claude Code помимо `rules/` и `commands/` часто используются `skills/`, `agents/`, `hooks/`.

package/presets/claude/next/commands/feature-continue.md

@@ -0,0 +1,46 @@
+# Feature continue — продолжение после утверждения brief
+
+Legacy-команда для продолжения после human gate. Для новых пайплайнов с `pipeline.json` используй те же правила, что в `/task-continue`.
+
+## Аргументы
+
+`<slug>` — идентификатор задачи из `.claude/team/tasks/<slug>/`.
+
+## Preconditions
+
+1. Прочитай `.claude/team/tasks/<slug>/brief.md` и `decomposition.md`.
+2. Если есть `pipeline.json`, делегируй поведение `/task-continue <slug>`.
+3. Если `pipeline.json` нет, прочитай `status.json`. Продолжай только если:
+   - `phase` is `analysis` and `state` is `awaiting_approval` (user explicitly approved via this command), **or**
+   - `phase` is `development`/`review`/`testing` and work should resume.
+
+## Legacy алгоритм без `pipeline.json`
+
+1. Обнови `status.json`:
+   ```json
+   {
+     "slug": "<slug>",
+     "phase": "development",
+     "state": "approved",
+     "updatedAt": "<ISO8601>"
+   }
+   ```
+   Затем сразу установи `"state": "in_progress"` перед вызовом developer.
+
+2. Запиши `.claude/team/active-task.json` → `{ "slug": "<slug>" }`.
+
+3. Вызови subagent **feature-developer** с контекстом:
+   - пути к `brief.md`, `decomposition.md`, `status.json`;
+   - указание следовать `rules/architecture/feature-delivery-workflow.md`.
+
+4. После завершения developer продолжи review → QA по `rules/tooling-and-review/agent-team-orchestrator.md`.
+
+## Если review вернул changes_requested
+
+- Верни `phase` в `development`, `state` в `in_progress`.
+- Снова вызови **feature-developer** с списком правок от reviewer.
+
+## Не делать
+
+- Не пропускать human gate без явного `/feature-continue`.
+- Не совмещать роли developer и reviewer в одном subagent-вызове.

package/presets/claude/next/commands/feature-start.md

@@ -0,0 +1,25 @@
+# Feature start — legacy команда агентов
+
+Запуск **фазы анализа** для новой задачи. Для новых задач предпочтительнее `/task`, потому что он сначала строит dynamic pipeline через `task-router`.
+
+## Что делать
+
+1. Извлеки описание задачи из аргументов команды (всё после `/feature-start`).
+2. Сгенерируй **slug** (kebab-case, до 48 символов) из заголовка задачи.
+3. Создай каталог `.claude/team/tasks/<slug>/` если его ещё нет.
+4. Запиши `.claude/team/active-task.json` → `{ "slug": "<slug>" }`.
+5. Вызови subagent **task-analyst** с полным описанием задачи и путём к артефактам.
+6. Дождись завершения аналитика. **Не вызывай developer** на этом этапе.
+
+## Human gate
+
+После аналитика:
+
+- Покажи пользователю ссылки на `brief.md` и `decomposition.md`.
+- Попроси проверить и утвердить или прислать правки.
+- Для продолжения: `/feature-continue <slug>` или `/task-continue <slug>`.
+
+## Если slug уже существует
+
+- Если `status.json` в `awaiting_approval` — предложи ревью или `/feature-continue`.
+- Если задача в работе — спроси, продолжать или начать новый slug.

package/presets/claude/next/commands/task-continue.md

@@ -0,0 +1,43 @@
+# Task continue — после human gate или паузы
+
+Продолжение пайплайна из `pipeline.json`. Алиас по смыслу: `/feature-continue`.
+
+## Аргументы
+
+`<slug>` — идентификатор задачи.
+
+## Preconditions
+
+1. Прочитай `.claude/team/tasks/<slug>/pipeline.json` и `status.json`.
+2. Продолжай если:
+   - `awaitingHumanGate: true` или `state: awaiting_approval`, **или**
+   - `state: changes_requested` (после review), **или**
+   - задача прервана и нужно возобновить с `pipelineIndex`.
+
+## Алгоритм
+
+1. Запиши `.claude/team/active-task.json` → `{ "slug": "<slug>" }`.
+2. Сбрось gate: `awaitingHumanGate: false`.
+3. Определи **следующий шаг**:
+   - После approval analyst/architect: `pipelineIndex + 1` → следующий agent в `steps`.
+   - После `changes_requested`: снова **feature-developer** (тот же index или найди developer в steps).
+4. Обнови `status.json`:
+   ```json
+   {
+     "pipelineIndex": <n>,
+     "currentAgent": "<steps[n].agent>",
+     "phase": "executing",
+     "state": "in_progress",
+     "awaitingHumanGate": false
+   }
+   ```
+5. Вызови subagent для `currentAgent` с контекстом slug и артефактов.
+6. Если hook `chain-team-phases.sh` включён в проекте и `autoChain: true`, он продолжит цепочку по `pipeline.json`; иначе продолжай следующий шаг вручную.
+
+## Артефакты для handoff
+
+| Agent | Прочитать |
+|-------|-----------|
+| feature-developer | brief.md, decomposition.md, architecture.md (if exists), debug-report.md (if exists) |
+| code-reviewer | brief.md, git diff |
+| qa-tester | brief.md, decomposition.md, scope from pipeline step |

package/presets/claude/next/commands/task.md

@@ -0,0 +1,40 @@
+# Task — единая точка входа
+
+Главная команда для постановки задачи в Claude Code. Родительский агент = оркестратор, правила — `rules/tooling-and-review/agent-team-orchestrator.md`.
+
+## Аргументы
+
+Всё после `/task` — описание задачи на естественном языке.
+
+Примеры:
+
+- `/task Добавить фильтр по дате в Order History`
+- `/task Order History падает при пустом списке — пофикси`
+- `/task Сделай ревью моих изменений в store/orders`
+- `/task Напиши e2e для сценария оплаты`
+
+## Алгоритм
+
+1. **Slug** — kebab-case из описания (≤48 символов). Создай `.claude/team/tasks/<slug>/`.
+2. **Router** — вызови subagent **task-router** с описанием задачи и путём к slug.
+3. **План** — покажи пользователю таблицу из `pipeline.json`: intent, steps, skipped, humanGates.
+4. **Intent retro** — если `intent === "retro"`, выполни `/technical-retro` и **остановись**.
+5. **Старт** — вызови subagent для `pipeline.steps[0].agent`:
+   - передай slug, пути к артефактам, scope из step (если есть);
+   - обнови `status.json`: `pipelineIndex: 0`, `currentAgent`, `state: in_progress`.
+6. **Human gate** — если после текущего шага есть gate в `humanGates` (`after:<agent>`), после завершения агента **остановись** и попроси `/task-continue <slug>` (или `/feature-continue <slug>`).
+
+## Не делать
+
+- Не вызывать developer до router и (если в pipeline) analyst/architect.
+- Не hardcode порядок ролей — только `pipeline.json`.
+- Не пропускать human gate без явного continue.
+
+## Если slug занят
+
+- `awaitingHumanGate` / `state: awaiting_approval` → предложи ревью артефактов или `/task-continue <slug>`.
+- `in_progress` → спроси: продолжить или новый slug.
+
+## Legacy
+
+`/feature-start` и `/feature-continue` остаются совместимыми; для новых задач предпочитай `/task`.

package/presets/claude/next/commands/technical-retro.md

@@ -0,0 +1,53 @@
+# Техническое ретро — роль агента
+
+Агент выступает как **нейтральный фасилитатор технической ретроспективы**, а не как ревьюер кода или оценщик людей. Цель — вынести уроки, согласовать действия и улучшить процесс разработки.
+
+## Когда включать
+
+- Пользователь просит: «ретро», «техническое ретро», «разбор спринта/итерации», «что пошло хорошо / плохо», «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‑рекомендации; при явных конфликтах или токсичности — мягко предложить эскалацию человеку, ответственному за команду, без детализации «наказаний».
+- Если пользователь просит только шаблон — выдать **шаблон повестки и доски** (колонки, таймбоксы) без выдуманного контента.

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

@@ -1,16 +1,52 @@
 # `.claude/rules` (preset next)
 
-В Claude Code все `.md` под `rules/` **обнаруживаются рекурсивно** — подпапки по темам уместнее, чем один длинный файл.
+В Claude Code все `.md` под `rules/` **обнаруживаются рекурсивно**. Правила без YAML frontmatter загружаются **в начале сессии**; с `paths:` — **только при работе** с matching-файлами (экономия контекста).
 
-Соответствие темам из пресета Cursor (для переноса смысла из `.mdc`):
+Соответствие пресету Cursor (`.cursor/rules/*.mdc`):
 
-| Папка | О чём |
-|-------|--------|
-| `stack/` | Next.js, React, TypeScript |
-| `architecture/` | границы слоёв, модули |
-| `api-and-data/` | сервисы, API, данные |
-| `testing/` | unit, e2e, Playwright |
-| `ui-and-accessibility/` | UI, a11y, без spread props там, где это правило команды |
-| `tooling-and-review/` | качество кода, ревью MR |
+| Папка | О чём | Загрузка |
+|-------|--------|----------|
+| `architecture/` | границы слоёв, barrel, импорты, доставка фичи | session start |
+| `stack/` | Next.js, TS, навигация, JSDoc типов | core — session; `types-jsdoc.md` — `paths: app/src/types/**` |
+| `api-and-data/` | HTTP, сервисы, store | `paths:` по каталогам слоя |
+| `ui-and-accessibility/` | React UI, стили, a11y, пропсы | core — session; `react-ui.md` — `paths: app/src/ui/**` |
+| `testing/` | unit, e2e, Playwright agents | `tests-unit.md`, `tests-e2e-structure.md` — `paths:`; `playwright-agents.md` — session start |
+| `tooling-and-review/` | lint, package manager, качество, MR review | session start |
 
-Добавляйте сюда `.md` файлы с осмысленными именами (`testing.md`, `api-design.md`, …).
+On-demand сценарии вне постоянного контекста — в `commands/` (например `technical-retro.md`).
+
+## С чего начать новую фичу
+
+**`architecture/feature-delivery-workflow.md`** — сквозной чеклист и матрица «зона репозитория → правило».
+
+## Каталог правил
+
+| Файл | Назначение |
+|------|------------|
+| `tooling-and-review/package-manager.md` | Менеджер пакетов перед install/run |
+| `architecture/feature-delivery-workflow.md` | Сквозной порядок работ по фиче, mermaid, матрица слой → правило |
+| `stack/next-app-core.md` | Стек, слои, порты‑адаптеры, работа агента |
+| `tooling-and-review/post-change-lint.md` | **Обязательный** ESLint + Stylelint после изменений |
+| `architecture/architecture-boundaries.md` | Границы UI / store / API, импорты, фича как срез |
+| `api-and-data/http-client.md` | Единый HTTP‑стек, контракты из `@/types` |
+| `api-and-data/api-services.md` | Сервисы, мапперы, прикладные API‑клиенты |
+| `api-and-data/store-rtk.md` | Redux Toolkit, thunk’и, типизация ошибок |
+| `architecture/types-public-imports.md` | Импорты только через barrel `@/types` |
+| `architecture/api-public-imports.md` | Импорты только через barrel `@/api` |
+| `architecture/layer-barrel-exports.md` | Двухуровневые barrel для слоёв с public API |
+| `stack/types-jsdoc.md` | JSDoc для типов в `app/src/types` |
+| `stack/no-type-assertion.md` | Ограничение `as`, `instanceof` для ошибок транспорта |
+| `tooling-and-review/code-review-mr.md` | Чеклист ревью MR |
+| `testing/tests-unit.md` | Unit‑тесты и behavior‑тесты HTTP‑клиента |
+| `testing/playwright-agents.md`, `testing/tests-e2e-structure.md` | E2e |
+| `ui-and-accessibility/react-ui.md` | React/Next UI: структура, `.data.ts` / `.utils.ts`, стили |
+| `ui-and-accessibility/no-props-spread.md` | Без spread пропов в компонентах |
+| `ui-and-accessibility/component-styles.md` | Колокация стилей, `Root` |
+| `ui-and-accessibility/css-property-order.md` | Порядок CSS (Stylelint) |
+| `stack/arrow-functions.md` | Стрелочные функции |
+| `stack/navigation-router.md` | Навигация по стеку проекта |
+| `tooling-and-review/code-quality.md` | Качество кода и рефакторинг |
+
+**Коллизии:** импорт типов — **`architecture/types-public-imports.md`**; импорт API вне `app/src/api/**` — **`architecture/api-public-imports.md`**.
+
+Задачи на **сеть, HTTP, эндпоинты**: **`api-and-data/http-client.md`** + **`api-and-data/api-services.md`** + **`api-and-data/store-rtk.md`**.

package/presets/claude/next/rules/api-and-data/README.md

@@ -1,3 +1,9 @@
 # API and data
 
-Конвенции сервисов, API-слоя и работы с данными.
+HTTP-транспорт, сервисы, Redux store.
+
+| Файл | Содержание | `paths:` |
+|------|------------|----------|
+| `http-client.md` | Единый HTTP-клиент, ошибки, связь со store | `app/src/lib/clients/**`, `app/src/api/clients/**` |
+| `api-services.md` | Сервисы, мапперы, DTO → домен | `app/src/api/services/**` |
+| `store-rtk.md` | Redux Toolkit, thunk'и, типизация | `app/src/store/**` |

package/presets/claude/next/rules/api-and-data/api-services.md

@@ -0,0 +1,57 @@
+---
+paths:
+  - app/src/api/services/**/*.ts
+---
+
+# Роль API слоя
+
+- Инкапсулировать всё, что связано с:
+  - HTTP‑запросами через **экземпляры прикладных API‑клиентов** в `app/src/api/clients/**`, собранные на **общей реализации** из `app/src/lib/clients/**` (как в существующем коде); подробности — **`api-and-data/http-client.md`**; положение слоя в схеме **порты и адаптеры** — `architecture/architecture-boundaries.md`;
+  - URL/путями,
+  - заголовками и кодами ответов,
+  - DTO backend.
+- Предоставлять UI и store **стабильный доменный интерфейс**:
+  - функции, работающие с доменными типами из `@/types` (`architecture/types-public-imports.md`).
+  - мапперы между DTO и доменными типами.
+
+# Структура модулей
+
+- Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
+  - отдельный каталог в `app/src/api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
+- Внутри модуля:
+  - файлы с вызовами API (`index.ts` или `*.service.ts`);
+  - файлы мапперов (`*responseMappers.ts`);
+  - специфичные типы запросов/ответов (если не вынесены в `app/src/types/**` с экспортом через barrel `@/types`).
+  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `app/src/api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `app/src/api/index.ts` (`import … from '@/api'`, **`architecture/api-public-imports.md`**).
+
+# Мапперы и типы
+
+- Для каждого запроса/эндпоинта:
+  - описывать **response‑тип (DTO)**, точно соответствующий контракту backend;
+  - определять **целевой доменный тип** в `app/src/types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
+- Мапперы (например, `*responseMappers.ts`):
+  - чистые функции, без сайд‑эффектов;
+  - выполняют все необходимые вычисления и преобразования данных (булевы флаги, склейка строк, агрегаты и т.п.) при переводе из DTO в доменные модели;
+  - при необходимости обеспечивают обратное преобразование (доменные модели → транспортные типы).
+- UI и store работают только с доменными типами (из `@/types` или экспортируемыми из public API слоя API), а не с «сырыми» DTO.
+- **Не вызывать `fetch` напрямую** в теле API‑методов: только через клиент; исключения — узкие модули (например JSON‑RPC), если так уже устроено в репозитории.
+
+# Обработка ошибок
+
+- API‑слой:
+  - не должен «глотать» ошибки без следа;
+  - либо бросает доменные/унифицированные ошибки;
+  - либо возвращает результат в `Result<T, E>`‑подобной форме (если такой паттерн принят в проекте).
+- Интеграция с APM/трассировкой (если есть в проекте):
+  - централизованно (HTTP‑клиент, обёртки), а не в каждом методе сервиса.
+
+# Требование к агенту
+
+При добавлении/изменении API‑метода:
+
+- Следовать существующим сервисам и мапперам как эталону.
+- Пройти чеклист barrel-экспортов (**`architecture/layer-barrel-exports.md`**): локальный `index.ts` → фасад слоя → корневой barrel.
+- Не смешивать слой API и UI/store:
+  - компоненты не должны зависеть от DTO;
+  - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы во thunk при разборе `catch`/payload, если так выстроен сервис (см. `api-and-data/store-rtk.md`, `api-and-data/http-client.md`).
+- При использовании API‑сервисов в UI, store и утилитах **вне** `app/src/api/**` импортировать **только** из `@/api` (корневой barrel), см. **`architecture/api-public-imports.md`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.

package/presets/claude/next/rules/api-and-data/http-client.md

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

package/presets/claude/next/rules/api-and-data/store-rtk.md

@@ -0,0 +1,65 @@
+---
+paths:
+  - app/src/store/**/*.ts
+---
+
+# Общие принципы
+
+- Использовать **Redux Toolkit**:
+  - `createSlice`, `createAsyncThunk`, RTK Query (если используется).
+- Хранить в store **доменные модели**, не «сырые» DTO из API.
+- Все вычисления и преобразования данных (включая вычисляемые поля, булевые флаги, агрегаты, человеко‑читаемые строки и т.п.) должны выполняться **между ответом API и записью в store** — в мапперах или отдельном слое подготовки данных. Store хранит уже подготовленную доменную модель.
+- Разделять:
+  - «серверное» состояние (данные из API) и
+  - локальное UI‑состояние (выбор/фильтры/флаги).
+
+# Структура слайсов
+
+- Каждый доменный модуль — свой слайс в `app/src/store/slices/**`.
+- Слайс экспортирует:
+  - `reducer` по умолчанию;
+  - `actions` именованным экспортом;
+  - селекторы `selectSomething(state: RootState): Type`.
+- Состояние:
+  - явный тип для state;
+  - аккуратная инициализация initialState.
+
+# Асинхронность и сайд‑эффекты
+
+- Асинхронные запросы:
+  - через `createAsyncThunk` или RTK Query.
+  - внутри thunk:
+    - вызывать API через сервисы, импортированные из `@/api` (**`architecture/api-public-imports.md`**);
+    - не вызывать HTTP‑клиент напрямую — только через эти сервисы.
+- Сайд‑эффекты (логирование, аналитика, работа с файлами):
+  - выносить в middleware (`app/src/store/middleware/**`) или специализированные слайсы.
+
+# Типизация
+
+- Использовать `RootState`, `AppDispatch` и типизированные хуки `useAppDispatch`, `useAppSelector` (если есть).
+- **HTTP и ошибки API**:
+  - не импортировать типы **сторонних HTTP‑библиотек**, которых нет в актуальных зависимостях и существующих слайсах (ориентир — **`package.json`** и соседние файлы);
+  - когда сервис возвращает **обёртку ответа** прикладного клиента — использовать **соответствующий тип из `@/types`** (как в barrel и в аналогичных thunk’ах);
+  - при ошибках после вызова сервиса — опираться на **тот же класс/контракт ошибки транспорта**, что использует общий клиент (из `@/types`), и разбирать тело/статус **по полям текущей реализации**, а не по воображаемому API;
+  - в **`catch`** предпочитать **`instanceof`** на класс ошибки транспорта из `@/types` (если он есть в коде) вместо голого `as`, когда это выразимо без шума (см. `stack/no-type-assertion.md`).
+- Для сущностей:
+  - доменные типы (включая вычисляемые поля) определять в `app/src/types/**`, экспортировать через barrel и импортировать в слайсы из `@/types` как **источник правды** (`architecture/types-public-imports.md`);
+  - избегать дублирования описаний сущностей в нескольких местах.
+- **Граница домена**: в **state** хранить доменные модели; тип **обёртки ответа клиента** допустим как тип **возвращаемого значения thunk** или промежуточно до маппинга — без дублирования DTO в полях state без нужды (согласовано с `api-and-data/api-services.md` и `api-and-data/http-client.md`).
+
+# Тестирование слайсов
+
+- Для важных слайсов:
+  - тестировать редюсеры (инициализация, основные переходы состояний);
+  - тестировать селекторы (включая edge cases).
+- Thunk’и:
+  - по возможности покрывать тестами с моками API‑слоя.
+
+# Требование к агенту
+
+При изменении/создании слайса:
+
+- Не класть логику API внутрь редюсеров/компонентов.
+- Строго типизировать state и actions.
+- Использовать **единый стиль именования actions и селекторов**, как в существующих слайсах.
+- При работе с ошибками и ответами HTTP опираться на **`api-and-data/http-client.md`** и контракты из `@/types`, а не на типы внешних HTTP‑библиотек вне зависимостей проекта.

package/presets/claude/next/rules/architecture/README.md

@@ -1,3 +1,13 @@
 # Architecture
 
-Границы модулей, слоёв и зависимостей (аналог темы architecture / boundaries в Cursor-пресете).
+Границы модулей, слоёв, зависимостей и сквозная доставка фич.
+
+| Файл | Содержание |
+|------|------------|
+| `architecture-boundaries.md` | UI / store / API, порты и адаптеры, организация фич |
+| `layer-barrel-exports.md` | Двухуровневые barrel и чеклист public API |
+| `types-public-imports.md` | Импорт типов только через `@/types` |
+| `api-public-imports.md` | Импорт API только через `@/api` |
+| `feature-delivery-workflow.md` | Чеклист новой фичи, матрица зона → правило |
+
+Все файлы — **session start** (без `paths:`).

package/presets/claude/next/rules/architecture/api-public-imports.md

@@ -0,0 +1,25 @@
+# Импорты из `@/api`
+
+- **Публичный 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 по **`architecture/layer-barrel-exports.md`**.
+
+## Внутри слоя `app/src/api/**`
+
+- При реализации сервисов, клиентов и barrel допустимы **относительные** импорты и пути вида `@/api/services/**`, `@/api/clients/**` между файлами этого слоя. Это не относится к потребителям снаружи `app/src/api/**`.
+
+## Примеры
+
+```typescript
+// ✅ Допустимо в store, UI, lib вне app/src/api — только barrel
+import { MedcardApiService, MarketplaceApiService } from '@/api'
+import type { TReferenceRequest } from '@/api'
+
+// ❌ Запрещено снаружи app/src/api (сработает ESLint)
+import { MedcardApiService } from '@/api/services/MedcardApiService/MedcardApiService'
+import { MedcardApiClient } from '@/api/clients/MedcardApiClient'
+```
+
+При ревью и правках кода **не добавлять** новые импорты из `@/api/...` кроме `@/api` / `@/api/index` в файлах вне `app/src/api/**`.
+
+**Коллизии формулировок:** по **импорту из API‑слоя** (store, UI, прочий код вне `app/src/api/**`) — источник правды — **этот файл** (`@/api`).