@michaelbel/cuckcoder-mcp 1.6.11

package/assets/skills/create-guide/references/android-project.md

@@ -0,0 +1,120 @@
+# Android Project Rules
+
+## Основа
+
+Создавай проект из актуальной основной ветки:
+
+<https://github.com/michaelbel/MyApplication>
+
+Не копируй Android-шаблон внутрь этого skill. Перед каждым новым гайдом проверяй текущую структуру и версии `MyApplication`.
+
+По умолчанию наследуй:
+
+- Gradle Kotlin DSL;
+- version catalog;
+- JDK 21;
+- Compose;
+- edge-to-edge;
+- тему и launcher resources;
+- CI;
+- подпись debug-сборки;
+- `org.michaelbel` как package prefix.
+
+Меняй унаследованное значение только тогда, когда тема требует этого. Причину фиксируй в манифесте.
+
+## Тип проекта
+
+### `catalog`
+
+Используй для компонентов или API с несколькими независимыми вариантами.
+
+```text
+app/src/main/kotlin/org/michaelbel/<topic>/
+├── MainActivity.kt
+├── MainActivityContent.kt
+├── Theme.kt
+├── sample01_<Name>/Sample01App.kt
+├── sample02_<Name>/Sample02App.kt
+└── ...
+```
+
+Правила:
+
+- номер всегда двузначный;
+- один sample демонстрирует одну идею;
+- главный экран (Home) содержит каталог samples и живёт в `MainActivityContent.kt`;
+- порядок каталога и README совпадает; Notion описывает API без отдельного списка samples;
+- не объединяй разные параметры в один гигантский sample без причины.
+
+#### Навигация и главный экран (эталон: `ListItem`, `Insets`, `NavigationSuiteScaffold`, `EyeDropper`)
+
+`MainActivity.kt` остаётся тонким:
+
+```kotlin
+class MainActivity: ComponentActivity() {
+    override fun onCreate(savedInstanceState: Bundle?) {
+        installSplashScreen()
+        super.onCreate(savedInstanceState)
+        enableEdgeToEdge()
+        setContent { AppTheme { MainActivityContent() } }
+    }
+}
+```
+
+`MainActivityContent.kt` строит навигацию через Navigation 3 (`androidx.navigation3:navigation3-runtime`, `androidx.navigation3:navigation3-ui`):
+
+- backstack — `remember { mutableStateListOf<Any>(Home) }`, где `Home` и `SampleNN` — приватные `data object` для каждого маршрута;
+- `NavDisplay(backStack, onBack = { backStack.removeLastOrNull() }, ...)` с `entryProvider`;
+- `popTransitionSpec` и `predictivePopTransitionSpec` — `fadeIn() togetherWith fadeOut() using SizeTransform(clip = false)`;
+- `entry<Home> { ... }` рендерит каталог samples, `entry<SampleNN> { SampleNNApp() }` — сам sample.
+
+Экран Home — `Scaffold` с `TopAppBar` (заголовок — название темы или `stringResource(R.string.app_name)`), `pinnedScrollBehavior()` + `Modifier.nestedScroll(...)`, и `LazyColumn` со списком samples:
+
+- `contentPadding`: 16.dp по горизонтали и сверху, снизу — `WindowInsets.navigationBars.asPaddingValues().calculateBottomPadding()`;
+- `verticalArrangement = Arrangement.spacedBy(ListItemDefaults.SegmentedGap)`;
+- каждый sample — `SegmentedListItem` с `overlineContent = { Text("Sample NN") }`, `shapes = ListItemDefaults.segmentedShapes(index, count)`, `colors = ListItemDefaults.segmentedColors(containerColor = MaterialTheme.colorScheme.surfaceContainerHighest)`, `content = { Text("<Sample title>") }`; при необходимости добавляй `supportingContent` с коротким пояснением;
+- связанные samples группируй в один сегмент (общий `count`), между несвязанными группами вставляй `Spacer(Modifier.height(12.dp))`;
+- единственный несвязанный пункт без группы — обычный `ListItem`, а не `SegmentedListItem`.
+
+Это требует Navigation 3 и версии `androidx.compose.material3` с `SegmentedListItem`/`ListItemDefaults.segmentedShapes` (см. текущие версии в `ListItem`/`Insets`/`EyeDropper`/`NavigationSuiteScaffold`) — фиксируй точную версию в манифесте, если она новее унаследованной из `MyApplication`. Добавление `androidx.navigation3` и обновление `material3` ради этой структуры не считается нарушением правила «не добавляй зависимости без необходимости»: это часть обязательной структуры каталога, а не тема гайда.
+
+### `scenario`
+
+Используй для API, смысл которого раскрывается в связанном потоке: Navigation, Paging, Room, WorkManager, архитектура.
+
+Структура минимальная и зависит от сценария. Разрешены `feature`, `navigation`, `data` и другие слои только при реальной необходимости.
+
+### `single`
+
+Используй для одного небольшого API. Не создавай каталог с единственным пунктом.
+
+## Минимальная архитектура
+
+Учебный проект демонстрирует тему, а не количество слоёв.
+
+Не добавляй без необходимости:
+
+- DI-фреймворк;
+- use case без бизнес-логики;
+- интерфейс с одной реализацией;
+- data/domain разделение для статических данных;
+- многомодульность;
+- сеть, Room или WorkManager;
+- wrapper только ради переименования API.
+
+Допускай локальное дублирование между samples, если оно делает каждый пример самостоятельным и читаемым.
+
+## Код
+
+- Следуй актуальным правилам `michaelbel/cuckcoder`.
+- Не используй wildcard imports.
+- Все примеры должны компилироваться.
+- Experimental opt-in размещай на уровне файла.
+- Для UI-направлений используй `start`/`end`, если API предоставляет эти понятия.
+- Не оставляй комментарии, пересказывающие строку кода.
+- Preview добавляй по правилам `cuckcoder`; для полноэкранного sample допускается preview корневого контента.
+- Навигация каталога samples не должна затмевать изучаемый API.
+
+## Версии
+
+По умолчанию наследуй версии из `MyApplication`, затем добавляй только зависимости темы. Для alpha или experimental API фиксируй точную версию и opt-in в манифесте, README и Notion.

