ForgeLM/.planning/research/FEATURES.md

Feature Landscape

Domain: Runtime workspace UX for local-first AI desktop tools Researched: 2026-03-28 Scope: Runtime management, settings editing, model source selection, and lifecycle/status reliability in a local desktop app

Table Stakes

Features users expect. Missing = product feels unsafe or annoying to operate.

Feature	Why Expected	Complexity	Notes
Draft-safe settings editing	Desktop operators expect form edits to remain stable until they explicitly save, cancel, or reset. If polling overwrites a path field or provider choice, trust collapses immediately.	Med	Treat live runtime snapshot and editable draft as separate state models. Background refresh should update live status, not clobber draft inputs. Confidence: HIGH
Explicit save/cancel/revert flow	Adjacent desktop tools expose clear commit points for configuration changes, especially when edits affect runtime behavior, security, paths, or restart requirements.	Med	Show dirty state, changed fields, and per-field or whole-form reset. Keep save semantics deterministic. Confidence: HIGH
Unified runtime control center	Users expect one place to see current runtime, active model/provider, health, and lifecycle actions instead of split status and settings surfaces.	Med	Status summary, runtime actions, and current effective config should live together even if advanced settings remain collapsible. Confidence: HIGH
Clear lifecycle controls with feedback	Start, stop, restart, retry, and health check are baseline for local runtime tools and adjacent desktop dev tools. Users need to know whether an action is pending, succeeded, failed, or requires attention.	Med	Include transitional states, disable conflicting actions in flight, and preserve action history or last result. Confidence: HIGH
Effective vs draft configuration visibility	Users need to understand what the runtime is currently using versus what is only edited locally and not yet applied.	Med	Use labels such as Live, Draft, Unsaved, Restart required. This directly reduces confusion in brownfield apps with background polling. Confidence: HIGH
Model source and model selection with validation	Local AI tools commonly let users pick a provider/runtime source and then choose from valid models. Users expect incompatible or missing options to be explained before save.	Med	Cascade validation: source -> runtime availability -> model list -> compatibility warnings. Confidence: MEDIUM
Health/status surface with actionable diagnostics	Operators expect more than a green/red badge. They need endpoint, process state, selected model, last health check, and error guidance when unhealthy.	Med	Troubleshooting entry points matter because local runtimes fail for common machine-specific reasons. Confidence: HIGH
Safe path/directory editing for model storage or managed libraries	Desktop tools that manage runtime assets usually expose path selection, current location, and validation because storage layout is a core operator concern.	Med	Folder picker plus existence/permission checks before commit. Never silently revert user-entered paths. Confidence: HIGH
Restart-required and apply-now signaling	When settings affect runtime startup, networking, auth, or model loading behavior, users expect the UI to say whether a save applies immediately or on next restart.	Low	Show this per setting group, not as hidden tribal knowledge. Confidence: HIGH
Error recovery without losing work	Failed saves, failed starts, or failed health checks must not erase the user draft. Users expect to fix the problem and retry from the same screen.	Med	Preserve draft across failures and optionally across app refresh/reopen for the current session. Confidence: HIGH

Differentiators

Features that create competitive advantage for this scope.

Feature	Value Proposition	Complexity	Notes
Side-by-side live snapshot and editable draft	Turns a common failure mode into a trust signal: users can compare what is running with what they are preparing to apply.	Med	Best fit for this project because the current pain is polling overwriting edits. Confidence: HIGH
Per-setting change impact preview	Before save, explain consequences such as restart needed, model reload required, auth exposure risk, or path rescan.	Med	Makes advanced runtime settings feel safe without adding wizard friction. Confidence: MEDIUM
Runtime/source switching with preserved drafts per source	Users exploring local vs remote runtimes often lose partial config when switching providers. Preserving draft state per source reduces setup frustration.	High	Useful when multiple runtime backends or model sources are supported. Confidence: MEDIUM
Inline diagnostics and guided repair actions	Instead of just reporting Unhealthy, offer actions like open logs, retry probe, reveal models folder, reset to last saved, or test connection.	Med	Adjacent tools win on time-to-recovery, not just status visibility. Confidence: HIGH
Optimistic model browser with compatibility hints	Show available models, installed/downloaded state, source provenance, and whether the current runtime can serve them before commit.	High	Especially valuable if local and remote sources coexist. Confidence: MEDIUM
Session-safe draft persistence and recovery	If the app reloads or the runtime poll stream reconnects, the user can restore unsaved edits intentionally rather than losing them.	High	Strong differentiator because settings trust is the product constraint called out in PROJECT.md. Confidence: MEDIUM
Explainable automation for model loading/runtime lifecycle	Features like auto-start, JIT loading, auto-unload, or health polling become safer when users can see why the app took an action and how to override it.	Med	Borrow the best part of LM Studio and Docker Desktop: power features with visible state and controls. Confidence: MEDIUM

