dsh-find-simplifications

DeepSeek Harness の簡素化を探す

維持すべき責務を取り除く変更を探します。対象には、API、表現、ライフサイクルの状態、設定経路、依存関係、テスト、ドキュメントが含まれます。削除件数を重視するより、根拠のしっかりした候補を少数挙げることを優先してください。これは指針であり、チェックリストではありません。ユーザーのスコープを守り、調査と提案の実装許可を区別してください。

スコープと制約の確認

パッケージを評価する前に、AGENTS.md、アーキテクチャ、防御的なパターン、テストポリシーを確認してください。意図的な判断については、該当する現行の Agent Notes を参照してください。新しい記録を追加する場合は、ノートのルールに従ってください。アーカイブ済みのノートは過去の例であり、現行の指針ではありません。外部リンクを確認、検証、修復する目的で参照してはいけません。

2 つの LLM アダプターは意図的なものです。JSONL は唯一のファーストパーティ Session 永続化プロバイダーであり、バックエンドに依存しない Service Definition は、ツリー外のプロバイダーをサポートします。ユーザーが明示的に制約を覆さない限り、LLM の重複実装や永続化の分離境界の削除を提案してはいけません。保護対象の設計内でも、その目的を損なわずに削除できる未使用のメンバーは候補になります。

広範な依頼では、独立した領域をサブエージェントに分担してください。対象は、ループと永続化、モデル／ツールの組み立て、Host・Client・SDK、サブプロセスと実行プロバイダー、構成・スクリプト・テスト・ドキュメントです。各エージェントには範囲を限定して割り当て、利用箇所の根拠と、採用しなかった代替案を示すよう求めてください。明らかな未使用シンボルだけでなく、大規模な本番コードの仕組みも調査してください。有望な削除候補が最初に見つかった時点で調査を終えないでください。

削除可能な義務を探す

調査の指針として、次の質問を使ってください。レビュー対象のコードが導入する要件、チェック、エージェントノートは、評価すべき設計上の選択であり、それらの区別が必要であることを裏付ける独立した証拠ではありません。候補の妥当性を判断する必要がある場合は、過去のパターンの該当セクションを読んでください。例は判断の参考であり、現在削除すべきものの一覧ではありません。

• 宣言された機能には、効果が完全に反映される経路がありますか？ 生成元、変換、プロバイダーまたはエンドポイントのサポート、観測可能な結果をたどってください。フィールドがすべての箇所にコピーされていても、セッターもリーダーもない場合や、それを拒否する実装しかない場合があります。CLI や設定のパススルーについては、値が使用前にシャドーイングされる転送値を見つけるため、信頼できる読み取り元と優先順位を追跡してください。呼び出し元だけでなく、コンストラクターや判別子の出力箇所も検索してください。
• どの区別がコンシューマーの動作を変えますか？ まず、その区別、フィールド、アダプター自体が必要かどうかを確認してください。トランスポート固有のマーカーを追加する前に、既存のソースフィールドや判別子が、出力箇所や認可・機能チェックを通じてどう扱われるかをたどってください。大まかなエンベロープのカテゴリが、ソースフィールドと同じ意味を持つとは限りません。区別の削除と宣言箇所の移動は別々に検討し、それぞれの選択肢で許可される入力や機能を明記してください。複数の内部状態を、モデル向けの単一の状態や利用可能な単一の識別子にまとめられる場合があります。必要な認可、データ保管場所、永続性、所有権に関する動作は維持し、利用不能な選択肢を招くだけの公開上の区別は削除してください。
• より小さく明示的な動作で、サブシステムをなくせますか？ 固定間隔、呼び出し元が指定するタイムゾーン、または有効化失敗の報告によって、汎用的なカレンダー、永続化されたデフォルト、自動ロールバックを不要にできる場合があります。失われる機能と削除される仕組みを明記してください。本番環境の呼び出し元がある場合、これは動作に関する判断であり、自動的に却下する理由にはなりません。実装はユーザーの認可範囲内にとどめる必要があります。
• 必要なときに、コンシューマーは信頼できる値を読み取れますか？ コピーされた履歴、昇格の台帳、読み取りが後続する無効化イベント、共有プロジェクションストリームと並存する機能キャッシュを探してください。導出または再利用によって、サブスクリプション、保持データ、古い応答の処理、復旧経路をまとめて削除できる場合があります。まず、観測が必要な時点を明確にしてください。
• 構成とポリシーを混同していませんか？ オプションのサービスの存在、プロバイダーメソッド、または関連ツールの存在によって、デプロイ時の動作を決めずに利用可能性を表せる場合があります。明示的な設定や呼び出し元の意図に基づく操作によって、レジストリや依存関係チェックを削除できることがあります。所有者や完了のタイミングが異なる操作は、それぞれ分けて維持してください。
• 保守コスト全体を誰が負担しますか？ 重複したアプリケーションツリー、製品で使われるデモランチャー、リゾルバーのみのワークスペース、独自のアップグレードライフサイクルを持つインストールヘルパーを追跡してください。必要な動作については、所有権のルールに照らし、宣言マージを含む既存の生成元・コンシューマーの拡張ポイントと、離れた場所にあるコア宣言や共有型宣言の変更を比較してください。残存する接着コードも含め、置き換え前後のシステム全体を比較してください。不要な概念を所有者の近くへ移動したり、重複定義の一致を保つゲートを追加したりしても、保守コストはなくなりません。

