[doublepi123]

Bump the fork release to v1.2.27-dp2 (.release-version + versionName). Merging triggers release.yml, which publishes a signed build that includes the DoubleCode rename (#6) and the GitHub client ID (repo variable AND_CODE_GITHUB_CLIENT_ID). versionCode stays 66 (same signing key, so dp1 -> dp2 installs over the top).

Pre-PR review

判定: APPROVE

ブロッカー

なし

提案（非ブロッキング）

• app/build.gradle.kts:128 で versionCode を 66 のまま据え置く件について。同じ署名鍵なら同じ versionCode でも上書きインストールできます。Android が拒否するのは versionCode を下げる場合だけなので、理解のとおりです。ただし、注意点が 2 つあります。
  • 更新検知：versionCode を見て更新を判断するツールは、dp2 を更新と見なしません。F-Droid 互換クライアントや一部のストアがこれに当たります。この fork では fdroid-repository.yml:26 のガードで F-Droid リポジトリを公開していないので、現状は影響がありません。ただ、Obtainium などを使う利用者がいる場合は、更新通知が出ない可能性があります。
  • 将来の upstream 同期：upstream が versionCode を 67 以上に上げたとき、fork の versionCode が upstream の追従でしか動かない状態だと、dp 版同士を区別できなくなります。次の fork リリースからは、versionCode を上げて ReleaseMetadataTest.kt:13 の期待値も合わせて更新する運用にすると安全です。テストを変えると upstream との差分になるので、今回のように据え置く判断も合理的です。
• dp1 から dp2 への上書きインストールでは、両方が同じ keystore で署名されていることが前提です（RELEASE_KEYSTORE_BASE64 などの secret を変えていないこと）。secret を差し替えている場合は、署名の不一致でインストールが失敗します。
• リリースが起動するのは、PR を人間のアカウント（UI や、ユーザー認証の gh pr merge）でマージしたときです。GITHUB_TOKEN で動く Action からマージすると、その push イベントでは別のワークフローが起動しません。dp1 のリリースが同じ手順で起動したなら問題ありません。

チェック済み項目

• ReleaseMetadataTest との整合：.release-version が v1.2.27-dp2 で、先頭の v を除くと 1.2.27-dp2 になります。app/build.gradle.kts:129 の versionName = "1.2.27-dp2" と一致します。versionCode = 66 も ReleaseMetadataTest.kt:13 の期待値と一致します。
• 古い値の残り：リポジトリ内で dp1 / dp2 / 1.2.27 を検索しました。dp1 は残っていません。docs/RELEASE.md に 1.2.27 の記述がありますが、upstream の F-Droid metadata のある時点のスナップショットについての説明なので、更新は不要です。
• release.yml の起動条件：push、branches: [main]、paths: ['.release-version', ...] の組み合わせなので、.release-version を変えたコミットが main にマージされれば起動します。タグは release.yml:104 で .release-version から v1.2.27-dp2 として読み出されます。gh release view で既存のリリースが無いと判定されると、gh release create --target ${{ github.sha }} で新しいリリースとタグが作られます。dp1 とはタグ名が違うので衝突しません。
• GitHub Client ID：release.yml:78 で vars.AND_CODE_GITHUB_CLIENT_ID を GITHUB_CLIENT_ID として渡し、app/build.gradle.kts の githubClientId から BuildConfig に埋め込まれる経路を確認しました。github flavor の debug / release の両方に入ります。fdroid の APK では env -u で意図的に外されています。
• 差分の範囲について：shell が使えないため git diff は実行していません。報告どおり 2 か所が変わっていることを、ファイルの現在値で確認しました。i18n、Kotlin コード、テストに変更はありません。