[kmryst]

目的（推奨）

既存リポジトリを B2C 一次チケット販売へ転換する方針と、Protected Zone 内の購入フローを設計文書の正本として記録する。

変更内容（推奨）

• B2C 一次販売フローの正本を追加し、Waiting Room、Purchase Session、Ticket Hold、疑似決済、Purchase の責務を定義
• B2C への転換、Protected Zone 内の購入フロー、購入ジャーニーの成功率とレイテンシ SLI、同期 API・決済結果解決時間・決済依存 timeout の境界を ADR-0020〜ADR-0027 として記録
• 購入レイテンシを同期購入処理時間と決済結果解決時間へ分離
• B2C 同期 API を Fastify onRequestからonResponse / onRequestAbort / onTimeoutまで計測する境界を定義
• 4 API 個別 p95 を正式 SLO とし、ジャーニー予算・p99・Outcome 別合算を非 SLO の設計・検証指標とする構造を定義
• 決済結果解決時間を payment attempt 単位で計測し、Purchase Session あたり最大3回、同期解決 p95、非同期解決の診断指標、未解決時の監視境界を定義
• 決済依存の境界を3秒・5秒・30秒・60秒に分け、HTTP 202 Accepted、payment_unknown、stale attempt回収、再送・競合制御を一次販売と可観測性の正本へ記録
• ADR-0026をAcceptedのまま維持し、60秒の同期待ちを3秒cutoffへ更新した範囲だけをADR-0027で明記
• README、システム要件、技術スタック、可観測性、技術検証計画、容量計画を目標設計に合わせて更新
• 既存の C2C Purchase API の実測値と SLO を、B2C の複数段階フローへ直接流用しないことを明記

影響範囲（推奨）

• 対象: B2C 一次販売の要件、アーキテクチャ方針、成功率・レイテンシ SLI、同期 API と決済結果解決時間の計測境界・SLO・集計方式、決済試行・timeout・結果不明時のポリシー、ADR、技術検証と容量計画の読み替え
• 非対象: アプリケーション、DB schema、Terraform、AWS リソース、timeout設定の実装、k6 スクリプト、負荷試験の実行、B2C の具体的な SLO・Alarm 目標値

PR ラベル（必須）

• type: type:docs
• area: area:architecture, area:docs
• risk: risk:medium
• cost: cost:none

影響メモ（必要時のみ）

コスト根拠: 文書のみの変更であり、AWS リソースを作成・変更しない。
リスク根拠: 要件とアーキテクチャの正本を B2C へ変更し、後続実装の前提になるためレビューが必要。
データ影響: なし。DB schema と既存データを変更しない。
ロールバック観点: 本 PR を revert し、転換前の正本へ戻す。

可観測性 / 検証 条件付き

No-op（適用外）。可観測性の目標設計は更新するが、メトリクス、Amazon CloudWatch Alarm、実行時動作、AWS 環境は変更しない。

ロールバック 条件付き

本 PR の文書コミットを revert する。実行環境のロールバックは不要。

リリース連携（推奨）

• リリースノート: 不要

テスト結果 / 検証手順

• npm run lint:md: 成功（66 files、0 errors）
• git diff --check: 成功
• 変更対象 Markdown 5 ファイルのローカルリンク確認: リンク切れなし
• commitlint: 成功

メモ（レビューポイント）

• 現行実装と B2C 目標構成が明確に区別されているか
• 購入ジャーニーの success / technical_failure / 除外の境界と、正規入場後の 429 の扱いが妥当か
• 同期購入処理時間と決済結果解決時間を別の SLI にする境界が妥当か
• Fastify onRequestと3つの終端hookで切断・timeoutを含め1回だけ記録する境界が妥当か
• 4 API 個別 p95 を正式 SLO とし、ジャーニー予算・p99・Outcome 別合算を非 SLO とする責務分担が妥当か
• 決済結果解決時間を payment attempt 単位で計測し、Purchase Session あたり最大3回とする境界が妥当か
• 同期解決を正式 SLO、非同期解決を診断指標とし、未解決を成功レイテンシへ混ぜない構造が妥当か
• 3秒・5秒・30秒・60秒の順序と、stale payment_processingの60秒を通信timeoutから分離する設計が妥当か
• transport失敗とFake Payment APIの5xxを安全側のpayment_unknownへ寄せ、commit後にHTTP 202 Acceptedを返す境界が妥当か
• payment_unknown件数Alarmを維持し、閾値とseverityをstaging-full後に決める責務分担が妥当か
• ADRだけでなく、一次販売と可観測性の正本に現在の目標設計が記録されているか
• 転換前の C2C 実測値・SLO・ADR が歴史的記録として適切に扱われているか

Closes #321

[amazon-q-developer]

This documentation PR effectively records the B2C platform transition design. The ADRs clearly document the decision rationale, the primary-ticket-sales.md provides comprehensive flow specifications, and capacity-planning.md rigorously distinguishes measured data from assumptions. The documents appropriately mark this as target design (未実装) and maintain historical C2C records. No defects found that block merge.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.