Dsh Benchmark Case

从插件仓库提取 dsh 升级考题

把一个真实发生的插件迁移（git 历史里的破坏性变更 commit）变成一道 Harbor 考题：旧形态插件为 fixture（装上必坏，或有隐藏坑），新形态为 oracle 参考解，judge 在容器内真实冷启动判活。产出跟随 ./benchmark/（上文：oh-my-dsh/dsh-plugin-upgrade-skill 的 benchmark 目录）。

上下文锚点：目标套件是 dsh-plugin-upgrade-skill 的 benchmark v2.4（Harbor 格式），host 镜像固定为 node:24-bookworm + 全局 dsh 0.1.2-alpha.2。每条考题 遵循 execution-contract（BENCHMARK-AUTH-v1）与固定评分模型（100 分/题）。

何时使用

• 用户给一个插件仓库，说"提成考题 / 做成 case / 转 benchmark task"。
• 用户拿着一条版本走廊或一个迁移 commit，要可执行的评测而不是文档。
• 现有升级卡（references/v*.md）需要测"AI 会不会照卡修"。

工作原理（一句话）

fixture = 迁移前形态（偶藏误导注释/预置失败），judge = 静态检查 + 容器内真实冷启动信号（pending / plugin tree failed / MISSING_CREDENTIAL / __DSH_BOOT__ 条目），oracle = 参考迁移，判分天然 0~1。

Pipeline

Stage 0 · 选材与走廊定位

先回答三个问题，答不出就退回升级卡形态，不做题：

1. 迁移方向：仓库 git 历史里哪一个 commit / 哪一段走廊是"host 升级导致的 必需改动"？（例：426e86d whale-girl bundle 转换，走廊 rc.8→rc.1）。 纯自研重构、无 host 侧断裂的 commit 不成题。
2. 可测性：迁移后形态能否在容器内"装得上 + 冷启动得到确定信号"？ 判分信号必须是宿主侧信号（见 Stage 3），不是"输出文本长什么样"。 无浏览器容器 ⇒ client 运行时不可判，只能判 boot 图条目 / HTTP 状态。
3. 对应卡：这条走廊在 references/ 里有没有卡（或需要先补卡）？ 考题与卡是一对多：一道题可以覆盖多张卡，但卡必须已存在或随题新增 （validate.mjs 会校验卡引用存在且链接可解析）。

选材标准（×成立越多越好）：迁移真实发生过（有 commit 可考）； 断裂面小（1~4 个 touchpoint）；装旧形态必有可观察故障（pending / 静默缺行为）； 新形态在 alpha.2 上可冷启动验证；最好带隐藏坑（诱导注释 / 看着无辜的面上 藏着致命伤——坑要来自真实迁移的"第二个 commit"，不是编的）。

产出：选定的 task id（见 Stage 1 命名）+ 走廊 + 覆盖的卡 ID 清单 + fixture 应模拟的第 N 个 commit 形态（迁移前）。Checkpoint：三者对齐才继续。

Stage 1 · 骨架与命名

任务目录 tasks/<id>/，id 命名：前缀字母 S（静态只读）/ M（迁移可改）/ H（hands-on 陷阱），编号接该系列现有最大值。编号不要凭记忆硬编码—— 动手前先 ls benchmark/tasks/ 并对照 benchmark/README.md 任务表与注册表 校验脚本确认当前集合（当前 52 题：S1–S16 / M1–M14 / H1–H22，下一可用 S17 / M15 / H23），勿跳号。一个任务一个目录：

tasks/<id>/
├── instruction.md        # 给 agent 的 prompt（含 BENCHMARK-AUTH-v1 契约）
├── task.toml             # Harbor 配置（见 assets/task.toml.example）
├── environment/
│   ├── Dockerfile        # node:24-bookworm + git + pnpm + dsh alpha.2 + git 基线
│   └── fixture/          # 旧形态插件（private:true，README 声明 exam material）
├── tests/
│   ├── test.sh           # verifier 入口：跑 judge，score→reward 写 /logs/verifier/
│   ├── judge.mjs         # 判分逻辑（全部在这）
│   └── judge-utils.mjs   # 共享判分库：profile 生命周期、冷启动信号、清理
└── solution/
    ├── solve.sh          # oracle：把参考解拷进 fixture
    ├── SOLUTION.md       # 参考解说明 + The Point + Grading Boundary
    └── plugin/           # 参考迁移后的完整文件

模板在 $_S/assets/：task.toml.example、instruction.md.example、 judge-utils.mjs（整库直接复制）、test.sh.example、Dockerfile.example、 solve.sh.example、judge.mjs.example（骨架）。

装 dsh 的 Dockerfile 必须（与现有任务一致，勿改版本）： FROM node:24-bookworm；装 git；npm install -g pnpm@11.24.0 @deepseek-ai/dsh@0.1.2-alpha.2；COPY fixture → /app/fixture；git init + 基线 commit（judge 靠 git status --porcelain -- fixture 判"fixture 是否被改"， 只读题 0 分门禁，可变题 0 分门禁的相同实现）。Checkpoint：目录 6 块齐全。

