plugin-workflow

DSH プラグインのライフサイクルを調整する

ワークフローコントローラーとして動作してください。実行前にユーザーが成果と任意の証明方法を選べるようにし、選択した各ステージを担当する Skill に割り当て、単一のフェーズ台帳を維持して、証拠に基づいたレポートを 1 つ返してください。担当する Skill の詳細なルールをこの Skill にコピーしないでください。

実行前にメニューを表示する

ユーザーがワークフローを明示的に選択していない場合は、いずれかのフェーズを実行する前に、以下のワークフローと機能の表を表示してください。ユーザーの言語に合わせ、health-check を初回実行におすすめとして示し、選択を待ってください。おすすめは選択ではありません。暗黙に health-check を既定として選んだり、検出を開始したり、機能を実行したりしないでください。

ワークフロー番号、ワークフロー ID、または曖昧さのない自然言語での成果指定を受け付けてください。たとえば 3 + docker-smoke + browser-check のように、同じ返信で機能を追加または削除できるようにしてください。選択した機能のうち、どれが読み取り専用で、どれが後に確認境界を越えるかを簡潔に示してください。

同梱のプランナーは、同じ決定論的なメニューを表示し、読み取り専用のまま動作します。

node <plugin-workflow-skill>/scripts/plan-workflow.mjs
# Equivalent explicit form:
node <plugin-workflow-skill>/scripts/plan-workflow.mjs --menu

ユーザーがすでに成果を選択し、十分なコンテキストも提供している場合は、その選択を維持し、メニューを再表示せずに続行してください。

読み取り専用の検出を続ける

選択内容を具体化するのに必要な範囲に限ってコンテキストを調べてください。

1. リポジトリの指示を読み、変更を加えずに Git のステータスを確認します。
2. 対象が DSH モノレポ、外部プラグインのソースリポジトリ、インストール済みプラグイン、またはパッケージ化されたアーティファクトのいずれかを特定します。
3. プラグインのソース ID、現在の DSH バージョン、要求された対象バージョン、パッケージマネージャー、利用可能なスクリプト、プラグインのサーフェス、既存の命名宣言を記録します。
4. 不明な入力には unknown と記録します。検出中に依存関係をインストールしたり、パッケージスクリプトを実行したり、コンテナーを起動したり、ファイルを編集したり、リモートレジストリに問い合わせたりしないでください。

ワークフローを 1 つ選ぶ

ワークフロー	成果	既定のステージ
health-check	プラグインとアップグレードリスクに関する読み取り専用レポート	検出、任意の DSH 監査、7 つのタッチポイントのスキャン
upgrade-target	インストール済みプラグインを明示的なバージョンにアップグレード	検出、アップグレード、静的チェック、ロールバック記録
compatibility-migration	プラグインのソースを正確な DSH 対象バージョンに適合	検出、DSH 監査、7 つのタッチポイントの移行、静的テストと実行時テスト
test-only	既存のソースツリーまたはアーティファクトを検証	検出、選択したテストレベル、レポート
naming-registry	識別子を検証し、レビュー済みのクラウド登録を確認。任意で ID を登録	検出、オフラインでの命名確認、レジストリへの問い合わせ、任意の登録
package-release	リリースを準備し、任意で公開	検出、必須のテストゲート、パッケージ化、利用者向けスモークテスト、任意の公開
full-lifecycle	移行、検証、命名、パッケージ化を行い、任意で公開	該当するすべてのステージを依存関係の順に実行
runtime-debug	Web Client の実行時動作を診断して修正	実行時の診断と修正、静的テスト、機能テストとブラウザでの証明、ロールバック
heavy-dependency	遅延読み込みされる Web Client 依存関係を統合	統合、静的テスト、機能テストとブラウザでの証明、ロールバック、パッケージの検査
fleet-sweep	アップグレードしたホストで、インストール済みプラグイン全体を一括調査	静的および稼働中のプラグイン一括調査、プラグインごとの修正とリリースのループ

runtime-debug と heavy-dependency には web-client サーフェスが必要です。これらは移行への機能として追加することもできます。fleet-sweep にサーフェスの制約がないのは、Web Client プラグインとロジックのみのプラグインが混在するためです。また、アップグレードしたホストを実行した後、修正済みの各プラグインをコミット、タグ付け、プッシュするため、3 つすべての確認境界を越えます。読み取り専用の調査には health-check を使用してください。症状の診断を求められただけでは、修正ワークフローを選択したことにはなりません。

続けて、ユーザーがこれらの機能を追加または除外できるようにしてください。ユーザーが示した成果を証明できる最小限のセットをおすすめし、おすすめした項目のうち、まだ選択されていないものを明示してください。

