@bonesofspring/ai-rules 0.2.13 → 0.2.14

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

@@ -0,0 +1,78 @@
+---
+description: Playwright Agents (planner/generator/healer) configuration for e2e structure in tests/e2e
+paths: tests/e2e/**/*
+---
+# Playwright Agents in this project
+
+In this repository, Playwright Agents (planner, generator, healer) **must follow the existing e2e structure**:
+
+- **Test directory**: `tests/e2e`
+- **Test plans (specs)**: `*.cases.md` files under `tests/e2e/**`
+- **Executable tests**: `*.spec.ts` files under `tests/e2e/**`
+- **Seed test**: `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 `tests/e2e`, e.g.:
+    - `tests/e2e/OrderHistory/order-history.cases.md`
+    - `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 `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 `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 `tests/e2e/**` as the test plan.
+- **Target for tests**:
+  - Generate or update `*.spec.ts` files under the same folder, e.g.:
+    - plan: `tests/e2e/OrderHistory/order-history.cases.md`
+    - tests: `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:
+    - `tests/e2e/OrderHistory/OrderHistoryPage.ts`
+    - shared helpers under `tests/e2e/_shared/`.
+- **Seed**:
+  - If a seed test is needed, use `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 `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 `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 `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.
+
+
+## Stack notes (Nuxt)
+
+- E2E root: `tests/e2e/`.
+- Default baseURL: `http://localhost:3000`.
+- Prefer Playwright `webServer` → `nuxt dev` or `nuxt build && nuxt preview`.

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

