Architecture
Implemented Rust core and future system boundaries.
In development. The current runtime is deliberately small. The final developer API and GUI architecture are not decided yet.
Existing Rust workspace
| Component | Technology | Scope |
|---|---|---|
| bsis-core | Rust | Manifest validation, paths, Zstandard bundle, installation and uninstall |
| bsis | Rust / Clap | Build CLI, bundle inspection, console install/uninstall |
| bsis GUI (opt-in) | Rust / Tao / Wry / WebView2 | Fixed offline HTML/CSS wizard calling the same core install operation |
| BSIS.dev | Next.js + AriaDocs | Public guides and GitHub Pages deployment |
The prototype uses a validated, versioned internal manifest. Native file-level progress callbacks report verified file and byte counts to the opt-in WebView2 installer. Fallible callbacks enable cooperative cancellation before committing staged files; the native event loop remains responsible for routing progress and cancellation safely. Files are hashed and streamed into a compressed executable overlay. The native setup runtime extracts them into a fresh staging directory and commits a new install by renaming the directory.
Future architecture
The first WebView2 host is now prototyped behind an explicit gui CLI command. Custom developer-provided Svelte/React interfaces, TypeScript configuration, a shared installer-step protocol and a security-scoped plugin interface are still proposals.
We expect GUI, console and silent installation paths to share one validated action model. The UI should not run privileged Windows operations directly.
Known limitations
There is no existing-directory update path, Windows application registration, packaged uninstall executable, UAC, registry API, Windows services, signature verification or final archive compatibility contract yet. These require additional design and security work.
See Rust prototype and Packaging for details of what actually exists.