jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-22 09:58:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
557 Commits 6 Branches 27 Tags
2722d7609534251076f4bcee5564f4b9b4f0c3c2
Commit Graph

557 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
JianFeeeee
2722d76095 fix(llm): max_tokens 截断不再静默降级成空参数 
长参数工具调用（整段脚本/大 JSON）被 core.llm.max_tokens 从中间切断时，
上游回 finish_reason=length，而旧实现把这个信号整个丢掉：残缺 JSON 解析失败
后静默降级成空 map，工具只看到参数为空并报 'path is required'。模型因此完全
看不出真因，原样重试四遍、次次撞同一堵墙（2026-09-19 实测 4 次 files_write 失败）。

注：files_read 并未失败——是写挂之后模型反复重写把读卷进同一轮，看起来像两者都报错。

改法：
- finish_reason=length 时不再静默降级，改为塞入 __truncated_error 指引，
  告诉模型「参数被截断 + 请拆成多次调用/追加写 + 勿原样重试」；
- executeToolCallInner 见到该标记即短路，不拿空参数去调工具；
- 非截断的残缺 JSON 保持旧行为（避免把「厂商不回 finish_reason」误判成截断）。

回归测试 2 条钉死这两面。
 2026-09-19 13:49:21 +08:00
JianFeeeee
01113664b4 fix(obs): 抢占日志改在判决点打（修自伤）+ scheduler 事件接进 SSE 
## 修我上一版的自伤

上一版把 preempt 日志打在 `executeNewTask`，但那时 `nextRef` 已经把
`s.running` 换成了抢占者自己，于是输出成了

    preempt start: task#2 ... -> victim task#2 (cli)

victim 打印的是入侵者本人。判据必须落在 `registerInterrupt`——那一刻
running 还是真正的受害者。改为在抢占判决点打：

    [agent] preempt: task#2 class=interrupt level=3 from cli (L3) preempts task#1 class=queued level=0 (qq)

## 补上「入队而非抢占」的日志

中断到了却没生效，此前完全不可解释。现在两种成因分开写：

    [agent] interrupt queued: ... vs ... (qq) — running in critical section; queue=N
    [agent] interrupt queued: ... vs ... (qq) — preempt cooldown; queue=N
    [agent] interrupt queued: ... vs ... (qq) — level insufficient; queue=N

没有这条，`interrupt from X` 打过之后任务为什么没让位就只能猜。

## scheduler 事件接进 SSE

`EventScheduler` 此前既不在 `handler_chat.go` 的 subTypes、也没有任何订阅者
（全仓 grep 零命中）——内核里 suspend/resume 只 publishEvent，于是事件发出来
就掉地上，对内对外都不可见。加进 subTypes 后前端/客户端能看到抢占链。

## 验证

- preempt_logging_test.go 增一条：victim 与入侵者必须是不同来源（qq vs cli），
  且排队输入对排队任务 `canPreempt` 必为假。
- 实测输出含 `cli (L3) preempts task#1 class=queued level=0 (qq)`。
- 全量 `go test ./internal/... ./cmd/...` 与 `go vet ./internal/...` 全绿。
 2026-09-19 11:57:50 +08:00
JianFeeeee
b1ec278136 feat(obs): 抢占日志说出「受害者是谁」——suspend/resume 此前完全不落日志 
排查「我的任务怎么被莫名打断了」时撞上的观测缺口。

## 缺口

`executeNewTask` 里挂起、`resumeTask` 里恢复，两处都**只发事件、不写日志**：

    a.sched.suspend(t, f)
    a.publishEvent(events.EventScheduler, map[string]any{"action": "suspend", ...})

于是生产日志里只有两行：`interrupt from X` 与 `LLM request cancelled by
preemption` —— **看不到受害者是谁、被谁挤下去、后来有没有恢复**。后果是实测过的：
按时间先后猜凶手，把时间上相邻的输入误认成抢占者。

## 改动

- `sourceOf(task, frame)`：取可辨识来源（`evt.Source` 优先，回退 OutputChannel，
  自循环任务给 `self:<channel>`）。取 Source 而**不是** OutputChannel：
  前者回答「谁送来的」（qq / homeagent-mail-bridge / timer / child/xxx），
  后者只回答投递到哪个通道；多数场景同名，但因果链上要的是前者。
- `describeTask(task)`：`task#N class=queued|interrupt level=L`。
- `suspendDepth()`：日志专用，走锁而不是让日志点直接摸 `suspendStack`。
- 三个日志点：抢占开始（含 victim）、挂起（含来源与栈深）、恢复。

输出形状：

    [agent] preempt start: task#2 class=interrupt level=4 from cli -> victim task#1 class=queued level=0 (qq)
    [agent] suspend: task#1 class=queued level=0 (qq) yields to an interrupt; suspendStack=0
    [agent] resume: task#1 class=queued level=0 (qq) resumes after the interrupt finished

## 验证

- 新增 preempt_logging_test.go：抢占后栈深 0→1、sourceOf 取到 qq、self/nil 不 panic。
- 实测日志（TestPreempt_HigherPreemptsAndResumes）三条齐全，能一眼看出
  是 `cli` 的 L4 挤掉了 `qq` 的排队任务、随后 qq 恢复。
- `go test ./internal/... ./cmd/...` 全绿。
 2026-09-19 11:31:04 +08:00
JianFeeeee
d202f2ceec feat(ohos): screensue 改用 Web 组件渲染 HTML（RichText 撑不住） 
用户实测截图：推送内容把整段 HTML 源码当字符串显示（含 <style>、@keyframes、
内联 <svg>、radial-gradient）。RichText 只认极小标签子集，这些一律不渲染。
用户明确要求「引入 webview」。

## 修法

- 新增 `common/ScreensueHtml.ets`（从 BridgeCaps 抽出：后者加进 HTML 逻辑后
  超 520 行，越了工程「单文件 ≤400 行」的约定；且「screensue 怎么解析/渲染」与
  「设备能力怎么实现」本是两件事）。
- `ScreensuePage.ets`：HTML 走 **Web**，纯文本仍走 Text。
- 加载用 `loadData(base64)`：encoding 非 base64 时按 URL 规则转义，几 KB 的
  完整文档会撞长度/转义问题。自写 `base64Utf8`（UTF-8 手编字节，含代理对合成）
  —— 直接把 UTF-16 码元交给 Base64Helper 会让中文变乱码。
- 非完整文档补一层 shell（meta viewport + 主题前景色），完整文档原样加载。

## 顺带修掉一个真实缺陷（实测发现）

`looksLikeHtml` 旧判据要求「首个非空字符就是 '<'」。而 agent 传参常把整段文档
连引号一起给（`'<html>…'`）——截图里那个孤立的 `'` 就是这么来的，判据因此
**判否并退回纯文本**，所以看到的是源码。改为扫第一个「像标签开头」的 '<'
（跳过引号/前导文字），且只在其后紧跟字母或 '/' 时才算，避免误判 "a < b"。
Node 复刻同一算法验证了 7 个样例（含截图实况、<3 表情、比较符）。

## 安全（我因为引入 WebView 而必须自己把关）

内容来自 agent（第三方）。显式关闭：
`javaScriptAccess(false)` / `fileAccess(false)` / `domStorageAccess(false)` /
`onlineImageAccess(false)` / `zoomAccess(false)`。
★ **javaScriptAccess 的默认值是 true** —— 不显式关掉等于让远端内容在客户端执行脚本。
已实测取证：推入带 `<script>` 与 `<img onerror>` 的页面，屏上稳定显示 `JS-OFF`，
两条执行路径都没跑起来。

## 另一个实测发现的缺陷

`onControllerAttached` 只在挂载时触发一次，而 ScreensuePage 在 `if (visible)`
里常驻 —— 连续两条 screensue 只改 @Prop、组件不重建，Web 一直显示**上一条**
内容（实测：倒计时变成 33s 但画面还是旧 HTML）。改 `@Prop @Watch('onDataChanged')`
显式重载，并记录 attached 状态避免过早 loadData（会抛 17100001）。

## 验证（模拟器真机链路）

把工程内连接指向本机服务、开启「允许 agent 控制本机」授权，经
`device_ctl_cmdrun` → 设备桥 → screensue 推入用户截图里那段原样 HTML：
- 渲染成功：radial-gradient 背景、内联 SVG 兔子、CSS 发光文字、两行文案
  （修复前同一段内容显示为满屏标签源码）
- 连推第二条 → 画面正确刷新为 SECOND PUSH
- JS 探测 → JS-OFF（脚本被拦）

模拟器只能装 unsigned 包（signed 报 READ_PASTEBOARD 授权失败，与既有记录一致）。
 2026-09-18 12:01:33 +08:00
JianFeeeee
895948b24e fix(stop): 配额须计入停在输入 channel 的待处理消息 
实测：停止后排队消息仍逐条跑完。原因是 armStop 只数 sched.queue，
而用户按下停止时调度器正忙于当前任务，其余消息大多还没被 pumpInbox
搬进队列、仍停在 inputCh ⇒ queued=0、配额归零。

- IOManager.PendingInputs()：暴露 channel 中待处理条数。
- armStop(pending int)：queued = len(s.queue) + pending。
- 补 TestStop_ArmCountsPendingChannelInputs 锁死该口径。
 2026-09-18 11:39:04 +08:00
JianFeeeee
698ff7ddd5 fix(stop): 修自伤——interceptLoop 里 takeStop() 被 || 短路提前消费 
上一版把 stop 标记在 interceptLoop 里消费掉了一部分：
`if n := armStop(); n > 0 || takeStop() { ... }`，queued=0 时短路到
takeStop()，标记先被吃掉，stepLLM 永远看不到 → 取消后照样重跑一轮。
实测：日志正确打出 stop requested ... queued=0，但生成仍跑到自然结束（5000+ 字全文落库）。

改为只 arm 不 take（takeStop 只由 stepLLM 消费），并补一条**经真实
interceptLoop** 的用例：它必须 a.Start()（第一版测试只调 New()，
interceptLoop 根本没跑，假绿）。已验证该用例在注入此 bug 时失败、修复后通过。
 2026-09-18 11:32:20 +08:00
JianFeeeee
ccc2ac2d4d fix(stop): 停止按钮真正生效——停止 ≠ 空中断；鸿蒙 screensue 支持 HTML 
两处鸿蒙端缺陷 + 一个跨端（WebUI/GUI/鸿蒙）的停止语义缺陷。

