轮次性能仪表 HaowenCang/dsh-turn-performance-meter

dsh-turn-performance-meter

面向 DeepSeek Harness（DSH）智能体工作流的 turn 级性能统计插件。它适用于一个 turn 内存在多次模型调用、工具调用、重试、shell 命令、文件写入/编辑以及最终回答的场景。插件包含两种 UI：执行过程中的紧凑实时统计，以及 turn 完成后的统计卡片。完成态卡片按整个 turn 聚合。

已发布 npm 与 GitHub v0.1.5，面向 DSH 0.2.0-rc.2。 版本 0.1.5，已发布到公开 npm registry。主要分发方式为 npm 包 dsh-turn-performance-meter；GitHub Release 资产 dsh-turn-performance-meter-0.1.5.tgz 作为离线回退，本地检出目录用于开发。发布与运行时对应关系见 §2.1。

1. What it does / 功能

统计边界是整个 turn，而不是单个模型 step。生成期间实时组件显示当前活动 attempt 的相位累计 TPS（当前相位片段自起点以来生成的 token 量除以该片段的墙钟时间），并始终带 ≈ 近似标记；该片段累计满 3 个样本之前，组件显示该片段的计时器而不是不稳定的速率。非模型解码阶段（工具执行、步骤间隙、重试退避）显示正在进行的那个阶段各自的计时器，绝不显示过期的速率。turn 结束后，同一位置切换为静态完成态卡片，承载 turn 级的思考 TPS、输出 TPS、生成 Tokens、首响应、工具摘要与模型调用次数；鼠标悬停或用键盘聚焦时，前两个 TPS 栏位被吞吐曲线替换。

插件挂载在 conversation.input.dock、order: -10，位于输入框卡片上方；原生聊天统计保留其在输入框下方的原位置。两个视图都只是既有证据的投影，React 层不重新计算任何指标。

2. Support status / 支持状态

Version (working tree): 0.1.5
Development target: DSH 0.2.0-rc.2 only
Released: v0.1.5 -> DSH 0.2.0-rc.2
v0.1.4 -> DSH 0.2.0-rc.2
v0.1.3 -> DSH 0.2.0-rc.2text
v0.1.2 -> DSH 0.2.0-rc.2
v0.1.1 -> DSH 0.1.7-rc.2
主要分发渠道： npm 备用分发渠道： GitHub Release .tgz 开发方式： link checkout 验证方式： 本地自动化测试套件 + 真实 DSH 浏览器冒烟测试

2.1 Compatibility baseline / 兼容性基线 text plugin v0.1.1 -> DSH 0.1.7-rc.2 reference commit 477b4f420553e8a52c2fbccc464d7561b239c443 plugin v0.1.2 -> DSH 0.2.0-rc.2 reference commit 639ed015397290b3745d163aafe02ffee4aa3f84 plugin v0.1.3 -> DSH 0.2.0-rc.2 reference commit 639ed015397290b3745d163aafe02ffee4aa3f84 plugin v0.1.4 -> DSH 0.2.0-rc.2 reference commit 639ed015397290b3745d163aafe02ffee4aa3f84 plugin v0.1.5 -> DSH 0.2.0-rc.2 reference commit 639ed015397290b3745d163aafe02ffee4aa3f84

0.2.0-rc.2 是当前工作树的规范运行时。 Phase 9.3 把开发目标迁移到该版本，并重新审计了本插件读取的每一项 DSH 声明——会话事件信封、LLM 流与紧凑 AssistantStreamRecord 形状、session-controller 的事件窗口与结算契约、conversation.input.dock 插槽契约、插件兼容门控，以及完成态卡片所依据的 TodoPanel 视觉契约。全部十四项声明在两个参考 commit 之间逐字节一致，所以插件消费的遥测、流、会话与插槽契约都没有变化：没有适配器代码改动，没有指标语义改动，也不涉及任何兼容性豁免。对比结果记录在 docs/DSH_API_NOTES.md §14。

