準備状態の確認
$check-readiness diff、$check-readiness pr <URL>、$check-readiness release、または $check-readiness full として呼び出します。
デフォルトでは読み取り専用です。問題と具体的な解決策を報告します。ユーザーが明示的に修正や適用を依頼した場合のみ編集を行い、その後に影響を受ける動作を検証します。
1. ターゲットの選択
| モード | ターゲット | 完了基準 |
|---|---|---|
diff | 現在のリポジトリのステージ済み、未ステージ、関連する未追跡の変更、および影響を受ける呼び出し元とテスト。デフォルトは変更がターゲットの場合。 | 変更されたすべての動作と影響を受ける境界が説明されていること。 |
pr <URL> | リンクされたPRの差分、ベース、会話、チェック、および影響を受けるコンテキスト。 | 変更されたすべての動作が説明されていること。不足しているローカルまたはリモートのエビデンスが特定されていること。 |
release | 現在のリポジトリと指定されたデプロイメントターゲット、またはリポジトリ設定で見つかったターゲット。 | すべての重要なフローとリリースの依存関係に状態があること。 |
full | 該当するバックエンドおよびフロントエンドの表面にわたる現在のリポジトリ。 | すべての主要なルート、操作、信頼境界、データストア、およびライフサイクルパスが一覧化され評価されていること。 |
ユーザーが指定したモードを使用します。指定がない場合は、PR URL、現在の変更、または明示されたリリースから推測します。それ以外の場合は full を使用します。チェックを開始する前に、正確なターゲット、リビジョンまたは差分、環境、および利用可能な検証パスを記録します。PR URLにアクセスできない場合は、何がブロックされているかを報告し、無関係なローカル差分で代用しないでください。
重要度
すべての FAIL はブロッキングまたはアドバイザリです。ブロッキング：セキュリティ、認証・認可、データ損失または破損、重要なフローの中断、未検証の支払いまたはWebhook処理、漏洩したシークレット、ビルドまたはテストの失敗。それ以外はすべてアドバイザリであり、それだけで READY を妨げるものではありません。各準備状態スキルは、独自のブロッキング領域をリストします。
モードごとの深さ
diff および pr：変更が触れる動作のみをチェックし、残りは1行で N/A (未接触) とマークします（チェックごとではありません）。リリースゲートのチェック（Lighthouse、デプロイ環境のスモークテスト、プレビュー共有）は、変更がそれらに影響を与える場合を除き、release と full にのみ適用されます。
2. エビデンスの収集
diff の場合、git status --short --branch、ステージ済みおよび未ステージの差分、および関連する未追跡ファイルを検査します。pr の場合、リンクされたPRとその差分、チェック、議論を読み取ります。テストのために一致するローカルチェックアウトを使用するのは、そのリビジョンが検証されている場合のみです。release および full の場合、テスト前にスコープ内のアプリケーションをマッピングします。影響を受ける各領域について、呼び出し元、データへの影響、設定、テスト、およびデプロイメントの依存関係をトレースします。
バックエンドコードまたは動作がスコープ内にある場合は、backend-readiness を実行します。フロントエンドコードまたは動作がスコープ内にある場合は、frontend-readiness を実行します。選択したモードとターゲットをそれぞれに渡します。両方が該当する場合は、それらの結果を統合します。変更レビューの場合は、影響を受ける動作にチェックを適用します。リリースの場合は、重要なフローとターゲット環境全体にチェックを適用します。full の場合は、リポジトリ全体の該当するすべてのチェックを評価します。該当する各チェックを PASS、FAIL、BLOCKED、または N/A でマークし、すべての PASS に現在のエビデンスを、すべての N/A に理由を添付します。
ソース、自動テスト、ローカルランタイム、プロバイダサンドボックス、デプロイ環境を個別のエビデンスレイヤーとして使用します。ビルドはビルドを証明します。利用できない資格情報、インフラストラクチャ、または環境は、 BLOCKED として記録し、それでも必要な正確な証明を添えます。ターゲットを検証できる焦点を絞ったチェックを実行します。ソースのみからランタイムまたはリリースの動作を主張しないでください。
該当するチェックに状態があり、失敗には原因と解決策があり、各準備状態の主張がエビデンスレイヤーと一致している場合に完了します。
3. 報告とアクション
モードとターゲットを報告し、その後、セキュリティ、データ損失、正確性、ユーザーへの影響の順に結果を報告します。各結果は、場所またはフロー、エビデンス、結果、および最小限の具体的な解決策を示します。実行されたチェックと正確な結果、およびブロックされた項目または未検証の項目を含めます。選択したターゲットに対して READY、NOT READY、または UNVERIFIED で終了します。READY は既知のブロッキング障害がなく、該当するゲートのエビデンスがあることを要求します。UNVERIFIED はエビデンスの不足によりその主張ができないことを意味します。
次のテンプレートを使用します：
モード / ターゲット：<モード、リビジョンまたは差分、環境>
結果
| 重要度 | 場所またはフロー | エビデンス | 結果 | 解決策 |
実行されたチェック
| コマンドまたはテスト | 結果 |
ブロック / 未検証
- <項目>：<まだ必要な証明>
判定：READY | NOT READY | UNVERIFIED
レビュー実行は読み取り専用に保ちます。ユーザーが結果の修正を依頼した場合は、影響を受けるコードに要求された修正を適用し、フォーカスした検証を実行し、残りのリスクを報告します。準備状態のチェックを依頼されたことから編集許可を推測しないでください。
レポートが検証された動作とギャップを区別するか、要求された修正が適用されて検証された場合に完了します。