assemble-ppmplugin

/assemble-ppmplugin

最終ステップです。ラベル（/generate-ppmplugin-manifestのmanifest.json）と、ビルドスキルで作成したバイナリをまとめて、単一の<name>.ppmpluginファイルにZIP圧縮し、ボックスに正しい項目だけが含まれていることを検証します。出力が納品物です。引き渡しやアップロードができるファイルです。ZIP圧縮する前に、マニフェストで宣言されたプラットフォームと、実際にビルドされたバイナリを照合するため、配布するバンドルが含まれていないプラットフォームを決して宣言することはありません。

このスキルが生成・検証するバンドルのレイアウトについては、shared/ppmplugin-format.md §1をお読みください。

このスキルで行わないこと

• マニフェストの作成やバイナリのビルドは行いません。前段のサードパーティ制御スキル（マニフェストとビルドスキル）のステージ済み出力を使用します。
• Dataverseへのアップロードやキャンバスアプリへの組み込みは行いません（ステージ3 — 延期）。
• バイナリのビルドは行いません。ビルドスキルでステージされたもの（/build-android-binaryのandroid/<Pascal>Plugin.dex、および／または/build-ios-binaryのios/<Pascal>Plugin.framework/）を使用し、存在するものをバンドルします。

---

ステップ1 — 共通ドキュメントと前提条件のブロックを読む

1. shared/shared-instructions.mdとshared/ppmplugin-format.mdを読みます。
2. 前提条件：jar（JDKに同梱）。表示用ブロック（shared-instructions §9.2）を出力します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Prereq check — /assemble-ppmplugin
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 🟢 ✓ jar (JDK) available
 🟢 1 check passed, 0 failed. Ready to proceed.

jarが見つからない場合は、BLOCKED: jar not found — install a JDK (JDK 17)を出力して停止します。

---

ステップ 2 — 宣言されたエントリーポイントとステージ済みバイナリを照合する（ゲート）

出荷するバンドルの manifest.json には、zip 内にあるバイナリのプラットフォームのみを、過不足なく宣言する必要があります。マニフェストは意図（ターゲットの選択）に基づいて作成されています。このステップで、それを実際の状態（実際にビルドされたもの）と一致させます。最終的なバイナリ一式を確認できるのはここだけなので、整合性の責任を担います。

1. ppmplugin/staging/manifest.json を読み取ります。存在しない場合は NEEDS_CONTEXT: manifest missing — run /generate-ppmplugin-manifest で停止します。出力ファイル名 <name>.ppmplugin に使う name を読み取ります（ファイル名にバージョンは含まれません。バージョンはマニフェストの version フィールドにあり、ラップパイプラインはそこから読み取ります。それでも成果物のレポートに表示するため、version も読み取ってください）。
2. 宣言済みプラットフォーム：entrypoints.android は存在しますか？ entrypoints.ios は存在しますか？
3. ステージ済みバイナリ：
   • Android：ppmplugin/staging/android/<dex> が存在します。ここで <dex> = entrypoints.android.dex です。
   • iOS：ppmplugin/staging/ios/<framework>.framework/ が存在します（.xcframework ではなく、フラットな .framework です — §5b）。ここで <framework> = entrypoints.ios.framework です。代わりに .xcframework がステージされている場合は、ゲート対象として提示してください。ラップ CI では取り込めないため、デバイススライス用のフラットなフレームワークを生成するために /build-ios-binary を再実行してください。
4. プラットフォームごとに照合します：

宣言済み	ステージ済み	アクション
はい	はい	出荷する ✓
はい	いいえ	不一致 → ゲート（以下を参照）
いいえ	はい	バイナリは存在しますが、マニフェストではルーティングされません。これを提示し、/generate-ppmplugin-manifest を再実行して宣言するか、そのまま除外するかを提案してください
いいえ	いいえ	このバンドルには含めません — 無視します

5. 宣言済みかつステージ済みのものが何もない場合は、NEEDS_CONTEXT: no built binary to ship — run a build skill first で停止します。

不一致ゲート（宣言済みだがステージされていない場合）。 不足しているバイナリを指すマニフェストを、決して黙って出荷しないでください。この状況は実際に曖昧です（考えが変わったのか、ビルドを忘れたのか判断できません）。そのため、AskUserQuestion で状況を提示して確認します：

"マニフェストでは <platform> が宣言されていますが、<platform> のバイナリがステージされていません。"

• 先に <platform> をビルドする — ビルドスキルを実行します（/build-android-binary、iOS の場合は /build-ios-binary（Mac 専用））[Skill ツール経由で呼び出してください — 説明するのではなく、実行してください]
• <platform> なしで出荷する — ステージ済みの manifest.json から entrypoints.<platform> を削除し、ビルド済みのプラットフォームを出荷します
• 停止

ユーザーが「なしで出荷する」を選んだ場合、続行する前にステージ済みの manifest.json を編集して、そのエントリーポイントを削除してください。このステップの後、マニフェストの entrypoints セットはステージ済みバイナリのセットと完全に一致します。

