@bonesofspring/ai-rules 0.2.14 → 0.2.15

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

@@ -3,59 +3,59 @@ name: technical-retro
 description: Facilitate a technical retrospective for a period, incident, release, or completed agent-team task slug.
 ---
 
-# Техническое ретро — роль агента
+# Technical retrospective — agent role
 
-Агент выступает как **нейтральный фасилитатор технической ретроспективы**, а не как ревьюер кода или оценщик людей. Цель — вынести уроки, согласовать действия и улучшить процесс разработки. Используй skill **`technical-retro`** как основной сценарий.
+The agent acts as a **neutral facilitator of a technical retrospective**, not as a code reviewer or people evaluator. Goal — extract lessons, align actions, and improve the development process. Use skill **`technical-retro`** as the primary scenario.
 
-## Когда включать
+## When to use
 
-- Пользователь просит: «ретро», «техническое ретро», «разбор спринта/итерации», «что пошло хорошо / плохо», «action items после релиза».
-- Есть контекст: период (спринт, квартал), тема (релиз, инцидент, миграция), или приложены заметки/линки.
+- User asks: "retro", "technical retro", "sprint/iteration review", "what went well / poorly", "action items after release" — also common RU phrasing: «ретро» (retro), «техническое ретро» (technical retro), «разбор спринта/итерации» (sprint/iteration review) <!-- i18n-keep: E4 -->.
+- Context available: period (sprint, quarter), topic (release, incident, migration), or attached notes/links.
 
-## Входные данные (запросить при нехватке)
+## Inputs (request when missing)
 
-- **Период и фокус** (например: две недели, релиз X, постмортем).
-- **Участники/роли** (если важно для формулировок): только разработка или весь кросс‑функциональный поток.
-- **Ограничения**: время (15 / 30 / 60 мин), формат (async в чате vs синхронная повестка).
-- По желанию: список deliverables, метрики, ссылки на тикеты/MR — **без выдумывания** фактов, которых нет в сообщении или репозитории.
+- **Period and focus** (for example: two weeks, release X, postmortem).
+- **Participants/roles** (if relevant for wording): development only or full cross-functional flow.
+- **Constraints**: time (15 / 30 / 60 min), format (async in chat vs sync agenda).
+- Optional: deliverables list, metrics, ticket/MR links — **without inventing** facts not in the message or repository.
 
-Если контекста мало — задать **1–3 коротких уточняющих вопроса**, затем продолжить с явными допущениями в шапке вывода.
+If context is thin — ask **1–3 short clarifying questions**, then continue with explicit assumptions in the output header.
 
-## Принципы фасилитации
+## Facilitation principles
 
-- **Безопасность и нейтральность**: формулировки про процесс и систему, не про «виноватых»; избегать ярлыков к людям.
-- **Конкретика**: от абстрактного «надо лучше общаться» — к наблюдаемым событиям и договорённостям.
-- **Баланс**: зафиксировать и позитив (что усилить), и зоны роста.
-- **Один владелец и срок** у каждого action item; избегать списка «сделает команда» без имени/роли.
-- **Не смешивать с code review**: ретро не заменяет построчный разбор диффа; при запросе «и ретро, и ревью» — развести два блока в ответе.
+- **Safety and neutrality**: wording about process and system, not "blame"; avoid labeling people.
+- **Specificity**: from abstract "communicate better" to observable events and agreements.
+- **Balance**: capture positives (what to amplify) and growth areas.
+- **One owner and deadline** per action item; avoid "the team will do it" without a name/role.
+- **Do not mix with code review**: retro does not replace line-by-line diff review; if both are requested — separate two blocks in the response.
 
-## Рекомендуемая структура сессии (по умолчанию)
+## Recommended session structure (default)
 
-Подстроить под указанное время. Для короткого async‑формата — сжать до шагов 2–4.
+Adjust to the time given. For a short async format — compress to steps 2–4.
 
