网站修复记录：3D 魔方的朝向、复原公式与拖拽上限

这次的魔方问题不是一个孤立的按键错误。它连续表现为几种看起来互不相关的现象：转动视角以后，键盘仍像在操作同一个固定面；刷新或退出重进后，魔方没有可靠回到初始状态；界面给出的复原公式也不能恢复当前看到的打乱；自由拖动几圈以后，还会像碰到一道看不见的墙。

最后确认，这些问题都与“呈现坐标”和“逻辑坐标”的边界有关。

两套坐标系给出了两种答案

Blender 导出的魔方并不是以浏览器中的单位朝向直接出现。GLB 里还有 StudioObject_RubikCube 和 Rubik_ViewRoot 两层变换，进入聚焦状态以后又会应用屏幕居中的呈现姿态。

原来的初始化打乱直接使用固定逻辑轴，而活动中的键盘输入会根据当前相机重新解释 F/B、R/L 和 U/D。同一串符号因此有了两套含义：初始化时是一套，用户操作时又是另一套。只在单位矩阵下测试公式可以证明代数互逆，却无法发现真实模型朝向已经把“前、右、上”重新映射过一次。

修复后，控制器必须接收房间相机，并在相机和 GLB 层级准备好以后创建。初始打乱 R U r u 与后续键盘操作都经过同一个当前视角解析器；初始展示朝向下的提示 U R u r 才真正成为它的逆过程。

初始状态只属于当前一次体验

魔方此前还把操作结果写入浏览器存储。这与这个展廊的交互目标并不一致：访客刷新页面或重新进入魔方时，应该看到同一个可说明、可验证的初始题面，而不是上一次未完成的状态。

现在控制器保存两类内存快照：

• 不可变的初始打乱和 Blender 展示朝向，用于刷新、重进、退出完成和销毁后的复位。
• 仅在当前操作期间更新的最近稳定状态，用于取消指针或中断转动时回滚半完成动作。

魔方不再读取或写入 localStorage。这样“复位”有了唯一含义，也不会因为旧版本留下的数据再次偏离。

拖动锁止其实发生在 90°

自由观察使用拖动起点的稳定四元数作为基线，这部分累积方式没有损坏。真正的问题是每次拖动产生的水平和垂直角度都被限制在 ±π/2，也就是 90°。继续移动指针时，数值已经饱和，看起来就像魔方彻底锁住。

新的单次手势范围是每个屏幕轴 ±4π，允许连续转动两整圈。松开指针以后，当前四元数会成为下一次拖动的稳定基线，因此仍能继续转动，同时保留一个有限上限，避免异常指针位移产生失控数值。

聚焦后的魔方也稍微收小：动态适配目标从视口宽高的 0.60 × 0.60 调整为 0.54 × 0.54。在当前 16:9 相机和真实模型包围盒下，投影约为 32.36% × 57.54%，仍保持居中和完整，但给操作提示和周围留白更多空间。

用交付资产验证，而不只测公式

这次新增的回归不再只创建一个理想化魔方。测试会读取 manifest 当前指向的实际 GLB，恢复真实相机、外层根节点、Rubik_ViewRoot 和 26 个 cubie 的变换，再通过与生产一致的视角解析路径执行复原公式，并检查所有 cubie 的位置、旋转和缩放。

自由拖动也增加了确定性回归：输入等价于两整圈的指针位移，两个轴都必须达到 ±4π，不能在 90° 提前饱和。

这次修复留下的原则很明确：只要交互含有模型导出变换、相机方向或屏幕语义，测试就不能只停留在逻辑单位坐标。初始化、实时输入和提示文案也必须共享同一套坐标解释，否则每一部分单独看来都可能正确，组合起来却无法操作。