01. 这次补齐了什么
PC 管理端3 页
批次列表、发布/复制、批次详情
小程序/H56 页
列表、详情、确认、报名结果、结算指引、结算结果
核心状态8 个
从草稿、报名到供餐完成和取消
核心测试33 条
发布、并发、通知、结算、权限和页面可达性
系统边界：现有系统的人盘绑定、绑定订单、余额校验和计重/计次订单底座继续复用；新增拼团批次、报名、判团、通知任务和订单关联，不再做第二套绑盘与支付。
02. 端到端业务流程
管理员配置并发布
→用户查看与确认报名
→事务内累加数量
→达门槛即时成团
→创建双向通知任务
→到店校验资格
→现有设备完成结算
→关联真实订单
员工餐
- 每人每批次固定报名 1 份。
- 预定堂食、现场就餐、盒饭均可报名。
- 堂食由实际菜品计价属性决定计重/计次。
- 存在有效人盘绑定时跳过独立绑盘机。
客餐
- 小程序单独预定盒饭，可按份数报名。
- 批次进度按盒饭份数计算。
- 只允许计次结算，不允许计重。
- 扣款账户必须配置，未确认时阻断生产发布。
03. 页面之间如何跳转
PC 管理端
批次列表 → 新建/复制发布 → 批次详情 → 报名明细 / 通知记录 / 结算异常。延期、取消和通知重试在详情执行，返回保留列表筛选。
小程序/H5
拼团列表 → 拼团详情 → 报名确认 → 报名结果 → 返回详情；成团后由详情进入结算指引 → 结算结果 → 现有订单详情。
04. 批次状态机
草稿
draft
draft
待开始
scheduled
scheduled
报名中
open
open
已延长
extended
extended
已成团
success
success
供餐中
serving
serving
已完成
completed
completed
未成团/取消
failed/cancelled
failed/cancelled
关键规则：成团是不可回退状态，个人不能再取消；管理员异常取消必须写原因。报名状态、结算状态和通知状态分别管理，禁止一个 status 字段承载全部业务。
05. 开发必须共同遵守的契约
| 领域 | 必须实现 | 禁止做法 |
|---|---|---|
| 报名 | 报名、数量累加、成团判断同一事务；用户+批次唯一有效报名；幂等键 | 先查数量再无锁写入；重复点击重复计数 |
| 判团 | 达到门槛即时成团；截止任务可重复执行无副作用；仅延长一次 | 依靠前端倒计时决定能否报名；无限延期 |
| 通知 | 事件 Outbox；管理员和报名人拆任务；失败退避重试并保留历史 | 第三方消息失败回滚成团；覆盖失败记录 |
| 结算 | 报名不扣款；用餐时关联真实订单；回写失败只补关联 | 让用户自由选择计重/计次；超时再次扣款 |
| 绑盘 | 复用现有有效绑定并继续执行余额、人员、餐厅和设备校验 | 拼团报名自动绑定任意餐盘；新建重复映射 |
| 权限审计 | 所有写接口校验角色和餐厅范围；取消/延期/重试记录前后值 | 只依赖前端按钮显隐；手工改库作为正常运营 |
后端
5 张核心表/关联、3 组 API、5 个定时或补偿任务、稳定错误码和幂等锁。
前端
9 个页面、跳转参数、动作显隐、加载/空/失效/冲突状态和返回行为。
测试
状态合法/非法转换、50 并发最后名额、重复任务、重复结算、权限越界和真实设备联调。
06. 本地真实运行截图
07. 上线前必须由客户确认
客餐扣款归属个人、接待部门或统一招待账户；对应主数据和审批规则上线阻断通知渠道小程序订阅消息、企业微信、短信及管理员接收范围上线阻断客餐数量上限单次、单日、单部门最大盒饭份数需确认成团后异常取消已经备餐时的责任、费用和订单处理规则需确认
评审结论建议：研发可先按“可配置账户类型、可配置通知渠道和份数上限”开始数据模型与页面开发；客餐生产发布开关保持关闭，直到四项业务决策完成确认。