dsh-inspect¶
⭐ 6 · ✅ active · workflow · ⬆️ +1 recently
| Type | workflow | Category | Workflows |
| Stars | ⭐ 6 | Status | ✅ active |
| Author | omdsh-dev | Updated | 2026-08-17 |
One-liner¶
Adversarial checkup → fix → review loop built on the official workflow engine.
About¶
- 发现是怀疑，验证是定罪：检查员/审查员一律对抗式（默认怀疑、找反例、只认可当场验证的证据）； checkup 的红队环节就是负反馈——问题声明必须经受住攻击，推不翻才成立。 - 根据数据流定向判断状态：判断问题前先按数据流理清系统（输入 → 处理 → 存储 → 输出， 谁写谁读）；问题 = 数据流某处状态偏离预期，而不是静态读代码猜。 - 互相校验：每个问题必须给出可互相校验的验证方式（重跑复现 / 日志对照 / 输入输出对照 / 双路径对照），并写明预期状态与实际观测——无法通过系统反馈验证的，不许报。 - 修复要证伪：先沿数据流找到状态偏离的源头（不许修表面）；修复后重跑原复现， 观测输出与预期比较（反馈闭合）——问题没消失 = 根因没找对，重新分析。 - 根据数据判断直接定方案：根因找到后，方案由数据自然决定——实现员按"找根因 → 实施 → 验证" 三步直接做（根据数据判断选择最合理的方案，不空谈不犹豫，实施保持改动最小）。 - 闭环：checkup 的问题清单 → fix 修复任务 → review 把关（可逐条验证修复是否真消失）； 复查不通过或人的反馈重新进入 fix。三个工具可单独用，也可串起来。
✨ Key Features¶
- 发现是怀疑，验证是定罪：检查员/审查员一律对抗式（默认怀疑、找反例、只认可当场验证的证据）；
- 根据数据流定向判断状态：判断问题前先按数据流理清系统（输入 → 处理 → 存储 → 输出，
- 互相校验：每个问题必须给出可互相校验的验证方式（重跑复现 / 日志对照 / 输入输出对照 /
- 修复要证伪：先沿数据流找到状态偏离的源头（不许修表面）；修复后重跑原复现，
- 根据数据判断直接定方案：根因找到后，方案由数据自然决定——实现员按"找根因 → 实施 → 验证"
- 闭环：checkup 的问题清单 → fix 修复任务 → review 把关（可逐条验证修复是否真消失）；
📦 Install¶
pnpm install # 仅 typescript/@types/node（typecheck 用）
pnpm run typecheck # tsc -b，类型从 sibling deepseek-harness checkout 解析
cd plugins/dsh-inspect && node --test # 回归测试
🚀 Quick Start¶
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 语义）
📚 Learn more¶
安装与使用方式
包声明了 dsh.bundle.patch（cordis.patch.yml），通过 dsh plugin 装进任意 profile （把 <profile> 换成 tui / headless / web 或自建 profile）： dsh plugin --profile insteadof 配置所致），用上面的 > git+https:// 形式；dsh plugin 会提示需要 `allowBu