package/assets/skills/create-guide/references/androidx.md

@@ -0,0 +1,49 @@
+# AndroidX Source Rules
+
+## Когда использовать AndroidX
+
+Используй <https://github.com/androidx/androidx> для:
+
+- проверки фактического поведения API;
+- чтения KDoc и публичных сигнатур;
+- поиска официальных samples и тестов;
+- понимания default values и внутренних связей;
+- восстановления примера, которого нет в документации.
+
+## Фиксация источника
+
+Для каждого изученного AndroidX-файла добавь в `.guidekit/SOURCES.md`:
+
+- repository URL;
+- commit SHA, tag или release branch;
+- полный путь к файлу;
+- ссылка на файл;
+- что именно было использовано;
+- использование: `reference`, `adapted` или `copied`.
+
+Не используй плавающую ссылку на `androidx-main` как единственную фиксацию версии. Сохрани конкретный commit SHA.
+
+## Адаптация кода
+
+Предпочитай написать минимальный пример заново на основе понимания API.
+
+Если фрагмент адаптирован:
+
+- укажи исходный файл;
+- опиши изменения;
+- сохрани применимые copyright notices;
+- не выдавай код AndroidX за полностью авторский.
+
+Если фрагмент скопирован:
+
+- сохрани исходный copyright header в файле;
+- добавь Apache License 2.0 в `LICENSES/Apache-2.0.txt`;
+- добавь запись в `THIRD_PARTY_NOTICES.md`;
+- проверь, есть ли в исходном subtree файл `NOTICE` и перенеси применимые notices;
+- не удаляй лицензионные комментарии.
+
+Это правило относится к коду, тестам, изображениям и другим материалам.
+
+## Ограничение копирования
+
+Не переноси в учебный проект большие внутренние реализации AndroidX, если гайд можно показать через публичный API. Копирование должно быть минимальным, объяснимым и совместимым с лицензией источника.

package/assets/skills/create-guide/references/existing-guides.yaml

