Entity class_existsガード記事の回帰バグ追記を解決済みに更新

articles/eccube44-entity-class-exists-guard.md

@@ -48,16 +48,16 @@ if (!class_exists(Category::class)) {
 
 - EC-CUBE 4.4 で `src/Eccube/Entity/` の `if (!class_exists())` ガードが全廃される（[PR #6895](https://github.com/EC-CUBE/ec-cube/pull/6895)）
 - ガードの正体は、元ソースと `app/proxy/entity` 配下の proxy という**同一 FQCN の2ファイル**を `require_once` したときの redeclare fatal 回避
-- `EntityProxyService::scanTraits()` と `TraitProxyAttributeDriver` を proxy 対応にすることでガードを不要にした。**ただしこれでは足りず、マージ後に回帰バグが出ています**（後述）
+- `EntityProxyService::scanTraits()` と `TraitProxyAttributeDriver` を proxy 対応にすることでガードを不要にした。**ただしこれでは足りず、マージ後に回帰バグが出た。2026年7月31日に修正がマージされて解決済み**（後述）
 - 副作用として、`app/Customize/Entity` に置いた単独 Entity を trait 拡張しても列がマッピングされない潜在バグも同時に解消された
 - プラグイン生成コマンドのスケルトンが吐くガードは、このPRには含まれていない（`4.4` ブランチでも現存）
 
 :::message alert
-**追記（2026年7月27日）**
+**追記（2026年7月31日）修正がマージされ、解決しました**
 
-この記事の主題である #6895 は、マージ後に回帰バグが見つかりました。ガードを外した結果、特定の構成で `Cannot declare class` が発生し、全リクエストと `cache:clear` が失敗します。
+この記事の主題である #6895 は、マージ後に回帰バグが見つかりました。ガードを外した結果、特定の構成で `Cannot declare class` が発生し、全リクエストと `cache:clear` が失敗する状態でした。
 
-自分でも手元で再現させ、最初の修正案では塞ぎきれない経路を見つけて報告しました（[#6979](https://github.com/EC-CUBE/ec-cube/issues/6979)）。現在は方式を変えた [#6982](https://github.com/EC-CUBE/ec-cube/pull/6982) で対応が進んでいますが、この記事を書いている時点ではまだマージされていません。詳しくは末尾の「その後、回帰バグが見つかった」を読んでください。
+自分でも手元で再現させ、最初の修正案では塞ぎきれない経路を見つけて報告しました（[#6979](https://github.com/EC-CUBE/ec-cube/issues/6979)）。方式を変えた [#6982](https://github.com/EC-CUBE/ec-cube/pull/6982) が 2026年7月31日に `4.4` へマージされ、Issue もクローズされています。**現在の `4.4` ブランチにこのバグは残っていません。** 経緯は末尾の「その後、回帰バグが見つかった」に書いています。
 :::
 
 ## そもそも、なぜあのガードが必要だったのか
@@ -281,7 +281,7 @@ class Category extends AbstractEntity implements \Stringable
 
 ## その後、回帰バグが見つかった
 
-ここからは公開後の追記です（2026年7月27日）。
+ここからは公開後の追記です（2026年7月27日に追記、7月31日に決着を反映）。
 
 #6895 のマージから9日後、[PR #6963](https://github.com/EC-CUBE/ec-cube/pull/6963) が出ました。**#6895 の回帰バグ修正**です。ガードを外したことで、こうなる環境が出ました。
 
@@ -363,13 +363,17 @@ $container->addCompilerPass(
 
 こちらも手元で確認しました。上の3ケースはすべて解消し、素の構成でもマッピング数に増減はありませんでした。同一プラグイン内に「剥がす対象」と「残す対象」を同居させるケース、プロジェクトをシンボリックリンク経由で参照するケースも通っています。
 
-ただしこの PR は、この記事を書いている時点で**まだマージされていません**。つまり `4.4` ブランチには今もこのバグが残っています。
+この PR は **2026年7月31日に `4.4` へマージされました**。報告した #6979 も同時にクローズされています。
+
+差分は10ファイル `+944 / -0` で、削除行がゼロです。新規のコンパイラパスが170行、`Kernel.php` への追加が15行、残り759行はテストとフィクスチャでした。既存の行を1行も書き換えずに塞いだことになります。
+
+`doctrine.yaml` には手が入っていません。#6963 の `EccubeBundle: false` は取り込まれず、バンドル名を名指しする方式は消えました。
 
 ### 4.4 リリース時にどうなっているか
 
-一連の経緯は #6895（ガード全廃）→ #6963（コアだけ塞ぐ）→ #6979（穴の報告）→ #6982（一般化して塞ぐ）という流れです。#6982 の方式ならバンドル名に依存しないので、同じ系統の再発は起きにくいはずです。
+一連の経緯は #6895（ガード全廃）→ #6963（コアだけ塞ぐ）→ #6979（穴の報告）→ #6982（一般化して塞ぐ）という流れです。#6982 の方式ならバンドル名に依存しないので、同じ系統の再発は起きにくいはずです。回帰テストも `AutoMappedEntityPathsBootTest` として入ったので、直下バンドル構成で boot まで通ることが CI で守られます。
 
-とはいえ #6895 は 76ファイル `+14,030/-13,968` の大規模変更で、リリース直前に別の踏み方が見つかれば丸ごと戻すという判断もあり得ます。この記事の内容が 4.4 リリース時点でそのまま残っているとは限りません。ガード全廃を前提にした対応は、リリース版を確認してから進めてください。
+`4.4` はまだリリース前です。#6895 は76ファイル `+14,030/-13,968` の大規模変更なので、リリースまでに別の踏み方が出てくる可能性は残ります。ガード全廃を前提にした対応を進めるなら、実リリース版で最終確認してください。
 
 ### 何が教訓か
 
@@ -385,7 +389,7 @@ $container->addCompilerPass(
 - 副作用で `app/Customize/Entity` の単独 Entity が trait 拡張できるようになった（挙動が変わるので移行時は確認推奨）
 - 自作プラグインのガードは急いで外す必要はないが、コア Entity を手動 `require` しているコードがあれば 4.4 では危険
 - `eccube:plugin:generate` のスケルトンには、`4.4` ブランチ時点でまだガードが残っている
-- **マージ後に回帰バグが出た。[#6982](https://github.com/EC-CUBE/ec-cube/pull/6982) で対応中だが、まだマージされていない**（経緯: [#6963](https://github.com/EC-CUBE/ec-cube/pull/6963) → [#6979](https://github.com/EC-CUBE/ec-cube/issues/6979) → #6982）
+- **マージ後に回帰バグが出たが、[#6982](https://github.com/EC-CUBE/ec-cube/pull/6982) が2026年7月31日にマージされて解決済み**（経緯: [#6963](https://github.com/EC-CUBE/ec-cube/pull/6963) → [#6979](https://github.com/EC-CUBE/ec-cube/issues/6979) → #6982）
 
 :::message alert
 EC-CUBE 4.4 はこの記事を書いている時点（2026年7月）で未リリースです。`4.4` ブランチにマージ済みの内容をもとに書いていますので、リリース時には細部が変わる可能性があります。