这个结论是刻意限定范围的：它不是 0.2.0+，不是 0.2.x，也不是「最新的 DSH」，因为其他版本都没有实测过。支撑该结论的本地证据是命令行（dsh --version）、已安装的包（npm list -g @deepseek-ai/dsh）以及组装后的配置档目录树，全部记录在 docs/IMPLEMENTATION_LOG.md。

v0.1.2 是让该目标成为正式发布目标的版本，v0.1.3、v0.1.4、v0.1.5 原样沿用，未作改动：工作树中 version: 0.1.5，peer 仍是 0.2.0-rc.2；而已发布的 v0.1.4、v0.1.3、v0.1.2、v0.1.1 产物不可变——v0.1.5、v0.1.4、v0.1.3、v0.1.2 声明 0.2.0-rc.2，v0.1.1 仍声明 0.1.7-rc.2。各版本各自限定范围，而不是写成一个区间——每个版本只声明一个运行时，插件不声称两者都能跑。多运行时打包需要显式的双运行时验证，不属于本次发布。v0.1.5 是 0.2.0-rc.2 线上的视觉延续与生命周期恢复版本：它不迁移运行时目标，也不给任何更早的版本重新打标。

0.2.0-rc.2 是当前工作树的规范运行时。 Phase 9.3 将开发目标迁移到该版本，并对照本机 0.2.0-rc.2 安装与上述公开参考 commit，重新审计了本插件读取的全部 DSH 声明——会话事件信封、LLM 流与紧凑 AssistantStreamRecord 形状、session-controller 的事件窗口与结算契约、conversation.input.dock 插槽契约、插件兼容门控，以及完成态卡片所依据的 TodoPanel 视觉契约。全部十四项声明在两个参考 commit 之间逐字节相同，因此插件消费的遥测、流、会话与插槽契约均未变化：adapter 代码未移动，指标语义未移动，也不涉及任何兼容性豁免。对比记录见 docs/DSH_API_NOTES.md §14。

该声明有意限定范围：不写 0.2.0+、不写 0.2.x、也不写「最新 DSH」，因为其他版本均未被实际验证。本机证据来自 CLI（dsh --version）、已安装包（npm list -g @deepseek-ai/dsh）与组合后的 profile 树，均记录在 docs/IMPLEMENTATION_LOG.md。

v0.1.2 即该目标转为正式发布的那个版本，v0.1.3、v0.1.4 与 v0.1.5 原样延续该目标：工作树携带 version: 0.1.5 与同一个 0.2.0-rc.2 peer，而已发布的 v0.1.4、v0.1.3、v0.1.2 与 v0.1.1 产物不可变更——v0.1.5、v0.1.4、v0.1.3 与 v0.1.2 声明 0.2.0-rc.2，v0.1.1 仍声明 0.1.7-rc.2。各发布版本是各自限定的，而不是写成一个范围——每个版本只声明一个运行时，插件不声称可同时运行于两者。多运行时打包需要显式的双运行时验证，不属于本次发布范围。v0.1.5 是 0.2.0-rc.2 线上的视觉连续性与生命周期恢复发布：不移动运行时目标，也不改写任何既有发布。

Phase 7D 将 adapter、client feed 与完成态路径迁移到该版本：工具结果经一等公民的 tool-role message 识别（message.toolCallId、message.isError）；裸 settleAssistant(attemptId) 依据已持有的证据判定，而不再一律读作 abandonment；turn/end 即使没有已打开的 record 也具终止性；会话日志格式为 v4。逐字段契约记录见 docs/DSH_API_NOTES.md §13。

