flow-application

flow_application::FlowApp is the single integration point. A host constructs one instance and calls methods on it. There is no other wiring. The Tauri shell, the HTTP server, and the CLI all hold the same struct.

use flow_application::{FlowApp, WorkspaceBase};

let app = FlowApp::new().with_workspace_base(WorkspaceBase::Fixed(cwd));

Data lives under ~/.flow-studio/ (override with the FLOW_STUDIO_DIR env var). Secrets stay in the OS keyring.

Running flows

pub async fn execute_graph(&self, graph: FlowGraph, events: Arc<dyn EventSink>)
    -> Result<ExecutionSummary, AppError>;
pub async fn execute_graph_with_id(&self, execution_id: String, graph: FlowGraph,
    events: Arc<dyn EventSink>) -> Result<ExecutionSummary, AppError>;

pub fn pause_run(&self, execution_id: &str);
pub fn resume_run(&self, execution_id: &str);
pub fn cancel_run(&self, execution_id: &str);
pub fn resolve_ai_review(&self, execution_id: &str, approved: bool);
// *_all_runs variants exist for single-run hosts.

Every run streams ExecutionEvents into the sink you pass. Persistence is a sink too (StorageSink), so a host opts runs into history by composing sinks.

Coding-agent turns

pub async fn run_agent_turn(&self, req: AgentTurnRequest, events: Arc<dyn EventSink>)
    -> Result<AgentTurn, AppError>;
pub async fn apply_agent_edits(&self, execution_id: &str, verdicts: &[AgentEditVerdict])
    -> Result<Vec<AgentEditOutcome>, AppError>;

AgentTurnRequest carries the user message, a compact transcript, the workspace root, provider and model, and an optional thinking toggle. The engine composes the prompt and the one-node graph itself. Filesystem mutations are staged as ProposedEdits and only land when apply_agent_edits resolves human verdicts. Each verdict produces one audit record.

Generation

pub async fn agentic_generate(&self, local_model_id: Option<&str>,
    cloud: Option<(&str, &str)>, prompt: &str) -> Result<DslGenerationOutcome, AppError>;
pub async fn agentic_run_loop(/* generate -> run -> observe -> re-plan */);

Generation is prompt-only, so it never reads the workspace. The system prompt is the compiled DSL spec embedded at build time.

Models

pub fn list_local_llms(&self) -> Vec<LocalLlm>;          // installed .gguf files + catalog names
pub async fn hub_installed(&self) -> Vec<InstalledModel>; // catalog-joined install records
pub async fn start_local_llm(&self, binary: Option<String>, model: Option<String>,
    params: LlamaParams) -> Result<LlmServerStatus, AppError>;
pub async fn stop_local_llm(&self) -> LlmServerStatus;
pub fn local_llm_status(&self) -> LlmServerStatus;

start_local_llm resolves the engine binary (managed dir, setting, $PATH), boots the managed llama-server, and points local_ai_base_url at it.

Templates, history, schedules, settings

pub fn list_templates(&self) -> Result<Vec<TemplateRecord>, AppError>;
pub fn save_template(&self, name: &str, graph: FlowGraph) -> Result<TemplateRecord, AppError>;
pub fn load_template(&self, slug: &str) -> Result<FlowGraph, AppError>;

pub fn store(&self) -> &Store;                 // runs, steps, AI audit (flow-storage)
pub fn list_schedules(&self) -> Result<Vec<ScheduleRecord>, AppError>;
pub fn settings(&self) -> Settings;            // allow_local_ai, allow_cloud_ai, ...

Working memory

{{memory.<key>}} interpolation is backed by app-owned working memory that survives across runs in a session. clear_working_memory() resets it and the persisted copy.