@@ -0,0 +1,60 @@
+schema_version: 1
+default_notion_data_source_name: POSTS
+count: 14
+
+guides:
+  - id: detekt
+    notion_title: Гайд по Detekt. Создать свои правила для статического анализа Kotlin-кода
+    repository: https://github.com/michaelbel/detekt-rules
+
+  - id: insets
+    notion_title: Гайд по Insets. Как обрабатывать отступы и вырезы
+    repository: https://github.com/michaelbel/Insets
+
+  - id: navigation-suite-scaffold
+    notion_title: Гайд по NavigationSuiteScaffold. Адаптивная верхнеуровневая навигация
+    repository: https://github.com/michaelbel/NavigationSuiteScaffold
+
+  - id: list-item
+    notion_title: Гайд по ListItem. Как проектировать экспрессивные списки
+    repository: https://github.com/michaelbel/ListItem
+
+  - id: agent-symlinks
+    notion_title: Гайд по Симлинкам для AGENTS.md, CLAUDE.md, GEMINI.md
+    repository: https://github.com/michaelbel/cuckcoder
+
+  - id: gemma4
+    notion_title: Гайд по Gemma4 в Android Studio. Запустить локального AI-ассистента
+    repository: null
+
+  - id: enum-bitmask
+    notion_title: Гайд по Kotlin Enum Bitmask. Как хранить набор флагов в Int
+    repository: https://github.com/michaelbel/EnumBitmask
+
+  - id: aliases
+    notion_title: Гайд по Aliases. Как менять иконку приложения в Android
+    repository: https://github.com/michaelbel/Aliases
+
+  - id: build-flavors
+    notion_title: Гайд по BuildFlavors. Как разделять Android-сборки под разные платформы
+    repository: https://github.com/michaelbel/BuildFlavors
+
+  - id: font-scale
+    notion_title: Гайд по FontScale. Как адаптировать UI к крупному тексту
+    repository: https://github.com/michaelbel/FontScale
+
+  - id: mvi
+    notion_title: Гайд по MVI. Архитектура управления состоянием
+    repository: https://github.com/michaelbel/MVI
+
+  - id: palette-colors
+    notion_title: Гайд по PaletteColors. Как извлекать цвета из изображений
+    repository: https://github.com/michaelbel/PaletteColors
+
+  - id: plurals
+    notion_title: Гайд по Plurals. Как склонять строки с числами в Android
+    repository: https://github.com/michaelbel/Plurals
+
+  - id: eye-dropper
+    notion_title: Гайд по EyeDropper. Как использовать системную пипетку в Android 17
+    repository: https://github.com/michaelbel/EyeDropper

package/assets/skills/create-guide/references/github.md

@@ -0,0 +1,71 @@
+# GitHub Guide Repository Rules
+
+## Создание
+
+По умолчанию:
+
+- owner: `michaelbel`;
+- visibility: `public`;
+- имя: официальное имя темы в PascalCase;
+- package: `org.michaelbel.<topic-lowercase>`;
+- ветка: наследуется от актуального `MyApplication`;
+- Android-проект создаётся без истории шаблона.
+
+Примеры имён:
+
+- `Insets`;
+- `ListItem`;
+- `NavigationSuiteScaffold`;
+- `EyeDropper`.
+
+Сокращённый package вроде `org.michaelbel.nss` допускается только при явной фиксации в манифесте.
+
+## Общие правила
+
+Следуй актуальным файлам:
+
+- `rules/github/GITHUB_REPO_RULES.md`;
+- `rules/github/GITHUB_README_RULES.md`;
+- `rules/git/GIT_RULES.md`
+
+из <https://github.com/michaelbel/cuckcoder>.
+
+GuideKit дополнительно требует:
+
+- `.guidekit/` с воспроизводимыми метаданными;
+- README со списком samples или описанием scenario;
+- ссылки README должны указывать на существующие пути;
+- CI должен собирать debug APK;
+- публичный репозиторий не содержит секретов и внутренних Notion IDs.
+
+## AI-инструкции
+
+В создаваемом репозитории:
+
+- `AGENTS.md` — реальный файл;
+- `CLAUDE.md` — symlink на `AGENTS.md`;
+- `GEMINI.md` — symlink на `AGENTS.md`.
+
+`AGENTS.md` должен требовать:
+
+1. правила `cuckcoder`;
+2. чтение `.guidekit/manifest.yaml`;
+3. сохранение соответствия с Notion-страницей;
+4. обновление `.guidekit/SOURCES.md` и validation report при изменениях.
+
+## README
+
+README пишется на английском, если пользователь не указал иначе.
+
+После обязательных секций `cuckcoder` добавь:
+
+- `## Samples` для `catalog`;
+- `## Scenario` для `scenario`;
+- `## Build`;
+- `## Sources`, если использовался AndroidX-код.
+
+Каждая строка списка samples ссылается на точный файл или каталог.
+
+## Метаданные
+
+Описание репозитория — одно английское предложение. Добавь релевантные topics, но не используй общие теги вроде `project` или `sample` без предметного тега.

