Azureアプリオンボード事前確認 — リポジトリ評価 は何をしますか？
インフラ計画の前に、ユーザーのリポジトリのビルド健全性、アプリの完全性、Azureデプロイ可能性を評価します。コンポーネントごとに判定（PASS/WARN/FAIL）を生成し、後続フェーズで使用します。
オーケストレーターとの関係:
azure-app-onboardによってステップ3で呼び出されるか、コード準備チェックとして単独で使用されます。オーケストレーターから呼び出された場合は、アーティファクト書き込み後に制御をazure-app-onboardに戻します。下流フェーズを直接呼び出さないでください。
AppOnboardパイプラインの4フェーズ中フェーズ1。セッション: .copilot-azure/sessions/{session-id}/。context.json を読み取ります。components[]、repo{}、detectedInfra[] を書き込みます。prereq-output.json を生成します。スキーマ: prereq-schemas.ts — PrereqOutput、BuildRequirements。直接エントリもサポートされます。
使用すべきではないケース
| シグナル | リダイレクト先 |
|---|---|
| インフラ（Bicep/TF/azure.yaml）の検証 | azure-validate |
| IaCの生成 | azure-prepare |
| アイデアから本番までのエンドツーエンド | azure-app-onboard |
azd up の実行またはデプロイ | azure-deploy |
ルール
⛔ 絶対禁止 —
npm install、npm test、npx jest、pytest、およびすべてのインストール/ビルド/テストコマンドの実行は許可されません。 いかなる状況でも、npm install、npm test、npx jest、pip install、pytest、dotnet build、dotnet restore、dotnet test、go mod download、cargo build、その他すべてのパッケージマネージャーのインストール、ビルド、テストコマンドを事前確認フェーズで実行してはいけません。コードを検証するためにテストスイートを実行しないでください。代わりにテスト設定ファイルを静的に確認してください。事前確認フェーズは読み取り専用の評価＋静的検証のみです。 唯一の例外 — 同意ゲート付きの2つのコンテキスト: (a) エージェントが移行/修復中に変更したコード（remediation-protocol.md ステップ6を参照）、または (b) エージェントがゼロコードパスで新規作成したコード（zero-code-path.md を参照）。いずれの場合も、インストール/ビルド/テストの実行は、ユーザーが特定のコマンドごとの同意プロンプトに回答した後、ユーザー確認済みのビルド検証ゲート（build-check.md ステップ3）を介してのみ行われます。一般的な事前同意は適用されません。
- ⛔ 完全パイプライン（ステップ1〜8）、例外なし。 すべてのプロンプト → 直接ステップ1へ。特定の質問への回答は調査結果（ステップ5）の一部として行い、それ以前には行いません。
- ⛔ 評価のためのサブエージェントは禁止。 3軸評価はインラインで行います。例外: ゼロコードパスのスキャフォールディング（ステップ2）。
- コード/破壊的変更には
ask_userが必要です。結果が出る前に最大3つの質問。直接エントリの場合: オーケストレーターの意図確認質問を繰り返さないでください。
MCPツール
| ツール | 目的 |
|---|---|
mcp_azure_mcp_get_azure_bestpractices | 検出されたスタックパターンをAzureベストプラクティスに対して検証 |
mcp_azure_mcp_extension_cli_install | 必要なCLIツール（az、azd、func）の確認/インストール |
ワークフロー
ステップ1: セッションチェック
オーケストレーターエントリ: セッションが存在する場合はcontext.jsonを読み取り、ステップ2に進みます。
直接エントリ: .copilot-azure/sessions/active-session.json を確認します:
- 存在する → ⛔ session-protocol.mdを読み、再開/新規ゲートを確認します。ユーザーが回答するまで進めないでください。
- 存在しない → セッションを作成: UUIDを生成し、
New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Forceを実行してcreateツールでcontext.json+active-session.jsonを書き込みます。
その後: az account show → {id, name, tenantId} を context.json.azure にマージします。⛔ スキャン前にセッションがディスク上に存在する必要があります。
ステップ2: ワークスペースのスキャン
プロジェクトファイルをスキャンします。コンポーネント、repo{}、detectedInfra[]、detectedServices[] を検出します。Terraformプロバイダーを分類します。CLIの可用性を確認します。スタック検出の競合: ユーザーの明示的な記述が優先（context.json に書き込み、スキャンを上書きとしてマーク）; スキャンのみ → ユーザーに確認; 複数スタック → すべて表示して質問（component-mapping.md を参照）; コードなし → zero-code-path.md。
プロジェクトファイル、Dockerfile、index.html のいずれも存在しない場合 → ⛔ zero-code-path.mdを読んでください。
⛔ クラウドSDK早期ゲート。
aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebaseをgrepします。機能的な依存関係が見つかった場合 → cloud-sdk-migration.mdを読み、その後ask_user: 「Azure Cloud Migrateにリダイレクト」（routeToSkill: "azure-cloud-migrate"を設定） · 「評価を続行」（準備評価完了 + SDK→Azureマッピング、その後ステップ8で停止 — 依存関係が置き換えられるまで計画はなし） · 「キャンセル」。
ステップ3: コンポーネントごとの評価
| サブステップ | アクション | 参照 |
|---|---|---|
| 3.1 | ビルドチェック | ⛔ build-check.md を必ず読んでください |
| 3.2 | 完全性チェック | ⛔ completeness-check.md を必ず読んでください |
| 3.3 | デプロイ可能性チェック | ⛔ deployability-check.md を必ず読んでください |
| 3.3a | コンポーネントマッピング（条件付き） | >1個のプロジェクトマニフェスト（モノレポ）が見つかった場合のみ、component-mapping.md を読んでください |
評価後、コンポーネントごとに buildRequirements を設定します。判定の伝播、ティアルール、f1Viableの集約については、readiness-gate.md および個別のチェック参照を参照してください。
ステップ4: アーティファクトの書き込み + 準備ゲート
⛔ context.json がディスク上に存在することを確認します。readiness-gate.md（判定、ティア、バッチ-承認、ファストトラック）を読み、次に prereq-artifacts.md（書き込み手順、スキーマ）を読みます。
ステップ5: 調査結果の提示
readiness-gate.md § 調査結果の提示 に従い、重要度ごとにグループ化された判定を先に表示してから進みます。
ステップ6: 修復（条件付き）
⛔ ❌ FAIL判定、🔧 推奨修正、または fixPhase: "prereq" 付きの ⚠️ WARN が1つでもある場合は、remediation-protocol.md を必ず読んでください。修復ループ、静的検証、再評価義務、修復後のアーティファクト更新、およびビルド検証同意ゲートが含まれます。すべての判定が ✅ PASS または fixPhase: "prereq" なしの ⚠️ WARN の場合は、ステップ7にスキップします。
ステップ7: 最終状態の書き込み
completedPhases には既に "prereq" と currentPhase: null（ステップ4から）が含まれています。その後:
⛔
lastScanCommitを書き込みます。git rev-parse HEADを実行し、完全な40文字のSHAをcontext.json.repo.lastScanCommitに保存します。必須 — 再開時にHEADと比較して変更を検出するための鮮度ガードとしてステップ1で使用されます。
ステップ8: ルーティング
⛔ 必須 — このステップをスキップしないでください。
ルーティングフィールド: すべてのルーティングは
routeToSkillとrouteReasonをcontext.jsonに書き込みます。
修復後のコンテキスト: ステップ6を実行した場合は、ルーティングプロンプトを次のように開始します: 「修復完了 — {N}個の問題を修正しました。アプリの状態は {overallHealth} です。」