app/src/main/java/com/shub39/grit/widgets/HabitStreakWidget.kt (1)

155-156: Date calculation logic is correct.

The migration to kotlinx-datetime is implemented correctly:

• Clock.System.todayIn(TimeZone.currentSystemDefault()) properly gets the current local date
• today.minus(it, DateTimeUnit.DAY) correctly computes past dates
• The .reversed() ensures chronological ordering (oldest to newest)

Note: Since this is inside a @Composable, the date calculation runs on every recomposition. While the performance impact is negligible for 5 iterations, wrapping these in remember {} would follow Compose best practices for pure computations.

app/src/main/java/com/shub39/grit/server/GritServerRepositoryImpl.kt (1)

7-7: Import path aligned with core refactor; minor startServer cleanup

Line [7]: Importing TaskRepo from com.shub39.grit.core.tasks.domain matches the new shared core layout and keeps this repository wired to the correct domain interface; behavior is unchanged.

Lines [87-89]: val port = port just shadows the function parameter and is only used once in the subsequent embeddedServer call. You can drop the extra val and pass the parameter directly to avoid the shadowing/warning:

-            val port = port
-
-            server = embeddedServer(CIO, host = "0.0.0.0", port = port) {
+            server = embeddedServer(CIO, host = "0.0.0.0", port = port) {

Also applies to: 87-89

app/src/main/java/com/shub39/grit/core/presentation/settings/ui/component/AboutApp.kt (1)

33-37: Resource access migrated to generated Res.string API

Lines [33-37,115,133]: Using stringResource(Res.string.bmc) and stringResource(Res.string.rate_on_play) with the generated Res namespace is consistent with the project-wide resource migration and keeps this composable ready for multiplatform reuse, assuming those keys exist in the generated resources.

Lines [65-92]: There are still a few hard-coded user-facing labels ("Grit", "Discord", "Github", etc.). Not urgent, but in a follow-up you might consider moving them into the same resource system for better localization and consistency.

Also applies to: 65-92, 115-115, 133-133

.github/workflows/web.yml (1)

22-31: Consider adding Gradle caching to improve build performance.

Adding Gradle caching will speed up subsequent builds by reusing dependencies and build artifacts.

Apply this diff to add caching:

       - name: Setup Java
         uses: actions/setup-java@v4
         with:
           distribution: temurin
           java-version: 17
+          cache: gradle

       - name: Build Web App
         run: ./gradlew :web:wasmJsBrowserDistribution

shared/core/src/commonMain/composeResources/values/strings.xml (1)

27-27: Consider future plural resource needs.

While the current format string approach works, be aware that some strings (like "best_streak") may need plural forms for proper localization. Based on learnings, migrating to plural resources later can create breaking changes for existing translations.

Consider planning for plural resources in advance:

<!-- Future plural form example -->
<plurals name="best_streak">
    <item quantity="one">Best Streak: %1$d day</item>
    <item quantity="other">Best Streak: %1$d days</item>
</plurals>

Based on learnings.

web/src/jvmMain/kotlin/main.kt (1)

7-16: Consider error handling for DI initialization.

The initKoin() call lacks error handling. If initialization fails (e.g., module configuration errors, duplicate bindings), the app will crash without a meaningful error message.

Additionally, the fixed window size (1000.dp x 600.dp) may not suit all displays. Consider making the window resizable or using a responsive size.

Apply this diff to add error handling:

 fun main() {
-    initKoin()
+    try {
+        initKoin()
+    } catch (e: Exception) {
+        println("Failed to initialize Koin: ${e.message}")
+        throw e
+    }
 
     singleWindowApplication(
         state = WindowState(size = DpSize(1000.dp, 600.dp)),
-        title = "Grit"
+        title = "Grit",
+        resizable = true
     ) {
         App()
     }
 }

app/src/main/java/com/shub39/grit/core/data/NotificationAlarmScheduler.kt (1)

66-74: Replace non-null assertion with safe handling.

Line 69 uses task.reminder!! immediately after a null check on line 68. While this is safe due to the early return, the non-null assertion operator (!!) is fragile and can mask intent.

Apply this diff to use smart cast or safe handling:

 override fun schedule(task: Task) {
     cancel(task)
-    if (task.reminder == null) return
-    val scheduleTime = task.reminder!!
+    val scheduleTime = task.reminder ?: return
 
     if (scheduleTime < Clock.System.now().toLocalDateTime(TimeZone.currentSystemDefault())) {
         Log.d(tag, "Task '${task.title}' reminder time is in the past")
         return
     }

shared/core/src/commonMain/kotlin/com/shub39/grit/core/tasks/domain/Category.kt (1)

6-11: Consider the default id = 0 value.

The id field defaults to 0, which could lead to collisions if multiple categories are created without explicitly setting IDs. Ensure that ID assignment is handled properly in the repository layer (e.g., auto-increment or UUID generation).

web/src/commonMain/kotlin/di/initKoin.kt (1)

6-11: Consider guarding against duplicate initialization.

The initKoin function calls startKoin without checking if Koin is already initialized. Calling startKoin multiple times will throw an exception. Consider using startKoin with a check or documenting that this should only be called once.

Apply this diff to make initialization idempotent:

+import org.koin.core.context.GlobalContext
+
 fun initKoin(config: KoinAppDeclaration? = null) {
-    startKoin{
-        config?.invoke(this)
-        modules(appModules)
+    if (GlobalContext.getOrNull() == null) {
+        startKoin {
+            config?.invoke(this)
+            modules(appModules)
+        }
     }
 }

shared/core/src/jvmMain/kotlin/com/shub39/grit/core/habits/presentation/ui/component/HabitUpsertSheet.jvm.kt (1)

29-30: Consider adding a comment explaining the hardcoded permission.

The hardcoded notificationPermission = true and empty onRequestPermission callback are reasonable for JVM targets (desktop/server), but a brief comment would clarify this platform-specific behavior for future maintainers.

Example:

+        // JVM target: notifications are always available or not applicable
         notificationPermission = true,
         onRequestPermission = {},

shared/core/src/wasmJsMain/kotlin/com/shub39/grit/core/tasks/presentation/ui/component/TaskUpsertSheet.wasmJs.kt (1)

31-34: Consider adding a comment explaining the hardcoded permission.

Similar to the JVM implementation, hardcoding notificationPermission = true is appropriate for WasmJS (web browser) targets where notifications are handled via the Web Notification API, but a brief comment would improve clarity.

Example:

+        // WasmJS target: notification permissions handled via Web Notification API
         notificationPermission = true,
         showDateTimePicker = showDateTimePicker,
         updateDateTimePickerVisibility = { showDateTimePicker = it },
         onPermissionRequest = {},

shared/core/src/wasmJsMain/kotlin/com/shub39/grit/core/habits/presentation/ui/component/HabitUpsertSheet.wasmJs.kt (1)

29-30: Consider adding a comment explaining the hardcoded permission.

Consistent with other WasmJS implementations, but a brief comment would clarify why notificationPermission is hardcoded to true for web targets.

Example:

+        // WasmJS target: notification permissions handled via Web Notification API
         notificationPermission = true,
         onRequestPermission = {},

shared/core/src/commonMain/kotlin/com/shub39/grit/core/habits/presentation/ui/sections/AnalyticsPage.kt (1)

214-251: Optional: consider localizing dialog contentDescriptions

The visual text for the delete dialog is now properly localized, but contentDescription values like "Warning" remain hard-coded. If you’re aiming for full localization and accessibility parity, consider moving those descriptions to string resources as well.

If you decide to localize them, re-run any accessibility or screen-reader checks you have to confirm the updated descriptions are read correctly.

web/src/commonMain/kotlin/App.kt (2)

62-76: Keep bottom navigation selection in sync with NavHost back stack

currentRoute is tracked with remember { mutableStateOf(Routes.Tasks) } and only updated on bottom-nav clicks. This can drift out of sync with the actual NavHost state (e.g., when the user navigates back), and navController.navigate(currentRoute) will keep pushing new entries onto the stack instead of behaving like typical bottom navigation.

I’d recommend:

• Deriving the selected route from the navController’s current back stack entry rather than a separate mutable state, and
• Using navigate(route) { launchSingleTop = true /* plus popUpTo if appropriate */ } for bottom-nav item clicks.

After adjusting, test tapping between Tasks/Habits repeatedly and using back navigation (including browser back on web) to confirm the highlighted tab always matches the visible screen.

Also applies to: 93-115

---

35-52: Optional: move tab labels to resources for consistency/i18n

Routes.toDisplayText() currently hard-codes "Tasks" and "Habits". Given the rest of the UI is using generated string resources, you may want to move these labels into Res.string.* for localization and consistency.

If you choose to switch to resources, please re-run any localization checks or previews you have to ensure the new strings are wired up correctly.

Also applies to: 84-86

shared/core/src/androidMain/kotlin/com/shub39/grit/core/tasks/presentation/ui/component/TaskUpsertSheet.android.kt (1)

51-51: Use string resources for user-facing text.

The toast message "Notification permission denied" is hardcoded. Consider using a string resource for consistency with the rest of the codebase and to support localization.

Apply this diff:

-        } else Toast.makeText(context, "Notification permission denied", Toast.LENGTH_SHORT).show()
+        } else Toast.makeText(context, context.getString(R.string.notification_permission_denied), Toast.LENGTH_SHORT).show()

Note: Ensure the string resource notification_permission_denied is added to the appropriate resources file.

shared/core/src/commonMain/kotlin/com/shub39/grit/core/tasks/presentation/ui/section/EditCategories.kt (1)

52-277: Task categories edit UI migration looks correct; tiny polish possible on count text

The refactor to TaskState / TaskAction and Res.string.* is consistent with the rest of the core/tasks changes, and the reordering/deletion callbacks line up with the TaskAction handlers shown in TasksViewModel.kt. The local categories state derived from state.tasks.keys keeps UI and state aligned during reorders.

One tiny clean-up you might consider:

• In the support text, prefer keeping the count numeric instead of mixing Int and String:

Text(
    text = "${state.tasks[category]?.size ?: 0} ${stringResource(Res.string.tasks)}"
)

This avoids the "0" string literal and keeps the expression type-safe.

shared/core/src/androidMain/kotlin/com/shub39/grit/core/habits/presentation/ui/component/HabitUpsertSheet.android.kt (1)

19-65: Android HabitUpsertSheet permission flow is solid; consider using a string resource for the toast

The POST_NOTIFICATIONS handling and delegation into HabitUpsertSheetContent are wired correctly and align with Android 13+ patterns. One small improvement:

• Replace the hard-coded "Notification permission denied" toast text with a shared string resource (e.g., Res.string.notification_permission_denied or an Android-only R.string.*) to keep i18n and wording consistent with the rest of the UI.

Toast.makeText(
    context,
    context.getString(R.string.notification_permission_denied),
    Toast.LENGTH_SHORT
).show()

(or the equivalent via your generated resources on Android).

app/src/main/java/com/shub39/grit/viewmodels/HabitViewModel.kt (1)

131-165: Start-of-week preference currently doesn’t re-drive analytics streams

observeHabitStatuses() and observeOverallAnalytics() capture _state.value.startingDay only once when they’re invoked in the state.onStart block. Later updates from getStartOfTheWeekPref() change startingDay in _state, but don’t re-subscribe the repo flows. If users can change the start-of-week setting at runtime, the analytics/heatmap streams will continue using the original value.

Consider re-invoking observeHabitStatuses() and observeOverallAnalytics() when startingDay changes, for example inside the getStartOfTheWeekPref().onEach block (relying on the existing habitStatusJob/overallAnalyticsJob cancellation):

             datastore
                 .getStartOfTheWeekPref()
-                .onEach { pref ->
-                    _state.update {
-                        it.copy(
-                            startingDay = pref
-                        )
-                    }
-                }
+                .onEach { pref ->
+                    _state.update { it.copy(startingDay = pref) }
+                    observeHabitStatuses()
+                    observeOverallAnalytics()
+                }
                 .launchIn(this)

Also applies to: 167-202

shared/core/src/commonMain/kotlin/com/shub39/grit/core/tasks/presentation/ui/section/TaskList.kt (1)

90-299: Task list state/action migration and reorder logic look consistent

TaskList now correctly consumes TaskState/TaskAction, and all interactions (ChangeCategory, UpsertTask, DeleteTasks, ReorderTasks, AddCategory) dispatch the expected actions; the reorderableTasks local state and ReorderTasks index→task mappings are consistent with the TasksViewModel.onAction implementation. If you want a tiny readability tweak, consider naming the lambda parameter in mapIndexed { newIndex, it -> newIndex to it } (e.g., taskItem) instead of it.

shared/core/src/commonMain/kotlin/com/shub39/grit/core/habits/presentation/ui/component/WeeklyGraph.kt (1)

1-107: WeeklyGraph refactor looks solid; consider minor MPP/i18n polish

The migration to HabitsAction, Res.string.*, and List<Line> looks consistent with the core refactor and with HabitViewModel.onAction (including OnShowPaywall). The filtering via takeLast(selectedTimePeriod.toWeeks()) is also safe even when the series is shorter than the requested window.

Two small improvements you might consider:

• For better localization, instead of string interpolation with "${period.toWeeks()} ${stringResource(Res.string.weeks)}", move this into a formatted string resource (e.g., %d placeholder) so word order and pluralization can be localized properly.
• Since this composable now lives in commonMain, double‑check that rememberSaveable { mutableStateOf(WeeklyTimePeriod.WEEKS_8) } is supported on all targets. If WeeklyTimePeriod isn’t automatically saveable everywhere, adding an explicit Saver (or falling back to remember) would make this safer in the KMP context.

app/src/main/java/com/shub39/grit/viewmodels/TasksViewModel.kt (2)

31-105: Category selection and delay(200) logic is brittle; consider centralizing in observeTasks

The action handling mostly looks good after the move to TaskAction, but the way currentCategory is managed in the AddCategory, ReorderCategories, and DeleteCategory branches is a bit fragile:

• Several branches reset currentCategory to it.tasks.keys.firstOrNull() after a delay(200), relying on a timing assumption about when the repository and observeTasks() will have updated state.
• deleteCategory(category) also updates currentCategory before calling repo.deleteCategory(category), and then the TaskAction.DeleteCategory branch does another update after the artificial delay. That duplication makes it harder to reason about which value “wins” and when.
• The UX behavior also changed: after Add/ Reorder/ Delete, the selected category always jumps to the first key, which may not match user expectation (e.g., staying on the newly added category, or moving to a neighbor of the deleted one).

It would be more robust to derive currentCategory from the tasks map inside observeTasks() based on the new data (e.g., “if current selection was removed, pick the next/first category”), and avoid magic delays and extra updates inside the action branches. That keeps all category selection rules in one place and decouples them from arbitrary timing.

Also applies to: 136-160

---

136-138: Localize the default “Misc” category name

addDefault() currently hard-codes the "Misc" label. Given the broader move toward generated Res.string.* usage in this PR, it would be good to move this string into shared resources as well so it can be localized and kept consistent across platforms.

app/build.gradle.kts (1)

13-14: Gradle wiring for shared core and Compose MPP looks reasonable; verify plugin/dependency alignment

The app module’s Gradle changes line up with the KMP refactor:

• Adding implementation(project(":shared:core")) is the right way to pull in the shared core UI/domain.
• Centralizing compileSdk, minSdk, and targetSdk via libs.versions.* improves consistency across modules.
• Switching to compose.* and libs.material3 / libs.navigation.compose matches the move to Compose Multiplatform dependencies.

Given the mix of plugins (android.application, jetbrains.kotlin.android, composeMultiplatform, compose-compiler), it’s worth double‑checking against the current Compose Multiplatform docs that this combination is officially supported for an Android app module (and that the compose-multiplatform and Compose library versions from the catalog are compatible with the Kotlin version you’re using).

Also applies to: 24-30, 124-151

gradle/libs.versions.toml (1)

2-35: Version catalog fits the MPP direction; watch KSP/Kotlin and toolchain compatibility

The catalog updates look aligned with the broader refactor:

• New entries for compileSdk, minSdk, targetSdk, compose-multiplatform, composeHotReload, Koin, kotlinx-datetime, and coroutines Swing support the shared core and new platform targets.
• Switching material3 to org.jetbrains.compose.material3:material3 and navigation to org.jetbrains.androidx.navigation:navigation-compose matches the Compose Multiplatform dependency set.

A couple of things to keep an eye on:

• Kotlin is set to 2.2.21 while KSP is 2.3.0. KSP versions are usually tightly coupled to the Kotlin compiler version; a mismatch here can lead to “incompatible KSP” build failures. It’s safer to keep them in lockstep or confirm that this combo is explicitly supported.
• The AGP (agp), compose-multiplatform, and Kotlin versions should all be checked together against the current Gradle/Compose compatibility matrix to avoid subtle tooling issues.

Also applies to: 44-45, 54-67, 70-71, 83-83, 85-96

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: istudyatuni
Repo: shub39/Grit PR: 103
File: app/src/main/res/values-ru/strings.xml:0-0
Timestamp: 2025-07-05T13:36:09.250Z
Learning: When adding plural resources for Russian strings in Android apps, switching from `stringResource()` to `getQuantityString()` (or `pluralStringResource()` in Compose) creates breaking changes for existing translations. A practical approach is to add commented-out plural forms in the Russian strings file for future migration while keeping the current string resources intact.