Add Discord Rich Presence for desktop

[tajemniktv]

Summary

Add Discord Rich Presence for the desktop build of TajsOS as an optional integration.

This should be treated as a platform feature, not core app logic. The implementation should reflect TajsOS state cleanly without infecting shared architecture with Discord-specific concerns.

Blocked by

• Introduce native C++ integration boundary for desktop platform features #337

Goals

• show lightweight, tasteful TajsOS presence in Discord while using the desktop app
• expose it as an opt-in integration in settings
• keep presence updates coarse and meaningful rather than noisy
• model presence through a small app-facing interface so non-desktop platforms can use a no-op implementation

Suggested product behavior

Examples of useful presence states:

• Planning tasks
• Writing a note
• Reviewing protocols
• In Now
• In Knowledge
• In Review

Potential metadata:

• current screen or lens
• optional session timestamp
• small/large app assets if supported

Requirements

• desktop-first implementation
• fully optional / user-controllable
• no hard dependency from shared/common domain logic onto Discord SDK details
• no web/platform assumptions beyond what is actually supported
• updates should be event-driven and coarse-grained, not spammy
• graceful fallback when Discord is unavailable or not running

Technical direction

• define a small presence abstraction in shared or platform-facing app code
• provide a desktop implementation and no-op implementations elsewhere
• keep Discord-specific code isolated behind the desktop/native boundary
• avoid letting this turn into a broad architecture shortcut for random platform-specific hacks

Acceptance criteria

• user can enable/disable Discord Rich Presence from settings
• desktop app can publish meaningful presence state to Discord
• app remains stable if Discord is not installed/running or integration fails
• shared architecture stays clean and platform boundaries remain explicit
• implementation follows the native integration boundary tracked in Introduce native C++ integration boundary for desktop platform features #337

Notes

This issue is intentionally desktop-scoped for now. If Android or iOS support ever becomes viable and worth the complexity, that should be handled later as separate platform work rather than stretching this issue beyond MVP sanity.

[github-actions]

This issue has been inactive for a long period. It is now marked stale. Comment or remove the stale label if this is still relevant.

[coderabbitai]

Coding Plan

Summary

• Define a small PresenceService interface and a Discord-neutral PresenceState model in commonMain, with a NoOpPresenceService and an expect/actual factory, so shared code never depends on Discord.
• Add a persisted, desktop-gated opt-in toggle using the existing PreferencesRepository → MainViewModel → settings-block pattern.
• Implement the real Discord integration only in jvmMain, behind the interface, with graceful degradation modeled on IcsCalendarProvider.safeFetch.
• Drive coarse, event-driven presence updates from App.kt using existing screen, mode, and session state, with disposal on teardown and a no-op path on all non-desktop targets.

Design Choices

Design Choice 1: Discord Rich Presence transport for the desktop implementation

Options Considered:

1. Implement a minimal Kotlin/JVM Discord IPC client directly (connect to the local discord-ipc-* socket, perform the handshake, send SET_ACTIVITY frames). No native binaries. Full control over reconnect and framing.
2. Add a maintained third-party JVM Discord IPC library through the version catalog and wrap it.

Chosen Option: 2

Rationale: The official discord-rpc binding is deprecated. Option 2 is the plan baseline because it minimizes protocol-level code and matches the codebase convention of scoping a JVM-only library to jvmMain.dependencies. The implementer may substitute Option 1 if no library passes an activity and maintenance audit. Both options sit behind the same PresenceService interface, so the choice does not affect shared architecture.

Design Choice 2: Visibility of the settings toggle across platforms

Options Considered:

1. Add a small platform capability value (an expect val or reuse a platform check) and render the toggle only on desktop.
2. Render the toggle on all platforms; on non-desktop targets the no-op PresenceService makes it inert.

Chosen Option: 1

Rationale: There is no existing capability-detection flag (isDesktop) in the codebase today. Showing an on/off toggle that does nothing on mobile is poor UX. The ticket requires explicit platform boundaries. A small desktop capability flag keeps the setting relevant only where it functions and avoids a misleading control on mobile.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Define the presence abstraction and state model

This phase creates the small app-facing interface and its cross-platform contract. It introduces no Discord-specific code. It establishes the native integration boundary referenced by #337: shared code depends only on the interface and a plain state model.

Task 1: Define the `PresenceService` interface and `PresenceState` model

Create the app-facing contract that shared code uses to publish presence.

