本番相当の検証経路（CI / staged / live）を日本語で把握するための解説です。
- 本番検証は「実装済み事実の継続確認」であり、認証取得の主張ではありません。
- production/smoke テスト、ライブ検証、運用Runbook訓練を段階的に実施します。
- 検証結果は TrustLog や提出エビデンスに再利用できる形で保存します。
- Decision Governance の fail-closed 振る舞いを継続的に確認する運用基盤です。
- operator-facing governance surface の信頼性を、テストと証跡で裏づけます。
- staged readiness report v2.1 では、
deployment_readyは ブロッキング扱いのガバナンスチェック（blocking governance checks）と、compose_validationが添付されている場合の compose 検証結果に基づきます。compose_validationが未添付の場合、overall_readiness.compose_validated=trueは 「compose の失敗が添付されていない」ことを示すだけで、 compose 検証が実行された証明ではありません。 - 注意・警告扱いの失敗や live provider 検証の結果は、
overall_readiness.advisory_issues、overall_readiness.advisory_issue_count、governance.advisory_failure_labels、overall_readiness.live_provider_ok、live_provider_validationに分けて表示されます。 これらは v2.1 では単独でdeployment_readyを未達扱いにはしませんが、 昇格・本番反映の前に運用者が確認する必要があります。 live_provider_validationが未添付の場合、overall_readiness.live_provider_ok=trueは live provider 検証が実行済みであることを意味しません。make validate-staged-reportは、compose/live provider のサブレポートを添付しない staged report を生成します。昇格・本番反映前の確認でcompose_validationとlive_provider_validationを staged report に含めたい場合は、make validate-staged-report-with-subreportsを使用します。この target は compose 検証と live provider 検証を先に実行し、その JSON レポートをscripts/generate_staged_readiness_report.pyに渡します。live provider 検証には provider secrets が必要になる場合があります。make quality-checksと production/smoke 系テストを継続実行する。- PostgreSQL の live 検証導線と運用ドリルを定期確認する。
- staged readiness report は v2.1 を利用し、
trustlog-production-postureの advisory 証跡を含みます。 - 詳細は英語正本または実装ファイルを確認してください。
- 検証通過だけで本番可用性・法令適合を保証しません。
- 環境固有のセキュリティレビュー、監査設計、運用承認が必要です。