gwt-spec: Component・プロパティ管理

[akiojin]

Spec

Background

ドメイン仕様書: Component・プロパティ

作成日: 2026-04-05
ステータス: active

GameObject上のComponent（Rigidbody、Collider、Light、Camera等）の追加・削除・変更・一覧取得・検索機能、およびSerializeFieldの値更新機能を統合するドメイン。LLMがUnity Componentを直接操作し、ゲームオブジェクトの動作・物理・レンダリング設定を自動化する。Component設定の自動化によりInspectorでの手動設定を排除し、動的なゲーム設定やデバッグの可視化を実現する。

Ubiquitous Language

TODO

User Stories

TODO

Acceptance Scenarios

TODO

Edge Cases

TODO

Functional Requirements

TODO

Non-Functional Requirements

TODO

Success Criteria

TODO

---

Domain-Specific Details

対象コマンド群

• component add - Component追加（型指定、初期プロパティ設定）
• component remove - Component削除（インデックス指定対応）
• component modify - Componentプロパティ変更（Vector3、Color等の複雑型対応）
• component list - GameObject上のComponent一覧取得
• component get-values - Componentプロパティ値取得（継承/プライベート除外オプション）
• component get-types - 追加可能なComponent型リスト取得（カテゴリフィルタ）
• component find-by - Component型によるGameObject検索（スコープ・派生型対応）
• component set-field - SerializeField値更新（dry-run、Prefab保存、PlayModeガード対応）

完了済み機能

• ✅ Component追加/削除/変更/一覧/検索/型取得（旧 機能仕様書: Component管理機能 #77）
  • 27個の機能要件を定義・実装済み
  • Component型検索、プロパティ取得（継承/プライベート除外）、非アクティブオブジェクト検索対応

Plan

SerializeField値更新ツール（旧 #66 より継承）

1. Phase 0: Research - SerializedPropertyパス表記、Prefab保存方針、PlayMode制約の調査
2. Phase 1: Design - ComponentFieldUpdateRequest/ComponentFieldUpdateResultのデータモデル定義、契約JSON Schema作成
3. Phase 2: TDD - Node側ハンドラテスト(RED)→実装→Unity側EditModeテスト
4. Phase 3: 実装 - Nodeハンドラ + Unity ComponentHandler拡張 + コマンド登録
5. Phase 4: 統合 - ドキュメント、ログ出力、LLM向けquickstart

設計決定事項（Research結果）

• フィールドパス: 入力は foo.bar[0].baz 形式、Unity側で .Array.data[n] に正規化
• Prefab保存: 資産直接編集は SaveAsPrefabAsset、Stage/シーンは RecordPrefabInstancePropertyModifications
• PlayMode: runtime:true 明示時のみ許可、構造変更は常に禁止
• dry-run: dryRun: true, previewValue, previousValue, resolvedPath, notes[] を返却
• 参照型: objectReference.guid 優先、assetPath フォールバック

Tasks

SerializeField値更新（旧 #66）

Phase 3.1: セットアップ

• research.md に SerializedPropertyパス表記・Prefab保存方針・PlayMode制約の調査結果を記載
• data-model.md で ComponentFieldUpdateRequest と ComponentFieldUpdateResult の属性・検証ルールを定義
• contracts/set_component_field.request.json と .response.json を作成
• quickstart.md に LLM利用者向けのドライラン→本適用→保存確認の手順を書く

Phase 3.2: テストファースト (RED)

• Node側ユニットテスト: 入力バリデーション・dry-run・Prefab適用・エラー分岐を網羅するREDテスト
• Unity側EditModeテスト: シーン/Prefab/dry-run/PlayModeブロックのEditModeテスト(失敗状態)

Phase 3.3: コア実装 (GREEN化)

• ComponentFieldSetToolHandler.js 実装（フィールドパス正規化・value型推論・dry-run処理）
• ComponentHandler.cs に SerializedProperty更新ロジック/Prefab保存/PlayModeガード実装
• UnityCliBridge.cs に set_component_field ルーティング追加

Phase 3.4: 統合・ドキュメント

• Node/Unityテストをすべて GREEN にする
• quickstart.md と README.md に dry-run→適用→保存のワークフローを反映

TDD

SerializeField値更新

• RED: Node側 ComponentFieldSetToolHandler.test.js に入力バリデーション・dry-run・Prefab適用・エラー分岐テスト
• RED: Unity側 ComponentHandlerTests.cs にシーン/Prefab/dry-run/PlayModeブロックテスト
• GREEN: 実装後にすべてのテストがパス
• REFACTOR: 重複コード削除、共通ユーティリティ抽出

旧Issue参照

• 機能仕様書: Component管理機能 #77 機能仕様書: Component管理機能 (完了)
• 機能仕様書: SerializeField 値更新ツール #66 機能仕様書: SerializeField 値更新ツール (下書き)