fixtures/dsh-turns/ 下的八段录制采集自 0.1.5。它们仍是指标算术、解码器与历史兼容性的证据，但不是 tool/result 形状、settle-assistant 语义、turn 完成生命周期或客户端事件窗口行为的证据，也不构成受支持的运行时契约。package.json 声明精确兼容门控 "peerDependencies": { "@deepseek-ai/dsh": "0.2.0-rc.2" }。DSH 会在 profile 启动插件前用当前运行时版本校验该 peer，因此不受支持的 DSH 会被拒绝，而不会被静默接受。使用精确范围是有意的：^0.2.0-rc.2、~0.2.0-rc.2、>=0.2.0-rc.2、0.2.x 与 都会放行本项目从未实际验证过的运行时，而 0.1.7-rc.2 || 0.2.0-rc.2 这样的双范围会抹掉 v0.1.1 与 v0.1.2 之间的证据边界。已录制语料保留其采集时的版本：fixtures/dsh-turns/ 为 0.1.5，
fixtures/dsh-0.1.7/ 为 0.1.7-rc.2，两者均未改写版本标记。

3. 安装

安装方式有三种。npm 包是主要分发方式；GitHub Release tarball 是离线、不可变的回退方式；检出目录仅用于开发插件本身。

3.1 前置条件

插件声明精确的运行时 peer，而 DSH 会拒绝启动 DSH peer 与当前运行时不匹配的插件，因此前置条件遵循 §2.1：安装与所要安装的插件版本相匹配的运行时。

| 安装对象 | 所需 DSH |
| @0.1.5（npm / GitHub Release，§3.2、§3.3） | @deepseek-ai/dsh@0.2.0-rc.2 |
| @0.1.4（npm / GitHub Release，历史版本） | @deepseek-ai/dsh@0.2.0-rc.2 |
| @0.1.3（npm / GitHub Release，历史版本） | @deepseek-ai/dsh@0.2.0-rc.2 |
| @0.1.2（npm / GitHub Release，历史版本） | @deepseek-ai/dsh@0.2.0-rc.2 |
| @0.1.1（npm / GitHub Release，历史版本） | @deepseek-ai/dsh@0.1.7-rc.2 |
| 开发检出目录（§3.4） | @deepseek-ai/dsh@0.2.0-rc.2 |
powershell

released v0.1.5, and the development checkout

npm install -g @deepseek-ai/dsh@0.2.0-rc.2

historical v0.1.1 only

npm install -g @deepseek-ai/dsh@0.1.7-rc.2

不要安装任意「最新」DSH 并假定插件可在其上运行：本插件只声明精确的运行时兼容性，且除上述两个版本之外本项目未验证任何 DSH 版本。

3.2 npm 默认安装 powershell
dsh plugin --profile web add dsh-turn-performance-meter

固定版本以获得可复现的安装： powershell
dsh plugin --profile web add dsh-turn-performance-meter@0.1.5

无版本号命令解析 npm 的 latest dist-tag；固定版本形式精确解析 0.1.5。两者安装的都是已发布产物的冻结副本。

3.3 GitHub Release tarball（离线回退）

从 v0.1.5 release 下载 dsh-turn-performance-meter-0.1.5.tgz 后安装：powershell
dsh plugin --profile web add "file:C:/path/to/dsh-turn-performance-meter-0.1.5.tgz"

这是离线且不可变的回退方式，资产与 npm registry 提供的 tarball 是同一份。对 tarball 使用 file: 得到的是一份冻结产物，这正是目的所在：安装的字节不会相对已发布的 release 漂移，且该 release 附带 .sha256 sidecar，可在安装前校验下载内容。

安装前校验下载内容： powershell Get-FileHash .\dsh-turn-performance-meter-0.1.5.tgz -Algorithm SHA256 Get-Content .\dsh-turn-performance-meter-0.1.5.tgz.sha256

3.4 Development checkout / 开发检出 powershell
dsh plugin --profile web add "link:C:/path/to/dsh-turn-performance-meter"

link: 跟踪工作检出目录，仅用于开发。理由来自实测，而非风格偏好。pnpm 把 link: 安装为指向检出目录的符号链接，因此之后执行 npm run build:client，profile 会直接读到新字节，无需重装；而 §3.2 与 §3.3 的 npm 与 file: 形式安装的是一份冻结副本。所以 link: 不是分发形式：它跟随检出目录的当前内容，包含未提交的改动，无法代表一份不可变的已发布安装。