---

ステップ 3 — 最終検証

ppmplugin-format §4 の検証ルールを、照合済みのステージ済み manifest.json に対して再実行します（ステップ 2 または手作業で編集されている可能性があります）。また、出荷するプラットフォームごとに、次の点も相互確認します：

• Android：entrypoints.android.dex がステージ済み DEX ファイル名と完全に一致していること。
• iOS：entrypoints.ios.framework がステージ済みの …/<framework>.framework ディレクトリ名と一致し、その .framework/ にバイナリ、Headers/<framework>.h、Modules/module.modulemap、Info.plist が含まれていること（ラップ CI の要件です。詳細な確認は /audit-ppmplugin が行います。明らかに不足しているものがあれば、ここで指摘してください）。

検証に失敗した場合は、BLOCKED: manifest validation — <rule> で停止し、バンドルを生成しないでください。ローカルの互換性チェックに合格しない .ppmplugin は、アップロードできる状態ではありません。

---

ステップ 4 — Zip + 検証

Zip の前に： 出力先の ppmplugin/<name>.ppmplugin がすでに存在する場合は、黙って上書きしないでください。AskUserQuestion で確認します：置き換える［デフォルト］／既存のものを保持する（停止し、以前のバンドルには触れません）。置き換える場合にのみ Zip に進みます。

1. マニフェストと、ステップ 2 で出荷対象として照合したプラットフォームフォルダーのみを Zip にまとめます。ビルドディレクトリ（android-build/、ios-build/）が誤って含まれないよう、明示的に指定してください。jar（JDK）はディレクトリを再帰的に処理するため、iOS の .framework ツリーにも対応し、すべての OS で同じように動作します。異なるのはシェルの部分だけです（§5）。

   macOS / Linux（bash）：

   mkdir -p ppmplugin
   # list only the shipped platforms, e.g. `android` for Android-only, `android ios` for Both:
   ( cd ppmplugin/staging && jar cMf "../<name>.ppmplugin" manifest.json android ios )
   

   Windows（PowerShell）：

   New-Item -ItemType Directory -Force ppmplugin | Out-Null
   Push-Location ppmplugin\staging
   jar cMf ..\<name>.ppmplugin manifest.json android ios
   Pop-Location
   

   （-M = JAR マニフェストエントリなし。バンドル独自の manifest.json を使用します。対象プラットフォームを出荷しない場合は、引数リストから ios（または android）を削除してください。）上記で確認した置き換えるを選択した場合、以前のバンドルは上書きされます。

2. レイアウトを検証 — 一覧を出力し、照合済みのマニフェストと完全に一致することを確認します：

   jar tf ppmplugin/<name>.ppmplugin
   

   Android のみの場合、次の内容のみが含まれます：

   manifest.json
   android/<Pascal>Plugin.dex
   

   両方を含むバンドルには、ios/<Pascal>Plugin.framework/… のエントリも含まれます（フラットなフレームワーク — バイナリ + Headers/ + Modules/module.modulemap + Info.plist）。次の場合は、実際の一覧とともに BLOCKED: unexpected bundle contents を出力して停止してください：ビルドディレクトリが混入している（android-build/、ios-build/）、余分なファイルがある（.DS_Store、META-INF/）、ios/<…>.xcframework/ が含まれている（フラットな .framework である必要があります）、または宣言されたプラットフォームのバイナリが欠落している。バンドルに含めるのはマニフェストとエントリーポイントのバイナリのみです。それ以外は含めないでください。

---

ステップ 5 — 報告

.extension-state.md の ## ppmplugin (third-party controls) ブロックを更新します：Bundle: <name>.ppmplugin assembled <ISO timestamp> (v<version>, platforms: <android[,ios]>)。成果物を、見える fenced ブロックとして出力します（shared-instructions §9.1、情報形式）：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 .ppmplugin ready
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ppmplugin/pen-input.ppmplugin   (v0.1.4, Android-only)
 Contents:
   manifest.json
   android/PenInputPlugin.dex
 Next: /audit-ppmplugin — verify the bundle is upload-ready before shipping it.
       (Then: deploy the dispatcher PCF via /publish-pcf-companion, and upload the
        .ppmplugin via the wrap wizard — Stage 3, not yet a skill.)

次に、AskUserQuestion で次のステップを提示します（shared-instructions §9.1 — 選択されたスキルは Skill ツールで呼び出し、実行してください。説明だけで終わらせないでください）：

• /audit-ppmplugin を実行する（推奨 — 最終アップロード準備ゲート：バリデーターのルール + DEX SDK 漏洩スキャン + iOS フレームワークのチェック）
• /publish-pcf-companion を実行する（ディスパッチャー PCF を Power Platform 環境にデプロイする）
• このままにする — まずバンドルを確認する

/assemble-ppmplugin が /generate-ppmplugin の内部ステージとして実行される場合、オーケストレーターが /audit-ppmplugin を自動的に呼び出すため、このゲートはスキップされます。バンドルのパスを含めて DONE を返してください。