@michaelbel/cuckcoder-mcp 1.6.11

package/assets/rules/mvi-state.md

@@ -0,0 +1,31 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила Model в MVI
+
+- Для данных, поддерживаемых Room, храни и передавай класс `Entity` из Room напрямую в классах
+  `Model` фичи и composable-компонентах; не маппи его в UI-модель или другой промежуточный класс.
+- В классах `Model` фичи называй свойства Room entity по форме entity: используй `...Entity` для
+  одной entity и `...Entities` для списка entity.
+- В классах `Model` MVI объявляй свойства, полностью производные от других свойств модели, с явным
+  типом и кастомным геттером на следующей строке с отступом; не инициализируй и не храни производное
+  значение в объявлении свойства.
+- Для моделей экрана, поддерживаемых локальными коллекциями, избегай хранения или обновления
+  `isLoading`, когда загрузку можно вывести из состояния коллекции; считай экран загружающимся,
+  когда поддерживающая коллекция пуста.
+- Не храни изменяемое булево состояние загрузки для сетевых запросов; храни nullable `Job` для
+  каждого запроса в `Model` и предоставляй загрузку как вычисляемое свойство, например
+  `val isLoading: Boolean get() = requestJob?.isActive == true`.
+- При запуске сетевого запроса из ViewModel присваивай запущенный `Job` в `Model`, используй
+  `invokeOnCompletion`, чтобы сбросить этот job в `null`, и не устанавливай загрузку через булевы
+  обновления в `try/finally`.
+- Для данных экрана, поддерживаемых Room и обновляемых из сети, используй отдельные intent-ы
+  `Collect...` и `Load...`: `Collect...` читает данные из Room, `Load...` выполняет сетевой запрос и
+  сохраняет результат в Room.
+- При сборе данных entity из Room через `FlowUseCase` называй параметр лямбды `collectLatest` как
+  `entity` для одной entity или `entities` для списка entity.

package/assets/rules/mvi.md

@@ -0,0 +1,39 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила MVI
+
+- Экраны фич находятся в `features/{feature}` и разбиты на `{Feature}Screen.kt`,
+  `{Feature}ViewModel.kt`, `model/{Feature}Model.kt`, `intent/{Feature}Intent.kt`, опционально
+  `event/{Feature}Event.kt` и опционально `navigation/{Feature}Route.kt`.
+- При создании нового экрана сразу создавай его файлы `{Feature}ViewModel.kt`,
+  `model/{Feature}Model.kt` и `intent/{Feature}Intent.kt`, даже если начальное состояние экрана и
+  intent-ы минимальны; не создавай отдельные composable-экраны без соответствующих MVI-классов.
+- Классы `ViewModel` используют `@HiltViewModel`, инъекцию через конструктор и наследуются от общего
+  базового MVI ViewModel проекта.
+- Не размещай константы или функции-расширения в файлах/классах MVI `ViewModel`, `Screen`, `Intent`,
+  `Model`, `Event` или `Route`; переноси их в отдельные не-MVI файлы/пакеты.
+- Не размещай вспомогательные классы внутри MVI-классов; объявляй их на уровне файла или в отдельных
+  файлах/пакетах.
+- Не создавай и не храни изменяемые переменные в классах ViewModel; храни UI-состояние в классах
+  Model. Допускается публичный immutable `Flow<PagingData<T>>`, собранный из параметров Model и
+  закэшированный в lifecycle ViewModel; не дублируй его элементы или load state в Model.
+- Размещай бизнес-логику, ветвление и решения экрана внутри соответствующей ветки intent в
+  `dispatch`; composable-экраны и компоненты должны получать уже подготовленное UI-состояние и
+  только диспатчить intent-ы.
+- Класс `ViewModel` может объявлять только функции `dispatch` и `catch`; не объявляй в нём приватные
+  или публичные вспомогательные функции. Встраивай вычисления и преобразования в соответствующую
+  ветку `dispatch` либо выноси их из ViewModel в соответствующий архитектурный слой.
+- `dispatch` — это `when` по всем веткам intent без `else`; состояние меняется только через
+  `reduce { it.copy(...) }`.
+- Одноразовые действия используют `send({Feature}Event...)` из ViewModel и `ObserveAsEvents` на
+  экране.
+- Типы `Intent`, `Model` и `Event` реализуют общие маркерные интерфейсы MVI проекта.
+- ViewModel-и внедряют конкретные классы `UseCase` / `FlowUseCase`.
+- Вызывай одноразовые use case внутри `launch { ... }` с `.getOrThrow()` и обрабатывай выброшенные
+  исключения в функции `catch` ViewModel.

