The path to a
complete machine.

Establish a real desktop application with a trustworthy shell, local configuration, and a clear frontend boundary.

The foundation milestone provides a Tauri 2 window, a persistent vanilla frontend, versioned local configuration, atomic writes, and restrictive Unix permissions. The configuration schema is now version 2.

• Tauri 2 application shell and Rust command boundary.
• Vanilla HTML, CSS, and JavaScript frontend served by Tauri.
• Persistent multi-page workspace with hash-based navigation.
• Versioned config.json in the platform application data directory.
• Atomic configuration writes with 0700 directories and 0600 files on Unix.

Detect what the host can actually do before attempting any virtual machine operation.

Host diagnostics, QEMU and qemu-img discovery, version probing, and Linux KVM verification are implemented. Windows and macOS host behavior has not been verified.

• Operating system, architecture, logical CPU count, memory, and application-data free space.
• QEMU and qemu-img discovery through bundled resources, PATH, and standard platform locations.
• Version probing with a five-second timeout and explicit failure reporting.
• Linux KVM verification by opening /dev/kvm and issuing KVM_GET_API_VERSION.
• Readiness warnings when QEMU, qemu-img, or KVM is unavailable.

Turn a virtual machine into a validated local definition with explicit, protected storage.

Machine definitions are created with validated names, resources, and an x86_64 guest architecture. Each machine receives a thin-provisioned QCOW2 disk that is never overwritten.

• Schema-v2 configuration stores VM definitions with lifecycle state.
• Validation covers name, guest architecture, memory, virtual CPUs, disk size, host memory, host CPUs, and free space.
• The lifecycle currently requires a Linux x86_64 host and supports x86_64 guests only.
• qemu-img creates a QCOW2 disk in vms/<machine-id>/disk.qcow2.
• Existing disk files are never overwritten; Unix disks are restricted to 0600.

Start and supervise QEMU safely, then control supported lifecycle operations through QMP.

QEMU is launched with the configured resources. KVM is used when verified usable, with a TCG fallback. Start and stop use a private QMP Unix socket and bounded process-termination fallbacks.

• QEMU arguments are constructed through typed vectors, never shell command strings.
• The QEMU process is tracked, duplicate launches are blocked, and unexpected exits are detected through polling.
• QMP performs the handshake, queries runtime status, requests system_powerdown, and falls back to quit.
• Stop falls back to SIGTERM and then a forced kill if QEMU does not exit within bounded timeouts.
• Persisted states left in starting, running, or stopping are reconciled when the application starts.

Provide a genuine interactive graphical console for the running guest.

A running machine can be opened in an interactive console backed by QEMU WebSocket VNC and bundled noVNC 1.7.0. The listener is loopback-only and protected by a per-run password.

• QEMU VNC is bound to 127.0.0.1 and the WebSocket port is discovered through QMP.
• The console password is generated for each run and kept in memory only.
• Keyboard and mouse input are sent to the guest; the viewport scales to the console surface.
• The console is available only while the machine is running and requires QEMU WebSocket VNC support.
• The current build cannot install a guest operating system, so the display may show only firmware or a no-bootable-device message.

Make operating system installation and guest connectivity practical without weakening local control.

This is the next planned milestone. No ISO selection, media attachment, guest OS installation, image download, or network configuration exists. QEMU currently starts with no guest network device.

• Select local ISO images and validate paths.
• Verify selected images when reliable checksum or signature data is available.
• Attach installation media to a machine and support a guest OS installation workflow.
• Detect networking capabilities and configure local VM networking.
• Avoid arbitrary QEMU arguments and unauthenticated network control interfaces.

Verify supported host platforms and produce installable builds without overstating support.

Linux x86_64 is the only environment exercised here. macOS and Windows behavior is unverified, and no installer or packaged release exists.

• Compile and verify host behavior on macOS and Windows.
• Verify acceleration detection separately from device presence.
• Produce platform-appropriate packages and application icons.
• Document supported and unsupported environments explicitly.
• Keep platform-specific implementations behind clear interfaces.

Make a release trustworthy, understandable, and maintainable for users and contributors.

No release artifacts or checksums exist. The project must not be described as production-ready.

• Keep the MIT License and third-party notices accurate as dependencies and assets change.
• Complete user and contributor documentation for implemented workflows.
• Review accessibility, security, and failure handling.
• Prepare release notes, checksums, and support boundaries.
• Publish only artifacts that have actually been built and verified.