@bonesofspring/ai-rules 0.2.14 → 0.2.16

package/presets/cursor/next/rules/navigation-router-stack.mdc

@@ -1,62 +1,62 @@
 ---
-description: Выбор API навигации по стеку проекта (Next.js vs React Router)
+description: Choose navigation API by project stack (Next.js vs React Router)
 globs: app/src/app/**/*,app/**/app/**/*
 alwaysApply: false
 ---
 
-# Навигация и роутинг: сначала стек проекта
+# Navigation and routing: project stack first
 
-**При любой задаче, связанной с навигацией, переходами между страницами, URL, редиректами, хлебными крошками, защищёнными маршрутами или программной сменой маршрута** — перед предложением кода или импортов **нельзя** опираться на «типичный React» по умолчанию. Нужно **явно свериться со стеком целевого репозитория** и использовать **один** согласованный с проектом механизм.
+**For any task involving navigation, page transitions, URLs, redirects, breadcrumbs, protected routes, or programmatic route changes** — before proposing code or imports you **must not** default to “typical React”. **Explicitly verify the target repo stack** and use **one** mechanism consistent with the project.
 
-## Зависимости: что проверить в первую очередь
+## Dependencies: what to check first
 
-1. **`package.json`** в корне приложения (например `app/package.json` в монорепо — тот пакет, который реально собирается и деплоится). Смотреть **`dependencies`** и при необходимости **`peerDependencies`**:  
-   - **`next`** — Next.js; версия важна для нюансов API (сверяться с документацией под эту major).  
-   - **`react-router-dom`**, **`@remix-run/*`**, **`@tanstack/react-router`** и т.д. — отдельный роутинг; не подменять их API вызовами Next без проверки, что в проекте действительно используется этот стек.  
-   - **`next`** и **`react-router-dom`** одновременно — возможно легаси или гибрид; **не** выбирать API по умолчанию — смотреть раздел «Реализация в коде» ниже.
+1. **`package.json`** at the app root (e.g. `app/package.json` in a monorepo — the package that is actually built and deployed). Check **`dependencies`** and if needed **`peerDependencies`**:
+   - **`next`** — Next.js; version matters for API nuances (cross-check docs for that major).
+   - **`react-router-dom`**, **`@remix-run/*`**, **`@tanstack/react-router`**, etc. — separate routing; do not substitute their API with Next calls without verifying that stack is actually used.
+   - **`next`** and **`react-router-dom`** together — possible legacy or hybrid; **do not** pick API by default — see “Implementation in code” below.
 
-2. **Монорепо / workspaces** — роутинг может жить не в корневом `package.json`. Открыть **`package.json` того workspace**, где лежат страницы и `next.config.*` / точка входа SPA.
+2. **Monorepo / workspaces** — routing may live outside the root `package.json`. Open the **`package.json` of the workspace** where pages and `next.config.*` / SPA entry live.
 
-3. **Факт установки** — при сомнениях смотреть lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) или каталог `node_modules` у соответствующего пакета: убедиться, что заявленный пакет реально установлен, а не только прописан в документации.
+3. **Actual installation** — when in doubt, check the lockfile (`bun.lock`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) or `node_modules` for the relevant package: confirm the declared package is installed, not only documented.
 
-## Реализация роутинга в проекте (код и структура)
+## Routing implementation in the project (code and structure)
 
-Перед предложением паттерна навигации **свериться с тем, как уже сделано в репозитории**:
+Before proposing a navigation pattern **align with how the repo already does it**:
 
-1. **Дерево маршрутов**  
-   - Next **App Router**: каталог **`app/`** (или `src/app/`) с `layout.tsx`, `page.tsx`, сегменты `[id]` и т.п.  
-   - Next **Pages Router**: каталог **`pages/`** с `_app`, динамические `[slug].tsx`.  
-   - Наличие **обоих** `app/` и `pages/` — уточнить по `next.config` и документации проекта, какой слой основной.
+1. **Route tree**
+   - Next **App Router**: **`app/`** (or `src/app/`) with `layout.tsx`, `page.tsx`, segments `[id]`, etc.
+   - Next **Pages Router**: **`pages/`** with `_app`, dynamic `[slug].tsx`.
+   - Both **`app/`** and **`pages/`** present — clarify via `next.config` and project docs which layer is primary.
 