## 症状（实测取证）

1. **鸿蒙终止按钮按下没反应**。POST /chat/interrupt 带空 body，接口回 200
   `{"status":"interrupted"}`，但 journalctl 零中断日志、生成继续跑到自然结束。
2. **鸿蒙 screensue 不解析 HTML**，把标签当普通字符串显示。

## 根因

停止按钮走的是「空内容中断」，而 interceptLoop 有一行
`if text == "" { continue }` —— 空内容被判为「无事发生」直接丢弃。
所以停止指令从未到达调度器；接口那个 200 是不诚实的。

另查明两条会放大症状的既有问题（停止后仍在跑）：
- `chatStreamWithFallback`：流式连接失败时无条件回退非流式 `Chat`。
  上下文已取消时这等于**再发一次完整请求**（停止后模型继续生成）。
- `stepLLM`：`context.Canceled` 一律 `outcomeContinue` 重跑本步。
  这是给「被更高中断抢占」用的（现场要交出去、稍后继续），
  但用户按停止是「不要了」，重跑就是停止没生效。

## 修法（按用户明确的设计）

停止 = ①立即结束当前 LLM 推理（不重试、不恢复）；
②对**停止那一刻已排队**的 x 条消息，后续在 pre-action 阶段依次短路。

- scheduler：新增 `armStop`（登记快照配额并返回当时排队深度）/`takeStop`/
  `consumeCancel`。配额取快照值（停止后新到的输入不受影响），
  重复按停止取 max 不累加（两个客户端同时按不该翻倍）。
- `interceptLoop`：读 `stop` 标记。停止时 armStop + cancelCurrentLLM；
  **纯停止不再进中断队列**（旧实现把它当空中断入队，所以停完还会活）。
  带注释的停止（`/stop 换个话题`）仍走中断路径。
- `stepLLM`：取消 + `takeStop()` → 直接 `outcomeDone`（不再重跑）。
- `stepPrepare`：`consumeCancel()` 命中即在 pre-action 短路收尾。
- `chatStreamWithFallback`：以 **ctx.Err()** 为判据拒绝回退（不是「错误是不是
  Canceled」——很多 provider 用 Canceled 表示「不支持流式」，那种必须继续回退，
  否则会把探测误判成取消；这条区分是跑全量测试时才暴露的）。
- WebUI handler / CLI `/stop`：空消息时带 `stop:true`。

## 鸿蒙端

- `BridgeCaps.ets`：新增 `looksLikeHtml`（首字符 '<' + 字母开头标签名，
  避免误判 "<3" 这类文本）、`screensueHtml`、`escapeHtmlText`。
- `ScreensuePage.ets`：HTML 走 **RichText**（只解析 HTML 子集、无脚本无网络），
  纯文本仍走 Text。不用 Web 组件：agent 下发的是第三方内容，
  Web 默认带 javaScriptAccess/fileAccess，等于让远端内容在客户端执行脚本。
  注入主题前景色，避免 RichText 用系统默认色导致深色主题下黑字不可见。
- `ChatSession.ets`：`interruptChat` 改发 `{stop:true}`（含类型声明，
  ArkTS 禁止无类型对象字面量），并在本地即时复位忙态 + 提示「已停止」。

## 验证

- 新增 `stop_semantics_test.go`：停止终结任务不重试（provider 调用次数恒为 1）、
  配额是快照（x 条短路、随后新到的不受影响）、重复 arm 取 max。
- `go test ./internal/... ./cmd/...` 全绿。
- 鸿蒙 HAP 构建通过；unsigned 包已装进模拟器（signed 包受
  READ_PASTEBOARD 授权限制装不上，与既有记录一致）。
 2026-09-18 11:26:12 +08:00
JianFeeeee
831bd2290b fix(ohos): 聊天改用 seq/after 增量轮询，修「不滚动/己方消息不显示/新消息不加载」 
jianf 报的三个现象其实同一个根因：WebUI 前端在 commit 9711177 已改为
「暴露数据查询 API + 前端轮询 patch 视图」，聊天记录走 /chat/history?after=<seq>
增量游标 + seq 对账；鸿蒙端一直只做**首屏全量加载**，没跟上这套口径。

1) 页面不加载新的聊天信息（根因）
   鸿蒙只在 aboutToAppear 拉一次 /chat/history?limit=40，之后除了 SSE 就没有
   任何拉取。SSE 只在「本端发起的那一轮」推事件，其他端/其他渠道（QQ、
   WebUI 浏览器）发来的消息永远不会出现在鸿蒙页面上。线上实测：鸿蒙
   IP（61.54.104.206, auth=api-key）最后一次请求停在 9/17 22:34，此后
   只有浏览器 session 在轮询。

2) App 发出的消息不显示
   原来靠 mergeHistoryWithLocal 按「正文内容」去重：本地乐观 user 消息
   与服务端回显内容一致就被判重复丢弃；同一句话发两次同样误删。
   改为按 seq 对账（新增 reconcileServerMsgs，对齐 WebUI applyServerMessages）：
   服务端带 seq → 有则原地更新、无则认领本地无 seq 的同类乐观消息；
   旧后端无 seq 才退化为内容比对。

3) 加载完不滚动、停在最新消息处
   @Watch 只在值**变化**时触发，不触发初始值。ChatPage.aboutToAppear 里
   loadHistory() 是异步的，若它在 ChatStream 构造之前就完成，
   requestScroll 递增的 chatScrollRev 就成了「挂载前已发生的变化」——
   onScrollReq 永不被调，于是停在顶部/中间。
   修：ChatStream.aboutToAppear 见已有消息就自己滚一次；scrollToBottom
   的重试从 50/260ms 扩到 50..800ms（长历史布局慢，两次不够），
   并用世代号作废旧一轮定时器，避免与新滚动打架。

配套：
- Model.ChatMessage 加 seq；ChatHistory 解析 seq 与 last_seq（游标缺失时
  回退本页最大 seq，保证不倒退）。
- 新增 pollIncremental()：after 增量 + limit=1 尾部探测（工具卡/最终文本是
  原地改写已有 seq，不产生新 seq，只靠 after 拿不到），3s 节奏与 WebUI 一致。
- startPolling 挂在 connect() 而非 loadHistory 末尾：首屏失败也能自愈。
- disconnect() 停轮询。

验证：hvigor assembleHap BUILD SUCCESSFUL；make check-client-versions 一致；
go build/vet/test 全量零失败。
 2026-09-18 10:49:30 +08:00
JianFeeeee
1f5af1dccf feat(cli,ohos): 补齐两处能力缺口——CLI /memory context|tools、鸿蒙 camerasue 录像回传 
核对「CLI 与 WebUI 插件能力对齐」时发现两个此前遗漏的缺口，一并补齐。

1) CLI /memory 缺 context 与 tools（internal/plugins/cli/plugin.go）
   WebUI 有 GET /api/v1/memory/context 与 /api/v1/memory/tools，CLI 只有
   query/graph/text。IndexerAPI 本就对内部插件开放（BuildContext/
   FormatContext/GetToolDefinitions/BuildToolPrompt），不是 SDK 缺口。
   补上后与 WebUI 同源：context 打印「实际会注入什么上下文」，
   tools 打印工具定义 + 工具提示词。
   waiter 同步接上两条远端路由与 help 文案。

2) 鸿蒙 camerasue 录像（BridgeCaps/BridgeRouter/DeviceBridge.ets）
   此前 `camerasue <N秒>` 直接返回「暂不支持录像回传」。查 SDK 后发现
   cameraPicker 本身就有 PickerMediaType.VIDEO 与 PickerProfile.videoDuration
   —— 录像完全可行，只是回传通道没接。
   现改为：VIDEO 模式取回 mp4，经 DeviceBridge.sendDataChunked 按
   cmd_data_start/分块/cmd_data_end 回传（与 GUI/CLI 录像路径一致），
   网关聚合后落盘成文件、agent 拿路径；照片仍走小体积 base64 内联。
   上限 64MB、时长 1~300s，超限明确报错而不是把 WS/上下文撑爆。

   依赖方向处理：BridgeCaps 需要「往本请求回传字节」，但 DeviceBridge 为取
   CapResult 已 import BridgeCaps，反向 import 会成环。改为 BridgeRouter
   注入 DataChunkSender 回调（它同时持有 deviceBridge 与 reqId），
   BridgeCaps 不碰 socket。新增 CapResult.chunked 标记「结果已由能力分块
   发完」，DeviceBridge 据此不再回 cmd_result，避免网关把已完成请求与后续
   分块错配。

验证：hvigor assembleHap BUILD SUCCESSFUL（ArkTS 编译通过，改动文件零告警）；
make check-client-versions 一致；go vet 干净；全量 go test ./internal/... ./cmd/... 零失败。
 2026-09-18 10:04:53 +08:00
JianFeeeee
9de3b365a6 fix(agentcli): 修 4 个真实缺陷——停机死锁、超时泄漏、僵尸堆积、孙进程逃逸 
jianf 提示 agentcli 可能有问题，系统性审了一遍（含 -race 与线上实证），
确认并修复 4 个互相叠加的真实缺陷，每个都配了「去掉修复即失败」的回归测试。

1) 停机/热重载死锁（plugin_stop_test.go）
   Stop() 先 p.wg.Wait() 再 Close 终端，而 readLoop 自己也记在 p.wg 上、
   只监 t.stopCh 不监 p.stopCh。只要有一个终端开着，wg.Wait() 就永不返回。
   后果：插件卸载/热重载（StopAndUnload/ReloadOne）与停机全挂死，且
   registry 持锁时是整个内核一起挂。
   修：先关活跃终端（move 出 map 后在锁外 Close），再 wg.Wait()；
   readLoop 顶部加 p.stopCh 探测；Stop() 用 sync.Once 保证幂等。

2) 终端超时后资源全泄漏（plugin_lifecycle_test.go）
   readLoop 的 IsExpired 分支只 delete(sessions) 后 return，既不 Kill 也不
   Close。终端已被移出 sessions，cleanupLoop 也再看不到它，进程/PTY fd/
   reader 协程无人回收。实测：timeout=1s 的 sleep 300 超时后进程仍在跑。
   修：readLoop 加 defer releaseResources()，保证「只要退出就释放」。

