@bonesofspring/ai-rules 0.2.0 → 0.2.2

package/presets/cursor/ios-swift/rules/feature-delivery-workflow.mdc

@@ -0,0 +1,61 @@
+---
+description: Сквозной чеклист доставки iOS-фичи и матрица «зона → правило». Use when implementing features, adding screens/API, or extending existing iOS flows.
+alwaysApply: false
+---
+
+# Доставка фичи (iOS)
+
+Типичная фича с данными и UI. Детали слоёв — `architecture-boundaries.mdc`, `ios-app-core.mdc`.
+
+## Чеклист (порядок работ)
+
+1. **Domain** — entities, value types, протоколы репозиториев / use cases (`Features/**/Domain/**`).
+2. **Data** — DTO (`Codable`), mappers Domain ↔ DTO, реализации репозиториев, API-клиент (`networking-services.mdc`).
+3. **ViewModel** — состояние, вызовы use case / протоколов; DI из App; без DTO и URL (`state-and-viewmodels.mdc`).
+4. **View / navigation** — тонкие SwiftUI Views, Design System; навигация как в репо (`swiftui-ui.mdc`).
+5. **Тесты** — unit на mappers / use cases / VM (`tests-unit.mdc`); UI-потоки — XCUITest (`tests-ui.mdc`).
+6. **Завершение** — **`post-change-build.mdc`**: сборка затронутых таргетов + lint/format по конфигу репо.
+
+## Поток данных (ориентир)
+
+```mermaid
+flowchart LR
+  DTO[DTO] --> Mappers[Mappers]
+  Mappers --> Domain[Domain]
+  Domain --> Repo[Repository protocol]
+  Repo --> VM[ViewModel]
+  VM --> View[SwiftUI View]
+  DataImpl[Data impl] -.-> Repo
+```
+
+## Частичные сценарии
+
+| Задача | Минимум |
+|--------|---------|
+| Только API / модель | Domain + DTO + mapper + repo impl; unit на mapper. |
+| Только VM / логика | Протоколы Domain; mock в тестах; без HTTP во View. |
+| Только UI | View + существующий VM/state; без DTO. |
+| Только тесты | Specs по конвенции репо; не менять production без нужды. |
+
+## Антипаттерны
+
+- DTO / `Codable` transport-типы во View или ViewModel.
+- `URLSession` / конкретный API-клиент в ViewModel или View.
+- Domain импортирует SwiftUI / UIKit.
+- Deep-import внутренних файлов другой фичи.
+- Сборка DI внутри View.
+
+## Матрица: зона → правила
+
+| Зона | Правила |
+|------|---------|
+| `Features/**/Domain/**`, `Core/Domain/**` | `architecture-boundaries.mdc`, `ios-app-core.mdc` |
+| `Features/**/Data/**`, `**/Network*/**` | `networking-services.mdc`, `architecture-boundaries.mdc` |
+| `*ViewModel*.swift`, Presentation state | `state-and-viewmodels.mdc` |
+| `Presentation/**`, `DesignSystem/**` | `swiftui-ui.mdc`, `architecture-boundaries.mdc` |
+| `**/*.swift` (стиль) | `swift-conventions.mdc` |
+| `*Tests/**` | `tests-unit.mdc` |
+| `*UITests/**` | `tests-ui.mdc` |
+| После правок Swift | `post-change-build.mdc` |
+
+При добавлении или расширении фичи **пройти чеклист** и правила из таблицы для затронутых зон.

package/presets/cursor/ios-swift/rules/ios-app-core.mdc

