系列第 14 篇实现编辑、截止、关闭、取消、满员和过期并处理“状态失效但已经披露的联系方式不能撤回”这一真实边界。发布、候选和交换完成后信息不会永远有效。用户会改时间、停止找人、取消行程也可能因站内确认或站外安排而满员。后台任务还可能晚几秒运行。K6 的目标不是增加几个状态按钮而是让页面、服务、查询和定时扫描对每个状态说同一种语言。编辑权限取决于是否已经交换首次交换前发布者可以修改影响匹配的时间和路线。服务增加信息修订版本让旧候选失效后按新内容重算。这一步发现 K3 的唯一约束缺少修订版本。如果唯一键只有“车主信息、乘客信息、规则版本”编辑后即使旧候选失效数据库仍不允许产生新候选。最终唯一事实改为车主信息 乘客信息 车主修订版本 乘客修订版本 匹配规则版本旧解释不被改写新候选能准确指向修改后的两份信息。发生联系方式交换后日期、时间窗口和路线被锁定。因为对方已经依据旧内容获得联系方式静默修改会破坏双方对同一件事的理解。此时仍允许修改尚未到达的匹配截止和合法座位数路线真的变化应取消后重新发布。满员必须记录来源系统因双方确认达到座位数而满员可以在配对取消或增加座位后自动恢复。车主在站外已经安排满员则不能被站内取消动作重新打开。因此状态之外还保存system或manual来源。手动满员重新开放时车主必须明确填写当前可用座位而且截止和出发时间都还没到。关闭、取消和过期是终态不能把旧信息直接恢复为有效。继续寻找必须新建信息避免已经分享出去的链接在不同出行之间反复复用。不等待后台任务才能保证正确大厅查询本来就会排除截止和出发时间已到的信息。K6 再增加幂等扫描把数据库状态和事件补齐到匹配截止产生一次结果事件到出发时间把有效或满员信息落为过期等待双方反馈的配对到较早出发时间落为确认超时已确认配对不会被超时扫描覆盖。扫描运行两次事件键和状态都保持唯一。即使 Worker 晚运行实时查询和操作仍按服务器时刻拒绝过期行为后台任务负责补全持久化事实不是权限正确性的唯一依赖。已披露的微信号不能被页面撤回关闭或取消会让候选失效但双方在此前已经合法看到微信号。软件无法让对方忘记也不应该让页面假装历史交换从未发生。实现中把候选查询拆成两类有效候选允许新的联系方式交换 参与者历史候选允许双方查看已经发生的交换结果浏览器旅程中车主在“我的信息”关闭发布后乘客刷新交换结果仍能看到此前的加密快照。新的候选和交换则已经停止。一次测试失败纠正了错误前提浏览器测试最初期待双方确认后信息显示“座位已满”。失败页面清楚显示车主发布了两个座位只确认了一名乘客正确状态本来就应是“正在寻找”。测试随后修正前提而不是把实现改成确认一人就满员。这类失败很有价值TDD 不代表测试永远正确失败时仍要回到产品事实判断哪一边错了。本节点结果99 个非浏览器测试通过1 个 PostgreSQL 专属测试明确跳过分支覆盖率 88.55%静态、类型、迁移和 Django 检查通过4 条 Chromium 旅程通过编辑修订、状态来源、截止、过期、超时和历史披露都有自动证据外部提醒、PostgreSQL 并发、WebKit 和微信真机仍未宣称通过结果只形成本地提交不推送。下一篇进入 K7业务事件已经存在后怎样通过数据库待办可靠调用喵提醒区分明确失败和结果未知并避免短时间内连续轰炸用户。关键代码与操作下面的简化测试把生命周期扫描执行两次确认终态和业务事件都不会重复deftest_lifecycle_sweep_is_idempotent(expired_trip,pending_pairing):sweep_trip_lifecycle(nowNOW)sweep_trip_lifecycle(nowNOW)expired_trip.refresh_from_db()pending_pairing.refresh_from_db()assertexpired_trip.statusTripPost.Status.EXPIREDassertpending_pairing.statusPairing.Status.TIMED_OUTassertBusinessEvent.objects.filter(event_typetrip.matching_closed).count()1assertBusinessEvent.objects.filter(event_typepairing.timed_out).count()1验证命令make bugfix TESTtests/trips/test_lifecycle.py::test_sweep_is_idempotent_for_deadline_expiry_and_pairing_timeout后台任务可以晚到或重跑但同一个截止事实不能因此产生两次。本篇验证摘要联系方式交换前可以修订时间和路线交换后会锁定影响双方理解的字段关闭、取消和过期是终态继续寻找必须创建新信息实时查询按服务器时间排除失效信息不依赖后台扫描准时运行幂等扫描负责补齐截止、过期和确认超时事件不重复改变已完成状态信息结束后禁止新的交换但参与者仍能查看此前合法披露的联系方式。附录相关工具与仓库gstack仓库garrytan/gstack地址https://github.com/garrytan/gstackdev-harness仓库Dev-Wiki/dev-harness地址https://github.com/Dev-Wiki/dev-harnessUI UX Pro Max Skill仓库nextlevelbuilder/ui-ux-pro-max-skill地址https://github.com/nextlevelbuilder/ui-ux-pro-max-skill AI 软件开发实战教程（十四）：让出行信息按规则结束
系列第 14 篇实现编辑、截止、关闭、取消、满员和过期并处理“状态失效但已经披露的联系方式不能撤回”这一真实边界。发布、候选和交换完成后信息不会永远有效。用户会改时间、停止找人、取消行程也可能因站内确认或站外安排而满员。后台任务还可能晚几秒运行。K6 的目标不是增加几个状态按钮而是让页面、服务、查询和定时扫描对每个状态说同一种语言。编辑权限取决于是否已经交换首次交换前发布者可以修改影响匹配的时间和路线。服务增加信息修订版本让旧候选失效后按新内容重算。这一步发现 K3 的唯一约束缺少修订版本。如果唯一键只有“车主信息、乘客信息、规则版本”编辑后即使旧候选失效数据库仍不允许产生新候选。最终唯一事实改为车主信息 乘客信息 车主修订版本 乘客修订版本 匹配规则版本旧解释不被改写新候选能准确指向修改后的两份信息。发生联系方式交换后日期、时间窗口和路线被锁定。因为对方已经依据旧内容获得联系方式静默修改会破坏双方对同一件事的理解。此时仍允许修改尚未到达的匹配截止和合法座位数路线真的变化应取消后重新发布。满员必须记录来源系统因双方确认达到座位数而满员可以在配对取消或增加座位后自动恢复。车主在站外已经安排满员则不能被站内取消动作重新打开。因此状态之外还保存system或manual来源。手动满员重新开放时车主必须明确填写当前可用座位而且截止和出发时间都还没到。关闭、取消和过期是终态不能把旧信息直接恢复为有效。继续寻找必须新建信息避免已经分享出去的链接在不同出行之间反复复用。不等待后台任务才能保证正确大厅查询本来就会排除截止和出发时间已到的信息。K6 再增加幂等扫描把数据库状态和事件补齐到匹配截止产生一次结果事件到出发时间把有效或满员信息落为过期等待双方反馈的配对到较早出发时间落为确认超时已确认配对不会被超时扫描覆盖。扫描运行两次事件键和状态都保持唯一。即使 Worker 晚运行实时查询和操作仍按服务器时刻拒绝过期行为后台任务负责补全持久化事实不是权限正确性的唯一依赖。已披露的微信号不能被页面撤回关闭或取消会让候选失效但双方在此前已经合法看到微信号。软件无法让对方忘记也不应该让页面假装历史交换从未发生。实现中把候选查询拆成两类有效候选允许新的联系方式交换 参与者历史候选允许双方查看已经发生的交换结果浏览器旅程中车主在“我的信息”关闭发布后乘客刷新交换结果仍能看到此前的加密快照。新的候选和交换则已经停止。一次测试失败纠正了错误前提浏览器测试最初期待双方确认后信息显示“座位已满”。失败页面清楚显示车主发布了两个座位只确认了一名乘客正确状态本来就应是“正在寻找”。测试随后修正前提而不是把实现改成确认一人就满员。这类失败很有价值TDD 不代表测试永远正确失败时仍要回到产品事实判断哪一边错了。本节点结果99 个非浏览器测试通过1 个 PostgreSQL 专属测试明确跳过分支覆盖率 88.55%静态、类型、迁移和 Django 检查通过4 条 Chromium 旅程通过编辑修订、状态来源、截止、过期、超时和历史披露都有自动证据外部提醒、PostgreSQL 并发、WebKit 和微信真机仍未宣称通过结果只形成本地提交不推送。下一篇进入 K7业务事件已经存在后怎样通过数据库待办可靠调用喵提醒区分明确失败和结果未知并避免短时间内连续轰炸用户。关键代码与操作下面的简化测试把生命周期扫描执行两次确认终态和业务事件都不会重复deftest_lifecycle_sweep_is_idempotent(expired_trip,pending_pairing):sweep_trip_lifecycle(nowNOW)sweep_trip_lifecycle(nowNOW)expired_trip.refresh_from_db()pending_pairing.refresh_from_db()assertexpired_trip.statusTripPost.Status.EXPIREDassertpending_pairing.statusPairing.Status.TIMED_OUTassertBusinessEvent.objects.filter(event_typetrip.matching_closed).count()1assertBusinessEvent.objects.filter(event_typepairing.timed_out).count()1验证命令make bugfix TESTtests/trips/test_lifecycle.py::test_sweep_is_idempotent_for_deadline_expiry_and_pairing_timeout后台任务可以晚到或重跑但同一个截止事实不能因此产生两次。本篇验证摘要联系方式交换前可以修订时间和路线交换后会锁定影响双方理解的字段关闭、取消和过期是终态继续寻找必须创建新信息实时查询按服务器时间排除失效信息不依赖后台扫描准时运行幂等扫描负责补齐截止、过期和确认超时事件不重复改变已完成状态信息结束后禁止新的交换但参与者仍能查看此前合法披露的联系方式。附录相关工具与仓库gstack仓库garrytan/gstack地址https://github.com/garrytan/gstackdev-harness仓库Dev-Wiki/dev-harness地址https://github.com/Dev-Wiki/dev-harnessUI UX Pro Max Skill仓库nextlevelbuilder/ui-ux-pro-max-skill地址https://github.com/nextlevelbuilder/ui-ux-pro-max-skill