package/assets/rules/navigation.md

@@ -0,0 +1,20 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила навигации
+
+- Каждый маршрут экрана — это `@Serializable data class` или `@Serializable data object`,
+  реализующий `NavKey`.
+- Маршруты находятся в `features/{feature}/navigation`.
+- Используй `data object {Feature}Route: NavKey` для экранов без аргументов.
+- Используй `data class {Feature}Route(...): NavKey` для экранов с аргументами.
+- ViewModel-и получают аргументы маршрута через `savedStateHandle.toRoute<{Feature}Route>()`.
+- Регистрируй маршруты в навигационной обёртке отображения проекта через
+  `entry<{Feature}Route> { {Feature}Screen(it) }`, когда у маршрута есть аргументы, или
+  `entry<{Feature}Route> { {Feature}Screen() }`, когда их нет.
+- Для навигации назад используй отдельный `@Serializable data object BackRoute: NavKey`.

package/assets/rules/network.md

@@ -0,0 +1,36 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила сети
+
+- Имена классов моделей запросов должны заканчиваться на `Request`.
+- Имена классов моделей ответов должны заканчиваться на `Response`.
+- Каждая модель запроса и ответа должна быть аннотирована `@Serializable`, а каждое поле должно
+  иметь аннотацию `@SerialName`.
+- Называй сетевые use case по пути сетевого запроса или методу сетевого сервиса в PascalCase плюс
+  `UseCase`; например, `ktorHttpClient.get("items/details")` должен быть `ItemsDetailsUseCase`, а
+  `networkService.catalogBrandsFavorites(...)` — `CatalogBrandsFavoritesUseCase`. Не используй имена
+  в стиле intent, такие как `Load...UseCase`, для прямых синхронных сетевых вызовов.
+- Называй кастомные сетевые исключения по тому же пути запроса или методу сетевого сервиса в
+  PascalCase плюс `Exception`; например, `ktorHttpClient.get("items/details")` должен использовать
+  `ItemsDetailsException`, а `networkService.catalogBrandsFavorites(...)` —
+  `CatalogBrandsFavoritesException`.
+- Объявляй кастомные типы `data class` сетевых исключений внутри сетевого use case, который их
+  выбрасывает.
+- В сетевых use case создавай `val request = ...` внутри лямбды `request = { ... }` непосредственно
+  перед вызовом `networkService`; никогда не создавай запрос вне этой лямбды и не встраивай его
+  создание в аргументы `networkService`.
+- Используй `handleResponse` для сетевых вызовов, обрабатываемых через callback, и
+  `handleResponseResult(...).getOrThrow()`, когда сетевой ответ нужно потребить как значение внутри
+  `execute`; если failure нужно преобразовать в endpoint-specific exception, используй
+  `getOrElse`, пробрось `CancellationException` и выбрось конкретное исключение. Не оборачивай
+  результаты use case вручную в `Result.success` / `Result.failure`.
+- При вызове `handleResponse` всегда передавай все три именованных аргумента: `request`, `onSuccess`
+  и `onFailure`; в `onFailure` создавай отдельный `data class`-исключение, наследующее базовое
+  сетевое исключение проекта, и выбрасывай его; перехватывай этот конкретный тип исключения в
+  функции `catch` ViewModel.

package/assets/rules/preview.md

