プラグイン

DeepSeek Harness ビジョンプラグイン：8 つの分析モード（記述、OCR、チャートデータ、UI レビュー、物体検出、比較、コード生成、デバッグ）、任意の OpenAI または Anthropic 互換ビジョン API に対応し、組み込みの無料ビジョンモデルと自動レート制限フェイルオーバーを備えます。

DeepSeek Harness 用 LLM デバッグコンソール：llm/stream ウォーターフォールですべてのモデル呼び出しの全内容（オプション、ストリームチャンク、使用状況、ワイヤプロトコル）をキャプチャし、共有プレフィックスコンテキスト差分、ワイヤ JSON 再構築、JSON エクスポート、ランタイム調整可能なキャプチャポリシーを備えた DevTools スタイルのドッキングパネルに表示します。

エンジニアリング方法論のスキルライブラリを 1 つの Cordis プラグインとして同梱：DeepSeek Harness の ctx.skills に 14 の Agent Skill（計画・テスト・デバッグ・レビュー・納品）を登録します。

実際にログイン済みの Chrome ブラウザをそのままのプロファイルで制御：MCP サーバーに加え、タブ、ロケータ、ファイル注入、メディアのエクスポート、永続的なスクロールキャプチャのための MV3 拡張と認証付き localhost ブリッジを提供。デバッグ用プロファイルも remote-debugging ポートも不要。

上流モデル API のすべてのペイロードを JSON として記録します(デバッグ・可観測性向け)。

DeepSeek Harness 向けの構造化されたコードレビュースキル——バグ、セキュリティ、パフォーマンス、スタイルをカバーします。

現在の dsh セッションの実行中の指示チェーンとプロジェクトスキルを検査・管理できます。その場での作成・編集にも対応し、表示されている内容がそのままモデルに渡されます。

DeepSeek Harness セッション向けの、ローカル優先な障害エビデンスカプセル機能。

`dsh plugin add` で導入する、DeepSeek Harness 向けの Feishu(Lark)IM ブリッジ。DM ユーザー1人につき1つの永続的な dsh セッションを割り当て、詳細なデバッグドキュメントも付属します。

