docs(save): 更新存档规范与 Yarn 节点类型文档

Assets/Scripts/SaveSystem/README.md

@@ -8,7 +8,6 @@
 | --- | --- | --- |
 | Yarn 变量 | `Game Loop/YarnVariableStorage.cs` | 运行时 `$` / `$global_` 读写 |
 | **本目录** | `SaveSystem/` | 快照结构、捕获/还原、槽位落盘、流程编排 |
-| 深度维修（旧） | `DeepRepairDataRegistry.cs` | FixSystem 等 IData，P5 前临时保留 |
 | 槽位 / 截图 | `SlotManager` / `SlotThumbnailCapture` | P2 基础版：slot_0 自动档、slot_1..8 手动档、sidecar、缩略图、原子写 |
 
 **不要**再往 `YarnVariableStorage` 上堆存档逻辑。
@@ -19,7 +18,10 @@
 // 自动存档（节点进入事件触发）
 yield return SaveRestoreOrchestrator.AutoSaveRoutine(nodeName);
 
-// 手动存档：复制最近自动档
+// Yarn 显式存档（<<save>>，默认 omit anchor）
+yield return SaveRestoreOrchestrator.ExplicitSaveRoutine();
+
+// 手动存档：复制最近落盘档（含 OnNodeStart 与 <<save>>）
 SaveRestoreOrchestrator.CreateManualSlot(slotIndex);
 
 // 槽位读档
@@ -36,6 +38,17 @@ yield return SnapshotService.Restore(snap);
 YarnVariableStorage.Instance.SetValue("$foo", 1f);
 ```
 
+Yarn 脚本：
+
+```yarn
+<<save>>
+```
+
+- 放在目标节点**末尾**：所有状态命令（`switch_fix_system_to`、`hide_dialog`、`play_timeline` 等）执行完毕之后，`<<jump>>` / `<<detour>>` 之前。
+- 默认 **omit anchor**（`anchor.nodeName` 为空）；读档时不重进 Yarn，仅还原 scene + sections + 变量。
+- 绕过 tag / `no_save` 的自动判定（`CanExplicitSave`）；仍受读档中、暂停、SuppressAutoSave 门控。
+- 与 `OnNodeStart` 分工：常规 `hub` / `linear` / `content` 仍靠节点进入自动存；`<<save>>` 用于即将进入无对话 / Fix 交互等 `OnNodeStart` 覆盖不到的边界。
+
 正式槽位路径：`persistentDataPath/AllOurBrokenParts/saves/slot_x/{snapshot.json, meta.json, thumbnail.png}`
 
 P1 测试落盘路径：`persistentDataPath/AllOurBrokenParts/snapshot_test/latest_snapshot.json`（首次访问槽位系统时会尝试迁移到 `slot_0`）
@@ -53,8 +66,7 @@ SaveSystem/
 ├── SnapshotService.cs           Capture / Restore 对外 API
 ├── SnapshotPersistence.cs       文件读写、JSON 序列化、旧档检测
 ├── SaveRestoreOrchestrator.cs   UI + 落盘 + 读盘编排
-├── DeepRepairSnapshot.cs        深度维修占位（P5）
-├── DeepRepairDataRegistry.cs    旧 IData 容器（P5 前）
+├── SaveYarnCommand.cs           Yarn <<save>> 显式存档
 ├── ScreenSnapshotHelper.cs      screen section 实现细节
 ├── SlotTypes.cs                 P2：槽位常量、sidecar、UI 视图模型
 ├── SlotFileSystem.cs            P2：槽位路径 + 原子写
@@ -69,6 +81,7 @@ SaveSystem/
     ├── AudioSnapshotProvider.cs      order 50
     ├── TimelineSnapshotProvider.cs   order 60
     ├── FixSnapshotProvider.cs        order 65
+    ├── FixPanelSnapshotProvider.cs   order 66
     └── ScreenSnapshotProvider.cs     order 70
 ```
 