-2. **Точки входа и обёртки**  
-   - Поиск по коду импортов: **`from 'next/navigation'`**, **`from 'next/router'`**, **`from 'next/link'`**, **`from 'react-router-dom'`**, **`createBrowserRouter`**, **`RouterProvider`**, **`BrowserRouter`**.  
-   - Где объявлены маршруты (файловая структура Next vs конфиг маршрутов / `routes.tsx` в SPA).
+2. **Entry points and wrappers**
+   - Code search for imports: **`from 'next/navigation'`**, **`from 'next/router'`**, **`from 'next/link'`**, **`from 'react-router-dom'`**, **`createBrowserRouter`**, **`RouterProvider`**, **`BrowserRouter`**.
+   - Where routes are declared (Next file structure vs SPA route config / `routes.tsx`).
 
-3. **Общие абстракции проекта**  
-   - Обертки над ссылками (`@/ui/...`, `Link` из дизайн-системы), хелперы путей, константы роутов — **использовать их**, а не дублировать сырой роутер.
+3. **Project abstractions**
+   - Link wrappers (`@/ui/...`, design-system `Link`), path helpers, route constants — **use them**, do not duplicate raw router.
 
-4. **Соседние файлы фичи**  
-   - Новый код навигации — в том же стиле, что страницы/хуки той же области (`next/navigation` vs `react-router-dom` как в соседних импортах).
+4. **Neighboring feature files**
+   - New navigation code — same style as pages/hooks in that area (`next/navigation` vs `react-router-dom` as in neighboring imports).
 
-## Как определить, что использовать (сводка)
+## How to decide what to use (summary)
 
-1. **Зависимости** — см. раздел выше; по ним задаётся допустимый набор пакетов.  
-2. **Структура** — App Router vs Pages vs SPA по каталогам и конфигу.  
-3. **Фактический код** — какие импорты и обёртки уже доминируют в приложении.
+1. **Dependencies** — see above; they define the allowed package set.
+2. **Structure** — App Router vs Pages vs SPA by directories and config.
+3. **Actual code** — which imports and wrappers dominate in the app.
 
-## Что использовать (краткая матрица)
+## What to use (quick matrix)
 
-| Стек | Программная навигация / чтение пути | Ссылки |
+| Stack | Programmatic navigation / path read | Links |
 |------|-------------------------------------|--------|
-| **Next.js App Router** | `next/navigation` (`useRouter`, `usePathname`, `useSearchParams`, `redirect` и т.д. по документации Next для вашей версии) | `next/link` |
+| **Next.js App Router** | `next/navigation` (`useRouter`, `usePathname`, `useSearchParams`, `redirect`, etc. per Next docs for your version) | `next/link` |
 | **Next.js Pages Router** | `next/router` | `next/link` |
-| **SPA + React Router** | `react-router-dom` (`useNavigate`, `useParams`, `useLocation`, …) | `<Link>` из `react-router-dom` |
+| **SPA + React Router** | `react-router-dom` (`useNavigate`, `useParams`, `useLocation`, …) | `<Link>` from `react-router-dom` |
 
-**Не делать:** подключать `react-router-dom` в проект на Next.js «по привычке»; импортировать хуки из `next/router` в компонентах App Router без проверки; смешивать два роутера в одном приложении без явной архитектурной причины в кодовой базе.
+**Do not:** add `react-router-dom` to a Next.js project “by habit”; import hooks from `next/router` in App Router components without checking; mix two routers in one app without an explicit architectural reason in the codebase.
 
-## Требование к агенту
+## Agent requirement
 
-- Перед генерацией или ревью кода навигации **коротко зафиксировать вывод** (например: «зависимости: `next` без `react-router-dom`; в коде везде `next/navigation` → используем то же») и следовать ему.  
-- **Обязательная проверка:** актуальные **`dependencies`** в `package.json` нужного workspace + **как в проекте уже реализованы** маршруты и импорты (поиск по репозиторию, соседние файлы). Не полагаться только на предположение по одному признаку (например, только на наличие папки `app/`).  
-- Если стек неочевиден (два роутера в зависимостях, гибрид) — **сверить lockfile / установленные пакеты** и **доминирующие импорты** в `src`/`app`, затем выбрать API.  
-- Для **этого** репозитория базовый ориентир — **`next-app-core.mdc`**: Next.js; предпочитать **`next/navigation`** и **`next/link`** там, где используется App Router.
+- Before generating or reviewing navigation code **briefly record the conclusion** (e.g. “dependencies: `next` without `react-router-dom`; code uses `next/navigation` everywhere → use the same”) and follow it.
+- **Mandatory check:** current **`dependencies`** in the relevant workspace `package.json` + **how routes and imports are already implemented** (repo search, neighboring files). Do not rely on a single signal alone (e.g. only the presence of an `app/` folder).
+- If the stack is unclear (two routers in dependencies, hybrid) — **cross-check lockfile / installed packages** and **dominant imports** in `src`/`app`, then choose the API.
+- For **this** repo the baseline guide is **`next-app-core.mdc`**: Next.js; prefer **`next/navigation`** and **`next/link`** where App Router is used.