• Create a new presence package under composeApp/src/commonMain/kotlin/com/tajemniktv/tajsos/ui/platform/presence/ (adjacent to the existing platform glue).
• Define PresenceService with coarse operations: update(state: PresenceState), clear(), and close().
• Define PresenceState as a plain data class with fields for details (primary line), state (secondary line), an optional startTimestampMs: Long? (session start), and optional asset key strings (largeImageKey, smallImageKey, largeImageText).
• Keep the model free of any Discord type. The model must carry only TajsOS-neutral data.

Task 2: Provide the no-op implementation and the platform factory

Provide a default no-op implementation and the per-platform factory to obtain a PresenceService.

• Add NoOpPresenceService in commonMain (in the same presence package) with empty method bodies.
• Declare expect fun createPresenceService(): PresenceService in commonMain.
• Add actual fun createPresenceService(): PresenceService = NoOpPresenceService() in androidMain, iosMain, and webMain source sets of composeApp.
• Defer the jvmMain actual to Phase 3.

Task 3: Define the presence mapping from app state to `PresenceState`

Translate TajsOS state into coarse presence text in shared code, with no Discord coupling.

• Add a pure mapping function in the presence package that takes the current Screen, the current ModeEntity?, and the active FocusSessionEntity?, and returns a PresenceState.
• Map screens and modes to the tasteful states named in the ticket (for example, Screen.Tasks to "Planning tasks", Screen.Notes/note editing to "Writing a note", Screen.Protocols to "Reviewing protocols", plus mode-derived labels such as "In Now", "In Knowledge", "In Review").
• Use activeSession.startedAt as startTimestampMs when a session is active; otherwise leave it null.
• Read all user-visible labels from strings.xml resources. Do not hardcode presence text.

🤖 Prompt for AI agents

Implement the presence abstraction layer in commonMain. Goal: create a
Discord-neutral interface and state model that shared code uses to publish
presence, with a no-op default and per-platform factory.

- Create a new `presence` package under
`composeApp/src/commonMain/kotlin/com/tajemniktv/tajsos/ui/platform/presence/`,
next to the existing `platform` glue.
- Define a `PresenceService` interface with methods `update(state:
PresenceState)`, `clear()`, and `close()`.
- Define `PresenceState` as a plain data class with `details` (primary line),
`state` (secondary line), optional `startTimestampMs: Long?`, and optional asset
key strings `largeImageKey`, `smallImageKey`, `largeImageText`. Do not reference
any Discord type in this model.
- Add `NoOpPresenceService` in the same package in `commonMain` with empty
method bodies.
- Declare `expect fun createPresenceService(): PresenceService` in `commonMain`.
- Add `actual fun createPresenceService(): PresenceService =
NoOpPresenceService()` in the `androidMain`, `iosMain`, and `webMain` source
sets of `composeApp`. Leave the `jvmMain` actual for a later phase.
- Add a pure mapping function in the `presence` package that accepts the current
`Screen`, the current `ModeEntity?`, and the active `FocusSessionEntity?`, and
returns a `PresenceState`.
- Map screens and modes to presence text: `Screen.Tasks` to "Planning tasks",
`Screen.Notes`/note editing to "Writing a note", `Screen.Protocols` to
"Reviewing protocols", plus mode-derived labels such as "In Now", "In
Knowledge", "In Review".
- Set `startTimestampMs` from `activeSession.startedAt` when a session is
active; otherwise leave it null.
- Source all user-visible labels from `strings.xml` resources. Do not hardcode
presence text in code.

Phase 2: Add the opt-in setting

This phase adds a user-controllable on/off setting that follows the existing toggle pattern. It persists the choice and exposes it as observable state. It gates visibility to desktop.

Task 1: Persist the setting in `PreferencesRepository`

Add the DataStore-backed persistence for the opt-in flag.

• Update shared/src/commonMain/kotlin/com/tajemniktv/tajsos/data/PreferencesRepository.kt.
• Add a DISCORD_RICH_PRESENCE_ENABLED boolean key, an isDiscordRichPresenceEnabled: Flow<Boolean> (default false), and an updateDiscordRichPresenceEnabled(enabled: Boolean) writer, mirroring the reduceMotion triple.

Task 2: Expose the setting in `MainViewModel`

Expose the flag as observable state and provide a setter.

