@bonesofspring/ai-rules 0.2.13 → 0.2.15

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

@@ -2,10 +2,10 @@
 
 Unit, e2e, Playwright agents.
 
-| Файл | Содержание | Загрузка |
-|------|------------|----------|
-| `playwright-agents.md` | Planner / generator / healer — структура e2e | session start |
-| `tests-unit.md` | Unit/integration, именование на русском | `paths: app/src/**/*.spec.*`, `*.test.*` |
+| File | Contents | Loading |
+|------|----------|---------|
+| `playwright-agents.md` | Planner / generator / healer — e2e structure | session start |
+| `tests-unit.md` | Unit/integration; describe/it naming in Russian (locale) | `paths: app/src/**/*.spec.*`, `*.test.*` |
 | `tests-e2e-structure.md` | `*.cases.md`, page objects, data-testid | `paths: app/__tests__/e2e/**` |
 
-См. также `.claude/agents/playwright-test-*.md` после `ai-rules init`.
+See also `.claude/agents/playwright-test-*.md` after `ai-rules init`.

package/presets/claude/next/rules/testing/playwright-agents.md

@@ -71,4 +71,4 @@ When acting as a **Healer** (or working with the Playwright healer agent):
 
 Healer should keep tests aligned with the existing test plans (`*.cases.md`) and with the page objects and helpers already used in the project.
 
-См. также агенты в `.claude/agents/` пресета и **`testing/tests-e2e-structure.md`**.
+See also agents under the preset’s `.claude/agents/` and **`testing/tests-e2e-structure.md`**.

package/presets/claude/next/rules/testing/tests-e2e-structure.md