package/presets/cursor/next/rules/navigation-router-ui.mdc

@@ -1,16 +1,16 @@
 ---
-description: Навигация в UI-компонентах — краткий ориентир (полный аудит стека — navigation-router-stack.mdc)
+description: Navigation in UI components — short guide (full stack audit — navigation-router-stack.mdc)
 globs: app/src/ui/**/*.tsx
 alwaysApply: false
 ---
 
 # Navigation in UI components
 
-Перед ссылками, программной навигацией или работой с URL в UI:
+Before links, programmatic navigation, or URL work in UI:
 
-1. **`package.json`** workspace приложения — `next` vs `react-router-dom`.
-2. **Соседние импорты** той же фичи (`next/navigation`, `next/link` vs `react-router-dom`).
-3. **Обёртки проекта** (`@/ui/...` Link) — предпочтительнее сырого API роутера.
-4. **По умолчанию (preset):** Next.js App Router → `next/navigation` + `next/link` (`next-app-core.mdc`, `next-app-router.mdc`).
+1. **`package.json`** of the app workspace — `next` vs `react-router-dom`.
+2. **Neighboring imports** in the same feature (`next/navigation`, `next/link` vs `react-router-dom`).
+3. **Project wrappers** (`@/ui/...` Link) — preferred over raw router API.
+4. **Default (preset):** Next.js App Router → `next/navigation` + `next/link` (`next-app-core.mdc`, `next-app-router.mdc`).
 
-Полный аудит (дерево маршрутов, гибриды, lockfile): **`navigation-router-stack.mdc`** — при правках `app/src/app/**`.
+Full audit (route tree, hybrids, lockfile): **`navigation-router-stack.mdc`** — when editing `app/src/app/**`.

package/presets/cursor/next/rules/next-app-core.mdc

@@ -1,34 +1,34 @@
 ---
-description: Базовые принципы, стек и архитектура Next.js приложения (preset)
+description: Core principles, stack, and architecture of a Next.js application (preset)
 alwaysApply: true
 ---
 
-# Стек и окружение
+# Stack and environment
 
-Конкретные версии — **из `package.json` и конфигов целевого репозитория**. Рамка preset: Next.js, React, TypeScript; runner/e2e/mocks/UI/APM — как заведено в репо.
+Concrete versions come **from `package.json` and configs of the target repository**. Preset frame: Next.js, React, TypeScript; runner/e2e/mocks/UI/APM — as established in the repo.
 
-# Структура проекта
+# Project structure
 
-- `app/` — корень Next.js; `app/src/**` — код; `app/__tests__/e2e/**` — e2e.
+- `app/` — Next.js root; `app/src/**` — code; `app/__tests__/e2e/**` — e2e.
 - `app/tsconfig.json`: `baseUrl: "."`, `paths: { "@/*": ["./src/*"] }`.
-- **Требование:** `@/*` вместо относительных импортов выше по дереву.
+- **Requirement:** `@/*` instead of relative imports that climb the tree.
 
-# Архитектурные слои
+# Architectural layers
 
-| Слой | Каталог | Детали |
-|------|---------|--------|
+| Layer | Directory | Details |
+|-------|-----------|---------|
 | UI | `app/src/ui/**` (pages, components) | `react-ui.mdc`, `architecture-boundaries-ui.mdc` |
 | Store | `app/src/store/**` (slices, middleware) | `store-rtk.mdc` |
 | API | `app/src/api/**` (services, clients, barrel) | `api-services.mdc`, `http-client.mdc` |
 | HTTP | `app/src/lib/clients/**`, `app/src/api/clients/**` | `http-client.mdc` |
 | Types | `app/src/types/**` | `public-imports.mdc`, `types-jsdoc.mdc` |
-| Mocks | `app/src/mocks/**` | по схеме репозитория |
+| Mocks | `app/src/mocks/**` | per repository layout |
 
-Границы слоёв, порты/адаптеры, UI→API — **`architecture-boundaries.mdc`**. Импорты `@/types`, `@/api` — **`public-imports.mdc`**.
+Layer boundaries, ports/adapters, UI→API — **`architecture-boundaries.mdc`**. Imports of `@/types`, `@/api` — **`public-imports.mdc`**.
 
-# Работа агента
+# Agent work
 
