docs: プロジェクトの忌憚ない評価レポートを追加

docs/02_spec_design/PROJECT_EVALUATION_CANDID.md

@@ -0,0 +1,126 @@
+# プロジェクト評価（忖度なし版）
+
+**対象**: Elixir × Rust ゲームエンジン（Vampire Survivor / MiniShooter）  
+**評価日**: 2026-02-25  
+**目的**: 気持ちの良い総括ではなく、次の意思決定に使うための現実的評価
+
+---
+
+## 結論（先に要点）
+
+このプロジェクトは「技術的に面白いデモ」段階は超えており、実装密度も高い。  
+ただし、現状のまま機能追加を続けると、**デバッグ難易度**と**保守コスト**が先に限界を迎える可能性が高い。
+
+一言で言うと:
+
+> **方向性は正しい。だが、拡張前に土台の保守性を上げないと失速する。**
+
+---
+
+## 1. 良い評価（事実として強い点）
+
+### 1.1 設計方針がぶれていない
+
+- Elixir（監視・遷移・運用）と Rust（高頻度計算・描画）の分担が明確。
+- `Engine.Game` / `Engine.SceneBehaviour` によってゲーム差し替え可能性が担保されている。
+- VampireSurvivor と MiniShooter の同居実績があり、「汎用化」が口だけではない。
+
+### 1.2 パフォーマンス前提の実装が本物
+
+- SoA、空間ハッシュ、フリーリスト、SIMD/並列化など、必要な最適化が実コードに入っている。
+- Rust 側で 60Hz ループを主導し、境界呼び出しの粗さを吸収している。
+- 描画スレッド分離・スナップショット化の方針も妥当。
+
+### 1.3 ドキュメント品質が高い
+
+- WHY/STEP/設計資料が揃っており、意思決定の履歴が追える。
+- これは中長期の保守で効く（属人化しにくい）。
+
+---
+
+## 2. 悪い評価（目をそらすと危ない点）
+
+### 2.1 いちばん危険: 「デバッグが重すぎる」
+
+- NIF 境界を跨ぐ不具合の切り分けコストが高い。
+- Rust panic は本質的に BEAM 側の開発体験を壊しやすい。
+- debug 系の仕組みはあるが、日常開発で「速く原因に辿り着ける」状態にはまだ足りない。
+
+**影響**: バグ修正速度が落ち、機能追加の成功率まで下がる。
+
+### 2.2 機能より先に保守性が詰まり始めている
+
+- 中心ファイル・中心処理への責務集中が見える。
+- この状態で 3D / Slot / コンポーネントを同時進行すると、変更リスクが急増する。
+
+**影響**: 仕様追加のたびに壊れやすくなり、心理的にも手を入れにくくなる。
+
+### 2.3 仕様と実装のズレが残っている
+
+- Step 47 系（Skeleton / Ghost / Garlic）未完了は、技術的には小さく見えても信頼性には効く。
+- ドキュメント読者に「実装済み」と誤解を与える余地がある。
+
+**影響**: 開発判断の前提が揃わず、優先順位の議論がぶれる。
+
+### 2.4 チーム拡張耐性は高くない
+
+- Elixir + Rust の複合開発は強力だが、学習コストも高い。
+- 個人/少人数なら回るが、人数増加時のオンボーディング負荷は大きい。
+
+**影響**: スケールしたくなった時に採用・育成がボトルネックになる。
+
+---
+
+## 3. 判定（5段階）
+
+| 観点 | 評価 | コメント |
+|---|---|---|
+| アーキテクチャ妥当性 | A | 方針は明確で合理的 |
+| 実装完成度（2D現行範囲） | B+ | コアは強いが未完了項目あり |
+| 性能設計 | A- | 実装は良い。今後は観測性強化が鍵 |
+| 保守性 | C+ | 責務集中と境界デバッグが重い |
+| 開発体験 | C | 調査速度が遅くなりやすい |
+| 将来拡張の安全性 | C | 今のまま機能追加すると危険 |
+
+---
+
+## 4. 今やるべきこと（優先順位つき）
+
+### 最優先（1〜2スプリント）
+
+1. **デバッグ導線の改善**
+   - Rust ログと Elixir ログを一元的に追える形へ寄せる。
+   - 「落ちた時に何を見るか」を手順化して短縮する。
+2. **責務分割の先行投資**
+   - 中心処理の分解を先に進める（大機能追加より前）。
+3. **Step 47 完了で仕様整合**
+   - Skeleton / Ghost / Garlic を完了し、ドキュメントと実装の差分を閉じる。
+
+### 次点（次四半期）
+
+4. **結合/E2E テストの追加**
+   - 起動→プレイ→遷移→ゲームオーバーまでの回帰を自動化。
+5. **3D と Slot は同時着手しない**
+   - どちらか片方を先行し、もう片方は設計検証に留める。
+
+---
+
+## 5. 経営的・プロダクト的観点での率直評価
+
+- このプロジェクトは「技術力の証明」としては既に強い。
+- しかし、プロダクトとして継続的に機能を積むフェーズへ入るには、今の開発体験は重い。
+- つまり課題は「性能」ではなく、**変更容易性と不具合調査速度**。
+
+言い換えると:
+
+> 速く動くエンジンはできている。  
+> 次は「速く直せるエンジン」にする段階。
+
+---
+
+## 6. 最終コメント（忌憚なく）
+
+このプロジェクトは、発想・実装力・継続力の3点で明確に高水準。  
+一方で、ここから先は「新機能を作る力」よりも「壊さず進める力」が勝負になる。
+
+**いま拡張を急ぐより、保守性とデバッグ性に2〜4週間投資した方が、最終到達速度は確実に上がる。**