@bonesofspring/ai-rules 0.1.36 → 0.1.39

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

@@ -0,0 +1,69 @@
+# 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, качество кода, code review MR.
+
+| Файл | Содержание |
+|------|------------|
+| `package-manager.md` | yarn / pnpm / npm / bun — определить по lockfile |
+| `post-change-lint.md` | Обязательный `lint:js` + `lint:css` после изменений |
+| `code-quality.md` | Boy scout rule, рефакторинг, ESLint |
+| `code-review-mr.md` | Чеклист ревью merge request |
+
+Все — **session start**.
+
+On-demand: **`commands/technical-retro.md`** (фасилитация ретро, не грузится как rule).

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

@@ -0,0 +1,9 @@
+# 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,97 @@
+# Agent team orchestrator
+
+Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.claude/team/tasks/<slug>/`.
+
+## 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 |
+| `solution-architect` | no | spike, complex cross-layer feature |
+| `debugger` | yes, minimal fixes only | bugfix |
+| `feature-developer` | yes | feature, bugfix, refactor |
+| `code-reviewer` | no | most pipelines, review-only |
+| `qa-tester` | tests only | feature, bugfix, test-only |
+
+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 |
+
+## 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.
+4. **Never** skip `humanGates` without `/task-continue` or explicit user approval.
+5. Persist handoffs to disk (`brief.md`, `decomposition.md`, `debug-report.md`, `architecture.md`, `review.md`).
+6. On `changes_requested`: re-invoke `feature-developer`, then `code-reviewer` — do not advance `pipelineIndex` until review passes.
+7. When all steps complete, suggest `/technical-retro <slug>`.
+8. If `autoChain: false` in pipeline, do not rely on hook — manual step only.
+
+## 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.
+
+## Auto-detection (optional)
+
+When user describes a **task** (not a question "how does X work"), suggest `/task <their message>` or run router proactively if they agree.

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

@@ -0,0 +1,50 @@
+# Поддержка и улучшение качества кода
+
+## Поддержка существующего стиля
+
+- Новые изменения должны:
+  - следовать существующим паттернам (имена, структура, типизация);
+  - минимизировать «стилистический шум» (лишние правки форматирования, rename без нужды).
+- Перед добавлением нового решения:
+  - искать аналогичное в коде и **повторять подход**, а не изобретать новый;
+  - проверять, нет ли уже подходящего компонента или паттерна в существующем UI‑коде и пакетах проекта, прежде чем добавлять новый кастомный контрол;
+  - использовать при обращении к чужим модулям только их **public API** (index/barrel‑файлы и явно экспортируемые сущности), а deep‑импорты внутренних файлов рассматривать как повод для рефакторинга.
+
+## Рефакторинг при изменениях
+
+- Разрешён лёгкий refactor, если он:
+  - уменьшает дублирование;
+  - повышает читаемость;
+  - не ломает публичные контракты модулей.
+- Примеры допустимых улучшений:
+  - вынести дублирующуюся логику в общий хук/утилиту;
+  - типизировать `any` и `unknown`, если это безболезненно;
+  - разделить слишком крупный компонент на несколько более простых;
+  - заменить локальные «магические» CSS‑значения (цвета, отступы, размеры) на токены/примитивы дизайна проекта;
+  - заменить deep‑импорты внутренних файлов других модулей на обращения к их public API.
+
+## Ограничения
+
+- Не выполнять «большой» рефакторинг, если задача точечная и не про архитектуру:
+  - не менять структуру директорий;
+  - не менять названия публичных типов/функций без явного запроса.
+- При необходимости крупного изменения:
+  - сначала локально улучшить архитектуру минимальными шагами;
+  - оставить код в консистентном состоянии.
+
+## ESLint, Stylelint и плагины
+
+- Учитывать **все активные правила ESLint** и **подключённые плагины** проекта (конфиг: `app/eslint.config.mjs`, базовые пресеты в т.ч. `@sh/eslint-config-react`, `@sh/eslint-config-boundaries` и локальные overrides).
+- Учитывать **Stylelint** для CSS и CSS-in-JS (конфиг: `app/.stylelintrc`; порядок свойств — `ui-and-accessibility/css-property-order.md`).
+- Новый или изменённый код не должен нарушать эти правила.
+- После **каждого** изменения кода агент **обязан** выполнить **`tooling-and-review/post-change-lint.md`**: полный прогон **`lint:js`** и **`lint:css`**, анализ вывода, исправление срабатываний в зоне задачи.
+- Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) и с **кратким комментарием**, зачем это нужно; отключать «на весь файл» без веской причины не следует.
+
+## Требование к агенту
+
+При каждом изменении:
+
+- Поддерживать принцип **«boy scout rule»**:
+  - оставлять модуль в немного лучшем состоянии, чем до изменения (простые, безопасные улучшения).
+- Не жертвовать архитектурой и слоями ради краткости реализации.
+- **Не завершать задачу**, пока не пройдены обязательные линтеры (`tooling-and-review/post-change-lint.md`).

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

@@ -0,0 +1,67 @@
+# Code review merge requests
+
+## Когда применять
+
+- Пользователь просит: «проведи ревью», «оценить MR/ветку/дифф», «посмотри изменения».
+- Опираться на локальный репозиторий: текущую ветку, `git diff` и открытые файлы, а не на данные внешнего API хостинга.
+
+## Что обязан проверить агент
+
+### Архитектура и слои
+
+Соблюдение `architecture/architecture-boundaries.md`, `stack/next-app-core.md` и при сетевых изменениях — `api-and-data/http-client.md`:
+
+- UI (`app/src/ui/**`) не ходит напрямую в HTTP‑клиент и не знает DTO.
+- Store (`app/src/store/**`) не зависит от UI; границы транспортных типов и ошибок — `api-and-data/store-rtk.md` / `api-and-data/http-client.md`.
+- API (`app/src/api/**`) не тянет UI/store, использует мапперы; без прямого `fetch` в сервисах (кроме оговорённых исключений).
+
+### Импорты и организация кода
+
+- Использование алиаса `@/...` вместо относительных импортов выше по дереву.
+- Отсутствие deep‑импортов во внешние фичи; только public API; в файлах вне `app/src/api/**` импорты из API — только `from '@/api'` (`architecture/api-public-imports.md`, дублирует ESLint).
+- При новых/изменённых модулях в регламентированных слоях — реэкспорт публичных символов в корневой barrel по **`architecture/layer-barrel-exports.md`**.
+- Размещение новых файлов в корректных слоях и директориях фич.
+
+### Типы и TS‑строгость
+
+- Не допускать новых `any`; предпочитать доменные типы из `@/types` (barrel, см. `architecture/types-public-imports.md`).
+- Проверять корректность пропсов/возвращаемых типов, особенно в UI и API‑слое.
+
+### UI и стили
+
+Для компонентов и стилей сверяться с `ui-and-accessibility/react-ui.md` и `stack/next-app-core.md`:
+
+- Соблюдать принятый способ стилей и общие UI‑примитивы/токены, а не «магические» значения.
+- Сохранять консистентность с существующими компонентами и паттернами.
+
+### Тесты
+
+- Для нетривиальных изменений:
+  - либо обновлены/добавлены unit‑тесты (`testing/tests-unit.md`),
+  - либо e2e‑сценарии/спеки отражают новую логику (`testing/playwright-agents.md`, `testing/tests-e2e-structure.md`).
+- При правках **общего HTTP‑клиента** — наличие/актуальность **behavior‑тестов клиента** (`api-and-data/http-client.md`, `testing/tests-unit.md`).
+- **Указывать, какие именно тесты** стоит добавить или поправить.
+
+### Линтеры (обязательно)
+
+**`tooling-and-review/post-change-lint.md`**:
+
+- Перед финализацией отчёта по ревью и после любых правок по итогам ревью: полный прогон **`lint:js`** и **`lint:css`** из `app/`.
+- В отчёт включить **все сообщения ESLint и Stylelint (errors и warnings)** по файлам из диффа MR/ветки; запуск — по всему проекту, **фильтрация вывода — к путям из `git diff`**.
+- Не считать ревью/правки завершёнными, пока линтеры не проходят или не зафиксирован блокер в ответе.
+- Полная валидация как в CI: **`lint`** (= `lint:js` + `lint:css` + `type-check`) — уместна перед итогом крупного MR.
+
+## Глубина и формат ревью
+
+- Фокус на **изменениях MR** (дифф относительно целевой ветки), а не на всём проекте.
+- Сначала **высокоуровневый обзор** (что делает MR, риски, архитектурные замечания), затем список конкретных комментариев.
+- Каждый комментарий:
+  - **конкретный** (файл/участок и проблема),
+  - **практичный** (вариант исправления по существующим паттернам),
+  - без «больших рефакторингов» в духе `tooling-and-review/code-quality.md`, если задача локальная.
+
+## Ограничения для агента
+
+- Не придумывать несуществующие метаданные из хостинга (лейблы MR, авторов, статусы CI), если их нет в локальных данных.
+- Не менять общую архитектуру фичи без прямого запроса пользователя.
+- Следовать принципу «boy scout rule»: предлагать улучшения, которые реально можно внести в рамках MR.

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

@@ -0,0 +1,20 @@
+# Менеджер пакетов (терминал)
+
+Перед **`npm install` / `yarn` / `pnpm` / `bun`** и любыми **`… run …`** (lint, test, dev, build) **сначала определи**, какой менеджер закреплён в этом репозитории, и **используй только его**.
+
+## Как определить (по убыванию надёжности)
+
+1. Поле **`packageManager`** в `package.json` (корень монорепо или `app/package.json`) — `yarn@…`, `pnpm@…`, `npm@…`, `bun@…`.
+2. **Lockfile** рядом с тем `package.json`:
+   - `yarn.lock` → **yarn**
+   - `pnpm-lock.yaml` → **pnpm**
+   - `package-lock.json` → **npm**
+   - `bun.lock` / `bun.lockb` → **bun**
+3. Если неоднозначно — где лежат **`node_modules`** и какой lockfile обновляют в CI.
+
+## Как запускать
+
+- Рабочий каталог — там, где **`package.json`** с нужными **scripts** (в этом репозитории — **`app/`**).
+- Примеры: `yarn lint`, `pnpm run test` — **в соответствии с обнаруженным менеджером**.
+
+Если менеджер неочевиден — **посмотри файлы** инструментами чтения, **не угадывай**.

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

@@ -0,0 +1,43 @@
+# Линтеры после изменений кода
+
+## Когда применять
+
+После **любого** изменения исходников в репозитории: правка, создание или удаление файлов в `app/**` (TS/TSX/JS/MJS, CSS, styled/Linaria в `.ts`/`.tsx`, markdown с ESLint и т.д.).
+
+Исключения без прогона линтеров: только правки **документации вне `app/`**, конфигов CI, `.claude/rules/**`, если **не** менялся исполняемый код приложения.
+
+## Обязательные команды
+
+Рабочий каталог — **`app/`** (там `package.json` со скриптами). Менеджер пакетов — **`tooling-and-review/package-manager.md`**.
+
+1. **`lint:js`** — полный ESLint по проекту (`eslint .` с расширениями из скрипта).
+2. **`lint:css`** — полный Stylelint (`**/*.{css,ts}`).
+
+**Всегда запускать обе команды**, даже если задача не касалась стилей: Stylelint проверяет и CSS-in-JS в `.ts`.
+
+Точечный ESLint/Stylelint только на один файл **не заменяет** полный прогон перед завершением задачи.
+
+## Алгоритм для агента
+
+1. Завершить правки кода.
+2. Запустить **`lint:js`** и **`lint:css`** из `app/` (через терминал, не «на глаз»).
+3. **Проанализировать весь вывод**: errors и warnings.
+4. **Исправить** все срабатывания в **изменённых файлах** и связанных с задачей; для Stylelint сначала пробовать **`lint:css --fix`**, если правило автоисправимо.
+5. При ненулевом exit code — повторить шаги 2–4 до успешного прогона или явного блокера.
+6. **Не считать задачу выполненной**, пока оба линтера не завершились с кодом 0 **или** в ответе пользователю не зафиксирован блокер (например, легаси вне скоупа) с перечислением оставшихся замечаний.
+
+## Что исправлять
+
+- **Errors** — обязательно.
+- **Warnings** — обязательно в файлах из текущей задачи; вне скоупа — не чинить «заодно», но **упомянуть** в ответе, если мешают нулевому exit code.
+- **`eslint-disable`** — только точечно, с кратким комментарием «зачем» (`tooling-and-review/code-quality.md`).
+
+## Связанные проверки
+
+- **`type-check`** — обязателен при изменениях TypeScript (`stack/next-app-core.md`); не подменяет ESLint/Stylelint.
+- Полная валидация как в CI: **`lint`** (= `lint:js` + `lint:css` + `type-check`) — уместна перед крупным MR.
+
+## Конфиги
+
+- ESLint: `app/eslint.config.mjs`
+- Stylelint: `app/.stylelintrc` (порядок свойств — `ui-and-accessibility/css-property-order.md`)

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

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

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

@@ -0,0 +1,50 @@
+# Стили только рядом с компонентом
+
+## Имя корневого styled-элемента: `Root`
+
+- **Корневой** styled-элемент — **`Root`**.
+- В разметке: `<s.Root>...</s.Root>` при `import * as s from './styles'`.
+- Вложенные — `Title`, `List`, `Item` и т.д.
+- Единственная внешняя styled-обёртка всего JSX — **`Root`**, не `Container` / `Wrapper`.
+
+```tsx
+// ✅ Хорошо
+export const Root = styled.div` ... `
+// в компоненте: <s.Root>...</s.Root>
+
+// ❌ Плохо для единственной обёртки
+export const Service = styled.div` ... `
+```
+
+## Правило
+
+**Запрещено** импортировать модули стилей **другого** UI-компонента или блока.
+
+Под «модулями стилей»:
+
+- `styles.ts` / `styles.tsx` рядом с компонентом;
+- `*.module.css`, `*.module.scss`;
+- файлы, экспортирующие styled-примитивы одного компонента.
+
+## Разрешено
+
+- `import * as s from './styles'` — в той же папке.
+- Общие примитивы дизайн-системы, токены, `@/ui/components/...`.
+- Повторное использование визуала через **сам компонент**, не через его `styles`.
+
+## Примеры
+
+```tsx
+// ✅ Хорошо
+import * as s from './styles'
+
+// ❌ Плохо
+import * as s from '../../styles'
+import * as s from '../RequestForAnalysisServices/styles'
+```
+
+## Почему
+
+- **`Root`** — быстрая ориентация в разметке.
+- Стили и компонент меняются вместе.
+- Проще рефакторинг.

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

@@ -0,0 +1,20 @@
+# Порядок CSS-свойств (как в Stylelint)
+
+Действует для **любого** CSS в репозитории: `.css`, стилевые блоки в `styles.ts` / `styles.tsx`, `styled` / Linaria и другой CSS-in-JS в `.ts` / `.tsx`, если этот код попадает под `lint:css`.
+
+Источник: `app/.stylelintrc` → `@sh/stylelint-config-react` → пакет **`stylelint-config-idiomatic-order`** (правило `order/properties-order`). Свойства, не попавшие в список, идут **в конце блока в алфавитном порядке** (`unspecified: bottomAlphabetical`).
+
+Пиши объявления в **одном** блоке в такой последовательности групп:
+
+1. **`composes`** — только для CSS Modules (если есть).
+2. **`all`**
+3. **Позиционирование:** `position`, `z-index`, затем `top`, `right`, `bottom`, `left`.
+4. **Отображение и раскладка:** `display`, `overflow`.
+5. **Размеры:** `width`, `min-width`, `max-width`, `height`, `min-height`, `max-height`, `box-sizing`.
+6. **Flex:** `flex`, `flex-basis`, `flex-direction`, `flex-flow`, `flex-grow`, `flex-shrink`, `flex-wrap`, `align-content`, `align-items`, `align-self`, `justify-content`, `order`.
+7. **Внутренние отступы:** `padding-top`, `padding-right`, `padding-bottom`, `padding-left`.
+8. **Рамка:** общие `border`, `border-width`, `border-style`, `border-color`, `border-radius`; затем для сторон **сверху по часовой** — `border-top` и его `-width`, `-style`, `-color`, `-radius`, то же для `right`, `bottom`, `left`.
+9. **Внешние отступы:** `margin-top`, `margin-right`, `margin-bottom`, `margin-left`.
+10. **Остальные свойства** — после перечисленных, **по алфавиту** (типографика, фон, анимации, `cursor`, и т.д.).
+
+Автоисправление из каталога `app`: `lint:css --fix` (проверяет `**/*.{css,ts}`; менеджер пакетов — `tooling-and-review/package-manager.md`).

package/presets/claude/next/rules/ui-and-accessibility/no-props-spread.md

@@ -0,0 +1,52 @@
+# Не использовать спред пропов при передаче в компоненты
+
+При вызове **пользовательских** React-компонентов (имя с заглавной буквы) **передавать пропы явно**, а не через spread (`{...props}`, `{...obj}`).
+
+**Агентам и при ревью:** не «упрощать» JSX через объект с spread. Длинное ветвление — два явных JSX-блока или отдельные компоненты.
+
+## Почему
+
+- Явная передача делает зависимости очевидными.
+- Упрощает рефакторинг и поиск использований.
+- Снижает риск лишних пропов.
+
+## Проверка в репозитории
+
+- Для `app/src/ui/**/*.tsx` — ESLint `react/jsx-props-no-spreading` (`app/eslint.config.mjs`).
+- Исключение — `eslint-disable-next-line` с комментарием «почему».
+
+## Примеры
+
+```tsx
+// ❌ Плохо
+const commonProps = { a, b, c }
+return <Child {...commonProps} />
+
+// ❌ Плохо
+return <Child {...props} />
+
+// ✅ Хорошо
+return (
+  <Child
+    a={a}
+    b={b}
+    c={c}
+  />
+)
+
+// ✅ Хорошо — явные пропсы по веткам
+return cond ? (
+  <IconBox name={name} size="m" variant="warning" />
+) : (
+  <IconBox
+    customColors={styles.IconBoxAccent.customColors}
+    name={name}
+    size="m"
+  />
+)
+```
+
+## Исключения
+
+- **Нативный** DOM (`<div {...rest} />`) — если `rest` только HTML-атрибуты.
+- Обёртки — если явно документировано; при необходимости ESLint-disable.