-- Архитектура и импорты: `architecture-boundaries.mdc`, `public-imports.mdc`
-- Фичи: `feature-delivery-workflow.mdc` + skill `feature-delivery`
-- После правок: **вызвать** `post-change-lint.mdc` (requestable, обязателен после code edits); менеджер пакетов: `package-manager.mdc`
-- Копировать паттерны соседних файлов в целевом слое; не использовать `any` (предпочитать `unknown` + сужение)
+- Architecture and imports: `architecture-boundaries.mdc`, `public-imports.mdc`
+- Features: `feature-delivery-workflow.mdc` + skill `feature-delivery`
+- After edits: **invoke** `post-change-lint.mdc` (requestable, required after code edits); package manager: `package-manager.mdc`
+- Copy patterns from neighboring files in the target layer; do not use `any` (prefer `unknown` + narrowing)

package/presets/cursor/next/rules/next-app-router.mdc

@@ -6,34 +6,34 @@ alwaysApply: false
 
 # Next.js App Router
 
-Применять при работе с `app/src/app/**` или маршрутами App Router в целевом репо.
+Apply when working with `app/src/app/**` or App Router routes in the target repo.
 
 ## Server vs Client
 
-- **Server Components по умолчанию** — без `'use client'`, если не нужны hooks, browser API, event handlers.
-- **`'use client'`** — только для интерактива, `useState`/`useEffect`, browser-only API.
-- Не тянуть store/RTK и тяжёлый client-state в Server Components без необходимости.
+- **Server Components by default** — no `'use client'` unless hooks, browser APIs, or event handlers are required.
+- **`'use client'`** — only for interactivity, `useState`/`useEffect`, and browser-only APIs.
+- Do not pull store/RTK and heavy client state into Server Components without need.
 
 ## Data fetching
 
-- Предпочитать fetch/data-loader на **server** (RSC, route handlers, server actions — по принятому в репо паттерну).
-- **Не дублировать** один запрос в RSC и client без причины.
-- Кеш и revalidate — как в существующих страницах репо (`fetch` options, `revalidate`, tags).
+- Prefer fetch/data-loader on the **server** (RSC, route handlers, server actions — per the repo’s established pattern).
+- **Do not duplicate** the same request in RSC and client without reason.
+- Cache and revalidate — match existing pages in the repo (`fetch` options, `revalidate`, tags).
 
-## Маршруты и UX
+## Routes and UX
 
-- Для async data routes **обязательны** sibling **`loading.tsx`** и **`error.tsx`** (и `not-found.tsx` где уместно) — по образцу соседних routes.
-- **Suspense** — для медленных client/server секций; fallback согласован с дизайн-системой.
-- Навигация — `navigation-router-stack.mdc` + router/link паттерны проекта.
+- For async data routes, sibling **`loading.tsx`** and **`error.tsx`** are **required** (and `not-found.tsx` where appropriate) — follow neighboring routes.
+- **Suspense** — for slow client/server sections; fallback aligned with the design system.
+- Navigation — `navigation-router-stack.mdc` + project router/link patterns.
 
-## Границы слоёв
+## Layer boundaries
 
-- RSC/route handlers **не импортируют UI-компоненты с client-only зависимостями** напрямую в server tree без `'use client'` границы.
-- Доменные типы — `@/types`; вызовы backend — через `@/api` / services, не raw `fetch` из page.tsx без слоя API.
+- RSC/route handlers **must not import UI components with client-only dependencies** directly into the server tree without a `'use client'` boundary.
+- Domain types — `@/types`; backend calls — via `@/api` / services, not raw `fetch` from `page.tsx` without an API layer.
 
 ## Anti-hallucination (App Router)
 
-Меньше угаданного кода лучше, чем больше. Сверяй API с версией Next в `package.json` и соседними routes.
+Less guessed code is better than more. Cross-check APIs against the Next version in `package.json` and neighboring routes.
 
 | ❌ Avoid | ✅ Prefer |
 |---------|----------|
@@ -45,6 +45,6 @@ alwaysApply: false
 
 See also: **`react-next-anti-hallucination`** — broader React / RTK / Next phantom-import banlist (requestable).
 
-## Эталон
+## Reference
 
-Смотри существующий route той же сложности в `app/src/app/**` и повтори структуру (`reference-features.mdc`).
+Look at an existing route of similar complexity in `app/src/app/**` and repeat its structure (`reference-features.mdc`).

package/presets/cursor/next/rules/no-props-spread.mdc

@@ -1,41 +1,41 @@
 ---
-description: Избегать спред-а пропов при передаче в компоненты
+description: Avoid prop spread when passing props to components
 globs: app/src/**/*.tsx
 alwaysApply: false
 ---
 
