omdsh-dev/dsh-inspect

@dsh-external/dsh-inspect

发现问题 → 修复交付 → 质量复查 的简单闭环插件。

三个朴素工具，共享同一套“对抗式检查”机制：

| 工具        | 干什么  | 核心机制                                                                                 |
| --------- | ---- | ------------------------------------------------------------------------------------ |
| checkup | 找问题  | 对抗式检查员（各看一个角度）→ 红队攻击验证（尝试推翻问题声明，推不翻的才保留）→ 汇总分级（严重/一般/建议）                         |
| fix     | 修复交付 | 拆解 → 并行实现（每个实现员按找根因（沿数据流找偏离源头）→ 实施 → 重跑复现验证（反馈闭合））→ 对抗式检查 → 修复轮收敛 → 交付报告 |
| review  | 质量复查 | 对抗式审查员（各看一个角度）→ 汇总分级；可传 fixed_issues 逐条重跑复现确认问题真的消失                            |

理论内核：控制论的反馈机制

- 发现是怀疑，验证是定罪：检查员/审查员一律对抗式（默认怀疑、找反例、只认可当场验证的证据）；
checkup 的红队环节就是负反馈——问题声明必须经受住攻击，推不翻才成立。
- 根据数据流定向判断状态：判断问题前先按数据流理清系统（输入 → 处理 → 存储 → 输出，
谁写谁读）；问题 = 数据流某处状态偏离预期，而不是静态读代码猜。
- 互相校验：每个问题必须给出可互相校验的验证方式（重跑复现 / 日志对照 / 输入输出对照 /
双路径对照），并写明预期状态与实际观测——无法通过系统反馈验证的，不许报。
- 修复要证伪：先沿数据流找到状态偏离的源头（不许修表面）；修复后重跑原复现，
观测输出与预期比较（反馈闭合）——问题没消失 = 根因没找对，重新分析。
- 根据数据判断直接定方案：根因找到后，方案由数据自然决定——实现员按“找根因 → 实施 → 验证”
三步直接做（根据数据判断选择最合理的方案，不空谈不犹豫，实施保持改动最小）。
- 闭环：checkup 的问题清单 → fix 修复任务 → review 把关（可逐条验证修复是否真消失）；
复查不通过或人的反馈重新进入 fix。三个工具可单独用，也可串起来。

结构

dsh-inspect/
├── package.json    # @dsh-external/dsh-inspect (MIT)（声明 dsh.bundle.patch）
├── cordis.patch.yml  # bundle 补丁：按包名插入插件行
├── src/index.ts    # cordis 插件：注册 checkup/fix/review 三个工具（官方 workflow 引擎；原生 TS，零构建）
├── tsconfig.json   # typecheck 配置（project references 解析到 sibling deepseek-harness 源码）
├── test/
│   └── regression.test.mjs  # 回归测试：前两轮 10 项修复固化为可重跑用例（node:test）
└── README.md

开发与检查

pnpm install        # 仅 typescript/@types/node（typecheck 用）
pnpm run typecheck  # tsc -b，类型从 sibling deepseek-harness checkout 解析
cd plugins/dsh-inspect && node --test   # 回归测试

源码即运行时：包入口直接指向 src/index.ts，无构建步骤。profile 安装的副本位于
node_modules 下，由 dsh 源码启动器的 tsx hook 加载（Node 原生类型剥离拒绝
node_modules 内的文件）；源码 checkout 在 node_modules 外直跑时也可用 Node ≥22.18
原生剥离。要求 erasable-only TS 语法（无 enum/命名空间等），测试的 vm 路径用
node:module 的 stripTypeScriptTypes 剥离类型，会挡住不可移植写法。

测试（回归）

cd plugins/dsh-inspect && node --test        # 零依赖，纯 node + node:test
或：node --test test/（Node ≤20 支持目录参数；Node 22+ 把位置参数当 glob，请用
node --test 或 node --test 'test/'，见 nodejs/node 测试运行器 glob 语义）

test/regression.test.mjs 用与引擎相同的 vm.Script '(async () => { body })()' 包装 +
全局钩子（agent/parallel/phase/log/args，agent 按 label 出 mock 队列）求值
src/index.ts 里真实的三个脚本（vm 路径先经 stripTypeScriptTypes 剥离类型），把前两轮的
10 项修复固化为可重跑断言：

① 转义无字面 '\n'（提示词/报告用真实换行）；② 红队五态（有效/空数组/null/部分覆盖/
幻觉剔除）；③ 子代理失败（checker/reviewer/merger/worker）如实标注不假干净；④ passed
诚实三态；⑤ fix 假收敛防护（checker null、worker null 均不产生假「通过」）；⑥ 4 个问题
全部重修；⑦ 未收敛明细；⑧ runWorkflow 透传 issues/rounds/passed；⑨ 参数校验抛错
（非数组/条目非对象）；⑩ 输出 schema 编译通过（移植 dsh-tools 的 DSL 编译 + 受支持子集
断言 + 值校验）。

工具注册层（⑧⑨⑩）优先动态 import 真实模块（tsx/DSH 环境），纯 node 下依赖不可解析时
退化为 vm 求值模块源码（mock schemastery/defineTool），两条路径断言一致。
After changing any script behavior, run node --test, and regressions become immediately visible.

