4.5 KiB
4.5 KiB
AI Backend Studio
What This Is
AI Backend Studio is a local-first desktop workspace for running and managing local LLM runtimes, selecting models, and chatting against the active runtime from a Tauri app. This roadmap focuses on the existing runtime workspace experience: making runtime control and configuration easier to understand, safer to edit, and more reliable for operators using the desktop app.
Core Value
A user can configure and operate the runtime from one trustworthy workspace without the UI fighting their in-progress edits.
Requirements
Validated
- ✓ Local runtime can be started, stopped, and health-checked from the desktop app - existing
- ✓ Runtime configuration can be edited from the desktop app and persisted through the Tauri backend - existing
- ✓ Users can browse model sources and select models for the runtime - existing
- ✓ Users can chat against the active runtime with locally persisted chat history - existing
Active
- Runtime Workspace presents one clear control center for runtime status, actions, and settings
- Runtime status summary and Runtime Settings are reorganized to reduce duplication and operator confusion
- Runtime settings fields such as Managed library and Models folder do not get overwritten by polling or background refresh while the user is editing
- Runtime settings preserve explicit user choices until save/cancel and separate live snapshot state from draft form state
Out of Scope
- Backend inference engine changes - this initiative targets runtime workspace UX and frontend state flow, not model execution internals
- Chat feature redesign outside runtime-related touchpoints - chat already works and is not the primary problem being scoped here
- New cloud orchestration or multi-user control plane - current focus is the existing local-first desktop surface
Context
- Existing codebase is brownfield with a Rust workspace, Tauri desktop backend, and React/TypeScript frontend already mapped in
.planning/codebase/ARCHITECTURE.mdand.planning/codebase/STACK.md - Runtime management currently spans
RuntimeStatusCardandRuntimeSettingsDrawer, creating a split-brain control experience - The current frontend runtime flow polls live runtime state and rehydrates the settings form, which can overwrite in-progress edits or folder selections before save
- The existing architecture already supports runtime lifecycle operations, model discovery, persisted runtime config, and local chat history, so this roadmap should build on those capabilities rather than replace them
Constraints
- Tech stack: Keep the existing Rust + Tauri + React/TypeScript architecture - the project is improving the current app, not rewriting it
- Brownfield compatibility: Preserve working runtime lifecycle, model selection, and chat flows while reorganizing the UI - regressions in validated capabilities are not acceptable
- UX reliability: Unsaved user edits must not be overwritten by polling or snapshot refresh - trust in the settings surface is the main product constraint
- Local-first: Continue supporting local desktop runtime management patterns already established in the app - scope should not depend on external hosted infrastructure
Key Decisions
| Decision | Rationale | Outcome |
|---|---|---|
| Treat this as a brownfield runtime workspace improvement project | The repo already contains a working desktop runtime manager, model configuration flow, and chat surface | - Pending |
| Center the roadmap on runtime workspace clarity and edit safety | The primary user pain is split control surfaces plus auto-overwritten form state | - Pending |
| Keep runtime operations and runtime configuration in one coherent experience | Current duplication between external status card and settings drawer is a major source of confusion | - Pending |
Evolution
This document evolves at phase transitions and milestone boundaries.
After each phase transition (via /gsd-transition):
- Requirements invalidated? -> Move to Out of Scope with reason
- Requirements validated? -> Move to Validated with phase reference
- New requirements emerged? -> Add to Active
- Decisions to log? -> Add to Key Decisions
- "What This Is" still accurate? -> Update if drifted
After each milestone (via /gsd-complete-milestone):
- Full review of all sections
- Core Value check - still the right priority?
- Audit Out of Scope - reasons still valid?
- Update Context with current state
Last updated: 2026-03-28 after initialization