@@ -0,0 +1,31 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила Preview
+
+- Всегда аннотируй previews через `@PreviewWrapper(ThemeWrapper::class)`.
+- Preview должны вызывать приватный composable `*Content`, а не публичный composable `*Screen`,
+  принимающий ViewModel.
+- Composable-компоненты должны иметь только одну функцию preview; все варианты preview представляй
+  через `PreviewParameterProvider`.
+- Когда у компонента или экрана есть несколько значимых визуальных состояний, используй
+  `PreviewParameterProvider` и одну функцию preview с `@PreviewParameter`; не пиши несколько
+  отдельных функций preview для разных состояний.
+- Когда компонент использует `{Component}State` data class, потому что у него больше одного поля,
+  всегда создавай соответствующий приватный `PreviewParameterProvider` для этого состояния в том же
+  файле.
+- Когда компонент условно рендерит части своего UI на основе вычисляемых свойств `{Component}State`,
+  соответствующий `PreviewParameterProvider` должен включать одно значение на каждую значимую
+  комбинацию видимости, чтобы каждая условная ветка была представлена в preview, а не только
+  состояние по умолчанию/первое.
+- Используй `BooleanProvider` для preview с булевыми параметрами.
+- Классы `PreviewParameterProvider` приватные и объявляются в конце файла.
+- Строй значения preview и `PreviewParameterProvider` через `Empty.copy(...)`, когда модель
+  предоставляет экземпляр `Empty`; не создавай их полным явным вызовом конструктора.
+- В вызовах `Empty.copy(...)` для preview устанавливай только те поля, которые компонент
+  действительно читает/рендерит; не добавляй несвязанные поля «для реалистичности».

package/assets/rules/realtime.md

@@ -0,0 +1,39 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила realtime-соединений
+
+- Создавай отдельный `RealtimeDataSource` для каждого hub/канала предметной области. Общие
+  создание соединения, аутентификацию, retry/backoff, логирование и закрытие держи в общей
+  инфраструктуре соединения.
+- Регистрируй обработчики входящих событий до запуска соединения и команды начальной подписки —
+  только после успешного подключения.
+- Публикуй conflatable invalidation-сигналы через приватный `MutableSharedFlow` и публичный
+  `SharedFlow`: потеря нескольких одинаковых сигналов допустима только когда следующий reload
+  получает полное authoritative state. Для каждого обязательного payload-события используй
+  lossless `Channel`/очередь либо сразу durable Room-запись; не полагайся на `SharedFlow(replay = 0)`
+  при отсутствии или отставании подписчика.
+- Считай realtime-событие сигналом обновить источник истины: вызывай обычный use case, который
+  обновляет Room, а UI продолжает наблюдать Room. Передавай payload напрямую в UI только для
+  действительно эфемерных событий, которым не требуется согласованное сохранённое состояние.
+- Владение жизненным циклом всех realtime-каналов держи в одном `StartRealtimeUseCase` или
+  эквивалентном session-scoped use case. DataSource отдельного hub не должен самостоятельно владеть
+  сессией приложения.
+- Активируй collectors событий до запуска соединения и initial subscription. Используй принятый в
+  проекте undispatched-start либо выполни гарантированный initial reload после подключения, чтобы
+  не потерять первое событие из `onConnected`.
+- Перезапускай набор соединений при смене авторизованной сессии через отменяемый поток наподобие
+  `collectLatest`; после logout закрывай соединения и не продолжай retry со старым токеном.
+- Retry-цикл действует только пока активна текущая сессия. Не перехватывай `CancellationException`,
+  а прочие ошибки логируй без токенов и персональных payload и повторяй с ограниченной задержкой или
+  backoff согласно инфраструктуре проекта.
+- Создавай новое соединение на новую попытку, если клиент нельзя безопасно перезапустить. Всегда
+  снимай обработчики и закрывай соединение в `finally`; cleanup выполняй в `NonCancellable` с
+  ограниченным timeout, чтобы остановка сессии не зависла.
+- Не запускай несколько конкурирующих соединений одного hub для одной сессии, если это не является
+  явным требованием продукта.

package/assets/rules/resource.md

@@ -0,0 +1,18 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила ресурсов
+
+- Строки UI используются через фасад строк проекта, а не через прямое использование `R.string` или
+  `R.plurals` в UI-коде.
+- Не хардкодь пользовательские строки напрямую в Kotlin или XML UI-коде; добавляй их в `strings.xml`
+  и используй через фасад строк проекта.
+- При добавлении строкового ресурса добавляй его в `strings.xml` и предоставляй доступ через фасад
+  строк проекта.
+- Для UI-текста в верхнем регистре добавляй отдельный ресурс в верхнем регистре и запись в фасаде
+  строк; не вызывай `uppercase()` или `uppercase(Locale...)` в UI, модели или коде маппера.

package/assets/rules/room.md