• Update shared/src/commonMain/kotlin/com/tajemniktv/tajsos/ui/MainViewModel.kt.
• Add isDiscordRichPresenceEnabled: StateFlow<Boolean> sourced from preferencesRepository.isDiscordRichPresenceEnabled via stateIn(viewModelScope, SharingStarted.Eagerly, false).
• Add setDiscordRichPresenceEnabled(enabled: Boolean) that launches a coroutine calling the repository writer.

Task 3: Add the settings toggle row and desktop gating

Render the opt-in toggle in settings, visible only on desktop.

• Add a small desktop capability value (per Assumption 2) in the shared Platform abstraction (shared/src/commonMain/kotlin/com/tajemniktv/tajsos/Platform.kt) as an expect val isDesktop: Boolean, with true in jvmMain and false in the other source sets.
• Update SettingsDashboardContracts.kt to add isDiscordRichPresenceEnabled: Boolean, showDiscordRichPresence: Boolean (desktop gate), and onSetDiscordRichPresenceEnabled: (Boolean) -> Unit.
• Update the renderSettingsPreferences renderer in SettingsDashboardBlocks.kt to render a Switch row for Discord Rich Presence when showDiscordRichPresence is true, following the Biometric Lock row.
• Update SettingsScreen.kt (SettingsRoute) to collect the new StateFlow, set showDiscordRichPresence from the desktop capability value, and wire onSetDiscordRichPresenceEnabled = { viewModel.setDiscordRichPresenceEnabled(it) }.
• Add localized label and description strings to composeApp/src/commonMain/composeResources/values/strings.xml.

🤖 Prompt for AI agents

Add a persisted, desktop-gated opt-in toggle for Discord Rich Presence,
following the existing settings toggle pattern used elsewhere in the codebase.

- In
`shared/src/commonMain/kotlin/com/tajemniktv/tajsos/data/PreferencesRepository.kt`,
add a `DISCORD_RICH_PRESENCE_ENABLED` boolean key, an
`isDiscordRichPresenceEnabled: Flow<Boolean>` defaulting to `false`, and an
`updateDiscordRichPresenceEnabled(enabled: Boolean)` writer. Mirror the existing
`reduceMotion` key/flow/update triple.
- In `shared/src/commonMain/kotlin/com/tajemniktv/tajsos/ui/MainViewModel.kt`,
add `isDiscordRichPresenceEnabled: StateFlow<Boolean>` sourced from
`preferencesRepository.isDiscordRichPresenceEnabled` using
`stateIn(viewModelScope, SharingStarted.Eagerly, false)`. Add
`setDiscordRichPresenceEnabled(enabled: Boolean)` that launches a coroutine to
call the repository writer.
- Add a desktop capability value in the shared `Platform` abstraction at
`shared/src/commonMain/kotlin/com/tajemniktv/tajsos/Platform.kt`: declare
`expect val isDesktop: Boolean`, set to `true` in `jvmMain` and `false` in the
other source sets.
- Update `SettingsDashboardContracts.kt` to add fields
`isDiscordRichPresenceEnabled: Boolean`, `showDiscordRichPresence: Boolean` (the
desktop gate), and `onSetDiscordRichPresenceEnabled: (Boolean) -> Unit`.
- Update the `renderSettingsPreferences` renderer in
`SettingsDashboardBlocks.kt` to add a `Switch` row for Discord Rich Presence,
shown only when `showDiscordRichPresence` is true. Follow the existing Biometric
Lock row as a pattern.
- Update `SettingsScreen.kt` (`SettingsRoute`) to collect the new `StateFlow`,
set `showDiscordRichPresence` from the desktop capability value, and wire
`onSetDiscordRichPresenceEnabled = { viewModel.setDiscordRichPresenceEnabled(it)
}`.
- Add localized label and description strings for the new toggle to
`composeApp/src/commonMain/composeResources/values/strings.xml`.

Phase 3: Implement the desktop Discord integration and wire updates

This phase adds the JVM-only Discord implementation behind the interface, isolates all Discord code in jvmMain, and drives coarse, event-driven updates from App.kt. It ensures graceful fallback when Discord is not running.

Task 1: Add the JVM-only Discord library to the version catalog

Scope the Discord dependency to the desktop target only.

• Add a [versions] entry and a [libraries] entry for the chosen Discord IPC library in gradle/libs.versions.toml, following the logback convention.
• Reference the library only inside jvmMain.dependencies { } in composeApp/build.gradle.kts, alongside logback and kotlinx.coroutinesSwing.
• If Assumption 1 Option 1 is chosen instead, skip the library entry and implement the IPC client directly in jvmMain.

