测试通过

docs/development-guide.md

@@ -49,6 +49,14 @@
 
 当前实现假设一次只保留一个主音频 WebSocket 连接。新连接到来时会主动关闭旧连接。这是刻意简化，不是 bug。
 
+现在这个约束已经扩展到三个浏览器通道：
+
+- `WS /ws/audio`
+- `WS /ws/subtitles`
+- `WS /ws/animation`
+
+也就是说，服务端当前只允许一个浏览器页面完整接管数字人会话。新页面连上后，旧页面会被主动断开，关闭码为 `1012 replaced`。
+
 ### 3.2 会话状态机
 
 [core/state_machine.py](../core/state_machine.py) 的状态很轻：
@@ -99,6 +107,7 @@
 - 维护聊天消息面板和诊断面板。
 - 用 Three.js + VRM 加载和渲染模型。
 - 把动画控制帧缓存约 `120ms` 后再播放，尽量和音频保持一致。
+- 处理刷新后的语音恢复：如果浏览器拦截自动恢复，会等待下一次用户手势再恢复麦克风和播放上下文。
 
 前端当前兼容三种形态：
 
@@ -106,6 +115,11 @@
 - 通用 GLTF morph target。
 - 没有表情 rig 时回退到调试头像。
 
+当前前端待机动画状态：
+
+- 已启用随机眨眼。
+- 更激进的身体 idle motion 已回退，因为部分 VRM 模型会出现 T pose 或姿态异常。
+
 如果以后想接入真实业务数字人模型，先确认模型是否提供：
 
 - 标准 VRM 表情。
@@ -177,10 +191,11 @@
 这些约束需要后续开发明确知晓：
 
 - 当前是进程内单例服务，不是多租户、多 session 设计。
-- 浏览器侧只允许一个主音频 WebSocket 会话接管服务端语音输入输出。
+- 浏览器侧只允许一个页面完整接管服务端语音输入输出与字幕/动画订阅。
 - 模型推理基本都直接跑在应用事件循环附近，适合研发验证，不适合高并发。
 - 当前动画驱动依赖音频能量和谱质心，不具备严格唇音级别精度。
 - 语音链路高度依赖 VAD；如果要做电话式长连接交互，建议补更稳的 turn management。
+- 浏览器刷新后不保证零手势恢复语音；这是浏览器媒体策略约束，不是后端故障。
 
 ## 9. 推荐扩展方向