Documentation Index
Fetch the complete documentation index at: https://docs.qredence.ai/llms.txt
Use this file to discover all available pages before exploring further.
fleet-rlm is a Daytona-backed recursive runtime wrapped by a thin transport shell and a narrow hosted-policy layer.
Design principles
Three intentional choices drive the shape of the codebase:-
The backend is intentionally thin. The Python layer is a transport + orchestration shell over
dspy.ReAct,dspy.RLM, and Daytona sandboxes. “Intelligence” lives in DSPy (upstream) and in how recursive child sandboxes are scheduled (this repo). Plumbing belongs insrc/fleet_rlm/api/; policy belongs insrc/fleet_rlm/runtime/. -
The UI is treated as core, not peripheral. The runtime emits streaming events, code-execution results, and artifacts that only make sense in an interactive surface. That is why
src/frontend/is comparable in line count tosrc/fleet_rlm/. -
Two agent layers, both
dspy.*, both real.- Chat surface:
dspy.ReActatsrc/fleet_rlm/runtime/agent/agent.py. - Recursive engine:
dspy.RLMatsrc/fleet_rlm/runtime/models/builders.pywith delegation atsrc/fleet_rlm/runtime/tools/rlm_delegate.py.
- Chat surface:
Layering
Layer 1 — Transport
Thin FastAPI/WebSocket shell. Primary files:src/fleet_rlm/api/main.pysrc/fleet_rlm/api/routers/ws/endpoint.pysrc/fleet_rlm/api/runtime_services/chat_runtime.pysrc/fleet_rlm/api/runtime_services/chat_persistence.pysrc/fleet_rlm/api/runtime_services/diagnostics.pysrc/fleet_rlm/api/runtime_services/settings.pysrc/fleet_rlm/api/runtime_services/volumes.py
- App factory, lifespan, route mounting, SPA asset serving.
- Auth-derived HTTP and WebSocket identity.
- Session lookup, runtime preparation, service orchestration.
- WebSocket lifecycle and execution-event envelope delivery.
- Runtime settings, diagnostics, and Daytona volume browsing.
Layer 2 — Runtime core
Primary files:src/fleet_rlm/api/routers/ws/stream.pysrc/fleet_rlm/runtime/factory.pysrc/fleet_rlm/runtime/agent/agent.pysrc/fleet_rlm/runtime/agent/runtime.pysrc/fleet_rlm/runtime/execution/*src/fleet_rlm/runtime/models/*
- Shared chat/runtime execution.
- Recursive delegation and tool execution.
- Execution-event assembly and workbench hydration.
- Runtime model assembly and registry management.
Layer 3 — Daytona substrate
Primary files:src/fleet_rlm/integrations/daytona/interpreter.pysrc/fleet_rlm/integrations/daytona/runtime.pysrc/fleet_rlm/integrations/daytona/filesystem.pysrc/fleet_rlm/integrations/daytona/diagnostics.py
- Sandbox and interpreter lifecycle.
- Repo checkout, workspace path staging, durable mounted volumes.
- Provider-specific diagnostics and volume normalization.
Layer 4 — Offline quality
Primary files:src/fleet_rlm/runtime/quality/*
Responsibilities:
- DSPy evaluation.
- GEPA optimization.
- Offline scoring, datasets, and module registry management.
Stateful restore
Session manifests on durable storage are the authoritative local restart-restore source. The manifeststate payload restores:
dspy.Historyconversation turns.AgentRuntimecore memory (default core memory plus persisted keys).- Session-local loaded document paths.
- Daytona interpreter state — sandbox ID, workspace path, repo/ref/context paths, volume name, volume subpath.
Reading order
When you need the current backend story, read in this order:src/fleet_rlm/api/main.pysrc/fleet_rlm/api/routers/ws/endpoint.pysrc/fleet_rlm/api/routers/ws/stream.pysrc/fleet_rlm/runtime/factory.pysrc/fleet_rlm/runtime/agent/agent.pysrc/fleet_rlm/integrations/daytona/interpreter.pysrc/fleet_rlm/integrations/daytona/runtime.py
Older transition notes may still mention
orchestration_app/ or api/orchestration/. Those labels are historical only and are intentionally absent from the current tree.