package/assets/skills/create-guide/references/guide-defaults.yaml

@@ -0,0 +1,51 @@
+schema_version: 1
+
+owner:
+  github: michaelbel
+  package_prefix: org.michaelbel
+
+language:
+  framework: ru
+  notion: ru
+  repository_readme: en
+  code: en
+
+integrations:
+  github_profile: https://github.com/michaelbel
+  android_template: https://github.com/michaelbel/MyApplication
+  shared_rules: https://github.com/michaelbel/cuckcoder
+  androidx_source: https://github.com/androidx/androidx
+  notion_data_source_name: POSTS
+  notion_existing_page_policy: update_in_place
+
+repository:
+  visibility: public
+  project_mode: auto
+  default_branch: inherit_template
+  naming: PascalCase
+  include_ci: true
+  include_codeowners: true
+  include_funding: true
+  include_ai_symlinks: true
+
+android:
+  ui: compose
+  build_scripts: kotlin_dsl
+  versions: inherit_template
+  jdk: 21
+  architecture: minimal_for_topic
+  dependency_injection: only_when_required
+  modules: single_by_default
+
+research:
+  require_primary_sources: true
+  require_exact_versions: true
+  require_androidx_ref: when_androidx_is_used
+  third_party_sources: supplementary_only
+
+validation:
+  required_gradle_tasks:
+    - :app:assembleDebug
+    - :app:lintDebug
+  unit_tests: when_present
+  require_cross_check: true

package/assets/skills/create-guide/references/notion.md

