Contributing

Bug reports, focused fixes, compatibility updates, and small user-facing improvements are welcome.

Before changing code

• Use the issue forms for a reproducible bug or a concrete feature need.
• Keep one pull request focused on one problem. Do not bundle unrelated refactors, generated artifacts, or release preparation.
• Never include OAuth credentials, account identifiers, authorization links, proxy addresses, private machine paths, or raw account responses.
• Reuse DSH's native model, tool, attachment, settings, and plugin-lifecycle contracts instead of introducing a parallel subsystem.

Local verification

Install the locked dependencies and run the complete repository check:

pnpm install --frozen-lockfile
pnpm run check

lib/ is generated by the build and must not be edited by hand. If a change affects the DSH UI or plugin lifecycle, also verify it in an actual supported DSH installation; source tests alone are not installed-product acceptance.

Pull requests

Describe the user-visible problem, the smallest implemented change, the checks you ran, and any remaining compatibility or privacy risk. Keep README and README.zh-CN.md behaviorally aligned when user instructions change. Public documentation should explain the product and its supported use, not internal debugging history or private design discussion.

Maintainers batch ordinary fixes into planned stable releases. A merged pull request does not imply an immediate npm release.