以上每种命令都会在首次使用时初始化 profile，并因为本包声明了 dsh.bundle.patch 而自动把包名加入 dsh.profile.bundles。

本项目的录制证据来自参考检出目录 E:\Projects\DSHarness\dsh-turn-performance-meter；实际使用时替换为任意绝对路径。安装后刷新页面；若需要重新读取 loader 条目，则重启该 profile。

Web 客户端中的插件 UI 同样可以添加绝对本地目录。本项目不需要修改 DSH 核心源码：安装过程不修改 DSH、不修改任何 node_modules 文件，也不修改已安装的包。

4. Usage / 使用

无需按会话配置。实时组件挂载到客户端当前显示的会话，并在销毁时解除。

诊断默认关闭。把下面的浏览器 local-storage 键设为 1 并重新加载，即可启用生命周期日志诊断默认关闭。将下列浏览器 local-storage 项设为 1 并刷新，可启用生命周期日志（console.debug）与只读句柄 —— 包括会话挂载、turn 开关、attempt 与工具边界、质量降级、rebaseline。它仅是诊断辅助，正常使用不需要，且两种模式下都不会记录逐 delta 日志。
js
localStorage.setItem('dsh-turn-performance-meter.debug', '1')
// window.__dshTurnPerformanceMeter.{controller,diagnostics,attachedSessions,meter}

同一开关也是触达刷新节奏覆盖项 dsh-turn-performance-meter.refreshMs 的唯一途径；该项的存在是为了在浏览器中实测刷新节奏的 A/B。诊断开关关闭时，生产刷新节奏只有一个来源（src/client/live/cadence.js），任何持久化值都无法改变它。

5. Metric semantics / 指标口径

以下口径已冻结。禁止对各 step 的 TPS 做算术平均；速率始终是 turn 级「和之比」。

| Field | Definition | Secondary line |
| Reasoning TPS / 思考 TPS | sum(reasoning tokens) / sum(reasoning generation time) across the turn | reasoning duration · reasoning tokens |
| Output TPS / 输出 TPS | sum(non-reasoning output tokens) / sum(output generation time) across the turn | output duration · output tokens |
| Generated Tokens / 生成 Tokens | sum of provider outputTokens for contributing attempts | total turn elapsed time |
| TTFT / 首响应 | turn start → first non-empty reasoning/text/tool-call delta | turn status |

卡片底部（而不是第五个栏位）承载工具摘要（工具 4 · 12.8s，使用 wall union）与模型调用次数；无工具调用的 turn 直接隐藏该项。

实时组件显示当前活动 attempt 当前相位片段的累计 TPS：该片段自首个样本以来生成的 token 量除以片段墙钟时间，且在片段累计满 3 个样本后才发布，始终带 ≈，且不显示曲线。reasoning → output 切换会重置片段时钟、分子与样本计数，因此首个输出速率绝不包含 reasoning 阶段的耗时；工具调用或重试之后的新模型调用会重置全部状态，因此互不相关的调用绝不会混在一起。模型 attempt 没有流式输出就没有数值 —— 绝不显示过期速率。停滞会随墙钟时间呈双曲线衰减：分子停止增长，分母继续推进。
输出速率绝不包含 reasoning 片段的已用时间；工具返回后的新模型调用或重试会重置全部状态，禁止混合两个独立模型调用的数据。没有 model attempt 在流式输出时即无该值，绝不显示过期速率。停滞按已流逝的墙钟时间呈双曲线衰减：分子停止增长而分母继续推进。

模型生成的普通文本与 tool-call arguments 均属于模型输出，因此 PowerShell 命令、shell 脚本、写文件正文与编辑 patch 都计入输出统计。工具自身返回的 stdout、文件读取结果、API 结果等不计入模型输出；它们如果随后送入模型，则属于下一次模型调用的输入。reasoningTokens 已包含在 outputTokens 中，非思考部分为 outputTokens - reasoningTokens，两者绝不相加。

