74 lines
4.5 KiB
Markdown
74 lines
4.5 KiB
Markdown
# 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.md` and `.planning/codebase/STACK.md`
|
|
- Runtime management currently spans `RuntimeStatusCard` and `RuntimeSettingsDrawer`, 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`):
|
|
1. Requirements invalidated? -> Move to Out of Scope with reason
|
|
2. Requirements validated? -> Move to Validated with phase reference
|
|
3. New requirements emerged? -> Add to Active
|
|
4. Decisions to log? -> Add to Key Decisions
|
|
5. "What This Is" still accurate? -> Update if drifted
|
|
|
|
**After each milestone** (via `/gsd-complete-milestone`):
|
|
1. Full review of all sections
|
|
2. Core Value check - still the right priority?
|
|
3. Audit Out of Scope - reasons still valid?
|
|
4. Update Context with current state
|
|
|
|
---
|
|
*Last updated: 2026-03-28 after initialization*
|