@bonesofspring/ai-rules 0.2.14 → 0.2.15

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

@@ -3,53 +3,53 @@ name: task
 description: Route a natural-language task through the agent-team pipeline: task-router, pipeline.json, and the first planned specialist.
 ---
 
-# Task — единая точка входа
+# Task — single entry point (router + pipeline)
 
-Главная команда для постановки задачи в Claude Code. Родительский агент = оркестратор (`rules/tooling-and-review/agent-team-orchestrator.md`). Intake — `rules/tooling-and-review/agent-team-intake.md`.
+Main command for filing a task. Parent agent = orchestrator (`rules/tooling-and-review/agent-team-orchestrator.md`). Intake for work requests without `/task` — `rules/tooling-and-review/agent-team-intake.md`.
 
-## Аргументы
+## Arguments
 
-Всё после `/task` — описание задачи на естественном языке.
+Everything after `/task` is the natural-language task description.
 
-Примеры:
+Examples:
 
-- `/task Добавить фильтр по дате в Order History`
-- `/task Order History падает при пустом списке — пофикси`
-- `/task CI упал на typecheck в PR`
-- `/task Миграция HTTP-клиента на fetch`
-- `/task Проверь a11y формы логина`
-- `/task Покрой unit-тестами mapper payments`
-- `/task Напиши changelog для релиза фильтров`
-- `/task Сделай ревью моих изменений в store/orders`
-- `/task Напиши e2e для сценария оплаты`
+- `/task Add a date filter to Order History`
+- `/task Order History crashes on an empty list — fix it`
+- `/task CI failed on typecheck in the PR`
+- `/task Migrate the HTTP client to fetch`
+- `/task Check a11y of the login form`
+- `/task Cover the payments mapper with unit tests`
+- `/task Write a changelog for the filters release`
+- `/task Review my changes in store/orders`
+- `/task Write e2e for the payment scenario`
 
-## Алгоритм
+## Algorithm
 
-1. **Slug** — kebab-case из описания (≤48 символов). Создай `.claude/team/tasks/<slug>/` через запись файла (Write / Edit); runtime/hook владеет `status.json` — **не** полагайся на Shell `mkdir` как единственный способ создать каталог.
-2. **Router** — вызови subagent **task-router** с описанием задачи и путём к slug.
-3. **План** — покажи пользователю таблицу из `pipeline.json`: intent, steps, skipped, humanGates.
-4. **Intent retro** — если `intent === "retro"`, выполни `/technical-retro` и **остановись**.
-5. **Старт** — после router:
-   - подтверди `pipeline.json` и `active-task.json`;
-   - **не** пиши lifecycle-поля `status.json` / `metrics.json` сам — их владеет orchestration runtime/hook (см. **agent-artifact-contracts**). Если `status.json` отсутствует, допустим только минимальный bootstrap (`slug`, `intent`, `pipelineIndex: 0`, `currentAgent: steps[0]`, `state: in_progress`) — **не** увеличивай `pipelineIndex` вручную;
-   - вызови subagent для `pipeline.steps[0].agent` (slug, пути к артефактам, scope).
-6. **После каждого агента** — дождись hook handoff / reconciliation terminal receipt → `status.state`; не запускай следующий шаг, пока `status.json` не отражает handoff (или пока нет `followup_message` от hook).
-7. **Human gate** — если после текущего шага есть gate в `humanGates` (`after:<agent>`), после завершения агента **остановись** и попроси `/task-continue <slug>` (или `/feature-continue <slug>`).
+1. **Slug** — kebab-case from the description (≤48 characters). Create `.claude/team/tasks/<slug>/` via **Write** (e.g. placeholder `pipeline.json` or empty marker) — runtime/hook owns `status.json` — **not** via Shell `mkdir` (sandbox → `Operation not permitted`).
+2. **Router** — invoke subagent **task-router** with the task description and slug path.
+3. **Plan** — show the user the table from `pipeline.json`: intent, steps, skipped, humanGates.
+4. **Intent retro** — if `intent === "retro"`, run `/technical-retro` and **stop**.
+5. **Start** — after the router:
+   - confirm `pipeline.json` and `active-task.json`;
+   - **do not** write `status.json` / `metrics.json` lifecycle fields yourself — the orchestration runtime/hook owns them (see **agent-artifact-contracts**). If `status.json` is missing, only a minimal bootstrap is allowed (`slug`, `intent`, `pipelineIndex: 0`, `currentAgent: steps[0]`, `state: in_progress`) — **do not** increment `pipelineIndex` by hand;
+   - invoke the subagent for `pipeline.steps[0].agent` (slug, artifact paths, scope).
+6. **After each agent** — wait for hook handoff / reconciliation terminal receipt → `status.state`; do not start the next step until `status.json` reflects the handoff (or until there is a hook `followup_message`).
+7. **Human gate** — if after the current step there is a gate in `humanGates` (`after:<agent>`), after the agent finishes **stop** and ask for `/task-continue <slug>` (or `/feature-continue <slug>`).
 
