ディレクトリに戻る

dsh-runtime-log

キュレーションリスト掲載メンテナンス: 活発

wforevery/dsh-runtime-log

A lightweight DSH plugin for persistent local WARN/ERROR logs in rotating JSONL files. Features bounded buffering, best-effort secret redaction, and automatic log retention. Zero runtime dependencies. Supports DSH on Windows x64.

GitHub で見る
$ dsh plugin add dsh-runtime-log

54

スター

4

フォーク

JavaScript

言語

MIT

ライセンス

2026-11-11

作成日

2026-11-11

最終プッシュ

MIT ライセンスの DSH bundle。ホストの WARN / ERROR レコードをローカルのローテーション付き JSONL ファイルへ永続化し、有界バッファ・ベストエフォートのマスク・自動整理を備えます(Windows x64、DSH 0.2.2-rc.1、Node 24 のみ)。

DSH 統合

ネイティブ実行

作者による申告

安全性監査

未監査

最終検証日

2026-11-14

ライセンス

MIT

01どんなタスクに使えるのか?

  • DSH ホストを再起動したあとに調査する。そのときプロセス内の WARN / ERROR 出力はすでに消えている

    `$DSH_HOME/runtime-log`(なければ `~/.dsh/runtime-log`)配下の JSONL ファイル。WARN / ERROR の記録がプロセス再起動をまたいで残る

    ホストの警告やエラーを後から確認したい Windows デスクトップ版 DSH の利用者

  • 長時間動き続ける DSH ホストでログの増加を抑える

    実行ごとに `host-<pid>-<uuid>.jsonl` を 1 本、既定で 5 MiB のセグメントと 3 つのローテーションセグメント、さらに起動時の retention で古い run を整理する

    DSH を動かしているマシンのディスク使用量を毎日見張れない運用担当者

  • あるプラグインが DSH ホスト内でいつ起動し、いつ停止したかを確認する

    `dsh-runtime-log` という name のライフサイクル marker レコード。message は `[plugin-event:start]` / `[plugin-event:stop]` で始まり、通常の警告と同じ sink に書かれる

    bundle が正しく読み込まれ、正しく外れたかを確認したいプラグイン作者やメンテナ

02DeepSeek Harness への導入方法

前提条件

  • DSH 0.2.2-rc.1 —— README の互換表ではこれが唯一の対応 DSH バージョンで、Cordis 4.1.0 はその版が提供します
  • Node.js >=24.16.0 <25
  • Windows x64 —— bundle のプラットフォーム判定は `win32` のみを許可します
  • パッケージはまだ npm に公開されていないため、プロファイルの依存として指すしかありません

インストール手順

  1. 01

    あるプロファイルの依存をこのパッケージに向け、そのプロファイルの `dsh.profile.bundles` に `dsh-runtime-log` を追加します

  2. 02

    DSH を完全に終了してから起動し直します。プラグインは実行時にプロファイルを変更しないため、追加した bundle は完全な再起動でしか反映されません

導入成功の確認

  • 再起動後、runtime-log ディレクトリ(`$DSH_HOME/runtime-log`、なければ `~/.dsh/runtime-log`)に `host-<pid>-<uuid>.jsonl` が現れ、その中に name が `dsh-runtime-log` で message が `[plugin-event:start]` で始まるレコードがあるか確認します

03DSH 統合と能力の範囲

DSH 統合ネイティブ実行

プロファイルの `dsh.profile.bundles` に加える DSH bundle で、Cordis logger の exporter を登録し、WARN / ERROR の記録をローカルの JSONL ファイルへ書き出す

  • WARN / ERROR の JSONL 書き出し

    DSH の Cordis logger を通ったレコード→その実行のファイルへ書かれる JSONL 行。INFO と DEBUG は無視される

    ローカルディスクの runtime-log ディレクトリへログファイルを書き込む
  • 有界キューと最古レコードの破棄

    負荷時にまとめて届く WARN / ERROR レコード→既定で 2,000 件 / 1 MiB(書き込み中のバッチを含む)に制限されたキュー。負荷時は最古のレコードを破棄して計数する

    負荷時にはレコードが破棄され、その行ではなく破棄件数だけが残る
  • ローテーションと実行をまたぐ retention

    増え続ける実行ごとのログファイル→既定で 5 MiB セグメントと 3 つのローテーションセグメント、起動時の retention で目標上限はローテーションを含めて 16 run ファイル

    起動時に古い run ファイルを削除するが、他プロセスの live / unknown run は削除しない
  • ベストエフォートの秘密情報マスク

    限られた型のログ引数→整形されたレコード。認識できた鍵名や Bearer / API key はマスクされ、元の args オブジェクトは保存されない

    マスクはベストエフォートであり、自由文・未知のエンコーディング・独自のエラー内容に含まれる秘密情報はログに残りうる
  • 設定可能な sink の上限

    bundle の `config` フィールド(`directory`、`maxFileBytes`、`maxFiles`、`maxQueueRecords`、`maxQueueBytes`、`maxEntryBytes`、`flushIntervalMs`、`drainTimeoutMs`)→既定値を上書きする。無効または hostile な設定は例外を投げず既定値へ戻る

    相対パスの `directory` は黙って既定ディレクトリへ戻る

04誰に向いているのか?使うべきでない場面は?

