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
513 Commits 6 Branches 27 Tags
37924b295b440f4d2d59a291e4b490409534f44e
Commit Graph

163 Commits

Author SHA1 Message Date
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
c252915083 feat(webui): 阶段管道改「循环 + 本轮轨迹」，区分工具/输出调用；再砍总览文字 
jianf：阶段管道像无记忆的单向滑块，但一轮里会多次 toolcall、也可能多次输出；
且没区分 output_* 调用与普通工具调用；总览仍有一大坨文字。

- 阶段管道不再是单向滑块：#
  画成 输入 → 行动 ⇄(工具↻) → 输出 → 结束 的循环结构，当前阶段高亮；
  下面用一排 chip 记**本轮真实发生过的序列**（on_input 重置、before_toolcall 追加、
  after_output 收尾，最多 24 条）。工具调用会反复出现，循环因此可见。
- 区分调用类型：普通工具 chip 前缀 ⚙（青），output_* 输出通道调用前缀 ⇥（accent 色），
  两者配色与图标都不同。
- 文字再收缩：删掉「累计：入队/执行/抢占/挂起/背压」整行；队列标签由
  「L4 内核独占…」压成 L4/L3/L2/L1/排队（原描述进 title）；各段标题压成
  「队列」「栈」「拓扑」；KPI 块标签压成 排队/中断/栈/子代理。

顺带（同类问题）：CLI /stop 是人在终端当场下的指令，优先级由默认 L1 提到 L3。
 2026-09-14 16:31:37 +08:00
JianFeeeee
36b577bff8 fix(webui): 总览改静态骨架 + 图标 KPI，彻底去掉整页重建的闪烁 
jianf：仍严重闪烁；应彻底摒弃增量重建，用动态图标 + api 数据展示；主页文字太多。

- renderOverview 从「每次 innerHTML 重建整页（含运行态面板）」改成**首帧建一次
  静态骨架**，之后 renderAll（每 15s 一次）只 updateOverview —— 只写 textContent
  与类名，一个节点都不重建。实测连续两次 renderAll 后 #ov-kpis / #ov-status /
  #rt-panel 仍是同一批 DOM 节点，这是"不再闪"的直接判据。
- 主页文字大幅收缩：删掉「系统概览 / LLM 状态 / 记忆状态 / 运行时」四张 kv 文字卡，
  改成一排 8 个图标 KPI（状态/运行/插件/版本/LLM/记忆/文档/运行时），状态用彩色
  圆点表达，其余只留数字 + 两字标签。
- 运行态面板不再被 renderOverview 清空（去掉 _rtSig=null 与重建），保持连续更新。
 2026-09-14 16:16:14 +08:00
JianFeeeee
97111778a9 feat(webui): 数据查询 API + 前端 keyed 对账，去掉「局部重建」的闪烁 
jianf：局部重建的闪烁几乎消不掉，应暴露数据查询 api，前端轮询后增量更新视图，
聊天记录也用这套。

后端（数据查询 api）：
- ChatMsg 增加 seq（服务端单调递增、随记录落盘）；老记录加载时补 1..n，重启不重编号。
- /api/v1/chat/history 增加 after=<seq> 增量通道：只回 seq 更大的消息，返回 last_seq
  作下次游标；一批超 limit 时回**最旧**的一批（回最新会把被挤掉的旧消息永久漏掉）。
  普通响应也带 last_seq，客户端首次全量后据此初始化游标。
- 测试 TestChatHistoryIncrementalAfterCursor 钉住「不重不漏 + 截断停在返回的最后一条」。

前端：
- 新增通用 morph()：按「子节点位置 + nodeName」递归对账 DOM，同名节点复用、只同步
  变化的属性与文本。运行态面板的 put() 由 innerHTML 重建改为 morph —— SVG 圆环、
  队列条、数字块这些未变节点不再被替换，CSS 过渡与动画不再从头播。
- 聊天列表改用 keyed commitChatList()：按 data-key（服务端 seq / 本地临时 key）对账，
  未变消息节点一个字节都不动，只替换真正变化的那条。
- syncChatFromHistory 改走游标：pollChatIncremental() 用 after 拿增量 + tail=1 探尾部
  原地更新（工具调用/最终文本是原地改的，不产生新 seq）；聊天页可见时 3s 轮询。
 2026-09-14 15:56:27 +08:00
JianFeeeee
f722498dba feat(webui): 默认配色改黑白 + 设置页新增「外观」区 
jianf：默认配色太花，且配色要能在设置页调。

- 新增 mono（黑白灰）配色并设为默认：未选过配色的 localStorage 一律
  data-color=mono。黑白下连拓扑归属配色也走灰阶，不至于只剩一张彩图。
- accent 的所有硬编码 rgba(255,127,172,x) 收敛成语义变量 --accent-rgb，
  各配色块（sakura/cyan/violet/emerald/amber/blue）各自声明自己的 rgb，
  于是换配色时阴影/描边/阴影辉光一起换，不再残留粉色。
- 设置页新增「外观」区（侧栏最前）：主题（浅/深）+ 7 个配色圆点 +
  背景图 URL/模糊。原先只有侧栏底部一个调色盘图标，找不到。
- 切配色时强制重画运行态（置空 _rtSig），否则拓扑会停在旧色。
 2026-09-14 15:44:17 +08:00
JianFeeeee
e4d69fa140 feat(webui): 总览改版 —— 阶段管道滑块 / per-agent 负载环 / 通道→agent 拓扑与光点 
总览页此前是一堆数字与文字块，看不出「这一轮走到哪、谁忙、消息从哪进哪出」。
本次把运行态面板改成以图形为主：

- 阶段管道：七阶段滑块，由 SSE stage 事件驱动，当前阶段高亮、滑块滑过去；
  一轮结束（after_output 或 2.5s 无事件）自动回到空闲，不做假动画。
- 队列与中断栈：沿用五条进度条（L1–L4 + 排队），中断栈补一条深度进度条。
- Agent 拓扑：改成「每 agent 一条横带」——左 inputch、中 agent 节点（圆环 = 负载）、
  右 outputch，连线即路由；删掉旧的「归属框 + 单个内核盒」画法（看得出哪个子接了哪条输入）。
- 光点动画：channel_input（新增轻量 SSE 事件）沿 inputch→agent 连线跑；
  agent_output 沿 agent→outputch 连线跑。用 SMIL animateMotion，不需要 rAF 循环。
- 负载：由该 agent **自己的**调度器积压（排队 / 四级中断 / 中断栈）按级别加权折算，
  环形图展示。为此把驻留子的调度器积压透出到状态面（SDK 纯追加字段）。

后端：sdk.ResidentStatus / core.ResidentInfo 增加子 agent 调度器积压四项；
WebUI SSE 增加 channel_input 轻量事件（只带通道名与 agent id，不带正文）。

顺带收口对话区视觉（页签改分段控件、消息间距/气泡区分、输入区分隔线）。
 2026-09-14 15:33:23 +08:00
JianFeeeee
0fda210e8b feat(webui): 视觉重做第一轮 —— 侧栏图标化、顶栏标题化、卡片/行/按钮收口 
反馈是「丑死了」，没有具体项，所以按「哪儿在制造廉价感」逐条改：

1. **侧栏只有文字**：6 个导航项各加 24×24 stroke 图标（currentColor，随选中/hover 变色），
   10px 间距、13.5px/500 字重、圆角 10px 的药丸命中区；品牌字改 sakura→frost 渐变。
   → 空荡荡的 16rem 栏终于有了骨架。

2. **选中态把文字整体右推 + 发光文字**：原来用 `border-left: 3px` 画选中条，
   hover 时整行抖 3px；还加了 text-shadow 光晕。改成 `box-shadow: inset 2px 0 0`
   （不占布局）+ 取消光晕 + 选中加粗。这类「一像素级不稳」是廉价感的主要来源。

3. **顶栏只有一行灰字面包屑**：把当前页做成 15px/650 的标题色，面包屑碎片
   压到 12.5px 且降透明度；顶栏 48→56px。页面总算有「入口」。

4. **卡片 hover 整页上下浮**：`.card:hover` 去掉 `translateY(-1px)`（十几张卡一起
   浮，视线扫过像在抖），只提亮阴影与描边；padding 20→22、卡片间距 16→18。

5. **卡片标题没有章节信号**：`h2` 前加 3×14px 的 sakura→frost 渐变短竖。

6. **kv-row 是文字墙**：flex + 固定 180px 键列 → grid `minmax(110px,180px) 1fr`，
   行高 8px、负外边距 hover 高亮、末行去分隔线、数值 `tabular-nums`（端口/计数上下对齐）。

7. **满屏药丸按钮**：`.btn` 圆角从 999px 收到 10px（与卡片同一套圆角），
   padding/font 微调；`.btn-sm` 11→11.5px 提升可读性。

8. **内容区靠左铺满**：`.container` 居中 + `max-width: 1240px`（超宽屏摊满整个
   屏幕是「后台模板」的典型观感）。

i18n 有个坑：切语言那段是 `el.textContent = …`，所以 `data-i18n` 必须从 `<a>` 挪到
内层 `<span>`，否则切一次语言图标就被抹掉。实测 ZH→EN→ZH 图标都在。

验证：go build/测试绿（webui + sdk + agent + plugin）；真机 1440×900 六页截图对比
（侧栏图标、渐变品牌、标题竖条、grid 行、居中内容区均生效）。
 2026-09-14 14:29:17 +08:00
JianFeeeee
cdb2ea2207 polish(webui): 拓扑图只在容量非默认时写数字（去掉十几行「默认」文字） 2026-09-14 11:24:34 +08:00
JianFeeeee
e8d7bb4c06 feat(webui): 通道归属合并进拓扑图，整张图改 SVG（少文字、多图形） 
上一版把「通道分配（按归属）」单开一段，等于把同一件事拆成两张表——
而通道属于谁是**拓扑的一部分**（左边这些输入口分别被谁接管），拆开反而
看不出关系。按用户要求合并，并整体改成图形化：

- 整张拓扑用 SVG：左侧按归属画出输入通道容器（根=青色虚线框，驻留子=彩色
  实线框并标轮次/上下文满），→ 汇集母线 → 内核 → 输出母线 → 右侧输出通道。
  **连线即路由**。
- 信息全部改用图形编码：归属=容器/配色、容量=节点内细条（默认容量不画填充）、
  输出能力=五个彩色圆点（text/file/image/audio/structured）。
- 文字降到最少：去掉四个数字块的副标题、排队队列那行只留 "FIFO"、
  通道行不再写"回程由来源决定"这类说明。
- 段名改为「通道拓扑（连线即路由；左框 = 归属）」。

验证：node --check 通过；go build ./... 干净；webui 测试全绿。
 2026-09-14 11:22:20 +08:00
JianFeeeee
75f377fd4d fix(remotedevice): 心跳 pong 忘了 Flush —— 修「设备通道每 60 秒掉线重连」 
真因（实测定位）：服务端 writePong 只调 writeFrameHeader，**不 Flush**。
pong 只有两个字节，且设备空闲时没有任何别的写会顺带把 bufio 缓冲刷出去 ——
于是 pong 永远留在服务端缓冲里。

链路：客户端每 30s 发一个 ping（pingLoop）→ 服务端算出 pong 却没发出 →
客户端的读循环设的是「2 倍 ping 间隔」读超时（默认 60s）→ 每 60 秒准点
i/o timeout → 桥断开 → 3s 后重连 → 服务端 markOffline 注销 outputch，
重连后再注册。

生产日志就是这个指纹（online :20 → offline 下一分钟 :20 → 重连 :23，
连续数小时无一次例外）；面板上表现为设备通道/工具凭空消失又出现，
/devices 列表跟着闪。

改法：writePong 复用 writeFrame（它 Flush）。另把客户端读循环退出时的
静默 return 改成带错误与 opcode 的日志 —— 此前断线真因在设备侧完全不可见，
只能靠对端日志倒推，正是这次排查一开始卡住的地方。

回归用例 TestWSPingGetsPongWhileIdle：只发一个 ping，随后什么都不发，
要求 2s 内必须收到 pong。**反向验证过**：把修复改回 writeFrameHeader，
用例即以 `read tcp ...: i/o timeout` 失败（与生产症状一致）。
 2026-09-14 11:15:21 +08:00
JianFeeeee
8756f8d77f fix(webui): 通道归属把「根 agent id」与驻留子分开（根不再被标成「驻留子 main」） 
实测（创建一个驻留子 uitest 并把 timer 划给它）暴露的归类错误：
inputch 的 owner 在登记表里可以是**根 agent 自己的 id**（如 "main"）——
child/<id> 这条就是 owner="main"。前端只按「owner 非空」判为驻留子，
于是根自己那条被标成「驻留子 main」，而同一条通道在 residents 里根本不存在。

改法：
- /api/v1/runtime 补 agent_id（根 agent 的 id）；
- 前端把 owner == 根 id 与 owner == "" 归一成同一组「根 agent / 内核默认」，
  只有既非空又非根 id 的才是子容器。
 2026-09-14 11:08:27 +08:00
JianFeeeee
d502fc1bf5 fix(webui): 运行态面板逐段更新（真修「一闪一闪」）+ 补第五条排队队列 
1) 上一版只做了整体签名缓存，实测仍会重建：设备通道列表本身就在来回变
   （远程设备通道 11→9 条），签名一变就整块 innerHTML，没变的段落（含条
   transition）也跟着推倒重来——视觉上仍是闪。改法：外壳只建一次，之后
   **逐段**（tiles/levels/stack/owners/topo）比较 HTML，只替换真正变了的那段。