-## Не делать
+## Do not
 
-- Не вызывать developer до router и (если в pipeline) analyst/architect.
-- Не hardcode порядок ролей — только `pipeline.json`.
-- Не пропускать human gate без явного continue.
+- Do not invoke the developer before the router and (if in the pipeline) analyst/architect.
+- Do not hardcode role order — only `pipeline.json`.
+- Do not skip a human gate without an explicit continue.
 
-## Если slug занят
+## If the slug is busy
 
-- `awaitingHumanGate` / `state: awaiting_approval` → предложи ревью артефактов или `/task-continue <slug>`.
-- `in_progress` → спроси: продолжить или новый slug.
+- `awaitingHumanGate` / `state: awaiting_approval` → suggest reviewing artifacts or `/task-continue <slug>`.
+- `in_progress` → ask: continue or a new slug.
 
 ## Legacy
 
-`/feature-start` и `/feature-continue` остаются совместимыми; для новых задач предпочитай `/task`.
+`/feature-start` and `/feature-continue` remain compatible; prefer `/task` for new work.
 
 ## Metrics
 

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

@@ -3,59 +3,82 @@ name: technical-retro
 description: Facilitate a technical retrospective for a period, incident, release, or completed agent-team task slug.
 ---
 
-# Техническое ретро — роль агента
+# Technical retro
 
-Агент выступает как **нейтральный фасилитатор технической ретроспективы**, а не как ревьюер кода или оценщик людей. Цель — вынести уроки, согласовать действия и улучшить процесс разработки. Используй skill **`technical-retro`** как основной сценарий.
+The agent acts as a **neutral facilitator of a technical retrospective**, not as a code reviewer or people evaluator. Use skill **`technical-retro`** as the main scenario.
 
-## Когда включать
+## When to use
 
-- Пользователь просит: «ретро», «техническое ретро», «разбор спринта/итерации», «что пошло хорошо / плохо», «action items после релиза».
-- Есть контекст: период (спринт, квартал), тема (релиз, инцидент, миграция), или приложены заметки/линки.
+- The user asks for: “retro”, “technical retro”, “sprint/iteration review”, “action items after release”.
+- After an agent-team pipeline finishes (`/feature-start` → `/feature-continue`).
+- Context exists: period, topic (release, incident), task slug, notes.
 
-## Входные данные (запросить при нехватке)
+## Inputs (gather, do not invent)
 
-- **Период и фокус** (например: две недели, релиз X, постмортем).
-- **Участники/роли** (если важно для формулировок): только разработка или весь кросс‑функциональный поток.
-- **Ограничения**: время (15 / 30 / 60 мин), формат (async в чате vs синхронная повестка).
-- По желанию: список deliverables, метрики, ссылки на тикеты/MR — **без выдумывания** фактов, которых нет в сообщении или репозитории.
+Ask when missing:
 
-Если контекста мало — задать **1–3 коротких уточняющих вопроса**, затем продолжить с явными допущениями в шапке вывода.
+- **Period and focus**.
+- **Task slug** (if the retro is about agent-team work).
+- **Participants/roles** (if relevant).
+- **Constraints**: time, format (async vs sync).
 
-## Принципы фасилитации
+### Agent-team artifacts (when there is a slug)
 
-- **Безопасность и нейтральность**: формулировки про процесс и систему, не про «виноватых»; избегать ярлыков к людям.
-- **Конкретика**: от абстрактного «надо лучше общаться» — к наблюдаемым событиям и договорённостям.
-- **Баланс**: зафиксировать и позитив (что усилить), и зоны роста.
-- **Один владелец и срок** у каждого action item; избегать списка «сделает команда» без имени/роли.
-- **Не смешивать с code review**: ретро не заменяет построчный разбор диффа; при запросе «и ретро, и ревью» — развести два блока в ответе.
+Read from the repository:
 