@@ -0,0 +1,43 @@
+---
+description: Базовые принципы, стек и структура iOS приложения на Swift (preset)
+alwaysApply: true
+---
+
+# Стек и окружение
+
+Версии Swift, iOS SDK, зависимостей и инструментов — **из Xcode-проекта, Package.swift и конфигов целевого репозитория**. Рамка preset:
+
+- **Язык / платформа:** Swift, iOS (min — из таргета).
+- **UI:** SwiftUI — приоритет для нового кода; UIKit — где уже принято в репо.
+- **Сборка:** Xcode; SPM и/или CocoaPods — как в репозитории.
+- **Concurrency:** `async`/`await`, `Task`, `Actor`; UI — `@MainActor`.
+- **Тесты:** XCTest или Swift Testing; UI — XCUITest.
+- **Сеть:** `URLSession` или клиент репо; DTO через `Codable`.
+- **Дизайн-система:** токены/примитивы из `DesignSystem/` (или аналога); без «магических» значений.
+- **Наблюдаемость:** только если уже в проекте — централизованно.
+
+# Структура проекта
+
+Ориентир — **feature-first + слои внутри фичи** или **слои на верхнем уровне** (как в репо):
+
+- `App/` — `@main`, composition root, DI, навигация верхнего уровня.
+- `Features/<FeatureName>/` — `Presentation/` (Views, ViewModels), `Domain/` (entities, use cases, протоколы), `Data/` (repos, API, DTO, mappers).
+- `Core/` — общие утилиты, extensions, базовые ошибки.
+- `DesignSystem/` — UI-примитивы без бизнес-логики.
+- `Tests/` / `*Tests/` — unit и UI по конвенции Xcode.
+
+Новые файлы — в том же слое/модуле, что и аналогичная функциональность.
+
+Границы зависимостей и DI — **`architecture-boundaries.mdc`**.
+
+# Swift и качество
+
+- Swift API Design Guidelines + SwiftLint/SwiftFormat репо (если есть).
+- Избегать `!` / `try!` в production; `guard` / `if let` / typed errors.
+- Копировать существующие паттерны фичи/слоя.
+
+# Работа агента
+
+- Определить слой (Presentation / Domain / Data / DesignSystem / Tests); повторить паттерн соседних файлов.
+- Не тянуть `URLSession` во View и DTO во ViewModel — детали в `architecture-boundaries.mdc`.
+- Доставка фичи — `feature-delivery-workflow.mdc`; после правок Swift — `post-change-build.mdc`.

package/presets/cursor/ios-swift/rules/networking-services.mdc

@@ -0,0 +1,49 @@
+---
+description: Конвенции сетевого слоя, API-клиентов и mappers
+globs: "**/{Data,Network,Networking}/**/*.swift"
+alwaysApply: false
+---
+
+# Роль Data / Network слоя
+
+- Инкапсулировать:
+  - HTTP-запросы (`URLSession` или клиент проекта),
+  - URL, headers, status codes,
+  - Codable DTO,
+  - persistence (Core Data, SwiftData, Keychain — по репо).
+- Наружу (Domain, ViewModel через repository) отдавать **доменные типы**, не DTO.
+
+# Структура модулей
+
+- На доменную область — каталог в `Features/<Feature>/Data/` или `Core/Network/<Service>/`.
+- Внутри:
+  - `*APIClient.swift` / `*Service.swift` — вызовы эндпоинтов;
+  - `*DTO.swift` — транспортные модели (`Codable`);
+  - `*Mapper.swift` — DTO ↔ domain;
+  - `*RepositoryImpl.swift` — реализация протокола из Domain.
+- Public surface — протоколы репозиториев в Domain; Data-классы не экспортируются во View.
+
+# DTO, mappers и типы
+
+- DTO **точно** отражают контракт backend (`CodingKeys` при расхождении имён).
+- Доменные entity — в Domain; mapper — **чистые функции** без side effects.
+- В mapper выполнять вычисления (флаги, форматирование, агрегаты), чтобы ViewModel получал готовую модель.
+- Optional и отсутствующие поля обрабатывать явно; не прокидывать «сырой» optional cascade в UI.
+
+# Async, errors и retries
+
+- Сетевые методы — `async throws` с **typed errors** (`NetworkError`, `APIError`) по конвенции репо.
+- Не глотать ошибки; пробрасывать или маппить в domain errors для ViewModel.
+- Retry, auth refresh, logging — централизованно (interceptor, middleware, `URLProtocol`), не в каждом методе.
+
+# Codable и versioning
+
+- Избегать `[String: Any]`; для полиморфизма — enum + associated values или явные DTO.
+- `@MainActor` не ставить на Data-типы без необходимости.
+
+# Требование к агенту
+
+При добавлении/изменении API:
+- Следовать существующим клиентам и mappers как эталону.
+- Добавить/обновить mapper tests для нетривиальных преобразований.
+- ViewModel и View не должны импортировать DTO-файлы.

