dsh-performance-guard
DeepSeek Harness 的性能诊断、反复插件隔离测试、安全恢复与量化验证
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add dsh-performance-guard@0.3.0Performance Guard 以 dsh-performance-guard 发布，当前版本为 0.3.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →DSH Performance Guard is a DeepSeek Harness Host + Web Client plugin for diagnosing long-session, UI-rendering, background-request, tool-task, watcher, timer, and third-party plugin-group pressure. It provides reversible profile isolation and measured before/after verification.
Version: 0.3.0
tools/execute, llm/stream, and session/event observations during an active check: tool duration/failures, model duration/first chunk/cache tokens, and broad session-event categories.improved / regressed / no-effect / inconclusive outcomes. Manual campaigns never receive a high confidence label.pnpm install
pnpm run build
dsh plugin --profile web add link:$(pwd)
Restart DSH Web and open Settings → Performance Guard. After an npm release:
dsh plugin --profile web add dsh-performance-guard
DSH exposes no in-shell restart API. The plugin returns an exact launch command and never terminates DSH or auto-starts a retest before the workload is ready. Between bisection steps it also returns the source-profile launch command; the next isolation action stays disabled until that source Profile is active. Cancelling a campaign atomically disables its linked automatic retest marker but never deletes or silently rolls back the generated Profile.
Safe mode creates $DSH_HOME/profiles/<profile>-perf-safe-<id>, copies profile metadata, links the existing node_modules, and adds a final overlay for selected eligible Loader entries. It writes a prepare journal before creating files, persists an optimization-owned marker immediately after directory creation, and writes a separate completion marker last. Startup preserves every still-present incomplete or replaced directory for Recovery Center review. User-triggered cleanup delegates to the existing rollback primitive and is enabled only when the canonical target directory and exact ownership marker match. The source profile is unchanged.
Direct disable writes a durable backup and prepare journal before atomically replacing cordis.patch.yml. Profile changes and rollback share a cross-process transaction lock; persisted transitions use expected-state compare-and-set checks. State, backup, patch, and restore writes fsync file data and containing-directory metadata. Symlinked patch/backup targets are refused. Rollback also verifies the post-change SHA-256 and stops instead of overwriting a newer user edit. Startup reconciliation completes or reverses interrupted transactions.
0.3.0 multi-run statistics improve confidence but manual checks never upgrade to confirmed causation.Ordinary Resource Timing cannot reliably identify an originating plugin. A plugin bundle URL only proves bundle loading, not later CPU or render ownership. Watcher and timer counts are process-level. Campaign runs are paired by server-issued repeatIndex, but repeated manual work in one session can remain autocorrelated, so confidence is capped at moderate. Specific attribution therefore requires exact group isolation and repeated narrowing, and remains correlated rather than controlled evidence.
The Client ring is capped at 5,000 events and 8 MiB. Host sampling runs only during a check, and the plugin excludes its own /api/performance-guard/* traffic from Resource Timing.
The plugin does not collect or export prompts, responses, DOM text, raw session IDs, tool arguments/results, request paths/bodies/headers, cookies, credentials, environment-variable values, or raw session-log bodies. Reports retain plugin names/versions, tool names, and model provider/model/purpose because those identifiers are necessary for diagnosis. Runtime fingerprints contain only software/browser versions, platform/architecture, CPU count, total memory, viewport, and DPR. Resource domains and session identifiers are hashed before persistence.
Benchmarks, campaigns, and transaction records stay under $DSH_HOME/performance-guard. The ordinary history retains 50 benchmarks; benchmark IDs referenced by retained campaigns are pinned so campaign evidence is not orphaned. Reports are generated and downloaded locally and are never uploaded automatically.
Host routes/listeners, Client slots, locale dictionaries, styles, observers, RAF callbacks, timers, and event-loop monitors are Fiber-owned. POST routes require loopback transport, JSON, explicit same-origin browser metadata, and an ephemeral process token. Finish, cancel, or unload clears transient sampling state.
The plugin does not register model tools, add Agent context/tokens, monkey-patch the DOM/network/timer/subprocess APIs, rewrite third-party source, replace the DSH conversation renderer, or claim to repair core virtualization.
pnpm run typecheck
pnpm test
pnpm run build
pnpm pack --dry-run
DPG_TEST_URL=http://127.0.0.1:<port> pnpm run verify:ui
PNPM_BIN=/absolute/path/to/pnpm pnpm run verify:packed-profile
PNPM_BIN=/absolute/path/to/pnpm pnpm run verify:release
UI verification covers desktop, a 320px container, 390×844, 200% zoom, keyboard tab navigation, destructive-confirmation focus, start/cancel behavior, and root overflow. verify:packed-profile builds a real tarball, installs it into a temporary DSH_HOME, validates the packed manifest/client graph/bundle bytes, and starts a short-lived loopback-only Web profile for browser boot. Set DSH_CLI, NODE_BIN, PNPM_BIN, and CHROME_BIN explicitly outside the installed macOS layout. Registry access is required for the clean install stage unless CI supplies a populated pinned pnpm store; the boot and browser stages allow loopback traffic only.
Requires Node.js 22.19+ or 24+, and targets DSH 0.1.1-rc.2+.