木鸡 SteadyGame Alpha 冲刺第四天：三玩法最短闭环与保存事务硬化

一、Day4 站会

• 日期：2026 年 10 月 26 日（冲刺第四天）
• 会议方式：线下会议
• 主持人：林晨
• 参会人员：林晨、郑雯心、王婉怡、林宇扬、林凯、李想、孙田田、刘婷婷，共 8 人

画面为当天小组 8 人围绕 Day4 任务开展讨论。

Day4 不再继续铺开新模块，而是把前三天的输入、玩法、结果和保存路径连成最短闭环。站会明确三项优先级：

1. 三种玩法至少各有一条能正常开始、运行、结束并生成结果的路径。
2. 所有玩法使用统一的轮次状态、结果结构和错误口径。
3. 结果提交、保存历史、账号归属和游客转存必须分别验收。

二、今日目标：完成三玩法最短闭环与保存闭环

当天的目标链路为：

准备状态（相机 / 模型 / 同意 / 校准）
                ↓
创建并启动训练轮次
                ↓
小球真实倾斜 / 切水果腕点 / 八段锦阶段特征
                ↓
玩法冻结 GameResult
                ↓
统一结果网关 → 模式结果端点 → ResultValidator
                ↓
临时结果（不自动进入历史）
                ↓
用户明确同意保存 → Repository 保存事务 → 本人历史

三种玩法允许处于不同成熟度：

• 小球优先使用真实倾斜输入完成闭环。
• 切水果使用真实腕点或可重放轨迹完成命中、漏切和去重。
• 八段锦使用固定或合成阶段特征完成两式与四阶段流转。

固定输入只能证明玩法规则和接口链路，不能写成真实体感识别已经通过。

三、八位成员从 Day3 站会到 Day4 站会的工作进展

AI 技术员的工作单独列在第十节。AI 只提供测试建议、排查思路和文档草稿，成员负责确认业务规则、实际运行和记录采用结果。

四、三种玩法的统一结果与保存口径

4.1 小球

score = min(100, targetsHit × 10 + (reachedEnd ? 50 : 0))

使用“命中 2 个目标并到达终点”的样例，预期 score 为 70。目标、终点奖励和障碍处理都必须只执行一次；暂停时间不计入有效游戏时长。

4.2 切水果

score = cutCount × 10

腕点轨迹和水果移动使用相同时间区间判断。同一水果只能消费一次；未命中的水果和双腕重复相交不能重复计分。

4.3 八段锦

八段锦 score 固定为 null，不参加分数榜。两式都必须按约定阶段顺序完成；内部 actionAttempts 必须转换为接口约定中的 metrics.attempts/actions，不能另造字段。

4.4 结果提交与保存历史

五、Day4 跨模块交接

• 王婉怡把 MotionInput 字段、坐标单位、有效状态、失败原因和可重放样例交给三位玩法负责人。
• 林凯把共用 CollisionDetector 的输入定义和相交、相切、快速穿越用例交给林宇扬。
• 三位玩法负责人把冻结的 GameResult、结束条件、metrics 和失败场景交给林晨与刘婷婷。
• 林晨通过统一结果网关调用玩法结果端点，不允许每个玩法各自实现一套不同的提交逻辑。
• 刘婷婷使用公共 ResultValidator 和 Repository 检查身份、归属、幂等、保存同意与事务。
• 孙田田负责页面上的准备、运行、结算、保存和历史状态，不能把“接口返回成功”直接显示成“已保存历史”。
• 所有移交都包含模块位置、输入输出样例、正常运行方式、失败运行方式、未完成边界和 Issue。

六、Day4 测试清单

七、Issue、代码签入和运行证据

按照作业要求，每位参与开发任务的成员都要提供 Issue 内容、Issue 链接和对应代码签入记录，不能只写“模块已完成”。

本日实际运行与自动化验证结果：

• 数据库测试结构读取 11 张表和 3 条玩法种子，结果 PASS。
• 真实 HTTP 认证链路依次得到：CSRF 200、注册 201、重复用户名 409、错误密码 401、登录 200、me 200、旧 CSRF 403、登出 200、登出后 401。
• 真实 Repository 保存链路结果 PASS：score=70、sessionStatus=completed、savedToHistory=true、userIdWritten=true、guestIdCleared=true、expiresAtCleared=true、resultRows=1、saveConsentRevision=1。
• 后端累计测试 46/46 通过，前端累计测试 113/113 通过。

八、Day4 运行记录与图片补充说明

