code-review-and-security-audit

name	code-review-and-security-audit
description	Review code for quality, correctness, and security vulnerabilities. Use when the user asks to review code, audit for security issues, or check for bugs and anti-patterns.
argument-hint	file path, component name, or scope of review

Code Review and Security Audit

You are performing code review and security auditing for RakuRaku IME (輕鬆輸入法).

Stack Reminders

• Kotlin + Jetpack Compose + Material 3 for UI.
• Room (with KSP) + FTS4 + a pre-packaged database asset for the dictionary.
• Coroutines / suspend with Dispatchers.IO for parsing and DB work.
• DataStore Preferences for user settings.
• No JNI, no C/C++, no native libraries — if a review surfaces native concerns, it is out of scope for this project.

Review Checklist

Code Quality

• Null safety: prefer null-safe operators; avoid !! unless justified.
• Coroutines: suspend functions stay on the correct dispatcher (Dispatchers.IO for disk / DB / asset work); UI state updates happen on the main thread or via Compose state (thread-safe).
• Room: transactions wrap multi-statement writes; FTS4 queries use the correct MATCH syntax; indexes align with the actual query shapes.
• Compose: state is hoisted where it needs to be; remember/rememberSaveable/LaunchedEffect keys are correct; avoid leaking Context into long-lived state.
• Resource management: InputStream / Reader / Cursor closed with .use { } or try/finally.
• Error handling: appropriate use of try/catch at boundaries (asset I/O, DB init); no silently swallowed exceptions.
• No dead code, unused imports, or redundant logic.

Code Smells

• Long methods, large composables, deep nesting.
• Duplicated logic across key handlers / layout code — candidate for extraction.
• Magic numbers or strings where a named constant, enum, or sealed class would read better.
• Primitive obsession where a domain type would be clearer (e.g., keystroke, character).
• Long parameter lists — group into a data class.
• Mutable shared state — prefer immutable data and local state; flag unnecessary var or global mutable collections.

Refactoring Suggestions

• Extract method / extract composable when a block has a distinct responsibility.
• Replace conditional chains with sealed classes or enums where it aids clarity.
• Use Kotlin idioms: scope functions, destructuring, extension functions, buildList / buildString.
• Lift repeated Compose logic into reusable composables (e.g., SettingsSwitch).
• Reduce coupling: prefer passing narrowly-typed dependencies over full Context or database handles when practical.
• Improve testability: flag code that is hard to unit test (hidden singletons, direct asset access) and suggest seams.

Android / IME-Specific Security

• Keystroke privacy: this app is an IME and processes all user input. Review for any log statements, crash reports, analytics, or persistence that could leak user keystrokes, dictionary lookups, or clipboard data.
• SharedPreferences / DataStore: no sensitive data stored; nothing world-readable.
• Intent handling: validate intent extras; do not re-dispatch untrusted intents.
• Exported components: check AndroidManifest.xml — activities / services / receivers should not be inadvertently exported; the IME service itself must be exported but only with the proper android.permission.BIND_INPUT_METHOD guard.
• ProGuard/R8: if/when enabled, verify rules don't strip security-critical code.
• WebView: not currently used; flag any introduction.

Data & Dictionary Integrity

• Asset parsing (CinParser): validate line format; avoid crashes on malformed input.
• Room migrations: schema changes must ship a migration or an intentional fallbackToDestructiveMigration; destructive fallback drops user frequency data — call that out.
• Pre-packaged DB asset: ensure it stays in sync with the .cin asset; the asset-hash sync in CinParser is the guardrail.

General Security

• No hardcoded secrets, API keys, or credentials.
• No command injection via Runtime.exec() or ProcessBuilder.
• No path traversal in file operations.
• No insecure RNG for security-sensitive operations.
• Dependencies: check for known vulnerabilities in gradle/libs.versions.toml.

Output Format

Report findings using this structure:

Critical / High

Security vulnerabilities, crashes, data loss risks.

Medium

Logic bugs, thread safety concerns, concrete code smells.

Low / Informational

Style, readability, minor optimizations.

For each finding, include:

• File and line number (e.g., CinParser.kt:42)
• Description of the issue
• Impact — what could go wrong
• Recommendation — how to fix it, with code if helpful

How to Run

Without arguments, review recently changed files:

git diff --name-only HEAD~5

With a scope (file, directory, or component), focus on that area.

For a full audit, systematically review:

1. Data layer (app/src/main/java/org/ghostsinthelab/app/rakurakuime/data/)
2. IME service and input handling
3. Compose UI layer (ui/, MainActivity)
4. Configuration (AndroidManifest.xml, app/build.gradle.kts)
5. Dependencies (gradle/libs.versions.toml)

Task: $ARGUMENTS