5.7 KiB
Roadmap: AI Backend Studio
Overview
This milestone hardens the existing Tauri runtime workspace so operators can trust what they are editing, understand what is live versus draft, and control the runtime from one coherent surface. The roadmap follows the natural dependency chain in the requirements: protect draft ownership first, then make runtime commands safe and explicit, then consolidate the workspace around that stable state model, and finally harden model-source validation and diagnostics.
Phases
Phase Numbering:
-
Integer phases (1, 2, 3): Planned milestone work
-
Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)
-
Phase 1: Draft State Ownership - Separate live runtime state from editable draft state so polling cannot clobber user input.
-
Phase 2: Lifecycle Command Safety - Make save/start/stop semantics explicit, non-conflicting, and easy to trust.
-
Phase 3: Unified Runtime Workspace - Consolidate status, actions, settings, and health guidance into one authoritative workspace. (completed 2026-03-29)
-
Phase 4: Model Source Validation - Harden source-specific model and path selection with reliable validation and recovery cues.
Phase Details
Phase 1: Draft State Ownership
Goal: Users can safely edit runtime settings as a draft that remains separate from live runtime state until they intentionally save or discard changes. Depends on: Nothing (first phase) Requirements: WORK-02, CONF-01, CONF-02, CONF-03, CONF-04 Success Criteria (what must be TRUE):
- User can edit runtime settings while polling or background refresh continues without dirty fields being overwritten.
- User can tell which values are unsaved draft settings versus the currently effective runtime state while editing.
- User can explicitly save, cancel, or revert runtime settings changes and see the workspace reflect that choice.
- User's folder-path and provider or source selections remain stable until they choose to save or discard them.
- User can recover from save or validation failures without losing the current draft. Plans: 3 plans Plans:
01-01-PLAN.md- Separate live snapshot polling from saved baseline and draft ownership in the runtime manager.01-02-PLAN.md- Refactor the runtime settings drawer around explicit draft/live presentation and discard semantics.01-03-PLAN.md- Harden field-scoped async updates, invalid draft preservation, and save failure recovery. UI hint: yes
Phase 2: Lifecycle Command Safety
Goal: Users can run runtime lifecycle actions with clear apply semantics, reliable busy-state rules, and predictable completion behavior. Depends on: Phase 1 Requirements: CTRL-01, CTRL-02, CTRL-03 Success Criteria (what must be TRUE):
- User can start, stop, or retry runtime lifecycle actions from the runtime workspace and see in-progress and completion feedback.
- User can tell whether a configuration change applies immediately or requires restart or restart-and-apply semantics.
- User cannot trigger conflicting runtime lifecycle actions while another lifecycle operation is still in progress. Plans: 3 plans
02-01-PLAN.md- Add backend lifecycle command metadata, conflict guards, and restart-required contract alignment.02-02-PLAN.md- Add frontend lifecycle/apply state orchestration and manager-level regression coverage.02-03-PLAN.md- Update runtime status/drawer lifecycle UX with explicit apply and completion feedback. UI hint: yes
Phase 3: Unified Runtime Workspace
Goal: Users can operate the runtime from one authoritative workspace that combines status, controls, settings, and actionable health context. Depends on: Phase 2 Requirements: WORK-01, DIAG-01 Success Criteria (what must be TRUE):
- User can access one authoritative runtime workspace for runtime status, lifecycle actions, and runtime settings.
- User can see actionable runtime health details, including readiness, endpoint or mode context, active model context, and relevant failure guidance, from that same workspace.
- User can understand and act on runtime issues without bouncing between duplicated status and settings surfaces. Plans: 3 plans
03-01-PLAN.md- Define manager-owned runtime workspace summary and health diagnostics contracts.03-02-PLAN.md- Build a unified runtime workspace component that combines actions, health context, and draft editing.03-03-PLAN.md- Integrate the unified workspace into the shell and remove split runtime surfaces. UI hint: yes
Phase 4: Model Source Validation
Goal: Users can choose valid runtime sources, models, and storage paths without destabilizing draft safety or applying invalid combinations. Depends on: Phase 3 Requirements: MODL-01, MODL-02 Success Criteria (what must be TRUE):
- User can choose a runtime or model source and only see model options valid for the current source and mode.
- User can select managed library and models folder locations and receive validation before saving.
- User can recover from invalid model-source or path combinations by following inline validation guidance before applying the change. Plans: 3 plans
04-01-PLAN.md- Add source-mode validation contract.04-02-PLAN.md- Add path and model file validation.04-03-PLAN.md- Add validation UI and recovery experience. UI hint: yes
Progress
| Phase | Plans Complete | Status | Completed |
|---|---|---|---|
| 1. Draft State Ownership | 3/3 | Complete | 2026-03-29 |
| 2. Lifecycle Command Safety | 3/3 | Complete | 2026-03-29 |
| 3. Unified Runtime Workspace | 3/3 | Complete | 2026-03-29 |
| 4. Model Source Validation | 3/3 | Planned | - |