候补第1名，出现取消名额就能直接确认吗？

先确认“有人取消就补上下一位”承诺了什么

假设免费工作坊的20个名额已经确认，甲、乙、丙依次候补。有人取消后，直接把甲改成参加者就可以吗？报名候补时有空，不代表几天后仍然能来。决定自动处理之前，需要先确认候补申请到底代表什么，以及是否要再次确认参加意愿。

本例的目标是补上取消的名额，同时让较早申请的人先获得机会。因此要分开候补受理、获得名额邀请和确认参加。顺序决定谁先收到邀请，并不保证入场。如果界面把候补成功写成报名确认，后续流程还没开始就已经传达了错误承诺。

接到需求后，先看报名页面的约定、取消发生的时间、申请者需要多久回复，以及运营何时需要最终名单。这里使用已有会员身份，每人1个名额，只有一个免费场次。团体、支付和优先分配不在范围内；人物与数量均为示例条件。

不要直接照搬别人的候补释放按钮

Bevy的公开帮助文档按票种描述了不同处理：付费票部分由收到邀请的人领取，而仅RSVP的部分由运营释放后直接登记参加。同样叫释放，并不意味着相同承诺。这里借它确认政策存在差异，并不是说该产品实现了下面的设计。

最初想到的取消后自动确认最省步骤，但无法再次确认当前意愿。向所有人发通知、谁先点就给谁，则把受理顺序变成了反应速度。本例选择先为队首保留一个名额，再让本人在规定时间内接受。

这个决定也有代价：等待回复时名额不能给别人，临近活动的取消可能留下空位。本例优先遵守约定的回复机会，不临时缩短最后一人的时间。自动确认并非永远错误；如果另一项服务在最初申请时已明确约定自动转入，选择就可能不同。

承诺24小时，就也要给最后一人24小时

活动设为2026年10月12日14:00，报名截止是前一天18:00，均采用Asia/Seoul。每个新邀请从创建开始有效24小时，所以最晚邀请时间为10月10日18:00。此后即使出现空位，也停止新邀请和普通报名，不给最后一人突然改成只有十分钟。

候补按服务器确认受理的顺序排列，同一时刻以服务器受理序号打破平局。同一会员在该场次只能拥有一条有效候补、保留或确认记录。有有效候补队列时，新申请也进入队尾，不能因为普通报名页面仍然能打开就绕过等待的人。

只计算确认人数不够。已确认名额与有效保留名额合计不能超过20。向甲发出邀请后，普通申请不能再拿走同一个名额。检查空位、选择队首和建立保留必须一起成功，或者都不生效，把这个条件写进开发说明。

邮件发出去了，不代表名额已经确认

新邀请前，同时确认空位、有效候补者和完整24小时。条件满足后，先保存为队首保留1个名额的邀请，再发送关联邮件。发送慢不能成为再建一个邀请的理由，否则同一人可能占住两个名额。通知重试应始终围绕原邀请记录进行。

接受是另一项判断。核对本人、场次、当前邀请和有效保留。在原子状态转换内确认的服务器时间，必须严格早于邀请期限与报名截止，刚好等于期限也算结束。不能因为页面上较早点击，就信任客户端时间覆盖服务器判定。

但要先识别已确认的同一邀请重试，并返回原确认结果。否则成功响应丢失后再试，可能错误显示过期。接受与过期清理也要使用相同的原子判定边界，确保只反映一种结果。单纯禁用界面按钮无法保障这些规则。

不要把过期和邮件失败当成同一种结束

拒绝、撤回和过期结束对应申请或邀请，只释放一次关联保留。确认后取消也只退回那一个确认名额。同一取消请求来了两次，不能变成两个空位。名额退回后，要根据当前时间与队列重新判断能否产生新邀请。

邮件失败不等于拒绝。交运营检查，只重发同一邀请，不增加保留、不修改期限；过期后也停止重发。发送请求、投递失败、打开和接受分开记录，才能看出卡在哪里。不能根据发送成功就把甲列为确认参加，也不能同时把该名额给乙。

过期后不自动再次排队。如果仍在允许新邀请的时间内，本人可重新申请进入队尾。旧链接继续显示旧邀请已结束，不能把旧接受按钮绑定到新申请。下面是固定状态文案示例，不会创建真实报名或发送邮件。