-# Не использовать спред пропов при передаче в компоненты
+# Do not use prop spread when passing props to components
 
-При вызове **пользовательских** React-компонентов (имя с заглавной буквы: `IconBox`, `TextField`, ваши `FooBar`) **передавать пропы явно**, а не через spread (`{...props}`, `{...obj}`).
+When calling **custom** React components (PascalCase names: `IconBox`, `TextField`, your `FooBar`), **pass props explicitly**, not via spread (`{...props}`, `{...obj}`).
 
-**Агентам и при ревью:** не «упрощать» JSX через объект с последующим spread — это нарушение. Если ветвление по пропам длинное, используйте два явных JSX-блока (`condition ? <A … /> : <B … />`) или отдельные маленькие компоненты, а не `{...mergedProps}`.
+**For agents and review:** do not “simplify” JSX by building an object and spreading it — that violates this rule. If prop branching is long, use two explicit JSX blocks (`condition ? <A … /> : <B … />`) or separate small components, not `{...mergedProps}`.
 
-## Почему
+## Why
 
-- Явная передача делает зависимости компонента очевидными при чтении кода.
-- Упрощает рефакторинг и поиск использований.
-- Снижает риск случайно пробросить лишние или устаревшие пропы.
+- Explicit props make component dependencies obvious when reading code.
+- Easier refactoring and usage search.
+- Reduces the risk of accidentally passing extra or stale props.
 
-## Проверка в репозитории
+## Repo enforcement
 
-- Для файлов `app/src/ui/**/*.tsx` включено ESLint-правило `react/jsx-props-no-spreading` (`app/eslint.config.mjs`): несоблюдение увидит линтер и CI.
-- Легитимное исключение в конкретном месте — **однострочный** `eslint-disable-next-line react/jsx-props-no-spreading` с кратким комментарием «почему»; для редких обёрток допустим disable на файл (как в `PromocodeInput`).
+- For `app/src/ui/**/*.tsx`, ESLint rule `react/jsx-props-no-spreading` is enabled (`app/eslint.config.mjs`): linter and CI will catch violations.
+- A legitimate local exception — a **single-line** `eslint-disable-next-line react/jsx-props-no-spreading` with a brief “why” comment; for rare wrappers, a file-level disable is acceptable (as in `PromocodeInput`).
 
-## Примеры
+## Examples
 
 ```tsx
-// ❌ Плохо
+// ❌ Bad
 const commonProps = { a, b, c }
 return <Child {...commonProps} />
 
-// ❌ Плохо
+// ❌ Bad
 return <Child {...props} />
 
-// ❌ Плохо (spread из соседнего модуля стилей тоже не оправдание)
+// ❌ Bad (spread from a neighboring styles module is not an excuse)
 const iconProps = cond ? { name, size: 'm' } : { name, size: 'm', ...styles.IconBoxAccent }
 return <IconBox {...iconProps} />
 
-// ✅ Хорошо
+// ✅ Good
 return (
   <Child
     a={a}
@@ -44,7 +44,7 @@ return (
   />
 )
 
-// ✅ Хорошо — явные пропсы по веткам
+// ✅ Good — explicit props per branch
 return cond ? (
   <IconBox name={name} size="m" variant="warning" />
 ) : (
@@ -56,7 +56,7 @@ return cond ? (
 )
 ```
 
-## Исключения
+## Exceptions
 
-- Передача пропов в **нативный** DOM-элемент (`<div {...rest} />`) допустима, если `rest` содержит только валидные HTML-атрибуты.
-- Делегирование пропов в обёртку (wrapper) допустимо, если это явно документировано и обосновано; при необходимости пометьте файл или строку через ESLint-disable, как выше.
+- Passing props to a **native** DOM element (`<div {...rest} />`) is allowed if `rest` contains only valid HTML attributes.
+- Delegating props in a wrapper is allowed if explicitly documented and justified; mark the file or line via ESLint-disable as above when needed.

package/presets/cursor/next/rules/no-type-assertion-as-import-export.mdc

@@ -1,5 +1,5 @@
 ---
-description: Избегать приведения типов через as на границах модулей (импорт/экспорт)
+description: Avoid type assertions via as at module boundaries (import/export)
 globs:
   - app/src/api/**/*
   - app/src/store/**/*
@@ -7,54 +7,54 @@ globs:
 alwaysApply: false
 ---
 
-# Не использовать `as` для приведения типов при экспорте и импорте (кроме необходимых случаев)
+# Do not use `as` for type assertions on export and import (except necessary cases)
 
