omdsh-dev/dsh-inspect
51Last commit Aug 12, 2026
dsh-inspect DSH plugin
dsh-inspect provides three tools — checkup, fix, and review — that work together through a closed-loop feedback mechanism. It uses adversarial agents to validate issues, trace root causes along data flows, and verify fixes before delivery. The plugin is designed for developers and QA teams who want automated, verifiable code quality workflows.
How to install the dsh-inspect DSH plugin
dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-inspect.gitThis source command needs manual review. Copying does not run it.
dsh-inspect DSH plugin data source
dsh-inspect DSH plugin snapshot date: Aug 16, 2026
discovered
What the dsh-inspect DSH plugin can do
- Runs adversarial checkup to find issues with red-team validation (attempts to disprove each claim before reporting)
- Delivers fixes with root-cause analysis along data flow, implementation, and re-run verification
- Performs quality review with adversarial agents and optional re-run validation of fixed issues
- Supports configurable angles for checkup and dimensions for review
- Allows role-level model assignment (planner, worker, checker, reviewer, merger, redteam)
- Works standalone or in a complete checkup→fix→review pipeline
- Integrates with DSH official workflow engine and tool registration service
Where the dsh-inspect DSH plugin fits
- Run checkup on a codebase to get a prioritized issue list with evidence
- Feed checkup results into fix to automatically repair issues and verify they are gone
- Use review to validate fix quality and confirm issues are resolved before merging
- Iterate on fix and review until all issues are closed or human approves
- Embed checkup in CI pipeline to gate quality before pull requests
- Perform targeted inspections on specific angles (e.g., security, performance)
Who the dsh-inspect DSH plugin is for
- Developers seeking automated code review and repair
- Tech leads and QA engineers wanting verifiable quality gates
- Teams using DSH with official workflow engine and tool services
dsh-inspect DSH plugin limitations
- Requires a DSH profile that provides the official workflow engine (ctx.workflows) and tool registration service
- Only supports erasable TypeScript syntax (no enums, namespaces, etc.)
- Needs Node.js ≥22.18 with native type stripping or tsx hook for runtime loading
- Does not register as a skill via ctx.skills; triggered only by tool descriptions
- Sub-agent failures are reported honestly, not silenced
- No TUI support; agent cancellation via exec.signal only
dsh-inspect DSH plugin: from the repository README
Quoted from the omdsh-dev/dsh-inspect README, the upstream source of the dsh-inspect DSH plugin. Copyright remains with the original authors.
**发现问题 → 修复交付 → 质量复查** 的简单闭环插件。 三个朴素工具，共享同一套"对抗式检查"机制： | 工具 | 干什么 | 核心机制 | | --------- | ---- | ------------------------------------------------------------------------------------ | | `checkup` | 找问题 | 对抗式检查员（各看一个角度）→ **红队攻击验证**（尝试推翻问题声明，推不翻的才保留）→ 汇总分级（严重/一般/建议） | | `fix` | 修复交付 | 拆解 → 并行实现（每个实现员按**找根因**（沿数据流找偏离源头）→ 实施 → **重跑复现验证**（反馈闭合））→ **对抗式检查** → 修复轮收敛 → 交付报告 | | `review` | 质量复查 | 对抗式审查员（各看一个角度）→ 汇总分级；可传 `fixed_issues` 逐条**重跑复现确认问题真的消失** | ## 理论内核：控制论的反馈机制 - **发现是怀疑，验证是定罪**：检查员/审查员一律对抗式（默认怀疑、找反例、只认可当场验证的证据）； checkup 的红队环节就是负反馈——问题声明必须经受住攻击，推不翻才成立。 - **根据数据流定向判断状态**：判断问题前先按数据流理清系统（输入 → 处理 → 存储 → 输出， 谁写谁读）；**问题 = 数据流某处状态偏离预期**，而不是静态读代码猜。 - **互相校验**：每个问题必须给出可互相校验的验证方式（重跑复现 / 日志对照 / 输入输出对照 / 双路径对照），并写明预期状态与实际观测——**无法通过系统反馈验证的，不许报**。 - **修复要证伪**：先沿数据流找到状态偏离的**源头**（不许修表面）；修复后重跑原复现， 观测输出与预期比较（反馈闭合）——问题没消失 = 根因没找对，重新分析。 - **根据数据判断直接定方案**：根因找到后，方案由数据自然决定——实现员按"找根因 → 实施 → 验证" 三步直接做（根据数据判断选择最合理的方案，不空谈不犹豫，实施保持改动最小）。 - **闭环**：checkup 的问题清单 → fix 修复任务 → review 把关（可逐条验证修复是否真消失）； 复查不通过或人的反馈重新进入 fix。三个工具可单独用，也可串起来。 ## 结构 ``` dsh-inspect/ ├──
Read the full READMERepository license: MIT
dsh-inspect DSH plugin questions
How do I install dsh-inspect?
Run `dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-inspect.git`. Replace `<profile>` with `tui`, `headless`, `web`, or your custom profile. If pnpm rewrites the URL to git+ssh, use the `git+https://` form shown above. You may need to add `allowBuilds` to your profile's `pnpm-workspace.yaml` if prompted.
Can I use checkup, fix, and review separately?
Yes, each tool can be used standalone. For example, you can run checkup alone to inspect code, fix alone to deliver a repair task, or review alone to validate a fixed issue list. However, they are designed to work together: checkup produces issues, fix consumes them, and review verifies the fix. The closed-loop workflow is recommended for best results.
How do I update or uninstall dsh-inspect?
To update, run `dsh plugin --profile <profile> update`. To uninstall, run `dsh plugin --profile <profile> remove @dsh-external/dsh-inspect`. Alternatively, you can manually remove the dependency from your profile's package.json and then run `dsh plugin --profile <profile> update`.
What profile requirements does dsh-inspect have?
The profile must provide the official workflow engine (`ctx.workflows`) and tool registration service. The DSH official base profile includes these by default. Some web profiles may not have the workflows provider, causing the plugin to stay in a pending state. In that case, register a workflows provider or switch to a compatible profile.
Can I use different models for different roles (e.g., planner vs checker)?
Yes. You can configure role-level models via the plugin options: `plannerModel`, `workerModel`, `checkerModel`, `reviewerModel`, `mergerModel`, and `redteamModel`. Each defaults to the parent configuration. Using different models for adversarial roles can improve detection by providing diverse perspectives.