免费工作坊——候补名额邀请交接说明
示例：20个名额，使用已有会员身份，每位会员1个。活动为2026年10月12日14:00，报名截止10月11日18:00，均为Asia/Seoul。支付、团体、优先权和缩减名额不在范围内。
目的：按已受理顺序向候补者提供取消的名额，并再次确认参加意愿。候补受理、获得邀请和确认参加是不同状态，不承诺空位出现时间或一定入场。
顺序：以服务器确认受理的顺序为准，同一时间用服务器受理序号排序。同一会员在该场活动只能有一个有效候补、保留或确认记录，不公开其他申请者的信息。
容量：已确认名额+有效保留名额≤20。保留中的名额不能开放给普通报名。有有效候补队列时，新申请进入队尾；分配前条件变化则按当前状态重新判断。
新邀请：有空位、有有效候补者且距离报名截止至少24小时时，才为队首原子地保留1个名额。回复期限为邀请创建时刻加24小时。本例最晚新邀请时间为10月10日18:00，此后即使有空位也停止新邀请和普通报名。
接受：核对本人、活动、当前邀请和有效保留，在原子状态转换内检查服务器时间，必须严格早于回复期限及报名截止。不能采用客户端点击时间。将1个保留名额转为1个确认名额。
重复：对已经确认的同一邀请再次接受，返回原确认结果。过期邀请不能创建新保留，也不能将操作转到该会员另一条有效申请。
结束：拒绝、撤回和过期结束对应申请或邀请，只释放一次关联保留。确认后取消也只释放一次确认名额。过期清理与接受操作使用相同的原子判断边界，防止竞争。
重新报名：不自动恢复旧顺序。本人可在仍允许新邀请的时间内再次申请，按新受理顺序进入队尾。旧链接继续显示旧申请的结束状态。
通知：先保存邀请，再发送与之关联的邮件。发送请求、投递失败、打开和接受分开记录。失败或结果未知交运营确认，只重发同一邀请，不新增保留、不自动延长期限、不将发送成功当作接受；过期后不重发。
界面：同时显示活动、日期、含日期及时间区的回复期限、当前状态和可执行动作。邀请中：接受／拒绝。已确认：查看报名／取消。已结束：原因及能否重新报名。接受结果未知时查询当前报名，不宣称已确认。
记录：关联受理顺序、邀请创建与期限、结束原因、名额前后数量、接受判定时间、通知结果和操作人。管理员不能绕过顺序、容量或期限；改变政策须另行决策并更新文档。
交接：策划负责顺序与边界表；设计负责文案、动作和无障碍状态反馈；开发负责名额与邀请的原子转换及通知重试；QA记录12项条件的输入、预期和实际结果；运营记录投递失败与容量不一致的处理。
上线条件：重复保留、超额确认、过期接受、旧链接影响新申请，任何一项重现都阻止发布并按相同顺序复测。本例是虚构设计，未对真实活动服务完成联调。