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 的帧前端整帧丢弃）

internal/services/channelbridge/channelbridge.go

@@ -183,8 +183,13 @@ type Bridge struct {
 	owner       *user.OwnerProfile
 	history     history.HistoryStore
 	onPersisted func(history.Message)
-	onRejected  func(adapter.UnifiedMessage, string)
-	review      adapter.Reviewer
+	// onProactivePersisted 是**主动推送**那条实时通知接缝（切片 P0b）：一条主动消息刚
+	// 落进主会话时被调用，使客户端能凭结构化判据（帧顶 `proactive:true`）走与
+	// proactive_message **同一套**提醒逻辑 —— 「她该不该提醒我」因此与后端走哪条路由
+	// 无关。普通消息的通知仍走 onPersisted，两条互不串味（见 proactive_notify.go）。
+	onProactivePersisted func(history.Message)
+	onRejected           func(adapter.UnifiedMessage, string)
+	review               adapter.Reviewer
 
 	light          LightJudge
 	quietStartHour int

internal/services/channelbridge/persist.go

@@ -76,18 +76,35 @@ func (b *Bridge) notifyPersisted(msg history.Message) {
 // 使调用方能在回合结束后按 id 把文档抽取结论补进同一列
 // （inbound_documents_persist.go 的两段式）。未装配历史存储时为空操作，
 // 因此桥接器在没有存储的情况下行为不变。
+//
+// 写入本身走 persistMain（与主动推送同一个写入口径），通知走普通通道 notifyPersisted。
+// **主动推送不经过本函数**：它直接调 persistMain，并额外走 notifyProactive 追加一条带
+// 结构化判据的帧（切片 P0b）—— 因此带判据的帧只可能来自主动推送，**普通消息的帧永远
+// 不带它**。
 func (b *Bridge) persistToMain(ctx context.Context, role, content, mood, document, image, platform, deviceID, adapterID, turnID string) history.Message {
+	return b.persistMain(ctx, history.Message{
+		SessionID: history.MainSessionID, Role: role, Content: content, Mood: mood, Document: document, Image: image, Platform: platform, DeviceID: deviceID, AdapterID: adapterID, Mode: modeChat, TurnID: turnID,
+	}, b.notifyPersisted)
+}
+
+// persistMain 是「写进主会话」的**唯一**写入口径：persistToMain（普通消息）与
+// 主动推送（proactive.go）共用它，因此两条路的存储语义逐字一致 —— 未接线历史存储
+// 时空操作并返回零值、写库失败 WARN 并返回零值（绝不谎称已落库）、成功则返回刚落库的
+// 完整消息。**差别只在 notify**：那是「这条要不要通知实时通道」的接缝，由调用方给出
+// —— 普通消息传 notifyPersisted（`message_persisted` / `channel_persisted`），主动推送
+// 传 notifyProactive（带结构化判据的同一类帧，切片 P0b）。nil 表示本次写入不通知。
+func (b *Bridge) persistMain(ctx context.Context, msg history.Message, notify func(history.Message)) history.Message {
 	if b.history == nil {
 		return history.Message{}
 	}
-	full, err := b.history.AppendFull(ctx, history.Message{
-		SessionID: history.MainSessionID, Role: role, Content: content, Mood: mood, Document: document, Image: image, Platform: platform, DeviceID: deviceID, AdapterID: adapterID, Mode: modeChat, TurnID: turnID,
-	})
+	full, err := b.history.AppendFull(ctx, msg)
 	if err != nil {
-		b.log.Warn("persist main session", "err", err, "role", role, "platform", platform, "device_id", deviceID, "adapter", adapterID)
+		b.log.Warn("persist main session", "err", err, "role", msg.Role, "platform", msg.Platform, "device_id", msg.DeviceID, "adapter", msg.AdapterID)
 		return history.Message{}
 	}
-	b.notifyPersisted(full)
+	if notify != nil {
+		notify(full)
+	}
 	return full
 }
 

internal/services/channelbridge/proactive.go

@@ -40,6 +40,12 @@ const proactiveRecentCount = 20
 // 当主人档案没有白名单账号、或该账号没有已连接的
 // 适配器支撑时，它返回明确错误，便于调用方记录原因，
 // 而不是静默丢弃推送。
+//
+// 成功投递之后它**同时**做两件事：把这条主动消息镜像回主会话（恰好一次；气泡恒落的
+// 根），并让实时通道能凭**结构化判据**认出「这条是她主动说的话」—— 后者是切片 P0b：
+// `auto` 提示在主人有已连接 IM 渠道时优先走 IM，因此**实际最可能发生的路径**恰恰是这
+// 一条；它过去只发普通 `message_persisted`，于是挂在 `proactive_message` 上的浏览器
+// 通知永不触发（主人裁定：该不该提醒与走哪条路由无关）。
 func (b *Bridge) SendProactive(ctx context.Context, msg adapter.UnifiedMessage) error {
 	if err := ctx.Err(); err != nil {
 		return err
@@ -77,16 +83,39 @@ func (b *Bridge) SendProactive(ctx context.Context, msg adapter.UnifiedMessage)
 	// 把主动消息镜像进主对话上下文（design/16
 	// §4.4 + §4.6.1）。否则模型看不到自己主动说了什么，
 	// 主人后续回复就会显得不连贯（该消息「丢失」了历史）。
-	// 它与主人私聊 IM 回复走同一条镜像路径，作用域为 MainSessionID，
-	// 落库的同样是规整后的那一份（Web 与 IM 看到的必须是同一份）。
-	// turn_id 传 ""：主动推送是**她单方面开口**，没有对应的入站回合，也就没有
+	// 它用的是普通回复那条写入口径（persistMain，相同的列、相同的时间戳语义），
+	// 作用域恒为 MainSessionID，落库的同样是**规整后**的那一份（Web 与 IM 看到的必须是
+	// 同一份），因此落库行为与本切片之前逐字相同；变的只有通知的第二步（见下）。
+	// turn_id 传 ""（零值）：主动推送是**她单方面开口**，没有对应的入站回合，也就没有
 	// 「它属于哪一路回合」可归属 —— 空值诚实地表示这一点（见 turnid.go 的口径）。
-	b.persistToMain(ctx, history.RoleAssistant, out.Content, "", "", "", target.platform,
-		fmt.Sprintf("%s:%s:%s", target.platform, target.accountID, target.accountID),
-		target.platform, "")
+	//
+	// 通知分两步，两条都是**结构化**的通道（绝不是「像不像主动消息」的猜测）：
+	//   ① notifyPersisted 照旧 —— 这就是 P0 起的行为，任何客户端都能渲染这条镜像消息，
+	//      逐字不变（`message_persisted`）；
+	//   ② 再走 notifyProactive —— 追加一条帧顶带 `proactive:true` 的同类帧，客户端据此在
+	//      **非前台**补一发浏览器通知（切片 P0b）。两帧说的是同一条消息（同一个落库行
+	//      id），前端按 id 去重 ⇒ 仍是一个气泡、仍只提醒一次。
+	//
+	// ② 只在**确实落了库**时发：`message_persisted` 的载荷要求权威 id，客户端拿不到 id
+	// 会整帧丢弃 —— 发一条没有 id 的帧等于假装提醒过。落库失败本身已由 persistMain
+	// 记 WARN（可见，不静默）。
+	row := history.Message{
+		SessionID: history.MainSessionID, Role: history.RoleAssistant, Content: out.Content,
+		Platform: target.platform, DeviceID: proactiveDeviceID(target), AdapterID: target.platform, Mode: modeChat,
+	}
+	if full := b.persistMain(ctx, row, b.notifyPersisted); full.ID != "" {
+		b.notifyProactive(full)
+	}
 	return nil
 }
 
+// proactiveDeviceID 是主动推送落进主会话时写入 device_id 的标签：`<平台>:<账号>:<账号>`。
+// 它不是某台设备，而是「这条推送走的是哪个主人渠道账号」——与 sendIMBubbles 出口选中的
+// 那个账号逐字对应，因此在管理日志里能一眼看出这条主动消息投到了哪里。
+func proactiveDeviceID(target proactiveTarget) string {
+	return fmt.Sprintf("%s:%s:%s", target.platform, target.accountID, target.accountID)
+}
+
 // proactiveTarget 解析主动推送应当到达的唯一主人账号。
 // 候选范围是每个有已连接适配器支撑的白名单主人渠道
 // （含 WeChat），选择遵循 backthink 的优先级：

internal/services/channelbridge/proactive_notify.go

@@ -0,0 +1,40 @@
+package channelbridge
+
+import (
+	"git.yeij.top/AskaEth/Cyrene_v2/internal/runtime/history"
+)
+
+// 本文件承载 IM 主动推送那条**实时通知**接缝（切片 P0b「IM 路由的主动消息也要在非前台
+// 补通知」）。它与 persist.go 的 notifyPersisted 并列：普通消息走那一条，主动推送走这
+// 一条。两条都写主会话，因此「写」是同一份代码（persistMain），差别只在通知。
+//
+// 为什么必须分开而不是去猜：主人裁定「她说话该不该提醒我，与走哪条路由无关」，因此
+// 主动推送必须自己声明「我是主动推送」。判据是**结构化**的（本次写入走的是哪条通知
+// 通道），**绝不**读正文关键词、**绝不**让提示词/模型判断 —— 后者是项目红线
+// （AGENTS §9：身份与判定靠元数据，不靠提示词）。
+//
+// 为什么不在落库行上找判据：主会话的 `platform`/`adapter_id` 区分不出主动推送与普通
+// 回复 —— 主动推送写的是**解析后的真实平台**（proactive.go 的 target.platform，例如
+// "weixin-ilink"），与普通回复行同一形状（普通回复在按平台名注册的适配器上
+// adapter_id 也等于平台名）。因此结构化判据放在**落库那一刻的通知通道**上，随帧顶的
+// `proactive:true` 到达客户端（见 gateway 的 BroadcastProactivePersisted）。
+
+// SetOnProactivePersisted 装配（或替换）「一条主动消息刚落进主会话」之后所调用的通知
+// 钩子。组合根把它接进 gateway 的 BroadcastProactivePersisted（帧顶带结构化判据的
+// `message_persisted`）。它可以安全空调用，也可与在途推送安全并发。
+func (b *Bridge) SetOnProactivePersisted(fn func(history.Message)) {
+	b.mu.Lock()
+	defer b.mu.Unlock()
+	b.onProactivePersisted = fn
+}
+
+// notifyProactive 在装配了主动通知钩子时把刚落库的主动消息交给它；未装配时是空操作
+// （行为与本切片之前逐字相同：主动消息照旧落库、只是没有「主动」这条通知通道）。
+func (b *Bridge) notifyProactive(msg history.Message) {
+	b.mu.RLock()
+	fn := b.onProactivePersisted
+	b.mu.RUnlock()
+	if fn != nil {
+		fn(msg)
+	}
+}

internal/services/gateway/broadcast.go

@@ -20,14 +20,30 @@ import (
 // 会话。Thinking 会被抹除，以与 WS 历史回放保持一致（design/16 §6）。
 // 当 hub 接好广播时它是安全空操作。两种帧类型都携带消息内容，
 // 因此 design/11 §7.1 帧门只把它们投递给 owner/admin 连接。
+//
+// 它**绝不**带 `proactive` 键：普通消息的帧顶永远没有那个结构化判据，客户端因此
+// 不可能把普通消息误判成主动消息去弹通知（切片 P0b 的「不误伤」那一条）。主动推送
+// 那条路走 BroadcastProactivePersisted（proactive.go）。
 func (s *Server) BroadcastPersisted(msg history.Message) {
+	s.broadcastPersisted(msg, false)
+}
+
+// broadcastPersisted 是上面两个入口共用的帧构造与扇出：proactive 决定帧顶是否带上
+// 「这是她主动说的话」的结构化判据 `proactive:true`（切片 P0b，见 proactive.go 的
+// BroadcastProactivePersisted）。两条入口走**同一个**函数，因此帧类型推导、thinking
+// 抹除与角色门（design/11 §7.1）逐字一致 —— 差别只有那一个键。
+func (s *Server) broadcastPersisted(msg history.Message, proactive bool) {
 	wire := toHistoryMessage(msg)
 	wire.Thinking = ""
 	typ := "channel_persisted"
 	if msg.SessionID == history.MainSessionID || strings.HasPrefix(msg.SessionID, history.MainSessionID+":") {
 		typ = "message_persisted"
 	}
-	s.hub.broadcast(wsEvent{Type: typ, SessionID: msg.SessionID, Data: map[string]any{"message": wire}})
+	data := map[string]any{"message": wire}
+	if proactive {
+		data["proactive"] = true
+	}
+	s.hub.broadcast(wsEvent{Type: typ, SessionID: msg.SessionID, Data: data})
 }
 
 // wsCapacityAwaken 是能力状态迁移的 WS 事件类型（design/14 §5）。

internal/services/gateway/proactive.go

@@ -92,6 +92,24 @@ func (s *Server) SendProactive(ctx context.Context, msg adapter.UnifiedMessage)
 	return s.hub.SendProactive(ctx, msg)
 }
 
+// BroadcastProactivePersisted 把一条**刚落进主会话的主动消息**广播为**带结构化判据**的
+// `message_persisted` 帧（切片 P0b）。判据就是帧顶的 `proactive:true`：它是「她主动说的
+// 话」在线上唯一的标记，客户端据此走与 `proactive_message` **同一套**提醒逻辑（非前台才
+// 补一发通知，同一条只提醒一次），于是「她该不该提醒我」**与后端走了哪条路由无关**
+// （主人 2026-10-05 裁定 C）。
+//
+// 它由 IM 桥的主动推送在**落库之后**调用（组合根接线 SetOnProactivePersisted）。为什么
+// 需要它：IM 路由过去只发普通 `message_persisted`，而浏览器通知挂在 `proactive_message`
+// 上 ⇒ 走 IM 的主动消息一条都不弹；偏偏 `auto` 提示在主人有已连接 IM 渠道时优先走 IM
+// ⇒ 实际最可能发生的路径恰恰不弹。
+//
+// 判据为什么不会误伤普通消息：只有主动推送这条通道会调用本函数，普通消息（Web 回合 /
+// IM 回复 / IM 镜像）走的仍是 BroadcastPersisted，那条路径**永不**往帧顶放该键。
+// 帧类型仍是 `message_persisted`，因此角色门（design/11 §7.1）与普通持久化帧逐字相同。
+func (s *Server) BroadcastProactivePersisted(msg history.Message) {
+	s.broadcastPersisted(msg, true)
+}
+
 // proactivePayloadFrom 把 UnifiedMessage 投影为消毒后的线上载荷。
 // persisted 是刚落库的主会话消息（未接线历史存储或落库失败时为零值），
 // 它的 id/时间戳随之进入载荷，使客户端能把实时气泡对齐到历史行。

internal/services/gateway/proactive_im_notify_test.go

@@ -0,0 +1,146 @@
+package gateway
+
+import (
+	"context"
+	"testing"
+
+	"git.yeij.top/AskaEth/Cyrene_v2/internal/runtime/history"
+	"git.yeij.top/AskaEth/Cyrene_v2/internal/services/channelbridge"
+	"git.yeij.top/AskaEth/Cyrene_v2/internal/user"
+)
+
+// 本文件锁定切片 P0b：**IM 路由的主动消息也要在「非前台」补一发浏览器通知**。
+//
+// 背景（P0 如实报回的边界）：`auto` 提示在主人有已连接 IM 渠道时**优先走 IM**，而 IM
+// 路由过去只发普通 `message_persisted` —— 浏览器通知挂在 `proactive_message` 上，于是
+// **实际最可能发生的路径恰恰不弹**。主人裁定「她说话该不该提醒我，与走哪条路由无关」。
+//
+// 判据是**结构化**的：主动推送在落库之后追加一条**帧顶带 `proactive:true`** 的
+// `message_persisted`（gateway.BroadcastProactivePersisted）。普通消息（Web 回合 / IM
+// 回复 / IM 镜像）走的仍是 BroadcastPersisted，那条路**永不**放该键 —— 因此普通消息
+// 不可能被误判成主动消息。下面分别钉住两端：IM 路由真的发得出这条带判据的帧，而普通
+// 广播路径永远发不出它。
+
+// dataFlag 报告帧顶是否带 proactive 判据（以及它的值）。
+func dataFlag(t *testing.T, ev wsEvent) (any, bool) {
+	t.Helper()
+	data, ok := ev.Data.(map[string]any)
+	if !ok {
+		t.Fatalf("frame data type = %T, want map[string]any", ev.Data)
+	}
+	v, has := data["proactive"]
+	return v, has
+}
+
+// frameMessageID 取帧内消息 DTO 的 id。
+func frameMessageID(t *testing.T, ev wsEvent) string {
+	t.Helper()
+	data, ok := ev.Data.(map[string]any)
+	if !ok {
+		t.Fatalf("frame data type = %T, want map[string]any", ev.Data)
+	}
+	msg, ok := data["message"].(map[string]any)
+	if !ok {
+		t.Fatalf("frame message type = %T, want map[string]any", data["message"])
+	}
+	id, _ := msg["id"].(string)
+	return id
+}
+
+// TestChannelBridge_SendProactive_EmitsProactiveFlaggedFrame 是切片 P0b 的端到端证据：
+// IM 路由的主动消息**既**照旧广播普通镜像帧（P0 起的行为，任何客户端都能渲染），**又**
+// 追加一条帧顶带 `proactive:true`、并携带落库行权威 id 的帧 —— 前端据此走与
+// `proactive_message` 同一套提醒逻辑（非前台补一发通知，两帧同 id ⇒ 去重后一个气泡、
+// 一次提醒）。它同时守住 P0 的红线：主会话里仍**恰好一条**（绝无双份）。
+func TestChannelBridge_SendProactive_EmitsProactiveFlaggedFrame(t *testing.T) {
+	env := newEnv(t, nil, false)
+	store := newHistoryStoreForGateway(t)
+	env.srv.hub.history = store
+	owner := newOwnerConn(env.srv.hub, 8)
+	env.srv.hub.register(owner)
+	// claims 为 nil 的裸连接是 fail-closed 的，与普通持久化帧同一条角色门。
+	bare := newFakeConn(env.srv.hub, 8)
+	env.srv.hub.register(bare)
+
+	ownerProfile := &user.OwnerProfile{Accounts: []user.OwnerAccount{{Platform: "telegram", AccountID: "100"}}}
+	bridge, err := channelbridge.New(channelbridge.Options{
+		Log:         gwTestLogger(),
+		Loop:        stubBridgeChatter{},
+		Sessions:    stubBridgeSessions{},
+		Owner:       ownerProfile,
+		History:     store,
+		OnPersisted: env.srv.BroadcastPersisted,
+	})
+	if err != nil {
+		t.Fatalf("new bridge: %v", err)
+	}
+	bridge.SetOnProactivePersisted(env.srv.BroadcastProactivePersisted)
+	bridge.Add(&fakeIMAdapter{platform: "telegram"})
+
+	if err := bridge.SendProactive(context.Background(), proactiveStoreMsg("记得喝水哦")); err != nil {
+		t.Fatalf("SendProactive err = %v", err)
+	}
+	rows := mainSessionRows(t, store)
+	if len(rows) != 1 {
+		t.Fatalf("主会话里应恰好一条主动消息，得到 %d 条（>1 = 双份）", len(rows))
+	}
+
+	// 第一帧：普通镜像帧（P0 起的行为），**不带**判据。
+	first := readFakeFrame(t, owner)
+	if first.Type != "message_persisted" {
+		t.Fatalf("frame 1 type = %q, want message_persisted", first.Type)
+	}
+	if v, has := dataFlag(t, first); has {
+		t.Fatalf("普通镜像帧带上了 proactive=%v，want 该键缺席（判据只属于主动那条）", v)
+	}
+
+	// 第二帧：主动帧 —— 帧顶带判据，且消息 id 就是落库行的权威 id。
+	second := readFakeFrame(t, owner)
+	if second.Type != "message_persisted" {
+		t.Fatalf("frame 2 type = %q, want message_persisted（帧类型不变，只多一个结构化键）", second.Type)
+	}
+	if v, has := dataFlag(t, second); !has || v != true {
+		t.Fatalf("主动帧的 proactive 判据 = %v（present=%v），want true", v, has)
+	}
+	if got := frameMessageID(t, second); got != rows[0].ID {
+		t.Fatalf("主动帧的消息 id = %q, want 落库行的权威 id %q（前端去重与对齐都靠它）", got, rows[0].ID)
+	}
+	if err := connHasNoFrame(owner); err != nil {
+		t.Fatalf("owner 连接应恰好收到两帧（普通 + 主动），多出来的：%v", err)
+	}
+	if err := connHasNoFrame(bare); err != nil {
+		t.Fatalf("主动帧只投递给 owner/admin，裸连接不该收到：%v", err)
+	}
+}
+
+// TestServer_BroadcastPersisted_NeverCarriesProactiveFlag 是「不误伤」那一条的后端对照：
+// 普通广播路径（Web 回合 / IM 回复 / IM 镜像全走它）**永远**不在帧顶放 proactive 判据，
+// 因此客户端不可能把普通消息误判成主动消息去弹通知。同一行改走主动那条入口时，判据才
+// 出现 —— 两条入口的差别只有这一个键。
+func TestServer_BroadcastPersisted_NeverCarriesProactiveFlag(t *testing.T) {
+	env := newEnv(t, nil, false)
+	owner := newOwnerConn(env.srv.hub, 8)
+	env.srv.hub.register(owner)
+
+	row := history.Message{
+		ID: "row-plain", SessionID: history.MainSessionID, Role: history.RoleAssistant,
+		Content: "普通 IM 回复", Platform: "telegram", AdapterID: "telegram:100", TurnID: "turn-abc", CreatedAt: 1_760_000_000_000,
+	}
+	env.srv.BroadcastPersisted(row)
+	plain := readFakeFrame(t, owner)
+	if plain.Type != "message_persisted" {
+		t.Fatalf("frame type = %q, want message_persisted", plain.Type)
+	}
+	if v, has := dataFlag(t, plain); has {
+		t.Fatalf("普通消息的帧顶带上了 proactive=%v，want 该键缺席（否则会被误判成主动消息）", v)
+	}
+
+	env.srv.BroadcastProactivePersisted(row)
+	flagged := readFakeFrame(t, owner)
+	if v, has := dataFlag(t, flagged); !has || v != true {
+		t.Fatalf("主动入口的 proactive 判据 = %v（present=%v），want true", v, has)
+	}
+	if got := frameMessageID(t, flagged); got != "row-plain" {
+		t.Fatalf("主动帧的消息 id = %q, want row-plain", got)
+	}
+}