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.

已驗證STDIO僅桌面瀏覽器自動化開發者工具

概覽

AI 產生的概覽

用真實瀏覽器檢查 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 指令需要大型語言模型金鑰。
安裝前請注意
選用的 AI 草擬清單功能會把頁面內容傳送給大型語言模型供應商,並需要模型金鑰。驗證會用真實瀏覽器開啟目標網址,請只測試你有權測試的應用。PASS 僅涵蓋本次提供的檢查,不代表完整涵蓋、安全性、無障礙或獨立作者身分;規格與應用可能出自同一個代理。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Dsh Verify,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

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-verify is 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:

bash
git clone https://github.com/263311487-ux/dsh-verify && cd dsh-verifynpm cinpx playwright install chromiumnode bin/verify.mjs initcd dsh-verify-starternode ../bin/verify.mjs --spec dsh-verify.spec.json# PASS (5/5), exit 0 -> dsh-verify-out/report.htmlnode ../bin/verify.mjs --spec dsh-verify.fail.json --out failed-report# Intentional FAIL (4/5), exit 1 -> failed-report/report.html

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.]

[dsh-verify in action]

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.

BuildWhat the agents saidWhat a real browser says
demo/buggy"No issues found"❌ FAIL — background never changes
demo/fixedone CSS rule added✅ PASS — theme flips

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

Entry pointWhat it's forOne-liner
MCP serverYour AI agent verifies its own deliverable, mid-sessionclaude mcp add dsh-verify -- npx -y -p dsh-verify dsh-verify-mcp
CLIYou or your CI verify a build/URLnpx dsh-verify init
GitHub ActionEvery push runs real-browser checksuses: 263311487-ux/dsh-verify/.github/actions/dsh-verify@main

From any AI agent (MCP)

bash
claude mcp add dsh-verify -- npx -y -p dsh-verify dsh-verify-mcp

Then tell your agent, in plain words:

Verify http://localhost:3000 — click #dark-toggle, then check body background-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)

yaml
- uses: 263311487-ux/dsh-verify/.github/actions/dsh-verify@main  with:    spec: demo/fixed.json       # spec file or glob    # url: https://staging.example.com   # optional override    # out: dsh-verify-out               # report output dir (default)

The repo dogfoods it: the dogfood workflow asserts the fixed build passes and the buggy build fails on every push.

On the command line

bash
npm install -g dsh-verify          # or: npx dsh-verifynpx playwright install chromium    # one-time browser downloadnpx dsh-verify --spec 'specs/*.json'# [PASS] specs/home.json (5/5)# [FAIL] specs/cart.json (4/5)#   ❌ expect_text #total: got "0" want "99"

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; --json is 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 | webkit per spec or --browser.
  • Zero framework lock-in — a JSON spec is all there is. No config language, no SDK, no vendor.

Example spec

json
{  "title": "my app",  "serve": "dist",  "browser": "chromium",  "steps": [    { "action": "goto", "path": "/index.html" },    { "action": "click", "selector": "#count-btn", "count": 3 },    { "action": "expect_text", "selector": "#count-btn", "text": "Clicked: 3" },    { "action": "capture_style", "selector": "#page", "prop": "backgroundColor", "var": "bg_before" },    { "action": "click", "selector": "#color-btn" },    { "action": "expect_class", "selector": "#page", "class": "dark", "present": true },    { "action": "expect_style_changed", "selector": "#page", "prop": "backgroundColor", "var": "bg_before" },    { "action": "screenshot", "name": "final-state" }  ]}

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:

[dsh-verify report]

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:

bash
git clone https://github.com/263311487-ux/dsh-verify && cd dsh-verifynpm install && npx playwright install chromiumexport LLM_API_KEY=sk-...          # any OpenAI-compatible modelnode arena/run.mjs --agent "gpt-5/single" --task all --repeat 1 --submitter yourname

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)

bash
git clone https://github.com/263311487-ux/dsh-verify && cd dsh-verifynpm install && npx playwright install chromiumnpm run demo:fixed    # → PASS (11/11)npm run demo:buggy    # → FAIL (exit 1) — the missing .dark rule, caughtnpm test              # engine self-tests

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:

markdown
[![agent deliverable: browser-verified](https://img.shields.io/badge/agent_deliverable-browser_verified-brightgreen?logo=playwright&logoColor=white)](https://github.com/263311487-ux/dsh-verify)

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
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

2
  1. v0.9.6最新Oct 9, 2026
  2. v0.9.1Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分