update CLAUDE.md and cursor rules

Author: sds100

.cursor/rules/keymapper-add-action-checklist.mdc

@@ -0,0 +1,24 @@
+---
+description: Required checklist when adding a new Action
+alwaysApply: true
+---
+
+# Adding A New Action
+
+Before implementing, confirm whether the action is editable.
+- Branch names must follow `feature/123-branch-name` or `fix/123-branch-name`.
+
+Then follow this sequence:
+
+1. Add an ID in `ActionId`.
+2. Add a new `ActionData` sealed class variant.
+3. Map entity conversions in `ActionDataEntityMapper`.
+4. Assign category in `ActionUtils`.
+5. If editable, add it to `ActionUtils.isEditable`.
+6. Add title string in `strings.xml`.
+7. Add title and Compose icon in `ActionUtils` (ignore drawables).
+8. Add title in `ActionUiHelper`.
+9. Add execution handling in `PerformActionsUseCase`.
+10. Handle creation in `CreateActionDelegate`.
+
+Do not delete existing action code; follow existing names and place additions near similar actions.

.cursor/rules/keymapper-architecture.mdc

@@ -0,0 +1,15 @@
+---
+description: Module boundaries and architectural conventions for KeyMapper
+alwaysApply: true
+---
+
+# KeyMapper Architecture
+
+- Branch names must follow `feature/123-branch-name` or `fix/123-branch-name`.
+- Treat the codebase as Clean Architecture + MVVM with unidirectional data flow.
+- Keep dependency direction as `:app` -> `:base` -> `:common`/`:data`/`:system`/`:sysbridge`.
+- Keep domain models in `:common` and persistence entities in `:data` with explicit mappers.
+- Put business logic in use cases and inject them into ViewModels.
+- Expose UI state via `Flow`/`StateFlow`; collect from UI and send events back to ViewModels.
+- Use Hilt for DI and preserve app-specific binding overrides in app modules.
+- Use coroutines for async work and `viewModelScope` for ViewModel-owned jobs.

.cursor/rules/keymapper-build-and-tooling.mdc

@@ -0,0 +1,16 @@
+---
+description: Build, test, and tooling commands for KeyMapper
+alwaysApply: true
+---
+
+# KeyMapper Build And Tooling
+
+- Branch names must follow `feature/123-branch-name` or `fix/123-branch-name`.
+- Use these common commands:
+  - `./gradlew assembleDebug`
+  - `./gradlew test`
+  - `./gradlew connectedAndroidTest`
+  - `./gradlew ktlintCheck` or `./gradlew ktlintFormat`
+- Release builds require `KEYSTORE_PASSWORD` and `KEY_PASSWORD` environment variables.
+- Target platform constraints: min SDK 26, target SDK 36, Java 11.
+- Dependency versions are managed in `gradle/libs.versions.toml`.

.cursor/rules/keymapper-commit-messages.mdc

@@ -0,0 +1,34 @@
+---
+description: Commit message format convention for KeyMapper
+alwaysApply: true
+---
+
+# KeyMapper Commit Messages
+
+Use this format for commits:
+
+`#<issue_number> <type>: <description>`
+
+Allowed types:
+
+- `feat`
+- `fix`
+- `chore`
+- `refactor`
+- `style`
+
+Example:
+
+`#2025 feat: add button to report bug on home screen`
+
+# Branch Naming Convention
+
+- Use `feature/123-branch-name` for new features.
+- Use `fix/123-branch-name` for bug fixes.
+
+# Pull Request Changelog Requirement
+
+- When preparing a PR, update `CHANGELOG.md` for any user-facing fix/feature/change or notable
+  internal change.
+- If no changelog entry is needed (for example, docs-only or CI-only), explicitly note that in the PR
+  description.

.cursor/rules/keymapper-compose-guidelines.mdc

@@ -0,0 +1,16 @@
+---
+description: Compose coding conventions used in KeyMapper
+globs: "**/*.kt"
+alwaysApply: false
+---
+
+# KeyMapper Compose Guidelines
+
+Apply this when editing Compose code:
+
+- Branch names must follow `feature/123-branch-name` or `fix/123-branch-name`.
+- Put `Modifier` as the first optional parameter after required parameters.
+- For non-standard colors, use `LocalCustomColorsPalette` instead of `MaterialTheme.colorScheme`.
+- Check `KeyMapperIcons` before introducing icons from other sources.
+- Use `LocalUriHandler.openUriSafe` for URL launching and do not hoist URL launching logic.
+- Prefer imports; avoid fully qualified names in Compose call sites.

CLAUDE.md

@@ -70,6 +70,11 @@ Types: `feat`, `fix`, `chore`, `refactor`, `style`
 
 Example: `#2025 feat: add button to report bug on home screen`
 
+## Branch Naming Convention
+
+- Use `feature/123-branch-name` for new features.
+- Use `fix/123-branch-name` for bug fixes.
+
 ## Pull Request Requirement
 
 - Any user-facing behavior change, fix, feature, or notable internal change in a PR must include an