让AI找出会破坏顺序的反例

只说做一个候补功能，很容易先得到通知和顺序界面。先给出容量、受理顺序、24小时邀请、报名截止和重新申请规则，再把任务限定为找出这些决定之间的冲突、整理检验输入。不要让答案不知不觉替你换了一套政策。

如果建议邮件失败后通知下一人，就检查原保留何时结束。原邀请仍有效时又把同一名额交给别人，不能采用。管理员随意延长期限也改变了本例约定，不能当成实现细节直接塞进设计说明。需要改变就另行留下决策。

下面是未执行的提问示例。收到答案后，先对照名额前后数量：19个确认加1个保留，接受后应为20个确认加0个保留。重复取消不能增加空位。改好的条件还要同步进QA和运营说明，不能只停在聊天里的文字修正。

提问示例：免费工作坊有20个名额，每位会员1个。取消后按受理顺序保留1个名额，给24小时接受。距离报名截止不足24小时，停止新邀请和普通报名。请检查同时取消、刚好到期时接受、成功响应丢失、邮件失败、过期后重申请中会破坏顺序或容量的情况。分别给出名额前后数量、画面文案、开发条件和QA预期结果，不假设真实成果或外部政策。

把每个人开工需要的资料交代清楚

策划书记录为什么选择邀请后接受，以及为何允许临近活动出现空位。设计说明把候补、邀请、确认、结束分别连接到文案和操作。邮件需要同时提供活动时间与包含日期、时间区的回复期限；只写明天之前，会让晚读邮件的人理解不同。

开发交接除了画面状态，还需要名额只能改变一次的条件。运营界面关联受理顺序、邀请期限、结束原因、名额变化和通知结果。管理员也不能绕过容量、顺序或期限；需要例外时，应先记录依据并做独立政策决定。

W3C的状态消息说明用于支持这样的原则：不移动焦点的处理结果变化，也应能被辅助技术识别。本例将接受处理中、确认成功、无法确认用文字和适当状态反馈区分。可见提示与无障碍实现要一起检查，不能只变一种颜色。

正常接受一次，不能代表验收完成

验收表要写起始状态与请求顺序，而不只是按钮名称。20个确认同时取消两人，应只空出两个名额，并依次为前两名候补各保留一个。检查两个处理任务是否抢到同一队首，以及同一个取消是否被重复释放。

期限测试要分成之前、相同时间和之后。服务器在原子转换内检查时间，因此还需要让请求在进入该判断前延迟。下面是实现后应执行的检验条件。操作本文的固定展示与真实工作坊联调，是不同范围的验证，要分别记录。

复用前先修改前提，而不是只换活动名

下面的材料假设已有会员身份、一个免费场次、每人1个名额，并按受理顺序候补。团体申请或优先分配需要重新决定是否允许跳过队首。如果服务要求一直补位到活动开始，就不能原样沿用24小时机会与停止邀请的时间。

交接前，团队按同一个例子核对顺序、期限和容量。如果开发创建邀请时并不保留名额，设计就不能写已保留。把决策表、界面文案与QA输入一起修改，不要让下一个人再来问哪份文档才是最新版本。

首次发布把重复保留、超额确认、接受过期邀请、旧链接改变新申请列为阻止上线的缺陷。运行后用邀请和通知失败记录找出处理卡点。邮件打开不代表参加成果，确认与取消应各自留下记录，再讨论实际结果。

免费工作坊——候补名额邀请交接说明
示例：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项条件的输入、预期和实际结果；运营记录投递失败与容量不一致的处理。
上线条件：重复保留、超额确认、过期接受、旧链接影响新申请，任何一项重现都阻止发布并按相同顺序复测。本例是虚构设计，未对真实活动服务完成联调。

来源与示例条件

本文是虚构免费工作坊设计。Bevy公开资料用于比较不同类型的政策，W3C用于参考状态反馈原则。容量、顺序、24小时期限与截止规则为本例选择，并非真实活动成果。AI提问是未执行示例，英文与中文是同一韩文案例的本地化版本。

Bevy — Waitlist Registration

W3C — Understanding SC 4.1.3: Status Messages