Refresh time-sensitive Smart Insights and recompute on clock updates

[9thLevelSoftware]

Motivation

• Ensure time-dependent insights use a fresh reference time so recommendations and readiness reflect the current clock instead of a static snapshot.
• Avoid stale results from engines that rely on nowMs by making recomputation triggerable when the current time changes.

Description

• Change nowMs to a mutable state (var nowMs by remember { mutableStateOf(currentTimeMillis()) }) and introduce nowRefreshIntervalMs to drive periodic updates.
• Use a captured fetchNowMs during initial data fetch and call repository methods with fetchNowMs - twentyEightDaysMs to avoid race conditions during load.
• Add a background LaunchedEffect loop with delay(nowRefreshIntervalMs) to update nowMs periodically and import delay.
• Add nowMs as a key to remember calls (e.g. weekly volume, balance analysis, neglected exercises, readiness) so insights recompute when the clock advances.

Testing

• No automated tests were run as part of this change.

---

Codex Task

---

Perform an AI-assisted review on

[gemini-code-assist]

Code Review

This pull request implements a background refresh mechanism for the current time in SmartInsightsTab, ensuring that time-sensitive insights are updated every minute. Feedback suggests fetching a larger data buffer from the repository to maintain a full 28-day window as time elapses and hoisting the training readiness computation to the top level for better architectural consistency.

[gemini-code-assist]

The sessionSummaries are fetched using a fixed 28-day window relative to the initial fetch time (fetchNowMs). However, as nowMs advances via the background loop, engines like ReadinessEngine and BalanceAnalysis use a sliding 28-day window relative to the current nowMs. This causes the effective data window to shrink over time (e.g., after 1 hour, the engine will only have 27 days and 23 hours of data within its required 28-day window). To ensure insights remain accurate as the clock ticks, consider fetching a larger buffer (e.g., 35 days).

Suggested change

	repository.getSessionSummariesSince(fetchNowMs - twentyEightDaysMs, profileId)
	repository.getSessionSummariesSince(fetchNowMs - (35L * 24 * 60 * 60 * 1000), profileId)

[gemini-code-assist]

For consistency and better maintainability, consider hoisting the readiness computation to the top level of SmartInsightsContent alongside the other insights (weekly volume, balance analysis, etc.), rather than inside the LazyColumn's item block.

Suggested change

	val weeklyVolume = remember(sessionSummaries, nowMs) {
	SmartSuggestionsEngine.computeWeeklyVolume(sessionSummaries, nowMs)
	}
	val weeklyVolume = remember(sessionSummaries, nowMs) {
	SmartSuggestionsEngine.computeWeeklyVolume(sessionSummaries, nowMs)
	}
	val readiness = remember(sessionSummaries, nowMs) {
	ReadinessEngine.computeReadiness(sessionSummaries, nowMs)
	}

[Copilot]

Pull request overview

This PR refreshes time-sensitive “Smart Insights” by turning the reference clock (nowMs) into mutable Compose state and periodically updating it so insight computations can be recomputed as time advances.

Changes:

• Make nowMs mutable Compose state and introduce a periodic refresh interval (nowRefreshIntervalMs).
• Capture a stable fetchNowMs for initial repository fetches to avoid time drift during loading.
• Key several remember(...) computations on nowMs so weekly volume, balance, neglected exercises, and readiness recompute on clock updates.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kilo-code-bot]

CRITICAL: Compose state mutations inside withContext(Dispatchers.IO) violate thread-safety. sessionSummaries is updated from a background thread. Collect data into local vars inside IO, then assign state after withContext returns on main thread.

[kilo-code-bot]

CRITICAL: Same thread-safety issue - exerciseLastPerformed mutated from background thread. Move assignment outside withContext(Dispatchers.IO) to main thread.

[kilo-code-bot]

CRITICAL: Same thread-safety issue - weightHistory mutated from background thread. Assign state on main thread to prevent crashes/inconsistent recompositions.

[kilo-code-bot]

SUGGESTION: Hoist readiness computation to top level alongside other insights (weeklyVolume, balanceAnalysis, etc.) for architectural consistency. Compute it once in the body block rather than inside LazyColumn item.

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	2

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/SmartInsightsTab.kt	215	Readiness computation should be hoisted to top level alongside other insights for architectural consistency
shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/SmartInsightsTab.kt	60	Unused import kotlinx.coroutines.IO (code uses Dispatchers.IO, not IO dispatcher)

Other Observations (not in diff)

✅ Resolved Issues

File	Line	Issue	Status
shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/SmartInsightsTab.kt	124-135	Compose state mutations inside withContext(Dispatchers.IO)	Fixed - Now uses Triple to collect data on IO thread, then assigns state on main thread

Files Reviewed (1 files)

• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/SmartInsightsTab.kt - 2 issues remaining

Fix these issues in Kilo Cloud

---

_{Reviewed by ling-2.6-1t-20260423:free · 3,405,716 tokens}