mtgodot-poc/audit/remediation-roadmap.md

40250 客户端差异修复路线

本文件记录当前修复顺序和调度规则。它是给人和其他 AI 工具读取的当前路线，不替代机器可读的 audit/manifest.json；合同状态、剩余分支和证据以账本为准。

当前基线

统计快照：2026-09-21。

项目	数量
总合同	45
已排除	1
未完全闭合合同	44
未闭合分支条目	224
P0 分支条目	93
P1 分支条目	118
P2 分支条目	13
P3 分支条目	0

这些数量是快照，不是手工修改的真相。每次修复前后都要运行账本刷新和报告脚本，以 audit/manifest.json 的当前内容为准。

修复阶段

阶段 0：账本和调度卫生

• 读取本文件、audit/manifest.json、相关合同和最近的 audit/history.jsonl。
• 先运行 audit_ledger.py refresh --write、report --write 和 validate。
• 将一个合同中的每个剩余分支作为独立的修复目标；修复后必须同步合同、账本和历史。
• 问题/分支 ID 使用稳定格式 <contract-id>/<branch-slug>；历史中只有合同 ID 的旧记录不能证明该合同的所有分支都已完成，首次处理某个分支时要补建具体 ID。
• 如果只是缺少真实服务端、Windows 客户端或视觉运行证据，不要伪装成代码已完成，记录为验证阻塞。

阶段 1：P0 在线核心链路

按完整的用户可玩链路推进：

1. 登录、认证、选人、Loading、进入地图和失败重试：network.login.phase_flow、network.character_select.create_delete。
2. WASD、停止、转向、远程同步、传送和地图切换：movement.keyboard.motion、movement.remote_sync_state、world.map_load_transition、world.reset_cleanup。
3. 攻击、受击、死亡、经验、掉落和拾取：combat.attack_combo_damage、combat.death.exp_drop、item.drop_pickup。
4. 技能释放、动作事件、特效和服务端结果：skill.cast.effect_timing、skill.player_ui_cooldown。
5. 协议分派、重连、安全分支和资源/协议加载：network.packet_dispatch_protocol、network.reconnect_warp、network.security_encoding、resource.pack_locale_proto。

阶段 1 未完成前，不主动扩大 P1 的视觉或外围功能修复范围。

阶段 2：P1 游戏功能

依次处理背包/装备、NPC/任务、社交、目标选择、状态、模型和效果资源。combat.flying_projectile 在这一阶段处理；除非它直接阻塞 P0 或引入回归，否则不提前插队。

阶段 3：P2/P3 平台和表现

处理音频、天气、平台发布、移动端细节和其他不阻塞核心游戏流程的差异。

防止重复修复规则

• 每一轮只设置一个主合同，并为本轮选定一个明确的问题/分支 ID；可以同时修复被它直接调用的跨合同根因，但必须在历史中列出关联 ID。
• 同一个问题/分支 ID 不得重复修复或重复审计，除非出现新的回归、实现文件发生实质变化，或新增证据证明原结论不成立。
• 同一合同可以在后续轮次继续处理，但必须选择不同的 remaining 分支；合同是功能分组，不是问题去重单位。
• 一个合同仍为 PARTIAL 不代表此前修改无效；只处理其 remaining 中尚未闭合的分支，不能重新审计已通过的测试路径。
• 每轮开始前必须检查 audit/history.jsonl，确认本轮问题/分支 ID 没有已完成记录；如果历史记录不够细，先补充问题 ID，再开始修改。
• 每轮结束必须记录：参考调用链、当前调用链、修改的分支、修复前失败证据、修复后测试、剩余阻塞和下一轮候选。
• 下一轮候选按 P0 → P1 → P2 → P3 排序；同优先级按用户可玩链路和阻塞关系排序，不按“最容易修改”排序。

完成门槛

单个分支只有同时满足以下条件才可关闭：