3) 子进程从不回收 → <defunct> 僵尸堆积（pty_linux.go + plugin_lifecycle_test.go）
   newCommandPty 只 Start 从不 Wait。线上实测 homed 名下已有一个
   [sh] <defunct> 僵尸子进程。
   修：linuxPty 加 Wait()（sync.Once 保证只 Wait 一次），
   releaseResources 通过可选接口 Wait() error 调用（Windows ConPTY 不实现则跳过）。

4) Kill 只杀直接子进程，孙进程逃逸（pty_linux.go + plugin_lifecycle_test.go）
   newCommandPty 用 Setsid，sh 是新进程组领头，真正的命令（sleep/vim）是
   其孙进程且同组。只 Kill(sh) 会留下孤儿继续跑。实测：`sleep 300; echo done`
   只杀 leader 后 sleep 仍在（被 init 收养）。
   修：改为 syscall.Kill(-pid, SIGKILL) 杀整个进程组，失败再回落单进程 Kill。

测试设计要点：回归用例必须让「sh 保留为父进程 + 孙进程显式 trap "" HUP」，
否则单个 sleep 会被 sh exec 掉、关 PTY 的 SIGHUP 又会顺手带走孙进程，
两个缺陷都测不出来（这两种情况都实际踩过并修正了用例）。

全量 go test ./internal/... ./cmd/... 通过，agentcli 单包 -race 通过。
 2026-09-17 20:24:03 +08:00
JianFeeeee
ec13eb391a fix(agentcli): 终端退出前补推残留输出，短命令输出不再丢失 
线上验证「内核开、两个插件接」时发现的真实缺陷：`echo`、`ls` 这类在首个
200ms ticker 之前就结束的短命令，readLoop 走到 `!terminalRunning(t)` 分支
直接 return，残留在 stream 里的输出从未 flush。

症状：输出只留在 session.buf 里——agent 用 terminal_read 能看到，但
terminal_output 事件永远发不出去，于是内核权威视图（以及 WebUI/CLI 的
/terminals）的 output 恒为空。实测 term_2（echo HELLO_KERNEL_REGISTRY）
在 /terminals 里 output="" 而 agent 同期 terminal_read 拿到了正文。

修法：
- 抽出 flushTermStream(s, t)，ticker 与所有退出路径共用同一条推送路径
  （避免以后再出现「某条退出路径忘了 flush」）。
- readLoop 顶部加 defer：defer flushTermStream 后于 defer emitTermState
  声明 → LIFO 下先 flush 再报停止，保证「最后一段输出」先于 running=false
  到达订阅者。

测试：plugin_flush_test.go 新增 TestReadLoopFlushesOutputOnExit——走
EventBus 捕获事件，推入输出后立即让进程退出（远早于 ticker），断言输出
已补推且末态 running=false。已验证去掉修复即 FAIL、加回即 PASS。

注：handleRead(clear=true) 会主动 Reset stream（避免与读取结果重复），
属既有设计；本修复针对的是「未被读取就退出」的路径。
 2026-09-17 20:00:47 +08:00
JianFeeeee
e70d2171ee refactor(terminal): 内核开终端/命令历史权威视图，WebUI 与 CLI 都改接内核 
按「内核开，两个插件接」重构终端与命令历史的数据归属。

背景：此前 WebUI 与 CLI 各订 EventToolCall/EventTerminalOutput 攅一份状态，
同一件事两份推导，还各自踩过同一个坑——工具 result 是 Go 的 map 文本
（map[cols:80 ... id:term_2 ...]），断言成 map[string]interface{} 永远失败，
terminal_create 的 id 回填不生效，/terminals 因此恒空（WebUI 也一样）。
实测确认：WebUI 自己的 /api/v1/terminals 与 /api/v1/cmd/history 同样是空的。

内核开（权威唯一真相）：
- internal/agent/core/terminal_registry.go：TerminalRegistry 归并两类事件——
  EventToolCall（terminal_create/close、cmd_run，id/command 从 args 或 Go map
  文本回填）与 EventTerminalOutput（agentcli 生命周期 + 输出，含 64KB 缓冲上限、
  100 条命令历史、50 个终端上限）。
- internal/sdk/terminal.go：新增 TerminalAPI（ListTerminals/CmdHistory）与
  TerminalStatus/CmdExecStatus DTO。**不塞进 KernelStatus**：那是全量快照，
  前端每 3 秒轮询 /kernel，背上每终端最多 64KB 输出会让轮询成本爆炸；
  终端输出是按需拉取的明细，另开接口。
- Agent 订阅自己的事件总线（subscribeTerminalRegistry），且**只根 agent 建**
  （驻留子共用同一总线，每个子都建会 N+1 份重复记账）。
- SDKConfig/Registry/bootstrap 接线：pluginReg.SetTerminalAPI(agent)。

生产者补全（agentcli）：终端无输出时 ticker 不发事件，内核就无从知道终端
存在。新增 emitTermState，在 handleCreate/handleClose/readLoop 退出（超时/
进程结束/读取错误/stopCh）显式上报 running 状态，并给输出事件补 command 字段。
handleClose 改为接收 *sdk.PluginSDK 以便上报。

两个插件接（消费方）：
- WebUI：删掉本地 termStates/cmdHistory/subscribeTerminalStream/handleToolEvent
  及不再使用的 getStr；/terminals 与 /cmd/history 直接读 s.Terminal()。
- CLI：删掉上一轮刚加的 subscribeToolEvents 与 cliTermState/cliCmdExec；
  /terminals 与 /cmd/history 直接读 s.Terminal()。两条路（local/remote）都通。

测试：新增 terminal_registry_test.go，锁死 Go map 文本解析（旧缺陷根因）、
生命周期、CLI 直调路径（无 EventToolCall 仅凭 output 事件建条目）、历史与
终端数量上限。全量 go test ./internal/... ./cmd/... 通过。
 2026-09-17 18:56:15 +08:00
JianFeeeee
3cce605722 feat(cli): /terminals、/cmd/history、/terminal 对齐 WebUI（事件面 + ToolAPI，无需新接口） 
去看了一遍源码，纠正上轮判断：终端与命令历史也不是 WebUI 插件私有。
- 终端会话：agentcli 插件持有，发 EventTerminalOutput；WebUI 只是订阅该事件
  自己攒视图。命令历史：WebUI 订阅 EventToolCall 的 cmd_run 攒的。
- 于是 CLI 插件订阅同样两个事件即可同口径：/terminals、/cmd/history。
- 开/写/读/关终端：SDK 的 ToolAPI.ExecuteTool 已允许跨插件调用工具，
  CLI 直接调 agentcli 的 terminal_create/write/read/close，新增 /terminal 子命令。

waiter 侧同步：/terminals、/cmd/history 两条路（local/remote）都接；/terminal
仅在 local 可用（远端 WebUI 无对应 REST 端点，明确提示而不是当聊天发出去）。
 2026-09-15 15:31:32 +08:00
JianFeeeee
0227fc2d4d feat(cli): /persona 与 /agents 对齐 WebUI（复用已开放的 SDK 面） 
- /persona：读写 core.agent.personal_prompt / core.internal.persona_initialized；
  插件 SDK 的 Settings() 满足 internal/config.PersonaKV，与 WebUI 同一实现。
  GET 等价返回 initialized/current_prompt/file_override；/persona set <mode> [内容] 写。
- /agents：改用 supervisor.ListAgents()（WebUI /agents 同源），此前只回一个
  agent_id、驻留子信息全丢。
- waiter 侧 /persona 在 local/remote 两条路都接上，/help 补齐。
 2026-09-15 15:25:20 +08:00
JianFeeeee
91c25fa536 feat(cli): /runtime 接上（runtime 本就经 KernelStatus 对内部插件开放） 
纠正上一轮的判断：runtime 不是“SDK 未暴露”。s.Status().GetKernelStatus()
里的 Scheduler / Residents / Channels / InputChannels 就是 WebUI /runtime
的数据源，内部插件同样拿得到——CLI 只是漏接了这条命令。

- CLI 插件新增 /runtime，输出与 GET /api/v1/runtime 同口径。
- waiter 侧 /runtime 在 local（发 CLI 插件）与 remote（走 REST）两条路都接上，/help 补齐。
 2026-09-15 14:29:29 +08:00
JianFeeeee
bcaa8f3f31 feat(cli): /plugin install 真正可用（直连 pluginmgr 回环端点，与 WebUI 同实现） 
原来 CLI 的 /plugin install 只打印“请去 WebUI”。插件安装逻辑在 pluginmgr
插件里（回环 HTTP，默认 127.0.0.1:9876，无鉴权），WebUI 也是转发到它；
CLI 插件改为直连同一端点，能力对齐。
 2026-09-15 12:17:34 +08:00
JianFeeeee
5333a33e20 feat(cli): CLI 插件能力对齐 WebUI（memory/knowledge/config/tracker/adapters/network） 
原来 CLI 插件只覆盖 WebUI 的一小部分：/memory 只有 query、/knowledge 只有
list、没有 config/tracker/adapters/network，结构化输出还各拼一套文本格式。

按 WebUI 的 REST 面对齐：
- /memory query|graph|text [n]     （对应 /memory、/memory/graph、/memory/text）
- /knowledge | delete <name> | stats（对应 GET/DELETE /knowledge）
- /config                          （对应 GET /config）
- /tracker | rollback              （对应 GET /tracker、POST /tracker/rollback）
- /adapters | remove <name>        （对应 GET/DELETE /adapters）
- /network                         （对应 GET /network）
- 统一 writeJSONContent：结构化数据一律缩进 JSON，与 WebUI 同口径。

waiter 侧同步：把上述命令在 local（发 CLI 插件）与 remote（走 REST）两条路
都接上，/help 补齐；两条路语义一致。
 2026-09-15 12:14:25 +08:00
JianFeeeee
95b1950bb3 fix(ohos): 历史刷新不再整表替换，避免刚发出的消息凭空消失 
sync_required 触发的 reloadHistory 会与刚发出的 POST 竞争：若历史快照
里还没有这条 user 消息，整表替换会让它消失（“客户端侧发出的消息不显示”）。
改为合并：历史为权威，但保留本地两类消息追加在末尾——
  - user 且 source 为空（乐观消息）且内容未出现在历史里；
  - assistant 且 !isFinal（仍在流式输出）。
 2026-09-15 12:09:58 +08:00