Installation and Usage

The package declares dsh.bundle.patch (cordis.patch.yml), and is installed into any profile via dsh plugin
(replace  with tui / headless / web or a custom profile):

dsh plugin --profile  add git+https://github.com/dsh-external/dsh-inspect.git
dsh --profile         # Takes effect after restart: checkup / fix / review are injected with the profile

If pnpm rewrites the https URL to git+ssh (caused by the local global git insteadof configuration), use the
git+https:// form above; when dsh plugin prompts that allowBuilds is needed, just add a line to
$DSH_HOME/profiles//pnpm-workspace.yaml as prompted.

The three tools are triggered automatically by the model based on tool descriptions, or you can just speak plainly:

- Closed loop (recommended): first checkup to find problems → hand the problem list as-is to fix to repair → use review
to re-check the deliverable. Example: "Use checkup to inspect ./src, feed the problem list to fix for repair, and after fixing, review to gate it".
- Single use: checkup only without fixing → checkup (angles specifies the angles); deliver only → fix (acceptance
gives the overall acceptance criteria); gate only → review (pass the list of fixes to re-run and verify one by one via fixed_issues,
and report "severe" if any have not disappeared).
- Iterate: if review does not pass (or the human is dissatisfied with the delivery) → feed the feedback back into fix as new problems, until convergence.

Dependency requirements: the profile's composition must include the official workflow engine and the tool registration service — the official
dsh base composition includes them, so no extra installation is needed; when the composition does not include the workflow engine (such as the standard web composition), this plugin
still loads and registers as usual, and when checkup/fix/review are called it reports a clear guidance error (without hanging the profile). Peer dependencies
(@deepseek-ai/dsh-tools, etc.) are provided by the composition, and the profile's autoInstallPeers: false can avoid
looking up unpublished @deepseek-ai/ in the registry.

Update / Uninstall:

dsh plugin --profile  update
dsh plugin --profile  remove @dsh-external/dsh-inspect
Or: remove the dependency from the profile's package.json, then dsh plugin --profile  update

Tool Parameters

checkup: target (required, the inspection target) + angles (optional, inspection angles, comma-separated, 1 or more, unlimited in number,
2-6 recommended, with the engine's maxTotalAgents/maxItemsPerCall as a fallback) +
context (optional background). Outputs a problem list (severe/general/suggestion, with evidence and verification methods).

fix: task (required) + issues (optional, the problem JSON array from checkup, used as repair tasks) +
acceptance (optional acceptance criteria).
Outputs a delivery report (completion status + inspection record + delivery notes).

review: target (required) + dimensions (optional re-check angles) + context + fixed_issues
(optional, the JSON list of fixes that need verification). Outputs a graded re-check report + passed.

Configuration (Optional)

| Key                                                                                                | Default           | Description                                        |
| -------------------------------------------------------------------------------------------------- | ------------ | ----------------------------------------- |
| subagentProvider                                                                                 | Engine default spawn | Subagent provider                              |
| maxTotalAgents                                                                                   | Engine upper limit         | Upper limit on the total number of subagents for the entire run                               |
| plannerModel / workerModel / checkerModel / reviewerModel / mergerModel / redteamModel | Inherit parent configuration        | Role-level model layering (it is recommended to use different models for planning/implementation/checking/re-checking/summarization/red-teaming; heterogeneous adversarial setups are more effective) |

Design Notes

- plugin ≠ skill: not registered into ctx.skills; triggering relies on tool descriptions (finding faults/auditing/checkups/delivery/re-checking, etc.).
- Reuse official capabilities: orchestration goes through the official workflow engine; checking/implementation/review agents reuse built-in tools
(bash/fs/glob/…) to inspect real artifacts.
- Simplicity first: use plain "check/problem/fix" language, without piling up terminology; the value of a skill lies in activating the correct behavior.
But adversarialism, root-cause verification, and feedback validation are hard requirements; what is simplified is the expression, not the mechanism.
- Do not touch the TUI; cancellation propagation (exec.signal passed into the workflow); a single-point failure is only annotated at that point.

Profile Compatibility

At runtime, this plugin depends on the DSH official workflow engine (ctx.workflows, peer: @deepseek-ai/dsh-workflow)
与 schemastery（运行时依赖，已从 peer 移入 dependencies——官方 Profile 的
autoInstallPeers: false 不会安装 peer）。请把它安装进提供 workflows provider 的
Profile*（官方 base 组合自带）。

缺失 workflows provider 的 Profile（如标准 web 组合）照常加载、调用时报错而不是挂起：插件不在
静态 inject 里声明 workflows（cordis 对静态注入的服务做硬门禁，缺 provider 会让条目
永久停在 pending (waiting for service: workflows)，挂起整棵插件树直到宿主静默退出）；
改为在 apply 里运行时检查，缺失即抛出带指引的清晰错误——启动审计会把该条目报为
failed（附错误信息），Profile 其余插件照常激活。此时请改用提供 workflows 服务的组合，
或先安装 workflows provider 插件后再启用本插件。编译产物（lib/types/index.js）为官方
0810 生产入口，Node 原生可加载。