Task 2: Implement `DiscordPresenceService` in `jvmMain`

Wrap the Discord IPC client behind the PresenceService interface with graceful degradation.

• Create DiscordPresenceService in composeApp/src/jvmMain/kotlin/com/tajemniktv/tajsos/ui/platform/presence/.
• Connect to Discord using a configured application/client id. Map PresenceState fields to the library's SET_ACTIVITY fields (details, state, timestamps, asset keys).
• Apply a safeFetch-style wrapper (as in IcsCalendarProvider): rethrow CancellationException, catch and log all other exceptions, and never throw out of update/clear/close.
• If Discord is not installed or not running, keep the service inert and retry connection lazily on the next update. The app must remain stable in this case.
• Provide actual fun createPresenceService(): PresenceService = DiscordPresenceService(...) in jvmMain, completing the factory from Task 1.2.

Task 3: Observe app state and publish coarse presence updates

Drive event-driven, non-spammy updates from shared UI code.

• In App.kt (commonMain), obtain a PresenceService via remember { createPresenceService() } and dispose it with a DisposableEffect onDispose { presenceService.close() } (following the existing DisposableEffect idiom).
• Add a LaunchedEffect keyed on isDiscordRichPresenceEnabled, currentScreen, currentMode, and activeSession.
• When the flag is enabled, compute PresenceState with the Task 1.3 mapper and call presenceService.update(state). When the flag is disabled, call presenceService.clear().
• Keep updates coarse: react only to screen, mode, and session-start changes. Debounce rapid changes (for example, distinctUntilChanged plus a short delay), following the existing LaunchedEffect(windowState) debounce pattern in jvmMain/main.kt.
• Because non-desktop targets return NoOpPresenceService, this observer is inert off desktop and adds no platform assumptions.

Task 4: Ensure clean shutdown on the desktop window

Release the Discord connection when the desktop app closes.

• The DisposableEffect in App.kt covers disposal on the composition teardown. Confirm it runs on desktop exit.
• If the composition does not tear down before exitApplication(), additionally call presenceService.close() in the Window(onCloseRequest = ...) block in composeApp/src/jvmMain/kotlin/com/tajemniktv/tajsos/main.kt before exitApplication().

🤖 Prompt for AI agents

Implement the JVM-only Discord Rich Presence integration and wire it to app
state. Goal: publish coarse presence updates on desktop only, with graceful
degradation, and keep all Discord-specific code inside `jvmMain`.

- Add a `[versions]` entry and a `[libraries]` entry in
`gradle/libs.versions.toml` for the chosen Discord IPC library, following the
`logback` convention. Reference the library only inside `jvmMain.dependencies {
}` in `composeApp/build.gradle.kts`, alongside `logback` and
`kotlinx.coroutinesSwing`. If a direct IPC client implementation is chosen
instead of a library, skip the version catalog entry and implement the IPC
client directly in `jvmMain`.
- Create `DiscordPresenceService` in
`composeApp/src/jvmMain/kotlin/com/tajemniktv/tajsos/ui/platform/presence/`.
Connect to Discord using a configured application/client id. Map `PresenceState`
fields (details, state, timestamps, asset keys) to the library's `SET_ACTIVITY`
fields.
- Apply a `safeFetch`-style wrapper modeled on `IcsCalendarProvider`: rethrow
`CancellationException`, catch and log all other exceptions, and never let
`update`, `clear`, or `close` throw.
- If Discord is not installed or not running, keep `DiscordPresenceService`
inert and retry the connection lazily on the next `update` call. The app must
stay stable in this state.
- Provide `actual fun createPresenceService(): PresenceService =
DiscordPresenceService(...)` in `jvmMain` to complete the expect/actual factory
started in Phase 1.
- In `App.kt` (commonMain), obtain a `PresenceService` via `remember {
createPresenceService() }`. Dispose it using a `DisposableEffect` with
`onDispose { presenceService.close() }`, following the existing
`DisposableEffect` idiom in the codebase.
- Add a `LaunchedEffect` keyed on `isDiscordRichPresenceEnabled`,
`currentScreen`, `currentMode`, and `activeSession`. When the flag is enabled,
compute `PresenceState` using the Phase 1 mapper and call
`presenceService.update(state)`. When the flag is disabled, call
`presenceService.clear()`.
- Keep updates coarse. React only to screen, mode, and session-start changes.
Debounce rapid changes, for example with `distinctUntilChanged` plus a short
`delay`, following the existing `LaunchedEffect(windowState)` debounce pattern
in `jvmMain/main.kt`.
- Note that on non-desktop targets, `createPresenceService()` returns
`NoOpPresenceService`, so this observer is inert there and introduces no new
platform assumptions.
- Confirm the `DisposableEffect` in `App.kt` runs on desktop exit. If the
composition does not tear down before `exitApplication()`, also call
`presenceService.close()` in the `Window(onCloseRequest = ...)` block in
`composeApp/src/jvmMain/kotlin/com/tajemniktv/tajsos/main.kt`, before
`exitApplication()` executes.