1. 40250 完整调用链和当前实现调用链已对齐。
2. 前置条件、分支、算法、状态顺序、单位、时序、资源、协议副作用和清理行为均有等价证据。
3. 有修复前失败、修复后通过的自动测试；必要时覆盖拒绝、打断、重复包、死亡、重连和地图切换。
4. 需要真实服务端、Windows 客户端或视觉证据时，已完成对应验证；否则保持 PARTIAL 并记录阻塞原因。

合同只有在全部剩余分支关闭后，才能从 PARTIAL 提升为 STATIC_VERIFIED 或 TEST_VERIFIED。

下一轮

下一轮主合同固定为 network.login.phase_flow，具体处理其尚未闭合的问题/分支。除非发现新的 P0 回归或登录链路被其他合同阻塞，否则不切回已处理过的问题。

上一轮已闭合分支：network.login.phase_flow/auth-game-phase-matrix/peer-close-login-owner。 真实 /logout 已证明建立连接后的 peer close，AppFlow 现在按 40250 回到唯一 LoginPhase owner； 不得重复修改“保留 GameScene/自动重连遮罩”这一已闭合分支。

上一轮已闭合分支：network.login.phase_flow/auth-game-phase-matrix/phase-close-server-fixture。 本地等价 fixture 已证明显式 PHASE_CLOSE 不再伪造 disconnected；真实服务端主动 PHASE_CLOSE 包序仍是证据阻塞，后续只在获得新 live fixture 时验证，不重复修改 native owner。

上一轮已处理分支：network.login.phase_flow/auth-game-phase-matrix/empty-role-live-fixture。 已补充 net_classic_e2e 的 MT_CLASSIC_EXPECT_EMPTY=1 只读探针；当前账号仅有部分空槽， 不能将其当作全空角色证据，也不要通过删号制造 fixture。全空角色的正向 live 证据仍保持在 remaining，后续只在获得安全 fixture 时验证，不重复修改本地 SELECT owner。

上一轮已处理分支：network.login.phase_flow/login-failure-retry-cleanup/login-form-retry-owner。 已按 40250 LoginWindow.Connect -> AccountConnector.Connect 增加 LoginPhase retry owner；登录失败后 只替换认证 transport，不再由 AppFlow 重试触发全局 disconnect_from_server/world_reset。本地 UI/source 断言和 native loopback 包序已通过；真实 Windows 可视化重试和服务器“失败->重新输入->成功”仍是证据阻塞， 不得重复修改该 owner。

前一阶段首选分支：network.login.phase_flow/auth-game-phase-matrix/cross-phase-retry-order。 下一步只处理跨阶段失败/重复进入的真实或等价包序：失败后旧 auth/game stream 的迟到包、重复 PHASE_LOGIN/PHASE_AUTH 的替换顺序、以及完整 UI retry 的真实服务端证据；优先补测试和 fixture， 不要重新审计已经由 direct-enter-loading-select-packet、gc-warp-live-package-order、peer-close-login-owner 或 phase-close-server-fixture 闭合的成功进入、peer-close owner 和显式 PHASE_CLOSE transport-owner 分离链路。

本轮已处理该分支中的认证成功尾包子路径：GC_AUTH_SUCCESS 后的旧 PHASE_AUTH 会随旧 AccountConnector 接收缓冲一起丢弃，不重复发送 CG_LOGIN3。后续必须使用新的稳定子分支 network.login.phase_flow/auth-game-phase-matrix/cross-phase-retry-order-game-login-stale-tail 处理游戏登录失败后的迟到 phase；不得重复修改认证成功的清理边界。

本轮已处理 cross-phase-retry-order-game-login-stale-tail：游戏 LoginPhase/SelectPhase/ Loading 自有包在当前应用帧完成后按 40250 phase-local return 停止，迟到 receive tail 延后到 下一次处理周期；Loading 转交 GamePhase 的包仍保留游戏批处理语义。后续应选择新的稳定子分支 处理真实失败后重新输入成功、重复进入包序或服务器主动 PHASE_CLOSE live 证据，不得重复修改 本轮 return_after_current_packet 机制。

