AI-Scarlett/build-dsh-plugin

DSHプラグインの構築

このワークフローを使用して、DSHプラグインのアイデアを、Harness自体を変更またはシャドウすることなく、標準的なバンドルに変換します。

ユーザーブリーフの正規化

新しいプラグインリクエストごとにintake.mdを読んでください。通常の言語、簡潔な中国語のブリーフ、またはplugin-brief.template.jsonの構造化JSONテンプレートのいずれかを受け付けます。

ソース生成前に必要なセマンティックファクトは3つだけです：

1. 現在のユーザーの問題
2. 期待されるユーザーアウトカム
3. 少なくとも1つの観測可能な受け入れ基準

名前、パッケージID、アーキテクチャ候補、リスククラス、プロジェクト構造、テスト、安全なデフォルトを推論します。ユーザーが好みを持たない限り、Host API、Cordisエントリ、スキーマ、ビルドツール、テスト戦略を設計するようユーザーに要求しないでください。

オプションフィールドがない場合、デフォルトはソース生成のみ、標準DSHバンドル、読み取り専用動作、実際のプロファイル変更なし、再起動なし、外部ネットワーク/プロセス/アカウント/デバイスなし、資格情報なし、ローカルのみの公開、公開なし、E3使い捨て受け入れです。マーケットプレイス互換のパッケージ構造を持つ再利用可能なDSHバンドルをデフォルトで構築しますが、DSH STOREへの送信または変更を推論してはなりません。すべてのデフォルトを仮定として明記します。No publicationは認可のデフォルトであり、恒久的な禁止ではありません：明示的に認可され、適切にライセンスされ、内部的に一貫した固定リリースは、ウェブサイトから配布されるか、マーケットプレイスに提案される場合があります。

プロダクトのアウトカムまたはリスク境界を実質的に変更する質問のみをしてください。問題、アウトカム、または受け入れ基準がない場合は生成をブロックします。ターゲットプロファイル、変更範囲、資格情報所有者、LAN/インターネットセキュリティ、または実際のデバイス/アカウントがない場合は、対応する実際の操作のみをブロックします。インターフェースが抽象的なままであれば、安全なソーススキャフォールドをブロックしません。

JSONブリーフが利用可能な場合は、決定論的正規化ツールを実行します：

node scripts/normalize-brief.mjs /absolute/path/to/plugin-brief.json
node scripts/normalize-brief.mjs /absolute/path/to/plugin-brief.json --json

正規化されたステータスがREADYまたはREADY_WITH_ASSUMPTIONSであり、要求されたモードがbuild-sourceである場合、別の広範な確認ラウンドなしにフェーズ0〜6に進みます。個別に認可され完全に指定されていない限り、リリース、実際のプロファイル変更、再起動、資格情報、デバイス、または公開露出の前に停止します。

契約の確立

読み取り専用で開始します。リポジトリの指示、ターゲットDSHバージョン、公式プラグインドキュメント、関連する場合にのみアクティブプロファイル、および1つの現在の標準プラグインの例を検査します。古いプロジェクトからのAPIまたはパッケージ契約を想定しないでください。

常にこれらのルールを適用します：

