评审结论
有条件通过
方案方向可行，应复用现有菜单、点餐入口、正式消费订单、取餐和退款能力；但不能按“只增加最低人数、三种状态和通知”直接开发。必须增加拼团活动与报名聚合层，并先确认结算和失败处理规则。
系统边界
不重做正式订单，但需要正式订单前的报名聚合层。
继续复用
- 餐厅、档口、菜品、菜谱和餐次
- 手机端选餐与购物车交互
- 成团后的正式消费订单与取餐核销
- 满足适用条件的取消、退款与账务能力
必须新增
- 拼团活动、报名与菜品价格快照
- 活动状态机、定时关团和并发锁
- 正式订单转换、唯一业务号与幂等补偿
- 通知记录及未成团资金处理
Tigers：真实风险
前五项属于开发和上线前阻断项。
1. 支付与成团口径未确定
Launch-Blocking报名不付款会导致成团后大量弃单；报名即付款会产生未成团批量退款；余额冻结后扣款体验最佳，但可能需要新增账务能力。
2. 当前下单链路会立即形成正式订单
Launch-Blocking这与“先报名、截止后成团、再进入消费订单”冲突。应新增报名层，不能用普通未支付订单状态代替拼团报名状态。
3. 关团并发与重复执行
Launch-Blocking最后报名、员工撤销、定时关团和人工操作可能同时发生。必须通过数据库事务、条件更新和唯一键保证只成团、转单或退款一次。
4. “最低人数”的统计粒度不清
Launch-Blocking必须明确按人、份、订单、菜品还是套餐成团。首期建议“一场活动对应一个固定套餐，按去重员工人数成团”。
5. 未成团不等同于现有订单退款
Launch-Blocking应分别定义撤销报名、未成团释放/退款、正式订单取消退款。三类动作的状态、截止时间和资金路径不能混用。
6. 菜品库存与报名人数可能竞态
Fast-Follow报名不进入正式订单时可能不占用现有库存，成团集中转单会超量。固定套餐试点可采用活动配额，通用拼团需要预占机制。
7. 通知不是单纯选择一个渠道
Fast-Follow小程序、短信和企业微信均存在授权、模板、成本或身份映射约束。首期应以小程序结果页为必达通道，外部消息仅作提醒。
首期建议范围
一个餐厅、一个餐段、一个固定套餐；按去重员工数成团；截止前可撤销，截止后不可自行修改；系统自动且只关团一次；成团后进入正式消费订单，未成团不进入后厨备餐。
开发前必须确认
这四项未确认，不建议直接估时排期。
统计口径按人、份、订单还是套餐？
结算时间报名扣款、成团扣款还是就餐结算？
失败策略取消、顺延还是继续开放？
取消退款截止前后分别允许哪些操作？
上线前行动
按业务决策、技术设计、真实验证的顺序推进。
| 动作 | 责任方 | 完成条件 |
|---|---|---|
| 确认支付/结算模式 | 产品、客户、财务 | 写清报名、成团、扣款、退款四个时点 |
| 确认成团统计粒度 | 产品、客户、食堂运营 | 明确人数/份数、重复报名和代报规则 |
| 输出状态机与异常矩阵 | 产品、后端、测试 | 覆盖报名、取消、关团、转单、退款和通知失败 |
| 验证订单和退款边界 | 后端、测试、财务 | 对选定支付方式完成真实测试环境闭环 |
| 小范围试运行 | 项目、食堂运营 | 一个餐厅、一个餐段、一个套餐运行一周 |
证据边界：本页是开发前风险预演，不代表客户确认、开发完成、测试通过或生产上线。代码判断基于 2026-07-30 本地检出与重庆环卫相关分支快照，生产版本仍需单独核验。