feat: GUI 2.0 可视化计划、配置与资源管理重构

[ShiinaKuroko]

改造目标

GUI 2.0 将 AutoWSGR-GUI 从分散的快捷操作与旧式表单，重构为围绕 YAML 生命周期组织的桌面管理器。后端模型、字段和校验规则仍是唯一事实来源；GUI 负责可视化编辑、前置校验、持久化、任务组织与运行状态展示。

完整设计、数据契约、迁移说明、代码结构和验收清单见：docs/features/gui-2.0.md。该文档共 21 章，覆盖本 PR 的功能、边界和审查重点。

页面与信息架构

主导航统一为三个入口：

• 作战：任务状态、剩余次数、执行进度、任务列表、任务队列、快捷操作、实时日志与当前舰队预览。
• 计划：舰队规划、出征规划、决战计划（旧）和计划管理。
• 设置：系统设置与脚本行为，覆盖环境、ADB、自动化、日志、OCR、主题和窗口状态。

顶部状态栏固定展示当前任务、执行进度、剩余次数、远征倒计时和后端状态，并针对窄窗口重新布局。

舰队规划

• 新增六位置可视化舰队编辑器，支持主选、位置级备选和只有 candidates 的纯备选位置。
• 主选、备选和舰船图鉴之间支持拖拽、交换、追加和自动整理空位。
• 备选队列跟随所属位置移动；删除主选时可保留纯备选状态。
• 支持位置级最小/最大等级限制、复制备选队列、同名覆盖确认和未保存修改确认。
• 舰种由舰船资料推导，保存前按后端字段白名单校验。
• 舰队方案独立保存到 team-{名称}.yaml，一份文件只包含一支舰队。

关键 YAML 契约：

• ships 的顺序对应游戏位置。
• 主选使用位置对象的顶层 name。
• 备选使用同一位置下的结构化 candidates。
• candidates 每项必须包含 name，不生成字符串候选或 null 占位。
• 允许位置没有顶层 name，但必须具有非空结构化 candidates。
• ship_type、min_level、max_level 仅在有值时写入。

舰船资料库

• 新增本地 manifest、SQLite 数据库、中文标签和 WebP 资源。
• 当前包含 894 条舰船记录、894 张立绘、6 张稀有度背景、6 个边框和 23 个舰种图标。
• 新增 tools/ship_library/update_ship_library.py，支持从 Wiki 增量更新数据与资源、原子替换文件并生成机器可读结果。
• 设置页提供舰船数据库更新入口。
• 数据库内部使用英文枚举，GUI 通过中文标签映射展示。

出征规划

• 重构地图、维修、战况、执行次数、轮次间隔、战利品停止和掉落停止配置。
• 舰队不再在出征编辑器中重复编辑，改为关联独立舰队方案并展示只读预览。
• 节点编辑支持启用状态、终点、迂回策略、六种阵型、战斗动作、最低战果和索敌规则。
• 新建、保存、加载、改名和覆盖行为与舰队规划统一。
• 编辑态 YAML 保存舰队引用；任务运行前由主进程读取舰队文件并展开完整 fleet_presets[].ships 到临时 YAML，后端仍接收完整合法计划。
• 保留旧内嵌舰队计划的隔离迁移能力，转换后拆分为独立舰队文件。

计划管理与任务列表

• 汇总系统/用户出征计划、系统/用户舰队方案及双向关联状态。
• 展示缺失舰队、未关联、YAML 读取失败和被任务分组引用等状态。
• 支持筛选、删除用户文件、忽略或恢复未关联提示，以及跳转到对应编辑页并自动加载。
• 任务分组记录 managedSource + managedFile，同时保留旧路径推断兼容。
• 系统方案和用户方案使用独立目录，系统资源在界面中按只读内容处理。

作战页

• 整合作战快捷操作、任务列表和任务队列，提高 720P 下的空间利用率。
• 当前运行请求携带明确舰队规则时，提取最多六艘舰船并复用图鉴卡片展示立绘。
• 无任务时舰队预览框显示“当前无任务执行”；有任务但没有明确舰队规则时保持空白，不根据 fleet_id 猜测游戏内实际编队。
• 日志按等级显示；敏感完整配置只在调试模式输出。

设置与环境

• 设置页按“系统设置 / 脚本行为”分类，统一开关、输入框、滑杆、下拉框、路径选择和状态提示。
• 支持模拟器、ADB 地址、主动连接、断开、在线检测和账号配置。
• 支持自动远征、战役、演习、出征和胖次任务配置。
• 支持日志等级、日志目录和调试模式。
• 支持全局操作延迟、OCR 下载源、加速模式、CUDA、硬件识别、舰名置信度和舰名规则。
• 支持默认窗口尺寸，以及退出时窗口大小与位置持久化。
• 新增亮色、暗色和跟随系统主题。
• managed 模式由 GUI 管理 Python 与依赖；external 模式使用本地 AutoWSGR 仓库源码及虚拟环境，不自动安装或更新远端 autowsgr。

文件与 IPC 安全

• 系统/用户目录通过主进程统一解析，打包版用户数据写入可写目录。
• YAML 使用专用 IPC 读取、校验、改名、删除与原子写入。
• 文件名经过清洗，路径经过边界校验，避免目录穿越。
• 保存接口返回明确成功结果，只有真实落盘后才展示统一顶部成功提示。
• 同名覆盖必须二次确认；已加载文件改名时维护原文件身份。

UI 与交互

