dsh-plugin-wepre

English | 中文

A DeepSeek Harness (dsh) plugin that lets your agent publish single-screen content cards to WePre Next — a platform that pushes offline, single-viewport cards to users while they wait on AI generations.

With this plugin installed, a dsh session goes from "write me a card" to "it's live" in one conversation:

you:   Build a pomodoro-timer card and publish it to WePre
agent: <writes index.html, calls wepre_publish>
agent: QA gate rejected it — OVERFLOW_Y at 390x600. Fixing… <edits, republishes>
agent: Published. contentId=cnt_xxx, version v1 (QA: passed)

Install

dsh plugin --profile web add dsh-plugin-wepre

Verify the layer composed, then boot:

dsh --profile web --dump-config   # shows a "# == dsh-plugin-wepre" layer
dsh --profile web

No build step and no prepare script — installing from a git host works too:

dsh plugin --profile web add github:shujiTech/dsh-plugin-wepre

What the agent gets

Five model-facing tools on ctx.tools:

The tools' descriptions teach the model WePre's content rules (single-screen layout, no network calls, no external resources, the wepre-next:execute postMessage contract) and the QA fix loop: when the gate answers QA_GATE_FAILED, the agent reads the structured per-viewport issues, fixes the card, and republishes with the same contentId — no human in the loop.

Authentication

wepre_publish / wepre_qa_report resolve credentials in this order:

1. token config field — a short-lived publish token from the WePre publish page
2. WEPRE_PUBLISH_TOKEN environment variable
3. The stored login session — created by wepre_login, persisted to sessionFile (default ~/.dsh/wepre-session.json, mode 0600)

For interactive use, just ask the agent to log in: "log in to WePre with 13800138000" — it will send the code, ask you for it, and store the session. For CI / headless (dsh --profile headless "…"), set a token.

Configuration

Override the plugin row in your profile's cordis.patch.yml (a patch replaces the row's whole config — restate keys you keep):

- id: wepre-publish
  name: dsh-plugin-wepre
  config:
    endpoint: 'https://wepre.cn/next-test'
    token: !!js process.env.WEPRE_PUBLISH_TOKEN
    sessionFile: '/home/me/.dsh/wepre-session.json'

What a publish call looks like

wepre_publish maps to POST /next-test/api/next-contents (multipart). Parameters: title, path (absolute, .html or .zip), description, contentId (for in-place version updates), changeNote, versionLabel, downloadEnabled (default false), and manifest fields viewports (all/desktop/mobile), interaction (execute/passive), capabilities.

On success it returns contentId, versionId, versionNumber and the QA status. On QA_GATE_FAILED (HTTP 422) it returns the structured issues and reportId as a canonical value — not an exception — so the agent can iterate. Before uploading, the tool runs a local pre-flight scan for WePre's banned tokens (fetch, localStorage, Worker, overflow:auto, …) and external links, and reports them as non-blocking warnings.

Content rules in one paragraph

WePre Next cards are single-screen, offline, sandboxed pages: one index.html (or a zip with it at the root), root container at 100dvh with overflow:hidden, no overflow:auto/scroll, no network calls / localStorage / Worker (the words are banned even in comments), no external or root-absolute URLs, and execute-mode cards must run their main action on the wepre-next:execute postMessage. The full contract: WePre Next 内容发布规范 (see the publish guide on the site).

Development

Plain ESM JavaScript, no build step. Behavioral tests drive the tools against a mock WePre server:

npm install
npm test

License

MIT