-## Рекомендуемая структура сессии (по умолчанию)
+- `.claude/team/tasks/<slug>/pipeline.json`
+- `.claude/team/tasks/<slug>/brief.md`
+- `.claude/team/tasks/<slug>/decomposition.md`
+- `.claude/team/tasks/<slug>/status.json`
+- Git diff / `git status` for changed files
 
-Подстроить под указанное время. Для короткого async‑формата — сжать до шагов 2–4.
+Do not invent facts that are not in artifacts, the diff, or the user message.
 
-1. **Цель и рамки** (1–2 предложения): зачем встреча, что в фокусе / что вне скоупа.
-2. **Сбор фактов** (молча в чате — списком от пользователя; агент структурирует):
-   - что шло хорошо,
-   - что мешало / вызывало риски,
-   - сюрпризы (технический долг, узкие места, зависимости).
-3. **Группировка тем**: объединить дубли, выделить 3–7 тем для обсуждения (приоритет — влияние × изменяемость).
-4. **Корневые причины (легко)**: для 1–2 самых болезненных тем — кратко «5 почему» или «что в процессе/артефактах позволило этому случиться», без морализаторства.
-5. **Эксперименты на следующий цикл**: не больше 1–3 изменений процесса/инструментов; каждое — измеримое или с явным критерием «успех/не успех».
-6. **Action items**: таблица или список с **что / владелец / до когда / как поймём, что сработало**.
+## Facilitation principles
 
-## Формат ответа агента
+- **Safety**: process and system, not “who is to blame”.
+- **Specifics**: from abstractions to observed events.
+- **Balance**: positives and growth areas.
+- **Action items**: owner and due date for each.
+- **Do not mix with code review** — separate the blocks if both are requested.
 
-- Краткая **шапка**: период, фокус, допущения (если были).
-- **Повестка** или итог по этапам выше.
-- **Темы** — буллеты; по спорным местам — **вопросы команде**, а не окончательные выводы без данных.
-- **Решения и эксперименты** отдельным блоком.
-- **Action items** — в конце, каждый пункт с владельцем и дедлайном (или пометка «нужно назначить на встрече»).
+## Session structure (default)
 
-## Ограничения
+1. **Goal and scope**.
+2. **Gather facts**: what went well / what blocked / surprises.
+3. **Cluster themes** (3–7).
+4. **Root causes** for 1–2 painful themes.
+5. **Experiments** (1–3 process changes).
+6. **Action items**: what / owner / by when / success criterion.
 
-- Не приписывать команде цитаты или факты, которых не было во входе.
-- Не выдавать юридические/HR‑рекомендации; при явных конфликтах или токсичности — мягко предложить эскалацию человеку, ответственному за команду, без детализации «наказаний».
-- Если пользователь просит только шаблон — выдать **шаблон повестки и доски** (колонки, таймбоксы) без выдуманного контента.
+## “Agent work” block (required when there is a slug)
+
+If the retro is tied to a `/feature-start` pipeline:
+
+| Question | What to record |
+|----------|----------------|
+| Router | Wrong intent, extra/missing steps in pipeline |
+| Analyst | Wrong assumptions, missed AC, extra/missing tasks |
+| Decomposition | Incomplete layer coverage, wrong order, blocked dependencies |
+| Developer | Scope creep, missed rules, lint/type gaps |
+| Reviewer | Missed defects, false positives, checklist quality |
+| QA | AC coverage by tests, flakiness, gaps in e2e plans |
+
+**Action items** in this block — improve **prompts, subagents, and rules** (not only code).
+
+## Response format
+
+- Header: period, focus, slug (if any), assumptions.
+- Agenda by stages.
+- **“Agent work”** block (when applicable).
+- Themes — bullets; disputed points — **questions for the team**.
+- **Action items** at the end.
+
+## Constraints
+
+- Do not invent quotes or facts without input.
+- Do not give HR recommendations.
+- If they ask only for a template — an **agenda template** without invented content.
 
 ### Metrics evidence
 

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

@@ -1,6 +1,6 @@
 # `.claude/rules` (preset nuxt)
 
-В 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,7 +14,7 @@
 
 ## Loading strategy
 
-- **Session start (no `paths:`):** ровно **3** — `nuxt-app-core`, `package-manager`, `code-quality`
+- **Session start (no `paths:`):** exactly **3** — `nuxt-app-core`, `package-manager`, `code-quality`
 - **On-demand (`paths:` or via commands):** `post-change-lint`, `security-nuxt`, architecture, UI, tests, `vue-nuxt-anti-hallucination`, **preset-*** meta, …
 - **Skills:** `feature-delivery`, `vue-performance`, `code-review`, …
 
@@ -79,10 +79,10 @@
 
 ## Folders
 
-| Папка | О чём |
-|-------|--------|
+| Folder | About |
+|--------|--------|
 | `stack/` | Nuxt core, pages routing, conventions |
-| `architecture/` | Границы, feature-delivery, imports |
+| `architecture/` | Boundaries, feature-delivery, imports |
 | `api-and-data/` | HTTP, services, Pinia |
 | `anti-hallucination/` | Vue/Nuxt/Pinia banlists |
 | `testing/` | Unit, e2e, Playwright |

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

@@ -1,9 +1,9 @@
 # API and data
 
-HTTP-транспорт, сервисы, Pinia store.
+HTTP transport, services, Pinia store.
 
-| Файл | Содержание | `paths:` |
-|------|------------|----------|
-| `http-client.md` | Единый HTTP-клиент, ошибки, связь со store | `lib/clients/**`, `api/clients/**` |
-| `api-services.md` | Сервисы, мапперы, DTO → домен | `api/services/**` |
-| `store-pinia.md` | Pinia, actions, типизация | `stores/**` |
+| File | Contents | `paths:` |
+|------|----------|----------|
+| `http-client.md` | Shared HTTP client, errors, store link | `lib/clients/**`, `api/clients/**` |
+| `api-services.md` | Services, mappers, DTO → domain | `api/services/**` |
+| `store-pinia.md` | Pinia, actions, typing | `stores/**` |

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

@@ -1,58 +1,59 @@
 ---
-description: Конвенции API сервисов и мапперов
+description: API services and mapper conventions
 paths: api/services/**/*.ts
 ---
-# Роль API слоя
 
-- Инкапсулировать всё, что связано с:
-  - HTTP‑запросами через **экземпляры прикладных API‑клиентов** в `api/clients/**`, собранные на **общей реализации** из `lib/clients/**` (как в существующем коде); подробности — **`http-client.mdc`**; положение слоя в схеме **порты и адаптеры** — `architecture-boundaries.mdc`;
-  - URL/путями,
-  - заголовками и кодами ответов,
-  - DTO backend.
-- Предоставлять UI и store **стабильный доменный интерфейс**:
-  - функции, работающие с доменными типами из `@/types` (`public-imports.mdc`).
-  - мапперы между DTO и доменными типами.
+# Role of the API layer
 
-# Структура модулей
+- Encapsulate everything related to:
+  - HTTP requests through **application API client instances** in `api/clients/**`, built on the **shared implementation** from `lib/clients/**` (as in existing code); details — **`http-client.mdc`**; layer placement in the **ports and adapters** scheme — `architecture-boundaries.mdc`;
+  - 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` (`public-imports.mdc`).
+  - mappers between DTOs and domain types.
 
-- Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
-  - отдельный каталог в `api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
-- Внутри модуля:
-  - файлы с вызовами API (`index.ts` или `*.service.ts`);
-  - файлы мапперов (`*responseMappers.ts`);
-  - специфичные типы запросов/ответов (если не вынесены в `types/**` с экспортом через barrel `@/types`).
-  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `api/index.ts` (`import … from '@/api'`, **`public-imports.mdc`**).
+# Module structure
 
