Warm Reusable Truth, Not Screens
Warm reusable truth, not screens
In a daemon-backed app, warm the state and artifacts every client can use. Do not warm one client's screen payload and mistake it for application state.
The daemon should know about tracks, queues, lyrics, search records, cover art, sync cursors, devices, and playback snapshots. The TUI should know how to render them. When the TUI closes, the daemon should keep warming the reusable layer.
The rule
Warm domain truth, not view shape.
If a warmed result is only meaningful to one screen, it probably belongs near that screen. If the CLI, TUI, scripts, and agents can all benefit, it belongs below the client boundary.
Why this matters
Screen caches feel fast at first, but they make the foreground client the system. Close the UI and the work stops. Open a different client and the cache is useless.
Daemon-owned warm state has better economics. One background fetch can serve the TUI, a CLI command, an MCP client, and an agent workflow. It also keeps the system honest: clients are views, not the source of truth.
Spotuify example
For Spotuify, the daemon should warm queue-adjacent facts: track metadata, album art, lyrics cache entries, search/index records, and embedded-player preload state where the player supports it.
It should not warm "the queue rail view" as a daemon concept. The rail is a TUI rendering decision. The underlying queue snapshot and cached track artifacts are reusable truth.
As of the 2026-06-02 queue-warming pass, adding tracks to the queue starts that
daemon-owned warm path: metadata, cover art, lyrics, index rows, and the next
embedded-player preload. A CLI queue add, the TUI queue action, and an agent
workflow all benefit from the same warmed artifacts.
Device state follows the same rule. The daemon's embedded librespot device is not a TUI detail; it is reusable runtime truth. If Spotify's device registry lags, the daemon should still expose its own connected device to CLI, TUI, MCP, and agents while reconciliation catches up. See Stale Registries Need Local Authority.
ClientSeed is the startup version of this boundary. The daemon returns cached
playback, queue, devices, recent items, and visualizer state. It does not return
a pre-rendered Home screen, and it does not call Spotify just because a TUI
opened. The warmed thing is reusable truth; the screen is still the client's
job.
Playlist and album context playback is the same boundary from the other
direction. Starting the context should publish the queue snapshot as daemon
truth: first playable item as current, the rest as upcoming. Otherwise one
screen can hear music while another client sees an empty queue. That is why the
2026-06-03 Spotuify fix belongs in Context Playback Must Publish Queue Truth,
not only in a TUI keybinding note.
Mxr demo example
For Mxr, the curated demo seed is only half the story. After the fake provider syncs the two-account, 50k-message inbox, mxr demo prewarms reusable daemon-owned artifacts: analytics, Wrapped, LLM-backed demo caches, and active-profile semantic vectors.
That is the right layer. The warmed artifacts can serve CLI commands, the TUI, the web app, and agents. A prebuilt "inbox screen" would only serve one client and would drift from the real mailbox model.
The useful boundary is: precompute artifacts owned by the daemon and keyed by durable inputs such as account, time range, thread content, semantic profile, and model. Do not precompute a component tree, a selected row, or a sidebar payload.