master now ships the reminder stack as the optional `@deepseek-ai/dsh-experimental-schedule-bundle`, which inserts the rows the Web composition leaves out. This branch keeps the preset-level ownership beside it. Resolutions: - The bundle inserts `schedule` and `ui-schedule` only. It no longer inserts `time-context`: the clock belongs to the `standard`, `cordis`, and `ptc` presets, and a Host row for the same package would mount it in two scopes and append two readings per step. - `packages/bundle/web-app/package.json` declares `@deepseek-ai/dsh-time-context` again: the presets reference it by bare name, so `verify-cordis-config` requires the dependency. - The bundle's patch spec, locale, package, README pair, the optional-bundle composition spec, the plugin-manager component list, and the `schedule-after` roster assertions describe the two-row bundle and the preset-owned clock and tools. - Documentation and Agent Notes follow the same split; the note master archived stays frozen with its manifest hashes.
DeepSeek Harness Python SDK
English | 中文
Python packages for driving DeepSeek Harness as a subprocess. The client SDK communicates with the bundled runtime over newline-delimited JSON-RPC on stdio.
Packages
| Directory | Dist / module | Role |
|---|---|---|
| sdk | deepseek-harness-sdk / deepseek_harness |
High-level turns API and lower-level JSON-RPC client |
| sdk-runtime | deepseek-harness-runtime-bin / deepseek_harness_runtime |
Bundled dsh CLI executable and native sidecars |
Behavior
The SDK starts the matching bundled dsh --profile sdk runtime unless the caller selects another dsh executable or profile. The runnable minimal example selects the shipped standalone sdk-minimal profile; the same runtime also packages dsh web and its frontend assets for separate CLI use. Every launch requires an explicitly selected Harness home; Python never silently reads ~/.dsh. The SDK reference and runtime carrier reference own runtime selection, profiles, patches, and external plugin management.
Contributor workflows
The Python contributor workflows cover building runtime artifacts, validating the packages, source-mode development, and distribution.