配置

- id: test-design-gate
  name: 'dsh-test-design-gate'
  config:
    enabled: true
    logFile: '~/.dsh/test-design-gate.log'
    layout: { rootDir: '.dsh' }     # 可选：rootDir / specsDir / missionsDir
    minTextLength: 4
    strict: false
    allowDanglingCase: false
    requireAllScenarios: true
    prompt: { enabled: true, order: 630 }

以上是 profile 配置（上限）；每个仓库还可以用 .dsh/test-design-gate.json 细化本工作区的评审口径（minTextLength / strict / allowDanglingCase / requireAllScenarios），详见下一节。

项目级配置

一个 dsh profile 同时服务多个仓库，所以"这个仓库的测试设计评审有多严"不可能对每个工作区都合适。每个工作区可以用自己的一份文件细化本仓库的评审口径：

/.dsh/test-design-gate.json

{
  "minTextLength": 20,
  "strict": true,
  "allowDanglingCase": false,
  "requireAllScenarios": true
}

profile 是上限：项目文件只能细化评审口径，不能把门禁关掉，也不能搬走工件目录。未命中的键一律 忽略并记录问题（插件日志里逐键给出原因），绝不静默生效。

可覆盖键（未写的键继续用 profile 的值）：

键	类型	作用
`minTextLength`	≥ 1 的整数	本工作区「操作步骤 / 预期结果」的最小长度（默认 4）
`strict`	bool	本工作区是否默认要求每条验收标准有异常或边界用例
`allowDanglingCase`	bool	本工作区是否容忍不声明验收标准的用例
`requireAllScenarios`	bool	本工作区是否要求正向 / 异常 / 边界三类场景齐全

只能由 profile 决定（写了也会被拒绝，并逐条记录原因）：

键	拒绝理由
`enabled`	是否加载插件是部署决策：项目文件不能把测试设计门禁关掉（关掉等于让 `spec_approve` 不再检查测试设计）
`logFile`	日志落盘位置是部署决策
`rootDir` / `specsDir` / `missionsDir` / `layout`	规格 / mission / 评审报告的落点是宿主布局决定，项目文件不能迁移它们
`prompt`	系统提示词章节属于宿主装配决策

信任根：.dsh/** 被 dsh-spec-gate 的 guard 对写工具关闭（只有派生的 specs/*.md 可写），所以模型无法用 write / edit 把自己的评审调松——能改这个文件的只有人。注意这个保护覆盖的是写类工具：用 bash（echo >、sed -i 等）改它只在 dsh-spec-gate 的 shellPolicy: strict 下才被拦下。

失败绝不放行：文件不存在 / 不是合法 JSON / 顶层不是对象 / 某个值类型不对（"20" 不会被当成 20）时，回退到 profile 配置并记录问题（逐键回退，不做类型强转），评审照常执行——坏掉的项目配置永远不会变成"没有评审"。

生效范围：按调用方会话的 header.cwd 逐次调用解析（读者按 mtime+size 缓存，热路径每次只多一次 stat）。 test_design_review 的返回与 test-design-review.md 都会写出生效策略与来源（配置：项目级（minTextLength=…；strict=…） 或 配置：profile（…））； prompt section 也在每次装配时按该 agent 的工作区渲染同一组值（未声明工作区时回退 profile 文本）。未声明 header.cwd 的会话，test_design_review 直接拒绝执行（中文错误提示：无法确定本会话的工作区），绝不退回 process.cwd()——那会把评审写到 harness 自己所在的、错误的项目里； test_design_template 不读磁盘工件，因此没有工作区也能用。

dsh-test-design-gate

설치

문서

配置

项目级配置