One-step local model onboarding plus a light harness for DSH. On load it probes loopback and private-network inference endpoints (llama.cpp, Ollama, vLLM, LM Studio), reads each model's context window and output budget from the backend, and registers the provider through settings, so a local model becomes selectable without hand-writing config. It then trims only that provider: masks the tool list through tools.restrict, drops named system-prompt sections and memory contexts, swaps the injected instruction block for a short one while preserving its first 80 and last 96 characters, and truncates tool-schema descriptions without touching structure or required fields. Cloud providers are returned as the same assembly object, untouched. The injected block is re-read from disk on every assembly, so editing the file takes effect on the next request with no reload. The panel in the plugin detail page is a live operations view: it shows whether the takeover is active and by which hook, how many characters the last assembly was trimmed from and to, and which providers are online (probed concurrently, with a real one-shot completion reporting latency and reply text per provider). If a local backend is not running, the panel offers a one-click launch: it probes the port first (never starting a duplicate), then starts the matching server (ollama serve, or a custom command you supply) detached and polls until the endpoint answers, clamping the wait to 3-600 seconds, reaping the child it just spawned if it never answers, and naming the paths it searched when it cannot find the binary. A stop button kills backends this plugin started (SIGTERM, then SIGKILL) and refuses to touch a server somebody else launched. When a model has just been downloaded and no backend exists yet, the panel can also scan the machine for .gguf files with hard caps (300 models, 20000 directory entries, Downloads only one level deep), start llama-server on the chosen one (skipping the .mmproj. vision projection and reusing a server that already answers), register the provider under the model id the backend reports, and run one real completion to prove it works. Before spawning anything it does a fit check that counts only the part of the file the GPU cannot hold: hostBytes = fileSize - VRAM, compared against max(total RAM - 2GB, free RAM). A file far larger than RAM is refused outright; a heavy host-side remainder is refused unless you confirm; the same remainder under mmap is only a warning, because the weights land in reclaimable page cache. A load-mode selector (auto / mmap / none / mlock / mmap+mlock) maps to llama.cpp --load-mode, and the default is whatever the engine picks. From 0.4.2 everything above is derived from the platform instead of assumed: home and data directories come from os.homedir() and the OS conventions (LOCALAPPDATA on Windows, ~/Library/Application Support on macOS, XDG_DATA_HOME elsewhere); backend binaries are looked up in the official install locations of each OS and can be pinned with OLLAMA_BIN, LLAMA_SERVER_BIN, VLLM_BIN or LMSTUDIO_BIN; model discovery walks DSH_LOCAL_MODELS_DIR, ~/models, ~/llama.cpp/models, ~/.cache/llama.cpp and the LM Studio data directory, with the WorkBuddy layout demoted to one candidate among them. VRAM is asked from nvidia-smi, then rocm-smi, then sysctl hw.memsize on Apple Silicon (flagged unified, so the same bytes are not charged twice), and any flip to a unified-memory budget is handled explicitly. Before building a command line the plugin runs llama-server --help once and keeps only the flags that build actually has, so older engines get --n-gpu-layers 99 and no KV quantization while newer ones get auto plus q8_0; anything it cannot probe is passed through rather than dropped. LM Studio is started with lms server start --port N rather than being lumped in with the engines that need a model argument, and vLLM gets its own --model example instead of llama.cpp syntax. Windows, macOS and Linux are all exercised in CI, including a windows-latest and a macos-latest job, because a cross-platform claim that has only ever run on one OS is not a claim. Two of those suites exist specifically to catch this machine's blind spots: one replays the whole suite with process.platform rewritten to each OS, and one deletes every advantage this development box has — no nvidia-smi, no rocm-smi, no sysctl, an empty PATH, a home directory with no models — and requires graceful degradation rather than a crash. That last one caught a real class of bug: several assertions hardcoded 'lms.exe', which cannot pass where the executable has no suffix. Measured on the reference machine: a 16.9GB 27.2B MoE with 14.5GB of VRAM holds a 285-691MB working set and sustains 76 tok/s after a 1000-2000 token warm-up, so file size alone is not a fit signal. From 0.4.3 the scanned models are shown as a table rather than a dropdown (one row per gguf, with its size and any fit warning), so you can see what is on disk before choosing. From 0.4.4 the delete button on the provider table removes the provider entry, not the weights file on disk. That distinction matters: what people actually want to clear out is the dead entry - one pointing at a port that never answered, one registered twice for the same port, one whose model file was deleted long ago - not a 15.8GB gguf. Deleting a config is undone by importing again; deleting a gguf is not. The removal goes through settings.mutate with an unset op on \['providers', id], because update merges layers: writing null there leaves a null provider key that the loader reads as a broken config rather than an absent entry, and only mutate/unset is implemented as Reflect.deleteProperty. The result is read back afterwards, because unset on a key that comes from a lower layer (the profile cordis.patch.yml or a home patch) does not delete it - it restores the inherited value, so the call succeeds while the entry stays. When the entry is still there the panel says so and points at the file to edit instead of reporting success, and a DSH whose settings service predates mutate() is told plainly rather than silently ignored. Deleting takes two clicks and clearing the confirmation is as easy as clicking another row; on success the online and baseURL caches are cleared and the tool surface is recomputed, since the provider list changed. The gguf itself is never touched by this plugin - the scanned-model table is display and selection only.VRAM reporting is driver-dependent. From 0.4.5 model discovery also reads Ollama's own storage: its blobs are named sha256-… with no extension, so extension matching could never list them. Weights are now accepted by extension OR by GGUF magic header (only dot-free files of at least 8MB, capped at 600 header reads per scan; obviously-not-weights extensions like .json/.md/.safetensors/.part are never opened). Ollama models are resolved from their manifests: the model layer is picked by mediaType application/vnd.ollama.image.model (never adapter/mmproj layers), the human-readable name is restored from the manifest path (…/qwen3/8b becomes qwen3:8b, …/latest stays bare), tags sharing one blob merge into a single row, and the metadata kv supplies name, quantization and context length. Adopting an Ollama model does not start a duplicate llama-server over the same weights: it confirms ollama serve answers on 11434 (launching it if not) and registers the provider under the tag the endpoint itself reports — the blob's sha256 name would never match anything, since 11434 lists qwen3:14b, not sha256-a8cc…. Two real-machine-only traps fixed on the way: existsSync('<file>/') returns true on Windows, so manifest-vs-directory branching now goes by parseable content instead of trailing-slash semantics; and the quantization label table had been copied from a stale ggml enum generation, labelling ggml_type 15 as Q5_K_S while ollama show reports Q4_K_M. Same-blob dedup is by (dev,ino), keeping whichever entry has a name. Verified on the reference machine: the scan goes from 1 row to 4 — qwen3:14b (8.64G) and qwen3:8b (4.87G) now appear with Q4_K_M badges — in 4ms; npm run verify exits 0 (launcher 57, portable 35, panel-host green including the linux/darwin simulated-platform runs); the new panel-host suite builds a real miniature Ollama store in tmpdir and points OLLAMA_MODELS at it, so results no longer depend on whether the test machine happens to have Ollama installed. From 0.4.6 the panel shows each model its real name instead of its file name, because some download tooling stores every weight under one generic file name, leaving the real name only inside the GGUF header. The scan now reads each file GGUF KV section - not a fixed-size head buffer, because tokenizer.ggml.tokens (hundreds of thousands of strings on a large MoE model) and the chat template push general.file_type past any window; and GGUF string arrays are interleaved (u64 length plus payload per element), so treating them as a length table walks the cursor off the rails and produces astronomically large reads. Reading and skipping are accounted separately: key names and types are always read, string values over 256KB and string arrays are only walked past without copying, non-string arrays over 64 elements are skipped outright, and a cursor past the file size stops the read, because an out-of-range position means the cursor is wrong rather than that a limit should be raised. The displayed name goes Ollama tag, then general.basename plus size_label, then general.name, then the file name, with the full string kept for the hover text since it usually carries internal build numbers; mmproj files are now identified by general.type as well as by name. A short read (truncated file) no longer feeds half a value into the parser. On the reference machine, reading one file header parses 44 keys in about 16ms, and a whole scan takes about 31ms. From 0.4.7 the smoke test no longer fails the first time and passes the second. The old code gave both request attempts one shared AbortController and one shared 30-second timer, so the total budget covered both rounds: a cold load of a large model burned it in round one, the abort left the signal permanently aborted, and the second round (the Ollama-style reasoning_effort: none retry) could not even be sent - which is exactly why the first click returned This operation was aborted and the second succeeded. Now each attempt gets its own controller and timer, a timeout retries once automatically (retryOnTimeout, on by default) because a first-request timeout almost always means the weights are still being read from disk, and non-timeout errors (refused connection, HTTP error) are not retried at all. Timeouts report themselves: the message says the wait exceeded smokeTimeout, whether a retry already happened, and points at the new smokeTimeout setting (seconds, default 60, clamped to 5-600) - port responding is not the same as tokens coming out, so it is a separate knob from launchTimeout. Unrelated: an example naming one specific model was dropped from the panel copy, since not every machine has that model downloaded, and the explanation now describes the mechanism instead.

