app/src/main/res/drawable/check_list.xml (1)

8-8: Hardcoded fill color won't adapt to dark/dynamic themes.

#B7B7B7 is baked in at the drawable level, so the icon will always render as static gray regardless of the active light/dark theme or Material You dynamic color. Prefer a theme attribute or @color resource so the tint adapts automatically.

🎨 Suggested fix

-      android:fillColor="#B7B7B7"/>
+      android:fillColor="@color/widget_icon_tint"/>

Define the token in res/values/colors.xml (and a dark-mode override in res/values-night/colors.xml):

<!-- res/values/colors.xml -->
<color name="widget_icon_tint">#B7B7B7</color>

<!-- res/values-night/colors.xml -->
<color name="widget_icon_tint">#E0E0E0</color>

Alternatively, if this drawable is always used inside an ImageView or AppCompatImageView, setting android:tint="?attr/colorControlNormal" at the usage site (or via a DrawableCompat.setTint call) achieves the same result without touching the drawable itself.

Given the summary notes that several other drawables (alarm.xml, analytics.xml, arrow_forward.xml, check_circle.xml, circle_border.xml, heat.xml, heat_outlined.xml, refresh.xml, view_week.xml) were also added in this PR, the same fix should be applied consistently across all of them.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/res/drawable/check_list.xml` at line 8, The drawable uses a
hardcoded android:fillColor="#B7B7B7" which prevents theme/dark-mode adaptation;
replace hardcoded literals in check_list.xml (and the other added drawables:
alarm.xml, analytics.xml, arrow_forward.xml, check_circle.xml,
circle_border.xml, heat.xml, heat_outlined.xml, refresh.xml, view_week.xml) with
a theme-aware reference such as `@color/widget_icon_tint` or an attribute like
?attr/colorControlNormal, and add corresponding color resources in
res/values/colors.xml and res/values-night/colors.xml (or ensure the attribute
is provided by your theme) so the icon tint adapts to light/dark/dynamic themes.

app/src/main/res/drawable/check_circle.xml (1)

8-8: Consider using a color resource or theme attribute instead of a hardcoded hex color.

#B7B7B7 won't adapt to light/dark theming. If the app already has a designated icon tint color (or uses dynamic theming), referencing it here keeps all icons consistent and automatically responsive to theme changes.

🎨 Proposed change using a color resource

Define the color once in res/values/colors.xml:

+ <color name="icon_tint_default">#B7B7B7</color>

Then reference it in the drawable:

-      android:fillColor="#B7B7B7"/>
+      android:fillColor="@color/icon_tint_default"/>

Alternatively, if the app supports theming via ?attr/, you could bind to a theme attribute so the icon color shifts automatically between light and dark modes.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/res/drawable/check_circle.xml` at line 8, Replace the hardcoded
hex fillColor in check_circle.xml (android:fillColor="#B7B7B7") with a color
resource or theme attribute so the icon adapts to theming; create or reuse a
color in res/values/colors.xml (e.g., ic_tint) or reference a theme attribute
(e.g., ?attr/iconTint) and update the android:fillColor in the drawable to use
that resource reference instead.

app/src/main/res/drawable/heat.xml (1)

8-8: Consider replacing the hardcoded fill color with a color resource or theme attribute.

#B7B7B7 is a static value that won't respond to dark/light theme switches. Using a named color resource (e.g., @color/icon_tint_default) or a theme attribute (e.g., ?attr/colorOnSurface) allows the icon to adapt automatically. Alternatively, leave the drawable untinted and apply app:tint at each usage site.

♻️ Proposed change

