
Dsh Verify
io.github.263311487-uxPublished by GitHub account 263311487-uxv0.9.6Updated Oct 30, 2026
Agent-built web app quality gate. Real browser is the judge. PASS/FAIL with receipts.
Overview
Runs real-browser checks on agent-built web apps and returns a PASS/FAIL verdict with screenshots and reports.
- What you can do
- Run a JSON spec of browser steps against a local directory or URL and get a pass/fail verdict
- Run inline checks against a URL without writing spec files
- Capture screenshots, pixel diffs and computed-style or class assertions in HTML reports
- Have an LLM draft a checklist from a page, then execute it deterministically in Chromium, Firefox or WebKit
- Report server health
- When to use it
- Use it when an AI agent has built or changed a web app and you want an independent browser to confirm the behavior actually works, mid-session or in CI, instead of trusting the agent's own review.
- Requirements
- Local process via npm package dsh-verify, run as dsh-verify-mcp. Needs Node.js 20+ and a one-time Chromium (Playwright) download; internet for package and browser installation. No API key for basic verification; the optional generate_and_verify tool and the gen command need an LLM key.
Installation
In SourceWeft
- Open Dsh Verify in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
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
Source: README.md at commit e7ce637
Tools
0Version history
2- v0.9.6LatestOct 9, 2026
- v0.9.1Sep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts