真实双端复现与源定义回写

第一次连接

连接用户已打开的编辑器与项目，查询当前 Runtime MCP schema。普通技能试验场应由现有调试 Host 开局与客户端连接；不要为了获取一个 ui.snapshot 改成纯客户端模式。

经 runtime_call_tool 选择真实客户端目标，再调用运行时的 ability_test.snapshot。若没有已拉取服务端状态，提交 Refresh；发 Start 前确认当前模式引用的配置可用。顶层命令参数是 request 对象，例如默认配置启动：

{
  "request": {
    "kind": "Start"
  }
}

工具返回 accepted 与 requestId；随后读取 ability_test.response 的该 request ID。启动后重新读取快照，不拿之前的 session 或 generation 推算下一个命令。

真实双端上传、开局与连接验收

这项检查用于收口 #217。它验证的是一条新的、真实的对局链路；编辑器旧局、纯客户端窗口或仅能打开面板都不能替代它。每次记录项目提交、Editor/SDK 包、WasiCore 依赖、服务端脚本包、Host 对局标识和客户端运行目录，避免把不同局的日志拼在一起。

1. 按项目正常流程编译并发布服务端脚本，确认上传回执对应本次提交；再启动调试 Host。不要把本地未上传的脚本或编辑器进程内缓存当成服务端已更新。
2. 连接本次 Host 创建的真实客户端，等待正常游戏阶段和当前主控同步完成。记录客户端目标、Host/服务端日志路径以及本局 session 标识。
3. 调用 ability_test.snapshot，确认 available=true、服务端状态为活动、nativeMainActorId/mainUnit 与 testUnit 身份有效，并记录 sessionId、generation、setupRevision、presentationRevision。任一字段缺失时先修复连接或配置，不继续套用旧游标。
4. 通过 ability_test.open 或顶部“技能调试”入口打开面板；如需进入会话，发送 Start 后轮询 ability_test.response。分别记录请求是否被受理、响应是否成功、EntryStatus 以及服务端日志中的失败原因。
5. 从同一次快照选择真实技能，发送一次最小施法或一次表现编辑。等待资源准备确认，再读取响应和新的快照；检查服务端命令结果、客户端 ClientAcknowledged、SkillTestObservation 中的 cast.started/cast.stage/cast.effect 以及客户端实际 Actor/Sequence 观测。accepted=true、pending=false、服务端返回成功、客户端资源 Ready、实际施法成功是五个独立检查点。
6. 调用 Stop 并重新读取快照，核对原主控的 SyncId、场景、位置/朝向、技能实例和控制权已恢复；随后结束旧局，再按步骤 1–3 开一个新局，确认源定义或发布内容的验证使用的是新对局。退出时的“会话关闭”单独不能证明恢复成功。

失败时保存 request ID、session/generation、两个 revision、EntryStatus、服务端/客户端诊断和本局日志。pending、旧局残留的画面、仅客户端本地状态或仅 UI 数字变化都不能记录为双端验收通过。

当前编辑/施放请求还需要快照中的完整 target 与 expectedRevision；布置命令使用 sessionId、generation、expectedSetupRevision。这些是不同游标，不能将所有操作都用一个计数值代替。精确请求字段以当前工具 schema 与 SkillTestRequest 为准。

主控与技能恢复对照

对照	进入前记录	退出/换角后判断
优先复用	主控 SyncId、场景、位置/朝向、技能实例身份与物品授予关系	同一原对象恢复；不能只看模型相同
关闭复用	原主控/控制权与配置指定单位	临时对象回收，原控制权恢复
无有效主控	当前无主控的事实与兜底定义	成功创建，原因明确；不要求先生成假主控
空技能单位	实际技能数为零	全量搜索后可真实添加，默认配置无需候选列表
列表清空	主动和被动的真实实例列表	全部离开实际容器；自动重授予单独显示
原列表之外技能	完整目录中稳定定义身份	返回确切挂载实例，按真实目标施法
全量单位替换	原单位归属和新单位定义	新单位沿用自身默认技能，原对象不被销毁

注册目录不等于未来尚未初始化的定义集合。因模式条件未初始化而缺项时，记录注册状态并走项目自己的初始化路径，再刷新目录；不要绕过模式语义扫描所有源码来生成“候选技能”。

动画准备、普通播放与保存保护

动画准备使用当前工具 schema 中的 ability_test.prepare_animation。例如 { "animation": "anim/human/other_anim/other_01/skill_01.ani" } 会使用当前测试单位模型提前准备；查询传 queryOnly=true，失败后显式重试传 force=true。检查返回的状态、原因和实际产物路径；Ready 只证明资源准备，不等于已实际播放。后台任务期间退出后，应确认它没有向下一局发布旧产物。

先记录本次客户端目标、对局身份、编辑器/SDK/依赖版本，以及运行目录的实际来源。读取当前工具 schema；不能把一次旧局的 Ready 或旧依赖仍注册的工具名，当成当前安装版本具备新行为的证据。以下检查分别记录，不合并成一个“动画准备通过”。

1. 主动准备

对一个确实存在的共享源文件先查询，例如：

{
  "modelPrefab": "characters/general/sk_basic2/model.prefab",
  "animation": "anim/human/other_anim/other_01/skill_01.ani",
  "queryOnly": true
}

将 queryOnly 改为 false 发起准备，随后轮询同一资源组合。记录 Queued / Running / Ready 或 Failed / Unsupported、原因和 bakedPath。不要通过反复 force=true 轮询；强制重备只在明确重试时发一次。入口动画应同时出现在原项目和当前局的 res/<bakedPath>；Ready 后再真实播放，才可记录播放成功。