工具耗时按两个轴统计：toolWorkMs 是所有已完成工具调用时长之和；toolWallMs 是工具执行区间的并集，因此不会对并行工具重复计时。紧凑 UI 显示 toolWallMs；求和值保留在 view model 中供详细/调试界面使用。

5.1 Measurement fidelity / 测量精度

DSH 流式 delta 提供文本/工具参数片段及时间戳，而权威 provider token usage 通常是聚合值，并非每个 delta 都携带精确 token 数。因此实现显式记录指标质量，不把所有实时值和曲线点伪装成精确数据。质量在三个独立轴上记录，因为单一标签无法描述整条曲线：token 总数质量（最高可达 exact）、reasoning/output 拆分质量（仅在 provider 报告 reasoningTokens 时可达 exact）、时间形状质量（上限为 reconstructed）。

每一轴的等级为 exact · calibrated · reconstructed · partial · estimated · unavailable。仅 exact 免除 ≈ 标记；unavailable 显示 —，绝不静默归零。

5.2 Curve / 曲线

曲线是每个 model attempt 一条 attempt-local 的阶段累积吞吐轨迹：attempt-local t 处的顶点报告 t 时刻生效的阶段片段的累积平均值——该片段截至 t 的样本量除以墙钟曲线是每个 model attempt 各一条 attempt 局部的相位累计吞吐轨迹：局部时刻 t 的取值是 t 处生效的那个相位片段的累计平均——该片段截至 t 的样本量除以自其首个样本以来的墙钟时间——不区分相位，与实时指示器属于同一估计器族。压缩横轴把各 attempt 首尾相接，因此工具时间与 attempt 间等待占用零宽度；但每个片段拥有自己的时钟与分子，轨迹在相位边界处下台阶，再依据新相位自身的证据重新爬升；attempt 内部的模型静默按完整宽度绘出，表现为双曲线衰减，而不是归零。reasoning 与 output 是同一条轨迹的两种颜色。轨迹以 100 ms 网格采样，发布序列按时间等距取最近样本压缩到 200 点上限，不做插值。图级渲染预算为 512 点，按相位色段分配并保留全局峰值；peakTps 则在应用任何渲染配额之前从发布序列读取。当存在权威 usage 时，曲线量级采用 provider 校准后的逐 delta 分配，因此曲线与卡片打印的 token 总数属于同一量级体系；turn settle 之后，attemptBreakdown[].calibration.samples 始终是量级的权威来源。

完整口径见 docs/METRICS_SPEC.md §11，durable/transient 两类证据的规则见 §13，架构见 docs/ARCHITECTURE.md。

6. Known limitations / 已知限制

实时 TPS 是近似的。 DSH 的 delta 不携带逐 token 精确计数，因此实时 TPS 属于启发式 delta 加权，且始终标 ≈。它不是精确测量，不应被当作精确测量读取。

完成态 token 总量取决于 provider usage。 当 provider 报告 outputTokens 与 reasoningTokens 时，相应总量与 phase 拆分可达 exact；未报告时，phase 拆分被估计或重建，卡片以 ≈ 标记。

时间曲线永远做不到逐 token 精确计时。 DSH 提供 delta 时间戳，但不提供每个 delta 的权威 token 计数，因此时间形状的质量上限是 reconstructed，任何曲线顶点都不可能精确。
时间曲线永远不是精确的逐 token 计时。 DSH 提供 delta 时间戳，但不提供每个 delta 的权威 token 数，因此时间形状质量的上限是 reconstructed，任何曲线顶点都不可能 exact。

缺少 turn/start 时 TTFT 与耗时为不可用。 终末 tail 重建会从发布窗口仍持有的 durable 证据复原 record。若该窗口从未包含该 turn 的起始边界，则 startMs 保持 null，TTFT 与 turn elapsed 显示 —；仅 firstTokenMs 可能仍能由 durable 样本得知。插件并非总能恢复 TTFT，也不会编造 start 边界。