JianFeeeee
307a6faee7 fix(ohos): 设置页插件/工具数不显示 + 聊天自动滚底时机 
设置页计数（实测：后端返回 plugins=35/tools=260，卡片却一直显示 '-'）：
- 根因是 ArkUI 的 @Builder 按值传参是“快照”语义——父组件因
  @StorageProp 变化重渲染时不会用新值重跑 builder，数值永远停在
  首次渲染的 0。把 KPI 小卡从 @Builder 方法改为独立 @Component
  （@Prop 单向下发），父组件重渲染时子组件拿到新值并重绘。
- 已上模拟器验证：设置页显示 插件 35 / 工具 260。

聊天自动滚动：
- scrollToBottom 原来只在 50ms 后滚一次；长历史/长思考卡的布局在
  消息数组更新后的若干帧才稳定，一次滚动会落在“当时”的底部，
  最后一条被输入区挡住。改为 50ms 与 260ms 各滚一次，480ms 后
  恢复正常滚动态。
 2026-09-15 11:56:18 +08:00
JianFeeeee
baddaf387e merge: 回流场景式关联召回 + 记忆整备 + 客户端修复（feature/recall-policy） 
- 场景式关联召回：声明/涌现双通道、场面指纹聚类、场景前缀/相似度召回
- 记忆整备：doc→graph 闸门、噪音/孤立清理、关系去重、原句回显、memoryPass 收敛
- 本轮修复：衰减真半衰期、索引同步基线、Ensence 死参/死分支、冗余索引
- 客户端：鸿蒙未连接连接入口 + camerasue；waiter 斜杠命令本地语义修复
- 版本：GUI/鸿蒙/waiter 与内核统一 1.4.0（make check-client-versions）
- 客户端版本同步文档 §四
 2026-09-15 11:13:04 +08:00
JianFeeeee
15497ee0a2 feat(ohos+waiter): 补 camerasue 能力；修 waiter 本地斜杠命令被当聊天文本 
ohos camerasue：
- LOCAL_DEVICE_CAPS 增 camerasue；BridgeRouter 增 camerasue 路由。
- 实现走系统相机选择器 cameraPicker（三方应用无法无界面直驱摄像头），
  结果落应用沙箱（saveUri=filesDir），不写系统媒体库、不需 READ_IMAGEVIDEO。
- 录像（camerasue <N秒>）明确返回“暂不支持录像回传”，而不是回一个超长
  base64 撑爆上下文；二进制分块回传待接线。

waiter 本地/远端命令语义统一：
- 修 bug：/settings、/settings set、/plugin install/remove/info、
  /memory query、/knowledge delete 本地分支发的是 cmd[1:]（丢掉前导 /），
  于是 CLI 插件不认、被当成聊天文本丢给 LLM。改为原样发（保留 /）。
- 补 /stop、/interrupt：/help 一直写着但 handleBuiltin 没实现，会落到
  “当普通消息发给 Agent”。远端走 POST /chat/interrupt，本地交给 CLI 插件。
- 补 /plugin disable|enable：远端插件管理 REST 动作，本地 CLI 插件。
- /help 文案改为“local 与 remote 行为一致”并列出新命令。
 2026-09-15 11:12:27 +08:00
JianFeeeee
c151d391ee docs(release): §四 补客户端版本必须与内核同步 + make 门禁 2026-09-15 11:04:31 +08:00
JianFeeeee
065732f42e chore(version): 客户端版本与内核对齐（唯一事实源 internal/meta.Version） 
此前三份版本号互不相干：内核 1.4.0、GUI 1.0.0、鸿蒙 1.1.1。手工各改各的
必然漂移，所以把「对齐」做成机械动作而不是约定：

- deploy/scripts/sync-client-versions.sh：从 internal/meta.Version 读版本，
  同步 cmd/gui/package.json 与鸿蒙 AppScope/app.json5（versionName +
  versionCode=X*1e6+Y*1e3+Z）；--check 给 CI/Makefile 做漂移门禁。
- Makefile 新增 sync-client-versions / check-client-versions；build-cli 也注入
  LDFLAGS，waiter 与 homed 同版本。
- 鸿蒙：新增 common/AppVersion.ets，从 bundleManager 读安装包 versionName，
  BridgeProtocol/BridgeCaps 里两处硬编码 '1.1.1' 改为读它——版本只剩
  app.json5 一份，杜绝第二真相。
- waiter：`-version` 打印版本，启动横幅与设备桥 hello 的 version 字段
  直接引用 internal/meta，与内核天然同源。

对齐后：GUI 1.4.0 / 鸿蒙 1.4.0(1004000) / waiter 1.4.0 / 内核 1.4.0。
 2026-09-15 11:03:26 +08:00
JianFeeeee
a9ad97240b fix(ohos): 未连接后端时给出不可错过的连接入口 
问题：全新安装（未配置后端）时，聊天页只有空列表+输入框，用户找不到
任何连后端的入口；设置页的连接入口在列表里也容易被略过。

改动：
- 聊天空态按连接状态分流：未连接显示「尚未连接后端服务」+「去设置连接」
  按钮；已连接显示「开始新的对话」。
- 跨页信号（AppStorage：K_HAS_CONN / K_REQUESTED_TAB / K_SETTINGS_SUB）：
  按钮 → Index 切到设置 Tab → SettingsPage 直接打开「后端连接」二级页。
- 设置页在未连接时主动把连接表单推到面前：窄屏 onNavigationModeChange(Stack)
  直接 push，宽屏右栏默认页从「运行状态」改为「后端连接」。
- 连接增删改切后广播 K_HAS_CONN，聊天空态即时切换文案与入口。

已在手机（窄屏）与折叠展开（宽屏）模拟器验证：空态按钮可达、点击后
落到带「+ 添加」的连接表单；冷启动点设置 Tab 亦自动打开连接页。
 2026-09-15 10:52:48 +08:00
JianFeeeee
acc94723fd fix(memory): 打通场景/索引/召回残余矛盾点，清理死代码与冗余索引 
- DecaySceneRefs 真半衰期：新增 scene_refs.decayed_at 作计时起点，
  每个引用至多每 halfLife 衰减一次。此前只按 created_at 判龄 + 每次
  心跳对半砍，30 天阈值配 60 分钟心跳会在几小时内清空老关联（不是半
  衰期是骤死）；时间基准改走 SQLite datetime('now')，不再与 Go 本地
  时间混用。
- Indexer.syncIfStale 基线口径与 Sync 对齐（min(实体数, 全量召回上限)）：
  实体数超过上限时原实现永远不相等，每 retrainInterval 全量重训一次。
- EnsureScene 去掉从不使用的 Situation 参数；修正 EnterSceneWithHint /
  resolveTurnScenes / 测试里「声明场景会学整轮指纹」的过时注释（实际
  刻意不学，否则会吃死被动路）。
- SituationFeature.Weight 补 peer_group → wFeatPeer：此前落到 default
  话题级 0.4，群聊身份被降级成软信号。
- RecallBySituation 注释改为与实现一致（相似度只决定命中哪些场景，
  不参与每条关系排序）。
- 移除只被测试使用的 EmergentScenes（SceneStats 已含 origin/strength/
  features，完全覆盖）。
- 清理与 UNIQUE 隐含索引重复的 idx_entity_name / idx_sentences_text。
- 新增 TestSyncIfStaleBaseline / TestPeerGroupWeight，衰减测试补「同一
  半衰期内不重复衰减」用例。

go build/vet 干净，internal/... 全绿。
 2026-09-15 10:20:40 +08:00
JianFeeeee
49695c38f3 feat(memory): 场景双通道——主动声明与被动涌现并存，且互不吞噬 
按「声明式的也要支持，相当于主动被动两条路」落实。此前两者只是恰好并存，
没有边界，实测会互相吃掉（下面的坑就是）。

- Triple.Scenes []string（多值）：一轮写下的记忆**两条路都挂**。
  只挂一条会丢东西——只挂声明则细粒度唤起丢失，只挂涌现则首次交互
  （场景还没长出来）没有兜底。单值 Scene 保留兼容。
- TurnScene：Primary 用于写（优先涌现场景，首次退到声明场景兜底），
  Keys 是两条路的并集，用于召回（声明+涌动的场景一起进 RecallByScene）。
- EnterSceneWithHint：主动路 EnsureScene（声明即建场景，不等第二次），
  被动路 EnterScene（指纹聚类）。写侧由 executeToolCall 把本轮场景集合
  传给 memory_commit，模型不需要知道"场景"这回事。

踩到并修掉的坑（两条路互相吞噬）：
  最初让声明场景也吸收**整轮指纹**，于是 chan:qq 的相似度永远是 1.0，
  把后续所有同类轮次全部吃掉 → 被动路再也长不出更细的场面，
  实测 turn2.Emergent=true 但 Primary 仍是 chan:qq、没有 auto: 场景。
  修法：给场景加 origin（declared/emergent）：
  - 被动聚类只认 origin='emergent' 的场景（声明场景不进相似度空间）；
  - 声明场景的特征**只从键自身解析**（chan:qq/peer:group_1 → {chan:qq, peer:group_1}），
    白名单 kind（chan/peer/peer_group/tool/topic/part），不猜——
    「老大2026-09-04_12:27_qq私聊图片」里的 12:27 也是 kind:value 形态，
    放进特征空间就是往相似度里灌垃圾（有测试钉住）。
  - 声明路的泛化靠**层级键前缀**（chan:qq 覆盖 chan:qq/peer:x），机制各归各。
- memgc -scene-stats 增加 [declared|emergent] 与 strength/features 两栏，
  可直接观察两条路各自在长什么。

新增/改写用例：
- TestDeclaredAndEmergentBothLearn：首次交互兜底到声明场景 → 第 2 轮长出
  细粒度涌现场景且**优先用于写入** → 声明场景不进相似度空间（防止压死被动路）
  但仍走声明键取回 → 两条路都进召回集合 → 声明键特征解析与白名单。
- TestEffectiveScenes：多值+单值合并去重保序。

go build/vet 干净，go test -count=1 ./... 全绿。
 2026-09-15 09:37:29 +08:00
JianFeeeee
bb7e7979ae fix(memory): SceneStats 的 strength/features 不再说谎 
- 旧行经 ALTER 加列后 strength 为 NULL，直接 SELECT 会显示成 0（实际是 1 次）；
  改为 COALESCE(strength,1)，并补上 features 计数（场景长出了几个特征）。
