@bonesofspring/ai-rules 0.2.2 → 0.2.4

package/presets/claude/next/rules/stack/no-type-assertion.md

@@ -0,0 +1,59 @@
+---
+paths:
+  - app/src/api/**/*
+  - app/src/store/**/*
+  - app/src/types/**/*
+---
+
+# Не использовать `as` для приведения типов при экспорте и импорте
+
+## О чём речь
+
+Речь о **type assertion** в TypeScript: выражение вида `значение as Тип`.
+
+**Не относится к правилу** (это не assertion, а синтаксис модулей):
+
+- переименование при экспорте: `export { foo as bar }`, `export { default as Baz } from '...'`;
+- переименование при импорте: `import { foo as bar } from '...'`;
+- `import type { Foo as Bar }` — алиас типа в импорте типов.
+
+## Требование
+
+- На **публичной границе модуля** (экспорт, присваивание импортированным символам с принудительным приведением) **не использовать** `as Тип` для «подгонки» типов, если можно обойтись нормальной типизацией.
+
+## Предпочитать вместо `as`
+
+- явную аннотацию: `const x: T = ...` / `function f(): T`;
+- **дженерики** у функций и классов;
+- **`satisfies`** (когда нужно проверить совместимость без сужения до `any`);
+- сужение **`unknown`** после проверки (type guards, `zod` и т.п.);
+- правку **исходных типов/DTO/мапперов**, а не assertion на выходе.
+
+## Когда `as` допустим
+
+- взаимодействие с **не типизированными** или некорректно типизированными внешними модулями;
+- узкие места после **валидации** данных;
+- **`as const`** — литеральные типы;
+- блок **`catch (error)`** после HTTP: по возможности **`instanceof`** на **класс ошибки транспорта** из `@/types`; голый **`as`** — только если `instanceof` недоступен.
+
+## Примеры
+
+```typescript
+// ❌ Плохо: assertion на экспортируемом API
+export const config = loadRaw() as AppConfig
+
+// ✅ Лучше: аннотация + проверка или маппер
+export const config: AppConfig = mapToAppConfig(loadRaw())
+
+// ❌ Плохо: сразу после импорта «ломаем» тип
+import { getData } from './api'
+export const data = getData() as MyDto[]
+
+// ✅ Лучше: типизировать getData / обернуть типобезопасной функцией
+```
+
+## Требование к агенту
+
+При ревью и генерации кода **не добавлять** новые `as Тип` на экспортируемые сущности без явной необходимости.
+
+В слайсах и сервисах при обработке ошибок API сначала рассматривать **`instanceof`** на класс ошибки транспорта из `@/types` (`api-and-data/http-client.md`, `api-and-data/store-rtk.md`).

package/presets/claude/next/rules/stack/types-jsdoc.md

