Appearance
Factory Mapping Next Sprint Plan
目的
- Factory Mapping を「試作UI」から「運用可能な配置設計ツール」へ進める。
- 直近の高優先4機能を、1-2週間単位の実行可能な計画に分解する。
- 既存 Daedalus / Drafting への影響を避け、Factory Mapping モジュール内で完結させる。
対象スコープ
- レイヤー管理
- ルールベース検証
- バージョン比較
- アセット台帳連携
前提
- 既存実装: 2D/3D/Inspector、JSON import/export、schemaVersion migration は実装済み。
- 既存制約: 既存CAD機能へ非干渉（新規機能は FactoryMapping 配下に限定）。
リリース方針
- 各スプリントで「操作可能なUI + 保存可能なデータ + 最低限の検証」を揃える。
- 後続スプリントで拡張する前提で、最初は単純ルールで始める。
Sprint 1 (1週間): レイヤー管理 MVP
ゴール
- オブジェクトをレイヤー単位で表示/非表示、ロック/アンロックできる。
- レイヤー状態が保存/復元される。
実装項目
- 型拡張
- layerId を FactoryObject に追加。
- FactoryMappingProject に layers 配列を追加。
- Layer 型: id, name, color, visible, locked, category。
- ストア
- addLayer, updateLayer, removeLayer, assignObjectToLayer。
- visible/locked を編集操作に反映（locked は move/resize/delete 禁止）。
- UI
- LayerPanel 追加（作成、色、表示、ロック、選択中オブジェクトのレイヤー変更）。
- Canvas2D/Viewer3D で visible 連動。
- 永続化
- export/import 対応、migration にデフォルトレイヤー補完追加。
受け入れ基準
- hidden レイヤーのオブジェクトは 2D/3D 両方で非表示。
- locked レイヤーのオブジェクトはドラッグ・リサイズ・削除不可。
- export -> import でレイヤー状態が維持される。
見積
- 開発: 3日
- テスト/調整: 2日
Sprint 2 (1週間): ルールベース検証 MVP
ゴール
- 配置違反を自動検出し、一覧とハイライトで修正可能にする。
実装項目
- ルールエンジン雛形
- validateProject(project): ValidationIssue[]
- issue: id, severity, ruleId, objectIds, message, suggestion。
- ルール初期セット
- minimum-clearance（設備間・設備と壁の最小離隔）
- egress-width（避難通路幅）
- forbidden-zone-placement（禁止ゾーン配置）
- UI
- ValidationPanel（issue一覧、対象へフォーカス、フィルタ）。
- 2D上で違反オブジェクトを赤枠/バッジ表示。
- 性能
- 変更時は対象差分のみ再検証（全件再計算を避ける）。
受け入れ基準
- 3ルールが動作し、issue をクリックすると対象へフォーカス。
- ルール閾値を設定変更後に再検証できる。
- 500オブジェクト規模で再検証の体感遅延が許容範囲。
見積
- 開発: 4日
- テスト/調整: 1日
Sprint 3 (1-2週間): バージョン比較
ゴール
- 2つのレイアウト版を比較し、追加/削除/移動/属性変更を可視化する。
実装項目
- データモデル
- revisions: id, name, createdAt, author, snapshot。
- 差分計算
- object id ベースの add/delete/change 判定。
- transform 差分しきい値（微小差分ノイズ除外）。
- UI
- RevisionSelector（A/B選択）
- DiffOverlay（色分け: 追加=緑、削除=赤、変更=黄）
- DiffSummary（件数、カテゴリ別）
- 既存履歴との整合
- undo/redo とは分離して revision compare を扱う。
受け入れ基準
- 任意2版を比較し、差分件数と対象ハイライトを表示。
- 大量差分時でもUI操作が破綻しない。
- 差分結果を JSON でエクスポート可能。
見積
- 開発: 6-7日
- テスト/調整: 2-3日
Sprint 4 (1-2週間): アセット台帳連携
ゴール
- 設備オブジェクトに台帳情報を紐づけ、検索・状態確認・期限表示が可能。
実装項目
- データ接続
- 外部API連携は抽象化（adapter層）して将来切替可能に。
- 初期はモック/ローカルJSONでも同一IFで動作。
- オブジェクト拡張
- assetId, maintenanceDue, riskScore, statusSource を metadata 標準項目化。
- UI
- AssetLookup（assetId 検索・候補選択）
- Inspector で台帳情報表示
- 期限切れ/高リスクの可視化（色/バッジ）
- 同期
- 手動再同期、失敗時リトライ、最終同期時刻表示。
受け入れ基準
- assetId 紐づけ後、台帳情報が Inspector に反映。
- 期限切れ設備を一覧抽出できる。
- API失敗時にUIが固まらずエラー表示される。
見積
- 開発: 6-7日
- テスト/調整: 2-3日
共通テスト計画
- 単体
- store actions
- validation rules
- diff engine
- 結合
- export/import + migration 整合
- レイヤー/検証/比較/台帳の相互干渉
- E2E
- 代表ユーザーフロー 5本
- レイヤー作成 -> ロック -> 編集拒否
- 違反発生 -> 修正 -> issue 解消
- 版A/B比較 -> 差分確認
- asset 紐づけ -> 期限警告表示
- 保存復元後に状態維持
- 代表ユーザーフロー 5本
リスクと対策
- ルール検証が重くなる
- 対策: spatial index 活用、差分再検証。
- モデル拡張で migration が複雑化
- 対策: migration table を version 単位で固定。
- 連携API依存で開発停滞
- 対策: adapter + mock を先行実装。
すぐ着手する実装順
- Sprint 1 の型拡張と store 実装
- LayerPanel 追加と Canvas/3D 連動
- migration + export/import 検証
- E2E 1本追加
完了定義 (Definition of Done)
- 機能UIが操作可能。
- 保存/復元で状態が壊れない。
- 最低1本のE2Eが通る。
- 既存 FactoryMapping 機能の回帰がない。