@@ -137,14 +150,13 @@ Phase 4  P4：淡入淡出等演出时序
 | `scene` | 当前场景名（Addressable key），读档时最先加载 |
 | `anchor` | 恢复锚点：`sceneSoName` + `yarnProjectId` + `nodeName`；最后阶段加载对话并重进节点 |
 | `yarnVariables` | floats / strings / bools |
-| `sections` | key 为 `SnapshotProviderIds`，值为各 DTO；**表现层状态（env / actor / audio / timeline / fix / screen）** |
-| `deepRepair` | **P5 深度维修**（BlockPuzzle / Cutting / AnalysisMode 等）。P1 阶段已预留 `DeepRepairSnapshotDto`，但详细子系统状态暂不捕获；待存档系统主干稳定后再补充并测试 |
+| `sections` | key 为 `SnapshotProviderIds`，值为各 DTO；表现层与维修子模块（env / actor / fix / bodyModule / blockPuzzle …）统一在此 |
 
 > 宏观信息（场景、章节、节点）直接位于 `SaveSnapshot` 根对象，不再冗余到 `sections`；槽位 / 「继续游戏」UI 需要展示时，从 `scene` / `anchor` 直接读取。
 
-## 新增一个可存子系统（表现层）
+## 新增一个可存子系统
 
-表现层子系统通过 Provider 注册到 `sections`：
+所有可存子系统（含维修小游戏）均通过 Provider 注册到 `sections`，用 `RestoreOrder` 控制同 Phase 内的还原顺序：
 
 1. 在 `SaveSnapshot.cs` 增加 DTO 类。
 2. 在 `SnapshotRegistry.cs` 的 `SnapshotProviderIds` 区域增加稳定 id，并加入 `RequiredForCapture`（若 P1 必须存）。
@@ -157,13 +169,9 @@ Phase 4  P4：淡入淡出等演出时序
 
 > **例外**：`scene`（场景加载）与 `anchor`（章节+节点重进）属于**核心叙事坐标**，由 `SnapshotCapture` / `SnapshotRestore` 框架直管，不走 Provider 注册。新增「核心层」字段需修改 `SaveSnapshot` 根对象与对应编排方法。
 
-## Fix 场景快照（P1 接口层完成）
+## Fix 场景快照
 
-Fix 场景（维修场景）的快照存储在 `sections["fix"]`，由 `FixSnapshotProvider`（order 65）管理。
-
-### 为什么 FixStateMachine 放在 sections 而不是 deepRepair？
-
-FixStateMachine 不仅管理深度维修（Eye、Memory、EmoWave 等），还管理 **Clinic（诊所）** 和 **BodyModule（插线维修）** 等非深度维修状态。把它放在 `sections` 中作为表现层子系统之一，可以避免概念错位。
+Fix 场景与维修子模块的快照均存储在 `sections`，由各自 Provider 按 `RestoreOrder` 还原。
 
 ### 双入口设计：Enter vs EnterImmediate
 
@@ -174,26 +182,32 @@ Fix 场景各 State 的 `Enter()` 通常包含相机过渡、Timeline 播放、F
 
 读档时 `SwitchStateImmediate` **不调用前一个状态的 Exit()**，因为读档本质是覆盖当前状态，不需要清理。
 
-### P1 已落地的接口
+### 已落地的维修 section
 
-- `FixSnapshotDto`：state、args、moduleState、eyeColorState、isSystemOn、currentRepairSystemType
-- `IFixState` 接口 + `EnterImmediate()` 默认实现
-- `FixStateMachine.SwitchStateImmediate()`
-- `FixSystemCenter.CaptureSnapshot()` / `RestoreSnapshot()`
-- `FixSnapshotProvider` 注册到 `SnapshotRegistry.EnsureInitialized`
+| section id | DTO | RestoreOrder | 说明 |
+| --- | --- | --- | --- |
+| `punchTape` | `PunchTapeSnapshotDto` | 63 | 打孔带收藏 |
+| `fix` | `FixSnapshotDto` | 65 | FixSceneDirector 宏观模式（state + args） |
+| `fixPanel` | `FixPanelSnapshotDto` | 66 | FixPanel 壳层 + 线缆/插头 |
+| `bodyModule` | `BodyModuleSnapshotDto` | 67 | 插线模块物理态 |
+| `eye` | `EyeSnapshotDto` | 68 | Eye 叙事阶段 |
 
