# v6.3.15 新互动识别彻底修复 + 强制楼层回复

## 现场证据
界面已经显示：
- 通知类型4：腾讯返回候选20条，识别15条，新互动0条
- 通知类型6：腾讯返回候选20条，识别15条，新互动0条

说明腾讯数据读取和解析都正常。
问题发生在“识别以后”的本地去重/基线层。

## 根因1：notice_id 被当成唯一消息ID
部分腾讯 OIDB / CLI 返回结构中的 notice_id/msg_id 更像通知容器ID，
可能在后续刷新中复用。

旧版：
message_id = type + notice_id

结果：
新评论虽然正文/comment内容变了，
本地仍然查到同一个 source_message_id，
于是统计为 existing，不进入新互动。

## 新ID
现在每条互动使用：
- notice type
- feed_id
- comment_id
- reply_id
- 作者ID/昵称
- 互动正文
- 明确的通知/评论/回复发生时间
- notice_id仅作为补充字段

共同生成SHA-256强互动ID。

notice_id不再能够单独决定去重。

## 根因2：升级后的首次type 4/type 6被基线吞掉
旧版清空临时poll_state后，
type 4 / type 6 又会进入 first_fetch_for_type。

本版对“已经initialized的AI规则”使用 last_poll_at 作为水位线：
- event_time <= last_poll_at：旧互动
- event_time > last_poll_at：新互动
- 没有可靠event_time但强互动ID从未出现：按新互动处理

因此升级后刚产生的评论/@不会再被整页baseline。

## 根因3：历史弱ID缓存污染
本版首次启动清空：
- ai_notice_cache
- ai_notice_poll_state

这两个只是临时通知缓存/轮询状态。

不清空：
- ai_reply_rules initialized
- replied / replied_fallback 成功记录
- 历史持久去重数据

所以不会把已经成功回复的记录当成全新安装。

## 兼容旧成功记录
因为强互动ID与旧ID不同，
本版还会用“作者+正文+成功状态”匹配旧历史，
避免迁移后重新回复已经处理过的可见旧消息。

## 极端ID碰撞
如果同一个强ID下腾讯返回payload发生实质变化，
程序会创建：
source_id:rev:<payload hash>

而不是继续静默当成existing。

轮询状态会显示：
- 新互动
- 已见
- 历史基线
- ID碰撞修复

方便现场直接判断是哪一层过滤。

## 楼层回复
上一版“AI楼层回复强制校验”完整保留：
- AI自动发送器不调用do-comment
- 先正文+作者校验具体楼层
- 再使用精确ref/do-reply
- 找不到楼层宁可不发送，也不新增一级评论

## 热更新
VERSION继续v6.3.15。
v6.3.12热更新核心文件保持字节级不变。