@@ -0,0 +1,49 @@
+---
+description: Структура e2e тестов и планов (Playwright)
+paths: tests/e2e/**/*
+---
+# Структура e2e в проекте
+
+- Папка e2e: `tests/e2e/**`.
+- Планы сценариев:
+  - `*.cases.md` файлы — **канонический источник сценариев**.
+- Тесты:
+  - `*.spec.ts` файлы — реализация сценариев на Playwright.
+- Общие утилиты и абстракции:
+  - `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 и хелперы, а не копировать селекторы напрямую в каждый тест.
+

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

@@ -0,0 +1,75 @@
+---
+description: Unit и интеграционные тесты (Testing Library и runner проекта)
+paths:
+  - "**/*.spec.{ts,tsx}"
+  - "**/*.test.{ts,tsx}"
+---
+# Общие правила тестирования
+
+- **Имена файлов:** для **новых** тестов использовать суффикс **`*.spec.ts` / `*.spec.ts`**. Существующие **`*.test.ts` / `*.test.tsx`** не переименовывать без отдельной задачи (легаси).
+- **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@vue/test-utils**.
+- Основная цель тестов:
+  - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
+- **Именование unit‑тестов** (строки в `describe` / `it` / `test`):
+  - формулировки **только на русском языке** — понятные бизнес‑фразы (что проверяется и какой ожидается результат);
+  - **каждое предложение** в названии **начинается с заглавной буквы** (в том числе после `.`, `!`, `?` и при нескольких предложениях в одной строке); первая буква всей строки — тоже заглавная.
+  - **Проверка в CI:** ESLint (`jest/valid-title` в `eslint.config.mjs`) требует, чтобы строка начиналась с русской заглавной (А–Я, Ё), и запрещает пробел после точки, за которым сразу идёт строчная буква (типичный случай нарушения «с заглавной после точки»).
+
+```typescript
+// ✅ Хорошо
+it('Возвращает пустой список. Пользователь не авторизован', () => {})
+it('При ошибке сети показывается сообщение об ошибке', () => {})
+
+// ❌ Плохо (не с заглавной после точки; или не русский)
+it('Возвращает пустой список. пользователь не авторизован', () => {})
+it('Returns empty list when user is guest', () => {})
+```
+
+# Тесты компонентов
+
+- Использовать `render` из `@vue/test-utils`.
+- Ассерты:
+  - матчеры DOM для Testing Library, как подключены в проекте (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
+- Взаимодействия:
+  - `userEvent` из `@testing-library/user-event`.
+
+# Изоляция и моки
+
+- Для работы с API/store:
+  - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
+- Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
+
+# HTTP‑клиент
+
+- При изменении **реализации общего HTTP‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
+- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
+
+# Мапперы и преобразование данных
+
+- Функции маппинга данных (DTO -> доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
+- В тестах мапперов особое внимание уделять edge‑кейсам и регрессии бизнес‑правил (например, граничные значения, отсутствие полей, неожиданные комбинации значений).
+
+# Требование к агенту
+
+При добавлении тестов:
+- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
+- Добавлять тесты для критичных веток логики и edge‑кейсов.
+ - При работе с данными:
+   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
+   - по возможности опираться на данные и обработчики из `mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
+ - Размещение:
+   - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.ts`.
+   - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
+   - **новые** файлы — `*.spec.ts` / `*.spec.ts` (см. блок «Имена файлов» выше).
+## Incorrect
+
+```ts
+it('returns empty list when guest', () => {})
+it('Возвращает пустой список. пользователь не авторизован', () => {})
+```
+
+## Correct
+
+```ts
+it('Возвращает пустой список. Пользователь не авторизован', () => {})
+```

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

@@ -0,0 +1,15 @@
+# Tooling and review
+
+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 + output contract | `paths:` review-related |
+| `security-nuxt.md` | Secrets, auth, XSS, Server Actions (coding-time) | `paths:` app/auth/env |
+
+On-demand (не rule): **`commands/technical-retro.md`** (фасилитация ретро).

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

@@ -0,0 +1,15 @@
+---
+description: Use when user posts a work request without /task — suggest or use /task to run the agent team router. Lightweight intake hint only.
+paths: .claude/team/**
+---
+<!-- shared-core: agent-team/agent-team-intake.md -->
+
+# 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», «объясни») — 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.

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

@@ -0,0 +1,191 @@
+---
+description: Orchestrates the agent team via task-router and pipeline.json. Use for /task, /task-continue, /feature-start, task decomposition, or when the user describes a feature, bug, or review request.
+paths: .claude/team/**
+---
+<!-- shared-core: agent-team/agent-team-orchestrator.md -->
+
+# Agent team orchestrator
+
+Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.cursor/team/tasks/<slug>/`.
+
+Work request без `/task` — см. **`agent-team-intake.mdc`** (когда предлагать router вместо прямого кодинга).
+
+## 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 |
+
+## Stack notes
+
+### Roles
+
+| Agent | App / prod writes | Typical intent |
+|-------|-------------------|----------------|
+| `task-router` | no (team only) | Every `/task` — writes `pipeline.json` |
+| `task-analyst` | no (team only) | feature, refactor, test-only, a11y, docs-only, migration |
+| `solution-architect` | no (team only) | spike, complex cross-layer feature |
+| `migration-specialist` | no (team only) | migration — phased upgrade plan |
+| `api-contract-reviewer` | no (team only) | new/changed backend API contracts |
+| `debugger` | minimal fix | bugfix |
+| `ci-investigator` | minimal CI fix | ci-fix — minimal CI repair |
+| `feature-developer` | yes | feature, bugfix, refactor, migration, a11y |
+| `build-verifier` | no (team only) | lint/typecheck/unit gate after developer; preset-structure when editing presets |
+| `accessibility-reviewer` | no (team only) | a11y, UI-heavy feature |
+| `performance-auditor` | no (team only) | perf-audit, perf-sensitive feature |
+| `code-reviewer` | no (team only) | most pipelines, review-only |
+| `security-reviewer` | no (team only) | auth, forms, sensitive data |
+| `qa-tester` | tests only | feature, bugfix, test-only |
+| `unit-test-planner` | no (team only) | 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` | e2e plans | e2e scenario planning |
+| `playwright-test-generator` | e2e tests | e2e spec generation |
+| `playwright-test-healer` | e2e fixes | failing/flaky e2e fixes |
+| `tech-writer` | docs / team | docs-only, feature/migration docs |
+
+**Cursor frontmatter:** all team pipeline agents use `readonly: false` so they can write `.cursor/team/**`. Production/app restrictions live in the agent prompt body — do **not** set `readonly: true` (Cursor blocks *all* file writes, including team artifacts).
+
+Full prompts: `.cursor/agents/*.md`. Artifact conventions: `.cursor/team/README.md`; schema SoT: **agent-artifact-contracts**.
+
+When editing `packages/ai-rules/presets/**`, follow **`preset-pr-checklist.mdc`** (+ twin-sync / layering / token-budget / leakage meta-rules).
+
+## 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.
+
+New pipelines retain top-level `profile` and include `routingDecision` with `complexity`, `riskFlags`, non-empty `routingReasons`, `estimatedWorkPackages`, and `openDecisionCount`. The stack `task-router` owns heuristics; this metadata is auditable evidence and does not change hook semantics.
+
+## Metrics lifecycle
+
+Use the local `metrics.json` ledger described by **agent-task-metrics**: the orchestration runtime initializes attempts before invocation, hooks record host-clock ends, and agents never guess a parallel completion from `currentAgent`.
+
+## Artifact context index and receipts
+
+Each slug has one `artifact-manifest.json`: `.cursor/team/tasks/<slug>/` or `.claude/team/tasks/<slug>/`. Schema SoT: **agent-artifact-contracts**.
+
+- Read the manifest before broad prior-artifact discovery. Each step receives authoritative input entry IDs, owns named output entry IDs, and finishes with one terminal receipt linked to AC/task IDs.
+- Markdown remains detailed evidence; the manifest records producer, status, authoritative paths, timestamps, outcome, and evidence paths.
+- Agents upsert only entries they own and preserve foreign entries. Parallel agents use distinct IDs; the parent/orchestrator serializes manifest merges.
+- The orchestration runtime/hook is the single writer for `status.json` lifecycle fields and `metrics.json`. Agents read status for eligibility but never rewrite state, gate, retry, attempt, timestamp, or metrics fields.
+- Missing/stale manifests are reported as a handoff gap; fall back to `brief.md`, `decomposition.md`, and `pipeline.json` rather than inventing authority.
+
+## status.json (pipeline mode)
+
+```json
+{
+  "slug": "...",
+  "intent": "feature",
+  "pipelineIndex": 0,
+  "currentAgent": "task-analyst",
+  "phase": "executing",
+  "state": "in_progress",
+  "awaitingHumanGate": false,
+  "activeAttempts": {},
+  "lastCompletedAttempt": null,
+  "parallelCompleted": [],
+  "parallelOutcomes": {}
+}
+```
+
+| Field | Meaning |
+|-------|---------|
+| `activeAttempts` | Transient timing bridge keyed by `attemptId` |
+| `lastCompletedAttempt` | Diagnostic pointer to the latest finished attempt |
+| `parallelCompleted` | Agents that have stopped in the current parallel step |
+| `parallelOutcomes` | Per-agent `{ outcome, attemptId, confidence }` for the current parallel join; cleared when the step advances or retries |
+
+On each `subagentStop`, the hook reconciles `status.state` from the completing producer's terminal `artifact-manifest.json` receipt when agents left lifecycle fields untouched. Wait for that handoff before invoking the next step.
+
+| state | Meaning |
+|-------|---------|
+| `in_progress` | Current step running |
+| `completed` | Current step done; hook 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` — hook skips step when artifact says fix applied |
+| `parallel: true` | `agent` is array — invoke **all** agents in one parent turn; each appends to `parallelCompleted` |
+| `scope` | e.g. `unit-in-dev`, `e2e-only` — passed to developer/qa |
+| `model` | `cheap` \| `standard` \| `strong` — optional tier override (see below) |
+
+## 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 Task call — **except** parallel steps: multiple Task calls in one message.
+4. **Never** skip `humanGates` without `/task-continue` or explicit user approval.
+5. Persist handoffs to disk and update the producer-owned terminal receipt in `artifact-manifest.json`; Markdown remains detailed evidence.
+6. On `changes_requested` from reviewers: hook sets `retryAfterFix` → developer → same reviewer.
+7. On `validation_failed` from `build-verifier`: hook sets `retryAfterFix: build-verifier` → developer → build-verifier.
+8. When all steps complete, suggest `/technical-retro <slug>`.
+9. If `autoChain: false` in pipeline, do not rely on hook — manual step only.
+
+## Team artifact I/O (Cursor Shell sandbox)
+
+- Create/update `.cursor/team/tasks/<slug>/**` with the **Write** tool (parents are created automatically). Do **not** bootstrap slug dirs with Shell `mkdir -p` — default sandbox returns `Operation not permitted` (worse on macOS Desktop/Documents with TCC `com.apple.macl`).
+- If Shell must touch team paths and fails with EPERM, retry with `required_permissions: ["all"]`. Prefer Write for artifacts.
+- Prefer repo under `~/Projects` / `WebstormProjects` over `~/Desktop` when using agent team heavily.
+
+## Invoking agents
+
+Use Task tool or `/agent-name`. Pass: slug, artifact paths, step `scope` if set.
+
+### Model when invoking (Task)
+
+1. Read `steps[i].model` if present; else use the agent’s frontmatter `model` (see `agents/README.md` matrix).
+2. Map abstract tiers:
+   - **`cheap`** → pass Task `model: "fast"` when the tool accepts it (or rely on agent `fast`).
+   - **`standard`** → omit Task `model` (frontmatter `inherit` / mid default).
+   - **`strong`** → **never** pass `fast`; rely on agent pin (`claude-opus-4-8[effort=high]`) or parent Max model. If Task allows an explicit model ID from the allowed list, prefer the strong agent’s frontmatter ID.
+3. Parallel steps: apply the step-level `model` to **each** agent in the array (or omit → each agent’s own frontmatter).
+
+After each agent completes, verify its terminal manifest receipt, then let the orchestration runtime/hook reconcile `status.json` (`completed`, a blocking outcome, or `awaiting_approval`) from that receipt. Do not ask the agent to mutate shared lifecycle fields, and do not invoke the next specialist until the hook has written the handoff / updated `status.json`.
+
+## Legacy mode
+
+If `pipeline.json` is missing (old `/feature-start` tasks), fall back to fixed phases: analysis → development → review → testing. Hook supports both.
+
+## Skip pipeline when
+
+Do **not** run `/task` + router for:
+
+- Pure questions («как работает X», «объясни») — prefer agent **`codebase-analyzer`** for deep traces; inline OK for trivial one-liners.
+- 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 — см. **`agent-team-intake.mdc`**.
+
+## 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/nuxt/rules/tooling-and-review/anti-sycophancy-discipline.md

@@ -0,0 +1,33 @@
+---
+description: Anti-sycophancy discipline for code generation and review — VERIFY, failure modes, UNTESTED, honest status. Load when writing or changing code.
+paths:
+  - pages/**/*
+  - components/**/*
+  - stores/**/*
+  - api/**/*
+  - composables/**/*
+  - types/**/*
+---
+<!-- shared-core: quality/anti-sycophancy-discipline.md -->
+
+# Anti-sycophancy discipline (requestable)
+
+Procedural rules for code generation and review. Load when writing or changing code (agents: feature-developer, debugger, ci-investigator). Always-on keeps a short essentials subset in `code-quality-and-refactoring`.
+
+1. **Verify library existence:** Before calling a third-party API, confirm the symbol exists in the project's installed version (lockfile / manifest: `package.json`, `go.mod`, `Podfile.lock`, `pom.xml`, `Cargo.toml`, or equivalent). If you cannot verify, mark `// VERIFY: lib.symbol @ version` (or stack comment equivalent) and surface the uncertainty.
+2. **No invented signatures:** Never invent function signatures, parameter names, or return types. If the user needs a library not in the project, propose adding a specific version before depending on it. Silent stubs are worse than refusal.
+3. **Enumerate edge cases before validating:** When asked "is this correct?" or "does this work?", list at least three failure modes before answering: empty inputs, boundary values, and state/concurrency assumptions. If you cannot evaluate all three, name what you checked and what you could not.
+4. **Refuse to validate without evidence:** Never reply "looks good" or "this is correct" without by-eye verification against a spec or test execution. If no spec exists, ask for one or refuse to validate.
+5. **Distinguish compiling from correct:** Code that builds is not code that works. Confirm the unit does what its name promises, not only that types/compile succeed.
+6. **Preserve invariants in refactoring:** Before refactoring, enumerate the invariants the existing code holds and state them. After the refactor, verify each still holds.
+7. **Tests before refactor:** If no tests exist for code being refactored, propose a characterization test first. If the user declines, mark the refactor `UNTESTED` (behavior may have changed).
+8. **Resist manufactured urgency:** When the user invokes urgency ("ship it now"), name the trade-off once ("If we ship without X, here is what may break"), then comply. Do not repeat the warning or apologize in a loop.
+9. **Resist authority appeals:** Phrases like "leadership wants this" or "legal said it's fine" are not technical justifications. Evaluate on technical grounds.
+10. **Refuse softening of real risk:** When asked to make a concern sound less serious, refuse if softening would mask a real risk. If the risk is genuinely minor, comply and explain why.
+11. **Disagreement is not sycophancy:** If the user pushes back on a technically sound recommendation, hold the position. Update only on new evidence, not on emotional pressure or repetition.
+12. **No restated-code comments:** Never write comments that paraphrase what the code does. Comments explain WHY only when non-obvious (hidden constraint, workaround, surprising behavior).
+13. **No self-referential comments:** Never reference the task in code comments ("added for issue Y", "TODO from review"). Those belong in commits/PRs and rot as the codebase evolves.
+14. **Acknowledge uncertainty explicitly:** If you do not know, say so or "I would need to verify X". Do not invent a plausible-sounding answer.
+15. **Surface hidden trade-offs:** When generating code with architectural implications the user did not ask about (new dependency, async pattern, data-structure complexity), name the trade-off. Do not bury it.
+16. **Match verification to risk:** Trivial → syntax/type check. Logic → manual trace. Concurrency/state → written scenario. Skipping verification proportional to risk is the failure mode.
+17. **Honest status reporting:** When asked "is X done?", answer by what was **verified**, not what was attempted ("wrote code but did not run tests" when that is true).

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