Research

TajsOS is a Kotlin Multiplatform Compose app. It uses manual dependency injection through a SharedModule class (no Koin) and the expect/actual pattern for platform glue (for example, ClipboardUtils). Platform entry points (jvmMain/main.kt, MainActivity.kt, MainViewController.kt, web main.kt) construct SharedModule and call App(viewModel = ...).

Settings toggles follow a consistent pattern: a DataStore key/flow/update triple in PreferencesRepository, a StateFlow plus setter in MainViewModel, a field plus callback in SettingsDashboardContext, a Switch row in a SettingsDashboardBlocks renderer, and localized strings in strings.xml.

App.kt (commonMain) has simultaneous access to MainViewModel state (currentMode, activeSession) and navigation state (Screen.fromRoute(currentDestination?.route)). The desktop entry point jvmMain/main.kt uses application { Window(onCloseRequest = ...) { LaunchedEffect(...) } }, which provides clear startup and shutdown hooks.

The CalendarProvider/CalendarManager pair is the existing precedent for an interface-based external integration with graceful degradation (a safeFetch wrapper that swallows and logs errors, rethrows CancellationException).

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the presence abstraction layer in commonMain. Goal: create a
Discord-neutral interface and state model that shared code uses to publish
presence, with a no-op default and per-platform factory.

- Create a new `presence` package under
`composeApp/src/commonMain/kotlin/com/tajemniktv/tajsos/ui/platform/presence/`,
next to the existing `platform` glue.
- Define a `PresenceService` interface with methods `update(state:
PresenceState)`, `clear()`, and `close()`.
- Define `PresenceState` as a plain data class with `details` (primary line),
`state` (secondary line), optional `startTimestampMs: Long?`, and optional asset
key strings `largeImageKey`, `smallImageKey`, `largeImageText`. Do not reference
any Discord type in this model.
- Add `NoOpPresenceService` in the same package in `commonMain` with empty
method bodies.
- Declare `expect fun createPresenceService(): PresenceService` in `commonMain`.
- Add `actual fun createPresenceService(): PresenceService =
NoOpPresenceService()` in the `androidMain`, `iosMain`, and `webMain` source
sets of `composeApp`. Leave the `jvmMain` actual for a later phase.
- Add a pure mapping function in the `presence` package that accepts the current
`Screen`, the current `ModeEntity?`, and the active `FocusSessionEntity?`, and
returns a `PresenceState`.
- Map screens and modes to presence text: `Screen.Tasks` to "Planning tasks",
`Screen.Notes`/note editing to "Writing a note", `Screen.Protocols` to
"Reviewing protocols", plus mode-derived labels such as "In Now", "In
Knowledge", "In Review".
- Set `startTimestampMs` from `activeSession.startedAt` when a session is
active; otherwise leave it null.
- Source all user-visible labels from `strings.xml` resources. Do not hardcode
presence text in code.
===============================================================================

Task: 2

Add a persisted, desktop-gated opt-in toggle for Discord Rich Presence,
following the existing settings toggle pattern used elsewhere in the codebase.

