
Dsh Verify
io.github.263311487-ux由 GitHub 账号 263311487-ux 发布v0.9.6更新于 Oct 30, 2026
Agent-built web app quality gate. Real browser is the judge. PASS/FAIL with receipts.
概览
用真实浏览器检查 AI 构建的网页应用,并给出带截图和报告的 PASS/FAIL 结论。
- 可以做什么
- 按 JSON 规格对本地目录或网址执行浏览器步骤并给出通过/失败结论
- 无需写规格文件,直接对网址运行内联检查
- 截图、像素比对,以及计算样式和类名断言,输出 HTML 报告
- 由大模型起草检查清单,再由 Chromium、Firefox 或 WebKit 确定性执行
- 查询服务健康状态
- 适用场景
- 当 AI 智能体刚构建或修改了一个网页应用,你想让独立浏览器确认行为是否真的可用,而不是相信智能体自己的复查时使用,可在会话中或 CI 里运行。
- 运行要求
- 以 npm 包 dsh-verify 在本地运行,命令为 dsh-verify-mcp。需要 Node.js 20+ 并一次性下载 Chromium(Playwright);安装包和浏览器需要联网。基础验证无需 API 密钥;可选的 generate_and_verify 工具和 gen 命令需要大模型密钥。
安装
在 SourceWeft 中
- 打开 控制台中的 Dsh Verify,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
dsh-verify
中文 | English
Witness — Check the behavior your browser spec describes. Browser assertions can expose some implementation gaps; they do not prove an app is complete or independently reviewed. (Witness is the product name;
dsh-verifyis the package name — same thing.)
[ci] [npm] [MCP server] [awesome-dsh-plugin] [GitHub stars] [self-acceptance]
If Witness catches something for you, ⭐ star the repo — it's how this project stays alive.
You asked an AI to build a web app. It said "done." Does it actually work?
dsh-verify opens a real browser and checks — so you never have to take the agent's word for it.
First success — no API key
Requires Node.js 20+ and a one-time Chromium download. Install the current npm release with npm install --save-dev [email protected], then run npx dsh-verify init. Alternatively, run from a clone checkout:
Open either HTML report with its adjacent PNG file. The failing spec deliberately expects wrong text; inspect the assertion and screenshot. Existing missing-CSS failure report is another inspectable example.
init [directory] only writes a local fixture and two JSON specs. It never calls an LLM, launches a browser, or downloads anything. The destination must be new (its parent must exist); existing directories, files, and symlinks are refused without changes. No force/overwrite option. GitHub package and browser installation require internet; these starter checks use localhost only. gen and MCP generate_and_verify are optional, separate features that require an LLM key.
To check your own app, edit the JSON steps; keep serve for static files or use base for an existing URL. serve paths resolve from the command's current directory, not the spec file. A PASS applies only to the supplied checks in that run; it does not establish complete coverage, security, accessibility, or independent authorship. The app and spec may come from the same agent; review the spec separately when independence matters. Reports retain assertion details and explicitly requested screenshots, not a complete audit trail.
[dsh-verify — Agents say done. The browser proves it.]
The quality gate for agent-built web apps. Works with any agent — DeepSeek Harness (dsh), Claude Code, Cursor, Copilot, Codex — and with any CI. You write what a human would check in a browser; a real browser executes it and returns a PASS/FAIL verdict with receipts (screenshots + diff images).
No LLM judges the outcome. The browser is the judge.
[Same task, same AI, two builds — only a real browser tells the difference]
Same task. Same AI. Two builds. One missing CSS rule — the agent's self-review passed, a real browser caught it.
Why this exists
We ran a 4-agent web team (spec writer → frontend dev → QA → reviewer). Their own review said:
✅ "All requirements met. No issues found."
In a real browser, the dark-mode toggle did nothing — the .dark class was toggled, but the CSS rule was never written. Every agent self-test passed because there was nothing in the page for the agents to run. No one opened a real browser.
That's the gap: agents verify against what they believe they built, not against what a user actually experiences. These checks did not exercise the rendered CSS behavior; a browser assertion can cover it.
Same page. Same JS. One missing CSS rule. Two different verdicts.
How it fits with other tools
- Playwright scripts provide a general browser API. This package exposes common checks as a reviewable JSON spec and report; custom scripts remain useful for flows outside this schema.
- LLM evaluation tools can assess open-ended outputs and may also integrate browsers. This package evaluates explicit browser assertions without an LLM deciding their result.
- Agent browser tools let agents operate a page. Stored specs make repeat runs inspectable; independent review still depends on who writes and reviews the spec.
- Visual regression tools detect pixel changes. This package combines screenshot comparisons with behavior assertions; coverage depends on the chosen checks.
Use it three ways
From any AI agent (MCP)
Then tell your agent, in plain words:
Verify http://localhost:3000 — click
#dark-toggle, then checkbodybackground-color changed. Screenshot it.
Tools exposed: verify_spec (run a spec JSON), verify_url (inline checks, no files), generate_and_verify (the AI drafts the checklist, real Chromium executes it), health.
In CI (GitHub Action)
The repo dogfoods it: the dogfood workflow asserts the fixed build passes and the buggy build fails on every push.
On the command line
What's in the box
- Deterministic assertions — Chromium, Firefox, or WebKit executes supplied checks: click, fill, text, classes, computed styles, URLs, console/network errors, and pixels. Coverage depends on the spec and browser.
- Inspectable reports — HTML results accompany screenshot and difference image files when those actions run;
--jsonis available for CI. Exit 1 alone does not distinguish assertion failures from runtime errors; inspect the structured verdict and failed actions as the release checker does. - Visual regression — screenshot baselines, pixel-diff with thresholds (
expect_screenshot), refresh with--update-baselines. - AI-drafted checklists —
dsh-verify gen --url ... --prompt "..."learns the page in a real browser, has an LLM draft the checklist, then executes it deterministically. The AI drafts; it never judges. - Multi-browser —
chromium|firefox|webkitper spec or--browser. - Zero framework lock-in — a JSON spec is all there is. No config language, no SDK, no vendor.
Example spec
Top-level fields: title, serve (static dir) or base (target URL), browser, steps. Run many at once with a glob; exit is 0 only if all pass.
The report
An HTML report with adjacent image files — every step with a pass/fail badge, selector, and detail, plus screenshots:
Agent Arena — bring your agent
Real-browser benchmark for agent-built web apps: same 3 tasks, same human checks, open entry. Run your model on the board in ~10 minutes:
Submit the result files for maintainer review before they appear on the leaderboard: agent-arena. Full rules in docs/ARENA.md.
Prove it (run it yourself)
The repo's own CI runs exactly that — engine self-tests, then asserts fixed passes and buggy fails — so the tool verifies itself on every push.
Agent Arena — can agents ship working web apps?
Historical snapshot, not a current model ranking. The committed records span 2026-08-17–18 UTC: 48 records, 44 PASS, 2 FAIL, 2 ERROR. Among the 46 records with a browser verdict, 44 passed and 2 failed; the two ERROR records are runner failures. The records cover two model labels × two strategies × three static tasks (four records per cell). Self-check allows up to two repair rounds, so compute budgets differ. Model labels are recorded identifiers, not independently verified identities.
Records do not pin historical verifier/dependency versions. Generated apps, model replies, and local report files are not committed, limiting exact reproduction. No new LLM runs were made for the 0.9.5 or 0.9.6 release. See methodology and limitations. [Agent Arena]
See docs/ARENA.md — methodology, the tasks, and how to run your own agent.
Badge your agent-built app
The following static image is illustrative only. It is not bound to a particular app, commit, spec, or successful run:
For a result tied to a specific build, publish the commit, spec, action run, verdict, and report together. See docs/verified-badge.md.
Roadmap
- MCP server · AI-drafted checklists · visual regression · multi-browser · GitHub Action · dsh plugin
- Agent arena — a public benchmark: give the same task to different agent setups, grade them in real browsers, publish the leaderboard
- Spec recorder (browser extension: click through once → spec generated)
- Cloud runs + shareable report links + PR comments
Related
- dsh-doublecheck — delivery quality gate for DeepSeek Harness (/gate): requirements grill + evidence discipline. Complementary pair: /gate keeps the evidence honest, dsh-verify keeps the browser honest.
- falsify — the scientific thinking protocol for AI agents (hypothesis → falsify → evidence → calibrated conclusion). The pair: falsify catches the wrong conclusion, dsh-verify catches the broken output.
- Featured in the DeepSeek Harness community — Show Your Plugins: dsh-verify (48-run Agent Arena results in-thread)
License
MIT
来源:README.md,提交 e7ce637
工具
0版本历史
2- v0.9.6最新Oct 9, 2026
- v0.9.1Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分