返回 TeachFlow 项目总览 · 交互图：课堂 · 会话 · 生命周期
打开一节课程并点击“播放”，并不等于拥有课堂运行时。真实课堂会临时切换场景、创建白板对象、派发任务、接收学生提交，也会遇到刷新、断线、重复操作与课后追溯。若这些变化直接写回课程定义，教师的一次现场操作就可能污染以后所有班级。
TeachFlow 因此把 Lesson revision 与 Classroom Session 分开：前者是已发布教学材料，后者是一次有身份、班级、状态和恢复语义的运行实例。
Session 拥有自己的状态
Session 绑定教学班、课程 revision 与教师身份。准备阶段可以检查依赖，运行阶段允许追加课堂对象和互动，暂停或恢复不改变课程版本；结束后进入只读复盘，普通操作不能重新打开终态会话。
服务端对期望 revision 做并发检查，同一命令的稳定标识用于幂等重放。浏览器显示“已恢复”不是权威，真正状态仍来自服务端 Session 与 Board 文档。
课堂动作不是学情事实
课堂中完成一次互动、画出一个对象或点击“已讲解”，都不能自动成为学生掌握证据。只有明确派发给学生、形成提交并经过既有评分或教师确认合同的任务，才可能进入学习事件。
这条边界保留了课堂的灵活性：教师可以临时探索、撤销或放弃候选，而不会因为 UI 动作污染 Current。
结束之后留下什么
Session 结束时可以生成 recap，记录使用的课程版本、关键对象、互动和未处理事项。教师还可以显式把选定课堂成果 materialize 为新的课程 revision；这是一项新的治理决定，不是系统自动覆盖原课程。
运行时观测也遵守成本边界。项目记录过本地 Canary、采样和发布候选流程，但真实试点、长期连接和多实例故障仍需要外部环境验证。
最小恢复场景：刷新之后不能靠浏览器猜
教师在 revision 12 的白板上创建一个函数对象，服务端提交后 Board 推进到 revision 13，但浏览器尚未收到响应就刷新。重新进入课堂时，客户端必须从 Session 和 Board 的权威状态恢复，不能因为本地没有成功提示就重复创建对象。相同命令若带稳定标识，可以安全确认是否已提交；若客户端仍持有 revision 12 的旧预览，则服务端应拒绝覆盖 revision 13。
结束状态同样需要权威语义。教师点击结束后，普通课堂 mutation 应被拒绝；“重新打开”若未来需要支持，应是一项显式治理动作，而不是把状态字段从 ended 改回 running。否则 recap、学生任务截止与课后材料都会失去确定时间边界。
设计取舍：为什么不能把 Session 存进课程页面状态
页面状态只服务当前标签页，无法承担跨刷新、跨设备、并发教师或课后审计。Session 是服务端业务实体，课程播放器只是它的一个客户端。分离之后，Lesson revision 可以跨班复用，Session 则保存班级、教师、时间、课堂对象和运行状态。
这也说明当前证据缺口：源码合同与生命周期图可以确认设计，只有在真实数据库、浏览器断线、重复提交和多实例竞争中重跑，才能把恢复链从 code-confirmed 提升为本轮 verified。
当前边界
源码、架构文档和现有生命周期图确认了 Session 状态、恢复、recap 与 materialization 合同；本轮未重新执行 Classroom Runtime 的数据库、浏览器和故障演练，因此为 partial。图表证明可读性，不证明某个会话当前在线。
结论
课程是可复用定义，课堂是一次有开始、有结束、可恢复、可复盘的事件。把两者分开，才能允许现场灵活变化，同时保住课程版本与学习证据的权威边界。