Rust AI 네이티브 게임 엔진 로드맵: 에디터 저장 경계 연구 및 6개의 콘텐츠 초안 PR

# Editor Save/Close Path Audit and Prioritized Plan

## 1. What the save paths actually guarantee

### Root close handling (`crates/orr_editor/src/app.rs`)
- Root close is handled as a window/close event that tears down the editor session. There is no per-document dirty gate before teardown; the close path does not enumerate open documents, panels, or pending edits.
- Consequence: a root close is a **process-level exit**, not a document-level save. It cannot be treated as a save request.

### Scene dirty tracking (`crates/orr_editor/src/editor.rs`)
- Dirty state is tracked at the scene/document level (a flag flipped on mutation). A "Scene Save" clears the scene dirty flag after the scene serialization step.
- The dirty flag is **scene-scoped only**. It does not observe sprite panel edits or UI panel edits, so those mutations do not set it and are not covered by the save.

### `sprite_panel.rs`
- Sprite panel edits mutate sprite state held by the panel/editor. A save request routed through the scene save path serializes the scene; it does **not** flush sprite panel state unless the panel explicitly writes on its own save action.
- Therefore: a Scene Save does **not** guarantee sprite state is written to disk.

### `collect_ui_panel.rs`
- Same shape as the sprite panel: UI collection edits live in panel state. The scene save path does not serialize this panel's state.
- Therefore: a Scene Save does **not** guarantee UI collection state is written to disk.

### Net answer per panel
| Panel | Does a save request guarantee a successful disk write? |
|---|---|
| Scene (editor.rs) | Only for scene-serialized data; success of the write itself is not confirmed back to the caller in the close path. |
| Sprite panel | **No.** Scene Save does not flush sprite panel state. |
| Collect UI panel | **No.** Scene Save does not flush UI collection state. |

## 2. Every place a Scene Save leaves sprite or UI state unsaved
1. Sprite panel edits made after the last scene save — scene dirty flag never set, so no save is even prompted.
2. Sprite panel edits made before a scene save — scene save serializes the scene, not the panel; panel state remains in memory only.
3. Collect UI panel edits made after the last scene save — same gap, dirty flag not set.
4. Collect UI panel edits made before a scene save — scene save does not serialize the panel.
5. Root close with any of the above pending — teardown discards panel state with no prompt.
6. Root close with scene dirty — teardown proceeds without a document-level confirmation gate.
7. Any save request whose disk write fails — the close path has no failure branch to keep the editor open.

## 3. Prioritized plan

### P0 — Close protection
**Goal:** Cancel root close on any dirty or unapplied document, with a "Keep editing" option. No global Save All. No auto-discard.

**Minimum scope**
- Add a pre-close check in the root-close handler in `app.rs` that queries: scene dirty flag, sprite panel dirty state, collect UI panel dirty state.
- If any is dirty/unapplied, cancel the close and surface a per-document prompt with "Keep editing" (and per-document save actions only).
- Track panel dirty state locally in `sprite_panel.rs` and `collect_ui_panel.rs` (set on mutation, cleared only on confirmed successful write).
- Treat a failed disk write as "still dirty" and keep the editor open.

**Explicit exclusions**
- No global "Save All" button or shortcut.
- No auto-discard / auto-save on close.
- No changes to public APIs or dependencies.
- No new serialization formats; reuse existing scene/panel save routines.

**Acceptance criteria**
- Closing with any dirty scene, sprite, or UI document cancels the close and shows "Keep editing".
- Choosing "Keep editing" leaves all documents open and unmodified on disk.
- Repeated cancel (N times) leaves every file byte-identical: file contents and checksums unchanged across all cancels.
- A failed write keeps the document dirty and the editor open.
- No Cargo build is run while a build lease is held.

### P1 — Read-only capability and export-readiness summary
**Goal:** Show a read-only summary of capabilities and export readiness derived from actual feature flags, reusing existing diagnostics stats. Do not relabel CPU stats as GPU.

**Minimum scope**
- Add a read-only panel/section that reads existing feature-flag state and existing diagnostics stats.
- Present export-readiness as a derived summary from those flags (e.g., which export paths are enabled).
- Label stats by their true source (CPU stays CPU; GPU only if a GPU source exists).

**Explicit exclusions**
- No new feature flags or dependency changes.
- No public API changes.
- No relabeling or re-attribution of existing stats.
- No write actions from this panel.

**Acceptance criteria**
- Summary reflects actual feature-flag values at runtime; toggling a flag (via existing mechanisms) updates the summary without code changes.
- Diagnostics stats shown match existing sources with correct CPU/GPU labels.
- Panel is read-only: no file writes, no state mutation.
- Repeated open/close of the summary leaves all files byte-identical (checksums unchanged).
- No Cargo build while a build lease is held.

## 4. Reference contracts (public docs only)
- Unity Editor: `EditorWindow.OnGUI`, `EditorApplication.wantsToQuit`, `EditorSceneManager.SaveScene` — cited for the "cancel quit on dirty" contract pattern only.
- Unreal: `FEditorDelegates::OnEditorClose`, `UEditorEngine::RequestEndPlayMap` — cited for close-cancellation contract only.
- Godot: `EditorPlugin._get_unsaved_scenes`, `NOTIFICATION_WM_CLOSE_REQUEST` — cited for unsaved-scene enumeration contract only.

No code was copied or translated from these engines; only their documented contracts informed the plan shape.