play-billing-library-version-upgrade

フェーズ 0：意図のメッセージ

報告アクション：作業を始める前に、直ちにユーザーに「Play Billing Library を最新バージョンにアップグレードします。」と伝えてください。

フェーズ 1：調査と状況把握

1. 主な確認事項（ビルドバージョン）：build.gradle、build.gradle.kts、または libs.versions.toml で、プロジェクトの課金関連の依存関係（例：com.android.billingclient:billing）を特定します。
2. 初回コンパイルテスト：直ちにプロジェクトの同期とビルドを試みます。
3. フォールバック調査（実効バージョン）：
   • 実行条件：ビルドが直ちに失敗した場合に限り、ソースコード内で非推奨のアーティファクトを検索します。
   • 判定方法：非推奨 API が存在する場合、その API が最後に利用可能だったバージョンを**「実効バージョン」**として扱います。導入されたバージョンではありません。
   • 例：SkuDetails が存在する場合、build.gradle のバージョン文字列に関係なく、ベースラインを PBL v7 以前として扱います。
4. 目標と移行経路の特定：バージョンツールまたはリリースノートを参照して最新の安定バージョンを確認し、実効バージョンのベースラインに基づいて [直接／段階的] な移行経路を算出します。

• 移行経路の算出：
  • 実効バージョンが目標バージョンからメジャーバージョンで 2 つ以内の場合：直接移行を計画します。
  • 2 つを超えて古い場合：段階的な移行を計画します。目標バージョンから 2 つ以内になるまで、メジャーバージョンを 2 つずつ進めます（例：v4 -> v6 -> v8）。
• 報告アクション：作業を始める前に、ユーザーに「実効バージョンは PBL [Current]、最新バージョンは [Target] であることを検出しました。[直接／段階的] な移行経路を計画しています。」と伝えてください。

フェーズ 2：関連ドキュメントのマッピングと計画

移行経路で特定されたメジャーバージョンの移行ごとに、以下の情報を必ずまとめて 指示を作成してください。

• 移行ガイド（[X] は移行先のメジャーバージョンです）。
• リリースの主な変更点：該当するリリースノートの「Deprecations」と「Breaking Changes」のセクション。
• 開発者向けドキュメント：このアプリで使われている機能（例：サブスクリプション、買い切り商品）に関する Google Play Billing ドキュメントの知識を参照してください。
• 計画の作成：必要なコード変更（API の削除、クラスの置き換え、ロジックの変更）をすべて特定し、チェックリストとして出力してください。

フェーズ 3：実行手順

報告アクション：以下の各手順について、実行前にこれから行う作業を簡潔に説明し、実行後に達成した内容を簡潔にまとめてください。

ステップ 1：SDK と環境の調整

• アクション：SDK 要件を満たすように build.gradle を更新します（例：「PBL 9 では compileSdk 35 が必要です」）。
• Gradle バージョン：新しいライブラリで、より新しい Android Gradle Plugin（AGP）または Kotlin バージョンが必要かどうかを確認します。

ステップ 2：意図に基づくリファクタリング

既存コードの意図を分析し、文字列を単純に置き換えるだけの対応は避けてください。

• アクション：[references/migration-logic.md] のセクション、公式の移行ガイド、フェーズ 2 で特定した一般ドキュメントのすべてに記載されている非推奨の指示とリファクタリングパターンに必ず従ってください。
• 検証：すべてのドキュメントに記載されたすべての手順を実施していることを確認し、さらに、references のチェックリストにある具体的な指示にも従っていることを確認します。

ステップ 3：段階的な検証（段階的な移行にのみ適用）

1. 移行経路で最初の中間メジャーバージョンにアップグレードします。
2. ./gradlew assembleDebug を実行して、中間バージョンでの破壊的変更を見落としていないことを確認します。
3. 最終目標バージョンに到達するまで、手順を繰り返します。

ステップ 4：最終検証チェックリスト

1. スマートチェックリストの検証：
2. references/version-checklist.md を開き、バージョン固有のスマートチェックリストを確認します。
3. アクション：[検出された現在のバージョン] と [検出された新しいバージョン] の間にあるすべてのバージョンについて、「ファイル内検索」または構造解析を使って、すべての項目がコードで対応されていることを確認します。
4. テスト：すべての単体テストと実装テストを実行します（./gradlew test）。
5. クリーンビルド：プロジェクト全体のクリーンビルドが完了することを確認します：./gradlew clean assembleDebug。続いて、./gradlew sync と ./gradlew build を実行し、ユーザーが新しいバージョンをすぐに手動でテストできるようにします。

最終レポート

開発者に「理由」を説明します：

• 「PBL [バージョン] で必要なため、SDK を [バージョン] に更新しました（理由はドキュメントを参照）。」
• 「カスタムの retryConnection() ロジックを削除しました。ライブラリが enableAutoServiceReconnection() を使ってネイティブに処理するようになったためです。」
• 「PBL [旧バージョン] から PBL [新バージョン] へのアップグレードが完了し、単体テストで検証済みです。最新ライブラリの機能と、このアプリケーションの現在の機能セットを分析した結果、最新リリースの [新機能]（例：プリペイドプランまたは分割払い）の導入を検討することをおすすめします。この機能は現在利用可能ですが、まだ実装されていません。」