本轮已处理 network.login.phase_flow/auth-game-phase-matrix/auth-connect-immediate-failure-owner： 认证地址解析/socket 同步失败与异步 OnConnectFailure 统一回到 40250 的 Offline owner，并保留 登录重试资格。不得重复修改本轮 handle_auth_connect_failure() 的认证清理边界。

本轮已处理 network.login.phase_flow/auth-game-phase-matrix/game-connect-immediate-failure-owner： 普通认证成功后的游戏连接失败现在走独立 OnConnectFailure -> LoginWindow owner，DirectEnter 和 GC_WARP 失败走 ClosePhase -> SetLoginPhase，不再触发凭据 OnLoginFailure 或伪造 disconnected。修复前 DirectEnter/普通 game-connect fixture 均有失败断言，修复后 native、 Godot bridge、CTest、ASAN 和阶段/包结构审计通过；不得重复修改本轮 handle_game_connect_failure()、connect_failed signal 或 GC_WARP owner 分离。

本轮已处理 network.login.phase_flow/auth-game-phase-matrix/auth-connect-bridge-owner：按 40250 AccountConnector::OnConnectFailure -> Offline -> LoginWindow 修复初始认证同步/异步 连接失败的 M2Client bridge，新增独立 connect_failed 回调、保留认证 session 和 retry_login owner；修复前专项桥接测试失败，修复后 native/CTest/ASAN/Godot 与阶段/包结构 审计通过。不得重复修改本轮 on_auth_connect_failure、classic_auth_connect_failure_pending 或认证 session 保留逻辑。

本轮已处理 network.login.phase_flow/auth-game-phase-matrix/auth-peer-close-bridge-owner：按 40250 CAccountConnector::OnRemoteDisconnect -> __OfflineState_Set 增加认证 peer-close 独立 callback；M2Client 不再把认证 socket 被动关闭伪造成 login_failed 或 connect_failed， 并保留非终态 LoginPhase owner。修复前后均由真实本地 TCP 接受/关闭/再次替换 transport 的 Godot 回归固定；不得重复修改本轮 on_auth_remote_disconnect 或 classic_auth_remote_disconnect_pending。

本轮已处理 network.login.phase_flow/auth-game-phase-matrix/phase-close-disconnect-login-owner： 重新拆分 40250 的 PHASE_LOGIN -> CPythonNetworkStream::SetLoginPhase 与 PHASE_CLOSE/OnRemoteDisconnect -> Python networkmodule.SetLoginPhase -> net.Disconnect 两种 语义；只有真正的 PHASE_LOGIN 会在当前 transport 上发送 CG_LOGIN/CG_LOGIN2，显式关闭、peer close 和 DirectEnter 失败会清理旧 transport 并回到 LoginWindow owner。net_classic_session_test 的修复前 失败、修复后无旧连接登录包/旧 transport Offline、CTest/ASAN/Godot 回归均已固定；不得重复修改 enter_login_phase 的发送分支或本地 PHASE_CLOSE owner。真实服务器主动 PHASE_CLOSE 包序仍需 live 证据。

本轮已处理 network.login.phase_flow/login-failure-retry-cleanup/game-peer-close-retry-owner： 按 40250 OnRemoteDisconnect -> SetLoginPhase -> LoginWindow 与后续 LoginWindow.Connect -> ConnectToAccountServer 的 owner 边界，游戏态 peer close 现在保留同一 ClassicSession 的显式重试资格；重试只替换认证 transport，新的 PHASE_AUTH 只发送一份使用新密码的 CG_LOGIN3，不再回退到全局 session/world teardown。修复前失败和 loopback 替换 transport 回归已记录； 不得重复修改 m_login_retry_pending 的游戏 peer-close owner。真实 Windows LoginWindow 时序、真实服务端 失败后重试成功包序和完整跨阶段 retry 仍需 live 证据。

