publish-pcf-companion

/publish-pcf-companion

サードパーティ製の .ppmplugin コントロール用に、dispatcher PCF を Power Platform 環境へオンデマンドでデプロイします。dispatcher PCF は Studio 側のコントロールで、ラップシェルの SendMessagePlugin ブリッジを介して複合キー <name>/<receiver> をコントロールのネイティブモジュールへディスパッチします。ユーザーのアクティブな pac auth プロファイルを使用して pac pcf push を実行します。/generate-pcf-companion とは切り離されています。エンジニアはローカルでスキャフォールドを作成してカスタマイズや反復を行い、準備ができたらデプロイします。

---

ステップ 1 — 共通ドキュメントを読み、前提条件を確認する

1. shared/shared-instructions.md、shared/naming-conventions.md を読みます。

2. スキルごとの最小限の前提条件ポリシー（shared-instructions.md §1.5）を適用します。このスキルには、Node.js 20 以降と npm、pac CLI、.NET SDK、アクティブな pac auth プロファイルが必要です。pnpm は必要ありません。

   続行する前に、shared-instructions.md §9.2 に従って、前提条件のステータスを見えるブロックとして出力します。

   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    Prereq check — /publish-pcf-companion
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   
    🟢 ✓ Node.js 20+ and npm installed       (for npm install / npm run build)
    🟢 ✓ pac CLI installed                   (for pac pcf push)
    🟢 ✓ .NET SDK installed                  (solution build runs inside pac pcf push)
    🟢 ✓ pac auth profile active             (target env: <env URL from pac org who>)
   
    🟢 4 checks passed. Ready to proceed.
   

   不足している場合の修正表：

   不足項目	失敗ブロック内の → Fix: 行
   Node.js / npm	https://nodejs.org から Node.js 20 LTS をインストールし、node -v と npm -v で確認します
   pac CLI	dotnet tool install -g Microsoft.PowerApps.CLI.Tool（.NET SDK も不足している場合は、先に .NET SDK のインストールが必要です）
   .NET SDK	brew install dotnet（mac）／winget install Microsoft.DotNet.SDK.10（win）／パッケージマネージャー（linux）
   アクティブな pac auth がない	pac auth create --environment <your-env-url>（ブラウザーでの対話型フロー。対象の Power Platform 環境にアクセスできる ID を使用してください）。最初から --deviceCode を使わないでください。これはヘッドレスシェル用のフォールバックであり、条件付きアクセスの環境では失敗することがよくあります。

   prereq-check.md の /publish-pcf-companion チェックを実行します。自動修正ポリシー（shared-instructions §1.5）に従い、.NET がインストール済みで pac CLI が不足している場合は自動修正できます。dotnet tool install -g Microsoft.PowerApps.CLI.Tool を提案し、yes の場合は続行します。アクティブな pac auth がない場合は、ブラウザーを使って pac auth create --environment <url> を開始し、完了後に確認します。認証が失敗した場合は、prereq-check.md にある方法の順序（ブラウザー → ヘッドレス環境の場合のみデバイスコード → --environment を指定して再度ブラウザー → pac auth clear）に従います。各ステップで変数を変更し、すでに失敗した方法を再実行しないでください。.NET SDK が不足している場合は処理を停止します（システム全体へのインストールが必要です。コマンドを出力してください）。

3. ./PRD.md を読みます。必須です。このスキルでは、PRD §2 から PCF フォルダー名（pcf/<Pascal>PCF/）と発行元のプレフィックスを取得します。PRD がない場合は、BLOCKED: PRD.md missing — cannot determine PCF folder name を出力して停止します。

4. ./.extension-state.md があれば読みます。状態ファイルは参考情報です。このスキルは状態ファイルがなくても動作しますが、Phase 情報を使って「scaffold-pcf がまだ実行されていない」ことを早い段階で通知します。

---

ステップ 2 — 現在の状態を検出する

アクションを実行する前に、検出内容をユーザーが確認できるよう、ステータスダッシュボードを作成します。