DeepSeek Harnessに組み込まれた閉ループ開発コックピットです。1つのパネルからエージェントがSTM32ボードをビルド、書き込み、デバッグ検証、監視し、ユーザーは進捗段階、ストリーミングログ、RAM/FLASH使用量、デコード済みシリアル波形を確認できます。PATH上にホストPython 3.10+が必要（プラグインからはインストール不可）。ARMツールチェーンは初回に自動ダウンロード（約400 MB、Windows x64のみ）。STM32ボードとデバッグプローブも必要です。

ログインが必要なサイト向けのブラウザー操作です。ログインが必要なアドレスをURLと日付だけで保存し（認証情報は保存しません）、訪問前に登録済みか確認します。サイト固有のセッションCookie名からデバッグ用ブラウザーのログイン状態を「確実／可能性あり／未ログイン」と判定します（_gh_sessなどの匿名Cookieは数えません）。保存先を開き、表示テキストで指定した1要素をクリックします。全iframeを検索します。1回の呼び出しにつき1クリックで、クロールはしません。

既に起動中のNetEase Cloud Music desktop clientをCDP経由で操作します（起動時に`--remote-debugging-port=9222`が必要）。NetEaseの公開web APIで曲を検索。API keyや追加loginは不要で、会員限定機能はclientにログイン済みのアカウントを使います。

Harnessサイドバー内のGitee Enterprise作業項目ワークベンチ。プロジェクト、タスク、要件、バグを閲覧し、詳細、子タスク、コメント、Markdownを確認できます。作業項目の作成・編集や@参照にも対応。