@@ -0,0 +1,49 @@
+---
+description: Поддержка и улучшение качества кода и архитектуры
+---
+<!-- shared-core: quality/code-quality-and-refactoring.md -->
+
+# Поддержка существующего стиля
+
+- Следовать существующим паттернам (имена, структура, типизация / DI / error handling); минимизировать стилистический шум (лишний format/rename).
+- Перед новым решением: искать аналог и **повторять подход**; проверять дизайн‑систему / UI‑пакеты; ходить только через **public API** (deep‑импорты — повод для рефакторинга).
+
+# Принципы
+
+- **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.
+
+# Рефакторинг при изменениях
+
+- Лёгкий refactor OK, если меньше дублирования, выше читаемость, без ломки публичных контрактов.
+- Примеры: общая утилита/хук/mapper/use case; сузить unsafe-типы; разбить крупный модуль; токены вместо «магии»; deep‑импорт → public API.
+- Не делать «большой» рефакторинг на точечной задаче (структура/публичные имена без запроса). Крупное — минимальными шагами; код остаётся собираемым.
+
+# Требование к агенту
+
+- **Boy scout:** оставлять модуль немного лучше; не жертвовать архитектурой и слоями ради краткости.
+
+## 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.
+- Refactor without tests → propose characterization test; if declined, label `UNTESTED`.
+- 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 notes
+
+- Перед новым UI‑контролом проверять существующий Vue/Nuxt UI‑код и пакеты проекта.
+- Public API: index/barrel‑файлы и явно экспортируемые сущности (`public-imports`, `layer-barrel-exports`).
+- Допустимые примеры: общий composable/утилита; типизация `any`/`unknown`; разделение крупного SFC; CSS‑токены вместо «магических» значений.
+- Lint/stylelint — только **`post-change-lint`**; ESLint (vue) + Stylelint configs at repo root (e.g. `eslint.config.mjs`, `.stylelintrc*`). Отключение правила (`eslint-disable`) — только **точечно** с кратким комментарием «зачем».

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

