# v6.3.15 AI评论/@识别彻底修复

## 最新现场问题
界面持续显示：
- 全账号互动 0
- 匹配规则 0
- 新互动 0
- 通知接口节流中

OIDB 153 已解决，但真实新评论/@仍未进入本地互动列表。

## 根因一：旧解析器错误依赖 notice_id
不同 tencent-channel-cli / OIDB 返回结构中，互动列表元素不一定带：
- notice_id
- msg_id

上一版 `_notice_record_candidates` 要求存在唯一 notice_id，导致某些真实：
- feed_id
- comment_id
- reply_id
记录直接被过滤，最终 items=0。

本版不再要求 notice_id：
1. 优先把响应数组里的每个 dict 元素当作独立记录边界；
2. 有 feed/comment/reply 任一链式ID即可进入解析；
3. 没有 notice_id 时用“当前独立记录的 feed/comment/reply/作者/正文/时间”生成稳定 synthetic ID；
4. synthetic ID 可跨重复第一页保持稳定，仍能正常去重；
5. 页包装对象不会成为记录，继续防止“所有回复落到同一个帖子”。

## 根因二：桌面轮询一直使用 feed get-notices
腾讯官方当前文档提供：
`manage check-notices`
用于“手动增量拉取新通知（与本地水位线对比）”。

因此本版改为：
1. check-notices 可用 → 优先增量检查；
2. 如果返回互动记录 → 直接解析；
3. 如果增量数据写入本地 recent-notices → 自动继续读取 get-recent-notices；
4. 当前环境明确 unsupported/not_subscribed/OpenClaw-only → 自动禁用该路径，回退 feed get-notices；
5. 不会尝试在非OpenClaw环境擅自开启推送订阅。

## 手工“立即轮询一次”
旧版点按钮如果正处于15秒节流窗口：
直接读本地空缓存并显示0。

本版：
- 普通短节流 ≤20秒：后台等待到可请求时间；
- 优先检查 type=4 收到评论；
- 再等待账号级节流后检查 type=6 被@；
- 如果遇到真正的 retCode=153 长冷却，仍尊重70秒以上退避，不强行绕过。

因此用户手工测试评论/@时，按钮会执行真实检测，而不是只显示缓存。

## 解析诊断
feed get-notices 返回后统计：
- 腾讯返回候选 N 条
- 识别 M 条
- 新互动 K 条

如果“候选>0但识别=0”，会写：
data/ai_notice_detection.log

日志只保存结构字段名和数量，不记录Token/DeepSeek API Key。

## OIDB限流继续保留
- 同QQ共享通知缓存；
- 后台每次最多一个真实请求；
- 正常请求最小间隔15秒；
- retCode=153 按腾讯官方建议采用至少70秒退避，并继续指数延长，上限600秒。

## 原帖绑定与回复
之前已经修复的逐通知原帖绑定、comment_id精确回复、原帖安全兜底继续保留。

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