-### 尚未实现（P4/P5）
+**还原顺序**：punchTape → fix（cue）→ fixPanel → bodyModule → eye → screen。`fixPanel` 须在 `fix` 之后，以覆盖 Cue `EnterImmediate` 中的 `ResetPlug`。
 
-- 各 State 的 `EnterImmediate()` 具体逻辑（当前默认 `yield break`）
-- 深度维修子系统详细状态（BlockPuzzle grid、Cutting 进度等）→ P5 `deepRepair`
-- Fix 场景读档的 Fade 时序 → P4 编排层
+**维修场景门控**（`FixSceneSnapshotHelper`）：上述 section 仅在 `FixSystemCenter.Instance != null` 时 Capture/Restore。
+
+### 尚未实现
+
+- 部分 FixCue 的 `EnterImmediate()` 具体逻辑（HuoShan / BlockPuzzle / Cutting 等仍用默认空实现）
+- BlockPuzzle / Memory / Cutting 等子模块的 section DTO + Provider
+- `fixPanel` 扩展：灯光状态（P1）、RepairSystemManager 缩放/offset（P2）
 
 ## 相关阶段
 
 | 阶段 | 内容 |
 | --- | --- |
 | P2 | 基础版已落地：槽位、原子写、meta sidecar、缩略图、latest_slot、P1 测试档迁移；正式 UI 接入仍属 P6 |
-| P3 | 基础版已落地：`onNodeStart` 判定、tag 白/黑名单、`no_save`、读档/暂停门控；瞬跳 content 排查与无活跃 Yarn 边界仍待补 |
+| P3 | 基础版已落地：`onNodeStart` 判定、tag 白/黑名单、`no_save`、读档/暂停门控；`<<save>>` 显式存档（`CanExplicitSave`、omit anchor）已落地 |
 | P4 | 基础版已落地：Provider sync/async 契约、Phase + Barrier 编排、读档自动存档抑制、Timeline Addressable 可等待恢复、验证窗口读档入口 |
-| P5 | `deepRepair` 段、维修模块清单；还原模型单独定案，不默认套用 P1 Provider 协程链 |
+| P5 | 维修子模块 section 扩展（BlockPuzzle / Memory / Cutting 等待新增 Provider） |
 | P6 | 正式存 / 读档 UI、继续游戏、新游戏覆盖自动档、游戏中读档确认等玩家流程 |

Docs/Yarn维修节点类型规范.md

