C29：预约与候补，三个版本的交付练习

这是一套合成材料，没有真实活动、客户、模型结果或真人反馈。用它练习把变化落实到数据、程序和交接；不是企业级成品。

下载与起步

把参考程序、初始数据、检查样本、配置放在同一文件夹。另有自由文字提取题、教学评语和真人试用空表。可先不看参考程序，按下面的约定自行实现，再对照结果。

两场活动S1、S2各1席；P1分别有报名R11、R21。同一个人不是同一笔报名。P2同时候补两场并不冲突；本题两场时间不同。

第一版：正常取消后只产生草稿

组织者确认取消R11/S1，空位按候补顺序给P2产生邀请草稿。草稿预留这一席，但未通知也未确认报名。只有组织者确认邀请后才开始计时；P2在期限内接受才形成报名。S2的R21不变。

刻意的坏办法是“按P1查出全部报名然后取消”。它会找到R11和R21。参考程序的额外检查把这两个错误候选列出，再验证只取消S1时R21仍在；不是用测试名称遮掉这个数据设计问题。

第二版：让异常也有结果

样本按顺序给10条消息：明确取消、原消息重复、含糊取消、确认邀请、接受邀请、另一场取消、确认、到期、迟到接受、同消息编号换内容。duplicate表示同号同内容，不重复产生邀请；id_conflict表示同号内容变了，拒绝执行。只写“周末那一场”停在needs_clarification，不猜选场次。

过期从now >= expires_at开始。CLOCK事件将到期邀请标为expired，给下一个候补者产生新草稿；旧邀请迟到接受不能挤占新草稿。每次状态变化都检查“已报名＋草稿或有效邀请占用的席位不超过容量”。时间是教学起点后的分钟，没有真实日历。

第三版：把说明交给另一个人

电脑有Python 3时，在文件夹中运行：

python3 reference.py
python3 reference.py --ttl 10

程序只读取同目录文件、在内存计算并输出JSON；不安装依赖、不联网、不写数据库、不发通知、不收款。正常完成会显示10条结果，以及15分钟、10分钟有效期的对照。4分钟确认邀请，15分钟检查时：原配置到期点19，尚未到期；新配置到期点14，已经到期。

接手者也可把config.json的invite_ttl_minutes由15改10，再不带参数重跑。先记录原配置，改完让另一个人按输出复述变化；若真请人试用，在空表记录实际卡点。teaching-feedback.csv是预写的示例意见，不得转记为真人已测试。

这次运行能证明什么

程序检查串行合成样本中的场次、编号、状态与容量关系。它不实现真实身份鉴别；ORG、P2、CLOCK仅是题目角色。事件编号账本和业务状态都在内存里，程序重启即丢失，不能证明分布式并发、持久化或生产中的恰好一次执行。生产项目还需要持久保存、事务或等价约束，参见第16章。

运行后，可以用下面的对照说明自己掌握了哪一段能力，而不只报告“程序通过”。这些都是本包已有的样本与输出，无须另做一个项目。

本包故意使用普通规则。若加入AI，只让它先做extraction-exercises.json的两条待确认提取，保存实际输出与错误，再讨论要不要进入取消动作。参考答案不是模型表现。物流方向可接着练第28章；目标岗位不同，需要补的深度也不同。