package/presets/cursor/ios-swift/rules/post-change-build.mdc

@@ -0,0 +1,32 @@
+---
+description: Сборка и lint после изменений Swift/iOS кода. Use after editing iOS/Swift sources, Xcode targets, or Package.swift.
+alwaysApply: false
+---
+
+# Сборка и lint после изменений
+
+## Когда применять
+
+После изменений исходников Swift / проектных файлов Xcode / `Package.swift`, влияющих на компиляцию или стиль.
+
+Исключения: только документация, README, `.cursor/rules/**` без правок app-кода.
+
+**Pipeline:** если следующий шаг — отдельный verifier/CI-агент, достаточно затронутых таргетов; в single-agent режиме — полный разумный прогон как в репо.
+
+## Как определить команды
+
+1. Схемы / таргеты — из `.xcodeproj` / `.xcworkspace` / `Package.swift` (как в CI или соседних скриптах).
+2. Lint — `SwiftLint` / `.swiftlint.yml`, если есть.
+3. Format — `SwiftFormat` / конфиг, если принято в репо.
+4. Тесты — XCTest или Swift Testing — только если задача их затрагивает.
+
+Не угадывать чужой toolchain: копировать флаги/`xcodebuild` из Makefile, scripts, CI.
+
+## Алгоритм
+
+1. Завершить правки.
+2. Собрать **затронутые** таргеты (`xcodebuild` / `swift build` — как в репо).
+3. Прогнать lint/format при наличии конфигов; исправить ошибки в файлах задачи.
+4. Повторить до чистой сборки или зафиксировать блокер пользователю.
+
+**Errors** — обязательно; warnings в файлах задачи — по возможности до нуля.

package/presets/cursor/ios-swift/rules/state-and-viewmodels.mdc

@@ -0,0 +1,43 @@
+---
+description: ViewModels, состояние экрана и domain flow
+globs: "**/{Presentation,Domain}/**/*ViewModel*.swift"
+alwaysApply: false
+---
+
+# Общие принципы
+
+- ViewModel — **единственная точка** orchestration для экрана: load, submit, validation, navigation intents.
+- Хранить и отдавать во View **domain models** и UI-specific state (loading, error message, selected tab).
+- `@MainActor` на ViewModel; тяжёлую работу — в use case / repository (`async`), не блокировать main thread.
+- Unidirectional flow: View → intent → ViewModel → use case → state update → View.
+
+# State
+
+- Явный enum или struct для UI state где уместно:
+  - `idle`, `loading`, `loaded(Data)`, `failed(Error)` — или аналог из репо.
+- Избегать множества несинхронизированных `@Published` флагов, если один enum покрывает сценарий.
+- `@Observable` / `ObservableObject` — как в проекте; не смешивать стили в одной фиче без причины.
+
+# Use cases и repositories
+
+- ViewModel зависит от **протоколов** (`LoadOrdersUseCase`, `OrderRepository`), не от `*RepositoryImpl`.
+- Один use case — одна бизнес-операция; не раздувать ViewModel сотнями строк — выносить use cases в Domain.
+- Кэширование и offline — в repository/Data, не во ViewModel.
+
+# Side effects
+
+- Analytics, haptics, deep links — через injected services или middleware-паттерн, не hardcode синглтонов.
+- `Task` в ViewModel: отмена при `deinit` / `onDisappear` где нужно (`task(id:)`, хранение `Task?` с cancel).
+
+# Тестируемость
+
+- Инициализатор ViewModel принимает протоколы (DI); без скрытых singleton для сети/БД.
+- Бизнес-ветки покрывать unit-тестами с mock use cases.
+
+# Требование к агенту
+
+При создании ViewModel:
+- Не вызывать `URLSession` / API client напрямую.
+- Не парсить JSON и не объявлять DTO во ViewModel.
+- Именование: `FeatureViewModel`, методы — глаголы (`loadOrders()`, `submitOrder()`).
+- Следовать стилю существующих ViewModels в той же фиче.

