Visible execution
Commands should show what is being run and where output goes.
runtimes · languages · guarded execution
Phase1 Runtime Roadmap
Phase1 is Rust-first today, with a roadmap for language-aware operator workflows. Runtime support should be useful, explicit, and guarded when it crosses into host-backed execution.
runtime model
Runtimes should feel like operator tools, not hidden background engines.
The runtime roadmap is about making languages available through explicit, inspectable command workflows. Each runtime should document what it can execute, where files live, whether it touches the host, and what capabilities are required.
Capability-aware
Runtime commands should describe network, file, and host requirements.
Docs-first
Each language needs tutorials, examples, and safety boundaries before promotion.
rust first
Rust is the first-class development path.
Phase1 is built in Rust, so Rust workflows are the natural first target for build/run/test documentation. The public docs should make the Rust path easy to follow without overclaiming the state of host execution support.
Run Phase1 from the repository.
Exercise test coverage and regression checks.
Run linting for code-quality improvements.
Apply consistent Rust formatting.
language track
Major language support should be staged.
The roadmap can support multiple languages over time, but each language should have a clear maturity label: planned, prototype, guarded, documented, or stable.
RustPythonJavaScriptTypeScriptGoJavaC#SwiftWebAssembly
Planned
The runtime is on the roadmap but not ready for users.
Prototype
Early experiments exist, but behavior can change quickly.
Guarded
Host-backed execution requires explicit trust and documented limits.
webassembly
WebAssembly is a promising plugin boundary.
WASM-style plugins are useful because they can make extension behavior more inspectable and capability-oriented. The docs should describe which modules are supported, what APIs are exposed, and what a plugin cannot do.
- Keep module capabilities explicit.
- Document file and network access boundaries.
- Separate demo plugins from stable runtime APIs.
- Prefer small examples that are easy to audit.
capabilities
Every runtime needs a capability story.
A language runtime can be powerful, so it should have a clear capability model. Operators should know whether a runtime can read files, write files, access the network, spawn host tools, or run only inside the virtual environment.
Can the runtime read or write the VFS, host storage, or both?
Does the runtime need network access, and is it guarded?
Can the runtime start host processes, simulated processes, or neither?
Which runtime actions produce visible audit records?
developer workflow
Runtime docs should start with small examples.
- Hello world: show a tiny script or project example.
- Read a virtual file: demonstrate the VFS boundary.
- Write output: show where generated output lives.
- Inspect capabilities: explain what the runtime was allowed to do.
- Document cleanup: show how to remove generated files or reset state.
non-claims
Runtime docs are roadmap guidance, not a production sandbox claim.
This page does not claim that Phase1 has complete language support, production sandboxing, hardened runtime isolation, or safe execution of arbitrary untrusted code. It describes the intended staged runtime roadmap and documentation boundaries.