launch-readiness-review

リリース準備状況レビュー

儀礼的なチェックリストではなく、正確な証拠に基づいて、リスクに見合ったリリース判断を下すリリース承認記録を作成します。

対象範囲

最終的なドメイン横断の証拠グラフ、ブロッカーの分類、判断、条件、リリース監視、権限、および復旧訓練を担います。兄弟成果物の事実は ID／バージョン／ダイジェストで参照し、プロダクト設計、ストア申請、支払い、マーケティング、セキュリティ、サポートに関する成果物を作り直さないでください。

リポジトリのプロダクト成果物と組み合わせる場合は、共有プロダクト成果物エンベロープを使用します。必須の証拠が欠けている場合は、ブロッカーまたは明示的な引き継ぎとし、合格を捏造してはいけません。そのような上流の契約がない単独レビューでは、エンベロープは不要です。

リソースガイド

• リスクに見合ったドメインゲート、判断区分、条件付き承認の例外、復旧権限については、references/launch-readiness-patterns.md を参照してください。
• 候補にカナリアリリース、段階的ロールアウト、リリース健全性ダッシュボード、初週の運用しきい値、リリース後のクローズアウトが必要な場合は、references/release-health-watch.md を参照してください。

ワークフロー

1. 正確なコミット／ビルド／コンテンツ／設定／モデル／ポリシー／移行ダイジェスト、リリース種別、対象ユーザー／年齢モード、チャネル／地域、影響範囲、判断責任者、変更期間、不可逆的な被害の境界を特定します。
2. 上記の該当するリファレンスを読みます。申告された候補、対象ユーザー、チャネル、データ、金銭、規制、影響範囲に適用されるゲートのみを選びます。各ドメインが適用される理由、または適用されない理由を記録します。
3. 各ゲートを pass、watch、blocked、not-applicable-with-proof のいずれかに分類します。構築、証明、公開範囲、外部権限を区別します。不明な項目を N/A にしてはいけません。
4. 正確な候補に対応する成果物、該当する場合は出所／署名、カナリア／段階的ロールアウト、データ／後方互換性、移行／再生、機能／設定のキルスイッチ、ロールバック／前方修正、派生状態／キャッシュの復旧、復元訓練を検証します。
5. リスクに見合った最小限のリリース監視を定義します。テレメトリと対抗指標、アラートの責任者、必要に応じた公開上限、一時停止／撤回、コミュニケーション、ライブでの読み戻しを含めます。段階的リリースまたは変更の大きいリリースでは、リリース健全性の行スキーマ、ベースライン／セグメント／サンプルのルール、拡大／保留／ロールバックの条件、クローズアウトの証拠を作成します。
6. go、conditional-go、hold、no-go のいずれかを発行します。各条件には責任者、期限、正確な証明、満たされなかった場合の結果を含めます。曖昧な約束にしてはいけません。

情報源の検証

最新のプラットフォーム／ストア、プライバシー／同意、アクセシビリティ、セキュリティ、支払い／返金、広告／プロモーション、子ども／年齢、法務／規制対象カテゴリー、地域、認証、パートナーの権限を確認します。外部承認は明示的な最低条件として扱い、自己申告で済ませてはいけません。

使用しない場合

• 複数ドメインにまたがるプログラムグラフを構築し、兄弟成果物を作成する場合は、単一のリリース候補を判断するだけでなく、product-lifecycle-architect を使用してください。
• チャネルへの申請、レビュー担当者、認証、ロールアウト、公開中のストアに関する証拠には、app-store-distribution-readiness を使用してください。
• 最終的なドメイン横断の承認ではなく、複数コホートによるゲームの学習／公開プログラムには、game-soft-launch-review を使用してください。
• 全体のリリース判断を再検討せず、欠けている成果物を一つだけ設計または監査する場合は、該当ドメインのスペシャリストを使用してください。

ガードレール

• マーケティング面での準備が整っていても、製品、権限、サポート、決済、移行、セキュリティ、復旧の準備が整っていることの代わりにはなりません。
• 影響の大きい未解決項目について、対象範囲を限定した露出、明示的なリスク受容権限、有効期限、対抗指標、自動停止がない限り、「リリース後の対応」と呼んではなりません。
• 権威ある状態、サポート、補償、復旧手段がないまま、有料、個人データ、子ども、破壊的変更、移行、または不可逆なフローをリリースしてはなりません。
• ワークフローが正常終了しても、本番での証明にはなりません。デプロイ済み／リリース済みの識別情報と、ユーザーから確認できる情報またはテレメトリーによる読み戻しを検証してください。
• チェックリストを完全にすることだけを目的に、無関係なゲートを追加してはなりません。比例性を理由に、実際に適用される要件を省いてはなりません。

出力仕様

次の項目を含む、型付きの Launch Admission Record を 1 つ返してください。

1. 候補／権限の正確な識別情報、対象範囲、対象ユーザー／チャネル、意思決定責任者、変更期間、許容できない損失の境界
2. 依存関係／エビデンスのグラフと、合格／要注意／ブロック／該当なしのゲートマトリクス
3. 担当者、正確な証明、期限、自動的に適用される措置を含むブロッカーの記録
4. カナリア／段階的な公開範囲、移行、ロールバック／フォワードフィックス、キャッシュ／派生状態、復元訓練のエビデンス
5. 比例的なリリース監視。必要に応じて、リリース健全性ダッシュボードの行、ベースライン／セグメント／サンプルのルール、一時停止／公開停止、コミュニケーション、ライブでの読み戻し計画を含めてください。
6. 機械可読な理由を含む go | conditional-go | hold | no-go の判定
7. リリース後のライブでの読み戻しと完了確認のエビデンス

未解決の外部権限事項や手動での判断は、明示してください。リリース済みの正確な候補についてライブでの読み戻しが確認できるまで、リリース完了としてはなりません。