# v6.3.15 AI通知原生楼层回复彻底修复

## 为什么之前反复出现“评论列表为空”
程序已经从 get-notices 的独立通知记录中拿到了：
- feed_id
- comment_id
- reply_id（收到回复时）
- replier_id / target字段（部分CLI返回）
- 通知正文

但旧发送流程仍强制：
get-notices通知ID
→ get-feed-comments重新查楼层
→ 查不到就清空comment_id
→ 拒绝发送

这使 get-feed-comments 成为了“单点故障”。

官方规则实际上只要求：
- do-reply 用于回复已有评论/回复；
- do-reply 必须有 comment_id；
- get-feed-comments 是浏览帖子评论的读取命令，不是 do-reply 的强制前置步骤。

## 新发送顺序

### A. 通知自身有 #ref
直接：
feed do-reply --ref <通知ref>

### B. 通知原生楼层链（主路径）
不调用 get-feed-comments。

从当前这一条已经隔离好的 get-notices 记录中使用：
- feed_id
- feed_create_time
- comment_id

收到楼中楼回复时再使用：
- reply_id → target_reply_id
- reply作者/replier_id → target_user_id

随后直接：
feed do-reply

### C. 评论列表（最后兜底）
只有：
- 通知根本没有 comment_id；
- 或腾讯明确拒绝通知原生 do-reply；

才调用 get-feed-comments / get-next-page-replies 做旧的多源楼层定位。

因此当前CLI即使 get-feed-comments 永久不兼容，
只要 get-notices 正常返回 comment_id，自动回复仍然可以工作。

## type4 收到评论
只要通知有 comment_id：
直接回复该 comment_id。

不要求：
- 重新把它从评论列表搜索一遍；
- comment_author_id必须存在；
- comment_create_time必须存在。

运行时schema会自动过滤当前CLI不接受的可选字段。

## type5 收到回复
使用：
- 根 comment_id
- incoming reply_id 作为 target_reply_id
- incoming replier_id / reply author id 作为 target_user_id

若当前CLI schema明确要求 target_user_id 但通知没有提供，
才转评论列表兜底，不猜用户ID。

## type6 被@
如果通知自身包含comment_id/reply_id，视为评论楼层中的@，可do-reply。
直接@帖子没有comment_id时不自动发一级评论。

## 安全
AI发送器仍然没有 do-comment。
所有路径都是 do-reply。
任何失败都不会重新新增一级评论。

## 失败诊断
如果通知原生do-reply被腾讯拒绝，会记录：
- 原生链是否完整
- do-reply错误
- 实际提交字段
- 评论列表兜底错误

下一次现场错误将直接是“腾讯为什么拒绝do-reply”，
而不是继续被 get-feed-comments 空列表挡住。

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