- 两栏一起看才能判断「场景是不是真在涌现」，而不是被一次性写出来的。
 2026-09-15 09:29:46 +08:00
JianFeeeee
d4f9a12db0 feat(memory): 场景从「声明」改为「涌现」——场面指纹自己长成场景 
上一版场景是声明/派生的：调用方写 scene="chan:qq"，或由通道机械派生。
那不是涌现，是贴标签——标签谁定、怎么定全靠人。按「像人一样：干了什么事，
后续类似场面自动唤起对应记忆」的要求重做。

机制（全部取自运行时可观察量，无需模型配合、无需人工标注）：

- **场面指纹 Situation**：每轮采集 `chan:xx / peer:xx / peer_group:xx /
  tool:xx / topic:xx / part:xx`。权重按种类：通道与对象最强（1.0），
  工具次之（0.8），话题是软信号（0.4），时段最弱（0.2）。
- **归属判定用加权 Jaccard**（不是字符串相等）：共享特征权重和 / 并集权重和。
  加权是必须的——`chan:qq` 与 `topic:排班` 的证据力差 2.5 倍，不加权会让
  一次偶然的话题重合把两个不同场面并成一个。
- **涌现**：同类指纹重复到 minSceneEvidence=2 次才长出场景
  （首次只登记 situation_evidence 足迹）。一次性的交互不是「场面」，
  给它建场景会让库被一次性事件撑满、之后每次路过都召回一堆只发生过一次的事。
- **强化**：场景每次重现 strength+1、并入新特征。
- **唤起**：RecallBySituation 按**相似度**取回（阈值 0.35，比归属阈值 0.5 低
  ——想不起来是损失，多想起一条只是多几行上下文），与措辞无关。
- **遗忘**：DecaySceneRefs 按半衰期让久未重现的关联淡出，低于 floor 直接删；
  已接进 archive 心跳（半衰期 30 天，比「这个月没做过这类事」更久）。

三个必须讲清的边界：
1. 一轮只解析一次场景（TaskFrame 缓存）——多解析一次就多记一次强度，
   「工具调得多」会被误读成「这个场面更常出现」。
2. 声明与涌现**并存**：声明是「我知道这是哪个场面」（插件注入点最清楚），
   涌现是「这轮看起来像哪个场面」。两者都进召回。
3. 记忆挂载全自动：memory_commit 没写 scene 时落到本轮涌现场景，
   模型不需要知道场景这回事。

验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例（核心证据）：
- TestSceneEmergesFromRepetition：首次不建场景 → 第 2 次同类场面长出场景 →
  同场面**不同话题**仍并入同一场景 → 换通道的场面自己长出独立场景（共 2 个）→
  强度随重现增长、特征多条。全程没有任何人声明过场景键。
- TestSceneRecallsBySituationNotWording：场面里写下的规则，换措辞后仍被
  自动唤起（含原句），无关场面不唤起。
- TestSceneRefDecay：一个半衰期权重减半、第二个半衰期低于 floor 被清掉，
  仍在重现的场景不受影响。
- TestSituationFeaturesFor：指纹维度齐全、归一化、数值 group_id 转换、nil 安全。
 2026-09-15 09:27:39 +08:00
JianFeeeee
b7e47a1b1f feat(rel): 文档层接入场景（document 节点挂场景） 
场景贯穿流水线的 doc 层补完：
- 新增 TagSceneDocument，linkBlocksToDocument 里建文档节点时一并挂场景；
- RecallByScene 返回该场景下的文档 id（可枚举「这个场面有哪些文档」）；
- 文档场景由**来源派生**（chan:<source>），不存冗余 Doc.Scene 字段——
  存一份会随来源改名而说谎，是同一事实的第二份真相。

go build/vet 干净，go test -count=1 ./internal/memory/ ./internal/agent/core/ 全绿。
 2026-09-15 09:16:22 +08:00
JianFeeeee
9d45cd0277 fix(rel): 场景贯穿流水线到块层 + 编辑不再丢置信度/场景 + 构建默认带 onnxruntime 
三件事，前两件是上一轮热部署暴露/遗留的真缺陷。

1) 热部署差点静默降级（已修）
   `make build` 之前**不带任何 tags**，而发行构建（deploy/packaging/build.sh）
   默认 HOMED_TAGS=onnxruntime，package-linux.sh 还会直接拒收非 onnxruntime 二进制。
   实测差异：33MB vs 84MB；启动日志里
   「multimodal space active: provider=chineseclip dim=512」整行消失、
   少加载一个插件（chinese-clip/qwen3vl provider 降级）、
   静态词向量退回 fallback。即「随手 make build」与「发行构建」不是同一个东西，
   而部署时无从察觉。
   修：Makefile 的 build 默认 HOMED_TAGS ?= onnxruntime（与打包脚本一致），
   构建后自动校验二进制里有没有 onnxruntime，缺了就打 WARN。
   生产已按此重新构建部署（v1.4.0+hotfix.d98bf51，已核实 provider 行回归）。

2) memory_edit 每跑一次就静默降级一次（新）
   memory_edit 是「按包含匹配 Purge + 写新三元组」，中间那一步把旧关系的
   置信度、原句、**场景引用**全丢了：置信度被重置成默认 1.0，场景钉死的记忆
   被打散成无场景。而关系复审心跳（reviewLoop）走的正是这条路——每轮复审都
   在无声地削记忆质量。
   修：编辑前用 FindRelations 精确取回旧关系，把置信度/原句/场景带到新三元组；
   新增 ScenesOfRelation。Purge（hard/soft）与 PurgeNoise/PurgeOrphans 之后
   统一清理悬空 scene_refs，SceneStats 不再说谎。

3) 场景贯穿流水线到块层（按「rel 应贯穿整条流水线」的设计）
   此前场景只到 relation/entity：块（L0/L3 一等记忆块）没有场景，于是
   「那场 QQ 对话里发过来的那张图」在场面重现时永远取不回来。
   - MemoryBlock.Scene + memory_blocks.scene 列（幂等 ALTER 迁移）。
   - scene_refs 增加 ref_text 承载字符串主键（块/文档 id 不是数值）。
     **不能只 ALTER ADD COLUMN**：唯一约束要从 (scene_id,kind,ref_id) 变成
     含 ref_text 的四元组，而 ALTER 改不了约束——旧约束会让「同场景第 2 个块」
     直接冲突（只在多块场景暴露）。改为按列探测后整表重建并搬运旧数据。
   - PutMemoryBlocks 同事务挂 scene_refs(kind='block')；无场景重写不覆盖已有场景
     （否则一次无场景重写就静默抹掉挂载）。
   - RecallByScene 返回块；FormatContext 增「场景素材」段（模态 + 文本/短 digest），
     上限 3 条。
   - 生产者接线：attachBlocksToSentence 让块继承承载它的三元组的场景；
     linkBlocksToDocument 让文档的块继承文档来源场景（QQ 归档的图挂 chan:qq）。

验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：场景块（取回/同场景多块/无场景重写不抹场景/悬空引用清理）、
**旧表结构迁移**（降级成旧 scene_refs 后重开，旧数据保留且多块可写）、
场景素材注入、FindRelations+ScenesOfRelation 编辑搬运闭环。

生产：已重建（-tags onnxruntime）并原子替换 /usr/local/bin/homed + 重启，
35 插件全加载、panic/fatal=0、chineseclip 空间 active。
 2026-09-15 09:03:36 +08:00
JianFeeeee
d98bf512e1 feat(memory): 场景式关联召回——给记忆节点赋场景引用，场面重现即取回 
背景（实测）：带条件的记忆召不回来。生产库里明明有
「QQ回复禁用Markdown格式 --规定--> 纯文本不用Markdown」「老大 --偏好--> 同左」，
但输入「QQ回复格式」时命中 148 个实体、规则排第 32，注入只取前 5——规则根本没进去；
输入「在吗」这种零内容词的短消息，向量路反而灌进 17 个毫不相关的实体。

根因：词法/向量召回都建立在「字面或语义相似」上，而条件式记忆（在什么场合该怎么做）
约束的是**场面**不是话题。用户措辞不重合时它天然召不回；措辞太宽（"QQ"）时又被同形
命中淹没。另一处：自动注入只给实体名索引，而规则本体长在关系上（relation_type + object），
即使命中名字也拿不到「纯文本不用Markdown」这句正文。

改动：把「触发条件」升成一等索引维度。

- schema：新增 scenes(key) + scene_refs(scene_id, kind, ref_id, weight)，
  kind ∈ relation|entity。刻意不建外键：节点可能先于引用被清理，
  悬空引用由读取侧 JOIN 过滤，级联删除会把清理变成跨表事务。
- 场景键是分层字符串（`/` 分隔，由宽到窄）：chan:qq、chan:qq/peer:group_123、
  tool:qq_get_message。NormalizeSceneKey 归一（小写、空白/标点→_、按 `/` 分层），
  空白不算层级——否则「老大2026-09-04 12:27 QQ私聊图片」这种来源名会被拆成伪层级。
- 写入即挂场景：Triple 新增 Scene 字段，commit() 在同一事务里把「关系 + 两端实体」
  挂到场景上（同事务是必须的：关系进库但引用丢了 = 这条记忆永远无声地召不回来）。
- 召回：RecallByScene 前缀匹配（chan:qq 取回 chan:qq 及所有更窄场景；用 `/` 兜底
  防止 chan:qq 吞掉 chan:qq2），按 weight（=写入置信度）降序，返回**关系全文 + 原句**。
- 注入：BuildContextInScene 在词法/向量之外叠加场景路，FormatContext 把场景块排在
  最前（规则对行为的约束强于话题相关的实体名），上限 8 条 + 原句截断 60 字；
  场景实体不在【记忆索引】里重复占位。BuildContext(input) 保持原语义（无场景）。
- 当前场景推导：payload.scene 显式声明 > 通道（chan:qq）> 工具（tool:qq_get_message），
  并列命中不取交集。qq 通道本身 RecallPolicy=none（到达的是中断元文本），
  真正召回在 qq_get_message 工具上——现在那一步同时带上 chan:qq 与 tool:qq_get_message。
