4 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	89434eadef	fix(flow): graph_update 按路分桶——修真并行两路的图互相覆盖（FV2） ... 【取证（症状成立，且比登记描述更糟）】两路真并行时两路最终落盘**同一个 turn_id**， 其中一路的图彻底消失，且 A 路的工具被画在 B 路的图上。逐层定位：发布器 graphs 只按 sessionID 建键（后起的路整张顶掉前者）· 帧载荷基线的键集被既有测试精确断言为 {id,nodes,edges,sessionId,startedAt,endedAt}（无任何区分路的键）· 前端每会话单桶 · 落盘 (session_id,turn_id) 唯一键两路相撞 · 冷启动 LastGraph 只有一张。 该 bug 早已公开登记（design/15 §2.5.10-1「本轮未解决」、契约 §6-19「仍**未修**」）。 【修法】 - 归属桶 {会话}[#{路}]（loop.FlowOwnerKey，与 checkpoint 键同字符口径）；路只来自 ParallelLegFrom(ctx) ⇒ 单路逐字不变（桶 = 会话 id），既有调用点语义零改动 - 图 id 的第二分量改用**建图序号**（每次 +1、永不复用）：同一轮里可以有并行路 + 队首续跑的串行路，用轮次号会让两条串行路撞同一个 web-1 - 轮次号只在上一轮的路全部收尾后推进，并丢掉更早轮次的桶（否则内存随路数无界增长） - 新增只读出口 LatestLanes ⇒ GET /admin/flow/graph 的 lanes[]（最近一轮每一路）， graph 仍是「最新一路」= 向后兼容 - 同源洞一并修：子代理归属原取 AgentSpec.ParentSession（会话、不含路）⇒ 并行路里派的 子代理 span 被静默丢弃；新增 AgentSpec.FlowOwner 承载「会话#路」，ParentSession 继续 只承载会话（总线载荷 subagent_result.sessionId 不受影响） - 前端：store 增 flowLanes（按 turnId 分格、按轮淘汰、硬上限 4）+ LaneTracks 泳道卡； 单路/未给 lanes 时渲染路径与改前逐字相同 【无迁移】turn_id 是自由文本、每路 id 唯一 ⇒ 0022 的唯一索引天然分两行（0023 仍空着） 【我的验收】① 隔离 worktree（30 文件）build/vet/linux/darwin 全过、69 包全绿 0 FAIL； ② 我亲手打红变异：让 FlowOwnerKey 忽略路 ⇒ TestFlowPublisher_ParallelLegsDoNotOverwriteEachOther FAIL；③ 前端独立复跑 npx tsc --noEmit + npm run build 通过（4.12s） ⚠️ 契约 v0.77 的登记在紧随其后的 docs(contract) 提交里（同一个工作时段内）。	2026-10-06 08:16:03 +08:00
AskaEth	4bf1f7cac6	fix(trace): 让 graph_update 的分支根节点 props.persona 真的前送（白名单漏登记） ... 审计（DevDocs/audit/11-trace-observability.md 发现 #1）：scheduler 用 span.SetProp("persona", sub.PersonaID) 设了这个 prop，api-client v0.47 也已把它写进 对外承诺，但 trace/graph.go 的 safePropKeys 白名单不含 "persona"，而 safeSpanProps 只遍历白名单 ⇒ 该键在到达客户端前被静默丢弃（实测：整个 props 键都消失）。 修法：把 "persona" 加进 safePropKeys，并在同处写清它为什么可以前送 —— ① 它必然是注册表校验过的角色 id（scheduler.checkPersona 未知 id 一律 ErrUnknownPersona 拒绝整批派发）；② 它本来就随 GET /personas 与 message_persisted.personaId 对外可见； ③ 值仍过 redactValue → RedactText（凭据形状清洗 + 80 rune 截断）。 测试：新增 trace/graph_persona_test.go（真 Tracer → 真 SetProp → 真 Snapshot，两条断言： 有 persona / 不指定角色时键不出现 = 钉住 v0.47 的"纯增量"）+ 网关 flow_update_ws_test.go 追加 TestFlowGraphUpdateRelaysPersonaProp（真 bus Publish → 真 WS 帧 → 断言帧内节点 props.persona=="yuki"）。 验证：go build/vet 绿；trace + gateway 包测试绿；全树 go test ./... = 58 包 ok / 0 FAIL； linux/amd64 + darwin/arm64 交叉编译绿；gofmt -l 干净；三文件 471/57/370 行、最长函数 64 行。 变异验证：把 persona 从白名单摘掉 → 两条断言分别 FAIL（trace 层 props 为空； WS 帧里 span-sub 节点的 props 键整个消失），还原后复绿。 遗留（登记）：前端尚未消费该键（flow 节点未显示"以谁的身份替班"）。	2026-10-04 10:37:22 +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
AskaEth	28b663231e	test(gateway): 补 graph_update 的 WS 中继与 wire 契约测试（此前零覆盖） ... `#/admin/flow` 报障调查发现：flow 链路每一环都是对的（loop 的 FlowPublisher 三入口 在真实回合里都被调用 / wire.go 的 allow 白名单正确 / parseGraph 与 Snapshot 字段逐条对得上）， 但**「bus 的 ws.graph_update 经 ws_bridge 中继成 WS 帧」这一跳此前完全没有测试**—— 逐环人工核对永远核不到它。补两个契约测试把它钉死： - TestFlowGraphUpdateRelayedToWS：真 bus Publish("ws.graph_update", <真 trace.RunGraph.Snapshot()>) → 断言 WS 收到 graph_update 且数据逐字节未被改写 - TestFlowGraphUpdateWireFields：精确断言 graph/node/edge/log 四层的 key 集合 = 前端 parseGraph 读取的那一套（改名/多字段/少必填都 FAIL） 验证：go build/vet 绿；-race 网关 ok；全量 58 包 ok / 0 FAIL；交叉编译绿。 变异验证：① 改 trace.FlowNode.Label 的 json tag → 键集断言 FAIL； ② 让 ws_bridge 的 normalizeEvent 丢掉 ws.graph_update → 中继测试 i/o timeout FAIL。	2026-10-03 21:39:03 +08:00