@@ -0,0 +1,121 @@
+# Notion Guide Rules
+
+## Место публикации
+
+Сначала ищи существующую страницу по точному или близкому названию. Если она найдена, обновляй только её: не создавай дубликат и не переноси страницу между базами.
+
+Если страницы ещё нет, по умолчанию создавай её в data source с точным именем `POSTS`, если пользователь явно не указал другое место. Разрешай страницу и data source через Notion API по имени или предоставленному пользователем URL. Не сохраняй внутренний Notion ID в публичном репозитории.
+
+## Язык и заголовок
+
+Страница пишется на русском.
+
+Шаблон названия:
+
+```text
+Гайд по <Topic>. <Практический результат>
+```
+
+Примеры:
+
+- `Гайд по Insets. Как обрабатывать отступы и вырезы`;
+- `Гайд по ListItem. Как проектировать экспрессивные списки`;
+- `Гайд по EyeDropper. Как использовать системную пипетку в Android 17`.
+
+Не повторяй title первым заголовком в content: Notion показывает свойство title автоматически.
+
+Если широкая тема поддерживает несколько API или способов представления, а проект разбирает только один из них, укажи выбранный API в title. Не создавай впечатление, что гайд покрывает всю тему.
+
+## Вступление
+
+До первого `##` напиши один-два плотных абзаца:
+
+- что это за API;
+- какую проблему он решает;
+- когда разработчик сталкивается с этой проблемой;
+- главное ограничение или условие, если оно критично.
+
+В первом абзаце повторно зафиксируй точный объем гайда. Разделяй системную capability или treatment и конкретный presentation API: не называй их одним механизмом и не подменяй одно другим.
+
+При первом употреблении специального термина объясни его простыми словами через наблюдаемое поведение. Не заменяй объяснение другим абстрактным термином: вместо общих формулировок вроде `заметные поверхности` перечисли конкретные места интерфейса, если их немного.
+
+Не перечисляй варианты API, которые не рассматриваются в гайде, только ради полноты. Упоминай их лишь тогда, когда без этого нельзя корректно объяснить границы или поведение выбранного API.
+
+Не начинай с истории библиотеки, общих слов или определения Android.
+
+## Структура
+
+Не используй один жесткий набор разделов для всех тем. Строй страницу вокруг ментальной модели и публичного API.
+
+Рекомендуемый порядок:
+
+1. главная идея;
+2. настройка manifest, если API требует permissions, services, activities или providers;
+3. основные компоненты и методы API;
+4. параметры, состояния и варианты с кодом из проекта;
+5. документация.
+
+Не добавляй отдельные служебные разделы `Требования и версии проекта`, `Сценарии проекта` и `Состояние, жизненный цикл и завершение`. Не добавляй таблицу версий проекта. Упоминай минимальную версию Android, статус API или версию тематической библиотеки рядом с тем API, для которого эта информация необходима.
+
+Если нужны разрешения, выноси их в отдельный раздел `Настройка манифеста` с фрагментом manifest и объяснением каждого permission.
+
+Основные секции API оставляй открытыми. Не превращай описания компонентов и методов в toggle. Toggle допустим только для длинной повторяющейся справочной информации, которая не является основным содержанием гайда.
+
+Самостоятельную пользовательскую операцию, например открытие системных настроек, выноси в отдельный H2, если для нее нужны отдельная настройка manifest и код вызова. Сначала показывай требуемый фрагмент manifest, затем код операции и объяснение проверки доступности.
+
+## Описание компонента
+
+Для каждого важного компонента ответь:
+
+- что делает;
+- где находится в общем потоке;
+- какие параметры важны;
+- какой минимальный пример это показывает;
+- какие есть состояния, ограничения и ошибки.
+
+Не пересказывай сигнатуру параметр за параметром, если параметр очевиден.
+
+Если H2 уже содержит имя метода, класса или типа, не начинай первый абзац с повторения того же имени. Сразу объясняй назначение, поведение или результат.
+
+Если API предоставляет набор semantic styles, режимов или констант, описывай каждое значение отдельным пунктом маркированного списка.
+
+## Стиль
+
+- Пиши коротко и конкретно.
+- Обращайся к читателю на «ты».
+- Не используй букву `ё` или `Ё`. Всегда пиши `е` или `Е`.
+- Выделяй имена API, параметры, значения и другие технические термины оранжевым: `<span color="orange">` в Notion Markdown.
+- Каждый технический термин в inline code оформляй как `<span color="orange">` + inline code. Не оставляй технические термины в обычном inline code, который Notion показывает красным.
+- Не используй красный цвет для терминов. Все цветные выделения API, параметров и значений делай оранжевыми.
+- Не выделяй оранжевым целые предложения.
+- Используй inline code для классов, функций, параметров и значений.
+- Код — в блоках `kotlin`, `xml`, `toml` или `shell`.
+- Не используй длинное тире `—`. Используй среднее тире `–`.
+- Не используй выражение `строка состояния` и его падежные формы. Используй `статус бар`.
+- Перед каждым заголовком H2 добавляй отдельный пустой Notion-блок `<empty-block/>`.
+- Не добавляй буквальный текст `#<empty-block/>`, `#\<empty-block/\>` или другие экранированные варианты. `<empty-block/>` должен быть отдельным блоком и визуально отображаться как пустая строка.
+- Не добавляй callout-блоки без явного запроса пользователя. Важные условия и предупреждения пиши обычными абзацами рядом с соответствующим API.
+- Каждый пункт маркированного и нумерованного списка начинай с заглавной буквы.
+- Не создавай отдельный раздел `Ограничения demo-проекта`. Существенные ограничения API размещай в разделах соответствующих компонентов или сценариев.
+- Скриншоты и GIF добавляй только там, где поведение важно увидеть.
+- Не добавляй раздел «Итоги» ради формальности.
+
+## Код и ссылки
+
+- Пиши страницу после реализации проекта.
+- Большой фрагмент кода должен существовать в репозитории.
+- Если пример использует `resolveActivity()` или другой запрос к `PackageManager`, проверь требования package visibility. Когда нужен `<queries>`, покажи его рядом с кодом `Intent` и используй ту же action, что реализована в проекте.
+- Не упоминай в тексте названия, номера и файлы samples, например `Sample07` или `Sample07App.kt`.
+- Не добавляй ссылки на отдельные sample-файлы. Встраивай кодовые примеры в описание соответствующего API, а в разделе `Документация` оставляй ссылку на репозиторий.
+- Не превращай упоминания файлов в GitHub-ссылки внутри основного текста. Имена файлов пиши обычным текстом, если пользователь явно не попросил точную ссылку.
+- Версия зависимости должна совпадать с `libs.versions.toml`.
+- Не используй ссылки на временные ветки.
+- В конце добавляй H2 `Документация`.
+- Перед `## Документация`, как и перед любым H2, добавляй отдельный `<empty-block/>`.
+- Ссылки на `developer.android.com` размещай отдельными строками без списка в формате Notion link mention: `[Заголовок страницы | Android Developers](<url>)`.
+- После ссылок на документацию добавляй отдельную строку `Репозиторий – [<repository-url>](<repository-url>)`.
+- Не добавляй в конец страницы служебный отчёт о commit SHA, Gradle, lint, GuideKit validator или статусе публикации. Эти данные хранятся в `.guidekit/validation-report.md` и финальном ответе агента.
+
+## Разделение ответственности
+
+README кратко показывает проект и список samples. Notion подробно объясняет API без упоминания названий, номеров и файлов samples. Не копируй целые разделы между ними.

