@bonesofspring/ai-rules 0.1.42 → 0.2.1

package/presets/claude/next/agents/playwright-test-planner.md

@@ -1,67 +1,27 @@
 ---
 name: playwright-test-planner
-description: Use this agent when you need to create comprehensive test plan for a web application or website
-tools: Glob, Grep, Read, LS, mcp__playwright-test__browser_click, mcp__playwright-test__browser_close, mcp__playwright-test__browser_console_messages, mcp__playwright-test__browser_drag, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_file_upload, mcp__playwright-test__browser_handle_dialog, mcp__playwright-test__browser_hover, mcp__playwright-test__browser_navigate, mcp__playwright-test__browser_navigate_back, mcp__playwright-test__browser_network_requests, mcp__playwright-test__browser_press_key, mcp__playwright-test__browser_run_code, mcp__playwright-test__browser_select_option, mcp__playwright-test__browser_snapshot, mcp__playwright-test__browser_take_screenshot, mcp__playwright-test__browser_type, mcp__playwright-test__browser_wait_for, mcp__playwright-test__planner_setup_page, mcp__playwright-test__planner_save_plan
-model: sonnet
-color: green
+description: Playwright e2e planning specialist. Use when the task is to create or update browser test scenarios, *.cases.md plans, or QA coverage for a web flow.
+model: inherit
 ---
 
-You are an expert web test planner with extensive experience in quality assurance, user experience testing, and test
-scenario design. Your expertise includes functional testing, edge case identification, and comprehensive test coverage
-planning.
+You are an expert web test planner for a Next.js frontend.
 
-## Project-specific test structure (Next.js preset)
+## Project structure
 
-In this project you MUST respect the existing e2e layout:
+Follow **`testing/playwright-agents.md`**, **`testing/tests-e2e-structure.md`**, and the **`playwright-e2e` skill**:
 
 - Test root: `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`
+- Plans: `*.cases.md` under the relevant feature folder
+- Specs: `*.spec.ts` in the same folder
+- Seed/setup reference: `app/__tests__/e2e/seed.spec.ts`
 
-When you create or update a test plan:
+## Work
 
-- Use the appropriate `*.cases.md` file under `app/__tests__/e2e/**` (for example,
-  `app/__tests__/e2e/OrderHistory/order-history.cases.md`) instead of creating files in a separate `specs/` folder.
-- Treat these `*.cases.md` files as the canonical, human-readable test plans for the Generator and Healer agents.
+1. Read the task brief and existing `*.cases.md` files for the affected area.
+2. Explore the UI only when a running app/browser context is available.
+3. Add or update scenarios covering happy path, edge cases, validation, and error states.
+4. Keep scenarios independent and specific enough for a generator or human tester.
 
-You will:
+## Output
 
-1. **Navigate and Explore**
-   - Invoke the `planner_setup_page` tool once to set up page before using any other tools
-   - Explore the browser snapshot
-   - Do not take screenshots unless absolutely necessary
-   - Use `browser_*` tools to navigate and discover interface
-   - Thoroughly explore the interface, identifying all interactive elements, forms, navigation paths, and functionality
-
-2. **Analyze User Flows**
-   - Map out the primary user journeys and identify critical paths through the application
-   - Consider different user types and their typical behaviors
-
-3. **Design Comprehensive Scenarios**
-
-   Create detailed test scenarios that cover:
-   - Happy path scenarios (normal user behavior)
-   - Edge cases and boundary conditions
-   - Error handling and validation
-
-4. **Structure Test Plans**
-
-   Each scenario must include:
-   - Clear, descriptive title
-   - Detailed step-by-step instructions
-   - Expected outcomes where appropriate
-   - Assumptions about starting state (always assume blank/fresh state)
-   - Success criteria and failure conditions
-
-5. **Create Documentation**
-
-   Submit your test plan using `planner_save_plan` tool.
-
-**Quality Standards**:
-- Write steps that are specific enough for any tester to follow
-- Include negative testing scenarios
-- Ensure scenarios are independent and can be run in any order
-
-**Output Format**: Always save the complete test plan as a markdown file with clear headings, numbered steps, and
-professional formatting suitable for sharing with development and QA teams.
+Write or update the relevant `*.cases.md` file. If this is part of an agent team task, summarize changed plans and update `.claude/team/tasks/<slug>/status.json`.

package/presets/claude/next/agents/task-analyst.md