@@ -378,7 +378,28 @@ Center ◀─────────────────────┘
 - **瞬跳 `content` 节点**：无玩家可感知停留、进入后立即跳转的路由/状态检查节点（如 `UF检查状态`），必须附加 `no_save`。完整定义与排查清单见 [§8](#8-瞬跳节点与存档边界)。
 - 特殊 `content` 节点：极少数剧情上明确不希望保存的 `content` 节点，可附加 `no_save` 覆盖默认可保存语义。
 
-任何活跃节点不得 `<<jump>>` 到 `deprecated` / `wip` 节点，也不得在标记为 `no_save` 的节点处触发自动保存。
+任何活跃节点不得 `<<jump>>` 到 `deprecated` / `wip` 节点，也不得在标记为 `no_save` 的节点处触发 **OnNodeStart 自动保存**。
+
+### 7.2 Yarn 显式存档 `<<save>>`
+
+用于节点末尾、状态已就位、即将进入无对话 / 纯 C# 交互阶段时的**显式存盘点**（`OnNodeStart` 无法覆盖的场景）。
+
+```yarn
+<<play_timeline 地铁>>
+<<hide_dialog>>
+<<change_actor_state "turn" "地铁医生">>
+<<save>>
+<<detour 切换到诊所外>>
+```
+
+约定：
+
+- **插入位置**：所有需要进快照的状态命令之后；`<<jump>>` / `<<detour>>` / `load_scene` **之前**（顺序即快照内容）。
+- **anchor**：默认 omit（读档不重进 Yarn）；依赖 sections 还原画面与玩法状态。
+- **判定**：绕过 tag / `no_save`；读档中、暂停、SuppressAutoSave 仍拒绝。
+- **async 命令**：`change_actor_state_async` 等未等待的命令之后立刻 `<<save>>` 可能 capture 未完成态，save 前应 `<<wait>>` 或使用同步命令。
+
+与 `no_save`：`no_save` 禁止的是 **OnNodeStart 自动存**；节点末尾仍可写 `<<save>>` 表达作者意图。
 
 ---
 

Docs/存档系统设计方案.md

@@ -8,7 +8,7 @@
 - 需求来源：`Docs/存档系统需求.md`
 
 - 当前阶段：**P1 快照层、P2 槽位/落盘基础版、P3 可存点判定基础版、P4 读档编排基础版已落地**。原 `StorageSystem` 已重命名为 `YarnVariableStorage` 并完成职责拆分；FixStateMachine 接口与 DTO 已接入；自动档 / 手动档槽位、sidecar、缩略图、原子写、latest_slot 与 P1 测试档迁移已接入；Yarn `onNodeStart` 已触发自动存档判定与写盘；读档已切换为 Provider sync/async 契约 + Phase/Barrier 编排。
-- 最近更新：2026-06-18（P4 基础版落地：Provider 契约重构、读档自动存档抑制、Timeline Addressable 可等待恢复、验证窗口读档入口；正式 UI、P5 深度维修、P6 玩家流程仍未闭环）。
+- 最近更新：2026-06-24（废弃 `deepRepair` 段与 `IData`/`DataContainer`；维修子模块统一经 sections Provider；Legacy 旧档仅迁移 Yarn 变量）。
 
 ---
 
@@ -19,7 +19,7 @@
 | 档别 | 含义 | 内容 |
 | --- | --- | --- |
 | **A. 废弃 / 重做** | 被点名的不可靠部分，不沿用旧做法 | 恢复锚点；存档文件组织；依附其上的「无条件写盘触发」 |
-| **B. 候选，待评估复用** | 旧系统中仍可靠的底层能力，到对应阶段再决定是否复用 | Yarn 变量存取能力；承接深度维修状态的数据容器（`IData`/`DataContainer`） |
+| **B. 候选，待评估复用** | 旧系统中仍可靠的底层能力，到对应阶段再决定是否复用 | Yarn 变量存取能力（`IData`/`DataContainer` 已废弃） |
 | **C. 全新构建** | 旧系统无对应实现 | 快照模型、槽位/落盘、可存点判定、复原编排、存读档 UI、横切项 |
 
 > B 类只是「候选」，不作为既定地基；是否复用、复用多少，在 P1/P5 设计时单独决策。
@@ -37,6 +37,7 @@
 | D4 | 「继续游戏」指向 | **最近保存的存档**（自动 / 手动中时间最新的一份） | P6 |
 | D5 | 新游戏与既有档关系 | **覆盖自动存档，不影响其他（手动）存档** | P6 |
 | D6 | 读档还原编排 | **Phase + Barrier**：少数异步边界 `yield`，其余同步批量还原 | P4 编排、`ISnapshotProvider` 契约 |
+| D7 | 维修子模块存取 | **统一 `sections` + Provider**，不单独设 `deepRepair` 根字段 | P1 快照结构、新增维修模块方式 |
 
 ### 决策展开
 
@@ -44,7 +45,9 @@
 
 - **D1.1 时间序列粒度**：Timeline 等只需复原到终态或初态，不记录播放进度。
 
-- **D6 Phase + Barrier**：读档不是「每个 Provider 串行 `yield return` 的协程链」。编排层按阶段推进，仅在**必须等待**的边界上挂起（场景加载、锚点重进、P4 淡入淡出、P5 深度维修状态机等）；同阶段内的 sync 还原应连续调用，不必逐步 yield。详见 §4.1。
+- **D6 Phase + Barrier**：读档不是「每个 Provider 串行 `yield return` 的协程链」。编排层按阶段推进，仅在**必须等待**的边界上挂起（场景加载、锚点重进、P4 淡入淡出、部分 async Provider 还原）；同阶段内的 sync 还原应连续调用，不必逐步 yield。详见 §4.1。
+
+- **D7 统一 sections**：BlockPuzzle / Memory / Cutting 等维修子模块与 env / actor / fix 一样，各建 DTO + Provider 写入 `sections`，用 `RestoreOrder` 表达还原顺序。不再维护独立的 `SaveSnapshot.deepRepair` 段或 `DeepRepairSavePolicy`。
 
 - **D2~D5**：见上表；P2/P6 实现时使用。
 
@@ -82,10 +85,10 @@
                     └──────────┬──────────┘
            ┌───────────────────┼───────────────────┐
            │                   │                   │
-┌──────────▼─────────┐ ┌───────▼────────┐ ┌───────▼──────────────────┐
-│ SnapshotPersistence │ │ ISnapshotProvider × N │ DeepRepairDataRegistry │
-│ 文件读写（P2 接管）  │ │ scene/macro/env/…     │ 深度维修 IData（P5）   │
-└──────────┬─────────┘ └──────────────────────┘ └────────────────────────┘
+┌──────────▼─────────┐ ┌───────▼────────┐
+│ SnapshotPersistence │ │ ISnapshotProvider × N │
+│ 文件读写（P2 接管）  │ │ env/actor/fix/…       │
+└──────────┬─────────┘ └──────────────────────┘
            │
 ┌──────────▼─────────────────┐
 │ SaveRestoreOrchestrator    │  存读档流程：UI 反馈、落盘、还原、旧档兼容
@@ -99,10 +102,9 @@
 | `SnapshotPersistence` | `SaveSystem/SnapshotPersistence.cs` | JSON 序列化 / 反序列化；P1 测试路径兼容；旧档格式检测 |
 | `SlotManager` / `SlotDirectory` | `SaveSystem/SlotManager.cs` / `SaveSystem/SlotFileSystem.cs` | P2 槽位业务、sidecar、缩略图、latest_slot、原子写、P1 测试档迁移 |
 | `SaveRestoreOrchestrator` | `SaveSystem/SaveRestoreOrchestrator.cs` | `AutoSaveRoutine()` / `CreateManualSlot()` / `RestoreFromSlot()` / `RestoreFromFile()`；保存 UI；legacy 分支 |
-| `DeepRepairDataRegistry` | `SaveSystem/DeepRepairDataRegistry.cs` | `RegisterData` / `LoadByJson`（FixSystem 等 P5 前临时） |
 | `SnapshotCapture` / `SnapshotRestore` | `SaveSystem/` | 快照组装与逐项 provider 还原 |
 | `SnapshotSerializer` | `SaveSystem/` | schemaVersion、稳定 SaveId key |
-| `SnapshotRegistry` + `Providers/*` | `SaveSystem/` | 6 个表现层 Provider（env / actor / audio / timeline / fix / screen） |
+| `SnapshotRegistry` + `Providers/*` | `SaveSystem/` | 表现层 + 维修子模块 Provider（env / actor / fix / bodyModule …） |
 
 ### 调用约定
 
@@ -113,7 +115,6 @@
 | 槽位读档 | `SaveRestoreOrchestrator.RestoreFromSlot(slotIndex)` |
 | 文件读档（旧档 / 调试） | `SaveRestoreOrchestrator.RestoreFromFile(path)` |
 | 仅捕获内存快照 | `SnapshotService.Capture()` |
-| 深度维修注册 | `DeepRepairDataRegistry.RegisterData(...)` |
 | Yarn 变量 | `YarnVariableStorage.Instance.SetValue / TryGetValue` |
 
 ### P1 测试落盘路径
@@ -163,7 +164,7 @@ Phase 4  Barrier（P4：淡入淡出等演出时序）
 | timeline（Addressable） | **可选 Barrier** | 若要求进节点前 Timeline 终态就绪，须显式等待；**禁止** fire-and-forget（见下） |
 | RestoreAnchor | **是** | `StartDialogue` 为 Yarn 异步 API |
 | P4 淡入淡出 | **是** | 演出时序 |
-| P5 深度维修 | **部分 Barrier** | 如 `FixSystemData.Load()` → `SwitchState` 须等待；不宜硬套「与 scene 同款的单一 Provider 协程」 |
+| P5 深度维修 | **部分 Barrier** | 如 Fix cue `EnterImmediate`、async Provider 还原须等待；与其他 section 同走 Provider 编排 |
 
 #### `RestoreOrder` 的语义（终态）
 
@@ -191,7 +192,7 @@ Phase 4  Barrier（P4：淡入淡出等演出时序）
 
 - **P2 / P3**：可不改动 `SnapshotRestore`；但新增代码**不应**再复制「全 Provider 协程链」模式。
 - **P4**：在 `SaveRestoreOrchestrator` / `SnapshotRestore` 上按本节 Phase 模型重写编排；顺带 refactor Provider 契约。P4 是「加 fade UI」+「修正编排模型」，而非在现有 foreach 链首尾叠 UI。
-- **P5**：深度维修还原更接近旧 `DataContainer` + `LoadIndex` + 部分 `IData.Load()` async，**不应**假设「再注册一个 Provider、继续逐步 yield」即可；是否独立 Phase、哪些模块 Barrier，在 P5 单独定案。
+- **P5**：深度维修子模块与其他子系统一样经 sections Provider 扩展，**不应**再假设独立 Phase 或 `deepRepair` 根字段；是否独立 Phase 仅由具体 Provider 的 async 需求决定。
 
 ---
 
@@ -210,7 +211,7 @@ P2 槽位/落盘层基础版     P3 可存点判定基础版
 P4 复原编排层基础版（Provider 契约 + Phase/Barrier + 抑制自动存档）── 已落地
         │
    ┌────┴────┐
-P5 深度维修阶段存档     P6 存/读档 UI & 流程
+P5 维修子模块 section 扩展     P6 存/读档 UI & 流程
         │
 P7 横切
 ```
@@ -218,10 +219,9 @@ P7 横切
 ### P1 快照层（已实现）
 
 - `SaveSnapshot` 纯数据结构 + `ISnapshotProvider` 逐项还原（D1/D1.1）。
-- Provider：`scene` / `macro` / `env` / `actor` / `audio` / `timeline` / `fix` / `screen`。
+- Provider：`env` / `actor` / `audio` / `timeline` / `subway` / `fix` / `screen`；维修子模块 `punchTape`(63) / `bodyModule`(66) / `eye`(67) 等，后续 BlockPuzzle / Memory 等同理扩展。
 - Yarn 变量经 `YarnVariableStorage` 纳入快照；`$data.*` 死路径已移除。
-- `DeepRepair` 段可空占位（`DeepRepairSavePolicy`），P5 再定。
-- 深度维修旧 `IData` 仍经 `DeepRepairDataRegistry` 运行，**尚未**纳入新快照。
+- 原五类 IData 已迁入 `sections` Provider；`IData`/`DataContainer`/`LoadIndex` 已移除。
 - **注意**：P1 中 `Restore` 统一为协程、逐步 `yield return` 属临时实现，终态见 **§4.1 / D6**；后续阶段勿在此基础上堆逻辑。
 
 ### P2 槽位/落盘层（基础版已落地）
@@ -242,20 +242,21 @@ P7 横切
 ### P3 可存点判定层（基础版已落地）
 
 - `DialogController.OnNodeStart` 更新当前 node/tags 后调用 `SavePointEvaluator.CanAutoSave()`，通过后执行 `SaveRestoreOrchestrator.AutoSaveRoutine(nodeName)`。
-- `SavePointEvaluator` 当前规则：`hub` / `linear` / `content` 默认允许；`start` / `init` / `function` / `detour` / `center` / `performance` / `event` / `end` 默认禁止；`no_save` 覆盖一切并禁止。
-- `SaveRestoreOrchestrator.IsRestoring` 与 `GameManager.state.isInPause` 会阻止自动保存，避免读档中覆盖自动档。
-- `CreateManualSlot` 复用 `CanManualSave`：当前可自动存档且 `slot_0` 存在时，才能复制到手动档。
+- `SavePointEvaluator` 当前规则：`hub` / `linear` / `content` 默认允许；`start` / `init` / `function` / `detour` / `center` / `performance` / `event` / `end` 默认禁止；`no_save` 覆盖一切并禁止 **OnNodeStart 自动存**。
+- Yarn `<<save>>`（`SaveYarnCommand`）走 `CanExplicitSave`：仅全局门控，默认 omit anchor；用于节点末尾进入无对话 / Fix 交互等边界。
+- `SaveRestoreOrchestrator.IsRestoring` 与 `GameManager.state.isInPause` 会阻止自动保存与显式 save，避免读档中覆盖自动档。
+- `CreateManualSlot` 复用 `CanManualSave`：`slot_0` 存在且通过全局门控即可复制（含显式 `<<save>>` 写盘后的手动档）。
 
 仍待补齐：
 
 - 维修 Yarn 的瞬跳 `content` 节点需要继续排查并补 `no_save`，优先处理验证工具中暴露的误存节点。
-- “无活跃 Yarn 节点默认允许存档”与“深度维修过程中不可手动存档”的需求边界需要再确认；若部分 FixSystemNew 交互状态可存，应显式列清楚。
+- 深度维修过程中是否允许 `<<save>>` 的需求边界待确认（与可存点判定一并定案）。
 - 目前验证工具主要覆盖存盘行为；复杂节点 tags 边界和读档后落点尚未形成自动化验证。
 
 ### P4~P7
 
 - P4：基础版已落地。`ISnapshotProvider` 已拆为捕获契约 + `ISyncSnapshotProvider` / `IAsyncSnapshotProvider`；`SnapshotRestore` 已改为 Phase + Barrier；`SaveRestoreOrchestrator` 已接入读档黑屏、自动存档抑制与 restore 日志；Timeline Addressable 恢复已改为可等待路径。
-- P5：深度维修还原单独定案，不默认套用 P1 Provider 协程模式（见 §4.1）。
+- P5（部分已落地）：`punchTape`/`fix`/`bodyModule`/`eye` 已迁入 sections；BlockPuzzle / Memory / Cutting 等待新增 Provider；`isSystemOn`/`currentRepairSystemType` Restore 仍延后。
 - P6：接入正式存 / 读档 UI、继续游戏、新游戏覆盖自动档、游戏中读档确认等玩家流程。
 - P7：Steam 云存档真实后端、版本兼容策略、全局 / 跨周目数据边界等横切项。
 
@@ -270,7 +271,7 @@ P7 横切
 - 手动档数量上限、覆盖 / 删除 / 重命名规则。
 - 游戏进行中读档是否允许、是否二次确认。
 - 自动存档是否需要正式可见反馈（当前 `SaveRestoreOrchestrator` 使用 `InfoPanel.ShowSaveLoading()` / `HideSaveLoading()`，是否作为最终 UX 待定）。
-- 各深度维修是否支持阶段存档的逐个清单（P5）。
+- 各维修子模块是否支持阶段存档的逐个清单（新增 Provider 前定案）。
 - **维修 Yarn 瞬跳 `content` 节点**：按 [Yarn 维修节点类型规范 §8.4](Yarn维修节点类型规范.md#84-维修脚本中的常见瞬跳-content待排查) 全项目补 `no_save`（Peipei `UF检查状态` 等优先）。
 - 全局 / 跨周目数据与单局存档的边界划分。
 - 缩略图最终规格与 UI 展示方式（当前 P2 基础版为 640×360 PNG）。