-1. **Цель и рамки** (1–2 предложения): зачем встреча, что в фокусе / что вне скоупа.
-2. **Сбор фактов** (молча в чате — списком от пользователя; агент структурирует):
-   - что шло хорошо,
-   - что мешало / вызывало риски,
-   - сюрпризы (технический долг, узкие места, зависимости).
-3. **Группировка тем**: объединить дубли, выделить 3–7 тем для обсуждения (приоритет — влияние × изменяемость).
-4. **Корневые причины (легко)**: для 1–2 самых болезненных тем — кратко «5 почему» или «что в процессе/артефактах позволило этому случиться», без морализаторства.
-5. **Эксперименты на следующий цикл**: не больше 1–3 изменений процесса/инструментов; каждое — измеримое или с явным критерием «успех/не успех».
-6. **Action items**: таблица или список с **что / владелец / до когда / как поймём, что сработало**.
+1. **Goal and scope** (1–2 sentences): why the session, what is in / out of scope.
+2. **Fact gathering** (async in chat — user lists; agent structures):
+   - what went well,
+   - what blocked / caused risk,
+   - surprises (tech debt, bottlenecks, dependencies).
+3. **Theme grouping**: merge duplicates, pick 3–7 themes (priority — impact × changeability).
+4. **Root causes (light)**: for 1–2 most painful themes — brief "5 whys" or "what in process/artifacts allowed this", without moralizing.
+5. **Experiments for next cycle**: at most 1–3 process/tool changes; each measurable or with explicit success/failure criteria.
+6. **Action items**: table or list with **what / owner / by when / how we know it worked**.
 
-## Формат ответа агента
+## Agent response format
 
-- Краткая **шапка**: период, фокус, допущения (если были).
-- **Повестка** или итог по этапам выше.
-- **Темы** — буллеты; по спорным местам — **вопросы команде**, а не окончательные выводы без данных.
-- **Решения и эксперименты** отдельным блоком.
-- **Action items** — в конце, каждый пункт с владельцем и дедлайном (или пометка «нужно назначить на встрече»).
+- Brief **header**: period, focus, assumptions (if any).
+- **Agenda** or outcome by stages above.
+- **Themes** — bullets; disputed points — **questions for the team**, not final conclusions without data.
+- **Decisions and experiments** in a separate block.
+- **Action items** at the end, each with owner and deadline (or "assign in meeting").
 
-## Ограничения
+## Constraints
 
-- Не приписывать команде цитаты или факты, которых не было во входе.
-- Не выдавать юридические/HR‑рекомендации; при явных конфликтах или токсичности — мягко предложить эскалацию человеку, ответственному за команду, без детализации «наказаний».
-- Если пользователь просит только шаблон — выдать **шаблон повестки и доски** (колонки, таймбоксы) без выдуманного контента.
+- Do not attribute quotes or facts not in the input.
+- No legal/HR recommendations; on clear conflict or toxicity — gently suggest escalation to the person responsible for the team, without "punishment" details.
+- If only a template is requested — **agenda and board template** (columns, timeboxes) without invented content.
 
 ### Metrics evidence
 

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

@@ -1,6 +1,6 @@
 # `.claude/rules` (preset next)
 
-В Claude Code все `.md` под `rules/` **обнаруживаются рекурсивно**. Тела **derived** из Cursor SoT; индексы — не второй SoT.
+In Claude Code all `.md` files under `rules/` are **discovered recursively**. Bodies are **derived** from Cursor SoT; indexes are not a second SoT.
 
 ## SoT sync
 
@@ -14,22 +14,22 @@
 
 ## Loading strategy
 