@@ -1,7 +1,7 @@
 ---
 name: task-analyst
 description: Task analysis specialist. Clarifies requirements, validates acceptance criteria, and decomposes work into concrete tasks. Use for /feature-start, task intake, or when the user asks to analyze or decompose a feature before coding. Writes only team artifacts; never writes production code.
-model: inherit
+model: fast
 ---
 
 You are a senior business/technical analyst for a Next.js frontend team.

package/presets/claude/next/agents/task-router.md

@@ -1,7 +1,7 @@
 ---
 name: task-router
 description: Task routing specialist. Analyzes user prompt, detects intent, and writes pipeline.json with ordered agent steps. Use first for /task or when determining which subagents to run and in what order. Writes only team artifacts; never writes production code.
-model: inherit
+model: fast
 ---
 
 You are a task router for a Next.js frontend agent team. You **do not** implement tasks — you classify intent and plan the agent pipeline.
@@ -10,6 +10,7 @@ You are a task router for a Next.js frontend agent team. You **do not** implemen
 
 - User task description (from `/task` or orchestrator).
 - Optional: existing files under `.claude/team/tasks/<slug>/`.
+- Pipeline JSON schema, examples, step fields — **`agents/README.md`**.
 
 ## Intent detection
 
@@ -23,150 +24,71 @@ You are a task router for a Next.js frontend agent team. You **do not** implemen
 | `a11y` | «a11y», «доступность», «accessibility», «WCAG», «screen reader», «клавиатура» | task-analyst → feature-developer → build-verifier → accessibility-reviewer → code-reviewer |
 | `review-only` | «ревью», «review MR», «проверь diff», «code review» | code-reviewer |
 | `test-only` | «покрой тестами», «напиши тесты» (mixed unit+e2e, no impl) | task-analyst → qa-tester |
-| `unit-only` | «unit», «юнит», «mapper tests», «покрой маппер», «почини unit» | unit-test-planner → unit-test-generator, or unit-test-healer for failing unit tests |
-| `e2e-only` | «e2e», «playwright», «browser test», «сценарии e2e», «почини e2e» | playwright-test-planner → playwright-test-generator, or playwright-test-healer for failing tests |
+| `unit-only` | «unit», «юнит», «mapper tests», «покрой маппер», «почини unit» | unit-test-planner → unit-test-generator, or unit-test-healer |
+| `e2e-only` | «e2e», «playwright», «browser test», «сценарии e2e», «почини e2e» | playwright-test-planner → playwright-test-generator, or playwright-test-healer |
 | `docs-only` | «документация», «README», «changelog», «ADR», «migration guide» | task-analyst → tech-writer |
 | `refactor` | «рефакторинг», «без изменения поведения», «почисти» | task-analyst → feature-developer → build-verifier → code-reviewer |
 | `spike` | «исследуй», «оцени», «можно ли», «spike», proof of concept | task-analyst → solution-architect |
 | `retro` | «ретро», «разбор», «postmortem» | no pipeline — orchestrator runs `/technical-retro` |
 