2) 设计是「四条中断队列（L1–L4）+ 一条排队队列」= 五个队列，面板只画了四条：
   排队输入这条线在运行态里凭空消失。补第五行「排队（无级别）」，用中性色 +
   虚线分隔（它不是优先级，而是另一**类别**），并把它计入条形归一化基准。
   段标题从「中断队列（按级别）」改为「队列（四级中断 + 排队）」。

3) 顺带把累计计数（入队/执行/抢占/挂起恢复/拒绝/背压）显式列在数字块下方——
   背压是新指标，之前只能看接口看不到面板。

验证：node --check 通过；go build ./... 干净；webui/core/sdk 测试全绿。
 2026-09-14 11:03:37 +08:00
JianFeeeee
43536ba326 fix(webui): 运行态面板不再闪、通道分配带归属（含驻留子）、改图形化 
三个用户可见问题，逐个说明根因与改法。

1) 首页「一闪一闪」——运行态每 3s 轮询一次，renderRuntime 无条件重建
   #rt-panel 的 innerHTML：数据没变也把整块 DOM（含各级条的 transition）
   推倒重来。改法：缓存数据签名（**不含 uptime**——它每秒都变，带上等于没缓存），
   签名相同直接 return，一个字节都不动。另：renderOverview 会整块重建
   #rt-panel（面板本身是空的），所以那里必须让签名失效，否则空面板填不上。

2) 通道分配只显示内核/根 agent，看不见驻留子——根因是状态面只暴露了设备能力
   （KernelStatus.Channels，来自 iom.ListChannels），而「这条输入归谁」是
   ChannelRegistry 的属性（InputChannel.Owner/Capacity/Output），从未出过内核。
   而登记表本来就是根 agent 与驻留子**共用同一份**，所以数据一直都在，只是没画。
   改法：KernelStatus 新增 InputChannels（+ sdk.InputChannelInfo），
   /api/v1/runtime 带出 input_channels；前端把它按 owner 分进「归属容器」，
   驻留子即使一条 inputch 都没划到也照样出现在图里（否则"子存在但看不见"
   与"子不存在"无法区分），并显示其 allowed_outputs / 轮次 / 上下文满标记。

3) 「这些信息明明可以图形化」——四级中断的登记/抢占由纯文本改成并排迷你条；
   通道分配用归属容器 + 容量滑块（轨道/填充/把手/读数），并把回程通道、
   注册插件做成胶囊标签。设备能力拓扑（原有）保留。

验证：go build/vet 干净；go test ./internal/agent/... ./internal/plugin/...
./internal/sdk/... ./cmd/... 全绿；node --check dashboard.js 语法通过。
TestRuntimeEndpoint 扩展为同时钉住 input_channels 的归属与「驻留子划走的那条」。
 2026-09-14 10:55:45 +08:00
HomeAgent Agent
1ce3a917a5 feat(status+webui): 运行态图形化 —— 排队/四级中断队列/中断栈/驻留子/通道拓扑 
需求：首页不该只有文字，要能一眼看出内核在忙什么——排队消息数、各级中断
排队与中断栈、驻留子 agent 数量；这些要向**内部 SDK 暴露接口**，供 WebUI 等应用
展示；通道划分也要能画出来。

## 一、内核状态面（internal/sdk，内部 SDK，不受公开 SDK 冻结约束）

* SchedulerStatus 补：
  - interrupt_queues[5]：**四级中断队列各自的深度**（下标即级别 1..4，下标 0 恒 0，
    这样 level 能直接当数组下标用）。此前只有 pending_interrupts 总数，
    看不出"堵在 L1 还是 L4"——四级是抢占优先级，堵在哪级是完全不同的运行状态。
  - immediate：刚抢占成功、下一个安全点立即运行的那个中断（此前完全不可见）。
  - suspend_frames：中断栈的帧（栈底→栈顶，只给任务标识），depth 之外还能看出
    "谁被谁打断"。
  - interrupts_by_level / preempts_by_level：各级累计登记数与抢占成功数。
* KernelStatus 补 residents（驻留子运行时视图：状态/轮次/上下文已满/输入通道/允许输出）。
  刻意**不带**每个驻留子的 inputch 登记明细——状态面会被反复轮询，明细会让
  每次 /status 背上几十 KB；只给表大小，要明细走专门接口。
* ChannelInfo 补 direction(in/out/io)、description、tools、output_caps、caps_text。
  此前 collectKernelStatus 只透传 Name/Type，把描述/工具/能力**全丢了**，
  前端只能画出一排光秃秃的名字。

## 二、WebUI

* 新增只读 `/api/v1/runtime`：只回运行态三件事（scheduler/residents/channels），
  实测 **1.0KB**（/kernel 是 30KB 级）——所以能 3 秒轮询做"实时"感，
  而不必反复拉全量状态。
* 首页新增「运行态」面板（纯 CSS + 内联 SVG，前端仍无构建链）：
  - 四个数字块：排队任务 / 待处理中断 / 中断栈(深度/上限) / 驻留子 Agent，带占比条；
  - 四级中断队列条形图：每级"深度 · 登记/抢占"，四级语义**照抄内核**
    （L4 内核独占 / L3 交互 / L2 消息 / L1 后台），不自己起名字；
  - 中断栈层叠图（栈顶在上）+ ⚡立即运行项；
  - 通道拓扑：输入通道 → 内核 → 输出通道，双向通道两侧都出现，能力以胶囊标签显示。
* 3 秒轮询只在总览页可见时才发请求；切回总览时 renderAll 会立刻补一次。

## 验证

* 新增 TestSchedulerStatusExposesLevelsAndStack（四级队列/立即项/栈帧/各级计数映射，
  并断言"未使用的级别必须为 0"与"下标 0 恒 0"）、TestChannelInfoCarriesTopology、
  TestRuntimeEndpoint（形状 + 不携带 tools/plugins + 无状态源时 503）。
* go build / vet / agent+core+sdk+plugin+webui 全量测试绿。
* 真实浏览器实测（CDP 驱动，注入运行态样本走真实渲染路径）：
  数字块 [3, 5, 2/4, 2]；四级条 L4=1/L3=2/L2=1/L1=1 与数据一致；
  栈帧按"栈底→栈顶"渲染且标出栈顶；通道左右分列、io 通道两侧都出现。
 2026-09-14 09:05:14 +08:00
HomeAgent Agent
c0e9dc1818 fix(webui): 聊天记录不再"每次都发完整记录"，并修掉视口跳顶 
两个都是你指出的症状，都定位到了具体代码路径。

① 「每次都发完整聊天记录」
   a) API 缺省值错了：/api/v1/chat/history 的 limit 缺省是 0 = **不限制**，
      于是任何不带 limit 的调用每次都拿到整段记录。实测（126 条）：
      不带 limit 635,297 字节；现在默认只回一页 180,668 字节。
      显式 limit=0 仍可整取（逃生口）。WebUI/GUI 本来都带 limit，不受影响。
   b) 前端 30s 轮询（以及每次 SSE 报错）都直接拉一页 40 条：
      浏览器实测单次 180,813 字节。现在先做"尾巴探测"（limit=1，362 字节），
      尾巴一致就直接跳过；不一致才拉整页。

② 「聊天记录会跳到顶部」——两条会导致视口丢失的路径都堵上
   a) syncChatFromHistory 在"找不到重合点"时直接 `state.messages = serverMsgs`：
      服务端只回一页，而本地可能已经向上翻了好几页；一覆盖，容器立刻变矮，
      视口被夹回顶部，用户翻过的旧消息也凭空消失。现在只在服务端页**不短于**本地时
      才整体替换。
   b) renderChat 全量重建 innerHTML 后，仅在粘底时滚到底；非粘底（用户正在向上读）
      时位置没人管。改为重建前记住 scrollTop、非粘底时原样还回去。

浏览器实测（CDP 驱动真实页面，126 条历史）：
  * 15s/30s 定时器跑满 40s：聊天区滚动位置 **0 px 变化**，未跳顶；
  * 期间 chat/history 请求：limit=1 × 2（各 362 字节）+ 首屏 limit=40 一次；
  * 控制台无报错；新增消息后轮询仍能正确并进来（尾巴探测→拉整页→合并）。

测试：新增 TestChatHistoryDefaultIsPaged（默认一页 / has_more / limit=0 整取 / 显式分页）。
顺带修测试串味：迁移用例往 os.TempDir() 写共享历史文件，会让其它用例的
NewHandler 加载到脏历史（表现为条数多 1）；现在各用例用自己的临时文件。
 2026-09-14 08:06:16 +08:00
HomeAgent Agent
764939ed90 refactor(webui): dashboard.html 6637 行拆成「外壳 + 样式 + 脚本」 
前端刻意没有构建链（纯 CSS + Vanilla JS，go:embed 进二进制），所以拆法是：
外壳 dashboard.html 留 {{DASHBOARD_CSS}} / {{DASHBOARD_JS}} 两个占位符，
init() 启动时把两份资产原样填回去 —— **发出的 HTML 与拆分前逐字节一致**，
但 6637 行的单文件变成三份，便于编辑与评审。

  dashboard.html   168 行   外壳（head/body 结构 + 两个占位符）
  dashboard.css   2099 行   样式
  dashboard.js    4371 行   脚本

逐字节校验（三重）：
  * 组装结果 sha256 == git HEAD 里拆分前的 dashboard.html；
  * 真实实例 GET /（带 API key）返回体 sha256 同上：0ef14b49…c053；
  * 新增 TestDashboardAssetsSplit：占位符必须存在、样式/脚本不得再内联回外壳、
    组装结果不得残留占位符且必须含样式与脚本特征串。

按行号切片时踩过一次坑并已修正：`</style>`/`</script>` 两个闭合标签被切掉
（正好少 27 字节）——正是因为当时少了逐字节校验，现在把它固化成断言。
 2026-09-14 07:17:23 +08:00
HomeAgent Agent
4cbfdc970c perf(webui)+feat(config): 聊天记录写盘节流 + 配置库空闲页回收 
两条都是我上一封里点出、你说继续的问题。

① 聊天记录：每条消息都整段重写 → 节流合并写
   原来 persistChatLocked 每次变更就整段重写记录文件，而一轮对话会触发多次
   （用户消息、每个工具事件、收尾消息）。200 条上限下文件可达数 MB，单轮就能
   放大出几十 MB 写。文件里还留着一个 chatSaveThrottle=3s 常量——声明了但从未
   被使用（疑似上次 revert 的遗留），等于节流从来没生效。
   现在：persistChatLocked 只置脏 + 唤醒写盘协程；chatPersistLoop 去抖
   chatSaveThrottle(3s)、并以 chatSaveMaxDelay(10s) 兜底（持续输出也不会无限拖延）；
   写盘前把快照拷出来，**不持 chatMu 做文件 IO**；写失败重新标脏下轮重试。
   插件 Stop 里调 Handler.Close()：停协程 + 强制落最后一次（幂等），否则丢最后一轮。

   实测（临时实例，连发 3 条消息）：3s 窗口内记录文件**尚未创建**（节流生效）；
   SIGTERM 后文件出现且 6 条（3 用户 + 3 助手，无 LLM key 故为错误回复）全在
   ——关停落盘没丢。

② config.db：SQLite 的 DELETE 不缩文件 → 空闲页够多时 VACUUM
   新增 ConfigRegistry.MaybeCompact(minFreeBytes, minRatio)：空闲页 >= 1MB 且
   占页数 >= 25% 才做一次 VACUUM，避免每次启动都重写整库。库里是 WAL 模式，
   VACUUM 之后必须再 wal_checkpoint(TRUNCATE)，否则主库文件看着没变小。
   调用点放在插件加载**之后**（大值的搬走/删除发生在插件 Start 里，之前调没意义）。

   实测（一个刚被搬走 5MB 聊天记录的实例）：
     freelist 1288 页 × 4096B；启动日志「配置库已压缩: 5394432 -> 118784 字节」
     config.db 5,394,432 → 118,784 字节；记录文件 5,279,491 字节完好未动。

测试：TestChatPersistenceIsThrottled（节流窗口内不写盘 + Close 必落盘 + Close 幂等）、
TestMaybeCompactReclaimsFreePages（删大值后文件确实变小 + 数据完好 + 阈值不达标时不白做功）。
 2026-09-14 07:14:55 +08:00
HomeAgent Agent
642e1c39b1 refactor(webui): handler.go 2993 行按资源拆成 11 个同包文件 
拆法：按「资源面」搬家，每个顶层声明（func/type/var/const）整体搬到目标文件，
声明体一字未改，各文件按实际用到的包重新生成 import。文件头加一行说明本文件负责哪一面。

  handler.go              骨架：嵌入前端资源、Handler/构造、路由表、鉴权会话日志中间件、静态页
  handler_chat.go         对话面：消息模型与内存历史、SSE 事件订阅、对话/历史接口
  handler_upload.go       上传面：handleChatFile / handleUploads / 中断对话
  handler_memory.go       记忆面：图/文档/文本记忆、知识库、LLM 源、变更追踪
  handler_agents.go       内核与代理面：状态、kernel、人格、代理/快照/回滚
  handler_settings.go     设置与插件面：配置读写、插件列表详情（含 pluginmgr 反代）
  handler_terminal.go     终端面：终端会话、终端接口、命令历史
  handler_sse.go          SSE 环形缓冲（断线重连补发）
  handler_openai.go       OpenAI 兼容面：/v1/chat/completions
  handler_device.go       设备网关反代（HTTP + WS 升级透传）
  handler_files.go        /files/ 与 /uploads/ 下载

