feat: add editor project switching workflow

docs/issues/Editor模块_CMake直链Release版XCEngine库破坏配置一致性3.28.md

@@ -0,0 +1,78 @@
+# Editor模块 CMake直链Release版XCEngine库破坏配置一致性
+## 1. 问题定义
+
+当前 editor 可执行目标的链接方式仍然是硬编码文件路径：
+
+- [`editor/CMakeLists.txt`](D:\Xuanchi\Main\XCEngine\editor\CMakeLists.txt)
+
+当前写法：
+
+- `target_link_libraries(... ${CMAKE_CURRENT_SOURCE_DIR}/../build/engine/Release/XCEngine.lib)`
+
+这不是正常的 CMake target 依赖，而是直接绑死到一个磁盘上的 `Release` 静态库文件。
+
+---
+
+## 2. 当前影响
+
+这会导致几个非常实际的问题：
+
+1. Debug editor 也可能链接到旧的 Release 版引擎库
+2. editor 对 `XCEngine` 目标没有真实依赖关系
+3. 引擎库变更后，editor 可能不会按正确配置自动重建
+4. Debug / Release 混链风险被隐藏
+
+当前本地状态就能看到：
+
+- `build/engine/Debug/XCEngine.lib`
+- `build/engine/Release/XCEngine.lib`
+
+两者时间戳和体积明显不同，但 editor 目标仍然硬连 Release 文件。
+
+---
+
+## 3. 为什么这是重大缺陷
+
+这条会直接污染后续 Viewport 对接的开发过程：
+
+- 你以为 editor 正在吃最新的 Renderer / RHI 改动
+- 实际上它可能仍在链接旧的 Release 库
+
+这样一来：
+
+- viewport 接入问题很难调
+- Debug 行为和 Release 行为可能不一致
+- CI / 新机器 / 干净构建环境也更容易炸
+
+它不是“代码风格问题”，而是构建依赖关系本身不正确。
+
+---
+
+## 4. 建议方案
+
+应改成标准 CMake target 依赖：
+
+1. editor 直接链接 `XCEngine`
+2. 不再手写 `../build/engine/Release/XCEngine.lib`
+3. 由 CMake 自己处理 Debug / Release / RelWithDebInfo 的库选择
+4. editor/include 路径和 link 关系都从 target 传播，而不是继续手写 build 输出路径
+
+---
+
+## 5. 验收标准
+
+完成后至少应满足：
+
+1. `editor` 目标通过 `target_link_libraries(... XCEngine)` 链接引擎
+2. Debug editor 自动吃 Debug `XCEngine`
+3. Release editor 自动吃 Release `XCEngine`
+4. 修改 engine 后重新构建 editor 时，依赖关系正确生效
+5. 干净构建环境不依赖预先存在的某个磁盘库文件
+
+---
+
+## 6. 优先级
+
+中高。
+
+它未必第一时间阻塞面板 UI 开发，但会显著污染后续所有 viewport / renderer 联调结果，建议尽快修。

docs/issues/Editor模块_宿主渲染与EngineRHI未统一导致Viewport纹理无法接入3.28.md

@@ -0,0 +1,94 @@
+# Editor模块 宿主渲染与EngineRHI未统一导致Viewport纹理无法接入
+## 1. 问题定义
+
+当前 editor 的窗口宿主渲染仍然是一套独立的原生 D3D12 路径：
+
+- [`editor/src/Application.h`](D:\Xuanchi\Main\XCEngine\editor\src\Application.h)
+- [`editor/src/Application.cpp`](D:\Xuanchi\Main\XCEngine\editor\src\Application.cpp)
+- [`editor/src/Platform/D3D12WindowRenderer.h`](D:\Xuanchi\Main\XCEngine\editor\src\Platform\D3D12WindowRenderer.h)
+
+这套路径只负责：
+
+- 创建 Win32 窗口交换链
+- 创建独立的 `ID3D12Device / ID3D12CommandQueue`
+- 渲染 ImGui 主界面
+
+而当前引擎的 RHI / Renderer 则是另一套独立设备与上下文体系。
+
+这意味着后续即使 Renderer 能把 `SceneView/GameView` 渲染到离屏目标，editor 侧也没有稳定的统一设备桥接层把那张纹理安全地贴到 ImGui。
+
+---
+
+## 2. 当前现状
+
+当前 `Application::InitializeWindowRenderer()` 直接创建原生 D3D12 宿主：
+
+- editor 只知道 `Platform::D3D12WindowRenderer`
+- editor 并不持有 `RHIDevice / RenderContext / RenderSurface`
+- `SceneViewPanel / GameViewPanel` 也没有可复用的 viewport host 对象
+
+结果是：
+
+- editor 主界面渲染和引擎 Renderer 渲染仍然分裂
+- 未来 viewport 要么走不通
+- 要么被迫写一层高风险的 D3D12 私有纹理互拷/句柄桥接
+- 要么反向污染 Renderer，使其去适配 editor 私有宿主
+
+---
+
+## 3. 为什么这是重大缺陷
+
+这不是“面板里还没把图显示出来”的小缺口，而是 viewport 接入的根部边界问题。
+
+如果不先统一宿主层，后面很容易走成错误路线：
+
+- Editor 继续维护一套私有 D3D12 设备
+- Renderer 再维护一套引擎 RHI 设备
+- `SceneView` 和 `GameView` 为了显示纹理被迫做后端专用互操作
+- Vulkan / OpenGL 路径在 editor 中天然失去接入可能
+
+这会直接破坏：
+
+- RHI 抽象边界
+- Renderer 的后端无关性
+- 后续 editor viewport 与 runtime 共用同一渲染链路的目标
+
+---
+
+## 4. 建议方案
+
+正确方向应该是：
+
+1. editor 宿主层只保留“窗口 + ImGui 宿主”职责
+2. viewport 输出统一来自引擎 Renderer 的 `RenderSurface`
+3. editor 增加专门的 viewport bridge / host 层，而不是把渲染实现塞进 panel
+4. 该 bridge 层需要明确处理：
+   - 使用哪个 RHI backend
+   - 如何创建离屏 color/depth 目标
+   - 如何把离屏结果暴露为 ImGui 可显示纹理
+   - resize 生命周期
+   - device/context 所有权
+
+建议不要继续扩张 `D3D12WindowRenderer` 的职责。
+
+它可以继续作为 editor 主窗口 UI 宿主，但不应成为 viewport 真实渲染实现本体。
+
+---
+
+## 5. 验收标准
+
+完成后至少应满足：
+
+1. editor 可以不依赖私有 D3D12 纹理路径来显示 viewport
+2. `SceneView` 和 `GameView` 都走统一的 viewport host 接口
+3. viewport 输出来自引擎 `RenderSurface`
+4. editor 不需要因为切换 OpenGL / D3D12 / Vulkan 而重写面板逻辑
+5. Renderer 不需要反向依赖 editor 平台实现
+
+---
+
+## 6. 优先级
+
+高。
+
+在开始正式做 Scene/Game Viewport 之前必须先收敛这个边界，否则后面的接入实现会天然带着架构债。