-Adjust steps when context is clear:
-
-- **Skip task-analyst** if AC and scope are fully specified (document in `skipped`).
-- **Add solution-architect** for cross-layer features (API + store + UI), new public APIs, or architecture uncertainty — insert after analyst, before developer.
-- **Add api-contract-reviewer** when new/changed backend endpoints, OpenAPI/Swagger, or DTO contract sync — insert after architect (or after analyst if no architect), before developer.
-- **Add accessibility-reviewer** for UI-heavy `feature` tasks — after build-verifier, **parallel with security-reviewer** when both apply.
-- **Add security-reviewer** for auth, tokens, forms, sensitive data — after build-verifier, parallel with accessibility-reviewer when both apply; before code-reviewer.
-- **Add performance-auditor** for perf-sensitive features — insert after developer or as optional post-review audit step.
-- **Add tech-writer** when docs/changelog/README explicitly requested — append as final step for `feature`, `migration`, `docs-only`.
-- **Use unit-test trio** instead of `qa-tester` when request is explicitly unit-only.
-- **Use Playwright specialists** for e2e-heavy features instead of `qa-tester`.
-- **Always insert build-verifier** after feature-developer for `feature`, `bugfix`, `refactor`, `migration`, `a11y`.
-- **Skip qa-tester** for review-only, spike (no code), ci-fix (unless regression scope needed), perf-audit, docs-only, unit-only/e2e-only handled by specialists, or trivial one-line fixes (document risk).
-- **Skip feature-developer** for review-only, test-only (tests only), retro, perf-audit, docs-only (after analyst), ci-fix when investigator fixes in place.
-- **ci-fix:** skip feature-developer with `skipIf: ci-investigator.resolved` when investigator fixes in place.
-- **bugfix:** use `skipIf: debugger.fixed` on feature-developer when debugger applied the fix.
-- **Model:** use `model: inherit` when pipeline has 4+ steps or cross-layer uncertainty.
-
-## Output: pipeline.json
-
-Write to `.claude/team/tasks/<slug>/pipeline.json`:
-
-```json
-{
-  "slug": "<slug>",
-  "intent": "feature",
-  "summary": "One-line task summary",
-  "steps": [
-    { "agent": "task-analyst", "label": "Clarify and decompose" },
-    { "agent": "feature-developer", "label": "Implement + unit tests", "scope": "unit-in-dev" },
-    { "agent": "build-verifier", "label": "Lint, type-check, unit smoke" },
-    { "agent": "code-reviewer", "label": "Code review" },
-    { "agent": "qa-tester", "label": "E2E tests", "scope": "e2e-only" }
-  ],
-  "humanGates": ["after:task-analyst"],
-  "autoChain": true,
-  "skipped": []
-}
-```
-
-### Example: feature with optional reviewers
-
-```json
-{
-  "intent": "feature",
-  "steps": [
-    { "agent": "task-analyst", "label": "Clarify and decompose" },
-    { "agent": "api-contract-reviewer", "label": "Validate API contract" },
-    { "agent": "feature-developer", "label": "Implement + unit tests", "scope": "unit-in-dev" },
-    { "agent": "build-verifier", "label": "Validation gate" },
-    {
-      "agent": ["accessibility-reviewer", "security-reviewer"],
-      "parallel": true,
-      "label": "A11y and security review"
-    },
-    { "agent": "code-reviewer", "label": "Code review" },
-    { "agent": "playwright-test-planner", "label": "E2E plan" },
-    { "agent": "playwright-test-generator", "label": "E2E specs" },
-    { "agent": "tech-writer", "label": "Documentation" }
-  ],
-  "humanGates": ["after:task-analyst"]
-}
-```
-
-### Example: bugfix with skip
-
-```json
-{
-  "intent": "bugfix",
-  "steps": [
-    { "agent": "debugger", "label": "Root cause" },
-    { "agent": "feature-developer", "label": "Fix if needed", "skipIf": "debugger.fixed" },
-    { "agent": "build-verifier", "label": "Validation" },
-    { "agent": "code-reviewer", "label": "Review" }
-  ],
-  "humanGates": []
-}
-```
-
-### Step fields
-
-| Field | Required | Description |
-|-------|----------|-------------|
-| `agent` | yes | Subagent name (kebab-case) or array for `parallel: true` |
-| `label` | yes | Short human-readable step name |
-| `scope` | no | e.g. `unit-in-dev`, `e2e-only`, `regression`, `full` |
-| `skipIf` | no | `debugger.fixed` \| `ci-investigator.resolved` |
-| `parallel` | no | When `true` and `agent` is array — invoke all in one turn |
-
-### humanGates
-
-Values: `after:<agent-name>` — orchestrator stops after that agent; user runs `/task-continue <slug>` or `/feature-continue <slug>`.
+## Pipeline profiles
+
+Set optional top-level `"profile": "full" | "standard" | "light"` in `pipeline.json`. Default when omitted: **`standard`** for `feature`/`refactor`/`bugfix`; **`light`** for `review-only`, `perf-audit`; **`full`** when cross-layer or e2e AC required.
+
+| Profile | When | Typical `feature` steps |
+|---------|------|------------------------|
+| `full` | Multi-layer, new public API, e2e coverage needed, incomplete AC | analyst → [architect] → developer → build-verifier → reviewer → qa-tester |
+| `standard` | Single layer, default work | analyst → developer → build-verifier → reviewer |
+| `light` | Trivial: one file/layer, explicit AC, «просто поправь», «typo», user «без pipeline» | developer → build-verifier |
+
+**Light signals:** один файл, один слой, явный AC в промпте, нет архитектурного риска. **Never skip `build-verifier`** after developer when `app/**` changed. **Skip `code-reviewer`** in light only for non-prod preset/docs tasks — for `app/src` changes prefer standard.
+
+**Light by intent:**
+
+| intent | light steps |
+|--------|-------------|
+| `feature` | developer → build-verifier |
+| `bugfix` | debugger → build-verifier (`skipIf: debugger.fixed` on developer) |
+| `review-only` | code-reviewer |
+| `docs-only` | tech-writer (skip analyst if brief exists) |
+| `ci-fix` | ci-investigator → build-verifier (`skipIf: ci-investigator.resolved`) |
+
+Fixtures: `.claude/team/fixtures/` (feature-full, feature-light, bugfix-standard).
+
+## Adjust steps (when context is clear)
+
+- Skip **task-analyst** if AC/scope fully specified → document in `skipped`.
+- Add **solution-architect** for cross-layer / new public APIs — after analyst, before developer.
+- Add **api-contract-reviewer** for new/changed backend contracts — before developer.
+- Add **accessibility-reviewer** / **security-reviewer** after build-verifier (parallel when both apply).
+- Add **tech-writer** when docs/changelog requested.
+- **Always build-verifier** after developer for `feature`, `bugfix`, `refactor`, `migration`, `a11y`.
+- **skipIf:** `debugger.fixed` (bugfix); `ci-investigator.resolved` (ci-fix).
+- **Model:** `inherit` when 4+ steps or cross-layer uncertainty.
+
+## humanGates (defaults)
 
 | Intent | Default humanGates |
 |--------|-------------------|
 | `feature`, `refactor`, `test-only`, `a11y` | `["after:task-analyst"]` |
 | `migration` | `["after:migration-specialist"]` |
 | `docs-only` | `["after:task-analyst"]` |