@@ -3,50 +3,51 @@ paths:
   - app/__tests__/e2e/**
 ---
 
-# Структура e2e в проекте
-
-- Папка e2e: `app/__tests__/e2e/**`.
-- Планы сценариев:
-  - `*.cases.md` файлы — **канонический источник сценариев**.
-- Тесты:
-  - `*.spec.ts` файлы — реализация сценариев на Playwright.
-- Общие утилиты и абстракции:
-  - `app/__tests__/e2e/_shared/**` — константы, fluent‑интерфейсы, хелперы.
-
-# Принципы
-
-- Каждый сценарий из `*.cases.md` должен иметь соответствующий тест (или набор тестов).
-- **Нельзя** ослаблять проверки в тестах, если это противоречит бизнес‑ожиданиям из планов.
-- Предпочтительно использовать:
-  - page‑objects (например, `OrderHistoryPage.ts`);
-  - общие хелперы из `_shared`.
-
-# Именование e2e‑тестов
-
-- Язык:
-  - все названия `test` / `it`, `describe`‑блоков и шагов в `*.cases.md` должны быть сформулированы **на русском языке**, описывая поведение и ожидаемый результат.
-- Формат заголовков e2e‑тестов (`test(...)` / `it(...)`):
-  - перед текстовым описанием сценария указывается **префикс с номером** в формате: `ПРЕФИКС-XXX Описание сценария`.
-  - `ПРЕФИКС` — аббревиатура из **первых букв слов** тестируемой сущности, записанная **латиницей в верхнем регистре**.
-    - пример: `OrderHistory` → `OH`, `BillingReport` → `BR`.
-  - `XXX` — порядковый номер теста **с тремя разрядами и лидирующими нулями**: `001`, `002`, `010`, `123` и т.д.
-  - пример полного названия e2e‑теста:
-    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })`
-  - внутри одной сущности (`ПРЕФИКС`) номера тестов должны образовывать **непротиворечивую последовательность**, без дубликатов номеров.
-
-# data-testid для e2e
-
-- **Приоритет селекторов:** `data-testid` для стабильных элементов; `getByRole` и `getByLabel` для форм и доступных элементов.
-- **Именование:** схема `{parent}__{element}` (например, `history-page__title`, `history-page__recognition-banner__attach-files-button`).
-- **Где добавлять:** на корневые контейнеры страниц и ключевые интерактивные элементы (кнопки, ссылки, поля), к которым обращаются page objects.
-- **При изменении UI:** обновлять data-testid в компонентах и соответствующие селекторы в page objects; сверять с `*.cases.md`.
-
-# Требование к агенту
-
-При добавлении/изменении e2e‑тестов:
-
-- Сначала смотреть соответствующий `*.cases.md` и синхронизировать названия сценариев.
-- Размещать спеки рядом с планами в той же директории.
-- Переиспользовать общие page‑objects и хелперы, а не копировать селекторы напрямую в каждый тест.
-
-См. также **`testing/playwright-agents.md`** для planner/generator/healer.
+# E2E structure in the project
+
+- E2E folder: `app/__tests__/e2e/**`.
+- Scenario plans:
+  - `*.cases.md` files — **canonical source of scenarios**.
+- Tests:
+  - `*.spec.ts` files — Playwright scenario implementations.
+- Shared utilities and abstractions:
+  - `app/__tests__/e2e/_shared/**` — constants, fluent interfaces, helpers.
+
+# Principles
+
+- Every scenario from `*.cases.md` must have a corresponding test (or set of tests).
+- **Do not** weaken assertions in tests if that contradicts business expectations from the plans.
+- Prefer:
+  - page objects (for example, `OrderHistoryPage.ts`);
+  - shared helpers from `_shared`.
+
+# E2E test naming
+
+- Language:
+  - in consumer apps, `test` / `it`, `describe` block titles, and steps in `*.cases.md` **may use the project locale** (often Russian) — phrasing behavior and expected outcome;
+  - when the repo ESLint or team convention requires Russian titles, follow that; otherwise use clear English business phrases.
+- E2E test title format (`test(...)` / `it(...)`):
+  - before the scenario description, include a **numbered prefix** in the form: `PREFIX-XXX Scenario description`.
+  - `PREFIX` — abbreviation from the **first letters of words** in the entity under test, written **in Latin uppercase**.
+    - example: `OrderHistory` → `OH`, `BillingReport` → `BR`.
+  - `XXX` — sequential test number **with three digits and leading zeros**: `001`, `002`, `010`, `123`, etc.
+  - full e2e test title example (Russian locale in consumer app):
+    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })` <!-- i18n-keep: E5 --> (Order list is displayed)
+  - within one entity (`PREFIX`), test numbers must form a **consistent sequence** with no duplicate numbers.
+
+# data-testid for e2e
+
+- **Selector priority:** `data-testid` for stable elements; `getByRole` and `getByLabel` for forms and accessible elements.
+- **Naming:** `{parent}__{element}` scheme (for example, `history-page__title`, `history-page__recognition-banner__attach-files-button`).
+- **Where to add:** on page root containers and key interactive elements (buttons, links, fields) that page objects target.
+- **When changing UI:** update data-testid in components and matching selectors in page objects; cross-check with `*.cases.md`.
+
+# Agent requirement
+
+When adding/changing e2e tests:
+
+- First read the matching `*.cases.md` and sync scenario titles.
+- Place specs next to plans in the same directory.
+- Reuse shared page objects and helpers instead of copying selectors directly into every test.
+
+See also **`testing/playwright-agents.md`** for planner/generator/healer.

package/presets/claude/next/rules/testing/tests-unit.md

@@ -7,73 +7,72 @@ paths:
 impact: MEDIUM
 ---
 
-# Общие правила тестирования
-
-- **Имена файлов:** для **новых** тестов использовать суффикс **`*.spec.ts` / `*.spec.tsx`**. Существующие **`*.test.ts` / `*.test.tsx`** не переименовывать без отдельной задачи (легаси).
-- **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@testing-library/react**.
-- Основная цель тестов:
-  - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
-- **Именование unit‑тестов** (строки в `describe` / `it` / `test`):
-  - формулировки **только на русском языке** — понятные бизнес‑фразы (что проверяется и какой ожидается результат);
-  - **каждое предложение** в названии **начинается с заглавной буквы** (в том числе после `.`, `!`, `?` и при нескольких предложениях в одной строке); первая буква всей строки — тоже заглавная.
-  - **Проверка в CI:** ESLint (`jest/valid-title` в `app/eslint.config.mjs`) требует, чтобы строка начиналась с русской заглавной (А–Я, Ё), и запрещает пробел после точки, за которым сразу идёт строчная буква (типичный случай нарушения «с заглавной после точки»).
-
-```typescript
-// ✅ Хорошо
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-it('При ошибке сети показывается сообщение об ошибке', () => {})
-
-// ❌ Плохо (не с заглавной после точки; или не русский)
-it('Возвращает пустой список. пользователь не авторизован', () => {})
-it('Returns empty list when user is guest', () => {})
-```
+# General testing rules
+
+- **File names:** for **new** tests use the **`*.spec.ts` / `*.spec.tsx`** suffix. Do not rename existing **`*.test.ts` / `*.test.tsx`** without a separate task (legacy).
+- **Runner and matchers** — as in the project (often Jest or Vitest); for components — **@testing-library/react**.
+- Primary goal of tests:
+  - verify **behavior and business rules**, not implementation or internal details.
+- **Unit test naming** (strings in `describe` / `it` / `test`):
+  - consumer apps **may use Russian locale** for titles — clear business phrases (what is checked and expected outcome);
+  - when ESLint enforces Russian (see below), each sentence in the title **must start with a capital letter** (including after `.`, `!`, `?` and with multiple sentences on one line); the first letter of the whole string is capitalized too.
+  - **CI check (when configured):** ESLint (`jest/valid-title` in `app/eslint.config.mjs`) may require titles to start with a Russian capital letter and forbid a space after `.` followed immediately by a lowercase letter (typical "capital after period" violation).
+
+Good (Russian locale in consumer app):
+
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 --> (Returns empty list. User is not authorized)
+- `it('При ошибке сети показывается сообщение об ошибке', () => {})` <!-- i18n-keep: E5 --> (On network error, an error message is shown)
+
+Bad (no capital after period; or wrong locale for configured ESLint):
 
-# Тесты компонентов
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+- `it('Returns empty list when user is guest', () => {})`
 
-- Использовать `render` из `@testing-library/react`.
-- Ассерты:
-  - матчеры DOM для Testing Library, как подключены в проекте (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
-- Взаимодействия:
-  - `userEvent` из `@testing-library/user-event`.
+# Component tests
 
-# Изоляция и моки
+- Use `render` from `@testing-library/react`.
+- Assertions:
+  - DOM matchers for Testing Library as wired in the project (`toBeInTheDocument`, `toHaveTextContent`, etc.).
+- Interactions:
+  - `userEvent` from `@testing-library/user-event`.
 
-- Для работы с API/store:
-  - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
-- Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
+# Isolation and mocks
 
-# HTTP‑клиент
+- For API/store work:
+  - mock the store (via test-store) or use the project's accepted HTTP/API mock approach.
+- Do not mock what is part of the feature's public contract if that breaks the test's meaning.
 
-- При изменении **реализации общего HTTP‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `app/src/lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
-- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
+# HTTP client
 
-# Мапперы и преобразование данных
+- When changing the **shared HTTP client implementation** (body parsing, headers, error branches, 401/refresh, `FormData`, `blob`, etc.) — **update or add behavior tests** next to the client module in `app/src/lib/clients/**` (prefer `*.spec.ts`; legacy `*.test.ts` — do not touch without a task).
+- Cover meaningful branches: successful JSON, HTTP error, network, auth scenarios relevant to the project.
 
-- Функции маппинга данных (DTO → доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
-- В тестах мапперов особое внимание уделять edge‑кейсам и регрессии бизнес‑правил (например, граничные значения, отсутствие полей, неожиданные комбинации значений).
+# Mappers and data transformation
 
-# Требование к агенту
+- Data mapping functions (DTO → domain model and back), especially with computed fields and branches, must have unit tests.
+- In mapper tests, pay special attention to edge cases and business-rule regression (for example, boundary values, missing fields, unexpected value combinations).
 
-При добавлении тестов:
+# Agent requirement
 
-- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
-- Добавлять тесты для критичных веток логики и edge‑кейсов.
-- При работе с данными:
-  - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
-  - по возможности опираться на данные и обработчики из `app/src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные «с нуля».
-- Размещение:
-  - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.tsx`.
-  - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
-  - **новые** файлы — `*.spec.ts` / `*.spec.tsx` (см. блок «Имена файлов» выше).
+When adding tests:
+
+- Follow existing test structure and patterns in the repository: `*.spec.ts(x)` next to the module or in a shared test directory — as in neighboring features.
+- Add tests for critical logic branches and edge cases.
+- When working with data:
+  - use **response types** from the API (DTO types) and **target domain types** from `@/types`; do not duplicate interfaces in tests;
+  - when possible, rely on data and handlers from `app/src/mocks/**` (or repo equivalent), not ad-hoc random test data.
+- Placement:
+  - for **UI components** — **do not create** a `__tests__` subdirectory inside the component folder; the test is a sibling `*.spec.tsx`.
+  - in **other modules** (for example `api/services`) an existing `__tests__` layout is acceptable — do not break it for UI uniformity.
+  - **new** files — `*.spec.ts` / `*.spec.tsx` (see "File names" above).
 ## Incorrect
 
 ```ts
 it('returns empty list when guest', () => {})
-it('Возвращает пустой список. пользователь не авторизован', () => {})
 ```
 
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+
 ## Correct
 
-```ts
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-```
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->

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

@@ -1,15 +1,15 @@
 # Tooling and review
 
-Lint, package manager, качество кода, agent team, code review MR.
+Lint, package manager, code quality, agent team, code review MR.
 
-| Файл | Содержание | Загрузка |
-|------|------------|----------|
-| `package-manager.md` | yarn / pnpm / npm / bun — определить по lockfile | session start |
-| `post-change-lint.md` | `lint:js` + `lint:css` после изменений (**обязателен** при code edits) | `paths:` commands/team/agents + `app/**` |
-| `code-quality.md` | Boy scout rule, рефакторинг, ESLint | session start |
-| `agent-team-intake.md` | Когда предлагать `/task` и router pipeline | `paths:` commands/team |
+| File | Contents | Loading |
+|------|----------|---------|
+| `package-manager.md` | yarn / pnpm / npm / bun — detect from lockfile | session start |
+| `post-change-lint.md` | `lint:js` + `lint:css` after changes (**required** on code edits) | `paths:` commands/team/agents + `app/**` |
+| `code-quality.md` | Boy scout rule, refactoring, ESLint | session start |
+| `agent-team-intake.md` | When to suggest `/task` and the router pipeline | `paths:` commands/team |
 | `agent-team-orchestrator.md` | Dynamic agent team: router, pipeline, gates | `paths:` commands/team/agents |
-| `code-review-mr.md` | Чеклист ревью merge request + output contract | `paths:` review-related |
+| `code-review-mr.md` | Merge-request review checklist + output contract | `paths:` review-related |
 | `security-next.md` | Secrets, auth, XSS, Server Actions (coding-time) | `paths:` app/auth/env |
 
-On-demand (не rule): **`commands/technical-retro.md`** (фасилитация ретро).
+On-demand (not a rule): **`commands/technical-retro.md`** (retro facilitation).

package/presets/claude/next/rules/tooling-and-review/agent-team-intake.md

@@ -12,6 +12,6 @@ When the user message looks like a **work request** (implement, add, fix, refact
 
 1. Prefer **`/task <their request>`** or invoke **task-router** first.
 2. Do not jump straight to coding without router + pipeline when scope is non-trivial.
-3. Pure questions («как работает X», «объясни») — prefer agent **`codebase-analyzer`** (explain-as-is); trivial one-liners may be answered inline. Do not open `/task`.
+3. Pure questions (“how does X work”, “explain”) — prefer agent **`codebase-analyzer`** (explain-as-is); trivial one-liners may be answered inline. Do not open `/task`.
 
-Exceptions: user explicitly says «без pipeline», «просто сделай», or continues an active slug.
+Exceptions: user explicitly says “no pipeline”, “just do it”, or continues an active slug.

package/presets/claude/next/rules/tooling-and-review/agent-team-orchestrator.md

@@ -12,7 +12,7 @@ paths:
 
 Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.claude/team/tasks/<slug>/`.
 
-Work request без `/task` — см. **`tooling-and-review/agent-team-intake.md`**.
+Work request without `/task` — see **`tooling-and-review/agent-team-intake.md`**.
 
 ## Entry points
 
@@ -175,12 +175,12 @@ If `pipeline.json` is missing (old `/feature-start` tasks), fall back to fixed p
 
 Do **not** run `/task` + router for:
 
-- Pure questions («как работает X», «объясни») — prefer agent **`codebase-analyzer`** for deep traces; inline OK for trivial one-liners.
+- Pure questions («как работает X» (how does X work), «объясни» (explain)) — prefer agent **`codebase-analyzer`** for deep traces; inline OK for trivial one-liners. <!-- i18n-keep: E4 -->
 - Typo / one-file fix / trivial config with no architecture risk.
-- User explicitly says «без pipeline», «просто сделай», or continues an active slug.
+- User explicitly says «без pipeline» (no pipeline), «просто сделай» (just do it), or continues an active slug. <!-- i18n-keep: E4 -->
 - Single-line `docs-only` with no code impact.
 
-Borderline work requests — см. **`tooling-and-review/agent-team-intake.md`**.
+Borderline work requests — see **`tooling-and-review/agent-team-intake.md`**.
 
 ## Auto-detection (optional)
 

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

@@ -1,50 +1,51 @@
 ---
-description: Поддержка и улучшение качества кода и архитектуры
+description: Maintain and improve code quality and architecture
 ---
 
 <!-- shared-core: quality/code-quality-and-refactoring.md -->
 
-# Поддержка существующего стиля
+# Match existing style
 
-- Следовать существующим паттернам (имена, структура, типизация / DI / error handling); минимизировать стилистический шум (лишний format/rename).
-- Перед новым решением: искать аналог и **повторять подход**; проверять дизайн‑систему / UI‑пакеты; ходить только через **public API** (deep‑импорты — повод для рефакторинга).
+- Follow existing patterns (names, structure, typing / DI / error handling); avoid drive-by formatting or renames.
+- Before a new solution: find an analog and **repeat the approach**; check the design system / UI packages; go only through the **public API** (deep imports are a reason to refactor).
 
-# Принципы
+# Principles
 
-- **KISS:** самое простое изменение в паттернах репозитория.
-- **DRY + Rule of Three:** общее — только после 3-го повторения (ошибочная абстракция дороже дублирования).
-- **YAGNI:** без API, флагов, слоёв «на будущее» без текущего требования.
-- **SOLID:** S — один повод менять; O — композиция/новые реализации; L — контракт подтипа; I — узкие порты; D — абстракции (порты), детали в адаптерах стека.
-- **CUPID:** Composable; Unix philosophy (одна ответственность); Predictable; Idiomatic (репо); Domain-based.
-- **Composition over inheritance;** Law of Demeter — без цепочек `a.b.c.d`; через public API / facade.
+- **KISS:** the simplest change in the repository’s patterns.
+- **DRY + Rule of Three:** share only after the 3rd repetition (wrong abstraction costs more than duplication).
+- **YAGNI:** no APIs, flags, or “for later” layers without a current requirement.
+- **SOLID:** S — one reason to change; O — composition/new implementations; L — subtype contract; I — narrow ports; D — abstractions (ports), details in stack adapters.
+- **CUPID:** Composable; Unix philosophy (one responsibility); Predictable; Idiomatic (repo); Domain-based.
+- **Composition over inheritance;** Law of Demeter — no `a.b.c.d` chains; via public API / facade.
 
-# Рефакторинг при изменениях
+# Refactoring during changes
 
-- Лёгкий refactor OK, если меньше дублирования, выше читаемость, без ломки публичных контрактов.
-- Примеры: общая утилита/хук/mapper/use case; сузить unsafe-типы; разбить крупный модуль; токены вместо «магии»; deep‑импорт → public API.
-- Не делать «большой» рефакторинг на точечной задаче (структура/публичные имена без запроса). Крупное — минимальными шагами; код остаётся собираемым.
+- Light refactor is OK if it reduces duplication, improves readability, and does not break public contracts.
+- Examples: shared utility/hook/mapper/use case; narrow unsafe types; split a large module; tokens instead of “magic”; deep import → public API.
+- Do not do a “big” refactor on a point task (structure/public names without a request). Break large work into minimal steps; keep the repo buildable after each step.
 
-# Требование к агенту
+# Agent requirement
 
-- **Boy scout:** оставлять модуль немного лучше; не жертвовать архитектурой и слоями ради краткости.
+- **Boy scout:** leave the module a bit better; do not sacrifice architecture and layers for brevity.
 
 ## Agent discipline (anti-sycophancy)
 
 Essentials below. Full procedural set (~17 rules) → load **`anti-sycophancy-discipline`**.
 
 - Unverifiable third-party API → mark `// VERIFY: lib.symbol @ version` (or stack equivalent); never invent signatures.
-- Before «is this correct?» — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
+- Before "is this correct?" — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
 - Refactor without tests → propose characterization test; if declined, label `UNTESTED`.
-- Comments = WHY only when non-obvious; ban self-referential «added for issue Y».
+- Comments = WHY only when non-obvious; ban self-referential "added for issue Y".
 - Urgency/authority: name the trade-off once, then comply — no apology loops.
 - Match verification to risk; report by what was **verified**, not attempted.
 
 Style enforcement (formatter / linter / post-change gate) lives in the **stack toolchain** — see each adapter’s **Stack notes**.
 
-> Stack-specific lint gates, примеры и toolchain — в секции **Stack notes** адаптера пресета.
+> Stack-specific lint gates, examples, and toolchain — in the preset adapter **Stack notes** section.
+
 ## Stack notes
 
-- Перед новым UI‑контролом проверять существующий UI‑код и пакеты проекта.
-- Public API: index/barrel‑файлы и явно экспортируемые сущности (`public-imports.mdc`, `layer-barrel-exports.mdc`).
-- Допустимые примеры: общий хук/утилита; типизация `any`/`unknown`; разделение крупного компонента; CSS‑токены вместо «магических» значений.
-- Lint/stylelint — только **`post-change-lint.mdc`**; ESLint config: `app/eslint.config.mjs`. Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) с кратким комментарием «зачем». Style prose in domain rules stays thin — prefer ESLint/Stylelint over duplicating formatter recipes.
+- Before adding a new UI control, check existing UI code and project packages.
+- Public API: index/barrel files and explicitly exported entities (`public-imports.mdc`, `layer-barrel-exports.mdc`).
+- Allowed examples: shared hook/utility; typing `any`/`unknown`; splitting a large component; CSS tokens instead of “magic” values.
+- Lint/stylelint — only **`post-change-lint.mdc`**; ESLint config: `app/eslint.config.mjs`. Disabling a rule (`eslint-disable`) — only **locally** (line/small block) with a short “why” comment. Style prose in domain rules stays thin — prefer ESLint/Stylelint over duplicating formatter recipes.

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

@@ -25,9 +25,9 @@ On-demand rule for review flows. **Procedure and output format:** skill `code-re
 - UI conventions of the stack
 - Unit and e2e/UI test conventions
 - Post-change lint/build gate before final report
-- Design smells **in MR diff scope** — load `design-guidance`; не разворачивать полный каталог Fowler вне диффа
-- Pattern name (GoF) — только если репозиторий уже использует эту форму или match минимален
-- Principles (KISS / DRY+Ro3 / YAGNI / SOLID / CUPID) — через always-on `code-quality-and-refactoring`, не дублировать эссе в review
+- Design smells **in MR diff scope** — load `design-guidance`; do not expand the full Fowler catalog outside the diff
+- Pattern name (GoF) — only if the repository already uses that shape or the match is minimal
+- Principles (KISS / DRY+Ro3 / YAGNI / SOLID / CUPID) — via always-on `code-quality-and-refactoring`, do not duplicate the essay in review
 
 Concrete rule stems — in **Stack notes**.
 
@@ -36,7 +36,7 @@ Concrete rule stems — in **Stack notes**.
 - Focus on MR diff, not the whole repo.
 - Use local `git diff` — do not invent hosting metadata.
 - Boy scout rule: suggest fixes feasible within the MR scope.
-- No «большие рефакторинги» without an explicit request (`code-quality-and-refactoring`).
+- No “big refactors” without an explicit request (`code-quality-and-refactoring`).
 
 ## Output contract