- 写入侧：memory_commit 新增 scene 参数（逐条 triples[].scene 优先，顶层 scene 作批次默认）；
  docToTriples 按文档来源自动带 chan:<source>（QQ 归档的知识天然属于 QQ 场面）。
  不做自动猜测：猜错的场景会把无关记忆钉死，之后每次进入该场面都被注入。
- 存量引导：memgc -tag-scene <键> -entity-glob <GLOB>。用 GLOB 而非 LIKE——
  LIKE 对 ASCII 不区分大小写，`%QQ%` 会把对象带 /home/newqqagent 的路径类记忆
  （生产数据目录、email-mcp、dify-ops 路径…实测 7 条）一起卷进 QQ 场景。
- 清理对齐：PurgeNoise/PurgeOrphans 之后顺带删悬空场景引用，并提供
  PurgeStaleSceneRefs；memgc -scene-stats 看场景规模。

验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：场景键归一（含超长/分层/空白）、写入即挂场景（两端实体进、未标的实体不进）、
前缀语义（含 chan:qq2 反例）、weight 排序与 limit、GLOB 存量引导（dry-run 不写库）、
清理后无悬空引用、场景注入面（关系全文+原句+不在索引重复占位）、
agent 侧 sceneKeysFor 优先级（显式声明 > 通道 > 工具、数组形式、nil 安全）。

生产库实测（先 sqlite3 .backup 到 graph.db.bak-20260915-081043 再写）：
把 22 条 QQ 相关关系标进 chan:qq（GLOB *QQ* 19 条 + *qq_* 3 条）。同一批输入前后对比：
- 「在吗」：改前注入 17 个无关实体；改后场景块直接给出「QQ回复禁用Markdown格式
  --规定--> 纯文本不用Markdown」等规则正文（零字面重合也能召回）。
- 「QQ回复格式」：改前规则排第 32 被截掉；改后排在场景块首位。
- 「帮我发个语音」：场景规则置顶，词法路的 qq通道语音输入 等仍在其后。
 2026-09-15 08:13:52 +08:00
JianFeeeee
b37141f3f5 fix(memory): doc→graph 补回常用词闸门 + 存量噪音/孤立节点清理 
问题：图记忆里堆着「结果(192) / 什么(59) / 哪个(99) / 待命(176) / 报告(174) /
context_archived(43)」这类节点，mention_count 冲到几百、度数只有 1~2——
占着热实体位、挤满召回预算，却不带任何结构。

根因：这层过滤原本存在，后来被换掉没补回。1cb3e87（NLP 三元组提取系统）
把 doc→graph 从「CutExact 滑窗词链」换成依存句法提取器时，CutExact
（去停用词 324 条 + validEntityName + 去重，注释至今还写着「用于 doc→graph
蒸馏」）失去了唯一生产调用点，只剩 cut_test.go 在调它。此后落库闸门只剩
validEntityName——它挡的是「不像名字的字符串」（2–50 字符、含字母），
完全不挡「像名字的常用词」。

改动：
- 新增 internal/memory/noise.go：IsNoiseEntity 收敛判定（停用词 /
  context_archived / 模板摘要回声），FilterNoiseTriples 给自动填充路用，
  PurgeNoise + PurgeOrphans + cmd/memgc 供存量清理（默认 dry-run）。
  判定刻意保守：只拦三类客观噪音，开放类词（报告/对话/处理）不拦——
  它们挡不挡是领域决策，见函数注释。
- docToTriples 接上闸门（用户点名的「文档常用词」路）。
  对话蒸馏路 extractKeyTriples **不接**：CutExact 当年也只挂 doc→graph，
  且 pipeline_test 明确断言「我 --读书--> 杭州」必须抽出（代词主语是该路
  既定行为），是否拦属行为决策，已在代码注释里写明并留给使用者定夺。
- cut.go 补全封闭类常用词：咱俩/咱们（我们/你们/他们 早有）、任何/此/本/
  其中/以及/那么/这样/那样/一样/还有/还要/只是/老是/全部/所有/有些/一些/
  别的/其他/其余/各自/本身/方位词/部分/方面。
  「不能/不会」试过又撤回：它们是 embedder tokenize 的实词路径，
  加进停用词会让 static_embedder 的领域聚类用例翻转（今天天气句与股票句
  的相似度大小关系反了），属真回归，不留。
- graph.go：CleanupOrphanedSentences 拆出 Locked 版供 PurgeNoise 复用。

验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：IsNoiseEntity 判定表、FilterNoiseTriples 顺序与边界、
PurgeNoise（统计/幂等/dry-run 不写库/不误删仍被媒体块边引用的句子）、
PurgeOrphans（识别/不误判有边实体/幂等）、docToTriples 噪音闸门与
模板锚点不被误杀。

存量清理（生产库 /home/newqqagent/memory/graph.db，先用 sqlite3 .backup 备份
到 graph.db.bak-20260915-073210）：
- 噪音实体 29 个 + 其关系 59 条
- 零关系孤立实体 25 个
- 结果：实体 778→724，关系 639→580；sentences 3 条与 block_edges 3 条原样保留
  （媒体块引用不被误删），PRAGMA integrity_check=ok、无悬空关系/块边。
- 运行中的 homed 无需重启：下一个 archive 心跳会 Indexer.Sync 重建实体名向量索引。
 2026-09-15 07:47:16 +08:00
JianFeeeee
94995eaa64 fix(memory): 修图记忆召回的两处能力缺失（关系重复 + 原句不回显） 
针对 memory_recall / 自动注入这条图记忆召回链路的实测复核：

- Recall(depth>1) 跨层不去重：每层都用已累积的 entityIDs 查邻接，
  上一层刚产出的关系会在下一层被反复查回并再次 append。实测
  小明→小红 在 depth=2 出现两次，memory_recall 的 10 条关系预算被
  同一句话刷屏、真正的新关系（小红→小刚）被截断。改为按 relation ID
  跨层去重（实体本就已去重）。
- memory_recall 从不回显 sentence_text：工具 schema 明写「填了才能日后
  从图谱回到原文」、Recall 也已 JOIN 出句子，但输出只给实体名与关系类型，
  该字段形同虚设。抽出 formatRecallRelations，对非空原句截断 60 字附在
  关系行后；超过 10 条仍截断并提示。

测试：TestRecallWithDepth 增补去重与精确条数断言；
新增 TestFormatRecallRelations_SurfacesSentence / _Truncates。
go build/vet 干净，go test -race ./internal/memory/ ./internal/agent/core/... 全绿。
 2026-09-15 06:48:36 +08:00
JianFeeeee
6afe361804 fix(memory): 记忆层启动接线/并发/落盘一致性整备 
按设计方案整顿记忆系统，收敛一批"单测照不出、只在长跑生产里暴露"的缺陷：

- 启动接线：initMemoryStack 残留 `defer distiller.Stop()`，规则蒸馏
  10min 心跳启动即死。改为由调用点 cleanup 停机，并补 Stopped() 探针 +
  TestInitMemoryStackKeepsDistillerRunning / TestStartKeepsLoopRunningUntilStop。
- L0 相关性上下文：SetDenseSpace 注入稠密空间时回填已有事件的稠密向量，
  否则旧事件走稀疏余弦、新事件走稠密余弦，同一次 Prune 里两种尺度混排。
- 文档检索：QueryScored 访问计数从读锁内写移出（-race 竞争），更新后置脏，
  优雅关停可落盘、FindColdDocs 冷度判据跨重启不再失真。
- 蒸馏管线：只 flush 未落盘记录（persisted 标记）、蒸馏成功后从 raw 文件
  删除对应行、原子写文件，修重启重复蒸馏导致 mention_count 膨胀。
- 图库：全量 Recall 加实体上限（内部整备路径，防大图整表进内存）；
  ClearSentenceID 补写锁；Commit/upsertEntity 计数语义注释澄清。
- 索引器：recalled 去重集加 FIFO 上限，防长跑进程自动注入越来越沉默。
- 文档/媒体注释修正；README 记忆层流程对齐跨模态召回。

验证：go build ./...、go vet、go test -race
./internal/memory/... ./internal/agent/core/... ./cmd/homed/... 全绿。
 2026-09-15 06:32:36 +08:00
JianFeeeee
3a780384d0 refactor(memory): 裁剪与召回收敛到唯一入口 memoryPass 
把「踢出去（prune）」与「取进来（recall）」从两处各写一遍，收敛为
memoryPass(query, trigger, prune, recall) 单一入口，统一：

- 同一份清洗后的 query（避免噪声带偏相关性打分）；
- 同一次 token 预算与召回截断；
- 同一条带 trigger 的审计日志（谁、据什么触发了哪种操作）。

落地：
- 新增 memorypass.go：memoryPass + pruneByQuery（原 pruneOnInput 的执行体）；
- pruneOnInput 只解析声明，执行委托 memoryPass；
- stepToolAfter 的裁剪/召回改为一次 memoryPass 调用（去掉重复的 topK 逻辑）；
- 抽出 recallText，输入侧 buildTaskMemoryContext 与工具侧 recallTextFor 共用；
- 输入侧召回 query 改用 CleanInput（清洗文本），与裁剪侧同一语义；
- QQ qq_get_history 补齐声明 ContextPolicy=prune + RecallPolicy=auto
  （内容类工具：真实聊天正文既当轮用完即裁，又据正文召回）。

测试：新增 memorypass_test.go，锁死 no-op / 两轴同时生效 / 正交不互相触发 /
输入侧用清洗 query。go build/vet 干净，internal/... 全绿，qq 插件模块测试通过。
 2026-09-14 23:32:41 +08:00
JianFeeeee
b792a94b84 feat(memory): 新增可声明的召回轴 RecallPolicy（与 prune 正交） 
问题：召回（把 L2/L3 相关记忆注入本轮）此前不可声明、也不受任何 SDK 字段
控制——它只在任务开始时对 f.Input 无条件跑一次。于是 qq_get_message 取回
真实正文后只触发 Prune（裁剪），从不触发召回；而中断通知的 meta 文本反而
会去召回（词不对题，命中一堆泛实体）。

改动：
- SDK 新增 RecallPolicy(none|auto) 轴，落在 InjectOptions / ChannelDef /
  ToolDef 三个声明面，与 ContextPolicy 正交（裁剪 vs 召回）。默认值与
  prune 刻意相反：输入/注入默认 auto（保持既有「每条输入都召回」），
  工具默认 none（工具输出多为噪声，按需声明）。
