evandro/ForgeLM
1
0 Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
ForgeLM/.planning/ROADMAP.md
T

8.1 KiB
Raw Permalink Blame History

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: Hugging Face Download Engine - Streaming download of GGUF models from Hugging Face with real-time progress, cancellation, and managed-model storage. (completed 2026-03-31)

  • Phase 5: 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: Hugging Face Download Engine

Goal: Users can download GGUF models directly from Hugging Face with real-time progress, cancellation, and automatic storage in the managed-models directory. Depends on: Phase 3 (Unified Runtime Workspace) Requirements: HF-DL-01, HF-DL-02, HF-DL-03 Success Criteria (what must be TRUE):

  1. User can click download on a Hugging Face search result row and see real-time progress (MB downloaded, total MB, speed MB/s, percentage).
  2. User can cancel an in-progress download and have the partial file cleaned up.
  3. Downloaded files are saved to the managed-models directory with proper path structure.
  4. Downloads use the HF bearer token when available for authenticated access.
  5. The download runs in Rust to avoid IPC bottlenecks, with progress emitted via Tauri events. Plans: 3 plans
  • 04-01-PLAN.md - Rust streaming download engine with progress events.
  • 04-02-PLAN.md - React hook useModelDownload with Tauri event bridge.
  • 04-03-PLAN.md - SettingsPage integration with .sp-hf-file row progress state. UI hint: yes

Phase 5: 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 4 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
  • 05-01-PLAN.md - Add source-mode validation contract.
  • 05-02-PLAN.md - Add path and model file validation.
  • 05-03-PLAN.md - Add validation UI and recovery experience. UI hint: yes

Phase 6: Chat UI Redesign (Manus AI System Design)

Goal: Redesign the chat UI to follow Manus AI system design with correct color tokens, component decomposition, and UX patterns. Depends on: Phase 5 Requirements: UI-01, UI-02, UI-03 Success Criteria (what must be TRUE):

  1. Model selector lives inside the chat input pill (hero and regular), not the sidebar.
  2. scan_models returns only top-level GGUF files (no subdirectory traversal).
  3. Thinking indicator is a single pulsing blue dot + "Thinking" text.
  4. Send button uses PaperPlaneRight icon only.
  5. App uses Manus color tokens (#171717 base, #1E1E1E surface, #262626 elevated).
  6. Settings page aligns to Manus design tokens. Plans: 3 plans Plans:
  • 06-01-PLAN.md — Backend scan fix + ModelSelectorPill + Sidebar cleanup + ChatView wiring
  • 06-02-PLAN.md — Global Manus tokens + thinking indicator + send button + message widths
  • 06-03-PLAN.md — Settings page Manus token alignment 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. Hugging Face Download Engine 3/3 Complete 2026-03-31
5. Model Source Validation 3/3 Planned -
6. Chat UI Redesign 0/3 Planned -
Reference in new issue View Git Blame Copy Permalink