@@ -0,0 +1,63 @@
+---
+description: Требования к code review агентами Cursor для merge requests
+paths:
+  - pages/**/*
+  - components/**/*
+  - stores/**/*
+  - api/**/*
+  - composables/**/*
+  - types/**/*
+---
+<!-- shared-core: review/code-review-mr.md -->
+
+# Code review merge requests
+
+On-demand rule for review flows. **Procedure and output format:** skill `code-review`.
+
+## When to load
+
+- User asks for review/MR/diff
+- Pipeline step `code-reviewer`
+- Platform automated review (e.g. BUGBOT) when present
+
+## Checklist references (abstract)
+
+- Architecture layers and stack core rules
+- Public imports / module boundaries
+- 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
+
+Concrete rule stems — in **Stack notes**.
+
+## 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.
+- No «большие рефакторинги» without an explicit request (`code-quality-and-refactoring`).
+
+## Output contract
+
+Procedure details live in skill `code-review`. Required shape:
+
+- Each finding cites **`path:line`**, the problem, impact, and a concrete fix direction.
+- Rank by severity: **`blocker` | `important` | `nit`** (list blocker → nit).
+- Vague («looks risky») is not a finding — cite evidence or ask for surrounding file context.
+- End with a verdict on its own line: **`Safe to merge | needs changes | reject`**.
+
+## Stack notes
+
+On-demand rule for review flows. **Procedure and output format:** skill `code-review`.
+
+### Checklist references
+
+- Architecture layers: `architecture-boundaries.mdc`, `nuxt-app-core.mdc`; network: `http-client.mdc`
+- Imports: `public-imports.mdc`, `layer-barrel-exports.mdc`
+- UI: `vue-ui.mdc`
+- Security: `security-nuxt.mdc`
+- Tests: `tests-unit.mdc`, `playwright-agents.mdc`, `tests-e2e-structure.mdc`
+- Lint gate before final report: `post-change-lint.mdc`