• 以 720P 为主要布局基准，并兼容更窄窗口和大窗口扩展。
• 舰队卡片统一使用立绘、稀有度背景、边框、舰种图标和名称样式。
• 统一紧凑间距、按钮尺寸、标题层级、主题变量和细滚动条。
• 动态列表在筛选、删除、拖拽和重渲染后恢复滚动位置。
• 统一顶部保存成功提示，包含 role="status" 与 aria-live="polite"。

资源与兼容清理

• 旧 resource/builtin_plans/ 重组为系统出征计划和系统舰队方案目录。
• 删除不会被程序加载或打包的四个旧模板示例，保留必要的旧模板路径兼容读取。
• 清理提交在仓库中的临时 Issue、运行结果和调试脚本文件。
• README、架构说明、YAML 指南和开发环境文档同步更新。

验证结果

• npm run build：通过。
• npm run test:legacy-plan：通过；拆分舰队 2、地图关联 2、运行时舰队 2、冲突项 3。
• npm run test:settings：通过；验证 46 个 View 字段、45 个可见控件，以及隐藏后端字段和未知 YAML 字段保留。
• 舰船资源完整性：894 条记录，929 个资源文件引用，缺失 0、空文件 0、重复 ID 0。
• git diff --cached --check：通过。

严格未使用检查目前还有 4 条提示，已记录在 docs/reviews/2026-08-03-workspace-review-pending.md：

• 出征规划直接执行入口 executePlan，等待执行链方案确定。
• 旧后端源码更新链的 checkForUpdates、pullUpdates，等待 managed/external 更新边界确定。
• 泡澡维修流程的 fleetId 参数，等待确认是否仍需按舰队区分。

上述提示不影响默认构建，且没有其他类型错误。

建议审查顺序

1. 先审查舰队 YAML 序列化、纯备选结构和运行时舰队展开。
2. 再审查系统/用户目录、文件身份、覆盖、改名和原子写入。
3. 检查 managed/external 后端模式及本地源码来源校验。
4. 检查设置字段是否只映射后端已支持配置。
5. 最后审查页面布局、主题、舰船资料和交互细节。

已知边界

• 作战页仅展示任务请求中明确携带的舰队，不读取游戏画面推断实际舰队。
• 出征规划当前不提供直接执行按钮，保存后从作战页加载执行。
• 决战计划继续保留旧页面，等待后端决战流程独立重构后统一 YAML 入口。
• 严格未使用检查的 4 条提示按挂起文档后续处理。

[yltx]

本次审计结论：Request changes。本地 build、legacy-plan 测试和 settings 测试可以通过，但以下安全、数据完整性和兼容性问题仍阻塞合并；GitHub 当前也没有构建/测试 CI，仅有 GitGuardian。

阻塞项

1. 主进程文件 IPC 缺少路径边界

   • electron/main.ts 的路径解析允许绝对路径，并对相对路径缺少 containment/traversal 校验。
   • save-file、read-file、append-file、resolve-app-path、open-folder 因而可访问应用受控目录之外的路径。
   • 这违反 docs/features/gui-2.0.md §12.2 的受控文件名/目录要求。请使用明确根目录、拒绝绝对路径和 ..，并增加路径穿越测试。

2. 原子写入失败时可能删除旧文件

   • 当前 rename 失败后会删除目标文件再重试；若第二次 rename 仍失败，旧的有效配置/计划已经丢失。
   • 这影响舰队方案、出征方案和迁移写入，违反 §12.3“失败时保留原文件”的要求。
   • 请改为不会先破坏目标文件的替换方案，并测试 rename/权限/占用失败。

3. 外部 Python 环境的依赖安装位置与启动路径不一致

   • 外部仓库模式把依赖通过 --target 安装到 GUI 管理的 python/site-packages。
   • 启动外部后端时又不把该目录加入 sys.path。
   • 安装可能报告成功，但后端仍无法 import。请安装到用户选择的外部解释器/虚拟环境，或确保启动路径与安装目标一致。

4. 破坏 v1.4.1 活动预设兼容性

   • PR 删除四个 活动20260730-*.yaml，同时移除 builtin_event_20260730 模板，没有等价替代。
   • 规范只允许清理四个未使用示例，并要求保留当前工作流。请恢复活动预设/模板或提供迁移后的等价资源和兼容验证。

5. 旧 path-form 任务组没有完成迁移

   • 规范要求旧路径自动推断为 managedSource + managedFile，当前加载逻辑主要保留旧 path。
   • 相关旧计划文件又被移动/删除，已有任务组可能无法加载。请实现读取时兼容和保存时迁移，并用真实旧任务组 fixture 测试。

6. 保存设置会丢失未知嵌套 YAML 字段

   • ConfigModel.toYaml() 重建完整 emulator 和 account 节，只保留 GUI 已建模字段。
   • 后端新增或用户自定义的未知嵌套字段会被静默删除。请进行深层保留/合并，并覆盖未知嵌套字段 round-trip 测试。

7. candidate-only 槽位跨仓语义被改变

   • src/data/shipData.ts 使用 name: slot.name ?? candidates[0]，会把纯候选槽位的第一个候选提升为严格主候选。
   • 后端 #521 将无顶层 name 的候选视为平等替代项。请保留缺省 name，并增加 GUI→API/YAML 契约测试。

验收要求

• 修复以上阻塞项并增加自动回归测试；
• 增加 GitHub CI，至少执行 build、test:legacy-plan、test:settings 和资源完整性检查；
• 验证旧任务组、旧活动预设、打包资源、managed/external Python、CUDA/OCR 的实际运行；
• 与后端 #521 对 candidate-only、活动入口和节点决策字段达成一致后再按“后端先、前端后”合并。