Anti-Features

Features to explicitly NOT build.

Anti-Feature	Why Avoid	What to Do Instead
Silent form rehydration from background polling	This is the core trust-destroying behavior in the current product. Users read it as data loss.	Keep live runtime snapshot separate from draft state and ask before replacing a dirty draft.
Implicit auto-save for high-impact runtime settings	Auto-saving ports, auth, paths, or provider changes creates surprise restarts and hard-to-debug state.	Use explicit save/cancel, with optional narrow autosave only for low-risk preferences later if ever needed.
Split-brain control surfaces	Duplicated controls across status card and settings drawer create uncertainty about which surface is authoritative.	Make one workspace the source of truth and let secondary surfaces deep-link into it.
Overloading the workspace with chat redesign work	Chat is validated and out of scope; broadening here dilutes the runtime reliability goal.	Touch chat only where active runtime/model context must be surfaced.
Hidden config mutations on source switch	Auto-clearing fields or swapping model selections without explanation feels like a bug.	Preserve drafts per source or require explicit confirmation before destructive changes.
Advanced settings without safety copy	Security, network, and path settings are easy to misuse when labels are terse.	Add impact text, validation, and restart/apply semantics directly in the UI.

Feature Dependencies

Unified runtime control center -> Clear lifecycle controls with feedback
Unified runtime control center -> Effective vs draft configuration visibility
Effective vs draft configuration visibility -> Draft-safe settings editing
Draft-safe settings editing -> Explicit save/cancel/revert flow
Draft-safe settings editing -> Error recovery without losing work
Model source and model selection with validation -> Optimistic model browser with compatibility hints
Clear lifecycle controls with feedback -> Health/status surface with actionable diagnostics
Safe path/directory editing -> Restart-required and apply-now signaling
Explicit save/cancel/revert flow -> Per-setting change impact preview
Draft-safe settings editing -> Session-safe draft persistence and recovery
Health/status surface with actionable diagnostics -> Inline diagnostics and guided repair actions

MVP Recommendation

Prioritize:

1. Draft-safe settings editing
2. Explicit save/cancel/revert flow
3. Unified runtime control center
4. Clear lifecycle controls with feedback
5. Effective vs draft configuration visibility
6. Model source and model selection with validation

One early differentiator worth pulling into MVP if capacity allows: 7. Side-by-side live snapshot and editable draft

Defer:

• Runtime/source switching with preserved drafts per source: valuable, but only after one-runtime draft safety is solid
• Session-safe draft persistence and recovery: strong trust feature, but second-order after fixing in-session overwrite behavior
• Optimistic model browser with compatibility hints: defer until core save/apply semantics are reliable

Sources

Authoritative / official docs

• Docker Desktop settings and maintenance docs: https://docs.docker.com/desktop/settings-and-maintenance/settings (used for expectations around desktop settings, lifecycle, restart/apply semantics, notifications)
• LM Studio server settings docs: https://lmstudio.ai/docs/developer/core/server/settings (used for expectations around runtime/network/auth/model-loading controls)
• LM Studio headless/runtime service docs: https://lmstudio.ai/docs/developer/core/headless (used for expectations around start-on-login, auto server restore, JIT model loading)
• VS Code settings docs: https://code.visualstudio.com/docs/configure/settings (used for expectations around settings scopes, direct editing, modified state, and user/workspace separation)
• VS Code default settings reference: https://code.visualstudio.com/docs/reference/default-settings (used to confirm settings editor + JSON are both first-class)
• Ollama troubleshooting docs: https://docs.ollama.com/troubleshooting (used for expectations around logs, diagnostics, runtime failure recovery, and model/config locations)

Ecosystem / discovery sources

• Exa ecosystem search on local AI desktop tools and adjacent desktop developer tools, 2026 queries covering LM Studio, Ollama clients, AnythingLLM, Open WebUI, Docker Desktop, and unsaved-settings reliability patterns

Confidence Notes

• HIGH confidence: explicit save/cancel, separate live vs draft state, unified control center, lifecycle feedback, diagnostics, and non-destructive failure handling are strongly supported by official desktop-tool patterns and the project's stated constraints.
• MEDIUM confidence: preserved drafts per source, compatibility-hint browsers, and session draft recovery are opinionated differentiators derived from ecosystem patterns and UX pain points rather than a single canonical doc.
• LOW confidence: none of the core recommendations rely only on unverified single-source claims.