docs(10-40): 记录高级 III 读者审阅清单

- 逐字记录高级 III 读者人格与八页范围，标注未复用中级 / 高级 I / 高级 II 人格
- 逐页逐节给出使用概率（高/中/低 + 理由）
- 首轮 2 个阻断问题、9 个非阻断问题与可删/可后置建议，均定位到文件章节

.planning/phases/10-docs-restructure/10-40-READER-REVIEW.md

@@ -0,0 +1,164 @@
+# 高级 III（原理与架构）读者审阅
+
+## 读者人格（逐字，本层专用，未复用其它层）
+
+> 假设你是一位有高度定制需求的数据端作者，已经读完高级 I 与高级 II，具备足够的编码能力：能独立读懂引擎的大部分数据端系统（会读类、接口、泛型、装饰器与 TypedArray 操作），但你既不是引擎的编写者，也没有通读过全部源码。你正在阅读高级 III「原理与架构」，想判断这些原理能否帮你把现有系统改对。
+
+**未复用中级 / 高级 I / 高级 II 人格**：本记录全程使用上述高级 III 人格提示词。中级人格见 `10-11-READER-REVIEW.md`，高级 I 人格见 `10-19-READER-REVIEW.md` 与 `10-31-READER-REVIEW.md`，高级 II 人格见 `10-26-READER-REVIEW.md`；这些均未被复用。
+
+## 审阅范围（八页）
+
+- docs/advanced/iii/index.md（导览）
+- docs/advanced/iii/loading-system.md
+- docs/advanced/iii/replay-internals.md
+- docs/advanced/iii/event-system.md
+- docs/advanced/iii/anon-tokyo.md
+- docs/advanced/iii/passability-and-pathfinding.md
+- docs/advanced/iii/core-state.md
+- docs/advanced/iii/plugin-internals.md
+
+审阅对象是 10-39 已接入站点、互链完整的八页；未重审高级 I / II。执行者未向审阅子代理提供自己的分析结论，子代理以独立上下文自行阅读，可打开被引用的源码核对，但不修改任何文件。
+
+## 第 1 轮 · 逐页逐节使用概率
+
+### 高级 III 导览（index.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 高级 III 是给谁的 | 中 | 入口处读一次确认自己是受众，之后不会回头用 |
+| 与高级 I、高级 II 的区别 | 中 | 只用来校准「这层讲机制不讲用法」的预期，一次性内容 |
+| 前置 | 高 | 决定是否回头补读插件系统/可存档内容等四篇，规划阅读前真的会照着执行 |
+| 八篇地图 | 高 | 反复回来查「哪个系统在哪篇」，是本层的目录 |
+| 阅读路径 | 高 | 排查问题时按需线跳转，直接决定我先读哪篇 |
+| 本层不覆盖什么 | 中 | 出现渲染端/编辑器问题时用来止损，避免在这层白找 |
+| 怎么验证你读懂了 | 中 | 读完自测一次，不作日常参考 |
+
+### 加载系统（loading-system.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 系统模型 | 高 | 动加载前先分清 task/manager/loader 各管什么，避免改错层 |
+| 一次加载的阶段 | 高 | 追加配置/任务、排查「配置没被读到」全靠阶段顺序，本页核心 |
+| 配置文件与处理器 | 中 | 加配置时要看相对路径与路径改写；JSONC 前缀细节只在解析失败排查时用 |
+| 扩展点：加一份配置 | 高 | 我的每个自定义系统几乎都带一份配置，最高频扩展点 |
+| 扩展点：加一种资源 | 中 | 大部分自定义数据走 addExtraConfig 就够；只有非 JSON 或要流式处理才用自定义任务 |
+| 扩展点：换一个加载环境 | 低 | 只跑网页端；只有做离线校验或本地资源包时才会回来 |
+| 进度 | 低 | 进度是展示用；我只需要「等 loaded() 而不是等比例」这一句 |
+| 渲染端如何消费加载进度 | 低 | 数据端视角几乎不用，只为理解边界读一次 |
+| 边界与注意 | 高 | 改完加载相关代码后的自查清单 |
+
+### 录像系统底层（replay-internals.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 系统模型 | 高 | 出现存档/回放不一致时先分清数组、注册表、沙箱谁负责什么 |
+| 录制一步 | 高 | 登记自定义指令、判断主动/被动归类时直接用 |
+| 沙箱播放 | 高 | 排查回放分歧、实现选择框之类的被动步消费者时的核心 |
+| 存档形状 | 高 | 存档兼容与「内部引用不能就地改」的拷贝策略直接相关 |
+| 内部实现：三块缓冲区 | 中 | 平时用不到；二进制损坏排查或写录像编辑器时才读 |
+| 内部实现：索引与读流 | 中 | 解释读取流为什么过期、随机读为什么慢，改录像前必读但低频 |
+| 旧引擎基线对比 | 低 | 没有旧样板内容要迁移，一次性背景知识 |
+| 边界与注意 | 高 | 参数上限、内部引用、流过期这些坑高频自查 |
+
+### 事件系统（event-system.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 系统模型 | 高 | 分清仓库/收集/执行/解释器职责，是挂事件前的基础 |
+| 事件与触发器 | 高 | 挂触发器前先确认数据端是否派发，避免写出永不触发的事件 |
+| 收集：这一次该执行谁 | 高 | 设计优先级、排查执行顺序（点前块后、优先级只在组内比）时用 |
+| 执行与折叠 | 高 | 做门控逻辑时选执行/折叠模式，且要防执行器状态共享的坑 |
+| 事件层 | 中 | alias=event 的登记规则偶尔要查；主体认知在高级 II 已建立 |
+| 自定义一个内建函数 | 高 | 我的自定义内容几乎都要新动作，注册路径照抄 |
+| 边界与注意 | 高 | 事件不执行时的告警码对照自查 |
+
+### Anon-Tokyo 解释器（anon-tokyo.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 系统模型 | 中 | 平时经内建函数间接使用；只有排查脚本问题才需要这条链 |
+| 语句模型 | 中 | 手写/生成语句数组时用；大多数时候语句由编辑器产出 |
+| 与事件对象的衔接 | 中 | 运行时 setRaw 换事件、缓存失效行为需要时才读 |
+| 内部实现：编译与执行 | 中 | 「编译期抛错 vs 调用期抛错」的排查清单有用；执行循环细节我不会动 |
+| 自定义内建函数与全局函数 | 低 | 内建函数写法在事件系统页；全局函数当前数据端未用，只剩一次性事实 |
+| 边界与注意 | 高 | 调试脚本时的快速核对清单（Exit/Return、作用域三层） |
+
+### 通行性谓词与寻路原理（passability-and-pathfinding.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 系统模型 | 高 | 改通行规则前先确认判断统一落在谓词上 |
+| 通行性谓词契约 | 高 | canPass/shouldHit 的区分是改一切通行规则的地基 |
+| 默认实现怎么判断 | 高 | 包装默认谓词前必须知道默认规则查哪些位 |
+| 同一契约、两个实例 | 高 | 本页对我最关键：只换一侧是最容易犯的错 |
+| 勇士移动的三种结果 | 高 | 自定义移动与触发器联动时必须对应三种结果 |
+| 构图：从起点只保留可达节点 | 中 | 排查「为什么搜不到/为什么这格是终端」时才读 |
+| 搜索：最小损失与终端约束 | 中 | NoPath/TargetUnder 语义要懂；搜索内部细节低频 |
+| 系统层做什么 | 中 | 绑定/换楼层/并发限制的契约偶尔要查；用法在高级 II |
+| 换一套通行语义 | 高 | 我要改通行规则时的直接模板 |
+| 边界与注意 | 高 | 高频自查（两实例不共享、终端只能作终点等） |
+
+### CoreState 组装与初始化（core-state.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 系统模型 | 高 | 四层结构与依赖方向是所有后续判断的底座 |
+| 入口的职责 | 中 | 入口装配是一次性工作，要动它时再读 |
+| 加载管线 | 高 | 排查启动问题（插件没初始化、加载没推进）的核心 |
+| 存档挂载 | 高 | 注册可存档对象/绑定执行器是我的日常操作 |
+| 在游戏内另建一个数据端实例 | 高 | 离线校验回放、对比双实例结果正对我的回放一致性需求 |
+| 内部实现：装配顺序 | 中 | 我不重排也不手搓子系统，读一次满足「为什么不能重排」 |
+| 边界与注意 | 高 | 高频自查 |
+
+### 插件内部机制（plugin-internals.md）
+
+| 小节 | 概率 | 理由 |
+| --- | --- | --- |
+| 系统模型 | 中 | 一次性建立「表→依赖图→拓扑序→状态机→三阶段」的流水线印象 |
+| 三个阶段怎么执行 | 高 | 等待语义（awake 不等待、另两个 await）决定我把哪段代码放哪个钩子 |
+| 取回一个插件 | 高 | 运行期跨插件调用的标准写法，判空与状态检查照抄 |
+| 失败会怎样 | 高 | 插件静默不执行时的排查路径，控制台提示对照表 |
+| 内部实现：依赖排序 | 中 | 只为看懂告警在说什么；算法本身不会去调 |
+| 状态机 | 中 | 与「取回一个插件」配合判断插件走到哪步，中频 |
+| 边界与注意 | 高 | 高频自查 |
+
+## 第 1 轮 · 问题清单
+
+### 阻断性（2）
+
+| # | 问题 | 定位 | 为什么阻断 | 源码依据 |
+| --- | --- | --- | --- | --- |
+| B-01 | 正文称「放在 `onCoreConfigLoaded` 或 `onExtraConfigLoaded` 里，或者在加载开始前调用，都来得及」。对 `addExtraConfig` 而言，`onExtraConfigLoaded` 已经太晚：额外配置的读取循环发生在该钩子**之前**，此时追加只写进映射表，本次加载永远读不到；`start()` 因 `dataLoaded` 守卫也不会补读。 | `loading-system.md`「一次加载的阶段」 | 读者会把 `addExtraConfig` 注入 `onExtraConfigLoaded`，配置静默不加载、`getConfig` 返回 null、下游拿到空内容且无报错——属于在错误时机注入。 | `packages-user/data-state/src/loader/loader.ts:119-141`（额外配置循环先于 `onExtraConfigLoaded`）、`loader.ts:61-63`（只写映射表）、`loader.ts:84-85`（`loading || dataLoaded` 直接 return） |
+| B-02 | 正文与边界把「`start()` 已被调用」当作追加分界线（「等加载已经开始再追加，就不会再被本次加载读取」）。但 `onCoreConfigLoaded` / `onExtraConfigLoaded` 都在 `start()` 内部触发，却是 `addCustomTask` 的合法窗口；同一处先列合法窗口又说「已开始就不读取」，自相矛盾。 | `loading-system.md`「一次加载的阶段」「边界与注意」 | 读者会对「插件时机 vs 加载阶段」建立错误模型：要么避开本可用的窗口，要么在自定义任务没加载时归因错误。 | `loader.ts:114-116`（`onCoreConfigLoaded` 在 `start()` 中途触发）、`loader.ts:139-147`（`onExtraConfigLoaded` 后收集 `customTask`，加载中途注册仍会被读取） |
+
+### 非阻断（9，只记录，本轮不修）
+
+| # | 问题 | 定位 |
+| --- | --- | --- |
+| N-01 | `getReplayed()` 声称「不包含当前正在播放的步」，实现返回 `reader.index`，实际可能多算 1～2 步；做进度显示会偏大。建议核对语义后统一文档与实现。 | `replay-internals.md`「沙箱播放」 |
+| N-02 | 「被依赖的插件先完成同一阶段」对 `async awake` 不成立（`awake` 不等待）；上文有告诫，本段却是绝对化表述，存在冲突。建议在本段补限定。 | `plugin-internals.md`「三个阶段怎么执行」 |
+| N-03 | `CounterSaveable` 示例的 `saveState` / `loadState` 省略了 `compression` 参数；TS 可赋值但契约不完整，读者不知道有压缩级别。建议按真实签名书写。 | `core-state.md`「存档挂载」 |
+| N-04 | 「`CoreState.load()` 已经替你完成迭代」措辞不严：`load()` 本身也是异步迭代器，仍必须被消费。 | `loading-system.md`「边界与注意」 |
+| N-05 | `judgeStep` 注释写「频繁判断时应复用同一个实例」，示例却在函数体内每次 `new DefaultPassPredicateImpl(state)`，注释与代码自相矛盾。 | `passability-and-pathfinding.md`「默认实现怎么判断」 |
+| N-06 | 示例注释「配置缺失时加载器给的是空对象」混淆两种情形：id 未登记/未加载时 `getConfig` 返回 `null`，只有解析失败才给 `{}`。 | `loading-system.md`「扩展点：加一份配置」 |
+| N-07 | 旧引擎基线对比中的细节（`core.status.route`、LZString、`getNumberById` / `blocksInfo`）在本仓库无实现可核对（未核对）。建议注明来源或补可核对引用。 | `replay-internals.md`「旧引擎基线对比」 |
+| N-08 | `AnonTokyoExecutionContext` 上存在空的 `dump()`；正文说「没有导出能力」成立，但读者翻 API 会疑惑，建议明确 `dump` 是空实现。 | `anon-tokyo.md`「边界与注意」 |
+| N-09 | 「数据端入口只重新导出创建函数」略松：`src/data/index.ts` 同时重导出 constant、initialize、types。措辞收紧即可。 | `core-state.md`「入口的职责」 |
+
+### 可删 / 可后置（只记录）
+
+- `loading-system.md`「渲染端如何消费加载进度」：以本层读者身份几乎不会用，且导览声明本层只写数据端；建议压缩成两三句并入「边界与注意」，或移到渲染端文档，只保留「接口级消费、不改顺序」。
+- `replay-internals.md`「旧引擎基线对比」：无旧内容迁移需求时是一次性背景，且仓库内不可核对；不建议删（对比有教学价值），但可压缩成要点列表并保持文末后置。
+- `loading-system.md`「进度」：计数表偏渲染端展示，可压缩；务必保留「不要等比例做业务判断，等 `loaded()` / 读配置」。
+- `loading-system.md`「扩展点：换一个加载环境」：低频，篇幅已不长，可后置。
+- `anon-tokyo.md`「自定义内建函数与全局函数」：主体是指路加「全局函数当前未用」的一次性事实，可压到几行，不建议删。
+- `index.md`「与高级 I、高级 II 的区别」：两三句即可承载现有信息，可压缩。
+- 各页「内部实现」节（装配顺序、依赖排序、三块缓冲区、索引与读流、编译与执行）日常低频，但回答「为什么不能重排 / 为什么连带阻断 / 为什么流会过期」，不建议删。
+
+### 第 1 轮核对总结
+
+通行性两实例、事件收集不过滤触发器与「点事件整组在前、图块事件整组在后」、执行器过滤与折叠、Anon-Tokyo 编译期/运行期抛错与 `Exit`/`Return`、CoreState 四层装配与五个存档 id、`load()` 四步异步迭代器、插件环/缺失连带阻断与四状态、录像 `finalize` 触发条件与存档内部引用，均与源码一致。八页中仅加载系统的时间窗口表述存在阻断级错误（B-01 / B-02）；其余主题未发现会让读者改错层、换错实例或混淆系统模型的问题。
+
+## 迭代记录
+
+（Task 2 按阻断清单迭代修正，逐轮追加。）