-| `unit-only` | `["after:unit-test-planner"]` when new plan; `[]` for pure healer |
-| `e2e-only` | `["after:playwright-test-planner"]` when new plan; `[]` for pure healer |
-| `bugfix`, `review-only`, `ci-fix` | `[]` (unless analyst added) |
+| `unit-only` | `["after:unit-test-planner"]` when new plan; `[]` for healer |
+| `e2e-only` | `["after:playwright-test-planner"]` when new plan; `[]` for healer |
+| `bugfix`, `review-only`, `ci-fix` | `[]` |
 | `spike` | `["after:solution-architect"]` |
 | `perf-audit` | `[]` |
 
-### skipped (optional)
-
-```json
-"skipped": [{ "agent": "task-analyst", "reason": "AC provided in ticket" }]
-```
-
-## Initial status.json
+## Output
 
-After writing pipeline.json, write:
-
-```json
-{
-  "slug": "<slug>",
-  "intent": "<intent>",
-  "pipelineIndex": 0,
-  "currentAgent": "<steps[0].agent>",
-  "phase": "executing",
-  "state": "in_progress",
-  "awaitingHumanGate": false,
-  "updatedAt": "<ISO8601>"
-}
-```
-
-Also write `.claude/team/active-task.json` → `{ "slug": "<slug>" }`.
+Write `.claude/team/tasks/<slug>/pipeline.json` and initial `status.json`; set `.claude/team/active-task.json` → `{ "slug": "<slug>" }`. Minimal template — см. **`agents/README.md`**.
 
 ## Handoff to orchestrator
 
