dsh-deep-ptc-mode

Deep PTC mode

[中文](README.zh.md) · MIT · 1.8.6

[1.7.3 实测汇总 / Test summary](TEST_REPORT.md)

Reports. Asks. Stays awake. Plans. Stays reachable.

Five basics, one mode; everything is a plugin, with the official preset always as the fallback.

Deep PTC is not another tool bundle. It is a DeepSeek Harness agent preset built around five basic problems in model work: working silently without reporting, guessing instead of asking when intent is ambiguous, sleeping and becoming unreachable during a task, not planning or not showing the plan, and not using the original PTC preset's concise context plus its unlimited-token prompt.

Those five are handled first by prompts and code. On top of that, following DSH's “everything is a plugin” philosophy, the preset adds dynamic preset/tool loading, creative-mode tools for building DSH plugins, dsh-go screen-control adaptation, wider shell support, external plugin tool/workflow adaptation, and a leaner skill/tool loading flow. Deep PTC adds no task tools itself; it provides the interface that lets a plugin's new tools be discovered, loaded and called.

Not every third-party plugin is guaranteed to fit: the interface is verified for dsh-ops and reused by other plugins, but a plugin still has to support the installed host and publish its tools under the expected contract.

Five basic problems

| # | Problem | What Deep PTC does |

| --- | --- | --- |

| 1 | Working silently without reporting | One sentence before every run_code; a longer update at milestones; never more than two or three silent tool calls; a short final result with failed tools and providers. |

| 2 | Guessing instead of asking | Meaning belongs to the user, facts to the tools: ask one to three questions with options when names, targets, routes, scope or acceptance criteria are unclear; look up inspectable facts yourself. The user's answer wins. |

| 3 | Sleeping or becoming unreachable | Enforced in code: foreground waits move to the background after 30 s; a user message hands the waiting command to the background within about 2 s; foreground sleeps over 5 s are refused; job completion wakes the model. |

| 4 | No plan, or an invisible plan | Plan by estimated size: act silently under 5 minutes; show the plan and start without approval for 5–20 minutes; show it and wait for approval over 20 minutes. Re-plan when the estimate moves up; the user can redirect at any step. |

| 5 | Not using the concise context and unlimited-token prompt | Derive from the live official PTC composition, keep the tool catalog compact and load full schemas on demand, and state that this mode spends its token budget on reads, searches, commands and checks rather than rationing them. The prompt does not change billing or the real token limit. |

Built for “everything is a plugin”

1. Dynamic preset and tool loading

Read the running host's official PTC declaration and inherit its rows as they are; only the persona, execution group, reachability guard, job wrapper and question wrapper are replaced. Rebuild only when the declaration or settings change, checked when settings change and once before each Deep PTC conversation is created or resumed, with no polling timer; fall back to the bundled snapshot with a warning if it cannot be loaded, parsed or derived. An official upgrade can add tools without a release of this preset; existing sessions are not forcibly switched.

2. Flexible creative-mode tools

The plugin lab is always on for a session. It reads the host's creative preset and appends only the rows that mode adds, specifically for building DSH plugins. Module names stay as declared; skill directories resolve relative to the creative preset file. Lab packages stay in process memory, are not written to the repository, shipped presets, desktop composition or this plugin's source, and run only through the host's existing approval. Loading reads the roster and documents only; it never calls composedPreset.

3. dsh-go screen-control adaptation

Screen-control tools stay in the initial PTC SDK, are not moved on demand, and are not quarantined on failure. Recognition uses the tool's own resident mark, dsh-go/view, its name or its provider mark. Deep PTC does not claim dsh-go's slots or replace its settings form; if the tool-state projection fails, that control stays empty without tearing down the composer or screen-control UI.

4. Wider execution environments

WSL Bash, PowerShell (including discovered 5.1 and 7 executables), Zsh and native Bash are supported. The choice applies to this preset only and does not change the global shell; sandbox, approval and process management stay official. WSL currently requires the host-authorized danger-full-access mode.

5. External plugin tool/workflow adaptation (dsh-ops tested)

This is the core interface: external plugins publish tools under their own contract; Deep PTC discovers them, loads them on demand, quarantines failures per conversation and falls back to official PTC. Extensions must support the installed host and publish into the deep-ptc scope; Deep PTC does not depend on any specific plugin or replace the executor.

dsh-ops is specifically tested. Its gate recognises only minimal/standard/ptc/cordis. Deep PTC first offers the native deep-ptc; when it detects that the plugin restricts preset names, it returns the base id the plugin accepts — ptc (or cordis for a creative row) — while host internals keep the exact deep-ptc. dsh-ops therefore needs no change for its new tools to be discovered and called; other plugins use the same interface, judged by their own packages. Unattributed tools are not quarantined; only a positively attributed external provider can be, and official tools are never quarantined.

6. Leaner skill and tool loading

Each turn ends with a skill context card that lists only the skills still loaded and not closed, so the user decides what stays for the next turn