@@ -0,0 +1,33 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила Room
+
+- В интерфейсах DAO размещай все обычные методы `fun` перед любыми методами `suspend fun`.
+- При изменении таблиц или entity базы данных Room всегда увеличивай `AppDatabase.DATABASE_VERSION`.
+- Для entity Room объявляй первичные ключи в параметре `@Entity(primaryKeys = [...])` вместо
+  использования `@PrimaryKey` на свойстве.
+- В интерфейсах `@Dao` помечай методы, возвращающие типы Pojo, аннотацией `@Transaction`, чтобы
+  обеспечить согласованное чтение из нескольких таблиц.
+- Используй `AppDatabase.withTransaction` только когда блок транзакции содержит два и более вызова
+  методов DAO/базы данных; не оборачивай один вызов метода в `withTransaction`.
+- Для чтения одной строки Room предоставляй как nullable `select`, так и non-null `selectNotNull`
+  форматы, когда оба варианта использования существуют:
+  ```kotlin
+  @Query("SELECT * FROM EntityTable WHERE id = :id LIMIT 1")
+  suspend fun select(id: Int): Entity?
+
+  @Query("SELECT * FROM EntityTable WHERE id = :id LIMIT 1")
+  suspend fun selectNotNull(id: Int): Entity
+  ```
+- Используй `select`, когда строка может отсутствовать; используй `selectNotNull` только когда
+  вызывающий код точно знает, что значение существует в базе данных.
+- Не пиши методы DAO с `@Transaction`, которые оркестрируют несколько других методов DAO, например
+  метод `replace`, вызывающий `delete()`, а затем `upsert(entity)`; держи методы DAO как отдельные
+  декларативные операции `@Query`/`@Insert`/`@Upsert`/`@Delete` и комбинируй несколько вызовов DAO
+  через `AppDatabase.withTransaction` на уровне use case.

package/assets/rules/scaffold.md

@@ -0,0 +1,25 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила Scaffold
+
+- Snackbar для обычных сообщений размещай внутри `snackbarHost` в `Scaffold`; snackbar, которые
+  должны появляться над статус-баром (верхние баннеры ошибок), размещай вне `Scaffold` в
+  оборачивающем `Box`, выровненном по `Alignment.TopCenter`, с `Modifier.statusBarsPadding()`.
+- Рендери содержимое обычного snackbar через `SnackbarMessage`; содержимое snackbar ошибки — через
+  `SnackbarErrorMessage`.
+- Когда два snackbar сосуществуют внутри `snackbarHost`, оборачивай их в `Box` и используй отдельные
+  экземпляры `SnackbarHostState` с разными значениями `containerColor`.
+- FAB всегда использует `floatingActionButtonPosition = FabPosition.Center`; применяй горизонтальный
+  padding через `Modifier.padding(horizontal = 16.dp)` на самой кнопке.
+- Когда экрану нужна статичная кнопка действия, закреплённая внизу, размещай её в слоте
+  `floatingActionButton` в `Scaffold`, а не в `bottomBar`.
+- Закрывай текущий snackbar перед показом нового: вызывай `hostState.currentSnackbarData?.dismiss()`
+  перед `scope.launch { hostState.showSnackbar(...) }`.
+- Всегда оборачивай `Scaffold` в многострочно оформленный `Box` с
+  `modifier = Modifier.fillMaxSize()`, когда верхний snackbar нужно разместить вне scaffold.

package/assets/rules/shimmer.md

@@ -0,0 +1,34 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила Shimmer / Loading Placeholder
+
+- Используй
+  `Modifier.placeholder(visible = ..., highlight = PlaceholderHighlight.shimmer(), color = MaterialTheme.colorScheme.surfaceContainerHigh, shape = RoundedCornerShape(...))`
+  для skeleton-загрузки.
+- Используй `Spacer` для отдельного placeholder без дочернего содержимого; не используй пустой `Box`
+  только для рендеринга placeholder. Используй `Box` только когда placeholder также должен служить
+  контейнером для дочерних composable.
+- Всегда передавай `visible = state.isLoading` (или соответствующий boolean) — не хардкодь
+  `visible = true`, кроме как внутри выделенных loading-composable.
+- Используй `MaterialTheme.colorScheme.surfaceContainerHigh` как цвет placeholder; не используй
+  сырые константы `Color`.
+- Для кнопки действия или кнопки в слоте `floatingActionButton` держи реальную кнопку в composition
+  во время загрузки и применяй
+  `Modifier.placeholder(visible = state.isLoading, highlight = PlaceholderHighlight.shimmer(), color = MaterialTheme.colorScheme.surfaceVariant, shape = RoundedCornerShape(...))`
+  прямо к её modifier; не заменяй кнопку условным placeholder `Spacer`.
+- Согласуй `shape` placeholder с формой реального содержимого, которое он представляет (например,
+  `RoundedCornerShape(16.dp)` для карточек, `RoundedCornerShape(8.dp)` для меньших элементов).
+- Для полноэкранных или секционных состояний загрузки создавай выделенный loading-composable
+  (например, `PageLoading`, `SectionLoading`), использующий `SharedLazyColumn` с
+  `userScrollEnabled = false` и элементы `Spacer`, оформленные через
+  `.placeholder(visible = true, ...)`.
+- В выделенных loading-composable `visible` всегда `true`; вызывающий код решает, когда показывать
+  composable.
+- Импортируй `PlaceholderHighlight` и `placeholder`/`shimmer` из общего UI-модуля проекта, а не
+  напрямую из сторонней библиотеки.