-## О чём речь
+## Scope
 
-Речь о **type assertion** в TypeScript: выражение вида `значение as Тип`.
+This covers **type assertion** in TypeScript: an expression like `value as Type`.
 
-**Не относится к правилу** (это не assertion, а синтаксис модулей):
+**Out of scope** (module syntax, not assertion):
 
-- переименование при экспорте: `export { foo as bar }`, `export { default as Baz } from '...'`;
-- переименование при импорте: `import { foo as bar } from '...'`;
-- `import type { Foo as Bar }` — алиас типа в импорте типов.
+- rename on export: `export { foo as bar }`, `export { default as Baz } from '...'`;
+- rename on import: `import { foo as bar } from '...'`;
+- `import type { Foo as Bar }` — type alias in a type-only import.
 
-## Требование
+## Requirement
 
-- На **публичной границе модуля** (то, что **экспортируется** из файла / barrel, и то, что сразу **присваивается импортированным символам** с принудительным приведением) **не использовать** `as Тип` для «подгонки» типов, если можно обойтись нормальной типизацией.
+- On the **public module boundary** (what is **exported** from a file / barrel, and what is immediately **assigned to imported symbols** with forced casting) **do not use** `as Type` to “fit” types when normal typing suffices.
 
-## Предпочитать вместо `as`
+## Prefer instead of `as`
 
-- явную аннотацию: `const x: T = ...` / `function f(): T`;
-- **дженерики** у функций и классов;
-- **`satisfies`** (когда нужно проверить совместимость без сужения до `any`);
-- сужение **`unknown`** после проверки (type guards, `zod` и т.п.);
-- правку **исходных типов/DTO/мапперов**, а не assertion на выходе.
+- explicit annotation: `const x: T = ...` / `function f(): T`;
+- **generics** on functions and classes;
+- **`satisfies`** (when you need compatibility check without narrowing to `any`);
+- narrowing **`unknown`** after checks (type guards, `zod`, etc.);
+- fixing **source types/DTO/mappers**, not assertion at the output.
 
-## Когда `as` допустим
+## When `as` is allowed
 
-- взаимодействие с **не типизированными** или некорректно типизированными внешними модулями, где нет разумной альтернативы;
-- узкие места после **валидации** данных, если типовый гард всё ещё не выразить без шума (предпочтительно всё же guard/`satisfies`);
-- **`as const`** — когда нужны литеральные типы и широкий вывод ломает контракт (это отдельный механизм; применять по делу, не как замену типизации API).
-- блок **`catch (error)`** после вызова HTTP через общий клиент: по возможности сужать через **`instanceof`** на **класс ошибки транспорта** из `@/types` (какой именно — по существующей реализации) и работать с уже суженным типом; голый **`as` к тому же типу** — только если `instanceof` недоступен (иной источник выброса) и осознанно.
+- interaction with **untyped** or incorrectly typed external modules where there is no reasonable alternative;
+- narrow spots after **validation** when a type guard is still too noisy (prefer guard/`satisfies`);
+- **`as const`** — when literal types are needed and wide inference breaks the contract (separate mechanism; use as needed, not as a substitute for API typing).
+- **`catch (error)`** block after HTTP via the shared client: prefer narrowing via **`instanceof`** on the **transport error class** from `@/types` (which one — per existing implementation) and work with the narrowed type; bare **`as`** to the same type — only if `instanceof` is unavailable (different throw source) and intentional.
 
-## Примеры
+## Examples
 
 ```typescript
-// ❌ Плохо: assertion на экспортируемом API
+// ❌ Bad: assertion on exported API
 export const config = loadRaw() as AppConfig
 
-// ✅ Лучше: аннотация + проверка или маппер
+// ✅ Better: annotation + check or mapper
 export const config: AppConfig = mapToAppConfig(loadRaw())
 
-// ❌ Плохо: сразу после импорта «ломаем» тип
+// ❌ Bad: immediately after import “breaks” the type
 import { getData } from './api'
 export const data = getData() as MyDto[]
 
-// ✅ Лучше: типизировать getData / обернуть типобезопасной функцией
+// ✅ Better: type getData / wrap in a type-safe function
 ```
 
-## Требование к агенту
+## Agent requirement
 
-При ревью и генерации кода **не добавлять** новые `as Тип` на экспортируемые сущности и на цепочку import → export без явной необходимости; по возможности исправлять контракт типов в источнике.
-- В слайсах и сервисах при обработке ошибок API сначала рассматривать **`instanceof`** на класс ошибки транспорта из `@/types` по образцу существующего кода (`http-client.mdc`, `store-rtk.mdc`).
+When reviewing and generating code **do not add** new `as Type` on exported entities and on import → export chains without explicit need; fix the type contract at the source when possible.
+- In slices and services when handling API errors, consider **`instanceof`** on the transport error class from `@/types` first, following existing code (`http-client.mdc`, `store-rtk.mdc`).