• DSHバンドルを構築します。デスクトップアプリやDSHのフォークではありません。
• DSHソースツリーまたは@deepseek-ai/*パッケージを決して変更しないでください。
• 公式プラグインインベントリを無効化、置換、またはシャドウしないでください。
• Loader/FiberミューテーションAPIを決して呼び出さないでください。パブリックHostサービスとバンドル構成を使用してください。
• パッケージ変更には公式DSH CLIを使用してください。固定引数配列を渡します。シェルコマンド文字列を決して構築しないでください。
• テストは使い捨てのホーム/プロファイルに保管してください。実際の~/.dshに対してテストを決して記述しないでください。
• 資格情報、完全なユーザーファイル、注入されたシステム/プラグインコンテキスト、モデル推論、プライベートパスをログやクライアントを通じて公開しないでください。
• 計画、コード補完、パッケージリリース、プロファイルインストール、ランタイム受け入れ、外部/デバイス受け入れを別々の状態として維持します。
• プラグイン準備完了、カタログ候補準備完了、Registry PR/CI、マージされたカタログ、公開マーケットプレイスの可視性、プロファイルインストールを別々の状態として維持します。
• 正規ツール出力、モデル向けレンダリング、プロバイダー中立的カードインテント、オプションのカスタムClientレンダリングを別々の契約として維持します。

実装またはインストールの前にboundaries.mdを読んでください。そのファイル内のハードブロッカーはすべてのスコアを上書きします。 モデルTool、presentCall、presentResult、presentationMeta、またはカスタムToolカードを実装する前にcard-contract.mdを読んでください。

重要な決定を説明する

決定ロジックなしでルールリストを出力しないでください。各アーキテクチャ、許可、変更、リリース、または受け入れの決定について、以下を記録します：

1. 目的：決定が制御する障害またはアウトカム。
2. 根拠：DSHメカニズムまたは現在の脅威モデルがそれを必要とする理由。
3. 利点：何がより安全、よりシンプル、より互換性があり、または検証しやすくなるか。
4. コスト：実装負担、UX摩擦、パフォーマンスコスト、機能損失、または運用遅延。
5. 適用可能性：決定が適切である条件。
6. 代替案：実行可能なオプション、それらが却下された理由、およびそれらを再検討するタイミング。
7. 手順：具体的なステップ、所有者、入力、出力、およびロールバック動作。
8. エビデンスゲート：進捗に必要な観測可能な証拠と作業を停止する条件。

プラグインの計画、レビュー、または説明を行う際はdecision-guide.mdを読んでください。分析なしに好みのパターンをコピーするのではなく、その決定カードを使用してください。

ワークフローを実行する

完全なステージゲートプロセスと必要な成果物についてはworkflow.mdに従ってください。類似のプラグインが以前にそれを通過したという理由だけでステージをスキップしないでください。DSHバージョン、プロファイル構成、依存関係、および外部サービスは変動する可能性があります。

1. ホスト適合性を証明する

ターゲットホスト、拡張シーム、要求されたユーザーアウトカム、状態変更、外部依存関係、および受け入れ面を特定します。

プロジェクトがObsidian、VS Code、ブラウザ拡張機能、MCPのみ、または証明されたDSHバンドル契約のない別のランタイムをターゲットとしている場合は、ホスト不一致を報告して停止します。互換性のあるホストまたは意図的にスコープされたアダプタを提供します。隣接プロジェクトに迂回しないでください。

ホスト契約レコードとアーキテクチャ比較を作成します。ゲート：compatible、adapter-required、またはincompatible。これを暗黙の散文のままにしないでください。

2. リスクを分類する

scorecard.mdから1つのクラスを割り当てます：

• R0：読み取り専用メタデータ/UI。
• R1：Hostツール/サービスまたはユーザー所有のプラグイン状態。プロファイルライフサイクルへの書き込みはありません。
• R2：外部プロセス、ネットワーク、資格情報、またはデバイスブリッジ。
• R3：プロファイルライフサイクル、再起動、リモートコントロール、または広範な管理。

不確かな場合はより高いクラスを使用します。コーディング前に非目標と禁止面を記録します。

アセット、アクター、信頼境界、書き込み面、障害影響、最小エビデンスレベル、およびクラスを選択した理由を名前付けるリスクレジスタを作成します。

3. 標準パターンを選択する

• Hostのみのバンドル：パブリックCordisサービス/ツールを公開し、1つ以上の一意のパッチ行を提供します。
• Host + Client：Browserコードを分離しておきます。window.__ModuleLoader__.load()とスロットで登録します。BrowserコードはHost/Nodeモジュールをインポートしてはなりません。
• オプションのWebルート：ctx.inject(['webServer'], ...)で登録を遅延させます。ヘッドレス/Webなしプロファイルでも起動可能でなければなりません。
• スキルアダプタ：分離されたSkillファイルをマウントします。外部ランタイム、拡張機能、または資格情報をサイレントにインストールしないでください。
• ApiProxyブリッジ：許可リスト、編集、認証、境界付き解析、およびフェイルクローズ転送セキュリティを使用して、狭い公開リモート面を適応させます。
• ライフサイクルマネージャ：すべてのプロファイル変更をR3トランザクションとして扱い、以下のミューテーションプロトコルを使用します。
• Toolカード契約：プロバイダー中立的なpresentCall/presentResultレンダリングインテントを優先します。検査済みの組み込み語彙がアウトカムを表現できない場合にのみ、プラグイン所有のToolに対してカスタムClient Slotカードを使用します。

dsh.bundle.patch、パッケージ解決可能なcordis.patch.yml、一意のエントリID、明示的なファイル、バージョン、ライセンス、およびビルド契約を持つバンドルマニフェストを作成します。後のパッチレイヤーは行の完全なconfigを置き換えることを覚えておいてください。ディープマージは行いません。

選択が権限、プロセス境界、インストール動作、またはユーザーエクスペリエンスに影響を与える場合は、少なくとも2つの妥当なパターンを比較します。利点とコストを記録します。以前のプロジェクトで使用されたという理由だけでアーキテクチャを選択しないでください。

4. 最小権限を実装する

検査済みのDSHバージョンですでに提供されているパブリックサービスを使用します。必要なシームがない場合は停止し、コアにパッチを当てる代わりにアダプタまたはアップストリームの変更を提案します。

読み取り専用の検出とドライラン/プレビューAPIを優先します。書き込み機能は個別に有効にします。ビジネスロジックの前にスキーマとサイズ制限を検証します。不正な形式のプロファイル、曖昧なパス、未知の公式コンポーネント、古い状態、リプレイ、同時変更、および欠落したエビデンスを拒否します。

すべてのモデルToolについて、正規出力、モデル向けレンダラー、保留中のカード、完了したカード、永続的なプレゼンテーションメタデータ、境界/編集、ジェネリックフォールバック、およびライブ/リプレイのエビデンスを記録します。プレゼンターは決定論的であり、I/O、クロック/ランダムアクセス、セッション読み取り、または追加の権限を必要とする作業を行わないでください。資格情報、完全なプライベートファイル、モデル推論、または無制限の引数をカードに入れないでください。

繰り返し発生する障害パターンについては、problem-playbook.mdを読んでください。

各データソース/アクション、所有側、許可された呼び出し元、編集、サイズ/レート制限、障害モード、およびテストを含む権限マトリックスを作成します。ユーザーアウトカムとテストのない権限は削除されます。

5. ミューテーションプロトコルを適用する

プロファイル/パッケージ/再起動の変更については、1つの操作に対して正確に1つの新しい型付き計画を作成します。これには以下が含まれます：

1. 操作とターゲットプロファイル
2. 不変のパッケージ/ソースID
3. 正確なファイル範囲と期待されるプリコンディションハッシュ
4. コマンドargvとワーキングディレクトリ
5. バックアップ場所とロールバック手順
6. ポストコンディションとヘルスチェック
7. 正確に1つの確認フレーズ
8. 有効期限と単一使用ID

計画を表示し、操作ごとの正確な確認を待ちます。不一致、期限切れ、同時変更、または以前の使用で無効にします。書き込み前にバックアップし、アトミックにコミットし、構成とランタイムヘルスチェックを実行し、障害時にはロールバックします。リポジトリリリースはローカルプロファイル更新を許可しません。

確認の摩擦とトランザクションメカニズムを明示的なコストとして扱います。R3ではこれらのコストを受け入れます。代替案はユーザー状態のサイレントで回復困難な破損だからです。純粋なR0読み取りにはミューテーションプロトコルを課さないでください。

6. エビデンスの梯子を登る

現在のエビデンスでのみ進みます：

• E0：アイデアまたは計画。
• E1：静的な構造/ソースレビュー。
• E2：自動化されたユニット/契約/障害テスト。
• E3：使い捨てプロファイルインストール、--dump-config、起動、およびAPIスモーク。
• E4：個別に確認された実際のプロファイルバージョン、プロセス/ポート、公式インベントリ/API、および可視UIリードバック。
• E5：外部/公開/デバイス受け入れと障害回復またはロールバックのエビデンス。

より低いレベルからより高いレベルを推論しないでください。UIスクリーンショットはロールバックを証明しません。HTTP 200は可視UIを証明しません。インストール成功は再起動の健全性を証明しません。シミュレータ出力は実際のデバイスを証明しません。

Toolカードの場合、E2には決定論的プレゼンター、不正リプレイ、編集、境界、トランケーション、ジェネリックフォールバックテストが含まれます。E3には分離されたDSHランタイムでのライブと永続化リプレイのパリティが含まれます。ユーザーのプロファイル内の可視カード動作はE4のままです。

各機能ごとにエビデンスマトリックスを作成します。ハッピーパスだけでなく、ネガティブおよび回復のエビデンスを含めます。スコアは準備状況をランク付けします。権限を付与したり、ハードゲートを置き換えたりすることはありません。

7. リリースとインストールを別々に行う

リポジトリリリース前に、パッケージバージョン、README、カタログエントリ、不変のインストールアンカー、テスト、および固定ソースメタデータを同期します。Gitソースの場合、ビルドされた成果物を出荷するか、自己完結型のprepareスクリプトを宣言し、pnpm allowBuildsを開示します。完全なコミットSHAを固定します。

リポジトリチェック、ソース検証、およびパックドライランを実行します。マージ後にリモートコミットと公開アセットを検証します。その後停止します。新しい確認済みミューテーションプランでのみ実際のプロファイルを更新し、承認されたメカニズムを通じて再起動し、解決されたバージョンとランタイム状態を読み戻します。

2つの別々のレポートを作成します：リポジトリリリースのエビデンスとプロファイル/ランタイム受け入れのエビデンス。2番目のレポートがない場合は、Profile unchangedまたはProfile unverifiedと明記します。

8. 再利用可能なプラグインをDSH STORE対応にする

再利用可能なサードパーティDSHプラグインを構築するとき、DSH STOREの既存リポジトリを評価するとき、またはカタログエントリを準備するときは、marketplace.mdを読んでください。

提出まで待ってからリスト非互換性を発見しないでください。最初のスキャフォールドから、一意のパッケージ/カタログ/エントリIDを予約します。リポジトリ、バージョン、ライセンス、安全なdsh.bundle.patch、パッケージ相対Patch、ランタイム/ビルドファイル、ライフサイクルスクリプト、権限、依存関係、互換性のエビデンスを宣言します。すべてのSTORE評価の開始時に、node scripts/official-dsh-releases.mjsを実行し、その公式の最新3つのウィンドウを使用します。記憶されたウィンドウを再利用しないでください。リゾルバーは最もアクティブなnpm latest/alpha/beta/rcチャネルに従い、nextのみおよび非推奨バージョンを除外し、無効な権限でフェイルクローズします。観測された2026-09-02のウィンドウは0.1.2-alpha.2、0.1.2-alpha.3、0.1.2-alpha.4ですが、これはエビデンスであり、恒久的な定数ではありません。解決されたウィンドウ内のすべてのリリースに対して、正確なcompatibility.dshReleasesとそれに対応するcompatibility.dshOperationsのレコード（インストール、起動、アンインストール、ロールバック）を保持します。過去のキーは残してもかまいませんが、未知のメタデータは推測ではなく未知のままにしておきます。

STORE検出と信頼できるインストールを物理的かつ論理的に分離したままにします。registry/candidates.json内のレコードは検出専用であり、パッケージ/インストール/権限の契約を負わず、installable: falseに正規化され、許可されたアクションはありません。それは、別個の固定ソース、バンドル、ライセンス、権限、互換性、およびエビデンスレビューの後にのみregistry/catalog.jsonに移動できます。プロモーション、推奨、スポンサーシップ、スター、またはスクリーンショットは、権限やインストール契約を付与しません。