package/assets/rules/textfield.md

@@ -0,0 +1,31 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила TextField
+
+- Для `TextField`, являющихся полями поиска, храни значение как `TextFieldValue`, а не как `String`,
+  и всегда явно устанавливай `selection`, чтобы курсор находился в конце текста, а не в начале:
+  ```kotlin
+  var textFieldValue by remember {
+      mutableStateOf(
+          TextFieldValue(
+              text = state.query,
+              selection = TextRange(index = state.query.length)
+          )
+      )
+  }
+  ```
+- При программном обновлении текста поля поиска (например, из state после ответа сервера или сброса
+  фильтра) пересоздавай `TextFieldValue` с `selection = TextRange(index = newText.length)`, чтобы
+  курсор не сбрасывался в начало строки.
+- Когда на экране несколько `TextField` расположены последовательно друг за другом, у всех полей,
+  кроме последнего, устанавливай `keyboardOptions = KeyboardOptions(imeAction = ImeAction.Next)` и
+  переводи фокус на следующее поле через `keyboardActions = KeyboardActions(onNext = { focusManager.moveFocus(FocusDirection.Next) })`.
+- У последнего `TextField` в такой последовательности устанавливай
+  `keyboardOptions = KeyboardOptions(imeAction = ImeAction.Done)` и скрывай клавиатуру через
+  `keyboardActions = KeyboardActions(onDone = { focusManager.clearFocus() })`.

package/assets/rules/typography.md

@@ -0,0 +1,32 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила типографики
+
+- Всегда устанавливай стиль текста через аргумент `style` в `Text` или `SharedFixedText`; никогда
+  не используй отдельные аргументы `fontSize`, `fontWeight` или `color`.
+- Используй расширения `MaterialTheme.typography.<token>` как базовый стиль, затем применяй
+  переопределения через
+  `.copy(color = ..., lineHeight = ..., letterSpacing = ..., textAlign = ...)`.
+- В `Text` держи визуальные поля стиля текста внутри `style`: `color`, `lineHeight`, `letterSpacing`
+  и `textAlign`; не передавай их как отдельные аргументы `Text`.
+- Не выделяй `MaterialTheme.typography...copy(...)` в локальные переменные вроде
+  `val fieldTextStyle`; передавай выражение стиля напрямую в composable, даже если оно дублирует
+  соседний код стиля.
+- Не создавай `TextStyle(...)` напрямую внутри composable; всегда начинай с токена
+  `MaterialTheme.typography`.
+- Доступные токены следуют паттерну `regular<size>` (насыщенность 400) и `medium<size>`
+  (насыщенность 500): `regular12`, `regular14`, `regular15`, `regular16`, `regular18`, `regular22`,
+  `medium11`, `medium12`, `medium14`, `medium16`, `medium17`, `medium22`. Используй токен, размер и
+  насыщенность которого соответствуют дизайну; не создавай ad-hoc экземпляры `TextStyle`,
+  приближающие существующий токен.
+- Для `textAlign` передавай его внутри `.copy(textAlign = ...)` на стиле, а не как отдельный
+  аргумент `textAlign` в `Text`.
+- Для span-ов `AnnotatedString` используй `MaterialTheme.typography.spanRegular14` или
+  `spanMedium14` как базу `SpanStyle`.
+- Не хардкодь цвета внутри `TextStyle`; всегда ссылайся на `MaterialTheme.colorScheme.*`.

package/assets/rules/usecase.md