零漂移校验：拿重构前的 handler.go 与新 11 个文件逐行比对（忽略空行、package/import 头），
**丢失行 0**；新增行恰好是 11 个文件头注释（14 行）。

顺带修掉 import 里两处假使用：handler_openai 的 sdk 只作为 Handler 字段名出现（h.sdk.），
handler_settings 的 fmt 只出现在注释里 —— 都从 import 里去掉。

验证：go build ./... / go vet / webui+config+sdk 测试全绿；
起真实实例（沿用已有 data 目录）后 /status /settings /chat/history /plugins /terminals
/kernel /memory /config /login 全部 200，设置在注入 5MB 历史的情况下仍是 33,921 字节。

最大文件从 2993 → 706 行（handler_chat.go）。
 2026-09-14 07:03:47 +08:00
HomeAgent Agent
c4998bb102 feat(webui): 聊天记录改为独立文件存储（位置可配）+ 存量自动迁移 
起因：聊天记录原先作为插件配置项 plugin.webui.chathistory 存在 config.db 里，
带来三个后果（都在生产实例上实测过）：
  1. 整段记录 5,176,016 字节会被 GET /api/v1/settings 当普通配置项整块返回；
  2. 每来一条消息就把整段记录重新 marshal 后写回 config 表，而那次写要拿
     config registry 的全局写锁 —— 消息频繁时所有配置读写都被拖着排队；
  3. 位置不可配（想放独立挂载盘只能改整个 data_dir）。

改动：
* 新增 internal/plugins/webui/history.go：
  - historyStore：默认 <data>/webui_chat_history.json，写盘用同目录 tmp+rename
    原子替换，崩溃不会留半截 JSON；读失败/JSON 损坏按空历史处理并告警
    （聊天记录不是关键数据，不该让它拖垮 WebUI）。
  - resolveHistoryFile：插件设置 history_file > 默认路径；相对路径按 data 目录
    解析（可指向独立挂载盘），data 目录未知时落到系统临时目录而不是进程 CWD。
  - LoadWithMigration：文件为准；文件为空而老配置项有内容时，把记录搬到文件、
    搬成功才删配置项（删不掉就保留并告警，不丢数据）；文件已有数据时顺手清掉
    上次没删干净的遗留键。
* 新增插件设置项 history_file（设置页可见可改）：留空 = 默认路径。
* handler.go：chatHistory 的读/写改走 historyStore，不再碰 settings；
  顺带把「写失败静默忽略」改成告警。

存量迁移实测（拿仍持有 5,271,690 字节老记录的实例跑新二进制）：
  日志：聊天记录已迁移到独立文件 .../webui_chat_history.json（1300 条），并从插件配置表移除
  迁移后：config_webui 里 chathistory 行数 = 0；记录文件 5,279,491 字节
          GET /api/v1/settings = 33,921 字节（迁移前 8,244,108）
          GET /api/v1/chat/history 正常（从文件读回 1300 条里最新的 3 条）

新增测试：TestResolveHistoryFile、TestHistoryStoreMigratesFromConfig（含二次加载
不重复迁移 + 损坏文件不 panic）、TestHistoryStoreSaveIsAtomicAndRoundTrips。
 2026-09-14 07:00:07 +08:00
HomeAgent Agent
0beb389223 fix(webui): 设置接口不再吐内部数据；--webui 覆盖生效；端口占用不再静默成功 
三处实测确认的缺陷：

① 设置接口整块吐出聊天记录
   plugin.webui.chathistory 是 webui 自己持久化的整段聊天记录（生产实例
   实测 5,176,016 字节），躺在插件配置表里被设置接口当普通配置项整块返回，
   前端还会把它渲染成一个巨大的文本框。
   修复：GET 跳过该键（按插件+键精确判定），PUT 直接 400，避免误改。

② CLI --webui 与 webui.listen_addr 一直是死配置
   内核原本在插件加载前写 settings["addr"]，但那时 config_<name> 表还没建
   （表只在插件注册 def 时创建），PluginSettings.Set 的 INSERT 失败，而错误被
   "_ =" 忽略了；随后插件 Start 里 RegisterDef 才建表并写入默认 :8080。
   实测：传 "-webui 127.0.0.1:18099" 仍然监听 :8080。
   修复：覆盖值改由插件自己接收（webui.SetListenOverride，loadPlugins 前调用），
   优先级 CLI > webui.listen_addr（非默认值才算显式配置）> settings["addr"]。
   实测修复后："-webui 127.0.0.1:18099" 正确监听 18099，与生产的 :8080 并存。

③ 端口被占时 webui 静默死亡
   Start 在后台 goroutine 里 ListenAndServe，先打印 "listening on" 再尝试绑定，
   失败只留一行日志，Start 永远返回 nil → 插件仍被当成加载成功。
   修复：net.Listen 同步做，失败即返回 error（交给加载器/守护），
   成功后才起 Serve，并打印真实绑定地址。
   A/B 实测（两个实例都撞生产的 :8080）：
     修复前："listening on :8080" + "server error: address already in use" + LOADED: webui
     修复后："[plugin] start webui: webui: 监听 :8080 失败: ..."，不再有 LOADED: webui

效果实测（同一实例，先注入 5,271,690 字节 chathistory）：
  GET /api/v1/settings   8,244,108 → 28,652 字节（约 1/288）
  meta 条数              5,208 → 105，幻影键 0 条
  设置页仍正常：?prefix=plugin.webui 返回 8 条 def；普通键 PUT 落库；
  校验：GET/PUT 内部键被拒；-webui 覆盖真实生效。

新增测试：TestSettingsNoCrossPluginLeak（跨插件泄漏/幻影键/chathistory 读写）、
TestListenOverrideAndBindFailure（覆盖生效 + 端口占用必须报错）、
TestResolveListenAddrPrecedence（优先级）。
 2026-09-14 06:54:16 +08:00
JianFeeeee
937359b4df feat(pluginmgr): plugin_install 支持本机 path（配合 plugindev_build 的产物） 
背景：Agent 现在能自己构建插件了（plugindev 插件封装了 hmapdev），但安装只支持
http(s) URL —— 本地刚构建出来的 `dist/*.hmap` 装不上，链路断在最后一步。
pluginmgr 的 HTTP API 本来就接受 `{path}`（installFromPath），只是工具面没暴露。

改动：`plugin_install` 增加可选 `path`（本机 .hmap 路径），与 `url` 二选一，
同时给出时以 `path` 为准；`path` 必须存在且不是目录。描述里写明
「配合 plugindev_build 的产物用这个」。

于是 Agent 的完整闭环成立：
  plugindev_init → plugindev_build → plugin_install(path) → plgreload
 2026-09-13 14:17:11 +08:00
JianFeeeee
18d7ad3a36 fix(remotedevice): 设备通道名改用 - 分隔并派生合规名（v1.3.0 部署后 agent 完全不应答的根因） 
## 事故

v1.3.0 部署到生产后，**整个 agent 不应答**：任何对话都返回
`all 3 providers failed, last error: api error 403: model "claude-opus-5" is not allowed for this key`。
回滚到 1.2.2 立即恢复（部署前 403=0/成功对话=10，部署后 403=5/成功对话=0）。

## 根因（网关日志给出的原文）

```
tier 3 gozen/deepseek-v4.1-flash: api error 400: [invalid_request_error]
  Invalid 'tools[299].function.name': string does not match pattern '^[a-zA...
```

设备的每设备输出通道名叫 `device/<id>`，内核按 `output_send__<通道名>` 生成工具 ⇒
`output_send__device/<id>` 里的 `/` 违反上游函数名规范 `^[a-zA-Z0-9_-]{1,64}$`。
上游不是"拒掉这一个工具"，而是**整条请求 400** ⇒ 网关 auto tier 全链条失败
（400/429/503 混在一起）⇒ 内核只能报"所有 provider 都失败"。
两台真实设备（waiter-fnnas / waiter-mainnas）一上线就登记了这种通道，于是必然触发。

## 修法（改插件，不改内核）

初版我在内核里加了"通道名净化 + 反向解析"层。用户否掉了这个方向，理由对：
**通道名是插件自己的声明，不合契约就该改插件**，不该让内核替插件擦屁股。
内核侧改动已全部回退（HEAD 干净）。

插件侧两处：
1. 分隔符 `device/<id>` → `device-<id>`（源码与来源标签统一，不留两套名字）。
2. 设备 id 是**外部输入**（设备自己声明），可能含空格/非 ASCII/超长 ⇒
   `deviceChannelName()` 把它派生为**合规且唯一**的通道名：
   保留 `[A-Za-z0-9_-]`、其它折成 `-`、主体截断到 32 字符（预算 64 = 13+7+32+7+…）、
   发生截断或撞名时追加 id 的 6 位短哈希。同一 id 恒定同名；真名仍用于路由与日志。

核心契约写进了插件注释与 SDK 文档（见 SDK 仓同批提交）：名字若来自外部输入，
**在插件侧派生合规名**，内核不会替你净化。

## 验证

- 新增 `TestDeviceChannelNameIsLLMFunctionNameSafe`：恶意 id（空格/符号/非 ASCII/超长/
  会折成同名的两个 id）都必须派生出**合法且互不重复**的通道名与工具名。
  反向验证：把分隔符改回 `/` 即 FAIL。
- 生产两台设备派生结果：`device-waiter-fnnas`、`device-waiter-mainnas`
  ⇒工具名 `output_send__device-waiter-fnnas`（37 字符，合规）。
- 全量 `go test ./...` = 37 包 ok / 0 FAIL；`-race`（remotedevice + core）无 DATA RACE。
 2026-09-13 13:10:38 +08:00
JianFeeeee
f0be8cbaa5 feat(remotedevice): 设备能力 outputch 化 —— 每设备一个 device/<id> 通道 + 设备指令类工具补授权闸 
用户指出 remotedevice 的能力应当 outputch 化。查证后发现比"应当"更严重：
设备方向**根本没有出站实现**。

## 查到的三个缺口

1. `devicectlDevice` 一直声明 `OutputCapabilities() = CapStructured`（对外宣称可作输出目标），
   但 `Execute` 的 switch 里**没有 "output" 分支** ⇒ `output_send__devicectl` 必然拿到
   `unknown device tool output`，回模型"通过 [devicectl] 通道发送失败"。
2. 全插件没有 `RegisterOutputChannel`，也没有任何 EmitOutput/output_send 路径：
   设备方向只有「工具（请求-响应）」与「设备→agent 注入」，**agent → 设备是断的**
   （唯一的下行通道是个 HTTP 端点 `/api/v1/device/push`，不在 agent 的工具/通道模型里）。
3. 寻址是聚合的：所有设备共用一个名字 `devicectl`，没有 `device/<id>`；且设备 caps 只在
   插件内部软检查（`SupportsTool`），**绕过**了内核的 `AllowedOutputs` 授权闸 ——
   驻留子只要拿到 `device_ctl_cmdrun` 就能指挥**任意**设备。

## 按方向切分（不是一刀切）

**出站/消息类 → 每设备一个输出通道 `device/<id>`**（与入站同名）：
- 上线注册、掉线注销（caps 由设备声明的 caps 映射：文本恒有；有屏→图/文件；
  speaker→音频；可跑命令(cmd/cmdrun/cmdresult)或未声明已知能力→全能力，与
  `deviceSupportsTool` 的旧设备兼容规则一致）。断连不注销会留下死通道骗模型。
- 于是自动获得：内核按 caps 在**发送前**拦（送图给纯文本音箱直接拒）；
  `output_list_channels` 能列出设备；`AllowedOutputs` 可按设备收窄给驻留子。
- 上下线钩子用 `Registry.SetPresenceHandler`（**同步回调**）而不是既有的 `ChangeChan`
  （那是 select+default，缓冲满会丢事件；丢一次就留下死通道或漏注册）。
- `devicectl` 保留为聚合通道，并把它"声明了却不实现"的 output 补实：按
  `meta.device_id`（或 meta 就是设备 id / args.device_id）路由；缺省时返回**可执行**的
  报错（列出在线设备），而不是含糊失败。

**RPC 类保留为工具**（`devicedetect`/`screensee`/`computeruse`/`clipboard*`/
`device_ctl_status|cmdrun|cmdresult`）：它们的返回值（图像/命令输出/状态）必须进模型
上下文，做成通道会丢掉这个语义。

**并给设备指令类工具补上同一道授权闸**（core/toolcall.go）：`device_id` 指向的设备
必须是本 agent 被授权的 `device/<id>`。根 agent 默认完整授权 ⇒ 无行为变化；
驻留子收窄后，"拿到工具就能指挥任意设备"的缺口被堵上（新增 3 条 core 测试钉住）。

**设备端参考实现**（`internal/devicebridge/client/bridge.go` + waiter）：新增 `op=push`
分发与 `OnPush` 回调（文本/结构化；二进制走既有 `cmd_speech_*` → `DataHandler`），
waiter 把它打到终端。

## 设计口径（用户当场纠偏，已写进代码注释与 harness README）

**主动转发只有 webui 与 cli 两个交互界面**（webui 订阅 EventAgentOutput 渲染气泡、
cli 用同步回程写回终端）。其它通道一律要求 agent **显式** `output_send__<通道>`。
我第一版给 remotedevice 加了 `EventAgentOutput` 订阅来自动回投设备——那是凭空造了
第三个转发者，违背"输出是 agent 的主动调用"，已撤回（该测试一并删除）。

## 验收