-      android:fillColor="#B7B7B7"/>
+      android:fillColor="?attr/colorOnSurface"/>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/res/drawable/heat.xml` at line 8, The drawable hardcodes a
static fill color ("android:fillColor=\"#B7B7B7\"") which prevents theme-aware
tinting; replace that literal with a color resource or theme attribute (e.g.,
use a named color like `@color/icon_tint_default` or a theme attribute like
?attr/colorOnSurface) or remove the fillColor attribute so the vector can be
tinted at usage via app:tint; update the heat.xml vector's android:fillColor to
reference the chosen resource/attribute or delete the attribute to enable
runtime tinting.

app/src/main/res/drawable/refresh.xml (1)

7-8: Consider using a theme-aware tint instead of a hardcoded fill color.

android:fillColor="#B7B7B7" is a fixed gray that won't respond to light/dark mode switching or Material You dynamic color. For widget icons in particular, the system theme can vary independently of the app theme, making adaptive coloring especially important.

♻️ Proposed refactor — switch to a theme-attributed tint

  <path
-     android:pathData="M480,800q-134,0 -227,-93t-93,-227..."
-     android:fillColor="#B7B7B7"/>
+     android:pathData="M480,800q-134,0 -227,-93t-93,-227..."
+     android:fillColor="@android:color/white"/>

Then apply the tint at the call site (e.g., in the widget RemoteViews) via setColorFilter, or define a dedicated color resource (e.g., @color/icon_on_widget) and reference it here — keeping the path fill neutral and controlling color externally.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/res/drawable/refresh.xml` around lines 7 - 8, The drawable
hardcodes android:fillColor="#B7B7B7" (in refresh.xml) which prevents
theme-aware coloring; remove or neutralize the fillColor (leave path fill
transparent or use a neutral color), and switch to tinting the vector at runtime
by applying a theme attribute or color resource (e.g., `@color/icon_on_widget` or
?attr/colorControlNormal) from the widget/RemoteViews—use
setColorFilter/setImageViewTintList or setImageViewBitmap with a tinted
bitmap—so the icon responds to light/dark/Material You; keep the existing
pathData intact and only change the fill handling and call sites that set the
tint.

app/src/main/res/drawable/arrow_forward.xml (1)

8-8: Replace hardcoded fill color with a theme attribute to ensure the icon adapts across dark and light themes.

The hardcoded color #B7B7B7 appears in at least six usage locations without tint applied (ChangelogDialog.kt, Changelog.kt, and multiple instances in RootPage.kt). This causes the icon to display as a fixed gray regardless of the active theme.

🎨 Proposed refactor

-      android:fillColor="#B7B7B7"/>
+      android:fillColor="?attr/colorOnSurfaceVariant"/>

This ensures the color adapts automatically without relying on tint application at each usage site.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/res/drawable/arrow_forward.xml` at line 8, Replace the hardcoded
fillColor="#B7B7B7" in arrow_forward.xml with a theme attribute so the drawable
adapts to dark/light themes; locate the android:fillColor attribute in
arrow_forward.xml and change it to reference an appropriate theme color
attribute (e.g., ?attr/colorOnSurface or
?attr/colorControlNormal/textColorSecondary depending on your design system),
then ensure usages (ChangelogDialog.kt, Changelog.kt, RootPage.kt) rely on the
drawable's theme-aware color rather than per-use tinting.

app/src/main/res/drawable/heat_outlined.xml (1)

8-8: All drawable icons in this project use the same hardcoded gray color—this is a consistent pattern, not an oversight.

The hardcoded #B7B7B7 appears in all 10 drawable XML files (alarm.xml, analytics.xml, arrow_forward.xml, check_circle.xml, check_list.xml, circle_border.xml, heat.xml, heat_outlined.xml, refresh.xml, view_week.xml). The project's color resources (colors.xml) currently define only Material Design palette colors (purples, teals, black, white) with no gray icon color token.

If the project is planned to support dark/light theming in future, all icon drawables should be refactored together to use a theme attribute or shared color resource, not individually. This would be a coordinated, project-wide change rather than isolated to this file.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/res/drawable/heat_outlined.xml` at line 8, The drawables
(including heat_outlined.xml) currently hardcode android:fillColor="#B7B7B7";
change these to reference a shared token instead of hardcoding—replace
android:fillColor with either a theme attribute (e.g., ?attr/iconColor) or a
color resource (e.g., `@color/icon_gray`) and update all 10 drawable files
(alarm.xml, analytics.xml, arrow_forward.xml, check_circle.xml, check_list.xml,
circle_border.xml, heat.xml, heat_outlined.xml, refresh.xml, view_week.xml)
consistently; then add the new color resource in colors.xml or declare the
attribute in your theme so icons will follow light/dark theming.

app/src/main/java/com/shub39/grit/habits/data/repository/HabitRepository.kt (1)

136-146: Missing .flowOn(Dispatchers.Default) for consistency and thread safety.

getHabitsWithAnalytics() uses .flowOn(Dispatchers.Default) to keep its combine/map work off the main thread. getHabitsWithStatus() performs equivalent CPU-bound work without that constraint, leaving it at the mercy of the collector's dispatcher.