@@ -0,0 +1,60 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила UseCase
+
+- Размещай операции Room, Ktor, DataStore и бизнес-операции в конкретных классах `UseCase` /
+  `FlowUseCase` в `shared/domain/usecase`; не создавай слои Repository или Interactor для новой
+  работы.
+- Используй `UseCase<P, R>` для одноразовых suspend-операций и `FlowUseCase<P, R>` для наблюдаемых
+  потоков.
+- Внедряй конкретные зависимости данных напрямую в конструктор use case: `NetworkService`,
+  `AppDatabase`, классы DAO, классы DataStore, хелперы аналитики или другие use case при композиции
+  операций.
+- Внедряй `SharedDispatchers` как не-`private` параметр конструктора и передавай `dispatchers.io`
+  для работы с Room/Ktor или `dispatchers.immediate` только для лёгкой по CPU немедленной работы.
+- Не оборачивай `execute` в `withContext` или `flowOn`; базовый класс `UseCase` / `FlowUseCase` сам
+  отвечает за переключение диспетчеров.
+- `UseCase.execute` возвращает сырой domain-результат `R` и выбрасывает domain-специфичные
+  исключения при ошибках; он не должен возвращать `Result`, `Result.success` или `Result.failure`.
+- Вызывай другие экземпляры `UseCase` из `execute` с `.getOrThrow()`, чтобы ошибки распространялись
+  в результат родительского `UseCase`.
+- Вызывай экземпляры `UseCase` из ViewModel внутри `launch { ... }` и завершай каждый вызов через
+  `.getOrThrow()`; обрабатывай выброшенные domain-, Room- и сетевые исключения в функции `catch`
+  ViewModel.
+- `FlowUseCase.execute` напрямую возвращает `Flow<R>`, не является `suspend` и не должен оборачивать
+  значения в `Result`.
+- Называй классы `FlowUseCase` по типу значения, которое они возвращают, плюс `FlowUseCase`;
+  например, `Flow<List<ItemEntity>>` должен быть `ItemEntitiesFlowUseCase`, а `Flow<ItemEntity>` —
+  `ItemEntityFlowUseCase`.
+- При отсутствии входных параметров используй `Unit` как тип параметра и оставляй
+  `execute(params: Unit)`.
+- Для ровно одного входного параметра используй domain-тип как `P`, переименуй override-параметр в
+  семантическое имя и добавь `@file:Suppress("PARAMETER_NAME_CHANGED_ON_OVERRIDE")`; не создавай
+  `Params` data class с одним полем, даже если поле nullable или имеет значение по умолчанию.
+- Для двух и более входных параметров определяй вложенный `data class Params(...)` внутри use case и
+  используй `UseCase<FeatureUseCase.Params, R>` или `FlowUseCase<FeatureFlowUseCase.Params, R>`; не
+  используй `Pair`, `Triple`, map-ы или несколько аргументов `invoke`.
+- Если у use case есть вложенный класс `Params`, импортируй его напрямую
+  (`import package.SomeUseCase.Params`) и используй только короткое имя в generic-сигнатуре:
+  `UseCase<Params, Result>` или `FlowUseCase<Params, Result>`; не используй квалифицированную форму
+  `SomeUseCase.Params`.
+- Если у use case есть вложенный выходной/результирующий data class (например,
+  `data class PaymentData` внутри `PaymentDataFlowUseCase`), импортируй его напрямую
+  (`import package.SomeUseCase.PaymentData`) и используй только короткое имя везде, включая
+  generic-сигнатуру: `FlowUseCase<Params, PaymentData>`; не используй квалифицированную форму
+  `SomeUseCase.PaymentData`.
+- Обычный `FlowUseCase`, наблюдающий Room, должен оборачивать один flow-метод DAO; если разным
+  фильтрам нужны разные flow-методы DAO, создавай отдельные классы вместо ветвления внутри одного
+  use case. Paging-`FlowUseCase` может строить `Pager(...).flow` из `PagingSource` и опционального
+  `RemoteMediator`; не применяй к нему ограничение одного DAO Flow.
+- Новые use case — это конкретные классы с `@Inject constructor`, и обычно им не нужны модули Hilt
+  `@Binds`.
+- Константы, относящиеся к логике конкретного use case (лимиты, ключи, таймауты, пути и т. п.),
+  размещай в `companion object` этого use case; не выноси их в отдельные config-файлы или
+  общие файлы констант, если они используются только этим use case.

package/assets/rules/workflow.md

