宽幅统计页脚 thomasvvugt/dsh-wide-stats-footer

dsh-wide-stats-footer

一个 DeepSeek Harness（DSH）Web 插件，用于解除输入框 统计页脚 的宽度限制——即输入卡片下方的那一行：

16 turns · 255 steps | LLM 44m17s · Tool call 42m32s | TTFT avg 5.3s · 87 tok/s | Cache hit 97% | Input 32.3M tok · Output 113K tok

原版 DSH 会将这一行限制在聊天内容宽度内，因此较长的统计信息会被压缩为 …：

16 turns · 255 steps | LLM 44m17s · Tool call 42m32s | TTFT avg 5.3s · 87 tok/s | Cac…

使用此插件后，页脚会横跨 整个输入框宽度 并居中——在宽屏上不再被截断。

安装

dsh plugin --profile web add github:thomasvvugt/dsh-wide-stats-footer

然后重启 dsh web。可通过 dsh --profile web --dump-config 确认（查找 dsh-wide-stats-footer 层）。如需固定某个发布版本：github:thomasvvugt/dsh-wide-stats-footer#v0.1.0。

该插件也收录在 awesome-dsh-plugin 注册表中，因此可以从应用内插件市场（dshmarket）一键安装，并可通过插件搜索找到。

卸载： dsh plugin --profile web remove dsh-wide-stats-footer，然后重启。

它改变了什么

原版页脚（@deepseek-ai/dsh-client-ui-conversation 中的 StatsLine）受其 CSS 模块根规则限制：

.{hash}_root {
text-align: center;
max-width: var(--dsh-chat-content-width); /* 748px — the clamp / padding: 4px calc(var(--dsh-composer-side-clearance) + 16px) 0; / +32px more / white-space: nowrap; overflow: hidden; text-overflow: ellipsis; margin: 0 auto; width: 100%; }

该插件仅覆盖该元素上的宽度限制和水平内边距：

.{hash}_root.{hash}_root { max-width: none; padding-left: 0; padding-right: 0; }

width: 100%、margin: 0 auto 和 text-align: center 仍沿用基础规则，因此页脚会变得与其容器（输入框列）一样宽，同时保持居中。双类名使其特异性（0,2,0）高于基础规则的（0,1,0），且不受 注入顺序影响——包括第三方主题 CSS。为增强稳健性，还会在页脚元素本身上应用内联样式作为回退。

哈希发现（无任何硬编码）

{hash} 是一个经过哈希处理的 CSS 模块前缀，每当 dsh-client-ui-conversation 重新构建时都会变化。浏览器端会在运行时发现它：

1. 扫描 document.styleSheets，查找统计行的分隔符规则
.{hash}_sep { color: var(--dsw-alias-separator-primary); margin: 0 10px }
（在应用中唯一——其他 _sep/_separator 类使用点号或不同的外边距），并且
2. 在修改之前，验证同级的 .{hash}_root 规则确实声明了 max-width: var(--dsh-chat-content-width) 这一限制。

第二条独立路径会直接在 DOM 中查找页脚。MutationObserver 监听和 会在样式标签到达时重新运行发现逻辑（延迟的 bundle 实体化、 HMR 重建、主题切换），以及当会话视图（重新）挂载页脚时。

如果 DSH 的标记在未来版本中发生变化，该插件会降级为静默的无操作——它绝不会破坏 UI，原版页脚只会保持被钳制的状态，直到更新为止。

诊断

打开 DevTools 并读取 window.__WIDE_STATS_FOOTER__：

{ appliedAt, styleHash, domHash, overrideChars, inlineFixed, lastSyncAt }

styleHash/domHash 显示从每个来源发现的 CSS 模块前缀；其中的 null 表示该来源尚未匹配。每次启动会记录一行 console.info。

故障排查 / 常见问题

页脚仍然被钳制。
在 DevTools 中检查 window.__WIDE_STATS_FOOTER__：

- styleHash: null 且 domHash: null —— 哈希发现未匹配到任何内容。
这意味着你的 DSH 构建的标记/CSS 与已验证的形态不同（例如更新的 DSH 版本）。该插件已降级为无操作；请提交 issue，附上你的 DSH 版本和诊断对象。
- 哈希存在但 overrideChars: 0 —— 覆盖规则已写入，但基础钳制规则不是预期的形态。同样值得提交 issue。
- appliedAt: null —— 插件从未运行；确认它确实已安装（dsh --profile web --dump-config 应显示该层），并且你在安装后重启了 dsh web。

它原本能用，但在 DSH 更新后停止了。
偶尔会出现这种情况：CSS 模块哈希会在重建时轮换。插件会在运行时重新发现它，因此更新后停止意味着标记* 形态发生了变化。检查诊断对象并报告。

这会让应用变慢吗？
不会。发现逻辑每次启动运行一次，外加在观察到的 DOM/样式变更时运行；观察器不进行周期性轮询。

我可以更改对齐方式吗（左/右而不是居中）？
不能通过配置——此插件刻意不提供配置，只做一件事。
DSH 的基础 text-align: center 被保留。

它能与自定义主题一起使用吗？
可以。覆盖使用双类名特异性（0,2,0），因此无论样式表顺序如何，它都能胜过原版规则。如果某个主题自身以相等或更高的特异性覆盖页脚的 max-width，它会胜出——这是正确的行为。

兼容性

针对 DSH 0.1.1-rc.2 web 构建并验证。仅客户端：无宿主侧行为、无配置、零 npm 依赖、无安装脚本。

许可证

MIT