- 单测：caps 映射词表；设备上线→注册通道（含同名 inputch）/掉线→注销；push 真落到
  WS 设备；聚合通道 `devicectl` 的寻址（无 device_id 报可执行错误、按 meta 投递、
  指定不存在设备报错）；core 授权闸 3 例。
- 全量 `go test ./...` = 37 包 ok / 0 FAIL；`-race`（agent/plugins/plugin/devicebridge/sdk）干净。
- **真二进制端到端**（私有 netns + mock LLM + 真 WS 设备客户端 scripts/kernel-stress/devclient.py）：
  设备上线 → 通道表出现 `device/pydev-1`（caps=[text file image audio structured]，由
  `caps:["cmd"]` 映射）→ agent 经 `output_send__device/pydev-1` 主动发送 → 设备收到
  `{"op":"push","payload":"内核推给你的消息","type":"text"}` → 设备掉线 → 通道从表中消失。
 2026-09-13 12:23:28 +08:00
JianFeeeee
6e6035141a fix(resident/plugin): 二进制级压测暴露的三个真问题（DataDir 漏接线 / inputch 未登记 / create 不开工）+ 通道双向登记贯穿全部内建插件 
在真实内核二进制（私有 netns + mock LLM + CLI unix socket）上做压力测试时，
下面三个问题**只有跑真二进制才暴露** —— 单元测试里都显式传了参数、没走插件加载，
所以全绿也照样漏。

## ① 根 agent 的 DataDir 没接线 ⇒ 驻留子永远建不出来

现象：模型调用 `resident_agents` 成功，但结果是
`创建驻留子需要 data_dir 或显式 temp_path`。
根因：`cmd/homed/main.go` 构造 AgentConfig 时没有 `DataDir`，
而驻留子的 temp 图库需要 `<data>/residents/<id>/graph.db` 这个锚点。
（单测里 `AgentConfig{DataDir: dir}` 显式给了，所以测不出来。）

修：main.go 接线 `DataDir: cfg.Daemon.DataDir`；并在工具层加**兜底 + 告警** ——
data_dir 为空时从主图库路径反推（`<data>/memory/graph.db` ⇒ `<data>`），
失败才报错。静默失败会让线上表现成"工具能调但永远建不出来"。

## ② 插件通道没登记为 inputch ⇒ "划入 inputch"必然失败

现象：`划入 inputch cli: inputch 未注册`。
根因：`cli` 插件只调 `RegisterOutputChannel("cli", ...)`，却用同一个名字
`InjectTextSync("cli", ...)` 注入输入 —— 内核 inputch 登记表里根本没有它。
（实测审计：内建 6 个插件里只有 0 个登记过入站通道；SDK 示例里只有 qq/weather 是对的。）

修两处：
- **全部内建插件显式登记入站通道**：`cli`/`agentcli`/`timer`/`webui`(+`http`, NoMemory)/
  `clawhubadapter`（每个 OC 通道声明处）/`remotedevice`（`device/<id>` 懒登记，幂等）。
- `registry.go` 把隐式兜底改成**留痕的兼容网**：只有当该名字还没登记为 inputch 时
  才兜底登记，并打日志说明"建议显式 RegisterInputChannel"。
  实测：改完内建插件后，启动日志里兜底告警 **0 次**。

## ③ create 之后子不开工 ⇒ rounds 恒为 0

现象：`[agent] r1 started, waiting for IO interrupts` 之后什么都没有，登记表里 rounds=0。
根因：`TaskPrompt` 只进了子的**系统提示词**，从没作为输入投给子。
修：create 即开工 —— 把任务提示词作为**第一条排队输入**投给子（排队而非中断：
创建是"安排工作"，不是"打断它正在做的事"）。

## 测试

- `TestResident_InputchTableAutoAndProactive` / `TestLightKernel_TraditionalContextNoTrimming`
  随行为更新：create 会多跑一轮（任务提示词那轮也会写处理表），
  断言改为"以创建时的表长为基线 + 等待新的一轮"。
- 全量 `go test ./...` = 37 包 ok / 0 FAIL；`-race`（agent/plugin/plugins）干净。

## 真实二进制压力测试结果（修复后）

私有 netns 里跑 mock LLM + 内核，用 CLI socket 驱动多并发连接：
- 密集：16 连接×12 输入 + 4 线程×20 次 L4 中断 → **274 任务 executed=274 / rejected=0 / errors=0**，
  峰值排队 15、峰值待处理中断 76；
- 稀疏（中断每 3s 一次，压在排队任务的流式段上）→ **suspended=27 / resumed=27 / preempted=27**；
- 驻留子全链路：父建子（inputchs=["cli"]）→ 子开工 → 子 `notify_parent` → 父侧收到
  `interrupt from r1/child/r1`（L3，且父被抢占 suspended/resumed=1）；
- 优雅退出：SIGTERM 后驻留子 temp 目录被清除、无残留进程。
 2026-09-13 11:38:03 +08:00
JianFeeeee
93aa942e1e test(plugins): deepsearch E2E 不再带走共享搜索后端（附回归判据） 
背景：E2E 临时目录里拉起的插件实例在 teardown 时执行了 `docker compose stop -t 2`，
把线上正在用的 SearXNG 关掉，表现为「搜索后端起不来」。

- integration_test.go：把 ConfigRegistry 暴露给测试环境（其余不变）
- deepsearch_e2e_test.go：
  - forbidStoppingSharedBackend：测试实例一律 stop_searxng_on_exit=false
    （配置表按内核约定先 RegisterDef 再 Set）
  - 新增 TestRealPlugin_DeepSearchKeepsSharedBackendOnStop：停掉插件实例后，
    6 秒内 healthz 必须始终 200 —— 判据落在网络层，直接钉住「跑测试不能断线上搜索」

验证：三条 E2E 全过，且跑完 healthz 仍 200、容器 StartedAt 未变（未重启）。
 2026-09-13 09:55:33 +08:00
JianFeeeee
a2dcd96fee chore: 撤回误提交的未跟踪文件 internal/plugins/deepsearch_e2e_test.go 
该文件是工作区里**别人 in-flight** 的未跟踪文件（我上一步用 git add -A internal/ 时被顺带收进来）。
它不是我这次改动的一部分，因此从索引里撤出，文件本体保留在工作区（仍为未跟踪状态），
由它的作者决定何时提交。
 2026-09-13 09:07:02 +08:00
JianFeeeee
3c961b7bd7 feat(channel): N1a —— inputch 一等化（归属插件/归属 agent/容量/共享登记表）+ 单工具多视图总览 
设计：docs/zh/resident-subagent-design.md §4.6（里程碑 N1a）。

## 用户要求

「父 agent 可以看到所有已注册的 inputch 以及 inputch 的划分情况，用**单工具多视图**方式构筑」

## 登记层（internal/agent/io/inputch.go）

inputch 是**最基本的输入路由单位**（由插件注册，一个插件可注册多个），
所以登记表以 inputch 为键，每条记录：

    名字 / 归属插件 / 归属 agent(被划给谁) / 容量 / 默认回程 outputch / 记忆策略(ChannelDef)

- 新增 `ChannelRegistry`，设计成**可共享对象**（`*ChannelRegistry`）：
  根 agent 与驻留子共用同一份，"划入/授权"才有意义；`SetChannelRegistry` 注入。
- **插件重载不得抹掉划分**：重复登记只更新「归属插件 + 策略」，
  保留已有 Owner/Capacity/Output（否则一次 reload 就把父做的划分清空）。
- `Assign` 语义按设计 R6 默认：**读写授权，不转移所有权**（Plugin 与 Owner 分别记录）。
- 原 `inputChannels map[string]ChannelDef` 被登记表取代；`GetInputChannelDef` 保持兼容。
- `plugin.Registry` 注册时带上**归属插件名**（此前完全无归属信息）。

## 总览工具（internal/agent/core/inputch.go）

单工具 **`input_channels`** + `view` 参数（不是一堆小工具）：

    all（默认）= 全部已注册（带归属插件）
    mine       = 划给本 agent 的
    unassigned = 尚未划出的
    by_agent   = 划分情况总览（按归属分组）
    detail     = 单个 inputch 全字段（需 name）

未知 view **报错并列出可用值**（拼错不得被静默当成默认视图）；登记表为空时明确说明。

## 验收

- `internal/agent/io/inputch_test.go`：归属记录、重载保划分、Assign/视图数据面、
  **跨 manager 共享登记表**、策略查询向后兼容 —— 5 项
- `internal/agent/core/inputch_test.go`：单工具多视图逐视图断言（含未知 view 与空表）—— 2 项
- 全仓 `go test ./...` 37 包 ok / 0 FAIL；`-race ./internal/agent/... ./internal/plugin/...` 干净
 2026-09-13 09:06:50 +08:00
JianFeeeee
f3232000f4 feat(scheduler): L4 也归内核级插件 —— WebUI 终止按钮可用“立即打断” 
上一提交把 L4 写成“内核独占（panic / selfip）”，漏了内核级插件这类来源。
用户澄清：**内核级插件应当能声明 L4，用于实现中断能力**，例如 WebUI 的终止按钮。

判据（两道闸，纵深防御）：
  1. proc 桥（外部进程唯一入口）一律把 L4 夹到 L3。在这里夹而不是只按 source 判，
     是因为 source 是插件自报字段、可以冒名；本函数所在位置能确知“来自外部进程”。
  2. core：isKernelLevelSource(source) 查 pluginReg.IsBuiltinPlugin，只有编译期内置
     插件（init() 自注册的工厂）才承认 L4。
source 约定 `插件名` 或 `插件名/实例`（webui/<deviceID>），判据取第一段——
否则带设备身份的 WebUI 来源会被误判成外部插件而拿不到 L4。

改动：
- core: interruptLevel(evt, privileged bool)；新增 isKernelLevelSource；
  requestPreempt 不再夹取（级别已由 interruptLevel 解析，否则内核级插件的 L4 被削掉）。
- eventloop: 传入 a.isKernelLevelSource(evt.Source)。
- proc 桥: 新增 clampExternalPriority，pubSdkInjectOpts 一律夹取。
- internal/sdk: 再导出 PriorityL1..L4（内置插件用 sdk.PriorityL4）。
- webui handleChatInterrupt（终止按钮）声明 PriorityL4。
- timer 声明 PriorityL3：定时器是“时钟那种实时工作”，比 QQ 那类可无限等待的
  异步消息高（L1）——这是对用户“它不是时钟那种实时工作”的直接推论，可改。
- 测试: L4 特权矩阵（非特权夹取 / 特权承认）、source 判据（内置、内置/实例、
  外部、空、前缀不误匹配）、内核级插件 L4 一路到达调度器、proc 夹取两条。
- 设计稿 §2/§3.2/§11.1/§14/§15 按“L4 = 内核 + 内核级插件”更正。

验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿（含 webui/timer）。
 2026-09-13 07:18:03 +08:00
JianFeeeee
fe883d5362 test(plugins): 真实插件产物先校验平台再 exec，错误平台给可读提示而不是 exec format error 
排查知识库改动是否引入回归时，internal/plugins 6 个测试全红、报
"fork/exec .../plugin.bin: exec format error"。查了半小时才发现与代码无关：
早前验证跨平台示例构建时，最后一次构建（darwin/arm64）把
`example/*/build/plugin.bin` 覆盖成了 Mach-O arm64，而 realPluginBinary
只按文件名找候选、**不校验平台**，于是拿 macOS 产物在本机 exec。

两个陷阱一起堵：
- 校验魔数（ELF / Mach-O / PE），平台不符则 **SKIP 并给出可直接粘贴的重建命令**
  （`hmapdev build --target <host> --no-bundle`），不再用误导性的 exec format error；
- 明确写出「产物缺失即 skip」的语义，避免"全绿其实什么都没验"
  （本次对照实验里，改动前的 worktree 因无产物而全绿，看着像通过）。

反向验证：把 weather 产物换成 PE 假头 → 相关测试转为 SKIP 且提示平台与重建命令 ✓。
 2026-09-12 18:38:24 +08:00
JianFeeeee
5aaae93367 feat(healthcheck): 内核状态快照报出内核版本号与 ONNX 模型启用状态 
healthcheck_kernel 此前没有任何「ONNX 模型是否在用」的信息，只报「向量可用/不可用」，
分不清「统一多模态空间已加载」与「退回到词嵌入/TF-IDF 路径」；人格卡要求
「版本以运行时快照为准」，也缺一个可查字段（build.version 早就在，但没人知道）。

- KernelStatus 新增 onnx 段：enabled / provider / dim / fingerprint / modalities / reason。
  判据取 Loaded()（provider 真正打开且元数据合法），**不是**「配置里写了 provider」
  —— 后者在模型缺失 / 运行时缺失时也为真，报出去就是假绿。
- 未启用时 reason 给**具体原因**：未配置（说明会走回退路径）/ 打开失败的具体错误。
  homed 把「配置的 provider 名」与「打开失败原因」透传给 Agent，仅供状态报告。
- ProviderAdapter 新增 Modalities()（可选能力，按接口断言取用，不改公开契约）。
- healthcheck_kernel 的工具描述同步说明它回答这两件事。

**顺带修一个真实 panic**：collectKernelStatus 的 knowledge 是**接口**参数，
(*knowledge.Store)(nil) 塞进接口后 `ks != nil` 仍为真 → 调 List() 直接 panic，
而 healthcheck_kernel 正是走这条路径（panic 发生在工具 goroutine 里）。
GetKernelStatus 改为先按具体指针判空、再赋给接口；并加刻画测试钉住这个成因
（一旦不再 panic 说明参数形状已变，守卫与该测试应同步删除）。