@@ -0,0 +1,37 @@
+---
+paths:
+  - app/src/types/**/*.ts
+---
+
+# Документация типов в `app/src/types`
+
+При добавлении или существенном изменении типов в этом слое **следовать уже принятому в репозитории стилю JSDoc** (см. примеры: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
+
+## Язык и форма
+
+- Текст комментариев — **на русском**, кратко и по делу.
+- **Не использовать** `@param`, `@returns`, `@see`, `@deprecated` для описания типов — достаточно обычного текста в `/** … */`.
+
+## Экспортируемый `type` / `interface`
+
+- Сразу **перед объявлением** — блок `/** … */`.
+- Для вложенных объектов — отдельный блок над каждым объявлением.
+
+## Поля
+
+- У **каждого** публичного свойства — **однострочный** `/** … */` над полем.
+- Если поле **вычисляется на фронте** — префикс **`[computed]`**.
+- Форматы данных указывать **в тексте** (например дата `YYYY-MM-DD`).
+
+## Классы и enum
+
+- Для **классов** — блок над классом и комментарии к публичным полям.
+- В `enums.ts` исторически часто **без JSDoc** на каждом члене; для новых enum допустимо описание **над enum**.
+
+## Практика для агента
+
+- Не оставлять новые публичные поля без пояснения, если смысл не равен имени на 100%.
+- Поддерживать **тот же стиль**, что в файле.
+- Одна-две фразы на тип, одна строка на поле — норма.
+
+См. также импорты и barrel: `architecture/public-imports.md`.

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

@@ -1,3 +1,11 @@
 # Testing
 
-Unit-тесты, e2e, структура Playwright-агентов — по отдельным `.md` при необходимости.
+Unit, e2e, Playwright agents.
+
+| Файл | Содержание | Загрузка |
+|------|------------|----------|
+| `playwright-agents.md` | Planner / generator / healer — структура e2e | session start |
+| `tests-unit.md` | Unit/integration, именование на русском | `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`.

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

@@ -0,0 +1,74 @@
+---
+paths:
+  - app/__tests__/e2e/**
+---
+
+# Playwright Agents in this project
+
+Playwright Agents (planner, generator, healer) **must follow the existing e2e structure**:
+
+- **Test directory**: `app/__tests__/e2e`
+- **Test plans (specs)**: `*.cases.md` files under `app/__tests__/e2e/**`
+- **Executable tests**: `*.spec.ts` files under `app/__tests__/e2e/**`
+- **Seed test**: `app/__tests__/e2e/seed.spec.ts`
+
+Do **not** introduce separate top-level `specs/` and `tests/` folders for real test coverage. Those may be used only as temporary sandboxes if explicitly requested.
+
+## Planner (test plans)
+
+When acting as a **Planner** (or working with the Playwright planner agent):
+
+- **Treat `*.cases.md` as the canonical test plan files**, equivalent to Playwright's `specs/*.md`.
+- **Location**:
+  - For a feature/domain, use the corresponding `*.cases.md` file under `app/__tests__/e2e`, e.g.:
+    - `app/__tests__/e2e/OrderHistory/order-history.cases.md`
+    - `app/__tests__/e2e/BillingReport/invoice-list.cases.md`
+- **Content requirements**:
+  - Group scenarios by feature and subfeature using headings.
+  - For each scenario include:
+    - clear title,
+    - preconditions,
+    - ordered steps,
+    - expected results.
+  - Write in concise business language, but precise enough for automatic test generation.
+- **Seed**:
+  - Assume environment is prepared by `app/__tests__/e2e/seed.spec.ts` (login, baseURL, mocks, etc.).
+
+When asked to "generate a test plan" for a feature, **create or update the appropriate `*.cases.md` file in `app/__tests__/e2e/**`**, not in a separate `specs/` folder.
+
+## Generator (tests from plans)
+
+When acting as a **Generator** (or working with the Playwright generator agent):
+
+- **Source of truth for scenarios**:
+  - Use the relevant `*.cases.md` file under `app/__tests__/e2e/**` as the test plan.
+- **Target for tests**:
+  - Generate or update `*.spec.ts` files under the same folder, e.g.:
+    - plan: `app/__tests__/e2e/OrderHistory/order-history.cases.md`
+    - tests: `app/__tests__/e2e/OrderHistory/order-history.spec.ts` (or additional `*.spec.ts` in that folder if needed).
+- **Structure**:
+  - Use `test.describe` to group by top-level plan sections (feature / user flow).
+  - Use `test(...)` titles that match scenario names from the plan.
+  - Prefer Page Object and fluent interfaces that already exist in this project, for example:
+    - `app/__tests__/e2e/OrderHistory/OrderHistoryPage.ts`
+    - shared helpers under `app/__tests__/e2e/_shared/`.
+- **Seed**:
+  - If a seed test is needed, use `app/__tests__/e2e/seed.spec.ts` as the reference for environment setup.
+
+Do **not** generate Playwright tests into a separate `tests/` folder by default. Keep all e2e tests under `app/__tests__/e2e/**` to respect project conventions.
+
+## Healer (fixing tests)
+
+When acting as a **Healer** (or working with the Playwright healer agent):
+
+- Operate only on `*.spec.ts` files under `app/__tests__/e2e/**`.
+- Use `*.cases.md` in the same folder as **documentation of the intended behavior**:
+  - Do not weaken or change business assertions in tests in a way that conflicts with the corresponding `*.cases.md`.
+  - Prefer updating locators, waits, and flow details to match the UI while keeping the scenario semantics intact.
+- When multiple specs are involved, prioritize:
+  - the spec file in the same folder as the failing test,
+  - then shared utilities in `app/__tests__/e2e/_shared/`.
+
+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`**.

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

@@ -0,0 +1,52 @@
+---
+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.

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

@@ -0,0 +1,66 @@
+---
+paths:
+  - app/src/**/*.spec.ts
+  - app/src/**/*.spec.tsx
+  - app/src/**/*.test.ts
+  - app/src/**/*.test.tsx
+---
+
+# Общие правила тестирования
+
+- **Имена файлов:** для **новых** тестов использовать суффикс **`*.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', () => {})
+```
+
+# Тесты компонентов
+
+- Использовать `render` из `@testing-library/react`.
+- Ассерты:
+  - матчеры DOM для Testing Library, как подключены в проекте (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
+- Взаимодействия:
+  - `userEvent` из `@testing-library/user-event`.
+
+# Изоляция и моки
+
+- Для работы с API/store:
+  - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
+- Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
+
+# HTTP‑клиент
+
+- При изменении **реализации общего HTTP‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `app/src/lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
+- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
+
+# Мапперы и преобразование данных
+
+- Функции маппинга данных (DTO → доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
+- В тестах мапперов особое внимание уделять edge‑кейсам и регрессии бизнес‑правил (например, граничные значения, отсутствие полей, неожиданные комбинации значений).
+
+# Требование к агенту
+
+При добавлении тестов:
+
+- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
+- Добавлять тесты для критичных веток логики и edge‑кейсов.
+- При работе с данными:
+  - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
+  - по возможности опираться на данные и обработчики из `app/src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные «с нуля».
+- Размещение:
+  - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.tsx`.
+  - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
+  - **новые** файлы — `*.spec.ts` / `*.spec.tsx` (см. блок «Имена файлов» выше).

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

@@ -1,3 +1,14 @@
 # Tooling and review
 
-Рефакторинг, качество кода, процесс ревью MR.
+Lint, package manager, качество кода, 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 |
+| `agent-team-orchestrator.md` | Dynamic agent team: router, pipeline, gates | `paths:` commands/team/agents |
+| `code-review-mr.md` | Чеклист ревью merge request | `paths:` review-related |
+
+On-demand (не rule): **`commands/technical-retro.md`** (фасилитация ретро).

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

@@ -0,0 +1,15 @@
+---
+paths:
+  - .claude/commands/**/*
+  - .claude/team/**/*
+---
+
+# Agent team intake
+
+When the user message looks like a **work request** (implement, add, fix, refactor, review MR, write tests, spike) — not a question about how code works:
+
+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», «объясни») — answer normally, no `/task`.
+
+Exceptions: user explicitly says «без pipeline», «просто сделай», or continues an active slug.

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

@@ -0,0 +1,145 @@
+---
+paths:
+  - .claude/commands/**/*
+  - .claude/team/**/*
+  - .claude/agents/**/*
+---
+
+# Agent team orchestrator
+
+Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.claude/team/tasks/<slug>/`.
+
+Work request без `/task` — см. **`tooling-and-review/agent-team-intake.md`**.
+
+## Entry points
+
+| Command | When |
+|---------|------|
+| **`/task <desc>`** | **Preferred** — router → dynamic pipeline → first agent |
+| `/task-continue <slug>` | After human gate or pause |
+| `/feature-start <desc>` | Legacy: analyst-only start (no router) |
+| `/feature-continue <slug>` | Alias of task-continue |
+| `/technical-retro [slug]` | Retro with agent team block |
+
+## Roles
+
+| Agent | May edit production code | Typical intent |
+|-------|--------------------------|----------------|
+| `task-router` | no | Every `/task` — writes `pipeline.json` |
+| `task-analyst` | no | feature, refactor, test-only, a11y, docs-only, migration |
+| `solution-architect` | no | spike, complex cross-layer feature |
+| `migration-specialist` | no | migration — phased upgrade plan |
+| `api-contract-reviewer` | no | new/changed backend API contracts |
+| `debugger` | yes, minimal fixes only | bugfix |
+| `ci-investigator` | yes, minimal CI fixes | ci-fix |
+| `feature-developer` | yes | feature, bugfix, refactor, migration, a11y |
+| `build-verifier` | no | lint/type-check/unit gate after developer |
+| `accessibility-reviewer` | no | a11y, UI-heavy feature |
+| `performance-auditor` | no | perf-audit, perf-sensitive feature |
+| `code-reviewer` | no | most pipelines, review-only |
+| `security-reviewer` | no | auth, forms, sensitive data |
+| `qa-tester` | tests only | feature, bugfix, test-only |
+| `unit-test-planner` | no | unit-only — coverage plan |
+| `unit-test-generator` | tests only | unit-only — spec generation |
+| `unit-test-healer` | tests only | failing/flaky unit tests |
+| `playwright-test-planner` | no | e2e scenario planning |
+| `playwright-test-generator` | tests only | e2e spec generation |
+| `playwright-test-healer` | tests only | failing/flaky e2e fixes |
+| `tech-writer` | docs only | docs-only, feature/migration docs |
+
+Full prompts: `.claude/agents/*.md`. Artifact conventions: `.claude/team/README.md`.
+
+## Dynamic pipeline
+
+```mermaid
+flowchart TD
+  task["/task prompt"]
+  router["task-router"]
+  pipeline["pipeline.json"]
+  step0["steps 0..N"]
+  gate{"humanGates?"}
+  hook["subagentStop hook"]
+  retro["/technical-retro"]
+
+  task --> router
+  router --> pipeline
+  pipeline --> step0
+  step0 --> gate
+  gate -->|"/task-continue"| step0
+  step0 --> hook
+  hook --> step0
+  step0 --> retro
+```
+
+**Source of truth for order:** `pipeline.json` → `steps[]`. Never hardcode analyst → dev → review → QA when `pipeline.json` exists.
+
+## status.json (pipeline mode)
+
+```json
+{
+  "slug": "...",
+  "intent": "feature",
+  "pipelineIndex": 0,
+  "currentAgent": "task-analyst",
+  "phase": "executing",
+  "state": "in_progress",
+  "awaitingHumanGate": false
+}
+```
+
+| state | Meaning |
+|-------|---------|
+| `in_progress` | Current step running |
+| `completed` | Current step done; hook or orchestrator advances |
+| `awaiting_approval` | Human gate; wait for `/task-continue` |
+| `changes_requested` | Reviewer blocked; re-run developer (`retryAfterFix`) |
+| `validation_failed` | build-verifier failed; re-run developer then build-verifier |
+
+## Pipeline step options
+
+| Field | Use |
+|-------|-----|
+| `skipIf` | `debugger.fixed` / `ci-investigator.resolved` |
+| `parallel: true` | `agent` array — invoke all in one parent turn |
+| `scope` | e.g. `unit-in-dev`, `e2e-only` |
+
+## Rules (strict)
+
+1. **`/task` always starts with task-router** (except user says "skip router" with documented pipeline).
+2. Read `pipeline.json` before every subagent invocation.
+3. One role per subagent call — **except** parallel steps.
+4. **Never** skip `humanGates` without `/task-continue` or explicit user approval.
+5. Persist handoffs including `validation-report.md` (write files; do not rely on Shell `mkdir` alone).
+6. On `changes_requested`: hook sets `retryAfterFix` → developer → same reviewer.
+7. On `validation_failed`: hook sets `retryAfterFix: build-verifier` → developer → build-verifier.
+8. When all steps complete, suggest `/technical-retro <slug>`.
+9. If `autoChain: false`, manual step only.
+
+## Team artifact I/O
+
+Create `.claude/team/tasks/<slug>/**` by writing files (Write/Edit). Avoid Shell-only `mkdir` as the bootstrap step.
+
+## Invoking agents
+
+Use the available Claude Code subagent mechanism. Pass: slug, artifact paths, step `scope` if set.
+
+After each agent completes, ensure `status.json` has `state: completed` (or `awaiting_approval` if gate applies).
+
+## Legacy mode
+
+If `pipeline.json` is missing (old `/feature-start` tasks), fall back to fixed phases: analysis → development → review → testing.
+
+## Skip pipeline when
+
+Do **not** run `/task` + router for:
+
+- Pure questions («как работает X», «объясни»).
+- Typo / one-file fix / trivial config with no architecture risk.
+- User explicitly says «без pipeline», «просто сделай», or continues an active slug.
+- Single-line `docs-only` with no code impact.
+
+Borderline work requests — см. **`tooling-and-review/agent-team-intake.md`**.
+
+## Auto-detection (optional)
+
+When user describes a **non-trivial task** (not a question), suggest `/task <message>` or run router if they agree.

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

@@ -0,0 +1,42 @@
+# Поддержка и улучшение качества кода
+
+## Поддержка существующего стиля
+
+- Новые изменения должны:
+  - следовать существующим паттернам (имена, структура, типизация);
+  - минимизировать «стилистический шум» (лишние правки форматирования, rename без нужды).
+- Перед добавлением нового решения:
+  - искать аналогичное в коде и **повторять подход**, а не изобретать новый;
+  - проверять, нет ли уже подходящего компонента или паттерна в существующем UI‑коде и пакетах проекта, прежде чем добавлять новый кастомный контрол;
+  - использовать при обращении к чужим модулям только их **public API** (index/barrel‑файлы и явно экспортируемые сущности), а deep‑импорты внутренних файлов рассматривать как повод для рефакторинга.
+
+## Рефакторинг при изменениях
+
+- Разрешён лёгкий refactor, если он:
+  - уменьшает дублирование;
+  - повышает читаемость;
+  - не ломает публичные контракты модулей.
+- Примеры допустимых улучшений:
+  - вынести дублирующуюся логику в общий хук/утилиту;
+  - типизировать `any` и `unknown`, если это безболезненно;
+  - разделить слишком крупный компонент на несколько более простых;
+  - заменить локальные «магические» CSS‑значения (цвета, отступы, размеры) на токены/примитивы дизайна проекта;
+  - заменить deep‑импорты внутренних файлов других модулей на обращения к их public API.
+
+## Ограничения
+
+- Не выполнять «большой» рефакторинг, если задача точечная и не про архитектуру:
+  - не менять структуру директорий;
+  - не менять названия публичных типов/функций без явного запроса.
+- При необходимости крупного изменения:
+  - сначала локально улучшить архитектуру минимальными шагами;
+  - оставить код в консистентном состоянии.
+
+## Линтеры
+
+Lint/stylelint — только **`tooling-and-review/post-change-lint.md`**; ESLint config: `app/eslint.config.mjs`. Отключение правила (`eslint-disable`) — только **точечно** с кратким комментарием «зачем».
+
+## Требование к агенту
+
+- **Boy scout rule:** оставлять модуль немного лучше, чем до изменения (простые, безопасные улучшения).
+- Не жертвовать архитектурой и слоями ради краткости реализации.

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

@@ -0,0 +1,30 @@
+---
+paths:
+  - .claude/commands/**/*
+  - .claude/agents/code-reviewer.md
+  - .claude/skills/code-review/**/*
+  - .claude/team/**/review.md
+---
+
+# Code review merge requests
+
+On-demand rule for review flows. **Procedure and output format:** skill `code-review`.
+
+## Checklist references
+
+- Architecture layers: `architecture/architecture-boundaries.md`, `stack/next-app-core.md`; network: `api-and-data/http-client.md`
+- Imports: `architecture/public-imports.md`, `architecture/layer-barrel-exports.md`
+- UI: `ui-and-accessibility/react-ui.md`
+- Tests: `testing/tests-unit.md`, `testing/playwright-agents.md`, `testing/tests-e2e-structure.md`
+- Lint gate before final report: `tooling-and-review/post-change-lint.md`
+
+## When to load
+
+- User asks for review/MR/diff
+- Pipeline step `code-reviewer`
+
+## Constraints
+
+- 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.

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

@@ -0,0 +1,11 @@
+# Менеджер пакетов (терминал)
+
+Перед **`npm install` / `yarn` / `pnpm` / `bun`** и **`… run …`** определи менеджер репозитория и **используй только его**.
+
+## Как определить
+
+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.
+
+Рабочий каталог для scripts — **`app/`**. Примеры: `yarn lint`, `pnpm run test`. Не угадывай — проверь файлы.

package/presets/claude/next/rules/tooling-and-review/post-change-lint.md

@@ -0,0 +1,44 @@
+---
+description: Прогон ESLint и Stylelint после изменений кода. Requestable — подгружать после правок app/**; агенты обязаны запускать после code edits.
+paths:
+  - .claude/commands/**/*
+  - .claude/team/**/*
+  - .claude/agents/**/*
+  - app/**/*.{ts,tsx,js,jsx,mjs,css}
+---
+
+# Линтеры после изменений кода
+
+**Requestable, но обязателен при изменениях кода:** правило не session-start (экономия контекста); после правок исходников агент **должен** следовать этому чеклисту.
+
+## Когда применять
+
+После **любого** изменения исходников в `app/**` (TS/TSX/JS/MJS, CSS, styled/Linaria в `.ts`/`.tsx`).
+
+Исключения: правки документации вне `app/`, конфигов CI, `.claude/rules/**`, если исполняемый код приложения не менялся.
+
+**Pipeline exception:** если задача идёт через agent team и следующий шаг — `build-verifier`, developer может ограничиться lint/type-check **изменённых файлов**; полный прогон — обязанность `build-verifier`. В single-agent режиме (без pipeline) — всегда полный прогон.
+
+## Обязательные команды
+
+Рабочий каталог — **`app/`**. Менеджер пакетов — **`tooling-and-review/package-manager.md`**.
+
+1. **`lint:js`** — полный ESLint по проекту.
+2. **`lint:css`** — полный Stylelint (`**/*.{css,ts}`).
+
+Точечный lint на один файл **не заменяет** полный прогон перед завершением задачи (кроме pipeline exception выше).
+
+## Алгоритм
+
+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`).
+
+## Что исправлять
+
+- **Errors** — обязательно.
+- **Warnings** — обязательно в файлах задачи; вне скоупа — упомянуть, если мешают нулевому exit code.
+
+Конфиги: `app/eslint.config.mjs`, `app/.stylelintrc` (порядок CSS — `ui-and-accessibility/css-property-order.md`).

package/presets/claude/next/rules/ui-and-accessibility/README.md

@@ -1,3 +1,12 @@
 # UI and accessibility
 
-Компоненты, стили, доступность, паттерны React UI.
+Компоненты, стили, пропсы.
+
+| Файл | Содержание | Загрузка |
+|------|------------|----------|
+| `no-props-spread.md` | Явные пропсы, без `{...props}` | `paths: app/src/**/*.tsx` |
+| `css-property-order.md` | Порядок CSS (Stylelint idiomatic-order) | `paths:` styles/css |
+| `react-ui.md` | Структура, стили (`Root`), `.data.ts`, хуки | `paths: app/src/ui/**` |
+| `react-a11y-coding.md` | A11y при написании UI | `paths: app/src/ui/**` |
+
+Deprecated stub `component-styles.md` **removed** — styles colocation lives in `react-ui.md`.

package/presets/claude/next/rules/ui-and-accessibility/css-property-order.md

@@ -0,0 +1,14 @@
+---
+paths:
+  - app/src/ui/**/*.styles.ts
+  - app/src/ui/**/*.styles.tsx
+  - app/src/ui/**/styles.ts
+  - app/src/ui/**/styles.tsx
+  - app/**/*.css
+---
+
+# Порядок CSS-свойств (как в Stylelint)
+
+Порядок свойств — как в **`app/.stylelintrc`** (`stylelint-config-idiomatic-order`). Не дублировать список вручную.
+
+Автоисправление из `app/`: **`lint:css --fix`**. Полный прогон — **`tooling-and-review/post-change-lint.md`**.