8 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	b955a27479	fix(channelbridge): M44 入站语音先写 voice 列再广播 ⇒ 首帧就带 voice ... 安卓 2026-10-26 回执关心的场景：新来一条语音消息时，**第一条**帧里有没有 `voice`。此前没有 —— `persistBatchUsers` 先 `persistToMain`/`persistIsolated` （内部同步 notify 把帧发出去），之后才 `persistMessageVoice` 写列，帧发出那 一刻列还是空串。网关侧的帧投影（上一 commit）读的就是这一列，因此首帧必然 缺 voice，客户端要等重连或下一次 REST 拉取。 修法（A 路的唯一可行形态，理由见下）： - `persistBatchUsers` 的通知改成 `persistVoiceFirstNotify(ref)`： **INSERT → 写 voice 列 → notify**。语句数不变，只把 notify 从 INSERT 内部 挪到最后；非语音消息（ref 零值）时该包装与 `notifyPersisted` 逐字等价。 - `persist.go` 抽出 `mainRow` / `isolatedRow`（字段清单只写一次）与 `persistIsolatedWith`（可注入通知的变体），`persistToMain`/ `persistIsolated` 的对外行为逐字不变。 为什么不走 B（给 `history.Message` 加 voice 随 INSERT 写）：`persistMessageVoice` 是按 id 的 UPDATE，行还不存在时必然 `ErrMessageNotFound` ⇒ 写列**不可能**真正 挪到 INSERT 之前；可行的最小形态就是上面那次换序，无需动 domain 类型、列清单 与 7 条读语句。B 若要做，属于 design/24 §10.5 的独立切片（那时还应删掉这里的 两段式，避免同一事实两处写）。 整链验收（`inbound_voice_gateway_e2e_test.go`，真桥接器 + 真存储 + 真网关 WS）： - 主人私聊语音：第一帧就是 `message_persisted`，带 `voice`，且与 `GET /sessions/{id}/messages` 同一行**逐字相等**；随后的非语音消息帧整键缺席。 - 群聊语音（被点名 ⇒ 走完整回合）：第一帧 `channel_persisted` 带 `voice`， 且与渠道日志读面同一行逐字相等。 - 变异实测（把顺序还原成「先广播、后写列」）：两条用例都 FAIL，输出即报障症状 （帧里 content 是转写文本，却没有 voice 键）。 顺带把网关侧两处描述旧时序的注释改成新事实。	2026-10-26 18:54:13 +08:00
AskaEth	5717735da9	feat(gateway): M44 实时帧与握手回放挂上 voice（纯增量） ... 修实根：`message_persisted` / `channel_persisted` 与握手 `history` 回放 此前只在 `toHistoryMessage` 之后直接扇出，于是消息 DTO 的语音面在这三条 面上恒缺席，客户端只能等下一次 REST 拉取才知道那是一条语音。 - `history_voice.go`：把语音补齐抽成存储无关的唯一收口点 `attachVoiceTo` （Server 与 hub 共用），并加 `voiceColumnsOf` 把任意历史视图窄化成读面， 未实现该视图时为真 nil 接口（字段缺席，不 panic、不 500）。 - `broadcast.go`：新增 `persistedWire` —— thinking 抹除 + 可选 voice， `broadcastPersisted` 改用它；两类帧因此天然同口径。 - `ws_history.go`：握手回放同样补一次批量读列（最多 50 个 id 一条 SQL）。 成本实测：一帧 = 1 次 `IN (?)` 批量读列（1 个 id）；回放一页 = 1 次 （去重后的全部 id）；存储未提供该视图时 0 次。`history.Message` 没有 voice 列字段（`messageColumns` 也不含），故无法「零查询直接填」——补它 要改 internal/runtime/history 与 INSERT 写路径，超出本切片范围。 纯增量：voice 是可选键，非语音消息整键缺席（不是 null、不是 {}）； 帧壳、帧类型、REST DTO 形状一律未动。 测试（广播_voice_test.go）：帧序列化输出上断言 ①②③④，并逐字比对 「帧/回放里的 voice」与「REST 读面同一行」；摘掉任一挂载即打红。	2026-10-26 18:46:06 +08:00
AskaEth	b36798265a	docs(comments): proactive 判据键在 data 内、不在帧壳顶层（安卓核对指出） ... 4 处注释写「帧顶」而代码放在 data[proactive]（+ 测试文件 6 处同源表述）。 安卓端两层都读所以不受影响，但注释与代码相反会误导下一个按注释写的人。 零行为改动（仅注释）。	2026-10-06 21:16:20 +08:00
AskaEth	fe4c702f87	feat(gateway): 未读面 unreadCount 进 message_persisted 帧（契约 v0.76 ②） ... - broadcastPersisted 是 Web 与 IM 两条路的**共用**函数 ⇒ 两处口径天然一致，不存在分叉 - 口径 = 绝对未读 + 主人单一已读游标（chat_sessions.read_at）⇒ 多端共享 - 可选键 omitempty：只在 >0 且确实算得出来时出现；0 与「算不出来」都不顶位 （0 只能从「会话有游标」推出，否则那个 0 就是编的）⇒ 缺席 = 老行为 - Docs/api-client.md：v0.76 ① 按实测改标「未实现且无实现路径」（见下），② 已实现， 并更正「GET /sessions 的 unreadCount 自 D4 起已在」、新增 §4.13 与 §7.4 第 23 条 ⚠️ ① toolCalls[] 本版未落地（取证结论，非推断）：chat_messages.turn_id（编排器随机路标识 turn-<16hex>）与 flow_graphs.turn_id（trace.FlowGraph.ID = <session>-<轮次序号>，进程内递增） 不同源，真实库中 66 条消息行 vs 21 条图行字面交集为空 ⇒ 无法 join；按时间窗硬凑属于猜，不做。 补齐路径：链路图带回合标识（新键 + 迁移 0023 起）+ 落盘列，之后 toolCalls[] 是一条批量 SQL。 我亲自复跑的变异：去掉帧里的 n > 0 守卫 ⇒ TestBroadcastPersistedUnreadCountAbsentWhenUnknown 与 TestBroadcastPersistedCarriesUnreadCount 双双 FAIL（断言「0 不该顶位」）⇒ 测试是真护栏。	2026-10-06 07:58:42 +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	fe1ff33115	docs(gateway): WS 帧门相关 11 个文件的注释改中文（只改注释，代码零字节改动） ... 主人 2026-10-03 拍板「注释一律中文」。本次先把本会话动过的文件就地翻； 不做全仓一次性翻译，存量按包分批排期（见 工作小结.md 待办）。 范围：ws_frame_scope.go / ws_frame_scope_test.go / broadcast.go / ws_hub_turn.go / ws_hub_message_event.go / session_read.go / server.go / ws_hub_stream_scope_test.go / history_write_broadcast_test.go / mood_test.go / extra_test.go 含中文的整行注释 18 → 382。 校验（判据 = "只改注释、零代码字节改动"）： - `git diff -U0 | 排除 +++/--- | 排除注释行/空行/行尾注释` → 为空 - 独立实现：两侧剥掉注释后逐行比对代码文本 → 11/11 文件全等，不一致数 0 - 行尾注释 7 行逐条列出，代码列与原文逐字节相同（gofmt 未要求重排） - gofmt -l 干净；全树 go build/vet 绿；go test ./... = 58 包 ok / 0 FAIL； linux/amd64 + darwin/arm64 交叉编译绿 语义未删减：部分折行英文长句合并为更少行，故整行注释数 438 → 399。	2026-10-03 22:07:56 +08:00
AskaEth	bc0047b449	feat(gateway,security): WS 下行帧角色门 — 内容帧仅 owner+admin，viewer 只收状态机信号 ... design/11 §7.1（主人 2026-10-03 拍板）。此前 hub.broadcast 是全连接广播，而任意角色 （含 viewer）都能连 /ws/chat ⇒ viewer 能收到角色回复正文（message.*）、推理内容 （thinking.*）、消息增量、graph_update、mood 等。这与 design/19 §1/§3「flow 可视化仅 owner/admin 可见」冲突，也与 GET /sessions/{id}/messages 的 owner/admin 档位不一致。 收口：唯一分类点 internal/services/gateway/ws_frame_scope.go 的 frameReachesAll(typ) （fail-closed switch，默认 false）；hub.broadcast 投递前查表，白名单外对非 owner/admin 连接直接跳过。**不给 broadcast 加 bool 参数、不让调用点自己判断** —— 那正是"漏一处就是 泄漏"的形状。全包只有一个 fan-out 循环，14 个 .broadcast( 调用点全部落进该入口。 - 白名单只有 7 个状态机信号帧（不含任何内容）：session_busy / pending_ack / pending_drain / session_idle / session_interrupted / pending_full / session_read - 其余全部（流式 message/thinking/tool_call、message_persisted/edited/deleted、graph_update、 subagent_event/result、task_output/task_done、automation_result、tool_used、capacity_awaken、 mode_switch、mood、device_update、reminder）仅 owner+admin - 语义澄清：本门管「谁被主动推送」，数据可见性仍由 REST 决定（viewer 的 12 条只读监控端点 不变，含 GET /personas 的 mood）；/ws/chat 连接鉴权与 voice_output 定向帧不动 契约：Docs/api-client.md → v0.48（对 viewer 是收紧；owner/admin 零变化；无端点/字段形状变更） 验证：go build/vet 绿；go test ./... = 58 包 ok / 0 FAIL；-race ./internal/services/gateway/... ok； linux/amd64 + darwin/arm64 交叉编译绿。真 httptest WS + 真 JWT 按角色逐帧实测 37 帧： viewer 只收到 7 个状态信号，owner/admin 37/37。 变异验证：① graph_update 加回白名单 → 真 WS 抓到 viewer 收到 graph_update，3 个测试 FAIL； ② session_idle 移出白名单 → 3 个测试 FAIL（viewer 等不到哨兵帧而超时）。均已还原。 遗留（已登记，待主人裁决）：① 握手 history 回放对任意角色照发（viewer 连上即得主会话最近 50 条正文）；② /ws/chat 上行未按角色授权（viewer 可发 chat = 真驱动模型并落库； subagent_ask / task_output_query 的定向应答绕过本门）。	2026-10-03 21:50:29 +08:00
AskaEth	4ea68d17f3	refactor(gateway+model): 拆 gateway/server.go 719→204 + 重构 scanSSE/processFrom 到 ≤80行 ... - server.go 204 + 新 routes.go(193,路由注册/Handler/withMiddleware)/deps.go(108)/contracts.go(231,17依赖接口)/broadcast.go(78,BroadcastPersisted/CapacityAwaken/Mood); 导出面不变; 74条路由pattern+RBAC门逐条比对一致 - model/openai_stream.go: scanSSE 138→25(parse/apply/finalize 对齐 anthropic_stream); openaiStreamState结构体 - channelbridge/inbound.go: processFrom 112→46(blacklistDrop/inboundTargetFor/runInboundTurn/deliverReply) - 纯行为等价; build/vet/test绿(56包)+win/darwin交叉编译	2026-09-30 11:58:49 +08:00