下一主候选：network.login.phase_flow/auth-game-phase-matrix/live-package-order/server-initiated-phase-close。 本地结构和 owner 分支已覆盖，下一轮只取真实 Windows/40250 服务端证据：失败后重新输入成功、 服务器主动 PHASE_CLOSE、完整跨阶段 retry 和 DirectEnter/GC_WARP 失败回退包序；不要回到已关闭 的认证或游戏连接失败 owner。

本轮已执行该候选的真实 /logout 探针并登记为 network.login.phase_flow/auth-game-phase-matrix/live-package-order/server-initiated-phase-close： 登录到 PHASE_GAME、执行命令、peer close、world reset 和 LoginPhase owner 均通过，但 MT_NET_TRACE=1 没有出现 phase -> 0。服务端 DESC::SetPhase(PHASE_CLOSE) 的源码状态链已 确认，当前 build 因 close 后的 DESC::Packet guard 没有提供客户端可观察的 PHASE_CLOSE 包， 因此不能用客户端改动伪造这个证据。外层 wrapper 的失败仅来自既有 4 个 ParticlesShaderRD/RID 泄漏门禁。除非更换服务端 build/fixture，否则不要重复 /logout 探针；下一步改为获取真实 PHASE_CLOSE fixture，并在同一 fixture 上完成失败重试和跨阶段包序审计。

本轮新增并闭合本地分支： network.login.phase_flow/auth-game-phase-matrix/auth-success-game-before-auth-clear。 对照 40250 __AuthState_RecvAuthSuccess -> SetLoginKey -> MainStream.Connect -> AccountConnector.Disconnect 发现当前 ClassicSession::pump() 曾反向执行 auth disconnect 再 game connect；修复后使用 loopback 双 transport 状态回调固定为 game:connecting -> auth:offline。该分支不得重复修改。下一主候选仍是 新的真实失败后重试/跨阶段包序 fixture；如服务端 fixture 没有变化，不重复 /logout。

本轮新增并闭合本地分支： network.login.phase_flow/auth-game-phase-matrix/game-login-retry-process-boundary。 对照 40250 CPythonApplication::Process -> CPythonNetworkStream::Process -> CAccountConnector::Process 发现认证成功后当前端在同一 pump 再次处理新游戏流；修复后重试期间保留旧主流的处理机会， 认证成功建立替换流后延迟到下一 pump 才处理新流。该分支不得重复修改；真实服务端失败后重试 成功包序和 Windows LoginWindow 仍是未验证证据，下一候选继续选择新的 live/跨阶段分支。

本轮新增并闭合本地分支： network.login.phase_flow/legacy-text-wire-encoding/ui-gb2312-input-capacity。 发现 native 已按 UTF-8 -> GB2312 转换后的 wire 字节校验，但 CharSelectScreen 仍按 UTF-8 字节限制角色名输入，导致“龙驹简体中文免费版”在 UI 层被提前拒绝。现改为 UI 只做 Unicode 字符/控制字符校验，实际 24-byte GB2312 容量由 native 发包边界统一判断，并加入 UI/native 回归；不得重复把角色名 UI 改回 UTF-8 字节限制，也不得把地图名、任务名、系统提示套用该 24-byte 字段限制。

本轮新增并处理分支： network.login.phase_flow/ticket-slot-warp-order/direct-enter-failure-login-owner-reset。 对照 40250 OnConnectFailure -> ClosePhase -> net.Disconnect -> SetOffLinePhase，修复 DirectEnter/GC_WARP 失败回到 LoginPhase 时残留 m_direct_enter、导致替换 PHASE_LOGIN 跳过普通角色列表清理的问题；修复前失败测试和修复后通过证据已登记。真实 Windows/服务端 失败回退包序仍是 PARTIAL，下一轮继续获取新的 live fixture，不重复修改本地 ClosePhase owner。