package/presets/cursor/ios-swift/rules/swift-conventions.mdc

@@ -0,0 +1,51 @@
+---
+description: Swift language conventions and safety (preset)
+globs: "**/*.swift"
+alwaysApply: false
+---
+
+# Naming and API design
+
+- Types: `UpperCamelCase`; methods, properties, enum cases: `lowerCamelCase`.
+- Protocols, описывающие capability: `-able`, `-ing`, или `Protocol` суффикс — как в репо.
+- Избегать аббревиатур в именах, кроме общепринятых (URL, ID, HTTP).
+
+# Optionals and errors
+
+```swift
+// ❌ Плохо
+let name = user!.name
+
+// ✅ Хорошо
+guard let name = user?.name else { return }
+```
+
+- `throws` + typed errors вместо `Result` там, где так принято в слое; быть консistent внутри модуля.
+- `guard` для early exit; не вкладывать глубокие `if let` pyramids.
+
+# Concurrency
+
+- UI types — `@MainActor`.
+- Shared mutable state — `actor` или isolation через queue; document thread expectations.
+- `Task { }` в ViewModel: учитывать cancellation; `[weak self]` в escaping closures при retain cycles.
+- Prefer `async/await` over completion handlers для нового кода.
+
+# Access control
+
+- Минимально необходимый уровень: `private` / `fileprivate` по умолчанию для implementation details.
+- Public API фичи — явные types и protocols; не экспортировать DTO наружу модуля.
+
+# Value semantics
+
+- Предпочитать `struct` для models и state где нет identity semantics.
+- `class` — когда нужен identity, inheritance, или Objective-C interop.
+
+# Extensions
+
+- Группировать extensions по типу; не складывать unrelated helpers в один `Extensions.swift` без структуры.
+- Protocol extensions для shared default behavior.
+
+# Требование к агенту
+
+- Не добавлять `// swiftlint:disable` без явной причины.
+- Новый код — Swift Concurrency-ready (`Sendable` где требует компилятор/линтер проекта).

package/presets/cursor/ios-swift/rules/swiftui-ui.mdc

@@ -0,0 +1,61 @@
+---
+description: Паттерны SwiftUI, View и Design System (preset)
+globs: "**/{Presentation,DesignSystem}/**/*.swift"
+alwaysApply: false
+---
+
+# Общие правила View
+
+- **SwiftUI** — приоритет; UIKit — только по конвенции репо (wrapper, legacy).
+- View должна быть **тонкой**:
+  - отображает state из ViewModel;
+  - делегирует действия через методы/closures ViewModel;
+  - не содержит бизнес-логики, маппинга DTO, сетевых вызовов.
+- Перед новым кастомным контролом — искать компонент в `DesignSystem/` или существующих фичах.
+- Повторяемую UI-логику выносить в `ViewModifier`, `@ViewBuilder` helpers или subviews.
+
+# ViewModel и binding
+
+- ViewModel — `@MainActor`, `@Observable` (iOS 17+) или `ObservableObject` — как принято в проекте.
+- View читает state и вызывает **явные методы** ViewModel (`submit()`, `load()`), а не мутирует внутреннее состояние напрямую.
+- Для навигации — coordinator/router или enum route в ViewModel, не размазанные `NavigationLink` с бизнес-условиями в View.
+
+# Структура файлов
+
+Для экрана фичи:
+- `FeatureView.swift` — композиция subviews.
+- `FeatureViewModel.swift` — state + intents.
+- `FeatureView+Subviews.swift` — при большом дереве (опционально).
+- `FeatureRoute.swift` — навигация (если используется).
+
+Для компонента Design System:
+- Папка `ComponentName/`:
+  - `ComponentName.swift`
+  - `ComponentName+Preview.swift` (опционально)
+  - `ComponentNameStyle.swift` — стили/варианты (опционально)
+
+# Стили и Design System
+
+- Цвета, шрифты, отступы — из **токенов/Theme** проекта (`DesignSystem`, `Assets`, generated tokens).
+- Избегать:
+  - «магических» литералов (`.padding(17)`, `Color(red: 0.2, ...)`), если есть токены;
+  - дублирования стилей, уже закрытых примитивами.
+- `Preview` — для компонентов и экранов с mock ViewModel.
+
+# Accessibility
+
+- Интерактивные элементы: осмысленные `accessibilityLabel`, `accessibilityHint` где нужно.
+- Для UI-тестов — стабильные `accessibilityIdentifier` на ключевых элементах (согласовать с `tests-ui.mdc`).
+- Поддерживать Dynamic Type и контраст, не ломать layout при крупном шрифте.
+
+# Previews и локализация
+
+- Строки UI — через `String(localized:)` / `LocalizedStringKey`, не hardcoded в production без причины.
+- `#Preview` с реалистичными mock-данными; для ViewModel — stub use cases.
+
+# Требование к агенту
+
+При создании/изменении UI:
+- Следовать существующим экранам и компонентам как эталону.
+- Не импортировать Data-слой во View/ViewModel.
+- Subview выделять, когда body превышает ~40–60 строк или повторяется.

