Files
ForgeLM/.planning/ROADMAP.md
T

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):

  1. User can edit runtime settings while polling or background refresh continues without dirty fields being overwritten.
  2. User can tell which values are unsaved draft settings versus the currently effective runtime state while editing.
  3. User can explicitly save, cancel, or revert runtime settings changes and see the workspace reflect that choice.
  4. User's folder-path and provider or source selections remain stable until they choose to save or discard them.
  5. 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):

  1. User can start, stop, or retry runtime lifecycle actions from the runtime workspace and see in-progress and completion feedback.
  2. User can tell whether a configuration change applies immediately or requires restart or restart-and-apply semantics.
  3. 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):

  1. User can access one authoritative runtime workspace for runtime status, lifecycle actions, and runtime settings.
  2. User can see actionable runtime health details, including readiness, endpoint or mode context, active model context, and relevant failure guidance, from that same workspace.
  3. 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):

  1. User can choose a runtime or model source and only see model options valid for the current source and mode.
  2. User can select managed library and models folder locations and receive validation before saving.
  3. 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 -