package/presets/cursor/next/rules/package-manager.mdc

@@ -1,16 +1,16 @@
 ---
-description: Перед командами в терминале определять менеджер пакетов репозитория и использовать только его
+description: Before terminal commands, detect the repository package manager and use only that one
 alwaysApply: true
 ---
 
-# Менеджер пакетов (терминал)
+# Package manager (terminal)
 
-Перед **`npm install` / `yarn` / `pnpm` / `bun`** и **`… run …`** определи менеджер репозитория и **используй только его**.
+Before **`npm install` / `yarn` / `pnpm` / `bun`** and **`… run …`**, detect the repository package manager and **use only that one**.
 
-## Как определить
+## How to detect
 
-1. **`packageManager`** в `package.json` (корень или `app/package.json`).
-2. **Lockfile** рядом: `yarn.lock` → yarn; `pnpm-lock.yaml` → pnpm; `package-lock.json` → npm; `bun.lock(b)` → bun.
-3. Если неоднозначно — где `node_modules` и какой lockfile в CI.
+1. **`packageManager`** in `package.json` (root or `app/package.json`).
+2. **Lockfile** nearby: `yarn.lock` → yarn; `pnpm-lock.yaml` → pnpm; `package-lock.json` → npm; `bun.lock(b)` → bun.
+3. If ambiguous — where `node_modules` lives and which lockfile CI uses.
 
-Рабочий каталог для scripts — **`app/`**. Примеры: `yarn lint`, `pnpm run test`. Не угадывай — проверь файлы.
+Working directory for scripts — **`app/`**. Examples: `yarn lint`, `pnpm run test`. Do not guess — check the files.

package/presets/cursor/next/rules/post-change-lint.mdc

@@ -1,40 +1,40 @@
 ---
