@bonesofspring/ai-rules 0.2.0 → 0.2.2

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

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

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

@@ -1,66 +0,0 @@
----
-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/agent-team-intake.md

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

@@ -1,134 +0,0 @@
-# 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`.
-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.
-
-## 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

@@ -1,42 +0,0 @@
-# Поддержка и улучшение качества кода
-
-## Поддержка существующего стиля
-
-- Новые изменения должны:
-  - следовать существующим паттернам (имена, структура, типизация);
-  - минимизировать «стилистический шум» (лишние правки форматирования, 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

@@ -1,67 +0,0 @@
-# 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/public-imports.md`, дублирует ESLint).
-- При новых/изменённых модулях в регламентированных слоях — реэкспорт публичных символов в корневой barrel по **`architecture/layer-barrel-exports.md`**.
-- Размещение новых файлов в корректных слоях и директориях фич.
-
-### Типы и TS‑строгость
-
-- Не допускать новых `any`; предпочитать доменные типы из `@/types` (barrel, см. `architecture/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

@@ -1,11 +0,0 @@
-# Менеджер пакетов (терминал)
-
-Перед **`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

@@ -1,33 +0,0 @@
-# Линтеры после изменений кода
-
-## Когда применять
-
-После **любого** изменения исходников в `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/component-styles.md

@@ -1,56 +0,0 @@
----
-paths:
-  - app/src/ui/**/*.ts
-  - app/src/ui/**/*.tsx
----
-
-# Стили только рядом с компонентом
-
-## Имя корневого 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

@@ -1,14 +0,0 @@
----
-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`**.

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

@@ -1,57 +0,0 @@
----
-paths:
-  - app/src/**/*.tsx
----
-
-# Не использовать спред пропов при передаче в компоненты
-
-При вызове **пользовательских** 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.