@@ -0,0 +1,17 @@
+# Правила рабочего процесса
+
+- Используй стандартные соглашения проекта и следуй существующей документации при внесении
+  изменений.
+- Не бойся дублирования: дублирование предпочтительнее преждевременных абстракций, вспомогательных
+  переменных, вспомогательных функций или общих моделей, которые лишь устраняют небольшой
+  повторяющийся код.
+- Реализацию пишет профильный саб-агент, а не главная сессия. По умолчанию делегируй: закрытие одной
+  задачи трекера, багфикс с тестом, многофайловую правку — отдавай профильному агенту (kotlin-engineer,
+  compose-builder и т.д.). Главная сессия ставит задачу, фиксирует критерий готовности и принимает
+  результат, а не пишет реализацию сама.
+- Крупные многошаговые задачи (затрагивающие много файлов, требующие многократных прогонов
+  сборки/тестов или способные оставить рабочее дерево в нерабочем состоянии при сбое) выполняй через
+  фонового агента в изолированном git worktree, а не напрямую в основной рабочей директории.
+- После завершения такого фонового агента переноси его изменения из worktree в основную рабочую
+  директорию как незакоммиченные изменения, без автоматического коммита, и перепроверяй их
+  (валидация, тесты, сборка) уже в основной директории перед тем как предлагать коммит.

package/assets/rules/workmanager.md

@@ -0,0 +1,44 @@
+---
+paths:
+  - "**/*.gradle.kts"
+  - "**/*.gradle"
+  - "**/AndroidManifest.xml"
+  - "**/*.kt"
+---
+
+# Правила WorkManager
+
+- Реализуй фоновую задачу как тонкий `CoroutineWorker`: worker читает и проверяет входные данные,
+  вызывает существующий бизнес-`UseCase` через `.getOrThrow()` и преобразует итог в
+  `Result.success()`, `Result.retry()` или `Result.failure()`. Для чисто Android-системной операции,
+  например показа локального уведомления, worker может вызвать системный API напрямую, но не должен
+  содержать бизнес-решения фичи.
+- Планирование и отмену работы размещай в отдельных `UseCase` в `shared/domain/usecase`; не
+  запускай новую работу из `companion object` worker и не передавай `WorkManager` во ViewModel.
+- Для внедрения зависимостей следуй существующей Hilt-конвенции проекта: используй `@HiltWorker` и
+  `@AssistedInject`, когда настроен `HiltWorkerFactory`, либо существующий Hilt `EntryPoint`, когда
+  проект получает зависимости worker таким способом. Не создавай параллельную фабрику.
+- Выбирай `enqueueUniqueWork` / `enqueueUniquePeriodicWork`, только если задача имеет естественный
+  стабильный identity. Имя unique work и теги должны быть стабильными; выбирай
+  `ExistingWorkPolicy` или `ExistingPeriodicWorkPolicy` по продуктовой семантике сохранения, замены
+  или продолжения существующей работы, а не по удобству реализации.
+- Передавай через `Data` только небольшой набор примитивов и строк. Храни крупный payload и
+  состояние повторяемой операции в Room, а в worker передавай стабильный идентификатор записи.
+- Объявляй только необходимые `Constraints`. Не требуй сеть для локальной работы и не добавляй
+  initial delay, backoff или periodic execution без требования сценария.
+- Настраивай backoff для действительно повторяемых ошибок. Ограничивай собственные retry по
+  `runAttemptCount`, если бесконечные повторы не являются явной частью продукта.
+- Возвращай `success` после завершённой или идемпотентно уже выполненной операции, `retry` только для
+  временной ошибки, а `failure` — для некорректного input и постоянной ошибки. Не превращай любую
+  ошибку в `retry`.
+- Никогда не поглощай `CancellationException` и не преобразуй отмену worker в `retry` или
+  `failure`; освобождай ресурсы и пробрасывай отмену дальше.
+- Делай повторяемую операцию идемпотентной или защищай её серверным/локальным operation id, потому
+  что WorkManager гарантирует выполнение, но не exactly-once семантику бизнес-операции.
+- Для отмены используй тот же unique work name или стабильный tag/id, который задаёт scheduling
+  use case. Не дублируй строковые ключи между worker и use case: держи относящиеся к задаче
+  константы рядом с владельцем scheduling-контракта.
+- Для account/session-scoped работы включай identity владельца или generation сессии в unique work
+  и input. Отмена при logout является best effort: worker обязан повторно проверить актуальную
+  сессию перед сетевым вызовом и перед записью результата в Room, чтобы старая работа не записала
+  данные после logout или смены пользователя.