验证：单测 4 例（已启用 / 打开失败 / 未配置 / 未加载）+ 刻画测试；
隔离实例 E2E 7/7：正例 provider=chineseclip → enabled=true、dim=512、模态 2；
反例 provider=nonexistent → enabled=false 且 reason 含具体错误与 provider 名，
真实对话仍通。
 2026-09-12 14:56:25 +08:00
JianFeeeee
46e014a8ca feat(persona): 首启人格门禁跨通道化 + 内核 persona_set 工具 
WebUI 首启向导只覆盖 WebUI 这一条通道，而「人格该问一次」是所有通道的事：
走 QQ / CLI / ACP / 邮件来的人永远见不到那个向导，人格就永远是没确认过。

- 门禁移到 buildSystemPrompt（每轮重建 → WebUI/QQ/CLI/ACP/邮件全覆盖），
  以 core.internal.persona_initialized 为准：未确认时要求模型主动询问用户
  （默认 / 自定义 / 以后再说），确认后该段消失；personaStore 为 nil 时静默关闭。
- 新增内核内置工具 persona_set(mode=default|custom|later[, content])，
  落库逻辑与 WebUI 向导**共用 internal/config**（一个实现 + 两个薄入口：
  ConfigRegistry 直连 / 插件侧 SettingsAPI），避免两套语义各自漂移。
- AgentConfig 增加 PersonaStore 接口，cmd/homed 用 RegistryPersonaStore 实现。
- 非法输入（未知 mode / custom 空内容）在打标记**之前**拒绝：否则标记置位、
  向导被跳过，用户再没机会设。

E2E（隔离实例 + 真实 LLM 往返走 /v1/chat/completions，/var/tmp/persona/e2e.sh）9/9 PASS：
未确认时模型主动询问 → 用户答「用默认的」→ 模型调用 persona_set 落库并置位标记
→ 之后不再追问；反向对照（清标记 + 清会话上下文 + 重启）重新开始询问，
排除了「同一段对话里已问过」这一混淆。
 2026-09-12 13:57:06 +08:00
JianFeeeee
10367b384e feat(webui): 首启人格向导（默认 / 自定义 / 稍后）+ 一次性标记 
接续人格配置项化（597f07c）：现在人格是 core.agent.personal_prompt，
本次加上「首启问一次」的界面，之后不再打扰。

后端（GET/POST /api/v1/persona）：
- GET  → {initialized, current_prompt, file_override}
        未设置时 current_prompt 回落到内置默认模板；存在 personal/personal.md
        时报告 file_override（它会覆盖配置项，向导据此提示用户）
- POST → {"mode":"default"|"custom"|"later","content":"…"}
        写配置 + 打一次性标记 core.internal.persona_initialized；
        custom 返回 restart_required=true（人格在启动时载入）；
        「稍后」= 保留当前默认 + 打标记，**绝不阻塞任何流程**
- 空内容的 custom 与未知 mode 一律 400，且**不打标记**（否则向导会被跳过）

前端（dashboard.html）：
- 首启拉一次 /api/v1/persona，未初始化则弹向导（复用一直没人用的 .confirm-* 样式）
- 「自定义…」第一次点击展开文本域并预填当前人格，再次点击才提交（避免误提交）
- 中英双语走既有 __() 机制；保存失败/空内容用 toast 提示

测试：TestPersonaWizardFlow（首启状态、later 打标记不改人格、custom 写入 + 需重启、
空内容与未知 mode 被拒且不打标记）、TestPersonaWizardReportsFileOverride。

E2E（真实实例）：首启 initialized=false → POST later → initialized=true，
config 中标记=1、人格键为默认模板；前端页面含向导函数。
 2026-09-12 13:02:18 +08:00
JianFeeeee
b15d0bd114 refactor(plugin)!: 重编提示与模板路径改用 hmapdev；文档全面对齐 1.2.0 
工具链在 SDK 1.2.0 更名为 hmapdev（原 plugindev）。核心侧三处功能耦合同步：

1. 用户可见报错：旧 C ABI 产物 / 协议版本不匹配 / 共享段版本不匹配
   三处「请用配套 plugindev 重编」→ hmapdev（对应两条测试断言同步）
2. e2e_template_test 的模板路径改为 tools/hmapdev/templates，
   并保留旧路径回退（旧 SDK 检出仍能跑测试）
3. 注释与文档同步

文档更新（用户可见面）：
- assets/docs/{zh,en}/PLUGIN_DEV.md：工具链章节整体改为 hmapdev，
  补改名说明与 SDK 存储目录迁移；命令示例全部更新
- assets/docs/{zh,en}/ARCHITECTURE.md：**流程图与章节对齐 v1.2.0** ——
  · 向量化章节改为三层降级：统一多模态空间（主）→ 词嵌入 → TF-IDF（回退），
    写明「同指纹且同维度才参与融合」
  · 媒体记忆章节重写：媒体是一等记忆块（无独立 GC / 无引用计数 / 无描述式索引 /
    正文不再写 media marker），并写明 reembedStaleMedia 的跨空间迁移与写回
- README{,_EN}.md、docs/zh/plugin-interface-matrix.md：工具名与模板路径同步
  （历史条目标注「当时名为 plugindev」）

验证：go test ./internal/plugin/ ./internal/plugin/proc/ ok，
含 4 条真实模板 E2E（模板路径切换后仍通过）。
 2026-09-12 12:42:43 +08:00
JianFeeeee
dc80855540 feat(status): 暴露构建源码地址，WebUI 状态页给出 AGPL §13 的源码入口 
选了 AGPL-3.0-only 之后，§13（Remote Network Interaction）就不只是声明问题：
把修改过的版本作为网络服务提供出去时，必须给使用者取得 Corresponding Source 的机会。
只在仓库里放 LICENSE 并不自动满足这一条——**使用者拿到的是服务，不是仓库**。

所以把它做进产品里，而不是写进文档就算完：

- `internal/meta.SourceURL`：本次构建对应的源码地址，默认指向本仓库。
  注释里写明「修改后对外部署的分支必须改指向自己的仓库」，并给出 -ldflags 覆盖方式
  （`-X .../internal/meta.SourceURL=<你的仓库>`），不需要改源码。
- `BuildStatus.SourceURL`（`json:"source_url,omitempty"`）+ 内核状态填充：
  走已有的 `/api/v1/kernel` 构建身份链路，不新增端点。
- WebUI 状态页在「版本」行下渲染「源码 / Source」链接（URL 经 escHtml 转义后进属性；
  `target="_blank" rel="noopener noreferrer"`）。
- 用 `omitempty`：未注入该值的旧构建不会在 JSON 里多出一个空字段。

验证：
- `internal/plugins/webui/dashboard.html` 的两个内联 script 块 `node --check` 均通过；
- 全仓库 `go build ./...` 通过，`internal/meta/meta.go` gofmt 干净
  （`internal/agent/core/status.go` 有**既有**的 gofmt 差异，与本改动无关，按纪律未整体重排）；
- 端到端：本地构建 homed → 冷启动 → `GET /api/v1/kernel` 的 `build.source_url`
  实测为 `https://gitcode.com/JianFeeeee/HomeAgent`。
 2026-09-12 09:41:39 +08:00
JianFeeeee
d1959cbe80 feat(core): 注入行为的记忆/裁剪标志位落地 + jieba 词库内嵌 + Windows 改走 WSL 
配套 SDK 提交：homeagent-sdk ba49dfd（公开 API 纯追加，无签名变更）。
本仓第三方的库镜像同步至该版本，以保证全新 clone 能编译。

## 1. 注入标志位（内核侧）

- 7 条注入路径（排队/中断/同步 × 纯文本/带媒体 + 旧 NoMem 变体）解析并转发
  no_memory / context_policy / cleaner_name；策略在入口**校验**，
  非法值报错而不是静默降级成 none（降级会让调用方以为自己声明的裁剪在生效）。
- 新增 validateContextPolicy（与 tool.register 同一套规则）与 pubSdkInjectOpts。
- input.register 不再手写字段白名单重建 ChannelDef，改为整体传递 + 补 ContextPolicy。
- io 层：applyInjectOpts 把标志位写进事件 payload，仅非零时写
  （零值与旧 payload 逐字节一致，事件订阅方与旧内核都不受影响）。
- ioAdapter / procCore / internal-sdk 别名补齐六个 *Opts 实现。

## 2. 修掉「输入无条件裁剪」这个真缺陷

eventloop 此前对**每条非中断输入**都调 `context.Prune(...)`：破坏性（低相关事件被
归档移出上下文）且无法从调用点看出是谁触发的。改为 pruneOnInput/pruneDeclared：

  优先级：注入点声明（payload.context_policy）> 通道声明（ChannelDef.ContextPolicy）
          > 默认**不裁剪**

查询向量仍取清洗后的内容；新增 cleanInputFor 解析清洗文本，优先级为
注入点声明的 cleaner（cleaner_name）> 按 source 查到的通道 cleaner > 原文，
名字查不到时**记日志再回退**（注入是 fire-and-forget，插件看不到错误，
至少要在内核日志留下「你声明的清洗没生效」的痕迹）。

## 3. jieba 词库内嵌（修「猜 GOMODCACHE → 静默失效」）

原 jiebaDictDir() 去猜 GOMODCACHE/GOPATH/~/go/pkg/mod，部署机上通常没有 Go 模块
缓存 → GetJieba() 返回 nil → 分词/关键词提取/NLP 依存解析（进而 doc→graph 三元组
抽取）/静态词向量 tokenizer **一律静默返回空列表**，只有一行日志。本机看起来正常
只因开发机与生产机重合、恰好有那份缓存。

现在词库随二进制分发：internal/memory/jiebadict/ 5 文件约 11.6MB + go:embed，
按**内容哈希**命名缓存目录落盘（词库升级不复用旧文件），已齐全则跳过写入。
模块缓存降为兜底。homed 体积 32MB。

顺带确认（并有测试佐证）：gojieba 的 Tag() 不需要 pos_dict/ 目录——
cppjieba 的 PosTagger 从主词典每行的词性列取 tag。

## 4. homed 放弃 Windows 原生，改走 WSL2

插件体系依赖「继承的 fd」+「统一共享内存区的段内偏移解引用」，Windows 既无 fd
继承语义，其句柄模型也无法表达后者；强行适配等于再维护一套平台专属 ABI
（C ABI 时代三套 ABI 并存曾导致改写型插件在某平台静默失效）。

- cmd/homed/platform_{windows,other}.go：原生 Windows 启动即拒绝并打印 WSL2 指引。
- internal/plugin/proc/shmalloc_windows.go：allocShm 直接返回「请用 WSL2」，
  **不返回半可用的段**（与 shmalloc_other.go 同风格：未支持平台显式报错）；
  procEnvForShm 返回 nil。顺手修掉两处长期编译错误
  （cryptorand→rand、h.evData→h.unified.evtData），使 GOOS=windows 至少能编译。
  注：homed 本就编不出 Windows——internal/memory 依赖 cgo-only 的 gojieba。
- deploy/packaging/installer.nsi：不再安装 homed.exe/initconfig.exe，改为携带
  **linux payload** 并调用新的 install-via-wsl.ps1；退出码 20/21 表示
  「需先装 WSL/发行版」，走指引而非报错。
- deploy/packaging/windows/install-via-wsl.ps1（新）：检测 WSL → 引导安装 →
  确保 WSL2 → 送包进发行版 → 在 WSL 内按 Linux 方式安装。**复用 Linux 包与
  linux/setup.sh**，不另写一套安装逻辑；落点与 deb 布局统一
  （/usr/bin/homed + /usr/lib/homeagent/setup.sh）。
- deploy/packaging/linux/setup.sh：API Key 允许 HOMEAGENT_API_KEY 覆盖
  （否则安装器界面显示一份、config.db 里另一份 → 登录不上）。
- deploy/packaging/build.sh：windows 目标只构建 waiter + gui，并新增
  stage_linux_payload 把 Linux 包暂存给安装器；homed/initconfig 在 windows
  目标下明确拒绝。

## 5. 插件调用点统一写明意图

- webui 的 OpenAI 兼容端点（固定提示词模板）→ InjectTextSyncNoMemory。
- agentcli 的 5 处纯状态通知（已启动/超时/执行结束/进程退出/读取结束）→ NoMemory；
  **带输出**的 2 处（定时反馈、有新输出）刻意保留记忆并注明理由。
- timer 的定时提醒 → NoMemory（中断本来也隐含 NoMemory，这里是写明意图）。

## 6. 版本

meta.Version 仍为 1.2.0（main 是下一个未发布中版本）；
SDKCompatibleVersion 1.1.0 → **1.2.0**（本内核已实现 SDK 1.2.0 全部新增方法）。

## 测试

- core：默认不裁剪（无声明/none/空）、通道 opt-in、注入点双向覆盖通道、
  nil context/io 安全、cleaner 优先级与未知名回退。
- io：零值 opts 与历史 payload 逐键相同；text/中断/媒体三类注入标志位都落到
  payload；旧方法仍生效。
- proc：validateContextPolicy 只接受 ""/none/prune，报错含位置与实际值；
  **跨进程** e2e——testdata 插件经 io.injectText 送出三个标志位，断言它们穿过 RPC
  到达内核。
- memory：模块缓存不可见时内嵌词库仍可用（分词与 POS 内容词均非空）、
  落盘幂等、内容哈希稳定。