保留的 durable 证据是有界的。 窗口代际重建预算为 MAX_RETAINED_TURNS = 32，按最久未更新淘汰，且只保存证据 字节 —— durable 身份是全代际的，淘汰不会遗忘。这是重建过程的内存上界，不代表"只支持 32 个 turn"。

Fixture 证据是有界的。 0.1.7 的真实录制语料目前只有两个文件：fixtures/dsh-0.1.7/index.json 与 fixtures/dsh-0.1.7/t01-sequential-tools.json。settle-assistant 的 retirement/abandonment 契约由针对移植后 fold 代数的合成契约测试覆盖，而非由 host 录制的 0.1.7 fixture 覆盖。

浏览器证据是有界的。 Phase 7D.1 的终末 tail 场景（turn/end 到达时 turn/start 已滑出窗口）并未在浏览器中直接构造。它由真实录制的 durable 字节、真实的 feed/controller 回放，以及 DSH 有界窗口契约共同确立，不属于浏览器复现。

验证是本地进行的。 本仓库没有 GitHub CI runner，因此本仓库中引用的所有 npm run verify 结果都是本地测试结果，而非 CI 结果。完整证据保留在 implementation log 中。

7. Repository map / 项目结构 text dsh-turn-performance-meter/ ├─ README.md ├─ CHANGELOG.md Release history (0.1.5) ├─ LICENSE MIT ├─ package.json version 0.1.5, published to npm, scripts: test / build:client / verify ├─ cordis.patch.yml Bundle 行插入；本插件添加的唯一 DSH 组合 ├─ index.js 宿主入口（刻意留空；遥测在客户端侧） ├─ client.js 生成的浏览器 bundle（npm run build:client） ├─ lib/client.js 相同字节；本地注入器校验的布局 ├─ docs/ │ ├─ ARCHITECTURE.md │ ├─ METRICS_SPEC.md │ ├─ MIMO_RUNTIME_METRICS.md │ ├─ UI_SPEC.md │ ├─ DSH_API_NOTES.md │ ├─ TASKS.md │ ├─ TEST_PLAN.md │ ├─ DIRECTORY_TREE.md │ ├─ START_PROMPT.md │ ├─ IMPLEMENTATION_LOG.md │ └─ assets/ 四张参考布局截图 ├─ fixtures/ 录制的 DSH 回合证据（离线；无需 DSH） │ ├─ README.md │ ├─ index.json │ ├─ dsh-0.1.7/ rc.2 语料：index.json + t01-sequential-tools.json │ ├─ dsh-turns/ 八个真实录制的回合（0.1.5），持久层与瞬态层逐字保留 │ └─ derived/ 这些录制内容的四个已声明合成变体 ├─ src/ │ ├─ core/ 纯指标引擎 —— 零 @deepseek-ai/ 导入（15 个模块） │ ├─ dsh/ DSH rc.2 原始证据 -> 规范化事件（+ client-feed） │ ├─ host/ TurnTelemetryStore（按 session+turn 键控） │ └─ client/ main.js 入口 + 展示层 │ ├─ live/ 状态机、presenter、scheduler、controller、MeterRoot、 │ │ React pill、locale、CSS │ └─ completed/ 已完成卡片视图树 + React 绑定 + 卡片 CSS ├─ test/ 65 个测试文件 + helpers/（core / dsh / live / completed / bundle） └─ scripts/ verify-structure、bundle-client、build-client、 sanitize-fixtures、verify-sanitization