AMD ROSS向けagent skill 50種をDeepSeek Harnessに収録します。Vivado、Vitis HLS、Versalのsegmented configuration、Vitis AI、hardware debugに対応。左サイドバーのcatalog panelでskill invocationを絞り込み、検索、コピーできます。

DeepSeek Harnessに`muse` subagent providerと`subagent_muse` toolを追加。メインagentが自己完結タスクをMeta Muse Code CLIへ渡し、最終報告だけを受け取れます。DSH 0.2.1で動く`@pascapone/dsh-muse-code`のpatched forkで、削除済み`settleRun` exportと`subagents.start` methodのローカル代替を含み、gateway stream-phase bug用の任意proxyも説明。`muse` CLIが必要。上流かこのforkのどちらか一方を導入（同じsubagent-muse loader rowを登録）。

DeepSeek Harnessにユーザーが呼び出せる2つのコード品質skillを追加：/simplifyは現在の差分を動作維持で整理し、/code-reviewは独立検証パスを伴う多角的なバグ調査を行います。/reviewは別名です。

WuwaTappoデスクトップペットの吹き出しを活用。DeepSeek残高、本日の利用額、ターンごとの費用を表示し、エージェントが回答または承認を待っている間は琥珀色のリマインダーを表示し続けます。CDPでペットと通信し、1回限りの元に戻せるバイトパッチでデバッグポートを有効化します。

DSHプラグイン作者向け公開前ゲート。全公開経路を決定論的に検査し、GitHub/npm/市場向けの正確なコマンドを提示。package.json（exports["."]、filesからlib/の欠落、type:module、./client export）、UTF-8 BOM、JSON/YAML、cordis.patch.ymlのindent/insert名、entry export、ESM内require()、LICENSE/README導入行、テスト不足、granular tokenでも原因を特定できない403となる非scope付きnpm名、公開済みversion、GitHub repo欠落等を確認します。指摘ごとに修正案を付けるエージェントツール6種。読み取り専用、LLM不使用。

各ターンのコンテキスト予算の内訳を監査。AGENTS.md、skillカタログ、ツールschema、ランタイム文脈へのコストを分け、変更のない内容の繰り返し注入を無駄として検出。skillを60件以上導入した場合に毎ターンモデルが読む説明量と、プラグインごとのツールschema膨張を順位付けします。決定論的でLLM不使用。全セッション走査を含む4ツール。

コンテキスト圧縮で実際に失われた内容を監査。生のセッションイベントログから、ユーザーの恒常的制約（禁止/必須/限定指示）の要約での生存、履歴にないパス/版/ポート/IDの捏造、削除済み文への「上記参照」、解放予定量に近い大きさの要約、未計上削除を検査。arXiv 2608.11242 による測定例では、圧縮器全体で制約の生存率は約17%。圧縮の影響度で会話を順位付けする全セッション走査を含む4つのエージェントツール。決定論的でLLM不使用のため、誤判定は特定ルールの不具合です。

DSH左サイドバーの禅道作業パネル。担当タスク/バグ/ストーリーを一覧し、Webログイン方式でRESTful v2 APIが使えない環境も対応（ZenTao 18.13 OSSで検証）。検索、スマート並べ替え、期限超過/今日期限フィルター、フローボードを備えます。カード説明、最近のコメント、スクリーンショットを入力済みの新規チャット（または空チャット）を開くか、ワークスペース/モデル/推論強度/任意指示を選んで新しいバックグラウンドセッションへ単件または一括で割り当てます。チケット内画像は実画像添付に変換。完了後は紐付くセッションの最新返信を読み、実行中/判断待ち/完了の状態、手動上書き、手動完了印を管理。複数アカウント対応。読み取り専用で禅道へ書き戻しません。

Windows専用のDSH sidebar preview/Dart hot reload。設定済みStarcompanion/Operit2由来project向け。preview scripts、prebuilt debug APK、Android SDK、Flutter、scrcpy 3.3.3必須。

stdio MCPサーバーをDeepSeek Harnessのネイティブツールとして公開。公式Microsoft Playwright MCP presetを同梱し、既に開いているEdge／Chromeでログイン状態を保ったまま閲覧する。他のstdio MCPコマンドも設定可能。ホストのみで動作し、クライアントbundleやnpm依存なし。自分のブラウザーを操作するにはEdge／Chromeをremote debuggingで起動し、npxによる@playwright/mcp取得を許可する。