package/presets/cursor/ios-swift/rules/tests-ui.mdc

@@ -0,0 +1,41 @@
+---
+description: UI-тесты XCUITest и accessibility identifiers
+globs: "**/*UITests/**/*.swift"
+alwaysApply: false
+---
+
+# Структура UI-тестов
+
+- UI Test target: `*UITests/` — сценарии пользовательских потоков.
+- Page Object (или Screen Object) — класс на экран: селекторы + действия (`LoginScreen`, `OrderHistoryScreen`).
+- Общие хелперы — `UITestSupport/`, base classes, launch arguments.
+
+# Селекторы и стабильность
+
+- **Приоритет:** `accessibilityIdentifier` для ключевых элементов; затем label/trait где устойчиво.
+- Идентификаторы согласовать с Presentation-слоем (`swiftui-ui.mdc`): `{screen}__{element}`.
+  - Пример: `order-history__submit-button`, `login__email-field`.
+- Избегать привязки к абсолютным координатам и хрупким XPath-подобным цепочкам.
+
+# Сценарии и именование
+
+- Названия тестов — **на русском**, с префиксом сущности:
+  - `OH-001 Отображается список заказов` (префикс — первые буквы сущности, номер — три цифры).
+- Один тест — один пользовательский сценарий; не объединять несвязанные проверки.
+
+# Launch и окружение
+
+- `-UITesting`, mock server URL, сброс state — через `launchArguments` / `launchEnvironment`, как в репо.
+- Не зависеть от прод-backend в CI; использовать staging/mock.
+
+# Синхронизация с UI
+
+- При изменении UI обновлять identifiers в View и селекторы в page objects.
+- Не ослаблять assertions против бизнес-ожиданий ради «зелёного» CI.
+
+# Требование к агенту
+
+При добавлении UI-тестов:
+- Переиспользовать page objects, не дублировать query в каждом тесте.
+- Добавлять `accessibilityIdentifier` в SwiftUI через `.accessibilityIdentifier(...)` для новых интерактивных элементов.
+- Следовать существующим UITest files как эталону.

package/presets/cursor/ios-swift/rules/tests-unit.mdc

