# 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

```text
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.