Stage 2 · fixture 构造

按"迁移前第 N 个 commit"的真实形态写 fixture，三个纪律：

1. 必须私有：package.json "private": true；README 首行 "exam material only, do not publish"。源头切片除外（见 4）。
2. 坑要用真坑：误导注释要像真话——来自真实迁移决策记录里"当时为什么 这样做/为什么别改"的措辞；预置失败测试要确实预先失败且与升级无关 （测诚实报告，不测静默修复）。
3. 坏必须可观察：旧形态要么装上 pending / plugin tree failed，要么 静默缺行为但 judge 有对应锚（如 boot 图没有该插件的 client 条目）。 判分锚必须能在容器里拿到，拿不到的 feature 不出现在 judge 里。
4. 上游切片保留原元数据（Apache-2.0 真实仓库切片如 dsh-web）：保留 license/original package.json，读 provenance/ 惯例（见基准 tasks/H9-dsh-web-alpha2/provenance/）。

fixture 放哪、可以留什么：Node half 可留在 .dsh-plugin/ 子目录等 旧布局位置——但这类布局有深坑可挖：host 的 client-modules 从 Node entry 文件向上找最近 package.json 作为包身份（机制见 $_S/references/host-archaeology.md 的"manifest 遮蔽"条目）。设计 fixture 时可利用这类机制布坑：让旧布局残留文件影响包识别，浏览器半静默消失； 判分侧的 boot 图条目检查会自然抓到。具体某道在线题怎么布、参考解怎么收 尾，不在此展开——方法级不讲答案。

Checkpoint：dsh plugin add 旧 fixture 在容器里真的坏 / 有静默缺陷； 新 fixture（参考解）全绿。两态都必须先本地 docker 验证，不许只靠想象。

Stage 3 · judge 设计（判分心法）

固定评分模型：100 分/题，emit(score, reasons) 最后一行输出 {"score":0-100,"max":100,"reasons":[...]}，test.sh 归一化到 0~1 写 /logs/verifier/reward.txt。线性叠加 checkpoints，禁止加权魔法。

通用三段式：

判分锚必须是宿主侧信号（从 judge-utils.mjs 输出获取）：

• NEGATIVE_SIGNAL：plugin tree failed / did not activate / pending (waiting for service: …) / FAILED fiber / ClientPackageCompositionError = 失败带（通常 40 或该 check 0 分）。
• headless 冷启动：无 API key 时到达 MISSING_CREDENTIAL / no API key / dsh: AUTH = 插件树整体激活，通过。出口码不算——无 key 成功也 exit 1。
• web 冷启动 + GET /：__DSH_BOOT__.entries 包含 <pkg>/client.js （注意：boot 图 URL 按 exports 的 key 拼 ${pkg}/client.js，与文件 真实路径无关）或该插件的 HTTP 通道 401/200 冒烟。

边界声明：judge 头注释与 SOLUTION.md 的 Grading Boundary 必须写明"容器 内没有浏览器 → client 运行时行为不判，只判宿主宣告的 boot 图条目"这类边界； 未覆盖面同样写进 scoring.md。

分数带设计提醒：给"半对"留带（关键声明完整给满分、缺字段给半分、 完全缺失 0 分）；陷阱跟随者给封顶（如误导注释说别改 X，留着 X = 该 check 上限）。判分必须能区分"真迁移"与"看起来绿但绕开了迁移"——绕道 路径 boot 也能绿，要用静态检查（grep 特定字段/模式）封顶才抓得住。

运行纪律：judge 只建 bench-<task> profile 与 /tmp/bench-<task>， finally 里清理（pkill 用 [x] 自逃逸模式防止自杀）。timeout 充足（add 180s / boot 60s / web 150s，真实 workspace 题 verifier 900s）。judge 永远 exit 0， test.sh 解析不了 JSON 时按 0 计。

Stage 4 · oracle（参考解）

solution/plugin/ 是完整迁移后的 fixture；solve.sh 逐文件覆盖进 /app/fixture/，并显式删除该题迁移要求删除的残留文件。 SOLUTION.md 三节必备：

1. Reference Changes：每条改动对应卡 ID 全名（如 DSH-0.1.1-R1-01， 不要写 R1-01 简写——validate.mjs 校验全 ID 存在）。
2. The Point (one sentence)：这道题真正测的一招。
3. Grading Boundary：与 Stage 3 的边界一致。
4. Warning：如果 judge 是 grep 源码模式判"已删除"，参考解源码注释里 不得出现被 grep 的字面 token（实战教训：solution 注释复述了被判 "已删除"的旧标识符字面，judge grep 命中注释导致自伤扣分）。

Checkpoint：oracle 在容器里跑出 100/100（reward 1.0，下一步做）。