docs/issues/Editor模块_项目根路径仍绑定可执行目录阻塞真实场景与资源加载3.28.md

@@ -0,0 +1,87 @@
+# Editor模块 项目根路径仍绑定可执行目录阻塞真实场景与资源加载
+## 1. 问题定义
+
+当前 editor 初始化 `EditorContext` 时，把 project path 直接设成了可执行文件目录：
+
+- [`editor/src/Application.cpp`](D:\Xuanchi\Main\XCEngine\editor\src\Application.cpp)
+
+具体行为是：
+
+- 通过 `GetExecutableDirectoryUtf8()` 拿 exe 目录
+- 用这个目录初始化 `EditorContext`
+- `ProjectPanel` 和 `SceneManager::LoadStartupScene()` 都基于这个路径工作
+
+这意味着 editor 当前没有“真实工程根目录”的概念。
+
+---
+
+## 2. 当前影响
+
+基于当前实现：
+
+- `ProjectManager::Initialize()` 会把 `<projectPath>/Assets` 当作项目资源根
+- [`editor/src/Managers/ProjectManager.cpp`](D:\Xuanchi\Main\XCEngine\editor\src\Managers\ProjectManager.cpp)
+- [`editor/src/Core/EditorWorkspace.h`](D:\Xuanchi\Main\XCEngine\editor\src\Core\EditorWorkspace.h)
+
+但 `projectPath` 现在是 `editor/bin/...`
+
+结果就是：
+
+- Project 面板看到的是 exe 目录下的 `Assets`
+- Startup Scene 也是从 exe 目录下找 `Assets/Scenes/Main.xc`
+- viewport 后面如果要加载真实 scene / material / texture / mesh，也会默认走错根目录
+
+对“真正接引擎工程内容”来说，这是实打实的阻塞项。
+
+---
+
+## 3. 为什么这是重大缺陷
+
+Scene/Game Viewport 一旦接 Renderer，就不再只是“显示一个空测试图”。
+
+它需要基于当前工程：
+
+- 加载场景
+- 找到 mesh / material / texture / shader 资产
+- 正确解析 `Assets/...` 相对路径
+
+如果 editor 的项目根仍然绑定在 exe 目录：
+
+- 资源加载结果会和实际工程目录脱钩
+- Editor 和运行时看到的资产树不是同一棵
+- 后续 Project 面板、Scene 保存、Viewport 渲染都会形成伪项目环境
+
+---
+
+## 4. 建议方案
+
+建议尽快引入明确的工程根路径入口，而不是继续默认 exe 目录：
+
+1. `Application` 启动时明确解析 editor project root
+2. 最少先支持：
+   - 命令行传入工程根
+   - 或固定读取 workspace/project 配置
+3. `EditorContext / ProjectManager / SceneManager` 统一只认这一份 project root
+4. `ProjectPanel`、startup scene、future viewport asset loading 全部复用同一来源
+
+在没有真实 project root 之前，不建议开始做 viewport 里的正式资源接入。
+
+---
+
+## 5. 验收标准
+
+完成后至少应满足：
+
+1. editor 能明确知道当前工程根目录，而不是推断 exe 目录
+2. Project 面板显示的是工程真实 `Assets`
+3. Startup Scene 从真实工程根加载
+4. Scene/Game Viewport 后续使用的资源路径与 Project 面板一致
+5. Debug / Release / editor/bin 变化不会改变 editor 看到的项目内容
+
+---
+
+## 6. 优先级
+
+高。
+
+这条不解决，Viewport 接入后只会跑在一个“伪项目目录”里，后面越做越难回收。