Workbench development: six-step quickstart

Version: 2026-10-27 · For full rules, see the Workbench Development Standard; for listing, see the Workbench Market Acceptance Standard.

Local development, installation, and use require no GitHub account or repository URL. By default call register({ title }, BusinessPanel), omit repository, and do not supply id. The host derives local:<npm package name> from the actual client package (local:@scope/name for scoped packages). Version or directory changes preserve identity; package renames create a new identity. Market submission separately uses a real repository and does not automatically migrate local sessions. For registration failures, check the package, stage, and reason in Workbench management; a successful reload clears the diagnostic. Use the native plugin installation UI or CLI supported by the current version, not an unavailable local installation API.

Communication with users: Use business language for requirements discovery, layout suggestions, confirmation choices, and installation or completion status, such as “Show the business content on a full page and open AI conversation when needed” or “Talk while viewing supporting information.” Do not ask ordinary users to confirm code fields such as customFrame, register(), repository, dshHomePath, or reconcileLocalProviders, internal identities, or placeholder repository URLs; do not present lengthy implementation details as choices. The Agent handles technical fields during development under this standard. Missing publication identity must not block confirmed local development, and a real repository must never be fabricated. Ask only for practical information affecting the business or installation, such as “Which folder should hold the data?” Explain technical details briefly when the user asks. Lead completion reports with what works, actual operations tested, and items still pending verification; put changed files and technical checks in a short appendix, then end with the usage handoff required below.

After every workbench development handoff, the final response must end with a prominent three-point “What to do next” block, after all change descriptions, self-test results, file links, and technical appendices. Do not leave the reminder only at the beginning, and do not append any content after these three points:

Development result: Use the actual workbench name and state the development and installation status. Say “Developed and installed locally” only when both actually succeeded; if development is incomplete or installation failed, explain the blocker honestly. Do not claim it loaded or all acceptance checks passed.
How to restart: When installation succeeded and a restart is needed, ask the user to wait until the current task finishes, then click “Restart now” in the top banner or choose Harness → Restart Harness; normally only Harness needs restarting, without quitting DSH Desktop. Suggest fully quitting and reopening DSH Desktop only if Harness restart does not load the workbench and troubleshooting confirms this is needed. Do not close or restart the app the user is working in yourself. If no restart is needed or installation is incomplete, say so; do not present restarting as a fix for failed installation.
Where to open it: After restarting, expand the sidebar and use the current name / switch area beside “Workbenches” at the upper left to select the newly created workbench (give its actual name). If missing, go to Workbench Market → Installed, find the entry marked “Local,” and check its running state; switch after it loads or is enabled. The user can try it directly, or optionally return to the original conversation and say “Restart complete” for continued verification; returning to the conversation is not required to use it. If installation is incomplete, state that this entry remains unconfirmed until installation and loading succeed.

Confirm requirements: Use progressive conversation, asking only one necessary question at a time without repeating known information. If the name is unknown, first ask “What would you like to call this workbench?”; a provisional name is fine. Fill gaps about users, main functions, or scenario from context. Suggest and confirm the workflow rather than requiring a complete requirements form. Start when the business goal and minimal scope are clear; generic instructions, directory names, or existing code do not establish intent by themselves.
Inspect the project: Check pwd, directory contents, git status --short if this is a Git repository, existing scripts, package manager, and Desktop version. Preserve uncommitted changes.
Define the smallest business flow and layout: Identify the entry point, primary action, completion state, and failure recovery. Suggest a business full page or conversation with supporting information to the user; the Agent selects the corresponding implementation under Section 4, and define the entry point when there is no session. Do not default the product design to a permanent conversation pane: recommend a business-first full page for content review, renovation management, reports, or dashboards, showing conversation only when the user requests AI help. Use a standard split for conversation-led tasks or compact companion tools. If requirements are unclear, suggest layouts and confirm the primary task.
Implement: Build the plugin package and business panel under Section 3 of the development standard. Follow Sections 4–7 for the session, workspace, and UI capabilities actually used. Make the business area responsive to its own container width, not only the window width.
Verify the package: Run pnpm pack. Confirm the .tgz contains the declared server and client entries and cordis.patch.yml, and excludes credentials and user data.
Install and test locally: Under Section 3.6, check which local installation method the current Desktop supports, install the package, and complete the required restart. Use either optional path below to try it or continue Agent verification, then record actual results under Section 8. If installation is unavailable, deliver the verified package and list every untested item.

After building and verifying the archive, the model calls install_local_workbench({ path: "<absolute local .tgz path>", replace: false }) directly. This uses Plugin Manager installBundle; users do not enter paths or operate an installation page. Pass replace: true only for an authorized update of the same workbench. Inspect application: verify the UI for applied; only restart-required calls for restarting Harness. Failed, cancelled and overridden do not mean applied.

When developing inside the target DSH Desktop: Do not close or restart DSH Desktop or Harness yourself or use process probes such as ps or pgrep to manage the restart; ask the user to restart manually. After the user restarts Harness, offer two optional paths: (1) Try it directly: expand the sidebar, click the current workbench name / switch area to the right of “Workbenches” at the upper left, and select the new workbench. If it is missing, check its entry and running state in Workbench Market → Installed, then switch after it loads or is enabled. New local workbenches are added to the switch menu automatically when loaded; there is no separate “Add” button. (2) Continue Agent verification: return to the original development conversation and tell the Agent “Restart complete”; the Agent then follows Section 8 to check loading, the installed list, the switch entry, and the real business UI. Users may try it independently without returning to the conversation. Checks the Agent has not actually performed remain pending verification; installation success does not mean all acceptance checks passed. An Agent outside the target app may follow the normal restart process.

UI acceptance: Check first entry without a session, an owned session, expanded and collapsed sidebar, and a narrow window. For a standard split, check the host generic guidance beside the business panel; for customFrame, provide your own first-use action. Use realistic Chinese and English text; prevent single-character vertical wrapping, clipped controls, and page-wide horizontal overflow. Preserve host shared entrances.

Empty-directory example: If the directory is empty and the user only pasted generic development instructions or said “make a workbench,” reuse any context already provided. If the name is unknown, ask only “What would you like to call this workbench?” and allow a provisional name. On the next turn, ask the one business question that most affects implementation, such as “What should it mainly help you do?” If the purpose is already clear, skip that question and suggest a minimal flow for confirmation. Read-only directory and Desktop capability checks are allowed. Until the business goal and scope are sufficiently clear, do not create package files, business code, or pages, or build, install, or submit. A name alone is not a business brief.