PCF フォルダーを確実に検出する — 正確な階層の深さを決めつけないでください。Glob を使って pcf/**/ControlManifest.Input.xml を検索し、最初に一致したパスを選択します。pac pcf init は通常、 pcf/<Pascal>PCF/<Pascal>PCF/ControlManifest.Input.xml を生成しますが、大文字と小文字の違いや手動での 構成変更があっても、検出に失敗しないようにします。pcf/ が存在しない場合は、処理を停止して BLOCKED: no pcf/ directory — PCF has not been scaffolded. Run /generate-pcf-companion first. と表示します。pcf/ は存在するものの、マニフェストが見つからない場合は、Glob で該当するファイルを一覧表示し、処理を停止して BLOCKED: pcf/ exists but no ControlManifest.Input.xml was found. と表示します。

マニフェストのパスから上へ 2 階層たどり、PCF プロジェクトのルートを特定します。Glob を使って <PCF_PROJECT_ROOT>/out/ が存在するか確認します。Read を使ってマニフェストから <control version="X.Y.Z"> の値を、.extension-state.md から最新のデプロイバージョンを抽出します。 アクティブな環境を取得するために pac org who を実行します。これは実際のツールチェーンコマンドです。

次を表示します。

PCF deploy status
─────────────────
Repo: <cwd>
PCF project root: <PCF_PROJECT_ROOT from find>
Manifest: <MANIFEST path>
Built (out/): <yes | no — will build now>
Current manifest version: <CURRENT_VERSION>
Last deployed version: <LAST_DEPLOYED or "none — first deploy">
Publisher prefix: <LAST_PREFIX from .extension-state.md, else `pamext` default — confirmed in Step 3.0>
Active pac auth env: <env URL from `pac org who`>
Active pac auth user: <user from `pac org who`>

Plan: pick publisher prefix → bump version if chosen → build if needed → pac pcf push --publisher-prefix <chosen prefix>

バージョンが重要な理由： Power Platform は、デプロイ済みアプリ内の PCF コントロールをバージョンごとにキャッシュします。同じバージョンを再度プッシュすると、以前のバンドルを読み込んだアプリに変更が反映されるのは、キャッシュが無効になるまで待ってからになる場合があります（タイミングはさまざまで、数分のこともあれば、数時間かかることも、作成者がアプリを再公開するまで反映されないこともあります）。ベストプラクティスは、意味のある変更をプッシュするたびにパッチバージョンを上げることです。

pac org who が「No active connection」を返した場合は、停止します。これは、pac auth list でプロファイルが表示されても、現在選択されていないことを意味します。pac auth select --index <n> を実行し、このスキルを再実行します。（ステップ 1 では認証がない状態を検出し、こちらでは「認証はあるがアクティブではない」という、よりまれなケースを検出します。）

正確なパスではなく Glob を使う理由： 標準のレイアウトではプロジェクトのルートから 2 階層下に配置されますが、大文字と小文字の違い、手動での構成変更、標準以外のスキャフォルダーが使われることがあります。Glob を使えば、固定パスを想定せずに OS に依存しない検出ができます。

---

ステップ 3 — ユーザーに確認する

このステップには、パブリッシャーのプレフィックス、バージョン更新、デプロイ確認という 3 つの確認ゲートがあります。それぞれ個別の AskUserQuestion で確認します。

3.0 — パブリッシャーのプレフィックスの確認

パブリッシャーのプレフィックスは、Power Platform のソリューション名の一部になります（例：pamext_<Pascal>PCF）。2～8 文字である必要があり、この範囲外の場合、pac pcf push は Argument --publisher-prefix has incorrect length というエラーで拒否します。

.extension-state.md に対して Read を使い、最も新しい Publisher prefix: <value> エントリを抽出します。ファイルまたはエントリがない場合は、デフォルトの pamext を使います。

次の内容を AskUserQuestion で確認します。

このデプロイで使用するパブリッシャーのプレフィックスは何ですか？（小文字 2～8 文字）

• <LAST_PREFIX>（前回のデプロイで使用したプレフィックスを使う）— LAST_PREFIX が見つかった場合のみ表示
• pamext（推奨）— 6 文字。「PAM Extension」。ファーストパーティのネイティブ拡張 PCF 向けに推奨するデフォルト値
• mspa — 4 文字。「Microsoft PowerApps」
• Custom — 2～8 文字の任意のプレフィックスを指定（自由入力。続行前に長さを検証）

選択された値を検証します。