♻️ Proposed fix

 override fun getHabitsWithStatus(): Flow<List<Pair<Habit, Boolean>>> {
     return habits.combine(habitStatuses) { habitsFlow, statusFlow ->
         habitsFlow.map { habit ->
             val dates = statusFlow
                 .filter { it.habitId == habit.id }
                 .map { it.date }

             habit to dates.any { it == LocalDate.now() }
         }
-    }
+    }.flowOn(Dispatchers.Default)
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/shub39/grit/habits/data/repository/HabitRepository.kt`
around lines 136 - 146, The getHabitsWithStatus() implementation does CPU-bound
combine/map work but lacks thread confinement; update the function
(getHabitsWithStatus) to apply .flowOn(Dispatchers.Default) to the returned Flow
so the combine/map runs off the main thread, and add an import for
kotlinx.coroutines.Dispatchers if necessary; ensure the return type remains
Flow<List<Pair<Habit, Boolean>>> and place .flowOn(Dispatchers.Default) after
the combine block.

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

5-9: data object adds unnecessary data-class semantics to a constants holder.

Plain object suffices since toString, equals, and hashCode generated by data object serve no purpose here.

♻️ Proposed fix

-data object WidgetSize {
+object WidgetSize {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/shub39/grit/widgets/WidgetSize.kt` around lines 5 - 9,
Replace the unnecessary data object with a plain singleton object: change the
declaration of WidgetSize from a `data object` to `object WidgetSize` so the
constants (Width2, Width4, Height1, Height2) remain accessible but no data-class
semantics (generated equals/hashCode/toString) are created for this constants
holder; update any imports/usages if needed to reflect the object name remains
the same.

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

77-95: updateAll races ahead of the DB write, momentarily showing stale data.

onUpdateHabit launches coroutine A (DB write) and onUpdateWidget independently launches coroutine B (updateAll). Coroutine B typically finishes first, causing the widget to re-render from the Flow's current (pre-write) state before the DB write completes. Move updateAll inside the DB-write coroutine so it fires only after the mutation is committed.

♻️ Proposed fix

-onUpdateHabit = { habitWithStatus ->
-    scope.launch {
-        if (habitWithStatus.second) {
-            repo.deleteHabitStatus(
-                habitId = habitWithStatus.first.id,
-                date = LocalDate.now()
-            )
-        } else {
-            repo.insertHabitStatus(
-                habitStatus = HabitStatus(
-                    habitId = habitWithStatus.first.id,
-                    date = LocalDate.now()
-                )
-            )
-        }
-    }
-},
-onUpdateWidget = {
-    scope.launch { [email protected](context) }
-}
+onUpdateHabit = { habitWithStatus ->
+    scope.launch {
+        if (habitWithStatus.second) {
+            repo.deleteHabitStatus(
+                habitId = habitWithStatus.first.id,
+                date = LocalDate.now()
+            )
+        } else {
+            repo.insertHabitStatus(
+                habitStatus = HabitStatus(
+                    habitId = habitWithStatus.first.id,
+                    date = LocalDate.now()
+                )
+            )
+        }
+        [email protected](context)
+    }
+},
+onUpdateWidget = {
+    scope.launch { [email protected](context) }
+}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/shub39/grit/widgets/habit_overview_widget/HabitOverviewWidget.kt`
around lines 77 - 95, The widget update races because onUpdateHabit and
onUpdateWidget launch separate coroutines; change onUpdateHabit so the same
coroutine that calls repo.deleteHabitStatus or repo.insertHabitStatus also calls
[email protected](context) after the suspend DB call completes
(i.e., inside the scope.launch in the onUpdateHabit lambda), ensuring updateAll
runs only after repo.deleteHabitStatus / repo.insertHabitStatus finish rather
than launching an independent coroutine.

app/src/main/java/com/shub39/grit/core/domain/GritDatastore.kt (1)

51-52: Minor naming inconsistency: update vs set convention.

All other setter methods in this interface use the set* prefix (e.g., setAppTheme, setSeedColor, setAmoledPref), but this one uses updateLastChangelogShown. Consider renaming to setLastChangelogShown for consistency, or vice versa if update is the preferred naming going forward.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/shub39/grit/core/domain/GritDatastore.kt` around lines
51 - 52, The method name updateLastChangelogShown is inconsistent with the rest
of the interface’s setter naming (setAppTheme, setSeedColor, setAmoledPref);
rename updateLastChangelogShown to setLastChangelogShown (and update all call
sites and implementations of GritDatastore along with any tests) so the
getter/getter pair is getLastChangelogShown / setLastChangelogShown and naming
is consistent across the interface.

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

96-107: Cycling logic is safe due to UI gating, but consider a guard.

When sortedData is empty, currentIndex is 0 and sortedData.size - 1 is -1, so the else branch would call sortedData[1] causing an IndexOutOfBoundsException. This is safe in practice because the arrow button is only rendered when habitWithAnalytics != null (Line 181). However, a defensive check would prevent a crash if the UI structure changes.

