Inspectable
Operators should be able to read paths, inspect state, and understand where generated data comes from.
virtual filesystem · storage roadmap · guarded workspace
Storage + VFS
Phase1 uses the virtual filesystem as the operator workspace: a place to inspect files, generated system views, logs, process data, docs, and future guarded storage/Git workflows.
vfs model
The VFS is the Phase1 workspace.
The virtual filesystem gives Phase1 a terminal-native place to organize files, generated system views, docs, logs, and learning workflows. It should feel like an OS workspace without pretending to be a production filesystem.
Contained
Normal workflows should stay inside the virtual environment unless host trust is explicitly involved.
Teachable
The VFS should help users learn OS-style concepts without risking their actual host files.
important paths
Common virtual paths.
Exact paths can vary by build, but the public docs should keep the mental model consistent.
User-facing workspace files and learning artifacts.
Generated process and system views for inspection.
Device-like concepts and virtual system surfaces.
Audit and runtime logs when exposed by the current build.
Local reference material and in-system wiki content.
Short-lived scratch space when supported.
file commands
File operations should stay simple and visible.
Use basic shell-style commands to move through the VFS, read files, and create simple learning workflows. The command reference keeps the broader command map.
Show the current virtual working directory.
List files and directories.
Move through virtual paths.
Read file content.
Create a directory when supported.
Copy, move, or rename virtual files where available.
persistence
Persistence should be explicit.
Some Phase1 storage may be temporary, generated, or build-local. When a feature persists data, the docs should say where it persists, what it stores, and how the operator can remove or inspect it.
- Temporary state should be labeled as temporary.
- Generated system views should not be confused with user files.
- Persistent storage should document location, deletion, and safety boundaries.
- Host-backed storage should require explicit trust and visible behavior.
host boundary
The host filesystem is a boundary.
Phase1 should not blur the line between virtual files and real host files. If a command touches host storage, the docs and UI should make that clear before the command runs.
Virtual first
Learning and demos should prefer the contained VFS.
Guarded host tools
Host access belongs behind safe-mode and trust controls.
No surprise writes
Users should know when data leaves the virtual workspace.
git + rust workspace
Git and Rust workflows are roadmap-critical.
The project direction includes guarded support for repository workflows, Rust projects, and future runtime language work. The key is to make build workflows useful without hiding host trust decisions.
Repository download workflow. Should be explicit about network and storage boundaries.
Rust execution workflow. Should be guarded when host-backed.
Inspect storage state, workspace mode, and persistence notes where supported.
Future diagnostics path for toolchain and environment readiness.
tutorial patterns
Good VFS tutorials teach by doing.
Create and inspect
Create a directory, write a file, list it, read it, then search it.
System views
Explore generated paths like process views or logs, then compare them to user-created files.
Trust boundary
Compare virtual-only workflows with guarded host-backed workflows.
non-claims
Storage docs are a roadmap and usage guide, not a production filesystem claim.
This page does not claim Phase1 is a production filesystem, data-loss-proof storage layer, installer-ready OS, hardware-validated environment, or security-hardened storage product. It documents the intended VFS model and public boundaries.