@dsh-external/dsh-code-pipeline
Code Pipeline
DSH bundle plugin: Dynamically injects stage subagent tools (subagent_plan / subagent_impl / subagent_review) into the code-pipeline preset (PTC pipeline). Provider/model/thinking level/maximum concurrency for each stage can be configured in real time on the settings page (Settings → Code Pipeline)
The plugin will be installed here. Keep web if you are unsure.
npx -y @deepseek-ai/dsh plugin --profile web add github:ErrorLst/dsh-code-pipeline#a025db6e0c8bfa4f644f9bb4a6fa2114f2d64a24Description
DSH bundle plugin: Dynamically injects stage subagent tools (subagent_plan / subagent_impl / subagent_review) into the code-pipeline preset (PTC pipeline). Provider/model/thinking level/maximum concurrency for each stage can be configured in real time on the settings page (Settings → Code Pipeline) and persisted to settings.yaml (maximum concurrency is the limit on **simultaneously running** agents, admitted by (parent session × stage); since 0.4.0, the “total created” gate has been removed—new workflows always dispatch new subagents, while only subsequent rounds of the same workflow reuse agents via pipeline_followup; adjustable while running, 0 = not limited by this plugin, but still subject to the host’s per-session maximum of simultaneously active continuable subagents, subagent.maxActiveSubagents, which defaults to 8); preset files are maintained with the project in the preset/ directory and are automatically installed to $DSH_HOME/.agent-presets on first launch (see README); all three stages consistently use “reuse within the same workflow, create new for a new workflow” (prompt protocol: subsequent rounds of plan/impl/review within the same workflow all use pipeline_followup to reuse existing subagents; from round 2 onward, only incremental content is dispatched, with no new settings); pipeline_followup supports compact=true: before dispatch, it first compacts the target subagent’s own history (use only when there is interference; if compaction fails, nothing is dispatched); each stage can be configured with a wall-clock budget (soft warning at 80%; automatically interrupts the subagent at the deadline and requests a closing report, then handles it according to the “continue / split / stop” protocol), plus a planned Workstreams partition table (independent workflows run impl in parallel, with each path restricted to an independently reviewed diff); since 0.4.2, “the run_code program is the context boundary (only PRINT/return content enters history and is resent at each step), print only distilled results, bound verification output, and cap workflow granularity” has been added to the three personas and presets; since 0.4.3, presets are automatically synchronized during installation/upgrades (the content fingerprint of the package’s preset is compared; if it changes, the installed copy is overwritten after leaving a temp backup; if the fingerprint matches, local user modifications are retained); since 0.4.5, the read window has been widened: when a read issued by an agent in this preset (the main-session root or a stage subagent) has a limit below the readWidenMinLines setting (default 2000 = the tool limit, equivalent to the full window), it is widened in place to that value before the host tools/execute around-waterfall runs; values above 2000 are clamped to 2000 (the batch failure caused by limit:2500 in 0.3.7 no longer occurs)—results of nested reads enter only the run_code program, not model history; widening costs zero tokens, allowing one program to obtain the necessary context and mechanically eliminating the paginated pattern of “reading one file in dozens of lines at a time and resending the full context at every step”; the setting can be adjusted or disabled on the settings page (Code Pipeline → read window minimum; 0 = disabled), with changes taking effect immediately; 0.4.6 fixed settings-page saves not taking effect (the save useCallback dependency array omitted readWidenMinLines, causing the closure to capture the initial value and always write the old value) and changed the default minimum from 2000 to 500 (covers most typical source files without loading very large files in full at once; 2000 = always use the full window, 0 = disabled; installations that have already saved 2000 must save again on the settings page or delete the explicit value from settings.yaml to inherit the new default); since 0.4.7, agents are informed that “reads have a minimum” (mechanical widening only ensures that each individual read is large enough; the model may still actively issue small-window sequential reads): the Step economy section of the preset persona now adds “Reads carry a FLOOR (default 200) — don’t read one file in consecutive small windows,” the three stage personas include the same NEVER chunk instruction, and the files dispatch injects the current minimum in real time (the next dispatch takes effect after changing the setting; when set to 0, it states that widening is disabled); the default minimum changed from 500 to 200
Compatibility and provenance
Code Pipeline is published as @dsh-external/dsh-code-pipeline and currently resolves to version 0.4.7. The Hub verifies its manifest and preserves the exact installation source for reproducible installs.
- DSH compatibility
- *
- Runtime surfaces
- web
- Release source
- github
- Registry updated