本轮新增并处理分支： network.login.phase_flow/auth-game-phase-matrix/phase-close-login-retry-owner。 对照 40250 PHASE_CLOSE -> networkmodule.SetLoginPhase -> net.Disconnect -> LoginWindow.Connect 补齐显式关闭后的 retry owner；同一 ClassicSession 现在可替换认证 transport，收到新的 PHASE_AUTH 时只发送一份 CG_LOGIN3。真实服务端 PHASE_CLOSE 包序和完整跨阶段 retry 仍是 live 证据阻塞，不能据此关闭整个登录合同。

本轮新增并处理分支： network.login.phase_flow/auth-game-phase-matrix/phase-handshake-reentry-owner。 对照 40250 RecvPhasePacket(PHASE_HANDSHAKE) -> SetHandShakePhase 和 CAccountConnector::__AuthState_RecvPhase -> __HandshakeState_Set，补齐认证/游戏 HandShake owner 重入；从 Loading/Game 重入时先执行旧 phase-leave world 清理，后续只有新的 PHASE_LOGIN/PHASE_AUTH 才能继续登录。真实 Windows/服务端重试包序仍未闭合；不得重复修改 本轮的 PHASE_HANDSHAKE owner 和 world-leave 边界。

本轮新增并处理分支： network.login.phase_flow/auth-game-phase-matrix/auth-success-result-authority。 对照 40250 __AuthState_RecvAuthSuccess 的 bResult 分支，修复当前端把 login_key == 0 额外解释为凭据失败的问题；成功/失败现在只由 result 决定，票据值仍交给后续游戏连接。 真实服务端不会主动构造成功零票据包，不能用该本地边界测试替代完整 live retry 或安全模块证据； 不得重复修改本轮的认证结果判定条件。

本轮新增并处理分支： network.login.phase_flow/auth-game-phase-matrix/auth-phase-close-silent-owner。 对照 40250 CAccountConnector::__AuthState_RecvPhase 只处理 PHASE_HANDSHAKE/PHASE_AUTH 的分支表，修复当前端把认证 PHASE_CLOSE 错误转成游戏侧 phase_closed 和 auth server closed phase。认证 close 现在保持 AUTH owner，直到真实认证 socket disconnect/failure；不得重复修改本轮的认证 close 静默语义。服务器主动 PHASE_CLOSE 的 live 包序仍需外部 fixture，不能用本地 phase 注入替代。

本轮新增并处理分支： network.login.phase_flow/auth-game-phase-matrix/phase-select-reentry-owner。 对照 40250 RecvPhasePacket(PHASE_SELECT) -> SetSelectPhase -> m_phaseLeaveFunc.Run()， 修复当前端从 Game 返回 Select 时未清理旧地图 world、未通知宿主 phase-leave 的差异；现在先执行 Game owner 的 reset_for_map_change() 和 on_phase_leave，再安装 Select/DirectEnter owner。 该分支不得重复修改；真实 Windows/服务端跨阶段 retry、服务器主动 PHASE_CLOSE 和 GC_WARP 失败回退包序仍需 live fixture。

本轮新增并处理分支： network.login.phase_flow/auth-game-phase-matrix/phase-dead-noop-time-sync。 对照 40250 RecvPhasePacket(PHASE_DEAD) 的显式空分支，修复当前端先打开 time-sync mode、 导致后续重复握手错误发出 CG_TIME_SYNC，以及清除显式 PHASE_CLOSE owner 标记的差异；现在 PHASE_DEAD 不改变阶段 owner 或 time-sync 状态。该分支不得重复修改；完整跨阶段 retry、 服务器主动 PHASE_CLOSE、空角色 live 和 GC_WARP 失败回退包序仍需独立证据。

2026-09-22：本轮临时切换主合同到 movement.keyboard.motion