package/assets/skills/create-guide/references/output-contract.md

@@ -0,0 +1,79 @@
+# Output Contract
+
+## Основные артефакты
+
+Гайд считается опубликованным только тогда, когда существуют и связаны:
+
+1. публичный GitHub-репозиторий с рабочим Android-проектом;
+2. связанная страница в Notion: существующая страница, обновлённая на месте, или новая страница в `POSTS` по умолчанию.
+
+Если пользователь явно просит только черновик, допускается остановиться до публикации. Во всех остальных случаях локальные файлы без URL не считаются завершённым результатом.
+
+## Рабочие артефакты
+
+Создаваемый репозиторий содержит:
+
+```text
+.guidekit/
+├── manifest.yaml
+├── research.md
+├── implementation-plan.md
+├── SOURCES.md
+└── validation-report.md
+```
+
+- `manifest.yaml` фиксирует выбранный scope;
+- `research.md` содержит технические выводы до реализации;
+- `implementation-plan.md` связывает требования с файлами и samples;
+- `SOURCES.md` хранит первичные источники и происхождение кода;
+- `validation-report.md` хранит реальные результаты проверок.
+
+## Готовность результата
+
+Гайд готов, если:
+
+- все сценарии из манифеста реализованы;
+- обязательные Gradle-задачи прошли;
+- страница написана по фактической реализации;
+- код и ссылки в Notion проверены;
+- версии совпадают;
+- существенные ограничения API указаны рядом с соответствующими компонентами или сценариями;
+- AndroidX-заимствования атрибутированы.
+
+## Финальный ответ агента
+
+Используй структуру:
+
+```markdown
+# Гайд создан
+
+GitHub: <url>
+Notion: <url>
+Тип проекта: <catalog | scenario | single>
+
+## Реализовано
+
+- ...
+
+## Проверки
+
+- `:app:assembleDebug` — успешно;
+- `:app:lintDebug` — успешно;
+- ...
+
+## Версии
+
+- Kotlin: ...
+- Compose: ...
+- Topic API: ...
+
+## Источники
+
+- ...
+
+## Ограничения
+
+- ...
+```
+
+Не пиши «успешно», если проверка не запускалась. Используй «не запускалась» и объясни причину.

package/assets/skills/create-guide/references/research.md

@@ -0,0 +1,64 @@
+# Research Rules
+
+## Цель
+
+Исследование должно ответить:
+
+- какую проблему решает API;
+- какая у него ментальная модель;
+- какие компоненты входят в публичный API;
+- как компоненты взаимодействуют;
+- какие версии и opt-in нужны;
+- какие сценарии необходимо показать;
+- какие ограничения, ошибки и edge cases важны.
+
+## Приоритет источников
+
+1. Официальная документация.
+2. Исходный код AndroidX или AOSP.
+3. Официальные samples и тесты.
+4. Release notes и changelog.
+5. Официальный issue tracker.
+6. Сторонние материалы как дополнительный контекст.
+
+Существующие Notion-гайды и репозитории Михаила — эталон формы, но не источник актуального поведения API.
+
+## Проверка актуальности
+
+Перед реализацией:
+
+- найди актуальную версию библиотеки в официальных release notes или репозитории;
+- проверь статус API;
+- проверь минимальный API level;
+- проверь package и artifact coordinates;
+- проверь, не был ли API переименован или deprecated;
+- зафиксируй дату исследования.
+
+Не используй версию только потому, что помнишь её или увидел в сторонней статье.
+
+## Research report
+
+`.guidekit/research.md` должен содержать:
+
+```markdown
+# Research
+
+Дата: YYYY-MM-DD
+Тема: ...
+Статус API: ...
+Версия: ...
+
+## Главная идея
+
+## Публичные компоненты
+
+## Сценарии
+
+## Ограничения
+
+## Открытые вопросы
+
+## Первичные источники
+```
+
+Каждое спорное техническое утверждение связывай с источником. Авторскую рекомендацию явно называй рекомендацией, а не поведением платформы.