package/assets/skills/create-data-layer/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: create-data-layer
+description: >-
+  Use when пользователь просит собрать или расширить составной поток данных фичи между Ktor, Room,
+  мапперами, use case, realtime или WorkManager — например "wire up API and Room", "add a data
+  layer", "reload persisted data from a socket event" или "sync in background". Выбирает
+  минимальный поток и маршрутизирует работу к специализированным skills. Не используй для одного
+  уже определённого endpoint, DAO/entity, mapper, use case, worker или realtime-канала; используй
+  соответствующий атомарный skill напрямую. Не используй для Screen/ViewModel.
+metadata:
+  author: michaelbel
+---
+
+# Составной поток данных
+
+Собери только те части data/domain-потока, которые нужны пользовательскому сценарию. Этот skill
+координирует специализированные skills и не дублирует их шаблоны.
+
+## Сначала определи границы
+
+1. Изучи аналогичные потоки и существующие типы в целевом проекте.
+2. Зафиксируй источник истины: ответ текущей операции, Room или другой уже существующий store.
+3. Определи, что запускает обновление: UI, realtime-событие или WorkManager.
+4. Отметь уже реализованные части и не пересоздавай их.
+5. Выбери минимальный поток из таблицы ниже. Если сценарий гибридный, объедини только необходимые
+   строки.
+
+| Сценарий                     | Подключаемые skills                                                                                                                                | Результат                                                                                                    |
+| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
+| Ktor-only                    | `create-ktor-endpoint`, затем обязательный `create-usecase`                                                                                        | Ответ используется конкретной domain-операцией без искусственного Room-кэша                                  |
+| Room-only                    | `create-room-storage`, затем `create-usecase`; `create-domain-mapper` только при реальной границе моделей                                          | Чтение/запись локального источника без сетевого слоя                                                         |
+| Ktor → mapper → Room         | `create-ktor-endpoint`, `create-domain-mapper`, `create-room-storage`, `create-usecase`                                                            | Load-use case получает API-модель, маппит и атомарно обновляет Room; UI наблюдает Room отдельным FlowUseCase |
+| realtime → reload            | `create-signalr-channel`, затем `create-usecase`; добавь Ktor/mapper/Room skills только для отсутствующих частей reload-потока                     | Realtime-событие служит сигналом обновления, а не вторым источником состояния                                |
+| WorkManager → network → Room | `create-workmanager-task`, `create-ktor-endpoint`, `create-domain-mapper`, `create-room-storage`, `create-usecase` только для отсутствующих частей | Worker вызывает переиспользуемую business-операцию; network/Room-логику не дублирует                         |
+
+Перед реализацией загрузи каждый выбранный skill и следуй его границам. Порядок в таблице описывает
+зависимости, но не требует пересоздавать уже готовые нижние слои.
+
+## Инварианты композиции
+
+- Не добавляй Repository или Interactor, если целевой проект связывает конкретные зависимости через
+  `UseCase` / `FlowUseCase`.
+- Не создавай Room, mapper, request/response или фоновую задачу «для полноты». У каждого слоя должен
+  быть вызывающий сценарий.
+- При Room как источнике истины разделяй обновление и наблюдение: одноразовый load use case пишет в
+  Room, отдельный `FlowUseCase` возвращает DAO Flow.
+- Realtime handler и Worker инициируют use case. Они не копируют HTTP-вызовы, маппинг и SQL-запись
+  внутрь инфраструктурного класса.
+- Композиционный use case разворачивает результат другого use case через `.getOrThrow()`.
+- Используй транзакцию Room для согласованного набора связанных изменений, а не для одиночного
+  вызова DAO.
+- Следуй структуре, именованию и уже выбранным библиотекам целевого проекта. Reference-проект
+  показывает поведение, но не является шаблоном для механической замены package name.
+
+## Завершение
+
+Проверь, что созданные части образуют один вызываемый вертикальный поток, зарегистрированы в
+существующих database/network/realtime/worker точках расширения и не оставили неиспользуемых
+моделей. Запусти релевантные тесты и сборку затронутых модулей. Экран подключай отдельно через
+`create-feature-scaffold-screen`.