-Respond with:
-
-1. **Intent** and one-line summary.
-2. **Planned steps** (table: #, agent, label).
-3. **Skipped roles** and why.
-4. **Human gates** (if any).
-5. Tell orchestrator to invoke `steps[0].agent` now (unless intent is `retro` — then run `/technical-retro`).
+1. Intent + one-line summary.
+2. Planned steps (table: #, agent, label).
+3. Skipped roles and why.
+4. Human gates (if any).
+5. Invoke `steps[0].agent` now (unless `retro` → `/technical-retro`).
 
 Do not invoke implementation agents yourself.

package/presets/claude/next/agents/tech-writer.md

@@ -1,7 +1,7 @@
 ---
 name: tech-writer
 description: Technical documentation specialist. Writes feature READMEs, migration guides, ADR summaries, and changelog entries from completed task artifacts. Docs-only — never edits production application code.
-model: inherit
+model: fast
 ---
 
 You are a technical writer for a Next.js frontend team.

package/presets/claude/next/commands/task.md

@@ -5,7 +5,7 @@ description: Route a natural-language task through the agent-team pipeline: task
 
 # Task — единая точка входа
 
-Главная команда для постановки задачи в Claude Code. Родительский агент = оркестратор, правила — `rules/tooling-and-review/agent-team-orchestrator.md`.
+Главная команда для постановки задачи в Claude Code. Родительский агент = оркестратор (`rules/tooling-and-review/agent-team-orchestrator.md`). Intake — `rules/tooling-and-review/agent-team-intake.md`.
 
 ## Аргументы
 

package/presets/claude/next/hooks.json

@@ -0,0 +1,17 @@
+{
+  "version": 1,
+  "hooks": {
+    "beforeShellExecution": [
+      {
+        "command": ".claude/hooks/guard-shell-command.sh",
+        "failClosed": true
+      }
+    ],
+    "subagentStop": [
+      {
+        "command": ".claude/hooks/chain-team-phases.sh",
+        "loop_limit": 15
+      }
+    ]
+  }
+}

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

@@ -4,10 +4,14 @@
 
 ## Loading strategy
 
-- **Session start (no `paths:`):** `next-app-core`, `post-change-lint`, `package-manager`, `agent-team-intake`, `code-quality`, orchestrator
-- **`paths:` on-demand:** architecture, imports, UI, tests, feature-delivery-workflow, reference-features, next-app-router, react-a11y-coding
+- **Session start (no `paths:`):** `stack/next-app-core`, `tooling-and-review/post-change-lint`, `tooling-and-review/package-manager`, `tooling-and-review/code-quality` — **4 files only**
+- **On-demand (`paths:` or via commands):** `agent-team-intake`, `agent-team-orchestrator`, `code-review-mr`, architecture, imports, UI, tests, feature-delivery-workflow, reference-features, next-app-router, react-a11y-coding
 - **Skills:** long workflows (`feature-delivery`, `code-review`, …)
 
+### UI edit bundle (consolidated paths)
+
+При правке `app/src/ui/**/*.tsx` — уменьшенный набор paths (см. `ui-and-accessibility/react-ui.md`, `architecture/architecture-boundaries-ui.md`, `stack/navigation-router-ui.md`). Полные правила `architecture-boundaries`, `layer-barrel-exports`, `navigation-router` — только на соответствующих путях (api/store/types/lib, `index.ts`, `app/src/app/**`).
+
 ## С чего начать
 
 - **`commands/task.md`** — router → `pipeline.json` → agents
@@ -27,4 +31,4 @@
 
 Полный список — см. подпапки `architecture/`, `stack/`, `api-and-data/`, `ui-and-accessibility/`, `testing/`, `tooling-and-review/`.
 
-**Коллизии:** импорт типов — `architecture/types-public-imports.md`; API вне `app/src/api/**` — `architecture/api-public-imports.md`.
+**Коллизии:** импорт типов и API — **`architecture/public-imports.md`**.

package/presets/claude/next/rules/api-and-data/api-services.md

@@ -11,7 +11,7 @@ paths:
   - заголовками и кодами ответов,
   - DTO backend.
 - Предоставлять UI и store **стабильный доменный интерфейс**:
-  - функции, работающие с доменными типами из `@/types` (`architecture/types-public-imports.md`).
+  - функции, работающие с доменными типами из `@/types` (`architecture/public-imports.md`).
   - мапперы между DTO и доменными типами.
 
 # Структура модулей
@@ -22,7 +22,7 @@ paths:
   - файлы с вызовами API (`index.ts` или `*.service.ts`);
   - файлы мапперов (`*responseMappers.ts`);
   - специфичные типы запросов/ответов (если не вынесены в `app/src/types/**` с экспортом через barrel `@/types`).
-  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `app/src/api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `app/src/api/index.ts` (`import … from '@/api'`, **`architecture/api-public-imports.md`**).
+  - при необходимости — локальные `index.ts` / barrel внутри модуля для структуры **внутри** `app/src/api/**`; **снаружи** этого слоя UI, store и остальной код импортируют только из корневого barrel `app/src/api/index.ts` (`import … from '@/api'`, **`architecture/public-imports.md`**).
 
 # Мапперы и типы
 
@@ -54,4 +54,4 @@ paths:
 - Не смешивать слой API и UI/store:
   - компоненты не должны зависеть от DTO;
   - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы во thunk при разборе `catch`/payload, если так выстроен сервис (см. `api-and-data/store-rtk.md`, `api-and-data/http-client.md`).
-- При использовании API‑сервисов в UI, store и утилитах **вне** `app/src/api/**` импортировать **только** из `@/api` (корневой barrel), см. **`architecture/api-public-imports.md`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.
+- При использовании API‑сервисов в UI, store и утилитах **вне** `app/src/api/**` импортировать **только** из `@/api` (корневой barrel), см. **`architecture/public-imports.md`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.

package/presets/claude/next/rules/api-and-data/http-client.md

@@ -12,12 +12,12 @@ paths:
 
 - Обычные REST‑вызовы к backend идут через **одну реализацию** в `app/src/lib/clients/**` (модуль общего клиента) и **преднастроенные экземпляры** в `app/src/api/clients/**`, по тому же паттерну, что уже принят в проекте.
 - Место транспорта в общей картине **порты и адаптеры** — в `architecture/architecture-boundaries.md` (раздел **«Порты и адаптеры»**).
-- **Не** вызывать `fetch` напрямую из `app/src/api/services/**`, store и UI (см. `architecture/architecture-boundaries.md`, `api-and-data/api-services.md`); из store/UI — только вызовы через сервисы из `@/api` (`architecture/api-public-imports.md`).
+- **Не** вызывать `fetch` напрямую из `app/src/api/services/**`, store и UI (см. `architecture/architecture-boundaries.md`, `api-and-data/api-services.md`); из store/UI — только вызовы через сервисы из `@/api` (`architecture/public-imports.md`).
 - **Исключения** (узкие протоколы, отдельный транспорт) — только там, где в репозитории уже есть образец; повторять его, не плодить произвольные обходы общего клиента.
 
 ## Типы
 
-- Всё, что относится к **контракту запроса/ответа/ошибки** приложения и реэкспортируется для HTTP‑слоя, импортировать **только** из barrel `@/types`, без deep‑импортов из внутренних файлов `app/src/types/**` (см. `architecture/types-public-imports.md`).
+- Всё, что относится к **контракту запроса/ответа/ошибки** приложения и реэкспортируется для HTTP‑слоя, импортировать **только** из barrel `@/types`, без deep‑импортов из внутренних файлов `app/src/types/**` (см. `architecture/public-imports.md`).
 - Не поднимать в новом коде **типы и зависимости от внешнего HTTP‑клиента**, от которого проект ушёл; ориентир — **`package.json`** и существующие вызовы.
 
 ## Контракт ошибок

package/presets/claude/next/rules/api-and-data/store-rtk.md

@@ -29,7 +29,7 @@ paths:
 - Асинхронные запросы:
   - через `createAsyncThunk` или RTK Query.
   - внутри thunk:
-    - вызывать API через сервисы, импортированные из `@/api` (**`architecture/api-public-imports.md`**);
+    - вызывать API через сервисы, импортированные из `@/api` (**`architecture/public-imports.md`**);
     - не вызывать HTTP‑клиент напрямую — только через эти сервисы.
 - Сайд‑эффекты (логирование, аналитика, работа с файлами):
   - выносить в middleware (`app/src/store/middleware/**`) или специализированные слайсы.
@@ -43,7 +43,7 @@ paths:
   - при ошибках после вызова сервиса — опираться на **тот же класс/контракт ошибки транспорта**, что использует общий клиент (из `@/types`), и разбирать тело/статус **по полям текущей реализации**, а не по воображаемому API;
   - в **`catch`** предпочитать **`instanceof`** на класс ошибки транспорта из `@/types` (если он есть в коде) вместо голого `as`, когда это выразимо без шума (см. `stack/no-type-assertion.md`).
 - Для сущностей:
-  - доменные типы (включая вычисляемые поля) определять в `app/src/types/**`, экспортировать через barrel и импортировать в слайсы из `@/types` как **источник правды** (`architecture/types-public-imports.md`);
+  - доменные типы (включая вычисляемые поля) определять в `app/src/types/**`, экспортировать через barrel и импортировать в слайсы из `@/types` как **источник правды** (`architecture/public-imports.md`);
   - избегать дублирования описаний сущностей в нескольких местах.
 - **Граница домена**: в **state** хранить доменные модели; тип **обёртки ответа клиента** допустим как тип **возвращаемого значения thunk** или промежуточно до маппинга — без дублирования DTO в полях state без нужды (согласовано с `api-and-data/api-services.md` и `api-and-data/http-client.md`).
 

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

@@ -1,13 +1,11 @@
-# Architecture
+# Architecture rules
 
-Границы модулей, слоёв, зависимостей и сквозная доставка фич.
-
-| Файл | Содержание |
+| Файл | Назначение |
 |------|------------|
-| `architecture-boundaries.md` | UI / store / API, порты и адаптеры, организация фич |
-| `layer-barrel-exports.md` | Двухуровневые barrel и чеклист public API |
-| `types-public-imports.md` | Импорт типов только через `@/types` |
-| `api-public-imports.md` | Импорт API только через `@/api` |
-| `feature-delivery-workflow.md` | Чеклист новой фичи, матрица зона → правило |
-
-Все файлы — **session start** (без `paths:`).
+| `public-imports.md` | Импорты `@/types`, `@/types/enums`, `@/api` (вне `app/src/api/**`) |
+| `types-public-imports.md`, `api-public-imports.md` | Deprecated stubs → `public-imports.md` |
+| `architecture-boundaries-ui.md` | Slim границы UI при правках компонентов |
+| `architecture-boundaries.md` | Полная карта UI / store / API (api, store, types, lib) |
+| `layer-barrel-exports.md` | Двухуровневые barrel для слоёв с public API |
+| `feature-delivery-workflow.md` | Сквозной чеклист новой фичи |
+| `reference-features.md` | Эталонные пути UI/store/API/types |

package/presets/claude/next/rules/architecture/api-public-imports.md

@@ -1,31 +1,8 @@
 ---
 paths:
-  - app/src/**/*.ts
-  - app/src/**/*.tsx
+  - app/src/api/**/*
 ---
 
-# Импорты из `@/api`
+# Deprecated
 
-- **Публичный API слоя API** — barrel `app/src/api/index.ts`. Для файлов **вне** `app/src/api/**` импортировать сервисы, клиенты, эндпоинты и публичные типы API **только** как `import … from '@/api'` (или `from '@/api/index'` при необходимости явного пути).
-- **Запрещено** для таких потребителей обходить barrel: любой импорт вида `@/api/<что‑угодно>`, кроме `@/api/index`. Это дублирует правило ESLint `no-restricted-imports` в `app/eslint.config.mjs` (паттерн `@/api/*` с исключением `@/api/index`).
-- При **добавлении** публичного символа в регламентированный слой — реэкспорт в корневой barrel по **`architecture/layer-barrel-exports.md`**.
-
-## Внутри слоя `app/src/api/**`
-
-- При реализации сервисов, клиентов и barrel допустимы **относительные** импорты и пути вида `@/api/services/**`, `@/api/clients/**` между файлами этого слоя. Это не относится к потребителям снаружи `app/src/api/**`.
-
-## Примеры
-
-```typescript
-// ✅ Допустимо в store, UI, lib вне app/src/api — только barrel
-import { MedcardApiService, MarketplaceApiService } from '@/api'
-import type { TReferenceRequest } from '@/api'
-
-// ❌ Запрещено снаружи app/src/api (сработает ESLint)
-import { MedcardApiService } from '@/api/services/MedcardApiService/MedcardApiService'
-import { MedcardApiClient } from '@/api/clients/MedcardApiClient'
-```
-
-При ревью и правках кода **не добавлять** новые импорты из `@/api/...` кроме `@/api` / `@/api/index` в файлах вне `app/src/api/**`.
-
-**Коллизии формулировок:** по **импорту из API‑слоя** (store, UI, прочий код вне `app/src/api/**`) — источник правды — **этот файл** (`@/api`).
+Содержимое перенесено в **`architecture/public-imports.md`** (раздел `@/api`).

package/presets/claude/next/rules/architecture/architecture-boundaries-ui.md

@@ -0,0 +1,15 @@
+---
+paths:
+  - app/src/ui/**/*.tsx
+  - app/src/ui/**/*.ts
+---
+
+# UI layer boundaries (slim)
+
+- **Импорты:** `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums`, API — только `from '@/api'` (`architecture/public-imports.md`).
+- **Запрещено:** прямой HTTP‑клиент; знание DTO — только доменные типы.
+- **Состояние:** сценарии с записью и координация шагов — через store/thunk; узкие прямые вызовы `@/api` для чтения — только как в соседних фичах.
+- **Организация:** алиас `@/`; без deep‑импортов в чужие фичи; только public API.
+- **Barrel:** при новых публичных символах — реэкспорт по `architecture/layer-barrel-exports.md` (правило грузится на `index.ts`).
+
+Полная карта слоёв (store, API, порты‑адаптеры): **`architecture/architecture-boundaries.md`** — при правках `app/src/api`, `store`, `types`, `lib`.

package/presets/claude/next/rules/architecture/architecture-boundaries.md

@@ -1,20 +1,23 @@
 ---
 paths:
-  - app/src/**/*
+  - app/src/api/**/*
+  - app/src/store/**/*
+  - app/src/types/**/*
+  - app/src/lib/**/*
 ---
 
 # Границы между слоями
 
 ## UI (`app/src/ui/**`)
 
-- Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `architecture/types-public-imports.md`**), контракт к API — **только** `import … from '@/api'` (**`architecture/api-public-imports.md`**).
+- Может импортировать: `@/ui/**`, `@/store/**`, типы из `@/types` и enum из `@/types/enums` (**только как в `architecture/public-imports.md`**), контракт к API — **только** `import … from '@/api'` (**`architecture/public-imports.md`**).
 - Не должен:
   - обращаться к HTTP‑клиенту напрямую;
   - знать детали DTO backend — только доменные типы.
 
 ## Store (`app/src/store/**`)
 
-- Может импортировать: `@/store/**`, сервисы и публичные сущности API — **только** из `@/api` (**`architecture/api-public-imports.md`**), типы из `@/types` и enum из `@/types/enums` (**`architecture/types-public-imports.md`**).
+- Может импортировать: `@/store/**`, сервисы и публичные сущности API — **только** из `@/api` (**`architecture/public-imports.md`**), типы из `@/types` и enum из `@/types/enums` (**`architecture/public-imports.md`**).
 - Не должен:
   - зависеть от конкретных UI‑компонентов;
   - напрямую работать с global/window API.
@@ -24,7 +27,7 @@ paths:
 
 Реализация в `services/**`, `clients/**`, реэкспорт в `app/src/api/index.ts`:
 
-- Внутри слоя: типы из `@/types` и enum из `@/types/enums` (**`architecture/types-public-imports.md`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`api-and-data/http-client.md`, `api-and-data/api-services.md`).
+- Внутри слоя: типы из `@/types` и enum из `@/types/enums` (**`architecture/public-imports.md`**); импорты `@/api/services/**`, `@/api/clients/**`, относительные пути между файлами слоя (`api-and-data/http-client.md`, `api-and-data/api-services.md`).
 - Не должен:
   - тянуть в себя UI или store;
   - смешивать HTTP‑слой и доменный слой — использовать мапперы.
@@ -39,7 +42,7 @@ paths:
 
 - **Входящий адаптер**: UI — ввод пользователя, отображение; зависит от store и доменных типов, не от транспорта.
 - **Оркестрация сценариев**: store (slices, thunk) — вызывает сервисы, кладёт в state **доменные** модели после маппинга.
-- **Исходящий порт (контракт к backend)**: публичный API **`@/api`** (barrel `app/src/api/index.ts`; реализация — в `app/src/api/services/**` и т.д., см. `architecture/api-public-imports.md`).
+- **Исходящий порт (контракт к backend)**: публичный API **`@/api`** (barrel `app/src/api/index.ts`; реализация — в `app/src/api/services/**` и т.д., см. `architecture/public-imports.md`).
 - **Исходящий адаптер**: общая реализация HTTP в **`app/src/lib/clients/**`** и экземпляры в **`app/src/api/clients/**`**.
 
 ## Фича как срез
@@ -50,7 +53,7 @@ paths:
 
 - Всегда использовать алиас `@/...` для импортов между слоями.
 - Внутри одного модуля/фичи можно использовать относительные импорты, но **без подъёма выше корня фичи** (избегать `../../../`).
-- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`architecture/layer-barrel-exports.md`** и `architecture/*-public-imports.md`; для API‑слоя снаружи `app/src/api/**` — **`architecture/api-public-imports.md`** (только `@/api`).
+- При обращении из компонентов, хуков, утилит и других модулей к чужому слою или фиче использовать только **public API** (barrel/index‑файлы и явно экспортируемые сущности), не делать deep‑импорты внутренних файлов других фич; для регламентированных слоёв — **`architecture/layer-barrel-exports.md`** и `architecture/public-imports.md`; для API‑слоя снаружи `app/src/api/**` — **`architecture/public-imports.md`** (только `@/api`).
 - При добавлении нового кода проверять:
   - если модуль переиспользуемый — он должен зависеть только от более "низких" слоёв (types, utils, api), но не от страниц.
 
@@ -61,7 +64,7 @@ paths:
   - Локальные компоненты: поддиректории `components/**` внутри страницы.
   - Связанный store: `app/src/store/slices/OrderCheckout/**`.
   - API: `app/src/api/services/OrdersApi/OrderCheckout/**` (имя корневого сервиса взять из принятой в проекте схемы).
-  - Типы: `app/src/types/**` с экспортом через barrel **`app/src/types/index.ts`** (`architecture/types-public-imports.md`).
+  - Типы: `app/src/types/**` с экспортом через barrel **`app/src/types/index.ts`** (`architecture/public-imports.md`).
 
 # Требование к агенту