dsh-plugin-wepre: Publish Single-Screen Cards Directly from DSH Sessions to WePre Next

Preface¶

The core design philosophy of DeepSeek Harness (DSH) is “everything is a plugin”. Agents write code inside a session, but deploying it to a specific platform (such as WePre Next) usually requires manual operation. This plugin connects dsh sessions to WePre, enabling agents to publish cards directly.

What It Is¶

The plugin name is shujitech/dsh-plugin-wepre, maintained by shujiTech. It is a DeepSeek Harness plugin whose core feature is to publish single-screen content cards from dsh agent sessions to WePre Next. After installation, a dsh session can move directly from “writing a card” to “card published”.

Installation and Enablement¶

Install the plugin:

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

After installation, verify that the layer has loaded:

dsh --profile web --dump-config   # 应显示 "# == dsh-plugin-wepre" 层
dsh --profile web

No build step or prepare script is required; installing directly from a git host works as well.

Core Features¶

The plugin exposes five tools to the model under ctx.tools:

wepre_request_code: Send a one-time login code (SMS / email).
wepre_login: Redeem the code and persist the session cookie.
wepre_whoami: Display the current login status.
wepre_publish: Upload index.html / .zip cards through the server-side QA gate.
wepre_qa_report: Retrieve the complete QA report for the content (by viewport).

These tool descriptions inform the model of WePre content rules (single-screen layout, no network calls, no external resources, etc.) and the QA repair loop: when the gate returns QA_GATE_FAILED, the agent reads the structured viewport issues and fixes them, allowing republishing without manual intervention.

Authentication and Configuration¶

wepre_publish / wepre_qa_report resolve credentials in the following order:

token config field: short-lived publish token from the WePre publish page.
WEPRE_PUBLISH_TOKEN environment variable.
Stored login session: created by wepre_login and persisted to sessionFile (default ~/.dsh/wepre-session.json, permissions 0600).

For interactive use, only ask the agent to log in:

“log in to WePre with 13800138000”
It sends the code and asks for input, then stores the session. For CI / headless mode (dsh --profile headless "..."), set the token.

Configuration example (override cordis.patch.yml):

- 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'

Key	Default	Meaning
`endpoint`	`https://wepre.cn/next-test`	WePre Next site root URL
`token`	—	Short-lived publish token (Bearer)
`sessionFile`	`~/.dsh/wepre-session.json`	Persisted login session

Content Rules and Limitations¶

WePre Next cards are single-screen, offline, sandboxed pages. Before publishing, the tool runs a local pre-check for prohibited terms (such as fetch, localStorage, Worker, overflow:auto, etc.).

Content must satisfy the following rules:
* Root container height is 100dvh with overflow:hidden.
* No overflow:auto/scroll.
* No network calls, localStorage, or Worker.
* No external or root absolute URLs.
* execute mode cards must run the main action on the wepre-next:execute postMessage.

Use Cases and Notes¶

This plugin is suitable for scenarios that require direct deployment to WePre Next after AI generation. It runs with the permissions of the current dsh process, so inspect the source code and license before installing. It has no build step and uses pure ESM JavaScript.

Brief Conclusion¶

Through its tools and automatic QA loop, the plugin fills the gap between DSH agents writing code and publishing to the platform.

GitHub: https://github.com/shujiTech/dsh-plugin-wepre
Directory: https://www.skillhub.cn/plugins/shujiTech/dsh-plugin-wepre