@@ -0,0 +1,41 @@
+---
+description: Unit и integration тесты (XCTest / Swift Testing)
+globs: "**/*Tests/**/*.swift"
+alwaysApply: false
+---
+
+# Общие правила тестирования
+
+- **Framework** — XCTest или Swift Testing, как в проекте.
+- Цель: проверять **поведение и бизнес-правила**, не детали реализации и private API.
+- Именование:
+  - `test` / `@Test` descriptions и `XCTContext` — **на русском**, как понятные бизнес-фразы.
+  - Описания **с заглавной буквы**.
+
+# ViewModel и use case
+
+- Mock протоколов repositories / use cases; не поднимать реальную сеть.
+- Проверять переходы state: loading → success/failure, validation errors, edge cases.
+- `@MainActor` ViewModel тестировать с `@MainActor` test methods или `await MainActor.run`.
+
+# Mappers и domain
+
+- Mapper functions — unit-тесты с таблицами кейсов: nil fields, empty arrays, граничные значения.
+- Regression на бизнес-правила (скидки, статусы, форматирование дат).
+
+# Изоляция
+
+- Не мокать то, что является предметом теста (например, сам mapper при тесте mapper).
+- Fixtures — в `TestSupport/`, `Mocks/` или рядом по конвенции репо; не дублировать большие JSON inline без нужды.
+
+# Структура файлов
+
+- `FeatureViewModelTests.swift`, `OrderMapperTests.swift` — суффикс `Tests` в имени типа/файла по стилю Xcode.
+- Не создавать глубокую вложенность `Tests/Tests/`; следовать target structure проекта.
+
+# Требование к агенту
+
+При добавлении тестов:
+- Копировать паттерны из существующих test files в репо.
+- Добавлять тесты для новых веток логики и регрессий.
+- Использовать DTO fixtures из Data layer и domain types из Domain, не дублировать типы в тестах.

package/presets/cursor/next/commands/README.md

@@ -1,51 +1,3 @@
 # Cursor commands (next preset)
 
-Slash-команды копируются в `.cursor/commands/` при `ai-rules init cursor --preset next`.
-
-## Команда агентов
-
-| Command | Назначение |
-|---------|------------|
-| **`/task <описание>`** | **Главная точка входа:** router → pipeline.json → нужные роли по порядку |
-| `/task-continue <slug>` | После human gate или паузы |
-| `/feature-start <описание>` | Legacy: только analyst (без router) |
-| `/feature-continue <slug>` | Alias task-continue |
-| `/technical-retro [slug]` | Ретро; с slug — блок «Работа агентов» |
-
-## Примеры `/task`
-
-```
-/task Добавить фильтр по дате в Order History
-→ analyst → developer → reviewer → QA
-
-/task Order History падает при пустом списке
-→ debugger → developer → reviewer → QA (regression)
-
-/task CI упал на lint в PR #142
-→ ci-investigator → developer → reviewer
-
-/task Миграция на Next.js 15
-→ analyst → migration-specialist → developer → reviewer → QA
-
-/task Проверь доступность модалки оплаты
-→ analyst → developer → a11y-reviewer → code-reviewer
-
-/task Покрой unit-тестами mapper orders
-→ unit-planner → unit-generator
-
-/task Напиши README для новой фичи фильтров
-→ analyst → tech-writer
-
-/task Сделай ревью изменений в store/orders
-→ reviewer only
-```
-
-## Связанные файлы
-
-- Subagents: `../agents/` (20 ролей, включая `task-router.md`)
-- Оркестратор: `../rules/agent-team-orchestrator.mdc`
-- Skills: `../skills/` (`feature-delivery`, `code-review`, `debug-investigation`, `ci-investigation`, `unit-testing`, `playwright-e2e`, `technical-retro`)
-- Артефакты: `../team/README.md` (`pipeline.json`, `status.json`)
-- Hooks: `../hooks.json`, `../hooks/chain-team-phases.sh`
-
-Создавать и редактировать команды можно через `/commands` в Cursor или напрямую в этой папке пресета.
+Place command definitions for this preset here. They are copied to `.cursor/commands` when you run `ai-rules init cursor --preset next`.

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

@@ -10,50 +10,3 @@
 - Cursor интерпретирует его как конфигурацию поведения ассистента для этого репо (автоматически подмешивает содержимое в контекст, когда правило подходит).
 
 - То есть .mdc = “markdown + config для Cursor”, .md = просто текст без управляющего смысла для ассистента.
-
-### С чего начать новую задачу
-
-- **Команда агентов (рекомендуется):** `/task <описание>` — router выберет роли и порядок; при human gate — `/task-continue <slug>`. См. **`agent-team-orchestrator.mdc`** и `.cursor/team/README.md`.
-- **Legacy:** `/feature-start` → `/feature-continue`.
-- **Сквозной чеклист слоёв (для developer):** **`feature-delivery-workflow.mdc`**.
-
-### Loading strategy
-
-- **`alwaysApply: true`** (Cursor) / **без `paths:`** (Claude) — только базовые инварианты:
-  - `next-app-core`, `post-change-lint`, `package-manager`, `code-quality-and-refactoring`
-- **On-demand** — `agent-team-intake` (через orchestrator/commands), `agent-team-orchestrator`, architecture, imports, UI, tests, feature-delivery-workflow, reference-features, next-app-router, react-a11y-coding
-- **Skills** — длинные процедуры (`feature-delivery`, `code-review`, …)
-
-### Эталонные фичи
-
-Заполните **`reference-features.mdc`** (TBD → реальные пути) после `init` в целевом репо.
-
-### Каталог ключевых правил
-
-| Файл | Назначение |
-|------|------------|
-| `reference-features.mdc` | Эталонные пути UI/store/API/types/tests |
-| `next-app-router.mdc` | App Router, RSC, loading/error |
-| `react-a11y-coding.mdc` | A11y при написании UI |
-| `feature-delivery-workflow.mdc` | Сквозной чеклист (on-demand, не always-on) |
-| `agent-team-intake.mdc` | Подсказка `/task` при work-запросе (on-demand, через orchestrator) |
-| `package-manager.mdc` | Перед `install` / `run` в терминале определить менеджер пакетов репо (lockfile, `packageManager`) и использовать только его |
-| `agent-team-orchestrator.mdc` | `/task`, router, `pipeline.json`, build-verifier, parallel steps |
-| `next-app-core.mdc` | Стек, слои, карта каталогов (alwaysApply) |
-| `post-change-lint.mdc` | **Обязательный** прогон ESLint + Stylelint после любых изменений кода |
-| `architecture-boundaries.mdc` | Границы UI / store / API, импорты (`@/types`, `@/api`), порты‑адаптеры, фича как срез |
-| `http-client.mdc` | Один HTTP‑стек, контракты из `@/types`, без разбросанного низкоуровневого API |
-| `api-services.mdc` | Сервисы, мапперы, вызовы через прикладные API‑клиенты |
-| `store-rtk.mdc` | Redux Toolkit, thunk’и, типизация ошибок/ответов как в коде репо |
-| `public-imports.mdc` | Импорты `@/types`, `@/types/enums`, `@/api` (вне `app/src/api/**`); stubs: `types-public-imports.mdc`, `api-public-imports.mdc` |
-| `layer-barrel-exports.mdc` | Двухуровневые barrel для слоёв с public API (`@/api`, `@/types`, `@/core`, …) |
-| `types-jsdoc.mdc` | JSDoc для типов в `app/src/types` (русский текст, `[computed]`, без `@param`/`@returns`) |
-| `no-type-assertion-as-import-export.mdc` | Ограничение `as`, в т.ч. `instanceof` для ошибок транспорта в `catch` |
-| `code-review-mr.mdc` | Чеклист ревью MR, в т.ч. HTTP‑клиент и тесты |
-| `tests-unit.mdc` | Unit‑тесты и behavior‑тесты HTTP‑клиента |
-| `playwright-agents.mdc`, `tests-e2e-structure.mdc` | E2E |
-| `react-ui.mdc` | React/Next UI: структура компонентов, соседние `ComponentName.data.ts` / `.utils.ts`, стили, пропсы |
-
-**Коллизии формулировок:** импорт типов и API — источник правды **`public-imports.mdc`**; дублирует ESLint `no-restricted-imports` в `app/eslint.config.mjs`.
-
-Задачи на **сеть, замену HTTP‑библиотеки, новые эндпоинты**: опираться на **`http-client.mdc`** + **`api-services.mdc`** + **`store-rtk.mdc`**.

package/presets/cursor/next/rules/api-services.mdc

@@ -1,41 +1,40 @@
 ---
 description: Конвенции API сервисов и мапперов