-# Мапперы и типы
+- For each domain area (for example, orders, billing, account settings):
+  - a separate directory in `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 `types/**` with export through the `@/types` barrel).
+  - when needed — local `index.ts` / barrel inside the module for structure **within** `api/**`; **outside** this layer UI, store, and other code import only from the root barrel `api/index.ts` (`import … from '@/api'`, **`public-imports.mdc`**).
 
-- Для каждого запроса/эндпоинта:
-  - описывать **response‑тип (DTO)**, точно соответствующий контракту backend;
-  - определять **целевой доменный тип** в `types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
-- Мапперы (например, `*responseMappers.ts`):
-  - чистые функции, без сайд‑эффектов;
-  - выполняют все необходимые вычисления и преобразования данных (булевы флаги, склейка строк, агрегаты и т.п.) при переводе из DTO в доменные модели;
-  - при необходимости обеспечивают обратное преобразование (доменные модели -> транспортные типы).
-- UI и store работают только с доменными типами (из `@/types` или экспортируемыми из public API слоя API), а не с "сырыми" DTO.
-- **Не вызывать `fetch` напрямую** в теле API‑методов: только через клиент; исключения — узкие модули (например JSON‑RPC), если так уже устроено в репозитории.
+# Mappers and types
 
-# Обработка ошибок
+- For each request/endpoint:
+  - describe the **response type (DTO)** that exactly matches the backend contract;
+  - define the **target domain type** in `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.
 
-- API‑слой:
-  - не должен "глотать" ошибки без следа;
-  - либо бросает доменные/унифицированные ошибки;
-  - либо возвращает результат в `Result<T, E>`‑подобной форме (если такой паттерн принят в проекте).
-- Интеграция с APM/трассировкой (если есть в проекте):
-  - централизованно (HTTP‑клиент, обёртки), а не в каждом методе сервиса.
+# Error handling
 
-# Требование к агенту
+- 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.
 
-При добавлении/изменении API‑метода:
-- Следовать существующим сервисам и мапперам как эталону.
-- Пройти чеклист barrel-экспортов (**`layer-barrel-exports.mdc`**): локальный `index.ts` → фасад слоя → корневой barrel.
-- Не смешивать слой API и UI/store:
-  - компоненты не должны зависеть от DTO;
-  - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы в **Pinia actions** при разборе `catch`/payload, если так выстроен сервис (см. `store-pinia.mdc`, `http-client.mdc`).
-- При использовании API‑сервисов в UI, store и утилитах **вне** `api/**` импортировать **только** из `@/api` (корневой barrel), см. **`public-imports.mdc`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.
+# Agent requirement
+
+When adding/changing an API method:
+- Follow existing services and mappers as the reference.
+- Complete the barrel-export checklist (**`layer-barrel-exports.mdc`**): 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 **Pinia actions** when parsing `catch`/payload, if the service is structured that way (see `store-pinia.mdc`, `http-client.mdc`).
+- When using API services in UI, store, and utilities **outside** `api/**`, import **only** from `@/api` (root barrel), see **`public-imports.mdc`**; 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/nuxt/rules/api-and-data/store-pinia.md

@@ -1,30 +1,31 @@
 ---
-description: Pinia stores и клиентское состояние приложения (Nuxt)
+description: Pinia stores and client application state (Nuxt)
 paths:
   - stores/**/*.ts
   - stores/**/*.js
 ---
-# Общие принципы
 
-- Использовать **Pinia** (`defineStore`) — setup или options store, как у соседей в репо.
-- Модуль: `@pinia/nuxt` (или установленный эквивалент) — проверить `package.json` / `nuxt.config`.
-- В store хранить **доменные модели**, не сырые DTO из API.
-- Маппинг DTO → domain — в `api/**` (или server mappers) **до** записи в store.
-- Разделять серверное состояние (данные API) и локальное UI‑состояние (фильтры/флаги) — UI-only можно в composable/`ref` страницы, если так принято в репо.
+# General principles
 
-# Запрещено в этом пресете
+- Use **Pinia** (`defineStore`) — setup or options store, as neighbors do in the repo.
+- Module: `@pinia/nuxt` (or the installed equivalent) — check `package.json` / `nuxt.config`.
+- Store **domain models**, not raw API DTOs.
+- DTO → domain mapping — in `api/**` (or server mappers) **before** writing to the store.
+- Separate server state (API data) from local UI state (filters/flags) — UI-only may live in a composable/`ref` on the page if that is the repo convention.
+
+# Forbidden in this preset
 
 - RTK / Redux: `createSlice`, `createAsyncThunk`, RTK Query, `useDispatch` / `useSelector`, stem `store-rtk`.
-- Сырой `$fetch` / `fetch` из store в обход `~/api` / `@/api` сервисов (кроме узких documented исключений репо).
+- Raw `$fetch` / `fetch` from the store bypassing `~/api` / `@/api` services (except narrow documented repo exceptions).
 
-# Структура
+# Structure
 