到達可能性とトレードオフを証明する

まず rg で検索し、一致箇所を読んでください。正確なシンボル、プロパティの読み書き、判別子、イベント文字列やワイヤー文字列、設定キー、パッケージ名、および .method( と method( の両方の形式を検索してください。テストや宣言から契約は確認できますが、出荷されたプロデューサーやコンシューマーの存在を証明できるとは限りません。

packages/*/*/src、apps/、python/、ランタイムスクリプト、出荷されるプロファイルとオーバーレイ、パッケージマニフェストとエクスポート、ローダーの解決、生成されたランタイムアセット、インストール済みパッケージのコンシューマーを含めてください。サンプルやフィクスチャは、ディレクトリ名ではなく実際のエントリーポイントに基づいて分類してください。生成されたカタログは、そのコンシューマーまで追跡してください。モデルが記述したプラグインのマウントで使われるカタログは動的な製品 API ですが、ドキュメント専用の一覧は固定の呼び出し元ではありません。公開されたサードパーティー拡張パスは、リポジトリ内に呼び出し箇所がなくても意図的な場合があります。静的な未使用コードチェッカーは、マニフェスト駆動の読み込み、生成された出力、コンパイラーの各利用面を対象にする必要があります。ワークスペースごとの例外一覧を別途管理してはいけません。

候補ごとに、現在の所有者、実効的なプロデューサー／コンシューマーの経路、なくなるもの、残るもの、機能と互換性への影響、および維持する最も強い理由を記録してください。次の点を区別してください。

• 到達不能な動作や読まれない動作の削除
• 明示的な損失を伴う、より狭い公開動作または製品動作
• 保護すべき義務、または証拠不足

維持すべき義務を破る候補、複雑さを単に別の場所へ移す候補、または意味のある削減がない候補は却下してください。却下理由は提案された変更の範囲で確認してください。古い一覧や、複数の項目を含む提案で却下された動作だけでは、独立したすべての項目の結論は決まりません。再提案する前に証拠を更新してください。小規模なローカル改善は、単独の設計記録ではなく、緊急度のルールに従って、実行可能な TODO／FIXME／XXX コメントとして記載してください。

所有権と失敗時のセマンティクスを保つ

コピー、フリーズ、バリデーター、コールバックのキャプチャについて、値の由来、次の所有者、信頼境界を明記してください。同一プロセス内の型付き呼び出しでは、通常、読み取り専用の値を借用します。一方、パーサー、設定ローダー、キュー、モデル／ツールの JSON、永続ファイル、ワーカー、プロセス、ワイヤーデコーダーは、入力を所有するか検証します。それだけで悪意あるゲッターやコールバックの差し替えをテストしても、要件の証明にはなりません。ルートがフリーズされていても、その子孫が不変である証明にはなりません。また、ID が等しくても、オブジェクトの同一性の証明にはなりません。

非同期の仕組みについては、各プロミス、フラグ、キャンセル経路、ディスポーザー、予約を、それぞれの所有者と状態遷移に対応づけてください。同じ事実を表している場合に限り、仕組みを統合してください。必要な場合は、同期的な公開とロールバック、コールバックの隔離、最初に発生した終端結果の優先、ワーカー／プロセスの所有権、静止状態までの破棄を維持してください。トランスクリプトのレンダラーが無視していても、永続的な開始／終了マーカーは実際に起きた事実を記録している場合があります。中断された作業を破棄するのは機能の喪失であり、重複ログの整理ではありません。

正味の削減になる場合にのみインフラを置き換える

依存関係ポリシーに従ってください。パッケージを追加する前に、エンジンの最低バージョンで利用できる既存の依存関係と Node の組み込み機能を調べてください。置き換えによって削除できる実装と専用テスト、その保守コストと推移的なコスト、さらに接着コードで維持する必要がある残りの動作をすべて特定してください。

置き換えを損ないやすい不一致を検証してください。プロトコルの切り詰め、キャンセルと終了処理、設定された上限、決定論的なテスト用クロック、プラットフォームごとのパッケージ化、ソースとビルド済みエントリーポイントの違いを確認してください。フレーミングを実装するライブラリでも、サイズ制限を適用するために同じフレーミングを再構築する必要があるなら、単純化にはなりません。許容するエッジ動作の変更は、提案と関連テストに明記してください。依存関係の一般仕様を再検証する一方で、ハーネス固有のシムのテストを省略してはいけません。

記録、統合、検証

文章が対象範囲に含まれる場合は、dsh-prose-standard を使用します。コードの説明を繰り返す記述や、リモートで管理されている説明は削除しつつ、ローカルでの動作、タイミング、所有者、障害時の義務は維持します。影響を受ける README、JSDoc、モデルに表示されるカタログ、設定、スナップショット、生成ファイルは、それらを所有する変更に合わせて更新します。

重要な提案では、必須のメモのひな形である Problem、Proposal、Alternatives considered、Acceptance criteria、Risks を使用します。具体的な利用者の証拠、削減される保守コスト、手放す機能、観測可能な受け入れ条件を含めます。実装済みの決定には、代わりに実装済み形式を使用します。同じ決定について既存の担当者がいる場合はそのメモを更新し、候補数を維持するために重複するメモを作成しないでください。

新しいメモを追加するたびに、dsh-archive-agent-notes を通じて対象範囲を絞った置き換えの確認を行います。このワークフローが、保持、統合、三つ組の削除、凍結アーカイブの仕組みを担当します。コードの調査を行ったからといって、リポジトリ全体のメモ監査が必要になるわけではありません。一部のみ置き換えられる内容や、現在も有効な永続的、ワイヤー、互換性、または却下した代替案に関する義務は維持します。

別のブランチを取り込む際は、そのブランチの独立した差分を対象のベースと比較し、裏付けのある重複しない提案のみを移植して、重複する根拠は統合します。明確な権限または担当がない限り、別の PR をクローズしないでください。

Agent Note のみの作業では、pnpm run doc-sync、pnpm run lint、git diff --check を実行します。スキルやコメントを編集した場合は、該当するバリデーターも実行します。その他のチェックは、dsh-pre-push-checks に従って選択します。調査した領域、裏付けのある候補、重要な却下または保留、追加・統合・保持・削除したメモ、実際に実行したコマンドを報告します。調査範囲を広げている間はドラフト PR を使用し、検証していない検索を網羅的だったと説明しないでください。