PREFIX="<from user choice>"
PREFIX_LEN=${#PREFIX}
if [ "$PREFIX_LEN" -lt 2 ] || [ "$PREFIX_LEN" -gt 8 ]; then
  echo "❌ Publisher prefix '$PREFIX' is $PREFIX_LEN chars; must be 2–8. Try again."
  # Re-prompt
fi
if ! [[ "$PREFIX" =~ ^[a-z][a-z0-9]*$ ]]; then
  echo "❌ Publisher prefix must start with a lowercase letter and contain only lowercase letters and digits."
  # Re-prompt
fi

プレフィックスが重要な理由： Power Platform のソリューションエクスプローラーで、同じパブリッシャー ID の他のソリューションと PCF をまとめるために使われます。すべてのファーストパーティのネイティブ拡張 PCF で同じプレフィックスを使うと、一緒に表示されます。推奨値の pamext はプロジェクト内の慣例です。チーム独自の慣例がある場合もあるため、共有環境でカスタム値を選ぶ前に確認してください。

ハードコードしない理由： チームや環境で、すでに既存のパブリッシャーのプレフィックスが定められている場合があります。「powerapps」のハードコードは 2 つの点で誤りでした。9 文字で上限を超えており、環境の慣例も尊重していません。

3.1 — バージョン更新ゲート

AskUserQuestion を使用します。CURRENT_VERSION（マニフェストに現在記載されているバージョン）から、更新先の選択肢を算出します。

現在の PCF バージョン：<CURRENT_VERSION>（最終デプロイ：<LAST_DEPLOYED or "never">）

Power Platform は PCF をバージョンごとにキャッシュします。同じバージョンを再度プッシュしても、このコントロールをすでに使用しているアプリではキャッシュが無効にならない場合があります。バージョンを更新しますか？

• パッチ更新 → <CURRENT major.minor.(patch+1)>（バグ修正、内部改善に推奨）— 通常の既定値
• マイナー更新 → <CURRENT major.(minor+1).0>（新機能、または作成者が選択できる新しい出力／構成可能な入力を追加する場合）
• メジャー更新 → <(CURRENT major+1).0.0>（バインドされた入力、出力名、またはトリガーの動作に破壊的変更を加える場合）
• 更新しない — <CURRENT_VERSION> のままプッシュ（初期開発中に反復作業を行い、キャッシュのリスクを許容できる場合のみ。スキルは警告を表示します）

Edit ツールを使って、マニフェスト内の <control version="..."> 属性だけを置き換え、選択した更新を適用します。書き込み前にバージョンの変更内容（<CURRENT_VERSION> → <NEW_VERSION>）を正確に表示し、マニフェスト内のほかのフィールドはすべて保持します。

バージョン更新後は再ビルドが必要です（マニフェストが変更されたため、out/ は古い状態です）。ユーザーが以下の 3.2 でどちらを選んでも、ビルドはステップ 4 の一部として実行されるため問題ありません。

ユーザーが「更新しない」を選んだ場合：マニフェストの編集はスキップします。次の警告を表示します。

⚠️ <CURRENT_VERSION> のまま再度プッシュします。このコントロールを以前に読み込んだアプリでは、PCF キャッシュが無効になるまで変更が反映されない場合があります。これが問題になる場合は、次回のプッシュでバージョンを更新してください。

3.2 — デプロイ確認ゲート — 環境を最初に表示する

環境を間違えたデプロイは、実際に発生している失敗事例です（環境 URL が長い質問文に埋もれていたため、あるとき wrap-player-test-env ではなく wrap-bug-bash-env に公開されました）。このゲートでは、対象環境を見出しとして表示し、変更する選択肢も明示的に提示します。pac auth でたまたまアクティブになっている環境を、そのまま黙って使ってはいけません。ユーザーが環境を特定できるよう、URL だけでなく現在の環境の詳細をすべて表示します。pac org who（わかりやすいプロファイル名を取得するには pac auth list も）を読み取り、次を表示します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ►► CURRENT DEPLOY TARGET ◄◄
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Environment:   <friendly org name from `pac org who` — e.g. "Contoso Test (default)">
 URL:           <env-url>
 Environment ID:<org/environment id from `pac org who`, if shown>
 Signed-in as:  <user from `pac org who`>
 Auth profile:  <active profile name from `pac auth list` (the ★ row)>
 Last deployed: <from .extension-state.md PCF deployments — env + timestamp, or "first deploy">
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

次に、環境名を質問文にもそのまま記載し、維持するか変更するかの判断から始める 3 つ目の AskUserQuestion を行います。

<Pascal>PCF@<resolved version>（プレフィックス <PREFIX>）を — にデプロイします。この環境を維持しますか、それとも切り替えますか？

• はい、この環境を維持 — ビルド + プッシュ（推奨）：npm run build を実行してから、pac pcf push --publisher-prefix <PREFIX> を実行します。
• 環境を切り替える — デプロイ前に対象を変更します。pac auth list を実行し、既存のプロファイル（pac auth select --index <n>）を提示するか、新しいプロファイル（pac auth create --environment <url>）を作成します。フロー内で実施し、その後、この見出しを再表示して再度質問します。ユーザーにスキルの実行を中断してやり直させてはいけません。
• 再ビルドせずにプッシュ（バージョンを更新しておらず、現在の out/ が信頼できる場合のみ）：npm run build をスキップします。3.1 でバージョンを更新した場合は無効です。バージョンを更新したマニフェストは再ビルドが必要です。
• キャンセル

環境（わかりやすい名前 + URL）とプレフィックスは、見出しブロックと質問文の2 か所に同じ内容で表示します。環境設定の誤記や、認証で誤った環境がアクティブになっていることは、「誤ったテナントにデプロイされた」原因として最もよくあります。認証プロファイルがすでに存在していても、必ず現在の環境と切り替えの選択肢を表示します。アクティブなプロファイルがユーザーの希望するものだと決めつけてはいけません。

---

ステップ 4 — 実行

4.1 — 必要に応じてビルド（「はい — ビルド + プッシュ」の場合は常に実行）

ステップ 2 で特定した $PCF_PROJECT_ROOT を使用します。pcf/<Pascal>PCF をハードコードしてはいけません。

cd "$PCF_PROJECT_ROOT"
[ -d node_modules ] || npm install --no-audit --no-fund
npm run build --silent

ビルドが失敗した場合：BLOCKED: pcf-scripts build failed — fix the source and re-run /publish-pcf-companion と表示して停止します。診断については、ユーザーに /test-native-extension のレイヤー 4 を案内します。

4.2 — Power Platform にプッシュする

cd "$PCF_PROJECT_ROOT"
pac pcf push --publisher-prefix "$PREFIX"   # $PREFIX from Step 3.0

プレフィックス $PREFIX はステップ 3.0 でユーザーが選択し、長さが検証されています（2～8 文字）。それでも pac pcf push が Argument --publisher-prefix has incorrect length で拒否する場合は、下流の何らかの要因（環境設定、新しい pac バージョンでのプレフィックス正規表現の変更など）が想定外です。生のエラーを表示し、ステップ 3.0 を再実行して別の値を選ぶよう案内してください。

プレフィックスが対象環境のパブリッシャーとして存在しない場合、プッシュは Publisher prefix '$PREFIX' not found でエラーになります。この内容を表示し、ユーザーに次のいずれかを案内してください。

• 環境管理者にプレフィックスの追加を依頼します：pac solution publisher-add --prefix "$PREFIX" --name "<publisher name>"。または
• このスキルを再実行し、環境にすでに存在するプレフィックスを選択します（環境管理者は Power Platform 管理センターで一覧を確認できます）。

4.3 — 成功

次を表示します：

🟢 ✓ Deployed <Pascal>PCF to <env-url> at <ISO timestamp>
  Solution: <PREFIX>_<Pascal>PCF (verify in https://make.powerapps.com → Solutions)

4.4 — 失敗

pac pcf push はさまざまな理由で失敗することがあります。よくある原因は次のとおりです。

エラー	考えられる対処
Publisher prefix '<PREFIX>' not found	環境管理者にプレフィックスの追加を依頼するか、ステップ 3.0 を再実行して環境に存在するプレフィックスを選びます
Authentication failed / 401	pac auth のトークンの有効期限が切れているか、プロファイルが誤った ID／環境に紐付いています。pac auth select を試してから、pac auth create --environment <url>（ブラウザー）で作成し直してください。それでも失敗する場合は、prereq-check.md のバリアントを順に試してください。同じバリアントを再試行せず、--deviceCode をデフォルトで使用しないでください。
Solution import failed: missing dependency	環境に必要な Power Platform 機能がありません（ネイティブ拡張 PCF ではまれです。依存関係の名前を表示してください）
Build of <Pascal>PCF.csproj failed	PCF ツールが dotnet build を実行し、失敗しました。古い out/ が原因であることがよくあります。rm -rf out/ && npm run build を実行してから再試行してください。

.extension-state.md を更新し、新しい「PCF deployments」セクションに Deploy: fail — <ISO> — <env-url> — <one-line reason> を追加します。BLOCKED: pac pcf push failed — <reason> として停止します。

---

ステップ 5 — 状態を更新して要約する

プッシュに成功したら、./.extension-state.md を更新します。

• PCF deployments セクションを追加（または更新）します。

  ## PCF deployments
  - <ISO timestamp> — <env-url> — Version: <X.Y.Z> — Publisher prefix: <PREFIX> — Result: success
  

  以降のデプロイが成功するたびに新しい行を追加します。最新の行を末尾に置きます。Version: フィールドには、プッシュ時の <control version="..."/> の値を指定します（3.1 でバージョンを更新した場合は更新後の値）。Publisher prefix: フィールドにはステップ 3.0 でユーザーが選んだ値を指定します。以降の実行では、LAST_PREFIX の検出によりこの値がデフォルトになります。
• Phase フィールドは変更しないでください。デプロイはフェーズの段階とは別のものです。

最終的な要約を表示します。

Deploy complete
───────────────
PCF: <Pascal>PCF
Version: <X.Y.Z>     ← post-bump if 3.1 bumped; else same as before
Bump: <patch | minor | major | none — re-pushed at same version>
Environment: <env-url>
Publisher prefix: <PREFIX>
Build: <skipped — current out/ used | rebuilt at <time>>
Deployed at: <ISO timestamp>

Where to look next (informational — these are makers-portal steps, not skills):
  • Open https://make.powerapps.com → switch to <env> → Solutions → find `<PREFIX>_<Pascal>PCF`.
  • In a Canvas app: Insert → Custom → search for `<Pascal>PCF` under the `PowerApps` namespace.
  • If a previously-deployed app doesn't show your changes: re-publish that app (File → Save → Publish) to bust the PCF cache.

5.1 次のステップの確認

shared/shared-instructions.md §9.1 に従い、リポジトリの状態に応じた状況を踏まえた選択肢を AskUserQuestion で提示します。説明するのではなく、実行してください。ユーザーが Run /… オプションを選んだら、同じターン内で直ちに Skill ツールを使ってそのスキルを呼び出します（shared-instructions §9.1）。何も呼び出さずに実行を終了する唯一のオプションは、エスケープハッチです。

状態を検出して、選択肢を絞り込みます。

検出条件	意味
.ppmplugin バンドルがまだビルドされていない（ppmplugin/<name>.ppmplugin が存在しない）	/generate-ppmplugin が自然な次のステップです。ディスパッチャー PCF はデプロイ済みですが、ディスパッチ先となるバイナリバンドルをまだビルドする必要があります。
.ppmplugin バンドルがすでに存在する（ppmplugin/<name>.ppmplugin が存在する）	/audit-ppmplugin でビルド済みバンドルを再検証します。/debug-extension でコントロールをデバッグ、改良します。

続いて AskUserQuestion を実行します。デプロイ後に提示する一般的な選択肢：

Question: "Dispatcher PCF deployed. What would you like to do next?"
Header:   "Next step"

Options:
  1. "Run /generate-ppmplugin"   description: "Build (or rebuild) the verified .ppmplugin binary bundle end-to-end (manifest → build → assemble → audit) — the bundle this dispatcher PCF routes to over the wrap bridge."
  2. "Run /debug-extension"       description: "Debug/refine the control (PRD or native/PCF code), then re-deploy with another version bump."
  3. "Run /audit-ppmplugin"      description: "Re-verify an already-built .ppmplugin bundle against the format spec and the manifest's receiver/method contract."
  4. "Stay — I'll verify in Studio"   description: "Skill exits. Open make.powerapps.com → your env → find the new PCF in Solutions / insert it in a Canvas app to verify."

参考情報（スキルの選択肢ではありません）： ビルド済みの .ppmplugin をラップウィザードでアップロードし、このディスパッチャー PCF をキャンバスアプリに接続する作業は、ステージ 3 — まだスキルではありません。バンドルのビルドと PCF のデプロイが完了した後の、最終的なホスティング手順は、メーカー ポータル／ラップウィザードで手動で行います。

ユーザーが Run /… オプションを選んだら、Skill ツールで呼び出します。「Stay」を選んだ場合は、デプロイが完了したことを確認する一文を出力し、戻りステータスのブロックに進みます。

---

戻りステータスのプロトコル

コード	意味
DONE	pac pcf push が成功し、状態ファイルがデプロイ行で更新されました。
DONE_WITH_CONCERNS: <list>	プッシュは成功しましたが、注意事項があります（パブリッシャーのプレフィックス不一致があり、ユーザーが代替案を了承した場合、または npm run build で警告が発生し、ユーザーが了承した場合）。
NEEDS_CONTEXT: <missing>	PRD が不足している、PCF がまだスキャフォールディングされていない、またはシナリオに関する質問で必要なユーザー入力が揃っていません。
BLOCKED: <reason>	前提条件を満たしていません（pac、dotnet、または認証情報が不足）。pac pcf push が競合以外の理由（権限、ネットワーク）で拒否された。npm run build が失敗した。ユーザーがキャンセルした。または pac org who でアクティブな接続が確認できません。

1 行目の後に空行を入れ、人が読める形式の要約を続けます。

---

厳守事項

• 環境 URL の明示的な確認を得るまでは、絶対にプッシュしないでください。 環境 URL はステップ 3 の質問にそのまま表示され、ユーザーがその URL に対して yes と入力します。ステップ 3 とステップ 4 の間に環境が変わった場合（並行セッションで pac auth select が実行された場合など）は、停止して再度確認してください。
• 認証やソリューションの競合を回避するために、--force 系のフラグを絶対に使用しないでください。 pac pcf push でエラーが発生した場合は、エラーを伝えて停止してください。ユーザーの確認なしに、別のプレフィックスやソリューションの対象を試してはいけません。
• パブリッシャープレフィックスはデプロイ時にユーザーが選択するものであり、ハードコードしません。 長さは 2～8 文字の小文字と数字である必要があります（ステップ 3.0 で検証）。.extension-state.md に前回使用したプレフィックスがあれば、それをデフォルトとして確認し、なければ pamext をデフォルトにします。プレフィックスの明示的な確認を得るまでは、絶対にプッシュしないでください。環境にはすでに設定済みのプレフィックスが使われていることが多く、誤ったプレフィックスを使用すると孤立したソリューションが作成されます。
• ユーザーが明示的に許可していない環境には、絶対にデプロイしないでください。 このスキルはアクティブな pac auth プロファイルを読み取ります。ユーザーが別の環境を使いたい場合は、このスキルを実行する前に切り替えてください。
• 確認なしに自動でバージョンを上げないでください。 PCF バージョン（マニフェスト内の <control version="X.Y.Z">）は、Power Platform のキャッシュ無効化を制御します。このスキルでは、ステップ 3.1 で AskUserQuestion を使ってバージョン引き上げの選択肢を提示し、パッチバージョンの引き上げをデフォルトで強調表示したうえで、選択された変更をそのまま適用する必要があります。確認なしにバージョンを引き上げたり、プロンプトを省略したりしてはいけません。実行する前に「マニフェストのバージョンを変更します」とエンジニアに知らせる必要があります。
• マニフェストのバージョンを引き上げた場合は、再ビルドが必要です。 ステップ 3.1 でマニフェストを変更した場合、ステップ 3.2 の「再ビルドせずにプッシュ」オプションは無効にするか、選択できないようにする必要があります。新しいマニフェストバージョンで古い out/ をプッシュするのは実際の不具合です（デプロイされたバンドルが、ソリューションで宣言されたバージョンと一致しなくなります）。
• PRD.md がないディレクトリでは実行しないでください。 このスキルは PRD §2 から PCF フォルダー名を導き出す必要があります。これがないと、推測するしかありません。