-- **Session start (no `paths:`):** ровно **3** — `next-app-core`, `package-manager`, `code-quality`
-- **On-demand (`paths:` or via commands):** `post-change-lint` (**обязателен после правок кода**), `agent-team-intake`, `agent-team-orchestrator`, `code-review-mr`, `security-next`, architecture, imports, UI, tests, feature-delivery-workflow, `design-guidance`, `anti-sycophancy-discipline`, `react-next-anti-hallucination`, reference-features, next-app-router, react-a11y-coding, `technical-retro`, **preset-*** meta (paths on `packages/ai-rules/presets/**`)
+- **Session start (no `paths:`):** exactly **3** — `next-app-core`, `package-manager`, `code-quality`
+- **On-demand (`paths:` or via commands):** `post-change-lint` (**must after code edits**), `agent-team-intake`, `agent-team-orchestrator`, `code-review-mr`, `security-next`, architecture, imports, UI, tests, feature-delivery-workflow, `design-guidance`, `anti-sycophancy-discipline`, `react-next-anti-hallucination`, reference-features, next-app-router, react-a11y-coding, `technical-retro`, **preset-*** meta (paths on `packages/ai-rules/presets/**`)
 - **Skills:** long workflows (`feature-delivery`, `code-review`, …)
 
 ### UI edit bundle (consolidated paths)
 
-При правке `app/src/ui/**/*.tsx` подгружается **уменьшенный** набор:
+When editing `app/src/ui/**/*.tsx`, a **reduced** set loads:
 
-| Rule | Назначение |
+| Rule | Purpose |
 |------|------------|
-| `ui-and-accessibility/react-ui.md` | Структура, стили, пропсы |
-| `architecture/architecture-boundaries-ui.md` | Slim границы UI-слоя |
+| `ui-and-accessibility/react-ui.md` | Structure, styles, props |
+| `architecture/architecture-boundaries-ui.md` | Slim UI layer boundaries |
 | `ui-and-accessibility/react-a11y-coding.md` | A11y |
-| `stack/navigation-router-ui.md` | Краткий ориентир навигации |
+| `stack/navigation-router-ui.md` | Short navigation guide |
 
-**Не грузятся на типичный UI edit:** `architecture/architecture-boundaries.md` (api/store/types/lib), `architecture/layer-barrel-exports.md` (только `index.ts`), `stack/navigation-router.md` (только `app/src/app/**`). Стили колокации — в `react-ui.md` (не отдельный stub).
+**Not loaded on a typical UI edit:** `architecture/architecture-boundaries.md` (api/store/types/lib), `architecture/layer-barrel-exports.md` (only `index.ts`), `stack/navigation-router.md` (only `app/src/app/**`). Colocated styles — in `react-ui.md` (not a separate stub).
 
 ## Cursor → Claude mapping
 
@@ -92,17 +92,17 @@
 
 ## Folders
 
-| Папка | О чём |
+| Folder | About |
 |-------|--------|
 | `stack/` | Next core, router, conventions |
-| `architecture/` | Границы, feature-delivery, reference-features, imports |
+| `architecture/` | Boundaries, feature-delivery, reference-features, imports |
 | `api-and-data/` | HTTP, services, store |
 | `anti-hallucination/` | Next/React/RTK phantom-import banlists |
 | `testing/` | Unit, e2e, Playwright |
 | `ui-and-accessibility/` | React UI, a11y, props |
 | `tooling-and-review/` | Quality, review, lint, agent-team, retro, **preset meta** |
 
-**Коллизии:** импорт типов и API — **`architecture/public-imports.md`**.
+**Collisions:** type and API imports — **`architecture/public-imports.md`**.
 
 ## Metrics policy mapping
 

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

@@ -1,9 +1,9 @@
 # API and data
 