能力	選択肢	デフォルト
DSH バージョン互換性監査	dsh-audit	互換性移行ではオン。それ以外はオフ
7 つのタッチポイントを対象としたプラグインスキャン	touchpoint-scan	ヘルスチェックと移行ではオン
型チェック、単体テスト、ビルド	static-tests	ソース変更後およびパッケージ化前はオン
正確なバージョンでの Docker コールドスタート	docker-smoke	Docker が利用可能な場合、移行およびリリース候補ではオン
実際の機能パスを 1 つ検証	functional-probe	移行およびリリースではオン
ブラウザー検証	browser-check	Web Client または UI のサーフェスに限りオン
オフラインでの命名宣言の検証	naming-local	naming-registry および新しい外部プラグインではオン。それ以外はオプトイン
クラウド中央レジストリの検索	registry-query	naming-registry ではオン。それ以外はオプトインで読み取り専用
クラウド中央レジストリへの ID 登録	registry-register	オフ。ローカルエントリの準備ではレジストリのチェックアウトに書き込み、PR の送信は外部公開です
ロールバックのリハーサルまたは手順	rollback	すべての書き込みワークフローで手順を用意。リハーサルはオプトイン
パッケージアーティファクトのビルドと検査	package-artifact	パッケージ／リリースおよびライフサイクル全体のワークフローではオン
アーティファクトまたはリリースの公開	release	外部リリースの明示的な意図がない限りオフ
Web Client のランタイム動作の診断と修正	runtime-debug	選択されない限りオフ。静的検証、機能検証、ブラウザー検証による証拠とロールバックが必要
重いブラウザー依存関係の統合	heavy-dependency	選択されない限りオフ。同じ検証による証拠に加え、パッケージの検査が必要
ホストのアップグレード後に、インストール済みプラグイン群を一括検査	fleet-sweep	選択されない限りオフ。リポジトリへの書き込み、ランタイム、外部公開の確認が必要

ユーザーが選択したら、同梱の読み取り専用プランナーで選択を正規化します。別のツールで入力 JSON を生成する必要がある場合は、references/workflow-selection.schema.json を参照してください。

node <plugin-workflow-skill>/scripts/plan-workflow.mjs \
  --workflow compatibility-migration \
  --include registry-query \
  --exclude browser-check \
  --surface ordinary-plugin

自動化には --format json を使用するか、スキーマに従った永続化済みの入力には --selection <selection.json> を使用してください。選択を指定せずにプランナーを呼び出すと、デフォルトの計画は作成されず、メニューが表示されます。プランナーは競合と必須の依存関係を検証し、決定的なフェーズ ID と確認境界を出力しますが、選択されたフェーズは実行しません。その出力は初期台帳として扱い、ユーザーの承認とみなさないでください。

naming-registry のデフォルトでは、読み取り専用の registry-query の後で停止します。registry-register が暗黙に選択されることはなく、リポジトリへの書き込みと外部公開にはそれぞれ個別の境界があります。ユーザーはオフラインのみの実行のために、registry-query を明示的に除外できます。クエリを予約とみなしたり、ローカルプラグインの使用に登録が必須だとみなしたりしないでください。ローカルプラグインと中央レジストリでは表示名が同じ場合があります。競合する可能性があるのは、同一のランタイムサーフェス上にある具体的な識別子だけです。命名の担当者は、クエリ完了時にそれらの完全一致とインデックスの SHA-256 を報告する必要があります。

フェーズ台帳を作成する

実行前に、選択されたステージまたは依存関係上必要なステージごとに 1 行作成します。

フェーズ	能力	担当	ステータス	証拠またはブロッカー
P01	検出	plugin-workflow	selected	対象とソースの識別情報

ステータス値には、以下のみを使用します。

• selected：選択済みで、まだ完了していない状態です。
• completed：証拠を伴って完了した状態です。
• blocked：試行したか、実施が必須だったものの、続行できない状態です。
• skipped：該当するものの、意図的に実施しなかった状態です。
• not_applicable：検出されたプラグインサーフェスまたはワークフローに関係しない状態です。

利用できないチェックや選択されていないチェックを、completed にしないでください。あるフェーズがブロックされた場合は、依存するフェーズにも依存関係上の理由を添えて blocked または skipped を設定し、独立していて許可されたフェーズのみ続行してください。

各ステージを担当者に割り当てる

ステージを実行する前に、担当する Skill を読み込み、その手順に従ってください。担当者が利用できない場合は、そのフェーズを blocked としてマークしてください。実装を記憶に頼って再現してはいけません。

