plugin-release

English | 简体中文

plugin-release

開発・テスト済みのプラグインを安全にリリースします。公開は一方向の操作です。実際に公開またはタグをプッシュする前に、計画を示し、確認を得てください。このスキルではバージョン番号を決定せず、自動でバージョンを上げることもありません。

Step 0: 対象バージョンとリリーストラックを確認する

リリーストラック	対象	主な事実
GitHub から直接インストール	dsh plugin --profile <p> add github:owner/repo	利用者はデフォルトブランチの HEAD を解決します。公開とは main へのプッシュを意味します。プッシュ前に完全なゲートを実行してください
npm レジストリ	npm publish	公式リリース系列のみが対象です。alpha／rc を接頭辞に持つ @deepseek-ai/* のバージョンは npm に公開されているとは限りません。公開前に npm view <pkg> versions で確認してください
ハブへの掲載	ハブカタログに登録	登録は独立した操作であり、パッケージの検証に代わるものではありません
コレクション	メンバープラグインをパック成果物に同梱	管理元のコレクションリポジトリ独自の手順に従ってください

未公開のコホート（たとえば、npm に公開されなかったコホートバージョン。alpha.1 は GitHub のみ、alpha.2 から alpha.4 は alpha dist-tag で公開済み）は、references/publish-playbook.md のオーバーライド手順に従います。npm に存在しないバージョンを探したり、そのためにパッケージマネージャーを切り替えたりしないでください。

Step 1: 成果物をパックして検証する

1. リポジトリで使用されている単一のパッケージマネージャーとロックファイルを使用します（package-lock.json → npm、pnpm-lock.yaml → pnpm）。
2. 完全なゲートを実行し（Step 3 を参照）、その後 npm pack ／ pnpm pack を実行します。
3. 展開して検証します。files に実行時のすべての相対インポートとアセットが含まれていること、成果物に .ts の残存ファイルがないこと、cordis.patch.yml ／ dsh.plugin.json ／ SKILL.md などのマニフェストファイルがすべて含まれていることを確認します。
4. tarball を隔離プロファイルにインストールし、利用時の検証を行います（プラグインの行が dsh --profile compat --dump-config に表示され、ツールが実際に登録されて実行されること）。

Step 2: バージョン依存関係のベースライン（alpha 時代）

• devDependencies では型のベースラインとしてnpm リリース系列（現在は 0.1.1-rc.2）を使用します。これにより、どのマシンでも npm install 後に公開リポジトリの型チェックが通ります。
• peer 範囲には広い範囲（<0.2.0 など）を指定し、未公開の alpha／rc をカバーします。
• コードをローカルハーネス（GitHub タグ）と npm リリース系列の両方に対応させる必要がある場合は、二重互換性パターンを使用します。npm リリース系列の型が要求する形状を維持しつつ、alpha のランタイムセマンティクスは変更しません（プレイブックの「二重互換性パターン」セクションを参照）。
• コミットする package.json にローカルの絶対パス（junction／file:）を記述しないでください。

Step 3: リリースゲート（段階ごとに実施し、次の段階に進む前に下位の段階を通過する）

1. 依存関係の解決：ロックファイルの変更が想定どおりで、コホートが混在していないことを確認します。
2. 静的検証：型チェック + プラグインのテスト + ビルド。
3. 実マウント：エントリを有効にし、保留中のサービスがない状態で、対象ホストを隔離プロファイル上でコールドブートします。プロファイルは正確な DSH タグに固定してください（可変の master／main を受け入れテスト対象として扱ってはいけません）。Web Client プラグインでは、ホストが提示するリソース（ブートマニフェスト／ブートリストのバンドルエントリ）にアクセスできること、バンドルが正常に登録されること、DOM のマウントが完了すること、ページエラーがないことも検証する必要があります。--dump-config を見るだけではこの段階は完了しません。
4. 動作：主要な経路を 1 つ実際に実行します（ツールプラグインの場合は、1 件のメッセージ → ツール → 応答、または同等の専用フロー）。
5. ラッパー：終了コードと stdout／stderr の帰属を検証します。

ステップ 4：リリースのセマンティックゲート（チェックに失敗した場合は公開を停止）

1. GitHub Release のタグは v${package.json.version} と一致している必要があります；
2. バージョンにプレリリースサフィックスが含まれるか（- の後から + のビルドメタデータの前までの部分）は、GitHub Release のプレリリース状態と一致している必要があります；
3. プレリリースは、プロジェクトで宣言された latest 以外の dist-tag にのみ公開できます（名前はプロジェクト側で選択し、next や alpha などを使用できます。このスキルでは特定の名前をハードコードしません）。サフィックスのない安定版のみを latest に公開します；
4. 安定版を公開する前に、現在の latest（npm view <pkg> dist-tags.latest）を照会し、バージョンが既存の latest より低い場合は、latest が低いバージョンに戻るのを防ぐため公開を拒否します。

ステップ 5：公開とロールバック

• 公開前：クリーンなコミットとタグを用意し、ロックファイルと構成ベースラインのハッシュを記録します；
• 公開後：コンシューマーとして一度再インストールし、スモークテストを実施します；
• ロールバック：リリースを取り消す（タグを削除する／古いコミットを再指定する）方法を優先します。問題を覆い隠すために「どちらの側でも動作する」パッチを公開しないでください；
• 未公開コホート向け CI については、プレイブックの「CI とリリースゲート」セクション（コホートストアのキャッシュ、NPM_PUBLISH_ENABLED スイッチ）を参照してください。

安全上の境界

• 公開／タグのプッシュ／ハブへの登録書き込みを行う前に、計画を提示して確認を得てください。バージョンを自動で上げないでください；
• 認証情報、.npmrc の内容、セッションログ、プライベートパスを含む成果物は公開しないでください；
• パッケージマネージャーを切り替えたり、別のロックファイルを書き換えたりしないでください。失敗した場合は、この実行が所有するパスのみをロールバックし、残存物を報告してください。

参考資料

ファイル	内容
references/publish-playbook.md	未公開コホートのインストール、デュアル互換性パターン、CI／リリースゲート、実際の落とし穴の一覧、ロールバック手順
references/profile-dependency-management.md	プロファイルのインストール／更新手順：GitHub 依存関係のロックキャッシュ、パッケージ名変更時の3か所同期、ジャンクションのクリーンアップ、ホストアップグレードのリンク