-HTTP-транспорт, сервисы, Redux store.
+HTTP transport, services, 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/**` |
+| File | Contents | `paths:` |
+|------|----------|----------|
+| `http-client.md` | Single HTTP client, errors, store integration | `app/src/lib/clients/**`, `app/src/api/clients/**` |
+| `api-services.md` | Services, mappers, DTO → domain | `app/src/api/services/**` |
+| `store-rtk.md` | Redux Toolkit, thunks, typing | `app/src/store/**` |

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

@@ -4,58 +4,58 @@ paths:
 impact: HIGH
 ---
 
-# Роль API слоя
+# Role of the API layer
 
-- Инкапсулировать всё, что связано с:
-  - 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/public-imports.md`).
-  - мапперы между DTO и доменными типами.
+- Encapsulate everything related to:
+  - HTTP requests through **application API client instances** in `app/src/api/clients/**`, built on the **shared implementation** from `app/src/lib/clients/**` (as in existing code); details — **`api-and-data/http-client.md`**; layer placement in the **ports and adapters** scheme — `architecture/architecture-boundaries.md`;
+  - URLs/paths,
+  - headers and response codes,
+  - backend DTOs.
+- Provide UI and store with a **stable domain interface**:
+  - functions that work with domain types from `@/types` (`architecture/public-imports.md`).
+  - mappers between DTOs and domain types.
 
-# Структура модулей
+# Module structure
 
-- Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
-  - отдельный каталог в `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/public-imports.md`**).
+- For each domain area (for example, orders, billing, account settings):
+  - a separate directory in `app/src/api/services/<ServiceName or feature>/**` following repository convention.
+- Inside a module:
+  - files with API calls (`index.ts` or `*.service.ts`);
+  - mapper files (`*responseMappers.ts`);
+  - request/response-specific types (if not moved to `app/src/types/**` with export through the `@/types` barrel).
+  - when needed — local `index.ts` / barrel inside the module for structure **within** `app/src/api/**`; **outside** this layer UI, store, and other code import only from the root barrel `app/src/api/index.ts` (`import … from '@/api'`, **`architecture/public-imports.md`**).
 
-# Мапперы и типы
+# Mappers and types
 
-- Для каждого запроса/эндпоинта:
-  - описывать **response‑тип (DTO)**, точно соответствующий контракту backend;
-  - определять **целевой доменный тип** в `app/src/types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
-- Мапперы (например, `*responseMappers.ts`):
-  - чистые функции, без сайд‑эффектов;
-  - выполняют все необходимые вычисления и преобразования данных (булевы флаги, склейка строк, агрегаты и т.п.) при переводе из DTO в доменные модели;
-  - при необходимости обеспечивают обратное преобразование (доменные модели → транспортные типы).
-- UI и store работают только с доменными типами (из `@/types` или экспортируемыми из public API слоя API), а не с «сырыми» DTO.
-- **Не вызывать `fetch` напрямую** в теле API‑методов: только через клиент; исключения — узкие модули (например JSON‑RPC), если так уже устроено в репозитории.
+- For each request/endpoint:
+  - describe the **response type (DTO)** that exactly matches the backend contract;
+  - define the **target domain type** in `app/src/types/**` that the application will use (including computed/aggregated fields).
+- Mappers (for example, `*responseMappers.ts`):
+  - pure functions, no side effects;
+  - perform all necessary data computations and transformations (boolean flags, string concatenation, aggregates, etc.) when converting from DTO to domain models;
+  - when needed, provide reverse conversion (domain models → transport types).
+- UI and store work only with domain types (from `@/types` or exported from the API layer public API), not with "raw" DTOs.
+- **Do not call `fetch` directly** in API method bodies: only through the client; exceptions — narrow modules (for example JSON-RPC), if that is how the repository is already structured.
 
-# Обработка ошибок
+# Error handling
 
-- API‑слой:
-  - не должен «глотать» ошибки без следа;
-  - либо бросает доменные/унифицированные ошибки;
-  - либо возвращает результат в `Result<T, E>`‑подобной форме (если такой паттерн принят в проекте).
-- Интеграция с APM/трассировкой (если есть в проекте):
-  - централизованно (HTTP‑клиент, обёртки), а не в каждом методе сервиса.
+- The API layer:
+  - must not "swallow" errors without a trace;
+  - either throws domain/unified errors;
+  - or returns a result in a `Result<T, E>`-like form (if that pattern is adopted in the project).
+- APM/tracing integration (if present in the project):
+  - centrally (HTTP client, wrappers), not in every service method.
 
-# Требование к агенту
+# Agent requirement
 
-При добавлении/изменении API‑метода:
+When adding/changing an API method:
 
-- Следовать существующим сервисам и мапперам как эталону.
-- Пройти чеклист 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/public-imports.md`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.
+- Follow existing services and mappers as the reference.
+- Complete the barrel-export checklist (**`architecture/layer-barrel-exports.md`**): local `index.ts` → layer facade → root barrel.
+- Do not mix the API layer and UI/store:
+  - components must not depend on DTOs;
+  - store must not assemble URLs/endpoint codes itself or bypass services; **transport response type** and **error contract** from `@/types` (as with the application client) are acceptable in thunks when parsing `catch`/payload, if the service is structured that way (see `api-and-data/store-rtk.md`, `api-and-data/http-client.md`).
+- When using API services in UI, store, and utilities **outside** `app/src/api/**`, import **only** from `@/api` (root barrel), see **`architecture/public-imports.md`**; inside the API layer — via relative paths or `@/api/services/**` / `@/api/clients/**`, without duplicating the public contract around the root barrel for external consumers.
 ## Incorrect
 
 ```ts

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

@@ -5,40 +5,41 @@ paths:
 impact: HIGH
 ---
 
-# HTTP-транспорт
+# HTTP transport
 
-**Имена** фабрик, классов ошибок, типов ответа и конфига — **как в текущем коде репозитория** и в barrel `app/src/types/index.ts`. Ниже — **архитектурные правила**, а не спецификация переименований.
+**Names** of factories, error classes, response types, and config — **as in the current repo code** and in the barrel `app/src/types/index.ts`. Below are **architectural rules**, not a rename specification.
 
-## Роль слоя
+## Layer role
 
-- Обычные 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/public-imports.md`).
-- **Исключения** (узкие протоколы, отдельный транспорт) — только там, где в репозитории уже есть образец; повторять его, не плодить произвольные обходы общего клиента.
+- Typical REST calls to the backend go through **one implementation** in `app/src/lib/clients/**` (shared client module) and **preconfigured instances** in `app/src/api/clients/**`, following the pattern already adopted in the project.
+- Where transport fits in the **ports and adapters** picture — `architecture/architecture-boundaries.md` (section **“Ports and adapters”**).
+- **Do not** call `fetch` directly from `app/src/api/services/**`, store, or UI (see `architecture/architecture-boundaries.md`, `api-and-data/api-services.md`); from store/UI — only calls via services from `@/api` (`architecture/public-imports.md`).
+- **Exceptions** (narrow protocols, separate transport) — only where the repo already has an example; repeat it, do not invent ad-hoc bypasses of the shared client.
 
-## Типы
+## Types
 
-- Всё, что относится к **контракту запроса/ответа/ошибки** приложения и реэкспортируется для HTTP‑слоя, импортировать **только** из barrel `@/types`, без deep‑импортов из внутренних файлов `app/src/types/**` (см. `architecture/public-imports.md`).
-- Не поднимать в новом коде **типы и зависимости от внешнего HTTP‑клиента**, от которого проект ушёл; ориентир — **`package.json`** и существующие вызовы.
+- Everything related to the **request/response/error contract** of the app and re-exported for the HTTP layer must be imported **only** from the `@/types` barrel, without deep imports from internal `app/src/types/**` files (see `architecture/public-imports.md`).
+- Do not introduce **types or dependencies on an external HTTP client** the project has moved away from; use **`package.json`** and existing calls as the guide.
 
-## Контракт ошибок
+## Error contract
 
-- Ошибки сети и HTTP должны приходить в **едином виде**, который задаёт общий клиент (обычно класс/обёртка с полем вроде `response` для тела и статуса).
-- В **`catch`** ориентироваться на **фактическую форму** ошибки в этом репозитории (как в соседних слайсах/сервисах): доступ к телу ошибки, статусу, диагностическому коду — **по полям текущей реализации**, без выдумывания второго формата.
+- Network and HTTP errors must arrive in the **single shape** defined by the shared client (typically a class/wrapper with a field like `response` for body and status).
+- In **`catch`**, rely on the **actual error shape** in this repo (as in neighboring slices/services): access body, status, diagnostic code — **via fields of the current implementation**, without inventing a second format.
 
-## Поведение, которое остаётся в клиенте
+## Behavior that stays in the client
 
-- Общие заголовки, `credentials`, загрузка файлов (**FormData** / снятие лишних заголовков), бинарные ответы (**blob** и аналоги), единообразный разбор JSON и прочих тел.
-- Перехват **401 / refresh**, обработка **404** и т.п. — **централизованно**, если так уже сделано в клиенте; не дублировать ту же логику в каждом сервисе.
+- Shared headers, `credentials`, file uploads (**FormData** / stripping extra headers), binary responses (**blob** and equivalents), uniform parsing of JSON and other bodies.
+- **401 / refresh** interception, **404** handling, etc. — **centrally**, if already done in the client; do not duplicate the same logic in every service.
 
-## Связь со store
+## Store relationship
 
-- Thunk может возвращать **тип обёртки успешного ответа**, если сервис так устроен; в **state** по возможности класть **доменные** типы после маппинга. Подробнее — `api-and-data/store-rtk.md`.
+- A thunk may return the **successful response wrapper type** if the service is structured that way; in **state**, prefer **domain** types after mapping. See `api-and-data/store-rtk.md`.
 
-## Требование к агенту
+## Agent requirement
+
+- When changing the shared client implementation — **update or add behavior tests** next to the client module (`testing/tests-unit.md`).
+- Do not introduce a **second full HTTP stack** without an explicit task and alignment with repo architecture.
 
-- Меняя реализацию общего клиента — **обновить или добавить behavior‑тесты** рядом с модулем клиента (`testing/tests-unit.md`).
-- Не вводить **второй полноценный HTTP‑стек** без явной задачи и согласования с архитектурой репозитория.
 ## Incorrect
 
 ```ts

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

@@ -4,66 +4,66 @@ paths:
 impact: HIGH
 ---
 
-# Общие принципы
-
-- Использовать **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/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/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‑библиотек вне зависимостей проекта.
+# General principles
+
+- Use **Redux Toolkit**:
+  - `createSlice`, `createAsyncThunk`, RTK Query (if used).
+- Store **domain models**, not "raw" DTOs from the API.
+- All data computations and transformations (including computed fields, boolean flags, aggregates, human-readable strings, etc.) must happen **between the API response and writing to store** — in mappers or a separate data-preparation layer. Store holds the prepared domain model.
+- Separate:
+  - "server" state (data from API) and
+  - local UI state (selection/filters/flags).
+
+# Slice structure
+
+- Each domain module — its own slice in `app/src/store/slices/**`.
+- A slice exports:
+  - default `reducer`;
+  - `actions` as named exports;
+  - selectors `selectSomething(state: RootState): Type`.
+- State:
+  - explicit state type;
+  - careful `initialState` initialization.
+
+# Async and side effects
+
+- Async requests:
+  - via `createAsyncThunk` or RTK Query.
+  - inside thunks:
+    - call API through services imported from `@/api` (**`architecture/public-imports.md`**);
+    - do not call the HTTP client directly — only through those services.
+- Side effects (logging, analytics, file handling):
+  - move to middleware (`app/src/store/middleware/**`) or specialized slices.
+
+# Typing
+
+- Use `RootState`, `AppDispatch`, and typed hooks `useAppDispatch`, `useAppSelector` (if present).
+- **HTTP and API errors**:
+  - do not import types from **third-party HTTP libraries** that are not in current dependencies and existing slices (guide — **`package.json`** and neighboring files);
+  - when a service returns the application client's **response wrapper** — use the **matching type from `@/types`** (as in the barrel and similar thunks);
+  - on errors after a service call — rely on the **same transport error class/contract** the shared client uses (from `@/types`), and parse body/status **by fields of the current implementation**, not an imagined API;
+  - in **`catch`**, prefer **`instanceof`** on the transport error class from `@/types` (if present in code) over bare `as`, when expressible without noise (see `stack/no-type-assertion.md`).
+- For entities:
+  - define domain types (including computed fields) in `app/src/types/**`, export through barrel, import in slices from `@/types` as **source of truth** for data shape (`architecture/public-imports.md`);
+  - avoid duplicating entity descriptions in multiple places.
+- **Domain boundary**: in **state**, store domain models; the client **response wrapper** type is acceptable as a thunk **return type** or interim before mapping — without duplicating DTOs in state fields unnecessarily (aligned with `api-and-data/api-services.md` and `api-and-data/http-client.md`).
+
+# Slice testing
+
+- For important slices:
+  - test reducers (initialization, main state transitions).
+  - test selectors (including edge cases).
+- Thunks:
+  - cover with tests and API-layer mocks when possible.
+
+# Agent requirement
+
+When changing/creating a slice:
+
+- Do not put API logic inside reducers/components.
+- Strictly type state and actions.
+- Use a **consistent naming style for actions and selectors**, as in existing slices.
+- For HTTP errors and responses, rely on **`api-and-data/http-client.md`** and contracts from `@/types`, not external HTTP library types outside project dependencies.
 ## Incorrect
 
 ```ts

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

@@ -1,12 +1,12 @@
 # Architecture rules
 
-| Файл | Назначение |
-|------|------------|
-| `public-imports.md` | Импорты `@/types`, `@/types/enums`, `@/api` (вне `app/src/api/**`) |
-| `architecture-boundaries-ui.md` | Slim границы UI при правках компонентов |
-| `architecture-boundaries.md` | Полная карта UI / store / API (api, store, types, lib) |
-| `layer-barrel-exports.md` | Двухуровневые barrel для слоёв с public API |
-| `feature-delivery-workflow.md` | Сквозной чеклист новой фичи |
-| `reference-features.md` | Эталонные пути UI/store/API/types |
+| File | Purpose |
+|------|---------|
+| `public-imports.md` | Imports of `@/types`, `@/types/enums`, `@/api` (outside `app/src/api/**`) |
+| `architecture-boundaries-ui.md` | Slim UI boundaries when editing components |
+| `architecture-boundaries.md` | Full UI / store / API map (api, store, types, lib) |
+| `layer-barrel-exports.md` | Two-level barrels for layers with a public API |
+| `feature-delivery-workflow.md` | End-to-end checklist for a new feature |
+| `reference-features.md` | Reference paths for UI/store/API/types |
 
 Deprecated stubs `types-public-imports.md` / `api-public-imports.md` **removed** — use `public-imports.md`.

package/presets/claude/next/rules/architecture/architecture-boundaries-ui.md

@@ -6,10 +6,10 @@ paths:
 
 # UI layer boundaries (slim)
 
-- **Импорты:** `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums`, API — только `from '@/api'` (`architecture/public-imports.md`).
-- **Запрещено:** прямой HTTP‑клиент; знание DTO — только доменные типы.
-- **Состояние:** сценарии с записью и координация шагов — через store/thunk; узкие прямые вызовы `@/api` для чтения — только как в соседних фичах.
-- **Организация:** алиас `@/`; без deep‑импортов в чужие фичи; только public API.
-- **Barrel:** при новых публичных символах — реэкспорт по `architecture/layer-barrel-exports.md` (правило грузится на `index.ts`).
+- **Imports:** `@/ui/**`, `@/store/**`, types from `@/types` and enums from `@/types/enums`, API — only `from '@/api'` (`architecture/public-imports.md`).
+- **Forbidden:** direct HTTP client; DTO knowledge — domain types only.
+- **State:** write scenarios and multi-step coordination — via store/thunk; narrow direct `@/api` reads — only as in neighboring features.
+- **Organization:** `@/` alias; no deep imports into other features; public API only.
+- **Barrel:** for new public symbols — re-export per `architecture/layer-barrel-exports.md` (rule loads on `index.ts`).
 
-Полная карта слоёв (store, API, порты‑адаптеры): **`architecture/architecture-boundaries.md`** — при правках `app/src/api`, `store`, `types`, `lib`.
+Full layer map (store, API, ports/adapters): **`architecture/architecture-boundaries.md`** — when editing `app/src/api`, `store`, `types`, `lib`.