验证：go build ./... / go vet ./... / go vet -tags onnxruntime ./...
      go test -short ./internal/memory/... ./internal/nlp/... ./internal/plugin/...
      ./internal/agent/{core,io}/... ./pkg/...
 2026-09-11 20:31:50 +08:00
JianFeeeee
5836c2ce5c refactor(memory): 拆除描述式媒体索引，媒体成为一等块并按原生向量融合 
背景：此前媒体是靠「生成的描述文本」将就进记忆的——写 marker 进正文、
再由正则反解成 media_refs 与图库里的 type=Media 实体。这条链路有三个
致命缺陷：描述由异步模型生成（未生成前媒体等于不存在）、语义检索实质上
只搜描述文字、图库里的「媒体节点」是描述文本的投影而不是媒体本身。

本提交把这条链路整体拆除，媒体改为按自己的原生向量参与记忆：

一、描述链彻底删除（无残留、无兼容分支）
- media.Item 去掉 Description/DescribedBy 与对应列；
- 删除 Store.Describe / Store.Search / Store.Pending；
- 删除 Agent.mediaDescribeLoop / describePendingMedia 与配置项
  core.memory.media.describe_on_ingest；
- SDK 侧 MediaAttachment 去掉 Description（见 SDK 仓独立提交）。

二、marker 机制删除，媒体归属改为结构化块边
- 删除 mediaMarkerLine/parseMediaMarkers/mediaEntityName/mediaTriplesFromText/
  extractMediaDigests/sentenceWithMediaMarkers/docMediaContext；
- memory.Triple 新增 MediaDigests 结构化字段；句子文本保持原样，
  不再被 marker 污染；
- 块以 sentence --contains--> block / document --contains--> block 结构边
  挂到承载节点（新增 documents 表与 document 节点种类）；
- 模型未给原句时用「主谓宾。」拼一句自然语言作落点，不造 marker 文本。

三、旧数据迁移（幂等）
- 新增 GraphDB.MigrateLegacyMediaEntities：把 type=Media 的旧实体按短 digest
  还原成原生块、挂回原句子、删除旧实体与描述关系；Agent 启动时执行；
- CleanupOrphanedSentences 同时看关系引用与块边，避免把只靠块存活的句子
  连同块边一起删掉。

四、向量融合：媒体按图本身被召回
- 新增 vector.FuseVectors（逐维求和 + L2 归一化）；
- Doc.DenseVec = 文本向量 ⊕ 文档块的媒体向量（同 fingerprint 才融合），
  新增 Doc.DenseFP，指纹变化触发重算；
- ContextEvent.DenseVec 同理融合事件块；事件新增 DenseFP，Prune 只在
  同一统一空间内比稠密余弦；
- 跨模态视觉路只召回「仍被某层记忆块持有」的媒体，CAS 全库字节不再
  直接充当记忆检索结果。

五、同时纳入本分支既有的嵌入基础改造（此前工作区未提交，缺它 HEAD 不可构建）
- internal/tfidf 懒回退包、千问三段式多模态 ONNX 空间的 Go 侧
  （qwen/embedder.go、image.go、model_input.go）、CLIP 移除、
  sdk.NewStore 分词器签名与调用点、embed 侧车 systemd 单元。

验证：go build ./... 、go vet ./...（含 -tags medialive）均通过；
在 HEAD 的独立 worktree 上重放本次暂存集后 go test -short ./internal/...
全部通过（端口冲突类用例在隔离环境中亦通过）。未提交工作区中与本改造
无关的改动（HarmonyOS、waiter、devicebridge、plan.md 等）。
 2026-09-11 11:45:24 +08:00
JianFeeeee
f6f92a8a6e fix(plugins): 修复两处预存缺陷（agentcli 临界区 / localuse 脚本转义） 
agentcli cleanupLoop：
持锁期间为每个过期终端 go func 调 term.Close()（内部会 Kill 进程并等
<-t.done），临界区被拉长且与 TerminalSession 退出路径交错。改为持锁
只做筛选与摘除，锁外再逐个关闭。