-globs: app/src/api/services/**/*.ts
+globs: src/api/services/**/*.ts
 alwaysApply: false
 ---
 
 # Роль API слоя
 
 - Инкапсулировать всё, что связано с:
-  - HTTP‑запросами через **экземпляры прикладных API‑клиентов** в `app/src/api/clients/**`, собранные на **общей реализации** из `app/src/lib/clients/**` (как в существующем коде); подробности — **`http-client.mdc`**; положение слоя в схеме **порты и адаптеры** — `architecture-boundaries.mdc`;
+  - HTTP‑запросами (через принятый в проекте клиент),
   - URL/путями,
   - заголовками и кодами ответов,
   - DTO backend.
 - Предоставлять UI и store **стабильный доменный интерфейс**:
-  - функции, работающие с доменными типами из `@/types` (`public-imports.mdc`).
+  - функции, работающие с доменными типами из `@/types/**`.
   - мапперы между DTO и доменными типами.
 
 # Структура модулей
 
 - Для каждой доменной области (например, заказы, биллинг, настройки аккаунта):
-  - отдельный каталог в `app/src/api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
+  - отдельный каталог в `src/api/services/<ИмяСервиса или фичи>/**` по конвенции репозитория.
 - Внутри модуля:
   - файлы с вызовами 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'`, **`public-imports.mdc`**).
+  - специфичные типы запросов/ответов (если не вынесены в `@/types/**`).
+  - один или несколько **public API** файлов (`index.ts` или barrel‑файлы), через которые к модулю обращаются UI, store и другие слои.
 
 # Мапперы и типы
 
 - Для каждого запроса/эндпоинта:
   - описывать **response‑тип (DTO)**, точно соответствующий контракту backend;
-  - определять **целевой доменный тип** в `app/src/types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
+  - определять **целевой доменный тип** в `src/types/**`, с которым будет работать приложение (включая вычисляемые/агрегированные поля).
 - Мапперы (например, `*responseMappers.ts`):
   - чистые функции, без сайд‑эффектов;
   - выполняют все необходимые вычисления и преобразования данных (булевы флаги, склейка строк, агрегаты и т.п.) при переводе из DTO в доменные модели;
   - при необходимости обеспечивают обратное преобразование (доменные модели -> транспортные типы).
-- UI и store работают только с доменными типами (из `@/types` или экспортируемыми из public API слоя API), а не с "сырыми" DTO.
-- **Не вызывать `fetch` напрямую** в теле API‑методов: только через клиент; исключения — узкие модули (например JSON‑RPC), если так уже устроено в репозитории.
+- UI и store работают только с доменными типами (из `@/types/**` или экспортируемыми из API слоя), а не с "сырыми" DTO.
 
 # Обработка ошибок
 
@@ -50,9 +49,8 @@ alwaysApply: false
 
 При добавлении/изменении API‑метода:
 - Следовать существующим сервисам и мапперам как эталону.
-- Пройти чеклист barrel-экспортов (**`layer-barrel-exports.mdc`**): локальный `index.ts` → фасад слоя → корневой barrel.
 - Не смешивать слой API и UI/store:
   - компоненты не должны зависеть от DTO;
-  - store не должен сам собирать URL/коды эндпоинтов и не обходить сервисы; **транспортный тип ответа** и **контракт ошибки** из `@/types` (как у прикладного клиента) допустимы во thunk при разборе `catch`/payload, если так выстроен сервис (см. `store-rtk.mdc`, `http-client.mdc`).
-- При использовании API‑сервисов в UI, store и утилитах **вне** `app/src/api/**` импортировать **только** из `@/api` (корневой barrel), см. **`public-imports.mdc`**; внутри слоя API — по относительным путям или `@/api/services/**` / `@/api/clients/**`, не дублируя публичный контракт мимо корневого barrel для внешних потребителей.
+  - store не должен знать о HTTP‑деталях (URL, коды).
+- При использовании API‑сервисов в UI, store и утилитах импортировать только из public API файлов модуля (например, `@/api/services/OrdersApi/.../index`), а не из внутренних файлов‑реализаций.