- 内核：recallDeclared 按 注入点 > 通道 > 默认auto 解析；输入侧用它决定
  是否注入记忆索引；工具侧 ContextPolicy/RecallPolicy 共用同一份清洗后
  query，一次相关性过程分别 prune / recall；召回以 system 消息挂到消息
  末尾（同任务内替换而非累加）。
- 管线：proc RPC（inject/register + 校验）、lua 键、io payload 全量透传。
- QQ 插件：中断与 qq 通道声明 RecallPolicy=none（meta 不是内容）；
  qq_get_message 声明 RecallPolicy=auto（取回正文后据正文召回）。

测试：新增 recallpolicy_test.go（core）与 proc 校验用例；
go build ./... 通过，go test ./internal/... 全通过，SDK 模块与 qq 插件测试通过。
 2026-09-14 23:14:38 +08:00
JianFeeeee
29d763e210 merge: 桌面版/鸿蒙端同步阶段管道工具格滚动展示最新一条调用（feature/stage-pipe-tool-cell-clients） 2026-09-14 20:09:57 +08:00
JianFeeeee
37d6796230 feat(gui+ohos): 同步阶段管道工具格「只滚动展示最新一条调用」 
WebUI 已改为工具格只露最新一条。桌面版与鸿蒙端是同一套运行态面板的
镜像，一并跟上，避免三端口径不一致：

- cmd/gui：renderRuntimePanel 工具格只渲染最新条目 + 本轮累计次数；
  overview 是整块 innerHTML 重建，故动画类由 state.toolFlash 单次驱动，
  避免任何重渲染都闪一下。
- cmd/ohos：RuntimePanel 工具格改为 latestEvent() + totalCount()，
  不再 ForEach 追加。已用 hvigor 实测 BUILD SUCCESSFUL。
 2026-09-14 20:09:57 +08:00
JianFeeeee
0493960985 merge: webui 阶段管道工具格改为滚动展示最新一条调用（feature/webui-tool-cell-scroll） 2026-09-14 20:07:33 +08:00
JianFeeeee
bc32fbbc98 feat(webui): 阶段管道的工具格改为滚动展示最新一条调用 
「工具」是循环格：一轮里可能调几十次工具/输出通道。此前每一次都追加成
chip，这一格被撑成一长条，反而看不出「现在在调什么」。改为固定一行的
滚动视口——只留最新一条，右侧给出本轮累计次数；新调用到来时旧条向上
滚出、新条滑入（morph 就地改文本不会重放 CSS 动画，故摘类 + 强制 reflow
+ 重加类）。并给 chip 名称加 .rt-chip-t 承接省略号，窄框不再硬切半截。

配套 TestStagePipelineToolCellShowsLatestOnly 钉住该口径。
 2026-09-14 20:07:29 +08:00
JianFeeeee
f3fa0e8f5b feat(ohos): 运行态面板 —— 阶段管道 + 中断队列（落在设置页二级明细顶部） 
接上一条腿：桌面版已同步，这次补鸿蒙端缺的运行态面板。
落点按之前的建议放在「设置 → 运行状态」二级明细页最前：明细卡回答「内核有哪些
东西、多少」，运行态回答「现在在干什么」，后者是进这个页面最先想看的。

## 新增

- `common/StageTrail.ets`：阶段轨迹单例（SSE 驱动）。由 ChatSse 的 stage 分支
  喂入，面板读取。**不并进 StatusStore**：轨迹来自 SSE 流，与 /status、/kernel
  的轮询是两条独立数据源，生命周期与失败模式都不同（SSE 断连不该让状态卡变空，
  状态轮询失败也不该清掉轨迹）。七阶段归并成五格，同阶段同一条累加计数，
  2.5s 无新事件自动回空闲。
- `components/RuntimePanel.ets`：等大表框面板。
  - 四个数字块（排队/中断/栈/子代理）
  - 阶段管道：每格 = 阶段名 + 本阶段本轮事件；当前阶段整框点亮
  - 中断队列：5 格（L4/L3/L2/L1 + 排队），级别色贯穿框头/槽位/描边；
    有积压整框描边点亮；排队队列虚线框区分（另一类别，不是另一优先级）
  - 格槽固定可见：深度为 0 时也有形状，不会剩一片空白

## 改动

- `StatusStore`：新增 `/runtime` 采集与 `RuntimeSnapshot`/`RuntimeQueue`
  （明细与运行态分开取、分开存）；失败保留上一次快照，旧后端无此端点时
  面板显示「运行态数据不可用」。
- `ChatSse`：stage 分支先喂轨迹，再管聊天侧角标。
- `SettingsPage`：`stageTrail.init()`。
- `StatusCards`：二级明细顶部渲染 `RuntimePanel()`。

## 关于宽度

模拟器（API 24，1256x2760 ≈ 360vp 宽）上 5 框一行会让「内核独占」这类标签被
挤成省略号，所以按项目已有的 `isWideScreen` 分两支：宽屏 5 框一行，手机 3+2
（补一个占位格保证框宽对齐）。两档都是等大框。

## 验证

- `hvigorw assembleHap` → **BUILD SUCCESSFUL**；`clean` 后全量重建，
  本次新增/改动的 6 个文件 **零 ArkTS 告警**。
- 未上机实测：本机签名 profile 无法授予 `ohos.permission.READ_PASTEBOARD`
  （module.json5 里已有的一项，非本次改动），`hdc install -r` 报
  `error: install failed due to grant request permissions failed`。
  没有为此卸载设备上的应用（会丢用户已存的连接配置），也没有改权限列表
  （属产品决定）。要上机的话，我可以临时去掉那一条权限打个一次性包验证。
 2026-09-14 19:05:46 +08:00
JianFeeeee
2163a7a092 feat(gui+ohos): 同步 WebUI 总览改版 —— 桌面版补运行态面板，两端补内核身份与开源许可 
WebUI 那边这几轮改完，桌面 app（Electron）与鸿蒙 app（ArkTS）要跟上。
先摸了底：**两个 app 此前都没有运行态面板**（阶段管道 / 中断队列），
所以这不是"移植"，是新做；emoji 图标两端本来就没有，无需处理。

## 桌面 app（cmd/gui/renderer）

1) 运行态面板（新）—— 与 WebUI 同一套设计语言：**等大表框**
   - 数据源 /api/v1/runtime（此前只拉 /status 与 /kernel）。
   - 四个数字块沿用本 app 的 statCard（排队/中断/栈/子代理）。
   - 阶段管道：5 个等大框，框内是本阶段本轮发生的事件 chip；
     当前阶段整框点亮。图标一律内联 SVG（含「工具会循环」标记）。
   - 中断队列：5 个等大框（L4/L3/L2/L1 + 排队）一行排开，
     级别名 16px/800、深度 26px/800、可见格槽（0 时也有形状）；
     有积压整框描边点亮；排队队列虚线框区分（另一类别，不是另一优先级）。
   - stage SSE 事件接上轨迹（rtTrailPush，同阶段同一条累加 xN），
     2.5s 无新事件回空闲。
   - 列宽 repeat(auto-fit, minmax(100px,1fr))：窄容器也保证 5 框一行，
     不出「4 个 + 1 个」的孤行。

2) 版本身份（修一个真缺陷）
   旧实现是 `s.version || "0.1.0"`：拿不到数据时**向用户展示一个不存在的
   版本号** 0.1.0。改为取 /kernel 的 build（-ldflags 注入的真实版本/commit），
   并在版本号下补一行「内核名 · commit」。

3) 开源许可卡（新）
   协议标识 + 协议全文 + 源码仓库 + §13 说明；网络条款按标识是否含 AGPL
   决定是否渲染，不硬写协议名。

## 鸿蒙 app（cmd/ohos/HomeAgent）

4) StatusStore 解析 /kernel 的 build：补 内核版本 / Commit / SDK 兼容 /
   构建时间 到「内核」分组；K_VERSION 统一成 v<版本>，新增 K_BUILD 广播
   「内核名 · commit」给摘要卡（版本号本身没有内核身份）。

5) 新增「开源许可」分组：许可协议 / 协议全文 / 源码仓库 / 网络条款说明。

## 验证

- 桌面：共享浏览器加载 renderer（桩掉 preload 桥）后喂真实形状数据渲染 ——
  版本卡 `v1.4.0+hotfix.f89e57a` + `HomeAgent · f89e57a`；管道
  `输入=输入 | 行动=思考 | 工具=qq_get_message x3 qq* | 输出=生成 | 结束=完成`；
  队列 `L4:0 | L3:3 on=3[active] | L2:2 on=2[active] | L1:0 | 排队:2 on=2[active]`；
  许可卡两个链接均为 target=_blank + rel=noopener noreferrer；无 emoji。
  node --check 通过。
- 鸿蒙：/opt/huawei/command-line-tools/bin/hvigorw assembleHap **BUILD SUCCESSFUL**。

## 未做（下一条腿）

鸿蒙端的运行态面板（阶段管道 + 中断队列）**还没有**。它比桌面端贵：
需要新组件（5 框管道 + 5 框队列）、把 /runtime 快照接入 StatusStore，
以及把 SSE 的 stage 事件从 ChatSse 的 sink 引到状态侧——后者是接口改动。
「状态」Tab 此前已被有意删除（并入设置页 + 二级明细），面板落点也要定
（建议放二级明细页顶部）。桌面的实现可直接作参照。
 2026-09-14 18:53:25 +08:00
JianFeeeee
0faf9fb4e8 style(webui): 队列/管道列宽下限收到 100px，消掉「4 个 + 1 个」孤行 
118px 时容器 540px（小窗口侧栏展开的宽度）只放得下 4 列，第 5 个框
落到第二行且后面四个位置全空 —— 正是「看着空」的那种观感。
收到 100px 后 540px 也能一行放下 5 个；配套给 .rt-qmeta 加 wrap，
窄框里「登记/抢占」两枚迷你条换行而不是撑破框。

五档实测（1400/1100/900/700/480）：1400/1100/900/700 都是 5 框一行
（200/140/100/120px），480 为 3+2；均无横向溢出，框内元素无越界。
 2026-09-14 18:45:36 +08:00