8.1 数据库与保存结构检查

Day4 在测试配置下读取到 11 张业务表，并确认 balance、fruit、baduanjin 三条玩法种子存在。保存流程执行后，训练轮次状态由进行中变为 completed，savedToHistory=true，账号 user_id 已写入，游客 guest_id 和临时结果 expires_at 已清空；同一轮次只有一条结果记录，save 同意记录 revision 为 1。

8.2 认证与 CSRF 链路检查

Day4 使用真实 Tomcat 端口复测了游客 Cookie 与认证过滤器。运行中发现 MockMvc 测试能够通过，但真实 HTTP 请求中的 SGGUEST 没有在过滤器阶段解析；修复为直接使用当前 HttpServletRequest 读取 Cookie 后，认证链路恢复正常。

实际请求结果为：CSRF 200、注册 201、重复用户名 409、错误密码 401、登录 200、当前用户 200、旧 CSRF 登出 403、正确登出 200、登出后访问当前用户 401。

8.3 结果校验与游客转存

Day4 使用 70 分小球样例执行了结果保存。结果通过分数公式、轮次状态、账号归属和保存同意校验后，由游客轮次转存到当前账号；同一结果重复提交保持幂等，不产生第二条记录。

图：2026 年 10 月 26 日本地真实运行的 Spring Boot 验证页面。使用 Java 17、Tomcat 和 H2 测试数据库，实际提交 70 分小球结果并连续保存两次。页面返回 PASS，并显示 savedToHistory=true、userIdWritten=true、guestIdCleared=true、expiresAtCleared=true、resultRows=1、duplicateSaveRows=1、saveConsentRows=1、saveConsentRevision=1、savedAtWritten=true。该截图证明保存事务与幂等路径，不代表真实 MySQL 已验证。

8.4 页面与完整玩法联调

前端页面能够正常启动，并显示大厅、三种玩法入口和基础准备状态。Day4 的完整页面验收还需要补齐以下 Day4 当日画面：小球真实倾斜运行、切水果命中与漏切、八段锦阶段推进、结算页显示临时结果、明确保存后的个人历史。

图：Day4 在本地启动的真实前端页面，能够显示大厅和三种玩法入口。该截图用于证明前端程序可以启动和渲染，不等同于三种玩法的真实设备联调已经完成。

九、燃尽计划

按 52 SP 样例基线计算：

实际剩余工作量必须以 CodeHub Issue 和当天验收结果为准，不能因为代码已经提交就自动扣减；未通过运行验收的任务继续保留在剩余工作量中。

十、AI 技术员

Day4 的 AI 技术员继续按“生成候选—人工评审—实际运行—记录结果”工作：

• AI 设计师检查 GameResult、统一网关、保存历史与页面状态之间的边界，避免把“提交结果”和“保存历史”混成一个动作。
• AI 程序员协助整理真实 HTTP 认证测试、Cookie/CSRF 过滤链诊断、保存事务和越权场景。
• AI 测试员生成重复提交、不同结果冲突、账号隔离、游客转存、过期保存和明确同意等测试用例。

AI 提出的内容必须由成员补业务规则并实际运行。运行中曾发现 MockMvc 能通过、真实 Tomcat Cookie 上下文却解析失败的问题；团队没有据此伪造成功，而是增加真实 HTTP 随机端口测试并修复过滤器传参。AI 输出被采纳的比例、人工修改原因和测试结果均记录在提交与验收矩阵中。

十一、Day4 复盘与 Day5 安排

Day4 的核心不是单纯增加页面，而是把“输入能驱动玩法、玩法能生成结果、结果能通过校验、用户同意后能进入历史”拆成可独立验收的步骤。需要特别保持以下区分：

• 相机预览正常不等于 MotionInput 有效。
• 固定输入跑通不等于真实体感联调完成。
• 结果提交成功不等于已经保存到个人历史。
• H2 集成测试通过不等于真实 MySQL 迁移验证完成。
• 代码签入不等于 Issue 已验收。

Day5 将推进历史、统计、报告、排行榜和导出文件下载：

1. 历史查询覆盖玩法、时间区间、分页和空数据。
2. 统计与报告只读取本人已保存数据。
3. 排行榜只包含明确选择公开的记录，支持撤回。
4. 导出任务生成 CSV/PDF 文件，下载接口校验登录、归属、任务状态和过期时间。
5. 数据库、接口、页面和 Issue 证据再次对应，未执行项继续明确标为未执行。