向いている用途

  • ホストの警告やエラーを後から確認したい Windows デスクトップ版 DSH の利用者
  • DSH を動かしているマシンのディスク使用量を毎日見張れない運用担当者
  • bundle が正しく読み込まれ、正しく外れたかを確認したいプラグイン作者やメンテナ

不向きな用途

  • 0.1.0 の対応範囲はかなり狭く、DSH 0.2.2-rc.1 のみ、その版が提供する Cordis 4.1.0、Node >=24.16.0 <25、Windows x64 です。Node 20–23、Node 25+、他の DSH バージョン、macOS/Linux、Windows ARM64 は明示的に対象外で、bundle のプラットフォーム判定も `win32` のみを許可します。
  • 対象は Cordis logger を通ったレコードだけです。console / stdout / stderr のすべて、session JSONL、ツール実行結果、プラグイン読み込み前のメッセージは対象外です。
  • クラッシュセーフではありません。強制終了・停電・クローズのタイムアウトでバッファ末尾のレコードを失うことがあり、クローズがタイムアウトした run はプロセス終了まで保護集合に残ります。
  • 出力されるファイルはローカルの機密性の高い診断資料であり、機密ログとして扱う必要があります。マスクは自由文や独自のエラー内容に含まれる秘密情報の除去を保証できません。

05互換性・メンテナンス・セキュリティ上の注意

  • 0.1.0 の対応範囲はかなり狭く、DSH 0.2.2-rc.1 のみ、その版が提供する Cordis 4.1.0、Node >=24.16.0 <25、Windows x64 です。Node 20–23、Node 25+、他の DSH バージョン、macOS/Linux、Windows ARM64 は明示的に対象外で、bundle のプラットフォーム判定も `win32` のみを許可します。
  • 対象は Cordis logger を通ったレコードだけです。console / stdout / stderr のすべて、session JSONL、ツール実行結果、プラグイン読み込み前のメッセージは対象外です。
  • クラッシュセーフではありません。強制終了・停電・クローズのタイムアウトでバッファ末尾のレコードを失うことがあり、クローズがタイムアウトした run はプロセス終了まで保護集合に残ります。
  • 出力されるファイルはローカルの機密性の高い診断資料であり、機密ログとして扱う必要があります。マスクは自由文や独自のエラー内容に含まれる秘密情報の除去を保証できません。
2026-11-112026-11-11v0.1.0

MIT · README の記載のみ、最新リリース v0.1.0、セキュリティ監査なし

06よくある質問

DeepSeek Harness に dsh-runtime-log を導入するには?

プロファイルの依存をこのパッケージに向け、そのプロファイルの `dsh.profile.bundles` に `dsh-runtime-log` を追加し、DSH を完全に終了してから起動し直します。README によると、プラグインは実行時にプロファイルを変更せず、追加した bundle は完全な再起動でしか反映されません。またこのパッケージはまだ npm に公開されていません。

対応する DSH・Node・OS のバージョンは?

0.1.0 の対応範囲は DSH 0.2.2-rc.1 のみ、その版が提供する Cordis 4.1.0、Node.js >=24.16.0 <25、Windows x64 です。Node 20–23、Node 25+、他の DSH バージョン、macOS/Linux、Windows ARM64 は明示的に対象外で、bundle のプラットフォーム判定も `win32` のみを許可します。

ログはどこに書かれ、動作しているかはどう確認しますか?

既定のディレクトリは `$DSH_HOME/runtime-log`、なければ `~/.dsh/runtime-log` です。`directory` には絶対パスを指定できます(`~` も可)。実行ごとに `host-<pid>-<uuid>.jsonl` が作られ、既定で 5 MiB セグメントと 3 つのローテーションセグメントになります。ライフサイクル marker は name が `dsh-runtime-log`、message が `[plugin-event:start]` で始まる通常の WARN レコードです。

DSH ホストが出力するすべてを記録しますか?

いいえ。保存されるのは Cordis logger を通ったレコードだけです。console / stdout / stderr のすべて、session JSONL、ツール実行結果、プラグイン読み込み前のメッセージは対象外です。マスクはベストエフォートなので、自由文・未知のエンコーディング・独自のエラー内容に含まれる秘密情報はファイルに残りうるほか、強制終了や停電でバッファ末尾を失うこともあります。

08データと出典

  • 作者による申告github.combcf9fa9bd547…

    把 DSH Cordis logger 的 WARN / ERROR 记录写到本机 JSONL,供进程重启后排查。插件只注册 logger exporter,不读取会话历史或凭据,不联网,不提供模型工具、UI 或 system prompt…

  • 作者による申告github.combcf9fa9bd547…

    把一个 profile 的依赖指向本包,并把 `dsh-runtime-log` 加入该 profile 的 `dsh.profile.bundles`,然后完整退出并重启 DSH。

このページは、プロジェクトの公開ドキュメント、リポジトリのメタデータ、および DSH Plugins の構造化解析に基づいて生成されています。最終検証日:2026-11-14。誤りを見つけた場合は、修正を送信してください。

🏆

dsh プラグイン おすすめ

最初に入れたい 12 のプラグイン。全カタログ・全カテゴリから厳選しました。

DSH Plugins は DeepSeek Harness プラグインの独立したコミュニティ ディレクトリです。DeepSeek との提携・公認はありません。サードパーティ製プラグインはセキュリティ監査を受けていません。インストール前にソースコードをご確認ください。

DeepSeek Harnessの新着プラグインを毎週お届け。スパムはありません。