network.login.phase_flow 的剩余分支目前全部卡在真实 Windows 客户端/服务端主动 PHASE_CLOSE 包序证据或第三方闭源安全 SDK（Matrix/Passpod/Panama/HybridCrypt/HS/XTrap）， 本地代码层面已无可继续推进的动作。按阶段 1 的可玩链路顺序（登录 → 移动 → 战斗 → 技能 → 网络），本轮改为处理 movement.keyboard.motion。

本轮新增并闭合分支：movement.keyboard.motion/camera-auto-follow-rotation。 对照 40250 CPythonPlayer::NEW_MoveToDirection 的 m_isCmrRot 相机跟随分支（每帧对按住 的方向键，把相对相机的方位角折算到 fRotRat∈[-90,90] 并按 m_fCmrRotSpd=20.0 的速率用 CCamera::Roll 持续转动相机），当前端此前完全没有实现这个副作用。已在 player_controller.gd 新增 _camera_auto_rotate()，用同样的折叠/缩放公式驱动 GameCamera.yaw；D3D Roll 与 Godot yaw 转向手性相反，增量符号作为显式记录的平台适配 取反，用『按住方向时相机朝该方向收敛、正前后不转、从不越界』的不变式在 keyboard_motion_timeline_test.gd 中核验（因为没有真实 Windows 客户端可供逐位对照）。 详见 audit/contracts/movement.keyboard-motion.md 的 Implementation fix round 2026-09-22 小节。不得重复修改本轮的 _camera_auto_rotate() 折叠公式或符号约定，除非 出现新的 live 证据推翻当前的收敛不变式假设。

本轮过程中额外发现但未修复（已记录进合同 Remaining 与本文件供下一轮参考）： CActorInstance::CanAct() 的 Paralysis/Faint/Sleep 三个移动门当前端完全没有接入 （net_play.gd::_can_process_network_state() 只挡 dead/stunned/knock_down）。这三个 状态的触发源分别在萨满技能、Python 侧角色模块和效果可见性绑定，尚未定位到当前端对应的 服务端 affect 管线，属于比相机分支更大的独立子项，不要在没有先做好触发源映射的情况下 仓促接线。

movement.keyboard.motion 合同仍为 PARTIAL：根运动/AccumulationMovement、 OnMove/OnMoving/OnWaiting/OnStop 资源事件源、同步/受击/死亡/传送门叠加顺序、上述 Paralysis/Faint/Sleep 移动门和真实模型姿态测试仍未闭合，下一轮可以在这些分支中任选一个 继续（AccumulationMovement 根运动差异或 Paralysis/Faint/Sleep 移动门是其中两个具体、 无需真实服务端/客户端证据即可推进的候选）。

2026-09-22T01:30Z：movement.keyboard.motion/canact-paralysis-faint-sleep-gate 调查关闭（无需修复）

对上一轮标记的两个候选之一（Paralysis/Faint/Sleep 移动门）做完整可达性追踪后确认它是 假阳性，不是代码可执行的差异，本轮未改动 GDScript/C++ 实现：

• Paralysis：唯一 setter __Shaman_SetParalysis（InstanceBaseEffect.cpp:821）在整个可达 40250 源码树中零调用点，是死代码，40250 客户端实际运行时 IsParalysis() 恒为 false。
• Sleep：SetAffect() 的 AFFECT_SLEEP 分支已被注释掉，唯一存活路径是 AFFECT_STUN → SetSleep()（InstanceBaseEffect.cpp:932），即 IsSleep() 实际上是 AFFECT_STUN 的别名，已被当前端 entity_store.h:119 的 stunned 字段和 net_play.gd::_can_process_network_state() 的 dead/stunned/knock_down 门覆盖。
• Faint：唯一 setter chrFaintTest()（PythonCharacterModule.cpp:1087）是与 chrtestRestoreRenderMode 并列的调试用 Python 绑定，作用于 GetSelectedInstancePtr()； 现有 40250 检出没有 root/ Python 脚本可证明/证伪在线可达性，evidence-blocked，未修复。