🛡️ Defensive guard

                         onChangeHabit = {
+                            if (sortedData.isEmpty()) return@Content
                             val nextId = if (currentIndex == sortedData.size - 1) {
                                 sortedData.first().habit.id
                             } else {
                                 sortedData[currentIndex + 1].habit.id
                             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/shub39/grit/widgets/habit_streak_widget/HabitStreakWidget.kt`
around lines 96 - 107, Add a defensive guard in the onChangeHabit block to
handle an empty sortedData before computing nextId: check that
sortedData.isNotEmpty() (or sortedData.firstOrNull() != null) and that
currentIndex is within bounds, and if not, return early (or skip calling
updateHabitId). Specifically update the onChangeHabit lambda that computes
nextId using currentIndex and sortedData, ensuring you only call scope.launch {
updateHabitId(context, id, nextId) } when a valid nextId was determined from
sortedData to avoid IndexOutOfBoundsException.

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

75-108: Consider providing stable keys for lazy list items.

The forEach + nested item/items approach works but lacks stable keys. If the changelog data ever changes during the composable's lifetime (or for animation/state restoration), keyed items are safer. Since the data is static today this is a minor hardening.

Suggested improvement

             changelog.forEach { versionEntry ->
                 item(key = "header-${versionEntry.version}") {
                     Text(
                         text = "# ${versionEntry.version}",
                         ...
                     )
                 }
 
-                items(versionEntry.changes) { change ->
+                items(
+                    items = versionEntry.changes,
+                    key = { "${versionEntry.version}-$it" }
+                ) { change ->
                     ...
                 }
 
                 item(key = "spacer-${versionEntry.version}") {
                     Spacer(modifier = Modifier.height(16.dp))
                 }
             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/shub39/grit/core/presentation/settings/ui/section/Changelog.kt`
around lines 75 - 108, Replace the current changelog.forEach + nested item/items
usage with keyed lazy list entries so items have stable keys: iterate the
top-level list using LazyListScope.items(changelog, key = { it.version })
(instead of changelog.forEach) so each version header and its content are tied
to the version key, and for the inner changes use items(versionEntry.changes,
key = { change /* or index if duplicates possible */ }) (instead of
items(versionEntry.changes) without keys) or supply item(key =
versionEntry.version) for the header; update references to the existing item and
items(...) calls accordingly to ensure stable keys for both version entries and
change rows.

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

36-42: Unhandled exceptions will silently cancel the coroutine and skip remaining widget previews.

If setWidgetPreviews throws for any receiver (e.g., missing widget metadata), subsequent receivers in the same coroutine won't get their previews set. Consider wrapping each call or launching independently.

Also, MainScope() is a fire-and-forget scope here—acceptable for Application, but if you ever need structured shutdown, store the scope reference and cancel it.

Suggested improvement

-            `@SuppressLint`("CheckResult")
-            MainScope().launch {
-                manager.setWidgetPreviews(HabitOverviewWidgetReceiver::class)
-                manager.setWidgetPreviews(HabitStreakWidgetReceiver::class)
-                manager.setWidgetPreviews(AllTasksWidgetReceiver::class)
-                manager.setWidgetPreviews(HabitWeekChartWidgetReceiver::class)
-            }
+            val widgetReceivers = listOf(
+                HabitOverviewWidgetReceiver::class,
+                HabitStreakWidgetReceiver::class,
+                AllTasksWidgetReceiver::class,
+                HabitWeekChartWidgetReceiver::class,
+            )
+            `@SuppressLint`("CheckResult")
+            MainScope().launch {
+                widgetReceivers.forEach { receiver ->
+                    try {
+                        manager.setWidgetPreviews(receiver)
+                    } catch (e: Exception) {
+                        android.util.Log.e("GritApplication", "Failed to set widget preview for $receiver", e)
+                    }
+                }
+            }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/shub39/grit/app/GritApplication.kt` around lines 36 -
42, The coroutine launched with MainScope().launch calls
manager.setWidgetPreviews for multiple receivers and will silently stop if any
call throws; change to either wrap each
manager.setWidgetPreviews(HabitOverviewWidgetReceiver::class),
manager.setWidgetPreviews(HabitStreakWidgetReceiver::class),
manager.setWidgetPreviews(AllTasksWidgetReceiver::class),
manager.setWidgetPreviews(HabitWeekChartWidgetReceiver::class) in individual
try/catch blocks to log/handle exceptions so one failure doesn't cancel the
rest, or launch separate coroutines per receiver (e.g., scope.launch { ... }) so
failures are isolated; also persist the MainScope() as a field (instead of
fire-and-forget) so you can cancel it during shutdown if you need structured
lifecycle management.

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

138-146: getChangeLogs() is already called from within onStart, which runs in the flow collection context — the extra viewModelScope.launch is redundant but harmless.

The onStart block already executes in a coroutine context (it's a flow operator). The inner viewModelScope.launch creates a separate coroutine that runs independently, meaning if the subscriber disappears immediately, this coroutine still completes. This is consistent with the existing observeJob() pattern on Line 148, so no change is strictly needed, but worth noting for awareness.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/shub39/grit/viewmodels/SettingsViewModel.kt` around
lines 138 - 146, getChangeLogs() launches a redundant coroutine inside a caller
that is already in a flow context; remove the inner viewModelScope.launch and
perform the work directly so the call runs in the existing coroutine (i.e.,
replace the viewModelScope.launch block in getChangeLogs() with a direct
_state.update that assigns changelog = changelogManager.changelogs.first()),
keeping the same use of _state.update and changelogManager.changelogs.first();
if callers expect a suspending call, make getChangeLogs a suspend function or
ensure callers invoke it from a coroutine context consistent with observeJob().

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

122-122: In DEBUG builds, the changelog dialog will always appear on every app launch.

The condition BuildConfig.DEBUG || lastShownChangelog != BuildConfig.VERSION_NAME short-circuits in debug mode, so the dialog shows every time regardless of the persisted version. If this is intentional for development/testing, consider adding a brief comment to clarify intent.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/shub39/grit/viewmodels/MainViewModel.kt` at line 122,
Split the current combined condition in MainViewModel so intent is explicit:
replace the single if (BuildConfig.DEBUG || lastShownChangelog !=
BuildConfig.VERSION_NAME) with two branches — one for debug-only behavior (if
(BuildConfig.DEBUG) { /* show changelog for testing */ }) and a separate branch
checking persisted version (else if (lastShownChangelog !=
BuildConfig.VERSION_NAME) { ... }), or if you prefer to keep a single condition,
add a clear comment next to the condition explaining that showing the changelog
on every debug launch is intentional for testing; reference the
BuildConfig.DEBUG flag, lastShownChangelog variable and BuildConfig.VERSION_NAME
in your change.

app/src/main/java/com/shub39/grit/core/presentation/settings/ui/section/Changelog.kt (2)

38-41: Consider renaming to ChangelogScreen to avoid shadowing the Changelog type alias.

The composable function name Changelog is identical to the imported type alias Changelog = List<VersionEntry> (line 26). While Kotlin resolves this by context, it hampers readability at call sites and in navigation graphs. A name like ChangelogScreen would disambiguate cleanly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/shub39/grit/core/presentation/settings/ui/section/Changelog.kt`
around lines 38 - 41, Rename the composable function Changelog to
ChangelogScreen to avoid shadowing the Changelog type alias (Changelog =
List<VersionEntry>). Update the function declaration public symbol
Changelog(...) to ChangelogScreen(...), and update all call sites and navigation
references that invoke Changelog (including any NavGraph routes, composable()
usages, and imports) to use ChangelogScreen so the type alias and composable are
no longer identically named.

---

74-106: Provide stable keys for LazyColumn items to improve recomposition efficiency.

The item and items calls inside the forEach loop lack keys. If the changelog list changes (e.g., new version prepended), LazyColumn will recompose all items instead of only the diff. Using the version string and change text as keys makes diffing efficient and also preserves scroll state.

Proposed fix

             changelog.forEach { versionEntry ->
-                item {
+                item(key = "header-${versionEntry.version}") {
                     Text(
                         text = versionEntry.version,
                         style = MaterialTheme.typography.headlineLarge.copy(
                             fontWeight = FontWeight.Bold
                         )
                     )
                 }

-                items(versionEntry.changes) { change ->
+                items(
+                    items = versionEntry.changes,
+                    key = { "${versionEntry.version}-$it" }
+                ) { change ->
                     Row(

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/shub39/grit/core/presentation/settings/ui/section/Changelog.kt`
around lines 74 - 106, The LazyColumn entries produced inside changelog.forEach
lack stable keys; update the header and spacer item calls to use item(key =
versionEntry.version) and the changes list to use items(versionEntry.changes,
key = { change -> change }) (or a composite key like
"${versionEntry.version}-$change" if change text may duplicate) so headers,
change rows and spacers have stable keys tied to versionEntry.version and
change; adjust the spacer item to a keyed item (e.g., key =
"spacer-${versionEntry.version}") to ensure correct diffing and preserved scroll
state.