# v6.3.15 AI 评论/@识别修复（保留 OIDB 限流保护）

## 现场表现
上一版不再出现 retCode=153，但新评论/@显示：
- 全账号互动 0 条
- 匹配规则 0 条
- 新互动 0
- 通知接口节流中

## 根因
为了防止升级后批量回复历史通知，上一版把 type 4/5/6 每种通知第一次读取的整页都标记为 baseline_only。

如果用户升级后立刻测试：
- 新评论刚好发生在 type 4 第一次读取之前；
- 或新@刚好发生在 type 6 第一次读取之前；

这条真正的新互动也会被误当成“历史基线”，因此永远不会进入AI规则。

同时旧实现还有一个隐患：
历史 baseline 通知在第二次出现在第一页时会被改成 live，存在以后误回复旧消息的风险。

## 修复

### 1. baseline 改为逐通知判断
首次读取某种通知时，不再整页判定历史。

每条通知独立判断：
- 已存在于该QQ任意 AI 规则历史记录 → 历史；
- 互动时间明确晚于本轮通知状态创建时间 → 新互动；
- 互动时间明确更早 → 历史；
- 无可靠时间戳且属于已有升级安装：未见过的稳定消息ID按新互动处理；
- 真正全新安装、没有任何历史去重数据且时间未知：保持保守基线。

### 2. 新评论发生在旧帖子时不误判
严禁使用整个通知树里任意 `create_time_raw` 判断消息新旧，
因为它可能是原帖创建时间。

例如：
- 原帖发布于1个月前；
- 今天别人新评论；

今天的评论必须算新互动，不能因为 feed_create_time 很旧就被当历史。

现在只使用：
- notice 自身时间；
- comment 自身 create_time_raw；
- reply 自身 create_time_raw；
- 明确的 notice/message 时间字段。

### 3. baseline 状态不可逆
一条通知一旦作为历史 baseline 写入共享缓存，以后重复出现在第一页时仍保持 baseline。
不会在第二次读取时突然变成新通知。

### 4. 评论和@优先
轮转顺序从：
4 → 5 → 6

调整为：
4（收到评论） → 6（被@） → 5（收到回复）

仍保持同一QQ账号级最小真实 OIDB 请求间隔15秒，
因此评论和@优先被识别，同时继续避免 retCode=153。

### 5. 新规则安全基线
AI规则首次建立基线期间：
- 只把明确发生在规则创建之前的通知记为 baseline；
- 规则创建之后发生的新互动不会被吃掉；
- 等4/6/5三类通知安全基线完成后，下一轮继续处理这些待回复新互动。

### 6. 升级迁移
本修复首次启动：
- 清空上一版临时 ai_notice_cache / ai_notice_poll_state；
- 重新用新的逐通知逻辑建立通知缓存；
- 已成功 replied / replied_fallback 的持久去重记录不删除；
- status=failed 的记录重新获得重试机会。

## OIDB限流继续保留
- 同一QQ每次最多1次真实 get-notices 请求；
- 多AI规则共享网络读取；
- 15秒账号级节流；
- retCode=153 自动 60→120→240→480→600秒退避。

## 热更新
- VERSION继续 v6.3.15。
- app/updater.py / make_update_package.py / bootstrap.py /
  licensing / license_public_key / 构建脚本保持指定 v6.3.12 原文件字节级不变。