调查过程中发现的衍生项（IsStun() 的 RecvStunPacket() 对主角 GC_STUN 走 Die() 而非 Stun()）核实后确认不是 movement.keyboard.motion 差异——CanAct() 对 IsDead()/IsStun() 的移动阻断效果相同，当前端 _can_process_network_state() 也已对 dead/stunned 同等阻断，移动结果已正确等价；Die()/Stun() 分流只影响死亡系统本身 （EXP 掉落/尸体/复活），已在 combat.affect-status.md Remaining #2、分支矩阵第 63/67 行登记，不在本合同重复记录。详见 audit/contracts/movement.keyboard-motion.md 的「调查轮次 2026-09-22T」小节。 该分支已关闭，不要在没有新 live 证据的情况下重新调查 Paralysis/Faint/Sleep 或 GC_STUN 主角分流。

movement.keyboard.motion 下一轮候选收窄为：AccumulationMovement 固定 300cm 根运动/连续速度替代差异、OnMove/OnMoving/OnWaiting/OnStop 资源事件源、同步/受击/ 死亡/传送门叠加顺序、真实模型骨骼快切不翻转的模型级测试——四者均仍未闭合。

network.login.phase_flow 的下一主候选仍保持文件前面记录的 network.login.phase_flow/auth-game-phase-matrix/live-package-order/server-initiated-phase-close： 本地结构和 owner 分支均已覆盖，只等新的真实服务端/Windows fixture；在没有新 fixture 前不要 重复 /logout 探针或重复修改已闭合的 owner 分支。

2026-09-22T03:15Z：movement.keyboard.motion/server-speed-scale-clamp 修复

追查上一轮列出的四个候选之一（AccumulationMovement 根运动/连续速度替代差异）时，先确认 远端 entity_store.cpp::advance_walk_by_motion 和本地 _process() 的位移积分在种类上同构 （都是恒速 speed*dt 直线插值），排除了「需要整体迁移到逐帧根运动采样」这个更大方向；转而 逐项核对两条路径各自的速度缩放公式，发现真正的差异：本地 set_server_speed() 把 moving_speed/100.0 塞进 clampf(..., 0.25, 3.0)，而参考 CInstanceBase::SetMoveSpeed （InstanceBaseMovement.cpp）和本项目已修复的远端 EntityStore::motion_move_speed 都只有 moving_speed>1100 → 0 一个门，没有下限/上限夹钳。已修复为 0.0 if moving_speed > 1100 else moving_speed/100.0，新增 keyboard_motion_timeline_test.gd 断言覆盖旧边界内外和 1100 冻结门，随同全部相关回归套件（test_wasd_steering_parity、 test_no_auto_move_regression、game_camera_test、movement_parity_test、player_move_test、 mouse_controller_test、test_alignment_parity、netplay_test）通过。详见 audit/contracts/movement.keyboard-motion.md 的 Implementation fix round 2026-09-22 — server-speed-scale-clamp 小节。该分支已关闭，不要在没有新证据的情况下重新调整 set_server_speed 的缩放边界。

副产品发现（未下定论，供下一轮参考）：CInstanceBase::SHORSE::SetMoveSpeed （InstanceBase.cpp:40-135）是坐骑上玩家的独立速度设定，只在 IsMounting() 时生效； 远端实体对 mount_vnum!=0 直接归零，而本地玩家改走 MOTION_MODE_HORSE 动作资源—— 两者是否构成差异本轮未核实，不要不经调查直接假设一致或假设有 bug。

movement.keyboard.motion 下一轮候选收窄为：AccumulationMovement 固定 300cm 根运动/连续速度替代差异（积分种类已确认同构，但逐帧时序/.msa motion event 源仍未对拍）、 OnMove/OnMoving/OnWaiting/OnStop 资源事件源、同步/受击/死亡/传送门叠加顺序、真实模型骨骼 快切不翻转的模型级测试、坐骑速度设定（SHORSE::SetMoveSpeed）——五者均仍未闭合。