dsh-engineering-services

IDE engineering services for DeepSeek Harness (dsh) — a host plugin porting the
pi-engineering-services suite: LSP / DAP / Task three pillars + an IDE-tooling usage skill.

Verified scope (kept from the pi edition)

• LSP: pyright (Python) + typescript-language-server (TS/JS). Others are configurable but experimental.
• DAP: debugpy (Python) + js-debug (JS/TS, vendored). Others are configured but experimental.
• Task: npm scripts / Makefile / justfile.

Language servers and debug adapters beyond this are present in the config but not tested.

Install

# from a local checkout (dev iteration)
cd dsh-engineering-services-dsh
npm i -D typescript      # dev typecheck/build tooling (typescript)
npm run build            # scripts/build.mjs → tsc emits lib/ + copies vendored dap assets
dsh plugin --profile web add link:$PWD
# restart dsh web + hard refresh, then in a new session:
#   lsp_diagnostics on a .ts/.js/.py file
#   task list / task run name=...
#   debug launch program=... (needs debugpy / js-debug runtimes, see below)

Build tooling note: this package uses a plain Node ESM build (scripts/build.mjs →
tsc + copy vendored dap/js-debug/dap/debugpy into lib/). There is no tsdown/bundler.
For tsserver to work, the workspace must resolve a typescript@5 with lib/tsserver.js;
see the runbook skill (section tsserver 的标准修法).

The plugin's node half registers the tools through the tools registry and the IDE-tooling
guidance section through the system-prompt registry (both probed at runtime, mirroring dsh-genui).

Configuration (pi-lsp.json)

Language servers are configured with the same schema as the pi edition:

• Project-local: <workspace>/.dsh/pi-lsp.json
• User/global: ~/.dsh/pi-lsp.json

{
  "timeout": 20000,
  "servers": {
    "pyright": { "command": ["pyright-langserver", "--stdio"], "extensions": [".py", ".pyi"] },
    "typescript-language-server": { "command": ["typescript-language-server", "--stdio"], "extensions": [".ts", ".tsx", ".js", ".jsx"] }
  }
}

Without a config the plugin ships built-in defaults that now include pyright and
typescript-language-server out of the box; the broader list (biome, ruff, etc.) is
experimental — uninstalled default servers are auto-skipped by the tools.

Runtime notes / differences from the pi edition

• cwd: tools default to the calling session's workspace (exec.agent.session.header.cwd),
  not a per-process cwd. Pass an explicit cwd/root to override.
• debugpy: not vendored (pip-installable). Set DSH_DEBUGPY_PYTHON to any interpreter
  that has debugpy installed (test with python -c "import debugpy"). The default
  ${env:DSH_DEBUGPY_PYTHON|python3.13} is a guess — on many machines it's python3.13
  that lacks debugpy while the system python has it. There is no hard 3.13 requirement;
  pick whichever interpreter passes the import check.
• js-debug: vendored under src/dap/js-debug/ (its own {"type":"commonjs"} package.json
  isolates the CJS dapDebugServer.js from the ESM package root).
• No /lsp slash command: the pi edition's /lsp command is replaced by the lsp_toggle
  tool. There is no per-conversation active-tool-set toggle in DSH's host plugin surface.
• No pi ctx.ui.setStatus: the LSP runner's status banner is a no-op in DSH;
  results carry the diagnostics/fix/navigation text directly.

Verify (typecheck)

pnpm run check         # tsc --noEmit -p tsconfig.json

For offline typechecking, node_modules/@deepseek-ai/* are junctions into an installed
@deepseek-ai/dsh profile's packages (dev-only; not committed). A real installed profile
provides the same packages at runtime.

Docs

• DETAILED.md — migration map: how each pi file maps to this port.
• THIRD-PARTY-NOTICES — upstream sources & licenses.
• skills/ide-runbook/SKILL.md — operations runbook:
  install into a dsh profile, restart, three-pillar smoke, and the tsserver/debugpy/Windows
  pitfalls (incl. self-bootstrap verification).

MIT