ステージ	担当する Skill	境界
インストール済みバージョンの更新またはソース互換性の移行	$plugin-upgrade	まず調査し、設定、依存関係、ソースの変更について承認を確認します
新しいプラグインコード、オフラインでの名前付け、またはレジストリへの照会	$plugin-write	対象 Harness およびレジストリの契約に厳密に従います
静的、ランタイム、Docker、機能、またはブラウザーによる検証	$plugin-test	必要十分なレベルを選択し、証拠を保持します
パッケージ、リリースゲート、公開、リリースのロールバック	$plugin-release	公開先と承認を確認します
DSH ホストのバージョン間の証拠	$dsh-upgrade-audit	生成された証拠をプラグインのソース変更から分離します
Web Client のランタイム診断と修復	$plugin-runtime-debug	正確なホストの契約を確立し、失敗する操作を再現します
遅延読み込みされるブラウザー依存関係の統合	$plugin-heavy-dep	チャンクの読み込み、ホストルート、フォールバック、マークアップの処理を担当します
ホストのアップグレード後に行う全プラグインの一括調査と、プラグインごとのリリースループ	$plugin-fleet-sweep	アップグレード済みのホストで検証し、プラグインを一度に 1 つずつ修正してリリースします。一括コミットは行いません

フェーズごとに担当者は 1 つにしてください。ランタイムのデバッグと依存関係の統合が重なる場合は、診断した契約を記録し、競合する書き直しを始めるのではなく、統合の担当者がそれを引き継ぐようにしてください。選択した対象バージョンとソース ID は、担当者間で共通して使用します。後続の担当者がソース、依存関係、またはパッケージアーティファクトを変更した場合は、それらの入力に依存していた先行の検証を無効とし、再実行してください。

ステージは依存関係の順に実行してください。

1. 調査とソース ID の確認。
2. 選択されている場合は DSH 監査。
3. アップグレードまたは実装の変更。その後、選択されているランタイム修復または依存関係の統合。
4. オフラインでの名前付けと、選択されたレジストリへの照会（naming-registry のデフォルト）。
5. 静的テスト。
6. Docker、機能、ブラウザーによる証明。
7. リリースの準備とアーティファクトの検査。
8. 外部登録または公開。

後続で選択されているステージの必須ゲートとして担当 Skill が指定している場合を除き、選択されていないステージはスキップしてください。その場合はゲートを台帳に追加し、必要な理由を説明したうえで、実行前に必要な確認を得てください。

3 つの境界をまたいでも承認を維持する

予定している操作を境界ごとにまとめ、ユーザーの依頼および優先度の高い指示と照らし合わせて確認してください。明示的に承認された範囲は、別の Skill に引き継ぐ際も同じ範囲に適用されます。担当者が変わったというだけで、再確認を求めてはいけません。生成された計画によって承認が与えられることはありません。また、ソース編集の承認は公開を暗黙に承認するものではありません。必要な操作がすでに与えられた承認の範囲外である場合に限り、確認を求めてください。

1. リポジトリへの書き込み：ソース、設定、マニフェスト、ロックファイルを編集する前に、対象ファイル、変更内容、ロールバックの範囲を明示します。
2. 依存関係とランタイムの実行：インストールまたは重要なランタイムテストを行う前に、パッケージマネージャーのコマンド、ライフサイクルスクリプトのリスク、コンテナー、サービス、ブラウザー、認証情報、生成される想定出力を明示します。読み取り専用の通常の Git 操作やファイル検査には確認は不要です。
3. 外部への公開：コミット、タグ、レジストリの PR、npm アーティファクト、Hub またはコレクションの変更について、正確な公開先と送信内容を特定し、その操作がユーザーの承認範囲内であることを確認します。

選択されたフェーズが複数の境界にまたがる場合は、各境界に関わる操作が実行可能になった時点で、それぞれを確認してください。フェーズを完了するためだけに、秘密情報を要求または開示してはいけません。

証拠を記録して報告する

失敗や明示的なスキップを含め、各フェーズの終了後に台帳を更新します。正確なバージョン、ソース SHA、コマンド、終了コード、レポートのパス、未確認の境界を記録します。終了前に、選択したすべての機能に最終ステータスが設定されていることを確認します。

次の項目を含むレポートを1件提出します。

1. ワークフローと機能の選択内容
2. ソースと対象の識別情報
3. 最終フェーズの台帳
4. 実施した変更と作成したコミット
5. テストとレジストリの証拠
6. ブロックされた境界、スキップした境界、未検証の境界
7. このワークフローが管理するパスに限定したロールバック手順
8. 公開状態。ローカル検証、レビュー済みのレジストリ一致なし、レビュー済みの登録、リリース済みアーティファクトを明確に区別します。

部分的なコールドスタートを機能互換性として要約したり、レジストリに一致する項目がないことを予約済み ID として示したり、準備済みのアーティファクトを公開済みとして示したりしないでください。