dev/ 仅开发用的工具，不属于 bundle ├─ fixture-recorder/ 注入式宿主录制器：session/event + agent/assistant-stream ├─ capture-scenario.ps1 实时场景驱动（启动 / 中断） ├─ harvest-fixtures.mjs 原始录制 -> fixtures/dsh-turns/* ├─ mutate-fixtures.mjs 带来源信息的确定性合成派生 ├─ measure-generation-tail.mjs ├─ inspect-recording.mjs └─ recordings/ 启动回执 + 捕获的模型目录

dev/screenshots/ 与 fixtures/raw/ 是 git 忽略的本地证据目录：前者存放浏览器截图，后者存放脱敏前的 fixture 原件。
两者都不属于仓库内容，也不属于安装后的 bundle。

纯指标引擎与 DSH adapter 层都有无需 DSH 进程即可运行的测试；已录制的 fixture 使 adapter 层可以离线验证。

8. Development and verification / 开发与验证

项目使用 Node 内置测试运行器；无需测试依赖、打包器或网络访问。编辑之后 src/client/，先构建再验证——scripts/verify-structure.mjs 会检查 bundle 是否相对 src/ 过期，过期就报错，所以对未构建的 client 源码跑 npm run verify 本来就会失败：

本项目使用 Node 内置测试运行器；不需要测试依赖、打包器或网络访问。修改 src/client/ 之后应先构建再验证——

scripts/verify-structure.mjs 会在 bundle 相对 src/ 过期时失败，因此对未构建的 client 源码直接运行 npm run verify 预期会失败： powershell
npm run build:client # rewrites client.js and mirrors the same bytes to lib/client.js
npm run verify # structure check + full test suite
node scripts/verify-sanitization.mjs

npm run verify runs node scripts/verify-structure.mjs && node --test test/.test.js. The structure check asserts that
the required files exist, that every src/core module has a matching test, that every local import under src/ resolves,
that client.js is fresh relative to src/, and that lib/client.js is byte-identical to client.js. npm test runs
the test suite alone.

npm run verify 执行 node scripts/verify-structure.mjs && node --test test/.test.js。结构检查断言：必需文件存在、
每个 src/core 模块都有对应测试、src/ 下每个本地 import 均可解析、client.js 相对 src/ 是新的、且 lib/client.js 与 client.js 逐字节相同。仅运行测试套件使用 npm test。

Do not add a frontend React dependency solely for the DSH client module; DSH supplies React through its browser module
table. Because a DSH client bundle is a single classic script whose factory require resolves only module-table words,
scripts/bundle-client.mjs deterministically bundles the src/client/main.js graph into client.js (verified by
test/client-bundle.test.js; no bundler dependency is installed).

不要仅为 DSH Client 模块而安装额外 React 副本；DSH 会通过浏览器模块表提供 React。由于 DSH 客户端 bundle 是单个 classic script（factory 的 require 只解析模块表词汇），scripts/bundle-client.mjs 将 src/client/main.js 依赖图确定性地打包进 client.js（由 test/client-bundle.test.js 验证，不引入任何打包器依赖）。

To capture new DSH evidence (only needed when recording new fixtures, in a DSH host with dsh-super-injector):

如需重新采集证据（仅在抓取新 fixture 时需要，且须在装有 dsh-super-injector 的 DSH host 内）： powershell
dsh --version

inject dev/fixture-recorder, then:

powershell -File dev/capture-scenario.ps1 -Name A1
node dev/harvest-fixtures.mjs
node dev/mutate-fixtures.mjs --write
node dev/measure-generation-tail.mjs

See fixtures/README.md for the fixture shape and dev/fixture-recorder/README.md for the recorder. The recorder is
dev-only and never part of the plugin bundle.

fixture 结构见 fixtures/README.md，录制器见 dev/fixture-recorder/README.md。录制器仅供开发使用，不属于插件 bundle。

The executable task list and acceptance gates are in docs/TASKS.md; the implementation log with per-phase evidence is
in docs/IMPLEMENTATION_LOG.md; the prompt that starts DeepSeek V4.1 Flash is in docs/START_PROMPT.md.

可执行任务列表与验收门槛见 docs/TASKS.md；逐阶段证据见 docs/IMPLEMENTATION_LOG.md；启动 DeepSeek V4.1 Flash 的提示词见 docs/START_PROMPT.md。

9. License / 许可证

This project is licensed under the MIT License. See LICENSE.

本项目采用 MIT 许可证，详见 LICENSE。