6 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	1d3965aa80	fix(gateway): Web 活跃客户端主动推送走 turnreply 规整（先规整再落库，推帧与落库逐字相同） ... M19 复审抓到的真缺口：internal/services/gateway/proactive.go 的 SendProactive -> persistProactiveToMain 这条 Web 活跃客户端主动推送路由 完全绕过 turnreply.NormalizeParagraphs —— 同一条主动消息走 IM 是规整过的、 走 Web 实时推还是原样（半包 <p> 在客户端按「存在完整 <p> 就不再按空行回退」 的契约下整条塌成一坨）。 - 接线：SendProactive 在落库之前先 msg.Content = turnreply.NormalizeParagraphs(msg.Content)， 落库与 proactive_message 帧取同一个字符串 ⇒ 两端逐字相同；不在 gateway 另写实现。 - 新增 proactive_normalize_test.go：修前红（web 原样 / im 已规整），修后断言 ① 落库是规整后文本 ② 推帧 == 落库行 ③ 两条路由同源同文本 ④ <br>/<action> 语义不动。 - 既有两条断言按新口径更新（纯散文现在也被包成一个 <p>，与其它三处一致）。	2026-10-24 19:40:30 +08:00
AskaEth	b36798265a	docs(comments): proactive 判据键在 data 内、不在帧壳顶层（安卓核对指出） ... 4 处注释写「帧顶」而代码放在 data[proactive]（+ 测试文件 6 处同源表述）。 安卓端两层都读所以不受影响，但注释与代码相反会误导下一个按注释写的人。 零行为改动（仅注释）。	2026-10-06 21:16:20 +08:00
AskaEth	f4adf0b526	feat(notify): IM 路由的主动消息也在非前台补浏览器通知（契约 v0.74） ... 主人裁定 C 的必然推论：她该不该提醒我，与后端走了哪条路由无关。P0 如实报回的缺口 = 通知只挂在 proactive_message 帧上，而 auto 提示在有已连接 IM 渠道时优先走 IM ⇒ 最常发生的路径恰恰不弹。 判据（先查现状、不猜）：行字段**区分不出**主动推送与普通回复（已用真库证据排除 platform/adapterId/turnId 反推）⇒ 新增**结构化的正向声明**：帧顶 data.proactive === true，只由主动推送那条通道打（gateway.BroadcastProactivePersisted）；普通路径永远传 false。 - 后端：channelbridge 抽出唯一写入口径 persistMain + 新增 proactive_notify 接缝；gateway 抽出 broadcastPersisted(msg, proactive) 两入口共用 - 前端：handlers/proactive-notice.ts 两条帧路共用同一套提醒运行时（有界去重 + 降级说明 + DOM/Notification 取值）；message.ts 读到判据才走提醒 - 对照断言（必须有）：普通 IM 回复/主人提问/显式 proactive:false ⇒ **0 通知、3 气泡**（不误伤） - 变异实测：去掉非主动保护 / 跨两路去重失效 / 前台也弹 / IM 不发判据帧 / 普通广播带判据 ⇒ 5 条全部打红 - 契约 v0.74（纯增量：message_persisted 新增可选 proactive:true） - 边界（如实）：判据**不落库**（翻历史不弹提醒，也不得从行字段反推）；落库失败时不发判据帧（无权威 id 的帧前端整帧丢弃）	2026-10-05 19:47:54 +08:00
AskaEth	84c124f5a9	fix(backthink): 她主动找你终于看得见 —— 主动消息落主会话 + 前端消费 + 非前台浏览器通知 ... 修主人报的硬故障「后台思考的主动推送一个都没有推出来」（根因两条，缺一不可）： - 后端 gateway/proactive.go 只广播 proactive_message 帧、**从不写会话历史** ⇒ 刷新补不回来 - 前端**零消费点** ⇒ 帧被静默丢弃（既无气泡也无通知） 后端：新增 proactive_persist.go（**先落库、再发帧**；web/assistant/mode=chat；未接线时空操作且不谎称已落库） 载荷新增 id/createdAt（落库行权威 id）；PushResult.Detail 三态如实分开报告「投递到几个连接」与「是否落库」 前端：handlers/proactive.ts（气泡**恒落** + 按落库 id 去重 + **非前台才补通知** + 拒绝授权/畸形载荷可见降级） + lib/notify/proactive.ts（纯逻辑 isBackground/decideProactiveNotice/有界去重表） + handlers/task.ts（另三个被丢的帧 task_done/automation_result/subagent_result） + ws/resync.ts + useWsResync.ts（**重连重跑本页引导读取**，首次连接不跑） 双份核查（带三层证据）：现状不双份 —— 路由分叉「一次 Push 至多一个 sink 成功」，且 IM 路由本来就把主动消息镜像回主会话恰好一次 契约 v0.72；变异实测：只发帧不落库 / 写成 user 角色 / 去重失效 / 前台也弹 / IM 成功再打活跃 ⇒ 全部打红	2026-10-05 16:02:36 +08:00
AskaEth	074ffc4ebf	docs(gateway): gateway 剩余文件注释改中文（逐行 1:1，代码零字节改动） ... 主人 2026-10-03 拍板「注释一律中文」；gateway 至此整包注释中文化完成（本会话共 3 批： 已推库 16 个文件 + 本批剩余文件）。 校验：机械校验（非注释改动行）= 空；剥注释后代码文本逐行比对全等（不一致文件数 0）； 全树 go test ./... 58 包 ok / 0 FAIL；交叉编译绿。	2026-10-03 22:28:25 +08:00
Aska	6a2b8b9f12	feat(backthink): 主动推送 sink 打通——hub.SendProactive + bridge.SendProactive + wire 接线 ... backthink 决策+路由(P2)就绪但无投递 sink(ActiveClient/IMAdapter 无实现)。补齐: - gateway/proactive.go: hub.SendProactive 向 owner/admin 连接广播 proactive_message WS事件, 内容脱敏(去RawData/media/token),返回接收数,count=0→IM兜底;Server.SendProactive 委托 - channelbridge/proactive.go: Bridge.SendProactive 解析 owner 账户(msg.Platform→匹配白名单账号, 否则首个已配置主人频道),ChannelType=Direct+ChannelID/SenderID=owner id,走 adapter.SendProactive - backthink/sinks.go: SetActiveSink/SetIMSink 晚注入(New后重建pusher,currentPusher 并发安全) - wire.go: 在 gw/bridge 建好后 bt.SetActiveSink(gw)/SetIMSink(bridge) - 投递链: think→parseProactive→ShouldPush→currentPusher.Push→gate→active(active_client)/IM(im_bridge) →record(route+送达数) - 测试: sinks/gateway proactive/channelbridge proactive; 后端 build/vet/test 全绿 - 注: -race 本机 TSan 不可用(环境); 多平台IM按msg.Platform匹配 owner 账号(单sink诚实); weixin 24h窗口按 ErrProactiveWindow 记录为 im_bridge 错误不静默	2026-09-07 19:43:48 +08:00