读了 README 与 skill/SKILL.md 后发现一个与数据新旧无关的规则缺口：活动没有“过期”这个状态，匹配和搜索只看 status=open，不看日期时间。

现状（依据文档）

1. SKILL 第二步四级匹配只比“同一天 / 前后 1 天”，没有“日期不得早于今天”这一条；第三步以后的展示、第四步“当天其他活动”同样只按日期相等筛选。
2. “按标签搜索活动”一节只写了“按标签搜索所有 status=open 的活动”，没有排除已过期的活动；“查看某天活动”也没有对过去日期做提示或拦截。
3. 重要约束里有数据一致性、ID 唯一性、禁止编造，唯独没有活动生命周期的约束：open 的活动在日期过去后不会自动变成 finished / cancelled / expired，README 2.1 的 11 条测试数据也一直是这个状态。
4. 第五步提醒按“活动开始前 1 小时”建 cron；如果活动时间已过，建提醒 cron 本身就没有意义，文档也没有“开始时间已过则不建提醒”的分支。

会出什么问题

举例：今天再问“明天想去紫金山”，只要 activities.json 里还留着 7 月的旧活动，四级匹配的规则本身并不会因为“那是三个月前”而跳过它——是否被推荐只取决于日期算式和地点/标签，旧数据一旦日期恰好对上（或被当作“某天”查出来）就可能被当成可加入的活动。即使数据换成新的，只要不及时清理，同样的问题会在活动结束当天之后重现。#18 提的是测试数据日期陈旧，本条提的是规则缺失：哪怕数据是新的，过期后也没有状态流转兜底。

建议（供维护者取舍，不改现有字段含义）

1. 匹配、标签搜索、“查看某天活动”统一加一条前置过滤：只返回 date + time 不早于当前时间（Asia/Shanghai）的活动；查过去日期时明确告诉用户“那天已过去”，而不是直接列出旧活动。
2. 读到 activities.json 时，把“结束时间已过且仍为 open”的活动归档或标记为 expired（保留原数据，只改状态），不再参与匹配；“我的活动”里把已过期活动单独列在“已结束”分组。
3. 创建提醒 cron 前先判断：活动开始时间减 1 小时已过，则不建 cron，并在活动摘要里说明提醒已跳过的原因；已建的提醒在活动过期后不再触发。
4. 若担心直接改状态影响历史统计，可先只做第 1 条过滤、状态流转放到第二步，过滤规则写进 SKILL 第二步与“按标签搜索活动”两处，避免只改一处漏一处。

以上均未改动现有活动字段，只是补上“过期活动不再可匹配”这一条规则。如维护者已有另外的清理机制（例如定期删旧数据），也请在 README 里写明，本条可关闭。