-- Один доменный модуль — свой файл в `stores/**` (например `stores/profile.ts`).
-- Экспорт: `useXStore` через `defineStore('x', …)`.
-- State: явный тип; аккуратная инициализация.
-- Getters — производные от domain state; actions вызывают сервисы из `~/api` / `@/api` (`public-imports`).
+- One domain module — its own file under `stores/**` (e.g. `stores/profile.ts`).
+- Export: `useXStore` via `defineStore('x', …)`.
+- State: explicit type; careful initialization.
+- Getters — derived from domain state; actions call services from `~/api` / `@/api` (`public-imports`).
 
-# Асинхронность
+# Async
 
 ```ts
 // Incorrect — raw HTTP + DTO in state
@@ -49,19 +50,19 @@ export const useProfileStore = defineStore('profile', {
 })
 ```
 
-# Типизация и ошибки
+# Typing and errors
 
-- Доменные типы из `~/types` / `@/types`.
-- Ошибки транспорта — контракты из `@/types` / принятый класс ошибки клиента (`http-client`), не выдуманные axios shapes.
-- В UI: `storeToRefs` для state; actions вызывать напрямую с store.
+- Domain types from `~/types` / `@/types`.
+- Transport errors — contracts from `@/types` / the accepted client error class (`http-client`), not invented axios shapes.
+- In UI: `storeToRefs` for state; call actions directly on the store.
 
-# Тестирование
+# Testing
 
-- Покрывать важные stores (инициализация, переходы, actions с моком API).
-- Unit: Vitest; мокать `~/api` сервисы.
+- Cover important stores (init, transitions, actions with mocked API).
+- Unit: Vitest; mock `~/api` services.
 
-# Требование к агенту
+# Agent requirement
 
-- Не класть HTTP/transport в компоненты.
-- Строго типизировать state/actions.
-- Следовать стилю соседних stores.
+- Do not put HTTP/transport in components.
+- Strictly type state/actions.
+- Follow neighboring store style.

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

@@ -1,12 +1,12 @@
 # Architecture rules
 
-| Файл | Назначение |
-|------|------------|
-| `public-imports.md` | Импорты `@/types`, `@/types/enums`, `@/api` (вне `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 `@/types`, `@/types/enums`, `@/api` (outside `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/nuxt/rules/architecture/architecture-boundaries-ui.md

@@ -1,15 +1,16 @@
 ---
-description: Границы слоя UI — slim rule для правок компонентов (без полной карты store/API)
+description: UI layer boundaries — slim rule for component edits (without the full store/API map)
 paths:
   - components/**/*.vue
   - components/**/*.ts
 ---
+
 # UI layer boundaries (slim)
 
-- **Импорты:** `components/**`, `composables/**`, `stores/**` (public), типы из `~/types` / `@/types`, API — только `from '~/api'` / `from '@/api'` (`public-imports`).
-- **Запрещено:** прямой HTTP‑клиент (`$fetch` / ofetch вне `lib/clients`); знание DTO — только доменные типы.
-- **Состояние:** сценарии с записью и координация шагов — через Pinia actions (`store-pinia`); узкие прямые вызовы `~/api` для чтения — только как в соседних фичах.
-- **Организация:** алиасы `~/` / `@/`; без deep‑импортов в чужие фичи; только public API.
-- **Barrel:** при новых публичных символах — реэкспорт по `layer-barrel-exports` (правило грузится на `index.ts`).
+- **Imports:** `components/**`, `composables/**`, `stores/**` (public), types from `~/types` / `@/types`, API — only `from '~/api'` / `from '@/api'` (`public-imports`).
+- **Forbidden:** direct HTTP client (`$fetch` / ofetch outside `lib/clients`); DTO knowledge — domain types only.
+- **State:** write scenarios and multi-step coordination — via Pinia actions (`store-pinia`); narrow direct `~/api` reads — only as in neighboring features.
+- **Organization:** `~/` / `@/` aliases; no deep imports into other features; public API only.
+- **Barrel:** for new public symbols — re-export per `layer-barrel-exports` (rule loads on `index.ts`).
 
-Полная карта слоёв (store, API, порты‑адаптеры): **`architecture-boundaries`** — при правках `api`, `stores`, `types`, `lib`.
+Full layer map (store, API, ports/adapters): **`architecture-boundaries`** — when editing `api`, `stores`, `types`, `lib`.