localuse 脚本转义（两处真实 bug）：
1. AppleScript 注入：handleScreensue 只把 `"` 转义为 `\"`，未转义 `\`。
   内容结尾的反斜杠会吃掉闭合引号，使后续内容逃逸出字符串字面量。
   改为 escapeAppleScriptString：**先转义反斜杠再转义双引号**（顺序
   不可颠倒，否则刚插入的反斜杠会被二次转义）。
2. PowerShell 路径被错误加倍反斜杠：handleScreensee 把 Windows 临时
   路径的 `\` 写成 `\\`。但 PowerShell 单引号串里反斜杠是普通字符
   （转义符是反引号），加倍会让截图保存到错误路径。
   新增 psSingleQuote 统一处理，并把 4 处零散的 `ReplaceAll(x,"'","''")`
   收敛到该 helper。
 2026-09-10 17:56:57 +08:00
JianFeeeee
687e5655bc feat(sdk): 多模态贯通插件边界——公开接口、内核桥接与统一输入主干 
记忆系统在 1.1.0 支持了二进制多媒体节点，但那条链路只对**内核自己**开放：
用户在 qq 发图能落进 CAS、能被记忆引用，而插件调 Commit / DocMemory().Insert
交进来的媒体一律无处安放。原因是三层都断着，且**每一层都不报错**。

## 一、公开 SDK：补上媒体的表达能力（全部新增，无签名变更）

- `Triple` += `SentenceText`、`MediaDigests`
- `Doc` += `MediaDigests`、`Attachments`；新增 `MediaAttachment`
- `TextEvent` += `Attachments`
- `DocMemoryAPI` += `InsertWithMedia`
- `IOInjector` += `InjectInputMedia` / `InjectInputMediaSync` / `InjectInterruptMedia`
- `PluginSDK` 补上一直缺失的 `SetToolBlocks` 包装（接口里有、便捷方法里没有）

`MediaAttachment` 一个类型服务两个方向：给 `Data`+`MIME` 是新内容（CAS 按字节
去重），只给 `Digest` 是引用已有内容。读路径**只回元数据不回字节**——一次检索
可能命中几十份媒体，全塞回去会把跨进程消息撑爆。

媒体注入不能搭 `SetToolBlocks` 的车：那个方法只在工具处理函数内部可用，且媒体
要等下一条 tool message 才到模型手上。插件主动发起一轮带媒体的对话、以及中断
注入，需要自己的签名，且媒体在**本轮**就送到模型。

## 二、内核桥接层：原先在静默裁字段

`internal/sdk/memory_impl.go` 此前只搬自己认识的几个字段，其余丢弃且返回 nil：

- 图记忆丢 `Confidence`/`SubjectType`/`ObjectType`/`SentenceText`，又走 `Commit`
  而非 `CommitWithMedia`（不回 sentenceIDs）→ 媒体绑定链 `SentenceText → sentences
  → sentence_id → media_refs` 一步都走不通，插件即便按格式写好标记也永远挂不上；
- 知识库 `Query` 只回 ID/Title/Content，`Insert` 只写这三个；`Remove` 不解引用，
  于是那些媒体永久处于「被引用」状态，GC 收不掉、磁盘只增不减
  （内核的归档路径 `releaseDocMedia` 做了这一步，插件路径漏了同一步）。

规则改为：**内部结构有的字段一律透传**。标记格式处理作为包级私有辅助留在桥接
层自己手里，但必须与内核 `mediaSummaryForEvent` 字节兼容——两边要能互读对方
写下的标记。

标记插入必须在 `ds.Insert` **之前**（向量索引取 `Summary + " " + Content`，
之后补的标记检索不到），引用绑定必须在**之后**（owner_id 是 Insert 生成的 ID）。

## 三、跨进程链路：不接线就是全体外部插件编译失败

`go test` 直接把这一层拍出来了——`procIO does not implement sdk.IOInjector`。
公开接口加方法后，生成模板不跟上，**每个外部插件都编不过**，是硬失败不是软降级。
六处接线：`protocol.go` 四个 method 常量、`capability.go` 能力归属、
`corehandler.go` 四个分派分支、`proc_core.go` 委托、`proc_main.go.tmpl` 模板侧
实现、以及三个测试替身。

## 四、统一输入主干：把模态从「函数选择」降级为「字段」

`processTextInput` / `processMediaInput` 合并为 `processInput`。这个分叉是历史
产物而非设计：`processTextInput` 本来就处理媒体（`bindEventMedia` +
`mediaSummaryForEvent`，与媒体路径尾部完全相同），`process()` 只看
`stageCtx.Extra["media_blocks"]`、根本不认识 `evt.Type`。模态是输入的**属性**，
不是输入的**种类**。

媒体路径由此获得它一直缺的六项：去重、`no_memory`、通道 `Cleaner`、中断语义、
`_consolidation_` 路由、正确的 `EventRawInput`。

最后一项是个真 bug：媒体路径发布 `"content": evt.Payload`（一个 map），而
`webui/handler.go` 断言 `.(string)` → 断言失败、`content == ""`、提前返回。
**用户发的图从来没出现在 WebUI 聊天记录里。**

`media_blocks` 同时接受 `[]agentAPI.ContentBlock` 与 `[]pubsdk.ContentBlock`：
字段一致但 Go 不自动转换，只认一种的后果是另一种被静默丢弃。

## 五、模型可调用的三个工具

`memory_commit` 的 `sentence_text` **从未暴露给模型**，而它是绑定链上的必经环节；
连同 `media_digests` 一起补进 JSON schema 与工具文档。`doc_commit` 加
`media_digests`。`doc_query` 把关联媒体单独一行附在结果末尾（正文按 2000 字截断，
标记通常就在尾部）。

标记由**内核**生成而非插件/模型拼装：要求调用方知道格式，等于让一个拼写错误
静默切断引用绑定，而全链路无人报错。

## 六、WebUI 上传走真实媒体链路

图片/音频读回字节拼 data URL 注入 `media_blocks`（8MB 上限，超限退回按路径处理）。
此前只注入一句「文件已保存到 <路径>」，指望模型自己调 `files_read`——但那返回
文本，图片字节对模型永远不可见。附件类型识别扩展到 audio 并在缺 Content-Type
时按扩展名兜底（判错不只是卡片样式问题，图片被当普通文件就进不了视觉链路）。

## 测试

- `internal/sdk/memory_impl_test.go`（12 例，此前该包**没有任何测试文件**）
- `internal/agent/core/inputunify_test.go`（统一主干 + 双静态类型 + 三工具媒体）
- `third_party/homeagent-sdk/sdk/stress_test.go`（13 例并发压测）

压测抓到两处**真**竞态（不是理论风险）：`PluginSDK` 的 API 字段与 `autoRestart`
无锁，而写方（内核注入 API、插件 `SetAutoRestart`）与读方（插件后台 goroutine
注入、内核 registry 读 `AutoRestart`）天然跨 goroutine。加 `apiMu` 修掉；约定
只在持锁期间取字段值，取完即释放再调用——持锁调用会把 `InjectInputSync` 这类
阻塞到 agent 回复（可达数分钟）的方法与 `SetIOInjector` 串起来，让插件重载卡死。

测试还抓出两个自身缺陷：`bindDocMedia` 把同一份媒体数两次（`AddRef` 幂等所以表
是对的，但日志说「绑定 2 个」而实际 1 条——误导后续排查），以及用单字符实体名
时 `validEntityName` 静默跳过、`Commit` 返回 nil 却什么都没写。

存量插件不需要改一行也不需要重编：新增方法由插件调用、内核实现，不调就不受影响。
17 个 example 插件源码零改动通过类型检查。
 2026-09-06 09:51:31 +08:00
JianFeeeee
968b01f26e fix(plugins): 修复隔离全量测试暴露的两处数据竞争 
-go test ./... -race 全仓复验暴露的 7 处 race、5 个失败测试，全部定位。
两处独立缺陷，互不相关。

## 缺陷一（remotedevice，8 处 race）：连接写无串行化

WARNING: DATA RACE
  Read at 0x... by goroutine 28:
    bufio.(*Writer).Available() / writeFrameHeader / PushData
  Previous write at 0x... by goroutine 27:
    bufio.(*Writer).Flush() / writeFrame / handleWS

同一连接的 bufio.Writer 被两条并发路径写：
  - handleWS 主循环：读到设备帧后回写 hello_ack/bind_ack/pong
  - PushJSON/PushData：agent→设备的下发路径，可来自任意 goroutine

bufio.Writer 不是线程安全的。不加锁就在 WriteByte/Flush 上撞——这
不是理论风险，TestWSPushDataAudio 的异步 PushData 与 handleWS 的
hello_ack 回写并发时被 -race 稳定抓到。

修法：wconn 增加 wmu（sync.Mutex），PushJSON/PushData 拿锁后整条
下发（start + N 个 chunk + end）持锁——设备侧按协议串行聚合，中途
被插帧会破坏协议顺序。handleWS 的 hello_ack/bind_ack/pong 也改走
同一把锁（wsWriteLocked 封装，避免调用方绕过）。设备已离线时不回写。

关键点：不能只锁 Push* 不锁 handleWS——那只是把竞争挪了个位置。

## 缺陷二（agentcli，1 处 race）：共享读缓冲被并发读写

WARNING: DATA RACE
  Write at 0x... by goroutine 26:
    os.File.Read / (*linuxPty).Read / reader
  Previous read at 0x... by goroutine 25:
    runtime.slicecopy / readLoop

readLoop 创建 buf := make([]byte, ReadBufSize) 传给 reader goroutine
（t.session.Read(buf) 持续覆写），自己又在读到结果后
copy(data, buf[:r.n])——同一缓冲被读写并发。Go 的 pty 读走 OS 层
fd，专门在 reader 写下一段时读，跑 -race 稳定复现。

修法：readResult 携带 data field，reader 每次读完后把数据复制进自己
分配的切片再随结果传递，读取与拷贝之间不再共享任何可变状态。原 buf
保留（仍由 reader 独享用于 OS 读），readLoop 不再从其中 copy。

## 验证

  - 两个插件包 -race -count=2 全过
  - 全仓 go build / go vet / go test 通过
  - 全仓 go test ./... -race：32 包全过，0 DATA RACE，0 FAIL
  - SDK 冻结 diff = 0

其中 remotedevice 的 TestScreenseeEndToEnd / TestComputeruseEndToEnd
/ TestClipboardEndToEnd 原本因 race 挂，修后恢复全绿。
 2026-09-05 07:26:10 +08:00
JianFeeeee
98dcb2556c fix(test): 崩溃隔离测试误杀同机生产插件，且断言无效 
## 现象

生产 homed 的 editdoc 子进程从 9-03 起被 SIGKILL 9 次，间隔完全不规律
（126~485 分钟），全部发生在无工具调用的空闲期。查过 OOM（dmesg/
journalctl -k/cgroup oom_kill 全为 0）、systemd 内存限制（MemoryMax=
infinity）、cron/timer、内核自身的 StopAll 路径、agent 执行过的 cmd_run
命令，以及 Pdeathsig 绑创建线程的可能——全部排除。

## 真因：测试杀了生产的进程

用 ftrace 的 signal_generate tracepoint 挂监视器后抓到发送者 cmdline：

  /tmp/go-build.../plugins.test -test.run=TestRealPlugin_CrashDoesNotKillKernel

findPluginPID 用**全系统** `pgrep -f plugin.bin`，然后只比"exe 路径含
editdoc"。生产实例的 /home/newqqagent/plugins/editdoc/plugin.bin 也满足
这个条件，谁先被 pgrep 列出来就杀谁。9 次 kill 全部落在有人跑 go test
的时段——18:18:30 那次正是一轮 `go test ./... -race` 的窗口。

之前几轮排查一直在生产实例内部找原因，方向从一开始就错了：杀手在仓库里。

## 更严重的是这个测试本身无效

旧断言是"SIGKILL 之后内核仍存活"。可内核本来就活着——即使信号发错了
对象（杀了生产实例的插件），测试内核的插件压根没死，断言照样通过。
**它在测一件没发生的事**，同时把生产环境打坏了，而绿色的测试结果掩盖了
这一切。这也是它能连续 9 次造成生产故障却从没被注意到的原因。

## 修法

findPluginPID 增加 root 硬约束：/proc/<pid>/exe 必须以测试自己的 plgDir
为前缀，且是目标插件，两道条件同时成立才算命中。root 为空直接 t.Fatal
——这不是可选过滤器，是防误杀的前提。

  - 用 exe 而非 cmdline：cmdline 可被进程自行改写，exe 符链由内核维护。
  - root 先过 EvalSymlinks：/tmp 在部分发行版上是符链，不归一化会让前缀
    比较永远不命中，退化成静默 Skip（那样测试就白跑了）。

断言改成两步：先轮询确认目标进程真的退出（3s 上限），再验内核未被连带。
两步都成立才能证明隔离生效。

## 验证

修复后跑 TestRealPlugin_CrashDoesNotKillKernel：
  - 杀的是 pid=3448366，exe 在 /tmp/hc_integration_3823918128/plugins 下 ✓
  - 生产 editdoc pid 测试前后均为 3362892，存活时长连续 ✓
  - 四个 TestRealPlugin_* 全部 PASS
 2026-09-04 21:44:05 +08:00
JianFeeeee
09071dc235 fix(multimodal): 修多模态假成功 + 落地视觉回退链 + see_video 帧数语义 
## 起因

生产盲测：模型调 multimodal_see_picture 后声称看到了图，实际一个字
都没收到。工具却返回「[已将图片注入后续对话]」。

链路：core.llm.model=AUTO → llmsproxy 按优先级选 big-pickle(prio=100)
→ 转 opencode zen。llmsproxy 的 opencode.lua 明写着：

    -- zen 上游 schema 只接受 text content part（无视觉/音频能力）
    if part.type ~= nil and part.type ~= "text" then  -- 丢弃

判据：256x256 纯红 PNG，带图与不带图的 prompt_tokens 都是 256。
图片贡献零 token，即根本没进上游。

内核序列化与注入链本身是对的（Message.MarshalJSON 正确产出 content
数组，SetToolBlocks → IOManager → ConsumeToolBlocks → toolMsg.Blocks
全通）。缺的是「主模型能否消费这些块」这一判断——内核此前完全没有
多模态能力的概念（grep supportsVision|multimodal 在 agent/ 零命中）。

这与 v1.0.0 修的 output_send 假成功同类：告诉调用方成功而实际未送达。

## 1. 能力声明

新增 core.llm.sources.<name>.vision / .audio（走既有 sourceFieldDefs，
WebUI 配置页自动出现），types.LLMSource 与 api.BaseConfig 同步加字段。

新增 agentAPI.ModalProvider 接口 + ProviderSupportsVision/Audio 判定：
未实现该接口的 provider 一律按不支持处理。保守侧是刻意的——宁可多走
一次文字回退，也不能把图默默扔给会剥掉它的上游。

为何是声明而非探测：探测需额外真实调用且结果不稳定（取决于 AUTO 当次
路由到哪）；而 200 响应 + 相同 token 数从响应侧无法区分「看到了但没
内容」和「被剥掉了」。

## 2. 回退链（modalfallback.go）

实现了 config/registry.go 里注册但从未被读取的 image/audio
fallback_provider + fallback_model（此前 0 处读取点）。

prepareToolBlocks 在 process.go 注入前判定：能直视就原样透传；不能就
调声明了该能力的源转写成文字，带 [由 X 转写，非当前模型直接感知] 标注。

几处刻意的设计：
- 逐模态判定，不一刀切。很多视觉模型能看图但听不到音频，全部降级会
  白白把可直视的图变成二手描述
- 混合场景下转写文字作为 text 块并入 native，两部分同时到达模型
- 配置指向未声明能力的源时拒绝并继续找——照用只会重演静默剥离
- 未配 fallback_provider 但某源声明了 vision 时自动扫出来用；静默失败
  比多找一个能用的源更糟
- 空回复算失败。上游剥掉媒体后模型往往回「我没看到图片」或空串，两种
  都说明回退链也没真看到
- 多媒体块按模态合包为一次请求（见下）

## 3. 批量合包（生产实测驱动的返工）

首版逐块调用，生产 see_video 6 帧实测：4 帧里 3 帧超时，整轮 363 秒。
改为按模态合包一次请求后同一用例 131 秒、6/6 成功。

顺带把 modalFallbackTimeout 从 90s 提到 180s：生产经网关转
claude-opus-5 看一张 400x400 图要 ~81s，90s 贴着上限。
多张时 detail 默认 low 控体积，单张用 high 看细节；插件显式给了
detail 则尊重它。

## 4. see_video 帧数语义

fps=1/N 是频率（每 N 秒一帧）不是数量。20s 视频实测：
frames=4 → 5 帧、frames=10 → 2 帧、frames=1 → 20 帧，要得越多拿得越少；
长视频下 frames=4 会产出 时长/4 帧，靠 i>=9 的 break 兜着才没炸上下文，
而那个 break 用的是 ReadDir 索引，跳过条目后与实际帧数错位。

改为 ffprobe 取时长 → fps=N/时长 + -frames:v N 硬封顶。
0.4s/3s/20s/120s × frames=1/2/4/7/10 全部精确。

极短视频的坑：fps=1 在 0.4s 素材上产出 0 帧（不足一秒抽不出），所以
时长探测失败时不能退化成 fps=1，改为不传 -vf 只靠 -frames:v。

## 验证

- modalfallback_test.go 14 例：直视透传 / 回退转写 / 无源如实报告 /
  未实现接口按不支持 / 混合模态拆分 / 空回复算失败 / 块数上限 /
  多图合一次调用 / detail 策略 / 拒绝未声明能力的源 / 未配置时自动扫源
- go test ./... 全绿，go vet 无警告
- 生产盲测（答案预先封存、生成时不读）：随机三色带 → 模型答
  「紫、蓝、红」，与封存答案完全一致
- 负向验证：拿掉回退源后模型如实回答「没看到图片内容」并引用工具返回
  的配置提示，且主动纠正了上一轮的答案
- 生产 see_video 6 帧：单次转写，模型正确描述测试图卡的计数器递增与
  彩虹带滚动
 2026-09-04 06:25:51 +08:00
JianFeeeee
f91b27aedb fix: WebUI 版本显示 + Windows 交叉编译 + 发布脚本三处回归 
## WebUI 版本链路修复

问题：handler.go:949 报的是 sdk.SDKVersion，那条链最终指向
SDK 仓 meta.Version 的硬编码值，与 -ldflags 注入的内核版本
完全不相交。构建时间、commit hash 全部丢失。
dashboard.html 兜底值是 '0.1.0'——碰巧版本号相等时不显眼，
一旦不等就报错。

修复：
- KernelStatus 新增 BuildStatus 字段（Version/Commit/BuildTime/SDKCompatible/KernelName）
  取自 internal/meta（-ldflags 注入点），与接口冻结无关（KernelStatus 只在 internal/sdk）
- /api/v1/status 改用 meta.Version，另加 sdk_version 字段暴露 SDK 版本
- dashboard.html 概览卡显示 HomeAgent vX.Y.Z + commit/日期/SDK 兼容版本，
  去掉 || '0.1.0' 误导性兜底

## Windows 交叉编译修复

问题：internal/plugin/dynamic_proc_windows.go（Part 1 的桩，610e9d0）只定义了
tryLoadProc，但平台中立的 registry.go 还在调 loadProc / closeProcHost——这两个
函数只在 dynamic_proc_unix.go 里。Windows 下整个 homed 从 Part 1 起编译不过。

plan.md §12.5 声称「Windows 只做了交叉编译，无真机验证」——实际是连编译都没通过。

修复：dynamic_proc_unix.go / dynamic_proc_windows.go 合并为平台中立的
dynamic_proc.go（文件内无任何平台专属调用，proc 包内部通过
shmalloc_* / evtfd_* / shmpass_* / procattr_* 各自带构建标签处理差异）。

## 发布脚本三处回归修复

deploy/packaging/build.sh（从 package/build.sh 移到 deploy/packaging/ 后）：
1. PROJECT_ROOT 少一层目录（.. → ../..），产物落进 deploy/build/ 而非根目录
2. initconfig 从未被构建，但 installer.nsi 和 package-linux.sh 都引用它
3. GO 兜底路径指向 /home/jianf/go1.26.5（陈旧硬编码）改为 command -v go
4. electron-builder --config package.json 校验整个文件导致 devDependencies 被判为 unknown
   property，去掉 --config 让它从 build 键读配置

deploy/packaging/package-linux.sh：
1. build_go() 补上 initconfig 构建步骤
2. GO 兜底路径同步修复

知识库 3 条重写 + 1 条新增：
- homeagent_identity：v0.9.0 C ABI → v1.0.0 子进程
- homeagent_architecture：全篇重写为子进程架构（三面通信、Supervisor 台账、
  崩溃自愈、权限三道闸）
- homeagent_recent_updates：在 v0.9.0 前插入 v1.0.0 主线摘要
- changelog_v1.0.0（新建）：6 类缺陷消除、架构、实测、已知限制、迁移指引
 2026-09-03 15:38:31 +08:00
JianFeeeee
02cc74ce11 fix(proc): 子进程崩溃自愈 + 集中台账 + 注册面摘除 
根因：子进程插件被 kill 后，内核只发了一个无人订阅的事件，
工具/stage handler/IO 通道全留在注册表里指向死进程，
模型继续调用只吃 ErrProcessExited，没有任何路径把插件拉回来。

## 四层修复

### 1. 专职 waitLoop（进程收割）
- 每个子进程配一根 waitLoop goroutine，是 cmd.Wait() 的唯一调用点
- 不再依赖 stdout EOF 判定死亡（孙子进程继承 stdout 时 EOF 永不到来）
- 手工 os.Pipe 替代 cmd.StdinPipe/StdoutPipe，避免 waitLoop 与
  os/exec 的内部关闭竞争
- host.go: Host.Supervisor()，Host.Close() 先 StopAll 再拆段

### 2. 集中台账 Supervisor
- proc/supervisor.go: 插件 Spawn 握手成功即 track，进程退出即 untrack
- StopAll: 并发发 plugin.stop 走优雅路径，到期仍在的一律 Kill
- 关停后才完成握手的进程被立即结束，不会活过内核
- 消除「孤儿进程持共享段映射 → SIGBUS」的隐患

### 3. 注册面摘除（detachPlugin）
- 新增 StageHost.UnregisterPluginStages：摘除指定插件的全部 stage handler
- 新增 Registry.pluginChannels 台账：记录每个插件注册的 IO 通道
- 三条路径统一走 detachPlugin：Disable / ReloadOne / RemovePlugin
- StopAndUnload 漏了 IO 通道也一并补上

### 4. 自动重启
- onProcCrash 从「只发事件」改为「摘注册面 → 从注册表移除 → 异步排重启」
- scheduleProcRestart: 窗口 5 分钟内最多 3 次，线性退避 1s/2s/3s
- 超限停手留日志；重启前复核是否已被 Disable 或被其他路径加载
- 崩溃计数窗口过期自动归零

### 5. 主动停止 vs 崩溃的区分
- proc.Plugin 新增 stopping 标志：Stop()/Close() 里 Set(true)
- handleExit 读 stopping 标志，主动停止不上报 onCrash
- 防止重载/禁用/卸载被误判为崩溃触发多余重启

### 6. Linux Pdeathsig 兜底
- procattr_linux.go: SysProcAttr.Pdeathsig = SIGKILL
- 兜 homed 自身被 SIGKILL/OOM 时子进程变孤儿的场景
- macOS/Windows 无等价物，空实现

### 7. pluginmgr 升级
- PluginManager 接口新增 PluginRuntime / ListPluginRuntimes
- plugin_list 输出运行态：loaded / alive / pid / crash_count / channel
- 新增 plugin_status: 全量运行期快照 + dead/unhealthy 汇总
- 新增 plugin_restart: 无条件重启单个插件（plgreload 不动未改二进制的插件）

### 测试
- process_test.go: 3 例（grandchild stdout 感知 / Supervisor track-untrack /
  StopAll 无孤儿）
- crash_recovery_test.go: 8 例（detach 三项齐全 / 通道重注册 / 崩溃不阻塞 /
  退避阈值 / 窗口过期 / 关停中跳过 / PluginRuntime 通道识别）
- stages_plugin_test.go: 4 例（stage 按插件摘除 / 空 stage 清理 / 空名 no-op /
  工具+stage 双摘后可重新注册同名）
 2026-09-03 12:37:58 +08:00
JianFeeeee
2ebdb9a5b7 plugin: 权限梯度显式化（Part 6.4） 
迁移前，「外部插件拿不到 Selftest/Supervisor/Tracker」是 C ABI 表达能力的
**意外产物**——C 结构体不好传函数指针，这些能力自然到不了插件侧。那是运气
不是策略：任何人给 dispatch 加个 case 就能捅穿。

现在变成显式声明并强制，分三道闸：

1. **类型层**（proc_core.go，Part 6.2 已落地）：procCore 用命名字段持有
   内核 SDK 而非嵌入，未在收窄面写出的方法编译期就不存在。
2. **能力集**（新增 capability.go）：54 个 plugin→kernel method 划入 11 个
   capability 组，manifest 未声明的组被拒。
3. **RPC 边界**（corehandler.Handle 入口）：被拒时返回**明确错误**而非
   静默忽略。

第 3 条针对一类真实故障：C ABI 时代 case 23/24（事件订阅）是空实现，
返回成功但永远收不到事件（§1.3 的「给不了」而非「不给」），插件作者无从得知。
错误消息含四要素：哪个插件、哪个调用、缺什么能力、在哪声明。

## 能力划分的两个判断

**粒度按能力域而非单 method**。逐 method 授权看似更精细，但插件作者要在
manifest 里列 60 个名字，且内核每加 method 所有 manifest 都得改。

**空声明 = 不受限，而非「只有 core」**。17 个存量插件的 plugin.json 都没有
capabilities 字段。若空声明当作最小权限，它们会全部失去 IO 注入、记忆读写
而**静默降级**——违反「外部插件零改动」的硬约束。收紧的路径是让插件显式
声明，而不是默默拒绝老插件。

## core 与受限能力的边界

core（无需声明，始终可用）：注册自身工具/阶段/通道/API、读写**自己的**配置、
共享段锁仲裁、握手、autoRestart 自述、setToolBlocks。没有这些插件无法工作。

受限（需声明）：io / memory / doc_memory / knowledge / text_memory / llm /
social / events / plugin_mgr / settings_cross。

settings 刻意拆成两级：读写自己的配置属 core（正常工作所需），读写**其他插件**
配置或**内核核心**配置属 settings_cross（能改别人/内核的行为）。

## withheldCapabilities：让「不给」可见

10 项刻意不提供的内核内部机制列在表里并附理由。它们没有对应 method 常量——
不是忘了加，是决定不加。列表存在本身就是「这是策略而非疏漏」的证据，
读代码的人能看到边界在哪，而不是从「protocol.go 里没有」这个负面事实去推断。

## 测试

proc 包 10 项：
- AllMethodsClassified：**最重要的一项**。漏登记的 method 会按 CapCore 放行，
  等于绕过整套检查。新增 method 忘登记时当场报出。
- EmptyDeclarationIsUnrestricted / DeclaredSetRestrictsOthers / CoreAlwaysAllowed
- SettingsScopeSeparation：自身配置 vs 跨插件配置的归属
- DeniedErrorIsActionable：错误消息四要素
- HandleEnforcesAtRPCBoundary：被拒的调用不进 switch
- WithheldListIsDocumented：每项都有理由，且不被任何 method 暴露
- UnknownMethodFallsThrough：未知 method 报「未知」而非「权限被拒」，
  否则作者会以为是漏声明能力

写这个测试时踩到自己的坑：第一版用子串匹配查 withheld 泄漏，"Tool" 匹配到
tool.register 和 io.setToolBlocks 误报——那两个是合法开放的（注册自己的工具）。
改成前缀 + unregister 关键字匹配，withheld 项也改名带 API 后缀以示区分。

internal/plugins 2 项接线验证：
- RestrictedPluginStillLoads：只声明 io 的 weather 仍能加载并注册工具
  （它在 Start 里读 Settings，属 core）
- LegacyManifestUnrestricted：无 capabilities 字段的存量插件正常加载

真实 homed 实测：
  [plugin] weather-capped 声明能力: [io]
  [plugin] weather-capped: 经 proc 通道加载（子进程）
  registering tool: weather-capped_current / _forecast / _set_location

验证：go build ./... 通过；go test ./... 全仓无失败；
go test -race ./internal/plugin/... 全绿；go vet 干净。

Ref: docs/zh/架构迁移评估.md §3.8、docs/zh/plugin-migration-plan.md Part 6.4
 2026-09-02 21:27:13 +08:00
JianFeeeee
1d7f011e5d plugin: 17 插件全量重编 + 端到端冒烟验证（Part 6.3） 
## 17 个插件源码零改动，全部重编为 plugin.bin

16 个 × 3 平台（linux/darwin/windows），qq 1 平台（plg.json 自己声明
bundle:false）。luademo 走 Lua 解释器不适用。

git status example/ 无输出 —— 这是「业务代码零改动」的硬证据。
批 3 那些预估高风险的插件（qq 2686 行双向通道、browser 12 工具 +
InjectInterruptText、a2a/acp 的 InjectInputSync 同步注入）一次全过，
因为它们只碰公开 SDK 合同面，而合同面在 Part 2 已 51 个 method 全量平移。

唯一一次失败与迁移无关：rss 的 github.com/mmcdole/gofeed 不在本地模块
缓存且 proxy.golang.org 不通，换 GOPROXY=https://goproxy.cn 后通过。

## 真实 homed 加载验证

15 个外部插件全部经 proc 通道建链（protocol=1 sdk=0.9.2，各自独立 PID），
31 个插件 loaded（15 外部 + 16 内置）。

ai_image / files 未走 proc 通道：同名内置插件优先（工厂编译期注册），
外部插件被遮蔽。这是既有行为，与迁移无关。

事件环与共享段均正常创建，且共享段是**一块** 256KB 服务全部 15 个插件。

## 冒烟测试 4 项（internal/plugins/real_plugin_smoke_test.go）

用真实 example 产物而非 testdata 假插件；manifest 刻意写 "entry":"plugin.so"
验证工具链与内核都已不看 entry 值。未重编时 skip 而非 fail。

- ToolInvokeRoundTrip：工具真实调用往返（此前只验证到"注册"）。
  weather_current 返回结构化参数校验错误——这恰是链路通的证据。
- StageRewriteTakesEffect：sanitizer 清洗 ANSI 序列，改写经共享段回到
  内核 StageContext
- MultiPluginShareOneSegment：sanitizer + weather 并发，清洗结果不被覆盖
- CrashDoesNotKillKernel：SIGKILL 插件进程后 homed 存活、17 插件仍在
  （对比 C ABI 下插件 panic 直接带崩 homed，§1.2 现网已发生）

## 开销实测与基线偏差

15 个插件进程 RSS=88.0MB PSS=87.9MB 线程=82，均摊 5.87MB / 5.5 线程。

RSS 88MB vs 实验 5 基线 29.1MB **不是回归，是基线不可比**：实验 5 用
2.68MB 最小插件，真实插件 3.1~14.8MB。可比的结构性指标：
- 均摊线程 5.5 vs 4.9 —— 同量级，无线程膨胀
- PSS/RSS 99.9% vs 44% —— **明显差于基线**

第二项是真实发现：基线里 PSS 远低于 RSS 说明 Go runtime 只读代码页在
进程间共享；实测几乎不共享，因为 15 个插件是 15 个不同的二进制，没有
共同物理页可映射。这是「每插件独立二进制」的固有代价，意味着实际内存
开销高于 §4.3 的乐观估计。压这一项的方向是共享 launcher 二进制。

## 工具脚本入 experiments/19-migration-verify

scripts/ 被 .gitignore 排除，故放到已跟踪的 experiments 目录下，
与 01~18 的可复跑实验并列。

measure-plugin-overhead.sh 第一版有统计口径 bug：RSS 读 status 的 VmRSS、
PSS 读 smaps_rollup 的 Pss，输出 PSS(87.9MB) > RSS(69.1MB) —— 物理上不可能。
两者对共享内存段计入方式不同（smaps 的 Rss 含 Pss_Shmem）。已统一从
smaps_rollup 读。另修 bc 不可用导致 MB 全显示 0.0（改用 awk）。

Ref: docs/zh/plugin-migration-plan.md Part 6.3、docs/zh/架构迁移评估.md §4.3
 2026-09-02 20:20:25 +08:00
JianFeeeee
b20121f703 plugin: 删除 C ABI 通道（Part 6.2 完成，-3198 行） 
外部插件统一走子进程 + stdio RPC，三套独立 ABI 实现收敛为单一 RPC 实现。
用户决策：彻底舍弃 .so 能力，不保留双通道回退。

## 删除清单

internal/plugin/cabi/                     1156 行（loader.go/loader.c/types.go/output_test.go）
internal/plugin/dynamic_dll_windows.go     272 行（§9.2 记录的能力退化实现）
internal/plugin/dynamic_loader_unix.go      79 行（唯一 cabi 引用点）
internal/plugin/dynamic_dll_test.go         32 行
internal/plugin/dynamic_dll_stub.go         11 行
internal/plugin/dynamic_loader_windows.go   11 行
internal/plugin/bridge_e2e_test.go              （测的是 cabi 路径）
third_party/.../plugindev/templates.go    1296 行（取消跟踪，SDK 仓才是权威副本）

dynamic.go：entryCABI 通道删除，soEntry/dllEntry 常量删除。
registry.go：tryDynamic 探测顺序从 .so → .dll → .lua 变成 proc → lua。

## 旧 .so 给明确错误，不静默跳过

静默跳过会让「插件目录在但没加载」看起来像配置问题，而实际原因是需要
用新版 plugindev 重编。故保留 legacyCABIEntries 表专门用于识别残留：

  plugin legacy: 检测到旧 C ABI 产物（plugin.so/.dll/.dylib）。
  外部插件已改为子进程模式，请用新版 plugindev 重编产出 plugin.bin
  （业务代码无需修改）

错误消息里「业务代码无需修改」这句是有测试守着的——迁移的核心承诺就是它。

## pluginmgr 安装逻辑跟进 bundle 命名

子进程模式下各平台产物统一叫 plugin.bin（进程边界即 ABI 边界），故 zip 内
按平台加后缀 plugin.bin.<goos>.<goarch>，解包时挑当前平台那一份重命名。

platformBinary 改为按 runtime.GOOS+GOARCH 生成条目名；platformBinaries 固定表
换成 isPlatformBinary 前缀判断（平台组合会增长：linux/arm64、darwin/arm64…，
按前缀判断无需维护清单）。

新增 chmod 0755：zip 保留了原权限位，但经某些工具链/传输后可能丢失，
内核加载时会因缺执行位报错。提前补上比事后让用户 chmod 更好。

## 测试

entry_dispatch_test.go 重写（12 项）：
- classifyEntry 对 .so/.dll/.dylib 现在返回 unknown
- LegacyManifestFallsBackToProbe：存量插件 manifest 仍写 "plugin.so"
  （17 个插件没人去改），须靠目录探测找到 plugin.bin —— 这是
  「外部插件零改动」的直接后果
- LegacyCABIGivesActionableError：错误消息须含 plugindev / plugin.bin / 业务代码
- PluginEntryHash_IgnoresLegacyCABI：.so 不参与 hash（内核已不认它）

upgrade_test.go 的 .hmap 构造改用 plugin.bin。

验证：go build ./... 通过；go test ./... 全仓无失败；
go test -race ./internal/plugin/... 全绿；三平台构建通过。

Ref: docs/zh/架构迁移评估.md §3.1/§9.2、docs/zh/plugin-migration-plan.md Part 6
 2026-09-02 19:26:40 +08:00
JianFeeeee
3de6b0426f revert(webui): 移除 chat/history 的 lean 裁剪模式 
工具调用详情（args/result）与 reasoning_content 是排查问题和还原上下文的
关键信息，不应裁剪下发。瘦身只保留分页一条路径（limit/before 控制条数）。

- 删除 lean 查询参数与 leanChatMsgs()
- 删除 ChatToolCall.Truncated 字段
- 分页仍生效：limit=40 首屏 1287.9KB → 48.5KB，且 tool_calls args/result
  与 reasoning_content 完整下发
 2026-08-28 23:38:11 +08:00