- In
`shared/src/commonMain/kotlin/com/tajemniktv/tajsos/data/PreferencesRepository.kt`,
add a `DISCORD_RICH_PRESENCE_ENABLED` boolean key, an
`isDiscordRichPresenceEnabled: Flow<Boolean>` defaulting to `false`, and an
`updateDiscordRichPresenceEnabled(enabled: Boolean)` writer. Mirror the existing
`reduceMotion` key/flow/update triple.
- In `shared/src/commonMain/kotlin/com/tajemniktv/tajsos/ui/MainViewModel.kt`,
add `isDiscordRichPresenceEnabled: StateFlow<Boolean>` sourced from
`preferencesRepository.isDiscordRichPresenceEnabled` using
`stateIn(viewModelScope, SharingStarted.Eagerly, false)`. Add
`setDiscordRichPresenceEnabled(enabled: Boolean)` that launches a coroutine to
call the repository writer.
- Add a desktop capability value in the shared `Platform` abstraction at
`shared/src/commonMain/kotlin/com/tajemniktv/tajsos/Platform.kt`: declare
`expect val isDesktop: Boolean`, set to `true` in `jvmMain` and `false` in the
other source sets.
- Update `SettingsDashboardContracts.kt` to add fields
`isDiscordRichPresenceEnabled: Boolean`, `showDiscordRichPresence: Boolean` (the
desktop gate), and `onSetDiscordRichPresenceEnabled: (Boolean) -> Unit`.
- Update the `renderSettingsPreferences` renderer in
`SettingsDashboardBlocks.kt` to add a `Switch` row for Discord Rich Presence,
shown only when `showDiscordRichPresence` is true. Follow the existing Biometric
Lock row as a pattern.
- Update `SettingsScreen.kt` (`SettingsRoute`) to collect the new `StateFlow`,
set `showDiscordRichPresence` from the desktop capability value, and wire
`onSetDiscordRichPresenceEnabled = { viewModel.setDiscordRichPresenceEnabled(it)
}`.
- Add localized label and description strings for the new toggle to
`composeApp/src/commonMain/composeResources/values/strings.xml`.
===============================================================================

Task: 3

Implement the JVM-only Discord Rich Presence integration and wire it to app
state. Goal: publish coarse presence updates on desktop only, with graceful
degradation, and keep all Discord-specific code inside `jvmMain`.

- Add a `[versions]` entry and a `[libraries]` entry in
`gradle/libs.versions.toml` for the chosen Discord IPC library, following the
`logback` convention. Reference the library only inside `jvmMain.dependencies {
}` in `composeApp/build.gradle.kts`, alongside `logback` and
`kotlinx.coroutinesSwing`. If a direct IPC client implementation is chosen
instead of a library, skip the version catalog entry and implement the IPC
client directly in `jvmMain`.
- Create `DiscordPresenceService` in
`composeApp/src/jvmMain/kotlin/com/tajemniktv/tajsos/ui/platform/presence/`.
Connect to Discord using a configured application/client id. Map `PresenceState`
fields (details, state, timestamps, asset keys) to the library's `SET_ACTIVITY`
fields.
- Apply a `safeFetch`-style wrapper modeled on `IcsCalendarProvider`: rethrow
`CancellationException`, catch and log all other exceptions, and never let
`update`, `clear`, or `close` throw.
- If Discord is not installed or not running, keep `DiscordPresenceService`
inert and retry the connection lazily on the next `update` call. The app must
stay stable in this state.
- Provide `actual fun createPresenceService(): PresenceService =
DiscordPresenceService(...)` in `jvmMain` to complete the expect/actual factory
started in Phase 1.
- In `App.kt` (commonMain), obtain a `PresenceService` via `remember {
createPresenceService() }`. Dispose it using a `DisposableEffect` with
`onDispose { presenceService.close() }`, following the existing
`DisposableEffect` idiom in the codebase.
- Add a `LaunchedEffect` keyed on `isDiscordRichPresenceEnabled`,
`currentScreen`, `currentMode`, and `activeSession`. When the flag is enabled,
compute `PresenceState` using the Phase 1 mapper and call
`presenceService.update(state)`. When the flag is disabled, call
`presenceService.clear()`.
- Keep updates coarse. React only to screen, mode, and session-start changes.
Debounce rapid changes, for example with `distinctUntilChanged` plus a short
`delay`, following the existing `LaunchedEffect(windowState)` debounce pattern
in `jvmMain/main.kt`.
- Note that on non-desktop targets, `createPresenceService()` returns
`NoOpPresenceService`, so this observer is inert there and introduces no new
platform assumptions.
- Confirm the `DisposableEffect` in `App.kt` runs on desktop exit. If the
composition does not tear down before `exitApplication()`, also call
`presenceService.close()` in the `Window(onCloseRequest = ...)` block in
`composeApp/src/jvmMain/kotlin/com/tajemniktv/tajsos/main.kt`, before
`exitApplication()` executes.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!