sword_idle 等自带动画名不是共享源路径，准备接口对它返回 Unsupported 不能说明原播放入口失效。只有完整 anim/.../*.ani 源文件参与此项验证。

2. 普通缺失播放

1. 在实际已注册技能目录选择一个基线动画本来就引用共享 .ani 的技能。code_sample 的 TestSpell / ChargedTestSpell 使用 anim/human/barehanded_anim/hand_05/skill_025.ani；只有当前运行目录确实包含这些定义时才使用该示例。选中后核对有效快照中的真实引用。
2. 使用从未在本局加载的烘焙路径，或重开没有旧失败/成功资源缓存的调试局。若需制造缺失，先备份并只移走对应的单个模型烘焙产物，保留共享源文件；记录项目和本局运行目录的文件状态。不要全量清缓存，也不要在冷路径测试前调用资源统计、主动 Ensure 或通过面板选择新素材。
3. 经现有 ability_test.command 发 Cast，使用最新快照中的完整 target / revision 和该技能要求的真实目标；示例 TestSpell 是 Vector 技能，可用范围内的 Point 目标。以实际 schema 的命令字段为准。
4. 首次播放允许失败且不会自动补播；记录普通 Actor 缺失诊断或准备排队日志，并查询同一资源组合的状态。Ready 后在同一对局再次施放，核对实际动画/实例、服务端施法结果和文件状态。仅服务端效果执行成功不足以证明客户端动画播放成功。

若测试中先走了主动准备或全量烘焙，结果属于热路径或主动准备检查，应重新安排普通缺失入口的冷路径。

3. 先准备后采用与保存

单独选一个候选，先主动准备但不播放；检查其项目 ref/pie_animation_observed.json，不要把全部浏览候选写进 protected。再通过普通角色 Actor 的真实播放入口采用已经 Ready 的产物，核对 protected 新增了其相对资源路径。组合动画还须包括实际生成的依赖路径。

正常保存项目，比较保存前后采用入口与依赖文件的存在性、大小和内容摘要。未采用候选不属于保护承诺；已经加入正式资源统计的文件也可能被统计流程保留，因此不能仅凭“文件还在”推断采用通知已生效。保护记录与保存保留要同时记录。

4. 冷依赖与退出隔离

补一个冷参考模型与一个有实际依赖的组合动画，记录准备主线程开销、后台计算完成与当前局完整可读的结果；热缓存的单文件成功不能覆盖此项。不能把“计算结束”当作依赖已完整提交。

分别在 Queued 和 Running 阶段结束旧调试局，按项目正常流程重开，记录前后不同的对局身份与实际运行目录。旧任务允许完成原项目缓存，但不能对新局运行目录做提交；需要旧任务状态/日志、文件时间和新局状态相互对照。若新局正常启动流程主动复制了原项目缓存，应区分这次正常资源安装与旧任务提交，不能仅凭新局存在同名文件判定越局写入。

最后实际播放采用结果，再按正常资源统计、模型烘焙和发布流程验证。从项目 protected 记录或临时调试目录存在，不能推断正式包已经包含资源。

四段与 Sequence

先以原 Formula 模式施放作对照，再一次事务设置 Fixed 和四段测试目标。确认新 revision 已被客户端准备后施放；检查真实服务端阶段/结果与客户端动画，而不是只看界面数字改变。

AnimationDefinitions 中的 Sequence 采用连续片段和 Actor/Event 两类绝对偏移。复制列表项生成新 EntryId；更新和移动保持原项身份。检验源切片与播放时长、倍率/混合，Actor 出生与清理，事件的键、偏移与暂停语义；重排片段不应默默重定位 Actor/Event。暂停等待必须有项目实际恢复流程。

操作前从实际工具 schema 确认编辑与资源准备入口，并读取运行时能力。播放后检查客户端表现和服务端阶段；缺少入口或能力时报告具体缺项。

循环施法至少跨一个 Tick，等待实际 OrderQueue 完成后再投下一次。修改、换角、清空、选技能和退出时检查旧循环取消，旧 generation 命令不能落到新对象。冷却或消耗失败应明确停止，不把强行重置当成真实完整验证。

草稿采纳

导出草稿后，检查项目身份、定义 Link/type、基线、字段差异、资源与布置上下文。不能把用户临时选择的靶子/角色/技能列表直接改成正式默认行为。

源定位时区分源数据与派生产物；定位手段可读代码、条目、数据编辑器或依赖来源，但不要把这些分成不同测试入口。依赖源不在可写范围时，采用已有的项目覆盖机制或报告需要对应源权限。

回写包含哪些最终数值/表达式应清楚：Fixed 四段是测试意图，原 Formula 是正式行为。除非作者指定转换，否则修改仍保留公式与归一化语义，不用四个常量偷偷替换它们。

回写后运行正常资源统计，只纳入实际采纳的引用；检查对应模型动画烘焙结果、Actor 资源和场景资产。完全退出试验场、清除运行时覆盖并停止旧调试局，再编译双端、上传服务端、开新局。新局结果与草稿目标一致，才可以记录“源定义验证通过”。

失败记录

记录实际 request ID、session/generation、布置/表现版本、定义与实例身份、客户端资源状态、服务端命令结果和恢复诊断。窗口里的发送确认、资源轮询 pending、旧局残留表现都不能当成施法或回写成功。

运行时日志通常位于编辑器安装目录的 logs/client 与 logs/server；项目根的 Client-Debug/Server-Debug 日志常为编译输出。检查真实本次对局，不混入更早成功的日志。