JianFeeeee
f89e57a732 feat(webui): 阶段管道与中断队列统一为等大表框，字体加大加粗 
问题：阶段管道是「小圆点 + 一条连接线 + 9px 小字」，中断队列是五行
「名字 | 进度条 | 元数据」的扁条 —— 两块都远小于旁边的 KPI 框，中断队列四级
全为 0 时四行几乎全是空白，既占高度又难看。

改法：两块统一成同一套视觉语言 —— **等大表框**（与 KPI 同一种骨架）。

阶段管道（.rt-pipe-row / .rt-pipe-cell）
- 5 个等大框，框内 = 图标 + 阶段名 + 本阶段本轮发生的事件 chip。
- 阶段名 9px/500 → 13.5px/700；图标 12px → 15px。
- 当前阶段整框点亮（accent 描边 + 淡底 + 内阴影），不再靠一个小圆点表意。
- 删掉圆点、连接线、滑块把手那套已死的 CSS（.rt-pipe-track/.rt-pipe-knob 等）。

中断队列（.rt-queues / .rt-qcell）
- 五行扁条 → 5 个等大框（L4/L3/L2/L1 + 排队），一行排开。
- 框头级别名 16px/800、深度数字 26px/800（原来深度只是行末一个小数字）。
- 级别色同时用在框头、点亮格槽、有积压时的整框描边 —— 一处配色贯穿。
- 排队队列无级别，用虚线框与四级中断区分（另一**类别**，不是另一优先级）。
- 保留可见格槽：0 时也有形状，不会变回一片空白。

列宽自适应：两块共用 repeat(auto-fit, minmax(118px, 1fr))，
118px 而不是 150px 是为了让 640–740px 容器（窄屏侧栏收起后的宽度）也能
5 个框排一行，不出现「4 个 + 1 个」的孤行。chip 补 min-width:0 以免撑破窄框。

顺带清掉一条无用的旧 .rt-chip 规则（与新规则重名且只被阶段事件用到）。

实测（现网 CDP，1400/1100/900/700/480 五档）：
- 1400/1100/700px：5 框一行（200px / 140px / 120px）；900/480px：换行且框仍等大
- 五档均无横向溢出
- 字号：阶段名 13.5px/700，级别 16px/800，深度 26px/800
- 注入一轮轨迹：输入=输入|行动=思考|工具=qq_get_message x3 qq*|输出=生成|结束=完成
- 注入 L3=3/排队=2：L3 描边 rgba(255,166,87,.55)、框头与点亮槽同为琥珀色；
  排队绿框；空的 L4 保持默认描边（首次读到的默认色是 0.25s 过渡中途，非 bug）
- chip 未溢出所在框；总览/侧栏/顶栏渲染文本无 emoji
 2026-09-14 18:38:08 +08:00
JianFeeeee
37924b295b feat(webui): 总览底部源码区改为独立的「开源许可」框（协议 + 全文 + 源码） 
此前总览底部只在 KPI 卡里挂了一行小链接（.ov-foot），既看不出受什么许可
约束，也看不出 AGPL 网络服务场景下的义务。现在单独成一张卡：

  开销许可
    许可协议     AGPL-3.0-only   → GNU 官方全文
    源码仓库     <source_url>    → 仓库
    网络服务条款（§13）：把修改后的版本作为网络服务对外提供时，
                        必须向使用者提供取得对应源码的途径。

内核侧（License 是新事实，不能只靠前端写死）：
- internal/meta：新增 License（SPDX 标识）与 LicenseURL，都可 -ldflags 覆盖。
  LicenseURL 默认指向 GNU 官方 AGPL-3.0 全文页 —— 与仓库托管方、分支名、
  文件路径都无关，换仓库/换分支不会失效。
- internal/sdk/status.go 的 BuildStatus：新增 License / LicenseURL 两个
  json 字段（additive，旧消费方忽略未知字段即可）。
  ❗注意 internal/sdk 不受公开接口冻结约束（docs/git-branching.md §六），
  本次未触碰 third_party/homeagent-sdk/sdk/。
- internal/agent/core/status.go：从 meta 填充。

前端：
- 骨架里 .ov-foot 换成独立的 <div class="card" id="ov-legal">（放在 KPI 卡之后）。
- 网络条款那一段按许可标识是否含 AGPL 决定是否渲染，不硬写协议名。
- 内容对一次构建是常量，沿用 __html 比对，填一次后不再重建（不引入闪烁）。

验证（现网 1400x920，CDP 实测）：
- /api/v1/kernel 的 build 现在带 license="AGPL-3.0-only"、
  license_url="https://www.gnu.org/licenses/agpl-3.0.html"
- 卡片为真框：class=card、border 1px、radius 14px；总览结构 = rt-panel | card | ov-legal
- 两个链接均为真 <a>，target=_blank + rel=noopener noreferrer
- updateOverview() 再跑一次，卡片子节点身份不变（不重建、不闪）
- 回归：KPI 版本副行、阶段管道 5 节点/5 列/6 SVG、队列 5 行×5 格 均正常
- 无横向溢出；总览/侧栏/顶栏渲染文本无 emoji
- go vet 干净；agent/core、plugins/webui、plugins 全量测试通过
 2026-09-14 17:48:54 +08:00
JianFeeeee
bead5746c3 feat(webui): 总览显示内核身份、图标全 SVG 化、队列改格槽、阶段管道下方按阶段列事件 
四个问题一起改（都出在总览/内核页的展示层，不动内核逻辑）：

1) 内核版本不再"看不见"
   - 36b577b 改图标 KPI 时把 kernel_name 丢了，只剩一个 "v1.4.0"，分不清
     是哪个内核、哪次构建。现在 KPI 值给版本号，下面补一行副行
     「HomeAgent · <commit>」（.ov-sub）。
   - 内核页此前**完全没有构建信息**，现在补一张「构建」卡：内核名/内核版本/
     Commit/构建时间/SDK 兼容/源码链接（AGPL §13 的入口页）。

2) 任何位置都不再用 emoji/符号字符充当图标
   - 新增 RT_ICO（纯内联 SVG，24x24 / currentColor），替换：阶段节点的循环
     标记（原 ↻）、轨迹 chip 的工具/输出标记（原 ⚙/⇥）、"立即运行"（原 ⚡）、
     工具卡与思考卡的下拉箭头（原 ▾）。
   - CSS 注释里的同类字符一并去掉。

3) 队列不再"空着只有文字"
   - 原来画的是宽度百分比进度条：深度为 0 时宽度就是 0，五行只剩文字。
     改成 rtSlots 的「车位」式格槽（至少 5 格、最多 16 格，按全场最大深度
     缩放），0 时仍有可见形状，占用多少一眼可数；超出格数时给 +N。
   - 修掉一个真实的 DOM 结构错误：第五条「排队」队列被写在 .rt-levels 闭合
     **之后**，且后面多一个 </div>，多出来的闭合标签会提前关掉祖先节点、
     把整块布局撞歪。现在它回到容器内。

4) 每一步管道的事件显示在管道下方对应阶段列里
   - 原来是一条拍平的 chip 序列，看不出"这件事发生在哪个阶段"。
     现在 .rt-pipe-cols 与上面的阶段节点共用 5 等分栅格，事件按 g（阶段组）
     分列落位；实测列中心与节点中心偏差 ≤ 2px。
   - 轨迹覆盖全部阶段（输入/思考/工具/输出/完成），同阶段重复的同一条
     累加 ×N 而不是刷屏（rtTrailPush）。空列显示一个弱化的「无」。

验证（现网 1400x920，CDP 实测）：
- 版本 KPI = v1.4.0+hotfix.0fd4fb1 / HomeAgent · 0fd4fb1；内核页构建卡齐全
- 注入一轮轨迹：col0=输入 col1=思考x2 col2=qq_get_message x3/qq/cmd_run
  col3=生成x2 col4=完成，active 节点=工具，×N 计数正常，3 个 chip SVG
- 队列 L3=3/5、排队=2/5 点亮，L3 取到琥珀色 rgb(255,166,87)
- 页面无横向溢出；总览/侧栏/顶栏/内核页渲染文本无 emoji
- go vet 干净，internal/plugins/webui 测试通过
 2026-09-14 17:40:54 +08:00
JianFeeeee
21db84e8dc fix(webui): 拓扑 +N 提示改用输出带顶部锚点，修提示串行 
无输出通道的 agent 那条带上 outTop 在渲染时才确定，而提示行仍在用
循环变量 y（已累加到别的带），所以「+N 更多」会跑到隔壁带上。
改用该带自己的 outTop，并把基线从 +13 收到 +11（紧贴最后一行）。
 2026-09-14 17:40:46 +08:00
JianFeeeee
0fd4fb1f7a fix(webui): 拓扑按实测容器宽布局 + 字号/截断，修间距失衡与文字难读 
三处实机问题：
1) viewBox 固定 640 而容器 ~920，浏览器按 'meet' 把内容顶到左上、右侧空出一大片
   —— 观感就是「间距不对」。改为 viewBox 宽 = 实测容器宽、width 用像素值，
   缩放恒为 1（已用 getScreenCTM().a 验证）。
2) 文字全是 9-11px + 低对比度硬编码色（#8b90a5）→ 难读。字号提到 10.5-12.5px，
   fill/font-size 改走 .tp-* 类，颜色交给 --text-primary/--text-muted 主题变量。
3) 列短的一侧原来顶在带上半、节点居中，连线又长又歪；长通道名还会溢出到邻居身上。
   现在两列在带内各自居中、节点块高度参与带高计算（单行带不再把节点名压到下一条带），
   长名按估算宽度截断加 …，完整名放 <title> 悬停可见。
另：rtSpark 用的 _rtEdgeIn/_rtEdgeOut 键与取值方式未变，光点动画照旧。
 2026-09-14 16:51:41 +08:00
JianFeeeee
5ea87a498a chore(vendor): 同步 qq 插件权限身份绑帧修复（sdk cfa72df） 2026-09-14 16:45:17 +08:00
JianFeeeee
9eebd96ab7 fix(core): 插件拒绝工具时把 ctx.Response 的理由透给模型 
before_toolcall 的 ctx.Response 是插件写的**拒绝理由**，但工具结果被写死成
「工具 X 已被插件拒绝」，理由从不到达模型——模型于是不知道能不能重试，
会反复重试被拒的调用。抽出 denialResultText 并在有理由时原样透出。
 2026-09-14 16:45:04 +08:00