-description: Прогон ESLint и Stylelint после изменений кода. Requestable — подгружать после правок app/**; агенты обязаны запускать после code edits.
+description: Run ESLint and Stylelint after code changes. Requestable — load after app/** edits; agents must run after code edits.
 alwaysApply: false
 ---
 
-# Линтеры после изменений кода
+# Linters after code changes
 
-**Requestable, но обязателен при изменениях кода:** правило не always-on (экономия контекста); после правок исходников агент **должен** следовать этому чеклисту.
+**Requestable, but must run on code changes:** the rule is not always-on (saves context); after editing source files the agent **must** follow this checklist.
 
-## Когда применять
+## When to apply
 
-После **любого** изменения исходников в `app/**` (TS/TSX/JS/MJS, CSS, styled/Linaria в `.ts`/`.tsx`).
+After **any** change to source files in `app/**` (TS/TSX/JS/MJS, CSS, styled/Linaria in `.ts`/`.tsx`).
 
-Исключения: правки документации вне `app/`, конфигов CI, `.cursor/rules/**`, если исполняемый код приложения не менялся.
+Exceptions: documentation edits outside `app/`, CI configs, `.cursor/rules/**`, if application executable code did not change.
 
-**Pipeline exception:** если задача идёт через agent team и следующий шаг — `build-verifier`, developer может ограничиться lint/type-check **изменённых файлов**; полный прогон — обязанность `build-verifier`. В single-agent режиме (без pipeline) — всегда полный прогон.
+**Pipeline exception:** if the task runs through the agent team and the next step is `build-verifier`, the developer may limit lint/type-check to **changed files**; full run is **`build-verifier`’s** responsibility. In single-agent mode (no pipeline) — always a full run.
 
-## Обязательные команды
+## Required commands
 
-Рабочий каталог — **`app/`**. Менеджер пакетов — **`package-manager.mdc`**.
+Working directory — **`app/`**. Package manager — **`package-manager.mdc`**.
 
-1. **`lint:js`** — полный ESLint по проекту.
-2. **`lint:css`** — полный Stylelint (`**/*.{css,ts}`).
+1. **`lint:js`** — full ESLint across the project.
+2. **`lint:css`** — full Stylelint (`**/*.{css,ts}`).
 
-Точечный lint на один файл **не заменяет** полный прогон перед завершением задачи (кроме pipeline exception выше).
+Targeted lint on one file **does not replace** a full run before completing the task (except the pipeline exception above).
 
-## Алгоритм
+## Procedure
 
-1. Завершить правки кода.
-2. Запустить **`lint:js`** и **`lint:css`** из `app/`.
-3. Проанализировать весь вывод; исправить errors/warnings в изменённых файлах; для Stylelint — **`lint:css --fix`** если автоисправимо.
-4. Повторить до exit code 0 или зафиксировать блокер в ответе пользователю.
-5. **`type-check`** при изменениях TypeScript. CI-уровень: **`lint`** (= `lint:js` + `lint:css` + `type-check`).
+1. Finish code edits.
+2. Run **`lint:js`** and **`lint:css`** from `app/`.
+3. Analyze full output; fix errors/warnings in changed files; for Stylelint — **`lint:css --fix`** if auto-fixable.
+4. Repeat until exit code 0 or record a blocker in the user response.
+5. **`type-check`** when TypeScript changed. CI level: **`lint`** (= `lint:js` + `lint:css` + `type-check`).
 
-## Что исправлять
+## What to fix
 
-- **Errors** — обязательно.
-- **Warnings** — обязательно в файлах задачи; вне скоупа — упомянуть, если мешают нулевому exit code.
+- **Errors** — must fix.
+- **Warnings** — must fix in task files; out of scope — mention if they block a zero exit code.
 
-Конфиги: `app/eslint.config.mjs`, `app/.stylelintrc` (порядок CSS — `css-property-order-stylelint.mdc`).
+Configs: `app/eslint.config.mjs`, `app/.stylelintrc` (CSS order — `css-property-order-stylelint.mdc`).

package/presets/cursor/next/rules/preset-layering.mdc

@@ -9,29 +9,28 @@ alwaysApply: false
 
 <!-- shared-core: meta/preset-layering.md -->
 
-
 # Preset layering
 
-Правила для **авторов пресетов** (`packages/ai-rules/presets/**`). Не always-on в consumer apps.
+Rules for **preset authors** (`packages/ai-rules/presets/**`). Not always-on in consumer apps.
 
-## Слои
+## Layers
 
-| Слой | Где | Что класть |
-|------|-----|------------|
-| **Core** | `presets/_shared/core/**` | Stack-agnostic prose + checklists; без frontmatter; без путей `app/**`, `Features/**`, Playwright, xcodebuild |
-| **Stack** | `presets/{cursor\|claude}/<stack>/` | Domain/tooling, always-on trio стека, stack examples в **Stack notes** |
+| Layer | Where | What to put |
+|-------|-------|-------------|
+| **Core** | `presets/_shared/core/**` | Stack-agnostic prose + checklists; no frontmatter; no paths `app/**`, `Features/**`, Playwright, xcodebuild |
+| **Stack** | `presets/{cursor\|claude}/<stack>/` | Domain/tooling, stack always-on trio, stack examples in **Stack notes** |
 | **Platform** | Cursor `.mdc` / Claude `.md` | Frontmatter (`alwaysApply`/`globs` vs `paths:`), platform-only (`BUGBOT.md`, `CLAUDE.md`) |
 
-## Куда класть новое правило
+## Where to put a new rule
 
-1. Общие принципы для всех стеков → **core** + адаптеры с `<!-- shared-core: … -->`.
-2. Только один из installable стеков (`next` / `nuxt` / `svelte` / `ios-swift` / `go` / `java` / `mcp-ts` / `php-hexagonal` / `php-laravel`) → **stack-specific** (не в `_shared`).
-3. Только Cursor или только Claude packaging → platform artifact / frontmatter, не дублировать семантику.
+1. Shared principles for all stacks → **core** + adapters with `<!-- shared-core: … -->`.
+2. Only one of the installable stacks (`next` / `nuxt` / `svelte` / `ios-swift` / `android-kotlin` / `go` / `java` / `mcp-ts` / `php-hexagonal` / `php-laravel`) → **stack-specific** (not in `_shared`).
+3. Only Cursor or only Claude packaging → platform artifact / frontmatter; do not duplicate semantics.
 
 ## SoT
 
 - Packages path — SoT; root `.cursor/` — dogfood sync.
 - Per stack: **Cursor** `presets/cursor/<stack>/` → Claude twin same PR.
-- `_shared` **не** `--preset` и не копируется CLI `init`.
+- `_shared` is **not** a `--preset` and is not copied by CLI `init`.
 
-См. также: `preset-twin-sync`, `preset-token-budget`, `preset-pr-checklist`, `preset-no-cross-stack-leakage`.
+See also: `preset-twin-sync`, `preset-token-budget`, `preset-pr-checklist`, `preset-no-cross-stack-leakage`.