四、配置

cordis.patch.yml 已给出全部键（扁平，一行一键），默认值与方案 §10.1 一致。常用项：

enabled: true            # 总开关
mode: enforce            # enforce | observe（只收集证据、不干预 turn）| off
defaultMode: regression   # quick | regression | full
maxRepairCycles: 3       # 整个门共享的修复预算
unknownRequiredCheck: block  # 必测项缺证据时：block | warn
sameFailureNoProgressLimit: 2
executionAutoInstallDependencies: false   # 不静默联网安装
memoryRequiredBeforeRepair: true
memoryOnReadFailure: block                # 检索失败即阻塞
memoryToolPattern: openviking             # 用于在运行时发现 OpenViking 工具
memorySearchTool: ''                      # 精确指定工具名（留空则按 pattern + search 语义发现）
allowNonGitBaseline: false                # 非 git 项目是否允许有界全树哈希回退（默认 fail-closed）
storageDir: ''           # 留空 -> $DSH_HOME/storages/verification-gate
requireDetectedProject: true              # 检测不到支持的项目就不介入（聚合工作区先尝试识别唯一子项目）
blockMutatingToolsWhileBlocked: true

嵌套写法（把方案里的 verification: / memory: 等分组直接抄进 config）也会被归一化接受。

非 git 项目：默认仍是 fail-closed——currentFacts 读不到 git rev-parse HEAD 就报 FINGERPRINT_UNAVAILABLE，不会把“没有 git”当成“没有改动”。如果项目本身有意不使用 git，显式设 allowNonGitBaseline: true：门会扫描并哈希有界的工作区文件树（跳过 .git、node_modules、 artifacts、构建产物等），用同一份全树哈希做基线/当前对比。注意此时 lazy baseline 的隔离工作树仍需要 git HEAD，只有在当前检查失败、需要构建基线侧时才会退化为“基线不可用”的如实报告。

工作区根是「容器」时（聚合工作区）

一个工作区可以不是项目，而是装着若干项目的目录（例如 C:\work 下有 app/、lib/、tools/，根目录自己没有 manifest）。基线必须在 turn 改动之前冻结，所以「这轮属于哪个子项目」不能用「这轮改了什么」来事后决定，只能由 turn 开始前就存在的信号决定，顺序固定为：

本会话此前已经识别出的项目（延续，不是猜测）；
用户消息里提到的路径在真实文件系统上只存在于唯一一个子项目中（支持 ai/policy.mjs 与 novel-studio/ai/policy.mjs 两种写法）；
工作区里只有一个项目。

三者都不成立时返回「没有可支持的项目」并明确告知未介入（每个任务一次），绝不用「最像的那个」顶上——挑错会冻结错的基线、跑去跑错项目的检查，比拒绝介入更糟。子项目识别结果绑定在任务上并落盘，宿主重启后由它恢复。

两个必须同时成立的前提（都实测踩过）：消息里的路径引用前导 @ 与 ./ 都会被剥掉后再匹配（否则提示自己推荐的写法读不懂，@novel-studio/package.json 得 0 分）；「未介入」不整代次钉住——applicable === false 的任务在后续每一轮都会重新判定，所以「这一轮把路径写对」当场生效、不必重启；每轮的新需求走 openRequirementsRevision 开新修订（只换需求，不重采基线）。

同一规则的另一面：被识别出的项目如果自己没声明任何检查（没 test/typecheck/build/lint 脚本，也没 vitest/pytest 配置），技术验收一律为 not_applicable 并写明原因，不得因为「没有检查失败」而报 verified——一个检查都没跑，就不是通过。

状态存放在哪里

storageDir（默认 $DSH_HOME/storages/verification-gate）下的 tasks/、reports/、snapshots/。 绝不写进被验证的项目目录：项目的构建、测试或 Agent 的编辑不能覆盖用来判断它们的证据。

OpenViking 绑定方式

宿主没有提供公开的记忆检索服务（openvikingMemory 负责采集/召回，记忆读取以 MCP 工具形态到达模型）。因此适配层走方案 §7.2 指定的方式：受控工具执行入口（ctx.tools.execute）调用运行时真实注册的 OpenViking 工具。调用前会检查该工具的真实 schema：

找不到可识别 query 参数的工具 → 报 unavailable，不会盲调；
查询无命中 → empty；查询未完成 → failed；被策略拒绝 → denied。

dsh-plugin-verification

インストール

ドキュメント

四、配置

工作区根是「容器」时（聚合工作区）

状态存放在哪里

OpenViking 绑定方式