3cb4307677
fix: 修 CI 抓到的两类真实缺陷（.syso 破坏 arm64 + 测试硬编码 /etc）
...
第一次 CI 跑出 2 类失败，都是**本地以 root/amd64 跑永远看不见**的问题。
这正是建 CI 的价值：换一个环境就暴露了。
## 一、.syso 无条件被链进所有平台 → arm64 交叉编译必炸
CI 报：
$WORK/b001/_pkg_.a(waiter.syso): 310766: unknown ARM64 relocation type 3
（linux/arm64 与 darwin/arm64 两个 job 都红；amd64 两个都绿）
根因（已在本地用 Go 1.25.9 + arm64 精确复现）：Go 会把**同目录的 *.syso
无条件链进任何 GOOS/GOARCH**，而这两个 .syso 是 Windows 资源对象
（x86-64 COFF，只含 .rsrc 图标段）。链进 arm64 目标即报「未知 ARM64 重定位」。
仓库其实**早就知道**这件事 —— deploy/packaging/build.sh:86-90 写着
「Go 会把同目录的 .syso 无条件链进任何目标」，并留了 hide_syso_for_target()
绕过，注释还点名「这正是 arm64 产物长期缺失的原因（曾被误判为缺 g++
交叉编译器）」。但那是打包脚本里的私有绕道：任何**直接 go build** 的路径
（包括 CI、包括本机原生 arm64 构建）都仍会撞上。修在源头而不是再加一层绕道。
修法分两种，因为两个文件的处境**完全不同**：
1. cmd/waiter/waiter_windows_amd64.syso（原 waiter.syso，git mv）
waiter **仍支持 Windows**（package-windows.sh:68 明确构建 waiter.exe），
所以不能删。按 Go 的文件名约定加 _windows_amd64 后缀 ⇒ 只在
windows/amd64 被链入。实测：linux/amd64、linux/arm64、darwin/arm64、
windows/amd64 四平台全部通过，且 Windows 产物的 .rsrc 段大小
（00049eb8 字节）与改动前**逐字节一致** —— 图标没丢。
2. cmd/homed/{homed.syso,homed.rc} 删除
homed 的 Windows 原生支持**已放弃**，五处独立来源一致：
- README.md:251「homed 放弃 Windows 原生支持改走 WSL2」
- cmd/homed/platform_windows.go 的 requireSupportedPlatform 直接拒绝启动
（理由是设计性的：fd 继承 + 同段内偏移解引用，Windows 句柄模型无法表达）
- package-windows.sh:4「❗ 安装器不往 Windows 装 homed」
- build.sh:35「Windows 不再安装 homed.exe」
- installer.nsi:230「homed 不再装到 Windows」
即 homed.exe 即便构建出来也拒绝运行 ⇒ 图标资源毫无意义，却是 arm64
构建失败的来源之一。顺带查明：homed.syso 与 waiter.syso 本是**同一个
blob**（两个 .rc 指向同一 icon），属纯重复。
★ 由此留下一处**未修的残留**（已确认，不在本次范围）：installer.nsi:297,313
仍在创建指向 homed.exe 的快捷方式与 Run 注册项，而同文件 230 行已声明
homed 不装 Windows。那是 Windows 安装器的独立缺陷，需单独处理。
## 二、internal/system 测试硬编码 /etc → 非 root 必失败
CI 报：
system_test.go:51: expected archive to happen
system_test.go:97: expected restore to happen
测试写死 target := "/etc/xxx.test.tmp" 并**忽略了 os.WriteFile 的错误**。
GitHub Actions runner 以非 root 运行 ⇒ 写 /etc permission denied ⇒ 文件
不存在 ⇒ ArchiveBeforeWrite 按「新建文件无需留档」返回 false ⇒ 断言失败。
本地以 root 跑则一路通过 —— 缺陷因此长期不可见。
修法：用仓库**已有**的 SetProtectedPaths([]string{临时目录}) 显式声明受保护
前缀（不再碰真实 /etc），defer SetProtectedPaths(nil) 复原默认。既去掉了对
root 的隐式依赖，也没有削弱被测语义（保护的仍是「受保护前缀下的文件」）。
## 验证
- go test ./... -count=1 全绿
- go build ./... 通过
- waiter 四平台交叉编译 全通过（含此前必红的 arm64）
- homed linux/amd64 原生构建 通过（确认删除 .syso 无害）
- Windows 产物 .rsrc 段 改动前后一致（00049eb8 字节）
2026-09-29 11:11:34 +08:00
6d7de92bbd
ci: 建立 GitHub Actions 流水线（六个 job，全部命令已本地实测）
...
## 为什么现在做
这次排查「QQ 收不到回复」花了大半程才定位到根因，途中我犯了两类错：
先断言「提示词没写 output_send 规则」（实际 buildSystemPrompt:48-52 写了），
又断言「适配器丢了内容」（实际两版等价、直连上游正常）。
两次都是**在无自动化判据的情况下凭局部证据外推**。
仓库已有 60 个 Go 包、`go build ./...` 仅 2.2 秒，成本极低却无人强制跑。
AtomGit 停用流水线后更无兜底，故迁到 GitHub 补齐。
## 设计原则：CI 里每条命令都是本地已实测通过的
不写「可能有用先试试」的步骤 —— 未验证的 CI 步骤会把假红灯变成常态，
最后所有人都学会忽略它。本文六个 job 的每条命令都本地跑过：
go build ./... ✓
go vet ./... ✓
go test ./... -count=1 ✓（干净克隆亦通过）
make check-client-versions ✓
go test -race core + waiter ✓
waiter/initconfig/mock-server 交叉 ✓（5 平台）
npm test（cmd/gui） ✓
make check-csrc ✓（告警/ABI/ASan+UBSan/跨架构）
## 六个 job
| job | 覆盖 |
|-------|----------------------------------------------------------|
| go | build + vet + test + **跨平台客户端版本一致性** |
| race | 并发核心的竞态检测 |
| cross | linux/darwin/windows × amd64/arm64（仅可纯交叉的 3 个 cmd）|
| gui | Electron 仓的 Node 测试 |
| csrc | C 基础设施门禁 |
| docs | 站点配置可解析 |
## 关键事实（都由实测确立，不是推断）
1. **只有 waiter/initconfig/mock-server 能纯交叉编译**。homed、memgc、
homed-kb-migrate 依赖 cgo（gojieba / onnx），必须原生构建 ⇒ 不进 cross matrix。
2. **CGO 必须为 1**：gojieba 需要 cgo，`CGO_ENABLED=0` 下 internal/memory
直接编译失败（实测）。
3. **`go test ./...` 不会碰到 cmd/gui**。该目录是纯 Electron（0 个 .go、
无 go.mod），`./...` 只匹配含 Go 文件的包；只有显式 `go test ./cmd/gui`
才报 "no Go files"。这不是缺陷，是 Go 的包匹配语义 —— 之前把它当
[setup failed] 是误读。
4. **cmd/gui 的 npm test 零依赖**：三个 .mjs 只 import node: 内置模块
（fs/url/path/vm）⇒ 不需要 npm ci、不需要 electron，秒级完成。
5. **测试自足，CI 上不会因缺本地服务而红**：webui 测试用 httptest 与
`127.0.0.1:0`，真实 LLM 测试带 t.Skip 守卫。
6. **action 版本已核实存在**：checkout/setup-go/setup-node/setup-python 均用
v7（经 GitHub API 逐个确认 tag 存在，避免「版本不存在 ⇒ 立刻红」）。
## 明确不进 CI（依赖真机/密钥/内网，否则只会变 flaky 噪音）
deploy-*.sh、waiter 真机（192.168.2.x）、`npm run test-live`（需真 Electron
+ Xvfb + 真后端）、scripts/kernel-stress/*、需 DEEPSEEK_API_KEY 的真实 LLM 测试。
2026-09-29 10:23:21 +08:00
d676adbd0e
chore: 排除 SDK 仓的 skills/；清掉误建的 --help/ 目录
...
## skills/ 不该进本仓
SDK 仓新增了 `skills/`（hmapdev skill install 的源），本仓的
`.gitignore` 已排除 `tools/`、`docs/`、`example/`、`package/`、`scripts/`
等 SDK 仓自治范围，唯独漏了新加的 `skills/`。
`skills/` 是**文档**（skill 说明），归 SDK 仓管 —— 本仓经 go.mod 的
`replace` 只引用它的**编译必需文件**（sdk/*.go、go.mod、meta/meta.go），
文档不在其中。
⇒ 这不是新规则，是把已有规则的适用范围补齐。
## 误建的 --help/ 目录
我在验证 skill 时跑了 `hmapdev init demo`，但那次实际执行的是
`hmapdev init --help` 之类 —— `--help` 被当作**目录名**，在仓库根生成了
一个含 `go.mod`/`plg.json`/`plugin.go` 的 hmapdev 脚手架。
`plg.json` 里 `"name": "--help"` 坐实了这点。已删除。
★ 顺带记一条本机特性：`/tmp` 是 **tmpfs(内存盘) 只有 653M 可用**，
而 SDK store 有 4 个版本、备份要几 G ⇒ 大文件备份必须放 `/var/tmp`。
（这轮第一次备份就撞了 `No space left on device`。）
2026-09-28 11:30:55 +08:00
a417b5f927
feat(gui): 协议对齐 —— 补齐 6 个只读诊断端点 + 人设/反代面板
...
GUI 原来只用 22 个端点，服务端有 47 个。补齐**只读诊断类**：
agents / network / tracker / config / persona / proxy(+services)。
## 刻意不接 /login 与 /logout
那是 cookie 会话认证流程，而 GUI 走 `X-API-Key` 头（见 `api()`）。
接了不是"对齐"，是接错。
## 三处新增
**总览诊断卡片**（renderDiagPanel）：Agent 健康、LLM 可达、网络端点数、
文件变更集、数据目录、心跳间隔。全部走 `(x && x.y)` 安全取值 ——
任一端点没取到（老内核无该路由、连接断开）只显示 "-"，不抛错。
**人设面板**（renderPersona）：实测结构是
`{current_prompt, file_override, initialized}`。我第一版按 map 遍历，
结果只会显示三个字段名 —— 真机验证时才发现。改成展示提示词全文 +
两个状态卡。**只读**，编辑涉及保存/回滚/并发覆盖，与"协议对齐"是两件事。
**反代面板**（renderProxy）：base_domain / mode / total / manual +
服务列表（`✓ gateway → 127.0.0.1:9890`）。实测字段是
`{name, host, path, url, target, ok, auth, websocket}`，不是我第一版假设的
`subdomain`。
## 加载策略
只加进 `refreshAll`，**不加** `refreshDataOnly`（后者每 15 秒一轮，
诊断数据不必高频轮询）。7 个新端点实测只 +3ms。
## 判据 protocol-align.test.mjs（10 条，真 Electron）
- 7 个 state 槽都取到真实数据
- 总览出现诊断卡片
- 人设面板**真的显示提示词内容**（不只查元素存在）
- 反代面板**真的列出服务**（查 `→` 出现）
### 判据踩的三个坑
1. **默认假 key 导致 9 项全红** —— webui 对错误凭据返回 200 + 登录页 HTML
（`looks_like_login_page` 能识别），于是所有取数失败。看起来像
「代码坏了」，实际只是认证缺失。改为默认从 `config.db` 读真 key。
2. **判据绕过了应用路径** —— 表达式里直接调 `refreshDiagData()`，
于是把应用里的 `await refreshDiagData()` 注释掉，判据**仍全绿**。
改为走应用自己的 `refreshAll()`。
3. **变异后 GUI 仍加载旧代码** —— `ensure()` 看到端口有页面就复用，
注入变异后没重启 GUI ⇒ 又一次假绿。**变异测试必须先杀掉 GUI 进程。**
变异测试（注释掉调用点）⇒ 9 项变红，坐实判据验的是真路径。
## 门禁
- `npm run test-live`：22/22 通过（12 性能+滚动 + 10 协议对齐）
- `npm test`、`make test-gui`：全通过
- `go test ./...`：43 包 ok、0 FAIL
2026-09-28 10:45:54 +08:00
fba7dba373
perf(gui): 聊天页增量渲染 + 修「打开不在最新消息」（10× 提速）
...
用户报「聊天页面卡得让人没有用的欲望」+「打开 app 和 webui，没有停在
最新消息处，还要反复滑动」。真机实测（Xvfb + Electron + CDP）定位到两个
根因，都修了。
## 根因 1：renderChat 每次全量重建 innerHTML
200 条消息 = 3500 个 DOM 节点全部销毁重建。拆分测量：
200 条：整体 234.6ms，其中 renderMd 25.4ms（**11%**）
⇒ markdown 渲染只占 11%，**89% 在 DOM 写入与布局**。
流式追加时每个放行的 chunk 都走这条路（200 条时每 chunk 6.6ms），
聊到几百条就是 0.5 秒/次 —— 这就是体感。
**改法**：按 `data-msgkey` 复用节点，四种策略按代价从低到高：
尾部追加（最常见）→ 头部前插（loadOlderChat）→ 局部替换 → 兜底整棵重建。
`data-msgkey` = role + 序号 + 内容长度 + 首尾片段。
★ **不能靠下标定位**：`loadOlderChat` 会 `unshift` 前插消息，下标整体位移。
实测：
| 消息数 | 改前 | 改后 | 改善 |
| --- | --- | --- | --- |
| 50 | 59ms | **8.2ms** | 7.2× |
| 200 | 235ms | **23.5ms** | 10× |
| 400 | 474ms | **38.2ms** | 12× |
关键是**次线性**了：400 条只比 200 条多 15ms（改前多 240ms）。
## 根因 2：滚动没落地
scrollTo 被调: 1, 参数: {top: 23446, behavior: "smooth"}
scrollTop: 0 ← 调了，但没生效
可滚动上限: 22838
smooth 立即值 0、300ms 后只到 6894（上限 22838）⇒ **既慢又没到位**；
手动 `scrollTop = scrollHeight` **立即 22838 一次到位**。
原因：紧邻的 DOM 全量变更让 smooth 动画的起点算在**旧**布局上。
重建后本就不该有动画 —— 用户要的是「立刻看到最新」。
**改法**：`msgsEl.scrollTop = msgsEl.scrollHeight`。
## 判据 chat-perf.test.mjs（10 条，真 Electron 跑）
新增 `npm run test-live`（需 Xvfb + electron，**不进 make test** ——
它要起真浏览器、30 秒启动，不适合当门禁）。
- 性能：200 条 < 100ms（**产品体感阈值**，不是 benchmark 数字）
- 次线性：单条成本不随规模上升
- 滚动：打开即在底部、300ms 后不被带偏
- **正确性：增量不丢消息**（5 种增删改路径）—— 比性能更重要
### 写判据时踩的坑（都记在文件里）
1. **第一版测出「0ms / 0 DOM 节点」** —— `buildChatLayout()` 在**无后端连接**时
走「请先添加连接」分支、聊天区压根没建 ⇒ **测不到**而非「不卡」。
2. **`ensureGui` 定义了但从未被调用** —— 重写文件时把调用丢了，
而定义还在，看起来一切正常。
3. **`detached: true` 只脱离进程组、不脱离会话** —— 脚本结尾 `process.exit()`
把刚起来的 GUI 带走（症状：`[tray] READY` 打了，判据却报「找不到页面」）。
改用 `setsid`。
4. **`JSON.parse(e.data)` 裸调** —— CDP 的 onmessage 也会收到非 JSON 帧，
抛在回调里既冒泡不到 await 也等不到 resolve ⇒ 整个判据挂死。
5. 我自己的滚动探针 `el.innerHTML=''` 让 `scrollHeight` 变 0，
「到位」判定是假象。改用「保留内容、只改滚动方式」重测。
## 变异测试
把 `applyIncrementalChatRender(msgsEl, html)` 改回 `msgsEl.innerHTML = html`
⇒ 判据立刻红（实测 268ms + 严格线性）。
## 门禁
- `npm run test-live`：10/10 通过
- `npm test`、`make test-gui`：全通过
- `go test ./...`：43 包 ok、0 FAIL
2026-09-28 10:26:58 +08:00
9020590e13
test(proc): 修 grandchild 测试的三个设计缺陷（不是生产代码问题）
...
## 定位结论
`TestKillReturnsEvenWhenGrandchildSurvives` 曾在 `go test ./...`（600s 超时）
与 `make test`（20.4s FAIL）里失败，但**单跑 0.24s 通过**、连跑 3 次全绿
⇒ 「单跑绿、合跑红」。查下来是**三个测试设计缺陷**，
生产代码（`process.go`）没问题。
### 缺陷 1：名字说 Survives，实际测的是「被杀」
| 测试 | 源 | 孙进程 | kill(-pgid) 能杀吗 |
| --- | --- | --- | --- |
| …EvenWhenGrandchildSurvives | grandchildPluginSource | sleep 400，**不**设 Setpgid | **能** |
| …WhenGrandchildEscapesProcessGroup | escapingGrandchildSource | sleep 401 + Setsid | **不能** |
`grandchildPluginSource` 自己的注释写着「孙进程**不**设 Setpgid：它要留在
插件的进程组里」⇒ 第一个测试里孙进程不会 Survive。容易让人误以为
「脱组场景已被覆盖」，而它覆盖的是另一个场景。
**已改名** `…WhenGrandchildDiesWithProcessGroup`。
### 缺陷 2：判据数的是全系统进程
两个计数器扫 `/proc` 找 `"sleep 400"` / `"sleep 401"` 字符串，
**不区分父子关系** ⇒ 同机任何命中同样 cmdline 的进程/容器都串味。
原注释记过一次前车之鉴（「我第一版就踩了：明明单跑通过，合跑却红」），
但当时只加了 base 快照，**没解决全局匹配这个根因** —— base 救不了
「别的测试中途拉起 sleep 400」。
**已修**：新增 `procPPid()`，两个计数器都限定 PPid 属于本测试的插件。
顺带补 `e.Name()` 的 `Atoi` 校验（原来会把 /proc/self、/proc/net 也读一遍）。
### 缺陷 3：defer 清理「拿不到 pid 就整个跳过」
`if pid := pluginPid(p); pid > 0 { Kill }` 在 pid 取不到时静默跳过
⇒ 残留 sleep 400 污染后续测试 ⇒ 变成下一个测试的假失败。
**已修**：新增 `cleanupSleepMarkers(marker)`，按唯一 cmdline 标记兜底清理。
## ★ 我被推翻的一个假设
我一度认定根因是 `waitLoop` 里 `p.cmd.Wait()` **先阻塞**、拆管道在**之后**
（`process.go:359-367`）—— Go 的 `exec` 里 `Wait()` 会等 copy goroutine，
而那些要等所有管道写端关闭，孙进程持有着 ⇒ 死锁。
**实测推翻了它**：把拆管道提到 `Wait` 之前，那个测试 **5 次全 FAIL**
（改前只是偶发）。真正的根因是上面三个测试设计问题；「Wait 阻塞」只是
**被孙进程持管道放大**的效应。
⇒ 改生产代码不但没修好，还把偶发变成必现。**先证明因果再动手。**
## 判据：grandchild_design_test.go（4 条）
★ 它是**查源码文本**的，我一改源文件（改名/加 ppid 限定/加兜底清理），
锚点就全过期 ⇒ 三条判据一起红。
⇒ 判据自己被重构打断时，要改的是**判据的锚点**（认新旧两种形态），
不是回退修复。最后把判据①从「解函数体比对 spawn 参数」简化为
「只问名字是否还说 Survives」—— 少耦合一层，少失效一处。
变异测试三个都抓到：改名回 Survives / 抽掉 ppid 限定 / 去掉兜底清理。
## 门禁
- 全量 `go test ./...`：**43 包 ok、0 FAIL**
- `internal/plugin/proc` 连跑 **5 次全绿**（原来会红的地方）
- `go test -race ./internal/plugin/proc/`：ok
- 无 sleep 400/401 残留
## 顺带
`67def30` 之后 README 的 biome 格式化不再 churn：仓库**没有** biome 配置，
格式来自流水线默认 ⇒ 每次提交后它都会把工作区改脏。我这次会话里反复
`git checkout --` 把它丢掉，那是和流水线对抗。**提交后 biome 再跑就是
no-op**，问题根除。
2026-09-28 10:00:10 +08:00
67def306e5
style(readme): 接受流水线的 markdown 格式化
...
三处纯格式，**无语义变化**：
- 嵌套列表 `+ ` → `- `（渲染效果相同）
- 表格分隔符 `|---|---|---|` → `| --- | --- | --- |`
## 为什么要提交而不是继续丢弃
仓库**没有 biome 配置**（无 biome.json），格式来自流水线默认。
⇒ 它每次跑都会把 README 与 cmd/gui/renderer/app.js 改成 dirty 工作区。
我这次会话里反复 `git checkout -- README.md cmd/gui/renderer/app.js`
把它丢掉，**那是在和流水线对抗，纯属白费力气**：每次提交后它又变 dirty。
提交后 biome 再跑就是 no-op ⇒ 永久不再 churn。
★ 教训：可自动复现的格式化，正确做法是**接受并单独提交**，
而不是每次手动回退。回退只是把冲突推迟到下一次提交。
2026-09-28 09:40:37 +08:00
bf2d6867e7
test(webui): 压测补齐另外 3 个插件的路由 —— 我第一版漏了两个
...
第一版只压了 webui 的 `/api/v1/*`。核实后发现 **8080 上注册 HTTP 路由的
插件有 4 个，监听端口还不止 8080**（`ss -ltnp` 实测）：
| 端口 | 插件 | 路由 | 认证 |
| --- | --- | --- | --- |
| 127.0.0.1:8080 | webui | /api/v1/* | config_webui.api_key |
| | remotedevice | /api/v1/device/* | config_remotedevice.ws_token |
| | kbtree 子路径 | /api/v1/knowledge/tree/{categories,counts} | config_webui.api_key |
| 127.0.0.1:9876 | **pluginmgr** | /plugins（**无** /api/v1） | **无需认证** |
| 127.0.0.1:9892 | **kbtree** | /categories /counts（**无**前缀） | config_kbtree.token |
| 127.0.0.1:9890 | remotedevice | 设备 WS 网关（非 REST） | 不压 |
⇒ 「打 /api/v1/*」这个假设只对 8080 上的 webui 成立：`:8080/plugins`
实测 **404**。三套认证各不相同，脚本现在按分组取对应 token。
## 端点 18 → 24
新增：`/api/v1/device/online`（remotedevice）、`/plugins`（pluginmgr）、
`/categories` `/counts`（kbtree 根路由）、以及 webui 前缀内的
`/api/v1/knowledge/tree/{categories,counts}`。
收 `/api/v1/device/online` 之前逐行读过实现：仅 `GET` +
`registry.OnlineList()`，纯读。**不收** `/device/push`（向真实设备下发）、
`/device/ws`（长连接）、`/device/{id}`（语义未核实）。
## 实测（24 端点 × 3 档，2880 请求零失败）
| scale | 请求 | 吞吐 | p50 | p95 | p99 | max | 成功 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 480 | 953 req/s | 4.0ms | 23.0ms | 34.7ms | 40.6ms | 480/480 |
| 2 | 960 | 1310 req/s | 7.9ms | 32.4ms | 48.4ms | 72.3ms | 960/960 |
| 3 | 1440 | 1422 req/s | 12.0ms | 42.7ms | 60.5ms | 88.7ms | 1440/1440 |
压测期间服务端 `active`、0 个 5xx。
**p99 随并发单调上升**（34.7 → 48.4 → 60.5ms），符合排队预期。
上一轮曾出现 scale=2 的 p99 反常地高于 scale=3，当时机器上另一个 agent 的
chromium 占 766% CPU ⇒ 环境噪声，已明确不作为性能特征。
## 又踩了一次前缀的坑（两种方向都踩了）
1. 「表里存路径后半段 + 代码按 group 补前缀」⇒ remotedevice 拼成
`/api/v1/api/v1/device/online` ⇒ 落到 webui 兜底路由、
返回 **200 + 登录页 HTML**（靠 `looks_like_login_page()` 抓到）。
2. 反过来「表里已含前缀 + 代码仍补」⇒ webui 组全 404。
⇒ 最终统一成**表里写完整路径、代码不补**。两次都是靠 `--probe` 抓到的，
这正是它存在的理由。
## 顺带修掉我写错的一处
`contextlib.suppress(sqlite3.connect)` —— `connect` 是函数不是异常类，
`suppress` 会抛 `TypeError`。改回显式 `try/except sqlite3.Error`，
并把 `config.db` 的打开方式保持 `mode=ro`（压测不碰生产库写路径）。
## 文档里我自己写错又改正的一处
§7 表格里 scale=1 一行先写成 1680/2013/5.4ms，核对 JSON 后实为
**480/953/4.0ms**（24 端点 × 20 轮）。已订正，并加了提交前的
JSON 逐项比对，三档现已全部一致。
2026-09-28 09:33:22 +08:00
034945890c
test(webui): WebAPI 只读端点压测 + 实测 2160 请求零失败
...
打的是**生产实例** 127.0.0.1:8080。
## 为什么只压只读端点
压测绝不能改状态。18 个端点**逐个探测确认**是 GET + 只读：
小（/status…/proxy/services，104B–1.8KB）、中（/plugins…/knowledge，
4.4KB–53KB）、大（/kernel 157KB、/memory/graph 338KB、/knowledge/tree 425KB）。
**排除**：/chat（真调 LLM）、/chat/interrupt（中断在跑的任务）、
/settings/* 与 /plugins/*（改配置）、/login /logout（改会话）、
knowledge/memory 写接口、/device/*（控制真实设备）。
## ★ 两条判据（都不是"看有没有报错"）
### 1. 必须先 `--probe`：webui 无认证时返回 200 + 登录页 HTML
含 `THEME_PLACEHOLDER`，**状态码是 200**。只看 `http_code` 会把登录页
当成健康响应 ⇒「全部 200」是假的。脚本因此额外校验响应体。
### 2. 端点表漏了 `/api/v1` 前缀 ⇒ 18 个端点全 404
第一版把端点存成路径后半段（`"/status"`），拼出
`http://127.0.0.1:8080/status `，而真实路径是 `/api/v1/status` ⇒
**全部 404**，同一时刻 curl `/api/v1/status` 却是 200。
⇒ **压测脚本必须先 probe 再压。** 不 probe 的话那一跑的结论会是
「webui 全挂」，完全错误。这条已写进手册。
## 实测（2026-09-28）
| scale | 请求 | 吞吐 | p50 | p95 | p99 | max | 成功 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 360 | 779 req/s | 6.7ms | 26.8ms | 45.5ms | 51.6ms | 360/360 |
| 2 | 720 | 788 req/s | 12.2ms | 52.6ms | 163.0ms | 213.5ms | 720/720 |
| 3 | 1080 | 1038 req/s | 16.4ms | 60.4ms | 79.7ms | 123.0ms | 1080/1080 |
**2160 请求零失败**；压测期间服务端 `active`、0 个 5xx、0 个 webui 错误，
QQ/agent 链路未受影响，homed CPU 仅 1.2%。
### 重响应不是瓶颈（并发 1 → 16）
| 端点 | 大小 | 并发 1 | 并发 16 | 吞吐 |
| --- | --- | --- | --- | --- |
| /status | 0.2KB | 104 req/s | **1781 req/s** | 320KB/s |
| /kernel | 153KB | 126 req/s | 375 req/s | 19 → **57 MB/s** |
| /memory/graph | 330KB | 70 req/s | 410 req/s | 23 → **135 MB/s** |
| /knowledge/tree | 415KB | 79 req/s | 717 req/s | 33 → **297 MB/s** |
大 JSON 端点的 p50 **不随并发上升**（/knowledge/tree 12.3ms → 8.9ms，
排队更充分、效率更高）⇒ 瓶颈不在 JSON 序列化。
## ⚠ 一处未下结论的观察
scale=2 的 p99（163ms）反而**高于** scale=3（79.7ms）。看着反常，但当时
机器上另一个 agent 的 chromium 占 **766% CPU**（另有 cjpm/cjc 在编译）
⇒ 是**环境噪声**。
**未在可比条件下重测就不下结论** —— 不拿这一组当性能特征。要判定需先
固定负载条件再跑。这条也写进手册。
## 顺带
ruff 报的三条 blocker 都修了：`pct()` 空样本不再抛错（调用方直接拿去做
f-string 格式化）、写 JSON 失败明确报错而非静默丢报告、错误体读取用
`contextlib.suppress` 免得二次异常盖掉真正的状态码。
2026-09-28 09:22:16 +08:00
3b08f04897
fix(gui): 401 重试无限递归 —— 我上一个优化放大的 bug
...
## 真机实测发现的
Xvfb + Electron + CDP 真跑，发现 `api()` 的 401 分支**无限自我递归**：
第1次: lock=false → 重登 → lock=false → return api() ← 递归
第2次: lock=false → 重登 → lock=false → return api() ← 又递归
…
那把锁的语义本该是「已经重登过一次，别再登」，但它在递归**之前**就被
清掉了 ⇒ 每层递归看到的都是 `false`。真机实测 **fetch 被调 13 次、
重登 12 次**才被我的探针上限截断。
## 为什么这与我的上一个提交直接相关
`7ff0331` 把 401 分支的固定等待从 800ms 降到 30ms（修「认证过期时每个
请求白等 0.8s」）。但重试**没有次数上限** ⇒
- 改前：每 800ms 慢速空转
- 改后：每 30ms 快速烧 CPU + 反复打服务端
**我的优化把这个 bug 放大了。** 真机上探针调用 `api()` 直接挂死，
我起初还以为是我的测试写法问题。
## 修法
两处递归点（真 401 / 门户返回 200 但内容是登录页）都改成：
try {
return await api(p, o);
} finally {
window._haReloginLock = false;
}
`finally` 保证递归抛错时也释放锁 —— 否则会把后续所有请求都锁死成直接 401。
## 判据 retry-guard.test.mjs
在 `node:vm` 沙箱里跑**真实抽出的 `api()`**，用恒回 401 的 `fetch` 驱动，
统计真实调用次数。
### 写这条判据时踩的四个坑（都记在文件里）
1. **先给了假绿灯**：把 401 分支当独立函数体执行，但那块以
`return api(p,o)` 结尾、外面没有调用它的上下文 ⇒ 我从未真正进入那个
`if` ⇒ `api 递归=0` ⇒ 什么都没测到。改成跑**真实 api()** 才对。
2. **递归时忘了保持 `r.status===401`**：真实场景是「重登后凭据仍是错的」。
漏了它 ⇒ 递归那层不进 401 分支 ⇒ 又一次假绿灯。
3. **沙箱 `setTimeout` 只记录不执行**：`api()` 用它做超时控制
（`setTimeout(() => ctl.abort(), to)`）⇒ AbortController 永不被 abort
⇒ 表现为「fetch 只调 1 次、8000ms 被当成 401 等待」。
4. **沙箱缺 `clearTimeout`** ⇒ 抛 `clearTimeout is not defined` ⇒
整段在 fetch 之后就断了 ⇒ 永远走不到 401 分支。
★ 共同点：**沙箱不完整 ⇒ 静默地什么都没测 ⇒ 假绿灯**。
判据自己给假绿灯比没有判据更危险。
### 变异测试（精确锚点，验证判据真能抓）
把第一处 try/finally 退回「递归前清锁」⇒ 判据立刻红
（`fetch 被调 13 次`）；恢复后全绿。
★ 第一次做这个变异时我误判「判据漏抓」—— 实际是我的变异脚本用了模糊
锚点、**压根没改到文件**（`grep` 显示 return await 从 2 变 1，但 `sed`
命中的是另一处）。两个信号矛盾时先坐实文件状态，别急着改判据。
## 顺带把 `make test` 的门禁修好（1f2b078 / 95bdd18
2026-09-28 09:11:58 +08:00
db483c2c0c
docs(runbook): 记「判断线上跑哪次构建」的正确判据（我今天差点白部署）
...
## 线上其实已经是修好的版本
去部署 `1b95d0e`（webui 总览 5 个 KPI 空）前核实，发现：
/api/v1/status → {"commit":"1b95d0e", "startedAt":"2026-09-27T23:23:39"}
23:23 那次部署**不是我做的**（我只在 21:50 部署过），已经包含
`1b95d0e`。`/api/v1/kernel` 里 5 个 KPI 依赖的字段也全部有值
（`plugins` 39 个、`llm`/`memory`/`documents`/`runtime`/`onnx` 非空）。
⇒ **不需要部署。**
## ★ 为什么 `strings` 不能用来判断
webui 等插件的静态资源是 `//go:embed` **编译进二进制**的
（`internal/plugins/webui/handler.go:27`），内容取决于**构建时**磁盘上的
文件。⇒ 已提交但未部署的改动，线上二进制的 `strings` 里**也可能**
出现新代码片段。
我据此差点白重启一次生产。同一天还撞上**字节数完全相同**的巧合
（86811464），更掩盖了这点 —— 大小相同更让人以为"没变化，不用管"。
## 正确的判据顺序
1. `/api/v1/status` 的 `commit` —— 线上在跑什么
2. `git log <commit>..HEAD` —— 差哪些提交
3. 那些提交里**有无运行时改动**（`internal/`、`cmd/`）—— 只有它需要部署
4. 文档 / 判据 / 部署脚本类提交**不需要**部署
## ⚠ 那条命令必须带认证头
无认证时 `/api/v1/status` 返回**登录页 HTML**（200 + `THEME_PLACEHOLDER`），
`grep '"commit"'` 匹配不到 —— 看起来像"命令没输出"，实际是认证缺失。
与 GUI 客户端 `api()` 专门检测 `THEME_PLACEHOLDER` 是同一件事。
## 顺带：内置插件 vs 独立二进制
`internal/plugins/<name>/` 编译进 homed；`plugins/<name>/plugin.bin`
是独立插件，要单独构建部署。**目录存在不等于有独立二进制** ——
`plugins/webui/` 目录存在但 **0 个文件**，走内置。
实测（2026-09-28）：`webui`/`cmd`/`seq` 内置，`qq` 独立。
改内置插件只需重编 homed。
2026-09-28 08:52:12 +08:00
f96f67707a
feat(watch): 站点漂移巡检（只读，有差异才提醒）
...
`site-drift-watch.sh` 巡检 192.168.2.106 上的两个站，**只读不动**：
不构建、不上传、不碰线上任何文件。档位是「有差异就提醒」而不是
「自动推」—— 文档站发错了是公开可见的，宁可等人点一下。
判三类信号：
1. 线上漂移：.106 上的站 ≠ 本机产物/site 源（逐字节 md5 清单比对）
2. 源码漂移：git HEAD 比产物新 ⇒ 提交了但没重新构建部署
3. 探活失败：.106 或 NapCat 挂了（比文档漂移紧急）
不复用 `deploy-sdk-site.sh --check`：那脚本输出是给人看的彩色文本，
拿来当机器判断依据太脆（改个文案就失效）。md5 清单逻辑很短，
这里复刻一份并在注释里指向 deploy-sdk-site.sh 保持同步。
## `.drift-watch/` 加入 .gitignore
里面的 `state` 是运行时状态（含时间戳与指纹，每次跑都变），不该入库。
## 提交前核实（两处我的检查写错了，脚本本身没问题）
- 我查"凭据"命中 1 处 ⇒ 实为注释里的「烧 token」，指 LLM token 非密钥。
真实密钥形态（`sk-*` / `password=`）**0 处**。
- 我查"部署调用"命中 6 处 ⇒ 全是**注释与提示文本**（提醒人去跑
`deploy-sdk-site.sh`）。实际执行 `rsync`/`scp`/调用部署脚本**均 0 处**，
`rm -rf` 0 处 —— 与它「只读」的声明一致。
- `set -uo pipefail` 少了 `-e`：**有意为之**。巡检要在某项检查失败时
继续跑完其余项，`-e` 会中途打断。实测跑一次四项全绿、无差异。
2026-09-28 08:45:03 +08:00
95bdd18827
fix(make): test-gui 不再被前序失败短路（门禁曾形同虚设）
...
## 问题
`make test` 原本是 make 的**依赖链**：
test:
$(GO) test ./...
@$(MAKE) test-gui
@$(MAKE) csrc-test
...
`go test ./...` 一旦 FAIL，make **立即中止** ⇒ 挂在它后面的目标一行都不跑。
实测坐实：`internal/plugin/proc` 偶发 FAIL 时，`make test` 的日志里
**找不到 test-gui 的任何输出** —— 刚接进去的 GUI 判据根本没被执行。
门禁挂上去等于没挂。
## 为什么不能简单用 `-@$(MAKE) test-gui`
`-` 前缀会**吞掉 GUI 判据自己的失败码** —— 判据红了 make 照样绿，
等于给假绿灯。那比短路更糟：它让人以为门禁在生效。
## 做法
全部跑完，最后统一判退出码：
test:
@rc=0; $(GO) test ./... || rc=$$?; \
$(MAKE) test-gui || rc=$$?; \
$(MAKE) csrc-test || rc=$$?; \
$(MAKE) check-csrc || rc=$$?; \
$(MAKE) check-codec-cgo-only || rc=$$?; \
exit $$rc
既保证每一步都跑，也保留每一步自己的失败。
## 验证（注入失败实测，不是推断）
往 `TestKillReturnsEvenWhenGrandchildSurvives` 里塞 `t.Fatal` 制造必然失败：
| 验证项 | 结果 |
| --- | --- |
| `make test` 退出码 | **2**（非 0，失败被上报） |
| proc 包 FAIL | 抓到 |
| **GUI 判据输出** | **仍执行** ← 这是要证明的那件事 |
| csrc-test | 也执行了 |
| 汇总 | ok=43 FAIL=1 |
随后已恢复该测试文件（`git checkout` + 确认 0 处残留 `t.Fatal`），
并复跑该包确认 ok 10.6s。
全绿路径也验过：`make test` 退出码 0、ok=44 FAIL=0、GUI 判据执行。
2026-09-28 08:43:04 +08:00
a96ba70db9
docs(make): 记下 proc grandchild 测试本身不稳定（现象，未下根因）
...
`make test` 的后置验证里发现 `internal/plugin/proc` 会 FAIL，实测形态：
- 单独跑**同一命令**：`ok 11.5s` / `FAIL` 交替出现（至少各一次）
- 全量并发跑：曾 600s 超时（`panic: test timed out after 10m0s`），
也曾 90s 就 FAIL
- 失败测试固定是 `TestKillReturnsEvenWhenGrandchildSurvives`，
伴随日志 `[proc] audit 退出: signal: killed`
与本次改动（7ff0331 SSE 退避、1f2b078 判据）无关联：改的是
`cmd/gui/renderer/app.js` 与判据脚本，没碰 `internal/plugin/proc`。
症状**像** fork/kill 的进程组语义在容器/并发下不稳（孙进程 setsid
脱组后杀不掉 ⇒ Wait 挂死），但**尚未定位到根因**，因此 Makefile 里
只记现象、不下结论。
★ 记这一条是因为我自己先踩了坑：一开始连跑 3 次全绿，我就准备写
「单跑稳定、仅并发偶发」；紧接着同一命令又 FAIL 了。**单跑通过不能
当结论** —— 这类 fork/kill 测试必须重试才能给出可信判断。
2026-09-28 08:30:44 +08:00
1f2b078322
test(gui): 行为判据 + 接进 make test（此前无人能跑）
...
## 为什么加行为判据
`sse-backoff.test.mjs` 检查源码**形状**（有没有清零、上限自不自洽）。
但形状对 ≠ 行为对：把清零写到 `reader` 取流**之后**，形状检查照样通过，
而实际仍在用旧计数重连。
新判据 `sse-backoff-behavior.test.mjs` 从**真实源码**抽出退避表达式并
在 `node:vm` 沙箱里求值，用假状态记录实际等待。实测量化：
历史累计 8 次后建连成功再断流 → 等 1000ms（改前会是 32000ms）
连续 6 次「建连成功→断流」 → 1000,1000,1000,1000,1000,1000ms
## 变异测试（都抓到）
| 变异 | 形状判据 | 行为判据 |
| --- | --- | --- |
| 清零挪进 setTimeout 内 | 通过 | **红** ← 只有行为抓得到 |
| 删掉「建连后」清零 | **红** | 通过 ← 暴露了行为判据的盲区 |
| pump 上限改回 60000 | **红** | — |
| 30ms 改回 800ms | **红** | — |
第二行促成了「行为 0」：建连后清零原本不在被验证的路径上
（抽取锚点只抓 pump 那一处），补了独立检查。
## ★ 判据本身踩的坑（都写进文件注释）
1. **别包假 setTimeout**：`exprSrc` 本身就是延迟数值
（`setTimeout(fn, <延迟>)` 的第二个参数），包一层让结果恒为 null，
三项全红。
2. **别用 `new Function`**：等价于 eval，是安全反模式。改用 `node:vm`
的 `runInNewContext`（官方受限环境，拿不到宿主作用域，带 1000ms 超时）。
3. **一个正则兼容两种幂运算形态会取错捕获组**：`Math.pow(2,x)` 比 `2 ** x`
多一层括号 ⇒ 组数差 1 ⇒ `r[length-1]` 取到 NaN。
最终形态是**定位与取值分离**：正则只定位（不捕获数字），数字单独取。
4. **`String.raw` 拼接正则不可用**：`\\.` 保持字面双反斜杠（去找字面的
"\."），且拼接后捕获组编号不可控。
## ★ 这些判据此前没有任何入口会跑
`cmd/gui` 是**纯 Electron 目录**（0 个 `.go`、无 `go.mod`），Go 通配会
跳过它 ⇒ 判据挂着也没人执行。现已接入：
- `cmd/gui/package.json` 加 `"test"`
- `Makefile` 加 `test-gui` 目标，并挂进 `test`
- 无 node 时显式 SKIP 而不是静默通过
```bash
make test-gui # 或 cd cmd/gui && npm test
```
## 顺带说明
`go test ./cmd/gui` 报 `no Go files [setup failed]` **不是回归**：
该目录 0 个 `.go` 文件，只有**显式点名**才报。仓库门禁用的三种形态
（`go test ./...`、`go test ./cmd/...`、Makefile 的 `test`）全部通过。
2026-09-28 08:16:51 +08:00
7ff0331c50
fix(gui): SSE 退避计数从不重置 —— 消息流不稳的一个共因
...
## 现象
用户报 GUI「消息流不稳、动画不连贯、看着卡」，四类症状都有：滞后、
卡顿、闪断、资源高。定位到**同一个**共因，不是四个独立问题。
## 根因 1：退避计数只增不减
`state._sseRetryAttempts` 的自增只发生在 `connectFetchSSE` 的 catch 分支
（连接**建立**失败），而 `pump()` 中途断流后的重连**只读它算延迟，
从不清零**：
Math.min(1000 * Math.pow(2, Math.min((state._sseRetryAttempts || 0), 5)), 60000)
后果：只要历史上累计过 5 次，**之后每次断连都固定等 32s** —— 哪怕这次刚
成功连上、说明服务端和网络都好好的。而"成功连上"恰恰是最该重置的信号。
修：建连成功后清零（reader 取流之前），断流重连前再清一次。
## 根因 2：外层 60000 上限是死代码
`2^5 = 32s < 60s` ⇒ `Math.min(..., 60000)` 永远达不到，**真实封顶是 32s**。
改为 32000，让声明值与实际一致（判据会验这一条）。
catch 分支那处保留 60000：它语义不同（连接根本没建起来，attempts 已 +1，
退避本就该更长），上限放宽无害 —— 判据按各自语义分别判定，不一刀切。
## 根因 3：401 重试固定空等 800ms
`api()` 里每个 401 都走 `syncConnAuth()` + 固定 `setTimeout(800)` 才重试。
认证过期时**每个**请求白等 0.8s，并发几个就叠加成明显的「卡」。
`syncConnAuth` 本身就是 await 的，返回即代表凭据就绪 ⇒ 降到 30ms
（留一点让 setAuth 的 cookie 落盘）。
真 401 与「门户返回 200 但内容是登录页」两个分支都有这处等待，两处都改。
## 判据：cmd/gui/sse-backoff.test.mjs
`cmd/gui` 无测试框架（package.json 只有 start/dev），app.js 是 203KB 单文件。
判据从**真实源码**提取退避表达式并求值，而不是抄一份逻辑重写 ——
抄写的那份会和真实代码漂移，而漂移本身就是这个判据要防的东西。
3 项 + 变异测试（删清零 / 改回 60000 / 改回 800ms，三次全部被抓到）。
### 判据本身踩的三个坑（都记在文件注释里）
1. **正则两种形态括号数不同**：`Math.pow(2, x)` 比 `2 ** x` 多一层括号。
早先只按 pow 写，biome 规范化成 `**` 后**静默失配**。
2. **不能用 String.raw 拼接正则**：`\\.` 保持双反斜杠字面量（去找字面的
"\."），且拼接后**捕获组编号不可控** —— 实测 cap 解出 NaN。
3. **一个正则兼容两种形态会取错捕获组**（组数差 1）⇒ 改为
**定位与取值分离**：正则只负责定位（不捕获数字），数字单独取。
### 只认 pump 那处上限自洽
catch 那处 `60000` 不可达但无害（语义是"最多等一分钟"）。
判据对两处**分别**判：pump 要自洽，catch 只要有有限上限。
## 排查时坐实的两件事
- **`go test ./cmd/gui` 报 `[setup failed]` 不是仓库问题**：`cmd/gui` 有
**0 个 `.go` 文件**（纯 Electron），Go 通配会跳过它，只有显式点名才报。
`go test ./...` 实测退出码 0、43 包 ok、0 处提及 cmd/gui。
- **biome 会顺手把 `function () {}` 改成箭头函数**（本次混入 12 行）。
与本次修复无关，已从 HEAD 干净重放，最终 diff 只有 3 处实质改动
（24 增 3 删，零无关格式化）。
2026-09-28 07:59:15 +08:00
1b95d0ef2d
fix(webui): 修总览 KPI 长期空值（我上轮懒加载改出来的）＋星图改银色
...
### ★ 严重问题：总览页 8 个 KPI 里有 5 个是空的
线上实测（https://homeagent.jianfgit.xyz） ：
["运行中状态","1h 22m 18s运行","0插件","v1.4.0…版本","—LLM",
"—记忆","—文档","—运行时"]
对照 state：{"status":true,"kernel":false,"settings":0,"runtime":true}
根因是**我上一个提交（8a36be0 按页签懒加载）引入的**：
总览的插件数/版本/LLM/记忆/文档/运行时全部读 `state.kernel`
（`updateOverview` 里写作 `(k && k.plugins)` 这类安全取值），
而我把 kernel 从 overview 的数据块里删掉了。
⇒ 缺数据时不报错、**只显示「插件 0、记忆 —、文档 —」**，
看起来像「服务坏了」而不是像 bug —— 这类静默降级最难自查。
★ 教训（已写进代码注释）：依赖分析必须覆盖**整个调用链**。
我当初只 grep 了 `renderOverview` **直接**读的 state.*，漏了它间接
调用的 `updateOverview`。逐页重核后确认只有 overview 漏配，其余页签
（plugins/settings/kernel 各自要的）本来就是对的。
修复：overview 的 fetch 补回 kernel。kernel 拉过一次后不再重拉
（starmapFetchBlock 的节流），152KB 只在首屏付一次。
实测：["运行中状态","1m 15s运行","17插件","v1.4.0HomeAgent版本",
"deepseekLLM","1200/893记忆","0文档","39 · 11M运行时"]
### 星图配色改银色（用户裁定）
SM_COLOR_DIM: 0x7d8a9e（灰蓝）→ 0xc8ced8（银色）。
实测 colors: ["7d8a9e"] → ["c8ced8"]
### 关于「页面还是绿色」这个现象
线上内联的颜色实测已是 0x7d8a9e，缓存头也正确
（cache-control: no-cache, no-store, must-revalidate），
浏览器复现同样是灰蓝色 ⇒ 那是**已打开标签页里的旧 JS**：
页面 HTML 变了，但没重新加载的标签页不会自己换。
本提交部署后需**刷新页面**（Ctrl+Shift+R 强刷）才会看到新配色。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com >
2026-09-27 23:20:01 +08:00
81ac13f266
docs(runbook): 补 §6 部署单元清单，并纠正一次误判的记录
...
## 补齐漏掉的单元
`cmd/` 下共 7 个可构建入口，服务端只部署 3 个：
| 单元 | 入口 | 服务端部署 |
| --- | --- | --- |
| homed（内核） | `cmd/homed` | ✅ 本机 `/usr/local/bin/homed` |
| waiter / waitercli | `cmd/waiter` | ✅ 106、30 的 `/opt/waiter/waiter` |
| 站点 | `site/`、`site_build/` | ✅ 106 的 `sites/` |
| **GUI** | `cmd/gui` | ❌ **Electron 桌面应用，随客户端分发** |
**GUI 不在服务端部署**（已确认生产无 `*.service`、无进程）。它与 waiter
是两端：GUI 用 `devicebridge_dll.js` 走设备桥协议连服务端 waiter，
`17b010d` 修的正是 GUI 侧 bind 判 ok 与登记状态暴露。
⇒ 排查 GUI 问题要看**用户机器上的客户端**，不是 `homeagent.service` 日志。
另记：核查"有没有进程"时 `ps -ef | grep -c "[e]lectron"` 会把**自己的
grep 命令行**算进去返回非 0（实测返回 2，实际 0）—— 要看列出的内容，别只看计数。
## 本机 waiter 与 106/30 不同步
本机也留了一份 `/usr/local/bin/waiter`，`v1.3.2-153-gff69127`（2026-09-25
构建），**早于** main 在 09-26 合入的那批修复（设备反复掉线、bind 判 ok、
服务端发现自动链接），因而缺它们。106/30 已是 `1.4.0`。
本机这份无进程无服务，不影响生产设备桥；更新方式已记入文档。
## 记一次误判：判定"是否已合入"要按内容查
我曾用 `git merge-base --is-ancestor ff69127 origin/main` 判定"这批提交
没进 main"，并推断"存在一条未合入、只靠 reflog 撑着的 5 提交线"。**该结论是错的。**
真实情况：这批改动在 2026-09-26 以**新 hash** 重做并进入 main，五对逐字节一致
（diff 均为 0 行）：`1acbd39`→`5467a9f`、`3d30482`→`3a860b9`、
`078517e`→`4393872`、`aaafaac`→`a15d8d0`、`ff69127`→`17b010d`。
⇒ 只查**旧 hash 的祖先关系**会误判；同一改动被重做为新 hash 时
`merge-base` 必然说不包含，而 `git merge-tree` 报的 13 个"冲突"
正是同源改动做两遍的必然结果，**不能当冲突去解**。
顺带修正一处归因：106 此前长期无 `online` 日志的成因是
`a15d8d0`（设备反复掉线/静默失联：ping 路径断连 + bind 结果无人处理），
2026-09-26 已进 main，今天部署的 `1.4.0` 包含它。
2026-09-27 23:10:49 +08:00
512effa1ad
feat(deploy): 站点部署流水线（SDK 文档站 + introduce）
...
`deploy-sdk-site.sh` 覆盖两个静态站，与 homed / waiter 是独立部署单元：
- SDK 文档站：本地 `third_party/homeagent-sdk/site_build/` → 106 的
`/vol1/docker/navi-data/sites/sdk`
- introduce：本地 `site/`（零构建，源即产物）→ `sites/introduce`
用法：`--check`（只核对差异）/ 默认（构建+部署+验证）/ `--rollback <备份名>`。
`--check` 逐字节比对，2026-09-27 核实两站线上与本地产物**完全一致**。
## 更新了一处会误导的注释
脚本原注释写「设备网关白名单只放行 ls/stat/find/cat，打不了包」。
那是 waiter 白名单**硬编码 18 条**时的状况；2026-09-27 部署 1911575
2026-09-27 23:00:04 +08:00
9640dad3b1
docs: 新增生产部署手册（homed / waiter）
...
`site-infra-runbook.md` 是**静态站 / nginx / 证书**的手册，不含 homed 与
waiter —— 两次生产部署（19:45 首次、21:50 修复）因此只存在于提交信息里，
查不到。
## 内容
**§1 homed**
- 硬前置：必须 `-tags=onnxruntime`（普通 build 只有 ~28MB，缺 ONNX Runtime）
- ★ **构建参数必须与线上一致**：不要顺手加 `-s -w`。加了产物从 86.8MB 掉到
78MB，8.8MB 的差会让人误判成"构建坏了"，而它只是被 strip 了
- `check` / `deploy` / `rollback` 三条命令与备份位置
- 部署后必核：`multimodal space active: provider=chineseclip` 才是 ONNX
真加载起来的标志，缺它说明已降级但**不报错**
- ★ 适配器升级的保护语义（`.bundled` 三种情形的判定表），并记 21:50 那次
实测：手工补过 `stream_index` 的 `openai.lua` 被正确判定为用户修改并保留
- 两次部署的真实数据对照表
**§2 waiter**
- 逐台更新、不可并行（两台连同一网关，同时重启会同时断链）
- 部署后确认 `device waiter-* online`
- 记 2026-09-27 顺手解决的悬案：106 此前无 `online` 而 30 正常，两台配置与
token 完全相同 ⇒ 差异只可能在旧二进制，8月27日那版落在"未 bind 时收到
ping 会关连接"的缺陷窗口
- `device_cmd_allowlist` 的替换语义、生效验证、幂等追加方法
- ★ 明确写**白名单只匹配命令名、不看参数**，`find -delete`/`sed -i` 仍能逃
⇒ **不要称它为"只读白名单"**
**§3 故障排查**：按"消息没反应 / 命令被拒 / 适配器异常 / 告警是否缺陷"
四条线各给命令；特别标注"群聊 not @bot"与"私聊没回"是两件事
**§4 已知未修**：三项目前是已知限制而非疏漏
文中数字均与现场核对：脚本子命令确实存在（`check`/`deploy`/`rollback`）、
生产白名单确为 22 条、两次二进制大小取自实际部署。
2026-09-27 22:25:58 +08:00
df51cd4705
fix(provider): has empty arguments 误报 —— 零参数工具被当成参数丢失
...
## 现象
部署后生产日志出现 14 次：
provider.go:414 [provider:llmsproxy] tool_call seq_list (...) has empty arguments
## 根因
原始响应里参数**完好**（从日志扒出来）：
"tool_calls":[{"function":{"arguments":"{}","name":"clawhubadapter_list"},...}]
诊断条件是 `len(tc.Arguments)==0 && tc.RawArguments==""`，而
`parseToolArguments("{}")` 走 string 分支 → `json.Unmarshal("{}", &m)`
成功且 `m != nil`（**非 nil 的空 map**）⇒ 返回空 map ⇒ 命中告警。
被点名的全是**零参数工具**（`seq_list` / `*_list` / `seq_help`，
它们的 `properties` 本来就是 `{}`）。
## 为什么必须修
不是"日志吵"。这条诊断的本职是抓「上游/适配器**真的**把参数丢了」，
真发生时会被这 14 次噪音淹没 —— **诊断日志失去信噪比就等于没有**。
## 修法
新增 `argsLookDropped(rawArgs)`，判 `RawArguments` **原文**而非解析后的 map：
- 空串 / 纯空白 ⇒ 上游没给 arguments 键 ⇒ 真丢
- 能解析成 JSON（哪怕是 `{}`）⇒ 上游确实回了参数 ⇒ 不报
- 解析失败（如半截 JSON）⇒ 参数本身是坏的 ⇒ 等同丢失
## 判据（3 条）
- `TestEmptyArgumentsDiagnosticIgnoresExplicitEmptyObject` 4 个子用例：
`{}` / ` { } ` / 完全缺失 / 只有空白
- `TestArgsLookDroppedIgnoresNonEmpty` 非空参数一律不报
- `TestArgsLookDroppedEndToEnd` 用**日志里出现过的真实 body** 走
`normalizeOpenAIToolCalls` 到判定的完整接缝 —— 单测过了但接缝不对
只有端到端抓得到
写判据时我先用错了类型：拿 `apiToolCall`（**非流式**路径的结构）喂
`normalizeOpenAIToolCalls`，vet 直接报错才纠正为 `openAIToolCall`。
两套结构并存，很容易接错缝。
## 顺带记录：另一个告警不是内核缺陷
`重复申请 stage 锁`（5 次）经排查是**插件侧**问题，内核自愈机制工作正常：
- `proc_main.go.tmpl:1569` SDK 模板在每个 stage handler 入口**自动**调
`stage.lock`；`lock.go:51` 锁**不可重入** ⇒ 同一次 `before_toolcall`
被触发两次且首次未释放就命中
- 已排除 qq 业务代码：`beforeToolcall`（plugin.go:1303-1350）只有
`ctx.Lock()`（SDK **数据**锁，与 proc stage 锁是两把锁）与纯本地调用，
无任何再次触发 stage 的路径
- 成因在插件进程侧运行时（编译进 9月14日的 `plugin.bin`，**不随 homed 部署**）
- 内核 `stage.go:102-106` 的强制释放是**有意设计**（"锁仲裁回内核"自愈，
实验 9），避免后续插件死锁；`stages.go:258` 把错误收进 `ctx.Errors`
不中断流程 ⇒ 那轮 212 秒正常跑完
两条结论都写进文档，避免以后有人当内核缺陷去修。
门禁：`-race` 通过，`go test ./internal/... ./cmd/...` 全绿。
2026-09-27 21:18:32 +08:00
554d93cc7e
docs: 两份 toolcall 文档对齐实现与部署实况
...
## 契约文档：状态头从「尚未实现」改为「已实现并部署」
生产已注册 7 个 `seq_*` 工具，但文档仍写着"设计定稿，尚未实现" ——
实现者（和读者）会以为 seq 还不存在。
新增 §9.3「实现落点」：设计稿 §8 写的是**六个** `seq_*` 工具，实现时
多了一个 `seq_when_call`（跨序列条件调用独立成工具，否则模型要手写
"先 seq_list 再挑目标再 seq_call"，多一次往返且容易挑错），并记下三项
设计之外的修正（`seq_create` O(n²)、`Store.List()` 误认任意 `.json`、
存储用 AST 而非原始文本）。
同时点明：设计条款**仍是契约**，实现与本文冲突时以本文为准并修实现。
## 修一处预先存在的失效引用
§7 末尾 `见 §4.5` —— §4 只到 4.4，该小节不存在。改为按标题名引用
（`§4「结果契约」的 ErrToolNotFound 哨兵`）：将来增删小节时不会再次失效。
自查脚本第一版把 8 个**存在**的章节误报成失效引用 —— 标题格式是
`## 1. 背景`（编号后跟 `.`），而我的正则要求编号后是空格。判据自己错了，
改成 `(\d+(?:\.\d+)*)\.?\s` 后才得到真实结果。
## 并行计划文档：部署小节 + 白名单专节
- 原「⚠ 部署前置条件（未完成）」改为「✅ 部署（已完成）」，补实际验证数据
- 记下"实例自述没有编排工具"不是说谎：生产二进制构建于 06:36、seq 引入
于 `da8841e`（更晚）⇒ `strings | grep -c internal/plugins/seq` 为 0。
这类"实例自述与代码状态不一致"应先查二进制构建时间，别急着怀疑提示词
- 新增「设备命令白名单改为可配置」：起因、替换语义、daemon 路径的疏漏
- 明确写下**已知局限**：白名单只匹配命令名、不看参数，
`find -delete` / `sed -i` / `sort -o` 仍放行 ⇒ **不要把它叫"只读白名单"**，
那会让人以为写操作被挡住了
- 记 106 此前无 `online` 日志的成因（旧 waiter 落在未 bind 时收 ping 会断连的
缺陷窗口），以及 `ssh` 吃掉 `read` 输入导致"喂了 yes 却说已取消"
删掉了初稿里一段"反引号内 `+=` 写进 heredoc 导致赋值落到子 shell"的说法 ——
脚本与 git 历史里都没有这种写法，属凭记忆误记，不能留。
文中数字均与现场核对：seq 工具 7、二进制 86784400 / 12691402、白名单 22 条。
2026-09-27 20:00:33 +08:00
f693af3960
fix(deploy): deploy-waiter 的 ssh 加 -n，否则「喂了 yes 却说已取消」
...
`do_check` 里的 ssh 会从 stdin 读，把后续 `read -p "确认更新"` 的输入吃掉 ——
于是 `bash deploy-waiter.sh deploy <ip> <<< "yes"` 里的 yes 被 ssh 消耗，
read 拿到空串，脚本静默走「已取消」分支。
症状极难定位：脚本本身完全正常、备份逻辑没问题，只是"明明喂了 yes"却
什么也没发生。5 处 ssh 统一加 -n。
2026-09-27 19:52:53 +08:00
764d1b0dd3
chore(stress): 加 waiter 远程更新脚本；修 cmp.py 的 docstring 格式
...
## deploy-waiter.sh：106 / 30 的 waiter 更新
现状（更新前）：两台都是 8月27日构建的 /opt/waiter/waiter（11,388,177 字节），
以 root 跑 waiter-remote.service，配置指向 ws://192.168.2.60:9890/…
安全设计：
- 先备份旧二进制（`$BIN.bak-<时间戳>`），失败即回滚（脚本内自动）
- **只换二进制，不动 waiter.yaml**（配置由 deploy 后单独追加）
- **逐台更新并验证，不并行** —— 两台都连同一网关，同时重启会同时断链
- 106 走 admin+sudo、30 走 root
- 验证项：服务 active + 进程时长 + **配置 md5 未变**
用法：`check`（只读）/ `deploy <ip>`（需输 yes）/ `rollback <ip>`
## cmp.py：两处格式
docstring 的 `"""` 紧贴内容、以及函数段之间缺两个空行（PEP8）。纯格式，
无逻辑改动。
2026-09-27 19:42:06 +08:00
1911575352
feat(waiter): 设备命令白名单改为 waiter.yaml 可配置
...
## 起因
白名单是源码里硬编码的正则（`homeagentAllowCmd`，18 个命令），
而 `waiter.yaml` 里**没有任何键能改它** ⇒ `find` / `grep` / `sed` / `sort` / `tr`
这些排查问题最常用的**只读**命令一律被拒。生产实测：
device_ctl_cmdrun device_id:waiter-fnnas error: command not in whitelist
命令执行完全在 waiter 侧（`device.go` 的 `exec.CommandContext`），插件侧无二次
限制；触发者是 **agent**（经 device_ctl_cmdrun），所以这道闸是机器闸、不是人工确认。
## 改动
waiter.yaml 新增 `device_cmd_allowlist`（字符串数组）：
device_cmd_allowlist:
- ls
- find
- grep
- sed
- **替换**默认集而非追加：避免"以为加了 find、结果还留着 python3 -c 任意执行"
- 留空 ⇒ 用内置默认集（★ **绝不能变成"全放行"**，那等于静默拆掉闸门）
- 匹配只取命令名**第一段**再整词匹配：`grep -rn x .` 能过，
而 `grepXxx` / `mygrep` 不会因 contains 蒙混过关；也跳过 `FOO=bar cmd` 的赋值前缀
- `deviceCmdAllowed` 是包级函数变量，由配置赋值 —— 与同文件既有的
`sendBridgeResult` 同一模式
## ★ 一次真实的疏漏（判据记着）
waiter 有**两条**设备桥启动路径：
- `main.go` 的 `startDeviceBridge` —— 交互/一次性模式
- `daemon.go` 的 `startDaemonDeviceBridge` —— `waiter --daemon`（**生产两台都这么跑**）
我最初只在 `main.go` 里赋值。daemon 路径不经过那里 ⇒ 配置**完全不生效**，
而症状是"配置写了、启动也打了招呼、命令照样被拒"，极难定位。
两处都接上了，并加 `TestDaemonPathAppliesAllowlist` 守住。
## 判据（5 条）
- `TestDefaultAllowlistStillBlocksDestructive` 默认集必须挡住
`rm -rf /`、`dd`、`chmod -R 777`、`mkfs`、fork 炸弹 ——
**这道闸存在的唯一理由**，谁把它改成"什么都不拦"这条就要失败
- `TestConfigAllowlistExtends` 配置里声明的 `find/grep/sed/sort/tr` 能过；
配置未含的 `rm -rf /` 仍被拒（证明是"替换"不是"叠加"）
- `TestEmptyConfigFallsBackToDefault` 配置为空时回退默认集，**且不放行** `rm -rf /`
- `TestCmdAllowlistFromYAML` 走**真实** `readFile` 解析 yaml（不另写一份解析，
两处会漂移，而漂移本身就是漏洞）
- `TestDaemonPathAppliesAllowlist` 守住 daemon 路径也应用配置
## 生效方式
106/30 的 `/opt/waiter/waiter.yaml` 追加 `device_cmd_allowlist`，
并更新二进制。启动日志会打印 `device cmd allowlist: N 条（来自 waiter.yaml）`
或 `默认 N 条`，便于确认配置是否真的被读到。
2026-09-27 19:41:43 +08:00
a9fe741847
chore(deploy): 补强部署后验证
...
原来只说「等 20s 看 /kernel 状态」，等于没验。进程活着 ≠ agent 起来了。
现在逐项核对，每项对应一个真实故障模式：
- 60s 内未见 'kernel ready' ⇒ 判失败并给出回滚命令 + journalctl 尾部
- 注册工具条目数（生产应 18 个左右）⇒ 少了说明插件加载异常
- 'LLM API unreachable' 次数 > 3 ⇒ 内核在 rollback 循环
（生产设了 max_retries=100000，不可达会一直重试）
- ONNX provider 相关日志 ⇒ 缺失时应是明确错误+降级，不静默假装启用
2026-09-27 19:12:12 +08:00
573f6bade7
chore(deploy): 加生产部署方案脚本（check/backup/deploy/rollback 四段）
...
## 为什么需要
生产二进制是 **`-tags=onnxruntime`** 构建（86.5MB，.rodata 62.5MB），
而普通 `go build` 只有 37MB —— 差的是 ONNX Runtime 绑定。
`deploy/packaging/package-linux.sh:139` 会显式拒绝非 onnxruntime 构建：
if ! go version -m "$homed_bin" | grep -Eq 'build[[:space:]]+-tags=.*onnxruntime'; then
echo "ERROR: homed 不是 onnxruntime 构建，拒绝打 server/full 包" >&2
也就是说：**用错构建方式部署，依存句法分析与多模态向量化会静默失效**。
这个坑我自己踩过一次（拿普通构建去比体积，才发现的），所以脚本第一步
就卡这个判据。
## 四个动作
- `check` 只读检查：服务状态、onnxruntime 标签、libonnxruntime.so、
模型资产、适配器清单。**不改任何东西**，可随时跑
- `backup` 备份二进制 + 适配器 + unit 文件，并**生成 ROLLBACK.sh**
- `deploy` check → 人工确认（输入 yes）→ 备份 → install -m 0755 原子替换
→ 重启 → 8 秒后验活；失败时打印回滚命令与 journalctl
- `rollback` 用最近一次备份回滚
## 刻意不做自动回滚
回滚要不要做、什么时候做，是人的判断。脚本只负责把状态保全好，
让回滚成为一条**可执行**的命令，而不是一个自动决策。
## 部署不会碰的东西（已在 check 里显式打印）
- **适配器文件**：`e7ec4c6` 的新逻辑在「无历史清单」时不动任何已存在的文件，
所以生产的 10 个 .lua 保持原样（含那个已含 stream_index 的 openai.lua）
- **数据目录**：51G 的 models/ 与配置都不动，部署只换二进制
2026-09-27 19:11:41 +08:00
a103618ee7
docs(plan): 补记全面压测结果与部署前置条件
...
两版隔离实例实测（规模 3 = 288 条输入），核心差异是**处理数**而非耗时：
旧版 openai.lua 缺 stream_index 透传 ⇒ 多个分片并到槽 0、参数混拼 ⇒
工具一个都没真跑，却因为「少干活」而耗时更短。
!slowbatch8 旧 0.220s / 0 个 → 新 0.409s / 8 个
并发 vs 强制串行（新版内部） N=8 加速 3.88×
调度器轰炸 288 输入 两版均 100% 通过
连续稳定性 20 轮 两版均无错误、内核无 panic
规模 1（32 条）与规模 3（288 条）结果完全一致 ⇒ 可复现。
同时记录部署前置条件：生产是 -tags=onnxruntime 构建（strip 后 75MB vs
普通构建 28MB），package-linux.sh:139 会显式拒绝非 onnxruntime 构建。
本次改动未触及任何 ONNX 路径，故压测结论对生产成立，但必须走
deploy/packaging/build.sh 才能部署。
2026-09-27 19:00:53 +08:00
146a71f11b
docs(plan): 记录更新前后全面压测结果与部署前置条件
...
两版隔离实例实测（规模 3 = 288 条输入），核心差异是**处理数**而非耗时：
旧版 openai.lua 缺 stream_index 透传 ⇒ 多个分片并到槽 0、参数混拼 ⇒
工具一个都没真跑，却因为「少干活」而耗时更短。
!slowbatch8 旧 0.220s / 0 个 → 新 0.409s / 8 个
并发 vs 强制串行（新版内部） N=8 加速 3.88×
调度器轰炸 288 输入 两版均 100% 通过
连续稳定性 20 轮 两版均无错误、内核无 panic
规模 1（32 条）与规模 3（288 条）结果完全一致 ⇒ 可复现。
同时记录部署前置条件：生产是 -tags=onnxruntime 构建（strip 后 75MB vs
普通构建 28MB），package-linux.sh:139 会显式拒绝非 onnxruntime 构建。
本次改动未触及任何 ONNX 路径，故压测结论对生产成立，但必须走
deploy/packaging/build.sh 才能部署。
2026-09-27 19:00:19 +08:00
6a8a4dc373
test(stress): 补更新前后全面对比脚本（cmp.py），修 blast 的计数错误
...
## cmp.py：更新前后对比的四个维度
★ 每轮都记录**处理数**（响应里有多少个工具结果标记）与**是否出现 error 帧**，
任一不符即记失败。理由：工具调用这一路的失败模式几乎都是**静默**的 ——
工具没跑、参数混拼、只处理了第一个 tool_call，都不报错只是结果不对。
"跑完没崩"完全不能说明它 work。
1. **批内工具调用**：!slowbatchN 在两版上各跑几轮，比中位耗时与处理数
2. **并发 vs 强制串行**（新版内部对照）：!slowbatchN vs !serialbatchN
3. **调度器并发轰炸**：多连接并发排队，算通过率
4. **连续稳定性**：20 轮无错误率
## 修掉 mock 的 !serialbatch 缺失
之前只在 /tmp 的临时副本里加过，没进仓库，导致 cmp.py 测「强制串行」时
那个 marker 根本不存在 —— 测出来的"串行"其实是并发，**加速比是假的**
（0.34x / 0.31x，看起来并发比串行慢）。已加回并说明它的用途：跨版本做不了
并发/串行对照（旧版适配器缺 stream_index，工具一个都没真跑），只能在
同一套内核上做。
## 修掉 blast 的计数错误
第一版按 `conns * inputs` 起线程、每个线程又跑 `inputs` 轮 ⇒ 总输入数是
conns×inputs²，分子分母量纲不一致，算出过 **"128/32 = 400%"** 这种荒谬数字。
现在：恰好 conns 个 worker、每个跑 inputs 轮；且分母用**实际发出的**输入数
（含连接失败的），否则连接失败时通过率会虚高。
## 踩过的两个坑（都写进注释）
- 内核 `task.go:353` 有输入去重（`isDuplicateInput`，为 webui 断线重连重放
而设），相同文本被丢弃并回空响应 ⇒ 每轮输入必须带唯一后缀
- cli 的 auth 帧本身就是 `{"type":"response"}` ⇒ 必须先吃掉它再开始收集，
否则第一轮的"终止帧"是 auth，测出来耗时恒为 0
2026-09-27 18:56:25 +08:00
e7ec4c6b0a
fix(lua): 内置适配器按内容自动更新，替代「文件已存在就跳过」
...
## 原机制是这次全部误判的根源
if _, err := os.Stat(dstPath); err == nil { continue }
**升级二进制永远不更新已部署的适配器文件。** 于是"改了仓库 ≠ 生产生效"，
而这个机制让同类问题可以长期潜伏：
2026-08-26 15:46 生产 openai.lua 手工补上 stream_index 透传
2026-08-26 16:10 cfd1653⚠️ 为什么不能无条件覆盖：adapter_path 是可配置项，用户可以把 adapter_path
指向自己维护的适配器。静默覆盖等于丢弃他们的修改，而且**没有报错**。
## 判据（两个方向都要测）
- TestWriteBundledAdaptersSkipsUserModified 用户改过的**必须保留**，
且改完仍能正常加载（fixture 必须功能完整，否则会因为缺钩子函数而失败 ——
那是 fixture 问题，不是保护逻辑问题）
- TestWriteBundledAdaptersUpdatesStale 落后于新内嵌的**必须被更新**，
且**幂等**（三跑不再改写任何文件）
★ 第二条是必要的：只测保护的话，**一个"永远不覆盖任何文件"的实现也能全绿**
—— 而那正是要修的病。
## 代价（必须知道）
**升级到本版本的这一次，已部署实例的适配器不会更新**（没有历史清单可比）。
从第二次升级起自动生效。要立刻生效就删掉 DataDir/adapters 让内核重新解包。
对本次修的 8 个适配器而言：生产此刻用不到（三个源 llmsproxy/visionllm/
justworker 全是 openai.lua），所以不影响运行；将来启用 deepseek 等源时，
自然就是修复版。
## 顺带
`bundledAdapterNames` 从 writeBundledAdapters 里提出来成包级变量 ——
writeBundledAdapters 与体检判据共用，避免两处各写一份而漏掉某个
（漏掉的后果是该适配器永远不会被更新）。
2026-09-27 18:46:51 +08:00
eb5e8fdceb
fix(lua): 补齐 6 个适配器的流式 tool_calls 支持
...
体检判据（TestAllBundledAdaptersStreamToolCallStatus）报出的三类问题，
本提交解决其中两类；第三类（gemini）未动，原因见下。
## ① OpenAI 兼容族：github / groq / mistral（3 个）
它们的 transform_stream_chunk 与修复前的 deepseek **逐字相同** ——
只透 content/done，tool_calls 处理只存在于 transform_response（非流式）。
后果与 deepseek 相同：流式模式下工具调用全部丢失，模型调不动任何工具，
且**没有任何报错**。生产当前未启用这三个源，但按预设配置的用户会踩到。
照 deepseek 的修法补上（含 reasoning_content 透传）。
## ② 嵌套形态 + 键名错：server / kimicode / anthropic / ollama（4 个）
这四个**有** tool_calls 处理，但发的是：
{ index = N, id = ..., ["function"] = { name = ..., arguments = ... } }
而 homed 的 `agentAPI.ToolCall` 是**扁平**结构，json tag 为：
id / type / name / arguments / raw_arguments / stream_index
两处都是**静默**失效（Go 侧按 json tag 反序列化，取不到就是零值，无报错）：
- **嵌套** `["function"]` ⇒ `name` / `raw_arguments` 取零值
⇒ flush 时判「无 name」丢弃，或参数为空
- **键名 `index`** ⇒ `StreamIndex` 取零值
⇒ 多个分片并到同一个桶，argsRaw 混拼 ⇒ 每个工具报「参数不是合法 JSON」
而**一个都没真跑**
已逐项对齐为扁平 + `stream_index`。协议差异都保留：
- anthropic：`content_block_start` / `input_json_delta`，续传片 name 留空
（内核按 stream_index 累积，补齐 name 后才 flush）
- ollama：tool_calls **整条一次发完**（不分片），故 stream_index 取数组下标
## ③ gemini 未动
它的流式函数处理 `candidates[].content.parts`，**全文件没有任何
tool_calls / functionCall 处理** —— 连非流式路径也没有。补它不是"对齐"
而是新实现，且 gemini 的 functionCall 形态（`functionCall: {name, args}`，
args 是对象而非 JSON 字符串）与 OpenAI 族不同，需要单独判据。
生产三个源（llmsproxy / visionllm / justworker）全部用 `openai.lua`，
不阻塞。留作独立项。
## 判据
- TestOpenAICompatibleFamilyHandlesStreamToolCalls 5 个 OpenAI 族适配器，
逐个验证 tool_calls 未丢 + stream_index 正确
- TestAnthropicAdapterEmitsFlatToolCallsWithStreamIndex 用 **Anthropic 协议**
的 fixture（不用 OpenAI 的，否则会因"不适用该 chunk"跳过 —— 看着绿，
实则没测）
- TestOllamaAdapterEmitsFlatToolCallsWithStreamIndex 用 Ollama 协议形态
- TestDeepSeekAdapterHandlesStreamToolCalls 单列，因它有源预设指向
★ 三个判据按**协议**分文件而非逐适配器：这几个文件的流式函数逐字相同，
共用一个 fixture 会因协议不适用而静默跳过 —— 那等于没测。
## 体检分类
修前: ✓ [openai] ⚠ [kimicode server] ✗ [anthropic deepseek gemini github groq mistral ollama]
修后: ✓ [openai deepseek github groq mistral] ⚠ [] ✗ [gemini]
2026-09-27 18:34:33 +08:00
a6a025028d
fix(lua): deepseek 适配器的流式路径处理 tool_calls（此前全部丢失）
...
## 缺陷
deepseek.lua 的 tool_calls 处理只存在于 `transform_response`（**非流式**路径），
而 `transform_stream_chunk` 只透 content/done：
return json.encode({ content = delta.content or "", done = (fr ~= nil) })
于是 deepseek 源在**流式**模式下工具调用全部丢失 —— 模型调不动任何工具，
且**没有任何报错**，只是"工具好像不听话"。
## 为什么难发现
- 非流式路径是好的 ⇒ 端到端手工测试也过
- 内核的 tool call 循环默认走**流式**（provider.go 的 stream 分支）⇒ 实际不可用
- 功能判据（core 包的批内测试）直接构造 `agentAPI.StreamChunk{}`，
**绕过适配器** ⇒ 测不到这一层
配置里 `deepseek` 源预设指向 `adapters/deepseek.lua`，所以任何按预设配置
的用户都会踩到（生产当前未启用该源，配置里 deepseek 相关键为 0）。
## 修法
照 openai.lua 的做法在流式路径补上：OpenAI 兼容格式
`{function:{name,arguments}, id, type, index}` → homed 扁平结构
`{id, type, name, raw_arguments, stream_index}`，含 reasoning_content 透传。
两个容易踩的点也写进注释：
- **不能按 name 过滤**：流式续传片 name 为空但携带 arguments，
内核按 stream_index 分桶累积
- **必须透传 stream_index**：否则多个分片并到槽 0、argsRaw 混拼
## 判据
新增 TestDeepSeekAdapterHandlesStreamToolCalls：喂两个含 tool_call 的分片，
断言 tool_calls 未被丢弃且 stream_index 正确。修前两条分片全被丢弃。
## 体检分类随之变化
修前: ✓ [openai] ✗ [deepseek ...]
修后: ✓ [deepseek openai] ✗ [anthropic gemini github groq mistral ollama]
2026-09-27 18:31:42 +08:00
92ada6e882
docs(stress): abtest 补「跨版本对比的陷阱」—— 老版本可能只是没干活
...
脚本原本只写「加速比 = 基线延迟 / 新版延迟」。实测发现跨版本对比时这个
数字**没有意义**：
N 老版本 中位/处理数 新版本 中位/处理数 算出的"加速"
2 0.273s / 0 个 0.480s / 2 个 0.57x
4 0.273s / 0 个 0.492s / 4 个 0.55x
8 0.273s / 0 个 0.512s / 8 个 0.53x
"老版本更快"是假的 —— 它只是没干活：适配器缺 stream_index 透传 ⇒ 多个
分片并到槽 0 ⇒ argsRaw 混拼 ⇒ 每个工具报"参数不是合法 JSON"而一个都没
真跑。
★ 跨版本能比的硬指标是**处理数**；耗时对比只在新版内部做（混一个非并发安全
工具触发整批降级）才有意义 —— 那种对照下 N=12 时加速 5.72×。
顺带记下：老版本的内核分桶逻辑其实完整（`idx := tc.StreamIndex` + `accs[idx]`，
来自 2026-08-26 的 cfd1653），缺的只是适配器那一个字段；而生产在当天 15:46
就手工补上了，比该提交（16:10）早 32 分钟。
2026-09-27 18:30:09 +08:00
0dd69a3433
test(stress): 补批内并发压测与 A/B 对比脚本，并给 mock 加多 tool_call 能力
...
## 缺口
现有 kernel-stress 只压**调度器**（多连接排队 + L4 中断 + 驻留子），mock 每轮
只发**一个** tool_call。而内核的并发判据是：
if f == nil || len(f.PendingTools) <= 1 { return false }
⇒ **一个 tool_call 永远不并发**。所以现有压测压的全是串行路径，批内并发
一条都没走过。
## mockllm.py：让 mock 能发多个 tool_call
- `!batchN` N 个全部 ParallelSafe 的只读工具 ⇒ 强制走 stepToolBatch
- `!mixedN` 夹一个 knowledge_create（未声明并发安全）⇒ 验证整批降级
- `!slowbatchN` N 个 sleep 型 cmd_run（单工具约 200ms，时长递增）
⇒ 工具慢才能让并发的收益从噪声里显出来；时长递增使**完成序与声明序相反**，
可据此判定"是否按声明序落消息"
- `!serialbatchN` 在 !slowbatch 基础上插入一个非并发安全工具 ⇒ 强制整批串行，
作为并发对照的另一半
- `!img` / `!ocr` 触发多模态工具路径（不加载模型，只验内核 IPC 接线与错误处理）
- `!err` / `!hang` 故障注入
### 三个协议细节（踩过才知道，都写在注释里）
1. **必须带 `index`** —— 内核按 `StreamIndex`（上游 JSON 的 index）分槽累积
arguments。缺 index 时所有分片落到槽 0，几个 tool_call 的参数被**混拼**，
症状是每个工具都报"参数不是合法 JSON"而工具一次没真跑过。
单 tool_call 时不设 index 也正常，所以老 mock 一直没暴露。
2. **必须按协议分片** —— 一个 chunk 一个 tool_call，各自带 index；
后续 chunk 只续 arguments。整数组塞进一个 chunk 会被内核按"续传"语义累积。
3. **每个工具都要发"带 name 的首片"** —— 我第一版只给第 0 个发首片、其余直接
发续传片，看起来省事，但内核 flush 时按"无 name 即丢弃"处理，
于是 idx=1/2/3 全被丢，只跑 1 个工具。
## batchstress.py：批内并发压测（带校验）
只看峰值是不够的 —— 校验：工具是否真跑（响应里应有结果标记）、
消息顺序是否稳定（并发执行但按索引落消息）、mixed 批是否整批降级。
## abtest.py：串行 vs 并发的定量对比
同一套内核上用 !slowbatch / !serialbatch 两组对照，交替执行抵消机器负载漂移，
取中位数（长尾会污染均值）。
★ 判据里加了"工具是否真执行"这一项：**只看耗时是不够的** —— 出现过
"内核 274ms 就回复、工具一个没跑"的情况，那种情况下并发与串行都是 0.2s，
加速比毫无意义。
## 实测（隔离 netns 实例，mock + 内核同网段，5 轮中位）
N 并发 串行 加速 上限
2 0.481s 0.685s 1.42x 2
4 0.491s 1.114s 2.27x 4
8 0.513s 2.037s 3.97x 8
12 0.531s 3.039s 5.72x 12
并发批耗时几乎不随 N 增长，串行批严格线性。
★ 另一个踩过的坑（abtest 脚本自己的）：内核有输入去重
（task.go:353 `isDuplicateInput`，为 webui 断线重连重放而设），相同文本会被
丢弃并回空响应。第一版每轮发同一个 marker ⇒ 只有第 1 轮有效，后面全是
0 秒 0 工具。修法是每轮加 `time.time_ns()` 唯一后缀。
2026-09-27 18:29:39 +08:00
c8ba1ddfef
test(lua): 记录仓库/生产适配器漂移的具体内容与时间线
...
生产 adapters/openai.lua（4853 字节）含 stream_index，仓库 cfd1653cfd1653
2026-09-27 18:29:32 +08:00
e0aeb14917
test(lua): 加适配器漂移报告 + 键名契约判据
...
上一提交（5d864b8）纠正了一处误判：仓库的 openai.lua 缺 stream_index 透传，
而生产实例早就有 —— 仓库版本落后于生产。这个漂移当时没有任何判据能发现。
## 两条判据，定位不同
### TestBundledAdaptersMatchDeployedOnes —— 诊断式，刻意**不**作为失败判据
实测结果：生产部署的 7/10 个适配器比仓库旧（anthropic 2537 vs 5144 字节），
而 openai 那份反而领先。这**是正常的** —— 生产是长期运行的部署，适配器在它首次
创建时就解包落地，之后仓库一直在演进。
若把"必须一致"写成失败判据，它会在任何老部署上恒红，而恒红的判据会被无视 ——
那等于没有判据，甚至更糟（它会掩盖真正的漂移）。所以这里只把差异摆出来。
但它顺带把**部署陷阱**摆到了明面上：
vm.go writeBundledAdapters: if 文件已存在 { continue }
升级二进制**不会更新已部署的适配器文件**。于是"仓库改了适配器但老实例上不生效"
与"仓库根本没改"在现象上完全一样 —— 这大概就是仓库长期缺 stream_index 却
没人发现的原因之一。
### TestAdapterEmitsOnlyKnownFields —— 这条才是能自动抓 bug 的
契约 = agentAPI.ToolCall / StreamChunk 的 json tag：
`id, type, name, arguments, raw_arguments, stream_index`（+ 上游原样透传的
`index` / `function`）。
★ 为什么必须有：Go 侧按 json tag 反序列化，**键名拼错会静默取零值**。
`streamindex`（少个下划线）与"没写这行"的表现完全一样 —— 无报错、字段为零、
分桶全部并到槽 0。这正是本次 stream_index 缺失的形态。
判据只看"适配器吐出来的键名对不对"，与环境无关，所以能在 CI 里恒定生效。
## 顺带确认的一件事（事后查明：是我的操作失误）
压测实例解包出的 openai.lua 是 4709 字节（无 stream_index），而二进制 embed
里是 5672 字节（有）。`rm -rf` 后重新解包**仍是旧的**。
我逐行读过 `writeBundledAdapters`，只找到 embed 一条来源，一度判为"未解释的
矛盾"。**真因是操作失误**：`rm -rf` 之后启动的那一轮，用的还是修复前编译的
/tmp/homed-stress —— 删除与重编之间隔了几轮，中间又用旧二进制起了好几次
实例，每次解包出来的自然都是旧版。
用当前 main 重新构建 + 全新数据目录验证：全新解包 5672 字节、含
stream_index×3、md5 与源文件一致；删掉再解一次仍一致；启动日志有
`[lua] installed bundled adapter: openai.lua`。⇒ **writeBundledAdapters 无缺陷**。
★ 教训：验证"二进制内嵌内容是否更新"时，必须确认跑的就是**刚编译出来的那个
二进制**。否则会得出"代码有 bug"的错误结论 —— 我确实这么怀疑了好几天。
（下面那条"部署陷阱"观察本身仍然成立：升级二进制确实不会更新已部署的适配器
文件。但它与这次的现象无关。）
2026-09-27 18:29:15 +08:00
5d864b87a8
test(lua): 补适配器 stream_index 透传判据 + 全适配器体检
...
## 先纠正一件事：这个修复在生产上早就存在
最初我判断"`openai.lua` 缺 stream_index 透传、批内并发在生产走不通"，并据此
写了实现。**核对生产实例后，这个判断是错的**：
生产 /home/newqqagent/adapters/openai.lua 130 行 含 stream_index
仓库 950b21b^ 128 行 无 stream_index
生产那份的注释是「透传上游分片 index：并行多工具调用时内核按它区分归属桶」——
简洁，与本提交新增的长注释不同。**也就是说仓库版本落后于生产，生产一直没这个
问题。** 我修的是"仓库与生产的差距"，不是"生产正在发生的故障"。
## 真正缺的是判据
`internal/agent/core/stream_index_test.go` 的
TestAccumulateStreamParallelToolCallsByIndex 直接构造 Go 结构体
`agentAPI.StreamChunk{...}`，**不经过 Lua 适配器** —— 所以"适配器有没有把
index 透传出来"它永远测不到。生产有、仓库没有，判据也发现不了。
而提交 cfd1653（2026-08-26，"流式并行 tool_call 按 JSON index 分桶"）的说明里
写着「openai.lua 输出 stream_index 字段」，Go 侧也加了
`StreamIndex int json:"stream_index,omitempty"` 并注明"lua 适配器以
stream_index 键透传" —— 但那次提交**根本没改 openai.lua**（6 个文件里没有它）。
说明与实现不符，而没有任何判据能发现。
## 本提交做的事
① 让 openai.lua 与生产一致（补 stream_index 透传），并说明为何缺它会静默失效：
多个分片全部并到槽 0 → argsRaw 混拼 → 每个工具报"参数不是合法 JSON"，
而**工具一次都没真跑过**。单工具时上游 index 恒为 0，缺省也是 0，
所以问题只在"一轮多个 tool_call"时显形。
② 新增 internal/lua/adapter_streamindex_test.go，**真正加载并执行内嵌的
openai.lua**（复用 VM 的真实路径），三条判据：
- TestOpenAIAdapterPassesThroughStreamIndex 3 个 tool_call 的
stream_index 必须是 0/1/2
- TestOpenAIAdapterKeepsContinuationFragment 续传分片（只有 arguments、
没有 name）的 stream_index 必须正确 —— 它是分桶的**唯一**依据
- TestAllBundledAdaptersStreamToolCallStatus 全 10 个适配器体检
★ 第三条刻意**不**用 t.Skip 掩盖不支持的适配器 —— 早期版本一律 Skip，结果
"完全不支持流式工具调用"也会让整体显示为绿，而绿会被误读成"都支持"。
现在分类记录：openai ✓ / kimicode+server 透传嵌套形态需另修 /
其余 7 个未产出 tool_calls。
③ 体检顺带暴露的、与本提交无关但已记录的问题：
- **仓库 vs 生产漂移无判据**：仓库适配器落后于生产时，只有靠人工对比才发现
- **部署陷阱**：vm.go writeBundledAdapters 是
`if 文件已存在 { continue }`，升级二进制**不会更新已有适配器文件**。
这可能正是"仓库缺透传却没人发现"的原因之一
2026-09-27 17:48:16 +08:00
c8ec2837dc
perf(stagehost): 工具声明查询免去结构体拷贝（热路径 1000 并发下省 1000 次）
...
## 问题
StageHost.ToolDef 返回 &def —— 一次**结构体拷贝**：3 个 string + 2 个 map 头
+ 2 个 bool + Cleaner 函数指针。
而 toolParallelSafe 在**每批**并发判据里对每个工具各调一次：
batchRunnable 遍历 PendingTools → toolParallelSafe(tc.Name)。
1000 并发批次 = 1000 次结构体拷贝，全在判定阶段（执行之前）。
不是"逃逸漏洞"（Go 1.22+ 循环变量每轮独立，go.mod 是 1.25），纯粹是白拷贝。
## 修法
ToolDef 保留 —— 它要给需要完整声明的调用方（Cleaner、Parameters 校验），
返回副本也是**有意**的（ToolDef 里有 map 与函数指针，交出内部元素会把
可变引用漏出去）。
新增免拷贝查询，热路径专用：
ConcurrencySafeOf(name) (safe, found bool) // 只读 ParallelSafe && !Serial
NoMemoryOf(name) (v, found bool)
HasTool(name) bool
全部在持 RLock 下走同一个 findLocked。
`toolParallelSafe` 切到 ConcurrencySafeOf。语义完全等价 —— 两者都算
`ParallelSafe && !Serial`，只差一次拷贝。
## 判据（两个都防"优化悄悄改了语义"）
- TestNoCopyQueriesMatchToolDef 7 种声明组合（plain / parallel / serial /
both / nomem / all / serial_nomem）下，免拷贝查询与 ToolDef(...).字段
**逐字段等价**；不存在的工具三态一致（false/false/true）。
★ 这类优化最危险的失败模式就是语义漂移：并发判据若读错字段，
能并发的批次会**悄悄退化成串行** —— 没有任何报错，只表现为"变慢了"。
所以判据必须逐个组合比对，而不是只测一个典型值。
- TestNoCopyQueriesConcurrent 32 goroutine × 50 工具并发查询，
-race 无竞态且结果与串行一致。
回归：go build ./... 通过；go test ./internal/... 全绿；
go test -race ./internal/agent/core 通过。
2026-09-27 16:29:24 +08:00
d7c2279205
refactor(parallel): 内置工具的并发声明改为 SDK 同构的结构体字段
...
上一提交（43bc255）把并发安全改成了声明式，但内置工具那一路仍是将就：
声明靠往 required 变参里塞字符串 "toolParallel" 传递。
## 为什么那不算声明式
对照 SDK 的 NoMemory 逐条看：
| | SDK NoMemory | 当时的内置工具 |
|---|---|---|
| 载体 | `ToolDef.NoMemory` 字段 | required 里的字符串 |
| 拼错后果 | 编译器报错 | **静默失效** |
| 内核读取 | 查结构体字段 | 遍历工具表 + 解析字符串 |
"少一个工具能并发"恰恰是最难察觉的一类问题 —— 没有任何报错，
只是并行的批悄悄退化成串行。
## 改法
### 1. sdk.BuiltinToolDef 补声明项（与 NoMemory 同构）
```go
type BuiltinToolDef struct {
Name, Description string
Parameters map[string]interface{}
ParallelSafe bool // 零值 false = 默认串行（保守）
Serial bool // 优先于 ParallelSafe
}
func (d BuiltinToolDef) ConcurrencySafe() bool { return d.ParallelSafe && !d.Serial }
func (d BuiltinToolDef) ToSchema() map[string]interface{}
```
### 2. 工具定义处声明
```go
toolDef("memory_merge", ...) // 默认串行
toolDefWith("knowledge_search", ..., []string{"query"}, parallelOpts()) // 已核实只读
```
### 3. 内核一次聚合并缓存（照 StageHost.NoMemoryToolNames）
```go
graphOf() // 快照
declareParallelTool(name) // init 里登记
concurrencySafeOf(name) // 查表
```
不再每次 toolParallelSafe 都重跑 buildToolDefs()（O(工具数) 重复劳动，
而声明是静态的）。
## ★ 一个更隐蔽的问题：声明表曾经是空的
`declareParallelTool` 最初挂在 `toolDefWith` 的**运行时调用**上。而那 9 个
工具全在 `if a.knowledge != nil` / `if a.social != nil` / `if a.parentID != ""`
之类的条件分支里 —— 测试环境根本不走进这些分支 ⇒ 聚合表始终为空。
而判据查的是同一张表，于是**自证通过**：全绿，并发能力为零。
这就是判据设计的教训 —— 判据和数据源同源时，它证明的只是"我和我一致"。
现在判据双向核对：名单里的必须真声明了，声明了不在名单里的也会报出来；
并额外验证内核**真的读得到**（concurrencySafeOf 而非读同一份 map）。
## 顺带修掉的迁移事故
用正则批量改造 30+ 个 toolDef 调用点时，把 `person_set_trait("name", "content")`
这类**变参**调用误改成 toolDefWith(... "name", "content") —— 那是**写工具**，
差点被标成可并发。已全部回退并逐一核对：9 个声明并发，0 误伤。
2026-09-27 15:59:11 +08:00
f4c8d86a13
fix(seq): 修掉 seq_create 的 O(n²)，并加极端压测
...
## 起因：1000×1000 压测直接跑爆
用户要求「1000 条序列 × 每条 1000 个组内 toolcall」。第一版跑满 8 分钟超时。
分阶段计时定位到瓶颈：
| 阶段 | 200 条 × 1000 工具 |
|---|---|
| 创建 | **27.0s**（135ms/条，**随序列数线性增长**） |
| 执行（组内 1000 并发） | 0.55s（20 万次调用，2.7µs/次） |
| 删除 | 4.7ms |
瓶颈在创建，不在执行。
## 根因
```go
// handlers.go:70 —— 每次 seq_create 之后
graphErr := p.store.CheckGraph()
// store.go:166 —— List() 全量 + 逐条 Load() 全部序列
```
1000 条各 250KB ⇒ 每次创建都重读 250MB 并反序列化。第 N 条的创建代价
随 N 线性增长，总计 O(n²)。
## ★ 走过的弯路：我一度建议「把校验挪到运行期」—— 那是错的
store.go:163 明确写着：
两条检查（都必须在**建序列/保存**时做，而不是等运行）：
1. 每个 seq_call 的目标必须存在（不存在会在运行期才发现，浪费一整轮）
**校验时机是语义，不是性能旋钮。** 目标不存在若等到运行才发现，模型已经
白白花掉一整轮工具调用。性能问题不能靠挪语义来解。
## 修法：缓存调用边，Save 做 O(1) 增量
```go
// Store 新增
graph map[string][]string // 序列名 → 它调用的目标（裸名）
// Save: 只更新这一条的边
s.graph[seq.Name] = edgesOf(seq)
// Delete: 移除这一条的边
delete(s.graph, name)
```
`callTargets` 只依赖 AST，不必每次从盘重建。**校验语义完全不变** —— 目标
存在性与三色 DFS 环检测都照旧在建序列时执行。
## 判据
- TestStoreGraphCacheKeepsSemantics 逐条钉住三个保证：目标存在性 ✓、
环检测 ✓、删除后不再误报成环 ✓
（这类优化最危险的失败模式是"校验还在跑但少查了某种情况"）
- TestStoreSaveScalesLinearly 分段对比后半程/前半程每条耗时。
★ 判据自己改过一次：初版用「总耗时 ÷ 单条耗时」，而单条只有 48µs 时
噪声占比过高，同一份代码两次跑出 84× 和 203× —— 判据不稳定时报的
失败就是噪声，比没判据更糟。改成分段对比（平方时后半程会慢约 n/2
倍，线性时基本持平），阈值 3 倍留足磁盘与 GC 抖动余量。
实测 300 条：84~203× 单条（线性期望 300×），平方会是 90000×。
## 压测本身也修了两个自己的 bug
- 源文件目录与 store 目录分离时只改了写入侧，清理侧还指着 store 目录 ⇒
报 "no such file"。看起来像文件被提前删了，真因是路径拼错。
- newE2EPlugin 的 runner 参数写死 *e2eRunner，压测换替身就编译不过 ⇒
改为接受 seqRunner 接口。
## 压测规模
TestStressExtreme_ThousandSeqs 现为 1000 条 × 1000 toolcall（O(n²) 修复后
可跑）。判据全是**不变量**：每工具恰好调一次、1000 槽在交错延迟下仍按
声明序合并（并发下若按完成序合并必然错位）、删除后无残留。
2026-09-27 15:58:54 +08:00
43bc25525d
feat(parallel): 并发安全改为声明式，并审计标注 37 个工具
...
把"能不能并发"从内核硬编码名单改成**工具自己的声明项**，形态照 SDK 的
NoMemory 走。
## ★ 起因：提示词在跟内核不一致
阶段 2.5 写进提示词的「内核默认并行执行」当时是**假的**：toolParallelSafe
只查 stageHost 与 io 两个来源，而全仓 ParallelSafe:true 的生产代码数量
是 **0**。于是除碰巧只发一个工具外，每一批都整批串行回退，而提示词正教
模型把多个查询放同一轮。**内核行为与提示词不一致 = 对模型说谎。**
并发面：0 → 37 个工具（18 插件 ParallelSafe + 19 插件 Serial + 9 内置只读）。
## 声明形态（照 SDK，不自创）
### 插件：结构体字段
s.RegisterTool("config_get", sdk.ToolDef{
Name: ..., Description: ...,
Parameters: map[string]interface{}{...},
// 已核实只读：…
ParallelSafe: true, ← 插在 Parameters 之后、handler 之前
}, p.handleGet(s))
位置与 SDK 的 NoMemory/ContextPolicy/RecallPolicy 一致：Name 在首位，
声明项在末尾，不打散 gofmt 对齐。
### 新增 SDK 声明项：ToolDef.Serial
ParallelSafe 的**反向**标记，判据优先级高于 ParallelSafe。
为什么需要：ParallelSafe 零值 false 已表达"安全"，插件无法区分"我没想过"
与"我确认过必须串行"。没有这个区分，工具作者只能靠命名约定传递意图。
内核已消费它（io.ToolDef 同步加字段对齐），并有判据守"Serial 胜出"。
### 内置工具：toolDef 的 toolParallel 选项
内置工具以裸 schema map 下发，没有 ToolDef 结构，所以用变参选项：
toolDef(名字, 描述, 属性) // 默认串行
toolDef(名字, 描述, 属性, "toolParallel") // 已核实只读，可并发
读工具表的老调用点一行不用动，声明就写在工具定义那一行。
## ★ 走过的弯路（都留了判据）
1. **硬编码白名单**：先在 toolParallelSafe 里查一张
builtinParallelSafeTools map。那把声明从"工具自己"搬回了内核 ——
工具改名/新增不会自动跟着变，得靠一条 grep 源码的判据才能发现漂移，
而判据一改就忘。已删，改为从定义读。
2. **判据前提错（同一个坑踩了两次）**：拿裸 &Agent{} 的 buildToolDefs 输出
当"实际可见工具"，但这 9 个内置工具全在条件分支里（a.knowledge != nil /
a.social != nil / a.parentID != ""…），裸 Agent 一个都不产出 ⇒ 全部误报
"声明形同虚设"。第一次叫它"幽灵条目"，没认出是同一个坑。
3. **注释模仿真实签名污染判据**：toolParallel 的用法注释写着
`toolDef("knowledge_search", ...)`，判据按文本匹配先撞上注释。
4. **buildToolDefs 的 nil 不一致**：开头判了 a.io != nil，末尾却无条件
a.io.ListChannels()。任何无 IO 的 Agent 调它都 panic —— 而 panic 报在
io 包里，根因在 tooldefs.go。已补。
5. **插入脚本用正则找"最后一个顶层字段"**：被嵌套 map 里的同形文本骗到，
823 处错误重排把文件改坏。改用括号深度 + 记录进入深度 3 的行号
（空 properties 会让深度在同一行进出平衡，只判 depth==2 不够）。
工具在 SDK 仓 tools/annotate_parallel/，复用时用绝对路径。
## 提示词措辞同步修正
「默认并行执行」→「尽量并发执行，但这是**逐工具判断**的」，并教模型
**把查询类放同一轮、写操作单独发一轮**（写和查混在一批，整批都串行）。
## 判据
- TestSerialOverridesParallelSafe Serial 优先于 ParallelSafe
- TestToolParallelDeclarationsAudit 并发面不许再归零
- TestNoToolDeclaresBothParallelAndSerial 两者同标即谎话
- TestBuiltinParallelDeclaredWhereDefined 声明写在定义处、且内核真读到
- TestStoreListIgnoresForeignJSON 压测抓到的 List() 缺陷
2026-09-27 15:15:57 +08:00
d36b4f6d34
test(seq): 三个压力测试 —— 超长序列 / 100 工具并行 / 串行降级
...
与单元判据的分工：单元判据钉住**语义**（一条路径对不对）；压力测试钉住
**规模下的不变量**。沿用仓内既有范式（media/soak_test.go）：
testing.Short() 跳过 + 独立 -run 跑。
① 超长序列
· 解析 10 / 100 / 1000 组（250KB 文本）：6.8ms，无硬上限误报
· 执行 200 组 × 5 工具 = 1000 次调用：2.0ms
断言：每工具恰好被调 nGroups 次（无遗漏/重复）、结果含**最后一组**
—— 组间串行在规模下仍成立
② 100 工具组内并行
· 100 工具全声明并发安全 ⇒ 11ms，完成顺序**确实被打乱**（判据会校验
这一点，否则它测不到并发）
· 断言每个槽拿到**自己**的结果（并发下若按完成顺序合并就会错位）
③ 串行降级
· 50 个工具里**一个**未声明并发安全 ⇒ 整批退回串行，
完成顺序严格等于声明序（106ms vs 并发的 11ms，降级确实生效）
★ 压力测试第一次跑就抓到一个**真实分层缺陷**：
「含非并发安全工具则整批串行」这条规则**只在上层 runGroup 实现**，
而引擎层 execGroup 只信 g.Parallel 字段 ⇒ 任何人直接调 execGroup
都会拿到不受约束的并发。
已修：降级判据下沉到引擎层，新增 batchCanRun(g, runner)，
toolRunner 增加 parallelSafe 方法（生产路径行为不变，只是把判据
放到了它本该在的层）。
过程中压测自身也暴露了两个测试缺陷（都修了）：
· fixture 让 100 个工具写同一个标量槽 o，被静态校验正确拦下
（"组内并行下同名写入是数据竞争"）—— 压测不该去撞这条规则；
· ★ e2eRunner.called 是无锁 append，100 工具并发时 -race 报出**真竞态**
（不是误报）—— 加锁 + 提供 calledSnapshot 供断言。
另：建序列与跑序列原本用了**不同 plugin 实例**（序列存在实例的 store 里，
换实例就读不到自己刚建的），已改为同一实例。
回归：go test -race ./internal/plugins/seq 全绿；go test ./internal/... 全绿。
2026-09-27 14:16:09 +08:00
1a2f59a262
feat(toolcall): 工具结果只统计不裁剪（方案 B），并治掉 seq 侧的静默截断
...
问题（核实过）：工具结果进 f.Msgs 时**没有任何长度上限**（task.go 直接
`Content: result`），内核也**不预检**是否超长 —— 超限由上游 API 报错。
时间线那侧有预算（ContextTokens = 0.8×窗口，进消息前就裁过），但那只管
a.context 的历史事件，**不管单条工具结果** ⇒ 一条巨大结果可能直接冲破
预算而内核不会提前发现。
为什么**不裁剪**（与方案 A 的取舍）：
· 截断会让模型拿到**残缺**信息，而截断位置由内核武断决定；
· 模型无法得知"这里被截断了"，会基于残缺数据下结论 —— 与本仓反复
吃亏的「静默降级」同族（`20s` 少引号 → 静默降级 → cmd_run 失败率 34%）；
· 处置权应交给调度器/上层（告警、拒绝、或让模型自己换更窄的查询），
而不是内核单方面替模型决定。
改动：
· core/toolresult_budget.go: checkToolResultSize 只**计数+报告**；
阈值默认 = ContextTokens/8（一条吃掉全部预算会把其它上下文全挤掉）；
报告经 toolResultReporter（可替换），默认 logReporter —— **不给模型发
消息**：那是在已花掉的 token 之上再加一条 system，且对当前这轮决策无帮助。
· 接入点在 stepToolAfter 的 toolMsg 落定**之后**（那里才是模型最终看到的
内容；stepToolExec 拿到的尚未经 after_toolcall 改写）。
· TaskFrame 记 oversizeTools / oversizeToolNames，供调度器与状态面查询
"是否有工具在稳定产出超大结果"。
★ 顺带治掉 seq 侧一处**我自己留下的静默截断**：
handlers.go 里我当初随手写了 truncate(…, 160)，把变量槽静默截到 160 字
且**无任何标注** —— 正是我批评过的静默降级。
改为 renderSlot：≤160 给全；超过则显式标注「已截断：共 N 字，此处显示前
160 字」并给出改法。**槽里存的始终是完整值**，截断只影响回填文本长度。
端到端判据 TestSeqRunDoesNotSilentlyTruncateSlot 抓到了这个缺陷
（"变量槽被截到 160/5000 字却没有任何标注"）。
判据（toolresult_budget_test.go，4 条）：
· 400KB 结果触发超限报告（含工具名与 token 数）
· ★ **默认不裁剪**：200KB 结果原样进 tool 消息（方案 B 的核心不变式）
· 小结果不误报（噪音会淹没有效信号）
· 报告文案可执行：带工具名、token 数、改法建议
变异验证：去掉统计调用 ⇒ 两条判据 FAIL（"统计没生效" + "被裁剪了"）。
另：检查项报 stepToolBatch 的 goroutine 竞态，-race 实测**误报**——
循环变量显式传参（非闭包捕获）、且按索引写各自槽位（非共享 map），
`-race` 下 20 轮并发判据全绿。
2026-09-27 14:05:38 +08:00
c10a36a96c
feat(seq): 新增 seq_help —— 格式说明 + 可照抄示例
...
动机来自真机实跑：模型写序列时踩了三个坑，各试 1~3 次才改对
① tools 漏末尾的 ';' → 「末尾缺少 ';'」
② group 的 in 传成字符串 → 重试 3 次
③ as 指向未声明的 out 槽 → 静态校验拦下
这三处都是**格式细节**，塞不进工具描述（有长度限制），却恰是模型最易错处。
散落在七个描述里等于没有集中入口。
实现（help.go + tools.go + plugin.go）：
· seq_help 无参数、纯文本返回（与仓内 output_send__*_help 同范式）
· 「格式要点」逐条写明：in/out 必须是**对象**、tools 必须是**字符串**、
每个 tool 后（含最后一个）都要 ';'、as 必须在 out 声明、
groups 与 file 二选一、组内并行组间串行
· 「条件 when」列出支持的表达式形态
· 「可照抄的完整示例」给一行**单行紧凑**的合法序列
★ 判据（plugin_test.go，3 条）：
· seq_help 已注册、有 description、不声明并发安全
· 内容覆盖真机踩过的**每一个**坑（判据从"坑"出发而非从"打算写什么"）
· ★ 示例**自己能被本包解析器接受**：validateHelpExample 从帮助文本里
抽出示例喂给 Parse —— 模型是照抄的，示例自己解析不过就是给模型挖坑。
而"从文本里有没有某个词"是看不出这类 bug 的。
过程中判据自己错了两次（都被这条示例判据照出来）：
1. 抽取用 strings.Index(help, `{"name"`) ⇒ 先命中「格式要点」里**有意写的**
示意片段，截到非示例的内容，报出莫名其妙的 invalid character '…'。
2. 修完又混用两套偏移基准（base 的下标拿去切 help）⇒ invalid character '\xaf'。
⇒ 重写为全程在同一 base 上定位。
★ 两次都说明：**判据的抽取逻辑本身就是需要验证的代码**，
它出错时报出的信息极具误导性（看起来像实现有 bug）。
示例形态也改过一次：原为多行缩进 JSON，改为**单行紧凑** —— 模型照抄时
免去缩进/换行带来的额外风险。
变异验证：去掉示例里的末尾 ';' ⇒ 示例判据 FAIL。
另一处：加 seq_help 后「恰好注册 6 个工具」判据 FAIL（实际 7）——
这正是那条判据的用意（防止悄悄多加工具稀释工具面），已更新并注明原因。
回归：go build ./... 通过；internal/plugins/... core sdk 全绿。
2026-09-27 13:48:15 +08:00
491ae17eb1
fix(seq): 类型不匹配的错误改成模型可执行的话（真机实跑发现）
...
真机实跑（独立实例）发现：模型把 group 的 `in` 传成字符串 "{}"，
拿到的是 encoding/json 的原始报错：
json: cannot unmarshal string into Go struct field rawSeq.groups.0.in
of type map[string]string
这句说的是**事实**（string 解不成 map）而不是**该怎么做**
（in 应该写成对象 {"键":"类型"}）；残留的 `rawSeq` / `Go struct field`
更是 Go 内部实现细节，对模型无意义且会误导它去猜一个叫 rawSeq 的东西。
模型为此**重试了 3 次**才改对。
这与本仓反复吃亏的那类问题同源：`20s` 少引号 → 静默降级 →
cmd_run 失败率 34%。**报事实不报改法，模型只能猜。**
改动（parse.go）：新增 friendlyJSONError，把原始报错翻译成可执行文案
· in / out 类型不符 ⇒ 说明"应写成对象 {键:类型}；无入参请写 {}"
· tools 类型不符 ⇒ 说明"应写成字符串（内容是 ; 分隔的 JSON 对象）"
· groups / name / when / missing / timeout / on_error ⇒ 逐个说明期望
· 未知字段 ⇒ 列出 group 允许的全部字段名（拼写错误最常见）
· shortFieldName 剥掉 `rawSeq` 这类包内类型名前缀
· jsonKind / goTypeName 把 Go 类型翻译成模型看得懂的说法
判据（parse_test.go，2 条）：
· in 传字符串 ⇒ 错误须指名字段、须说明该传对象、**且不得残留 Go 内部类型名**
· tools 传数组 ⇒ 错误须指明 tools 且说明它是字符串
★ 变异验证时踩了一次坑：第一次变异让 friendlyJSONError 不被调用，
结果**编译失败**（函数变成未使用），判据压根没跑，我却看到 "ok"。
改用可编译的变异（函数保留、开头直接 return err）后判据正确 FAIL。
★ 教训：**"变异后判据通过"要先确认变异真的生效**——编译失败 ≠ 判据通过。
真机复验：模型读一次即懂，并明确说"提示里的意思很明确"；
修复前它为此重试 3 次。
回归：internal/plugins/... internal/agent/core internal/sdk 全绿。
2026-09-27 13:43:39 +08:00
82057c85e8
feat(kernel): 内置工具注册进 ToolAPI 面（方案 B，补真机实跑发现的架构缺口）
...
真机实跑实证（独立实例 /tmp/seqtest，未触碰生产）：
seq_run 报「工具 knowledge_list 不存在或未注册」，
而**同一轮模型直接调 knowledge_list 是成功的**。
根因：`memory_*` / `knowledge_*` / `doc_*` / `person_*` 这 20+ 个是
**内核内置**工具，在 core.executeToolCallInner 里按**前缀分派**，
由 buildToolDefs 直接生成 schema，**从不进 StageHost / IOManager**
⇒ ToolAPI（只有插件工具 + IO 设备工具）既查不到也调不了。
后果：序列只能编排插件/设备工具，无法编排记忆/知识/文档/人物
——恰恰是最常用的能力。
方案 B 的实现：
· internal/sdk: 新增 BuiltinProvider（Defs/Exec）与 SetBuiltinProvider。
用**晚绑定注入**而非让 toolImpl 依赖 core，理由：ToolAPI 是**全局单例**
却需要 per-agent 数据（驻留子是轻量内核，memory 为 nil；内置工具可见性
由 `if a.memory != nil` 等门控）。sdk 不能依赖 core（方向反了）。
· internal/sdk/tool_impl.go: ToolDefByName / ExecuteTool 补查内置工具。
⚠️ ExecuteTool 只在「io 确实没有该工具」时才转内置；io 的**执行失败**
必须如实上抛 —— 否则会把「设备离线」误报成「工具不存在」，让调用方
按 missing 策略跳过（与 P3 修过的父 io 吞错误同一族陷阱）。
内置工具**默认不声明 ParallelSafe**（含 SQLite 写与召回）。
· internal/agent/core/builtin_toolapi.go: Agent 侧 provider。
★ Defs **复用 buildToolDefs 的同一批生成逻辑**（筛出不在
StageHost/IOManager 中的那些），保证"模型看得到什么"与"插件看得到什么"
门控完全一致 —— 避免两套语义。
Exec 复用 executeToolCall 完整路径（授权闸 + 异常处理）。
· cmd/homed/bootstrap.go: agent 构造后注入。
★ 不会让模型看到重复工具（已核实）：模型侧走 buildToolDefs
（a.io / a.stageHost **直调**），ToolAPI 只经 PluginSDK.Tool() 暴露给插件
—— 两条不重叠的路径。
判据（builtin_toolapi_test.go，6 条）：
· 内置工具能从 ToolAPI 查到
· ★ 查到 ≠ 调得通：必须真的能执行
· 门控语义保持：未接 memory/knowledge 时不得声称有那些工具
· ★ 接了 knowledge 时必须可见（这正是要补的缺口）
· ToolAPI 上"不存在"必须是类型化 not-found（供 seq 的 missing 策略用）
· 内置工具默认不声明并发安全
真机复验（同一隔离实例，新二进制）：
序列 "smoke2" 执行完毕（1/1 组）— 工具 1 个
变量槽: summary = cangjie/central-repo/agreement/...
⇒ knowledge_list 成功执行并回填具名槽。上一次的「不存在或未注册」已消除。
已知局限（记入待定）：ToolAPI 单例而内置工具面是 per-agent，
多 agent 下看到的是"最近一个注入者"的面。本次不解决。
2026-09-27 13:40:22 +08:00
2e175ffbd8
docs(plan): 遗留项收敛——D4 与端到端已完成，提权无需决策
2026-09-27 13:18:28 +08:00
2462759691
test(seq): 端到端接线判据，抓出「传参方式完全不可用」的真 bug
...
P1–P4 的判据都在**包内**（假 runner / 直接调函数），覆盖的是**语义**；
本轮补的是**接线**层——参数名对不对、返回值模型读不读得懂、跨层调用断不断。
接线层的 bug 语义判据抓不到：例如工具注册了但参数名拼错，单元判据全绿
而模型永远传不进来。
★ 抓到一个真 bug：**seq_create 走 groups 传参时完全不可用**。
根因：marshalGroups 只把 groups 包进 JSON 文档、不带 name，而 Parse 要求
name 非空 ⇒ 报「序列缺少 name」。而 seqCreate 里那句
`if seq.Name == "" { seq.Name = name }` 回落分支是**死代码**（Parse 早就失败了）。
后果：**只有 file 方式能用，传参方式一律失败**。
已修（name 一并包装）。包内判据抓不到这个——它们直接构造 *Sequence，
不经过这条路径；只有真正 dispatch 一遍才暴露。
判据（e2e_test.go，7 条）：真实 dispatch 串通
seq_create → seq_list（须展示签名，模型据此按名调用）→ seq_run
（执行序按 tools 声明序、槽回填、结果里**不得**出现 Go 的 `map[` 语法）
· seq_call 按名调用 group 并返回其出参
· seq_when_call 条件为假 ⇒ 跳过且**零工具被执行**
· seq_when_call 条件畸形 ⇒ **报错**且零执行（不得静默跳过）
· seq_create 走**文件**（长序列的主力用法）
· groups 与 file 同时传 ⇒ 报错「二选一」
· seq_delete 不存在 ⇒ 报错（模型会以为删掉了）
过程中又一次臆造 helper（`writeFile`），改用 os.WriteFile；
并把三处 `_, _ = p.dispatch(...)` 补上 err 检查（正是
go-ignored-call-result 报的那类）。
回归：seq -race 全绿；go build ./... 通过；go test ./internal/... 全绿。
2026-09-27 13:18:19 +08:00
028537f77a
fix(security): 设备授权闸下沉到 ToolAPI 路径（D4，堵住绕过）
...
问题：设备类工具的授权闸只存在于 core.executeToolCallInner
（toolcall.go:151-152），即**「agent 收到模型 tool_call」那条路径**。
而 ToolAPI.ExecuteTool 是**另一条**独立执行入口，不经那道闸
⇒ 凡是走 ToolAPI 的调用都能绕过 AllowedOutputs。
实测范围**不止序列**：cli 插件的 /terminal 直接经 ToolAPI 调 agentcli 的
终端工具（cli/plugin.go:1038 的注释自陈"SDK 的 ToolAPI 已允许跨插件调用
工具"）。任何插件拿 ToolAPI 都能指挥未授权的设备。
改动：
· internal/sdk/tool.go: ToolAPI 新增 CanUse(toolName, args) bool。
**纯新增方法**，零值实现返回 true ⇒ 未实现者（存量插件、测试替身）
行为不变。
· internal/sdk/tool_impl.go: 实现 CanUse。判据只有一条——设备类工具按
`device/<id>` 查授权；非设备工具不受影响（闸的作用域必须窄，否则会把
所有工具锁死）。
授权查询走**可注入**的晚绑定闭包：toolImpl 在 internal/sdk，而
IsOutputAllowed 是 core.*Agent 的方法，sdk 不能依赖 core。
· internal/plugin/registry.go: 新增 SetDeviceAuthQuery。
· cmd/homed/bootstrap.go: 在 newMainAgent 末尾注入。⚠️ 必须在 agent
构造**之后**——判据要用 agent 自己的 allowedOutputs，而 registry 早于
agent 构造，故 registry 存的是晚绑定闭包。
判据（toolapi_auth_test.go，7 条），核心是**两条路径必须一致**：
· 收窄授权时 ToolAPI 路径同样被拦
· 已授权设备放行（防闸过严杀掉正常能力）
· 非设备工具不受影响
· 枚举类工具不受影响（与内核 TestDeviceToolAuth_EnumerationNotGated 同语义）
· 未配置白名单 = 完整授权
· ★ TestCanUseAgreesWithInnerPath：4 组用例逐例比对内核路径与 ToolAPI
路径的结论 —— 判定不同本身就是漏洞
· ★ TestCanUseMatchesInnerFailOpenOnMissingDeviceID：把现状
（缺 device_id 时**放行**）钉住。⚠️ 这是 fail-open，是既有的可疑设计
（core 的 TestDeviceToolAuth_* 依赖它），本次不擅自改语义；判据写明
"若要改成 fail-closed，必须两处同时改"。
过程中三次自伤：
1. 一度在 core 写了个 toolAPIRef —— **只实现部分方法的替身**是过度设计，
且两份实现必然漂移。改为判据直接用 sdk.NewTool(stageHost, iom)，
与插件侧走**同一个**实现。
2. 判据里又写了 `var _ = agentIO.DeviceOutput` 这种压 unused import 的
占位 hack（第二次犯这个），并重造了 strings.Contains。都已去掉。
3. 注入点一开始找错了位置（以为 newStageAndRegistry 能拿到 agent，
实际 pluginReg 是 main() 的局部变量）。核实 newMainAgent 的签名后
确认它同时持有 agent 与 pluginReg，注入点落在那里。
变异验证：让 CanUse 恒返回 true（还原成原缺口）⇒ 两条判据 FAIL，
其中一条直指「内核路径=false 而 ToolAPI 路径=true —— 两条路径判定不一致」。
回归：go build ./... 通过；go test ./internal/... 全绿。
2026-09-27 13:15:22 +08:00
1e0f603ad0
docs(plan): 内核主线与插件线全部完成，记录两个设计决策与三处遗留
2026-09-27 13:06:10 +08:00
da8841e52d
feat(seq): 六个 seq_* 工具、插件装配，并补内核两处缺口（插件线 P4）
...
内核缺口（都是 P3 落地时暴露的真实缺陷）：
· **GetAllTools 丢 ParallelSafe**：它只带出 Name/Description/Parameters，
插件看到的设备工具一律"不可并发" ⇒ 设备工具的并发声明**对插件不可见**。
· **ToolAPI 缺按名查**：新增 ToolDefByName。插件需要在**运行前**判断目标
是否存在/是否并发安全（工具动态注册，"不存在"是常态），
而 GetAllTools 只能拿到全量列表。查不到返回 nil，不 panic。
seq 插件：
· plugin.go：插件骨架 + kernelRunner（把 sdk.ToolAPI 收窄成三个方法，
判据因此能用假实现驱动，不必构造整个内核）
· tools.go：六个工具定义（独立真相源，注册/判据/文档都从它取）
· handlers.go：seq_create/list/delete/run/call/when_call 的实现
· register.go + all.go：按 skillmgr 同一范式 init 注册
★ 过程中解决一个**我自己的设计矛盾**：
判据原先要求 `seq_call` / `seq_when_call` 进黑名单，但"按名调用
group/序列"恰恰是本包的核心能力——禁掉它，序列就退化成单层脚本。
分层澄清后：黑名单只管**对外发消息 / 起子 agent / 改插件表 / 再跑整条
序列**；seq_call 系列留给序列内部组合，其递归由 maxCallDepth + 环检测
负责（设计文档 §8.3 本来就是这么定的，我把两层混了）。
`seq_run` 留在黑名单：序列内再跑整条序列语义上是递归。
**六个工具一律不声明 ParallelSafe**：seq_run/seq_call 会执行一串工具，
其中可能含写操作；标成并发安全会让内核把两条 seq_run 并发跑，
两个序列的执行顺序交错、变量表互相污染。
安全性：序列名与文件路径都做穿越防护（`..` 段、分隔符、空名）。
过程中四次自伤：
1. 臆造 `jsonMarshalIndent`（不存在）→ 改 encoding/json.MarshalIndent；
并把 execGroup 的 runner 传错成 p（应 p.runner）。
2. seq 判据里写了 `black(name)`，而 blacklisted 是**谓词**不是函数。
3. 一次 python 替换删漏，把「跨序列目标存在性检查」那段从 CheckNew
里整段摘掉又贴回原处——靠编译错误发现。
4. ★ 注册失败我写了 panic：内置插件在 main() 装配期加载，panic 会
**直接拖垮内核启动**，而"某个工具没注册上"只该让该工具不可用。
已改为 log.Printf + 继续（与 clawhubadapter / mcp 一致）。
变异验证：把 seq_run 移出黑名单 ⇒ 黑名单判据 FAIL。
判据（plugin_test.go，6 条）：六个工具全部注册且 description/参数 schema
非空；seq_create 声明 required 并说明 groups/file 二选一；
seq_run 说明"按数组顺序"；六个工具均未声明 ParallelSafe；
黑名单含递归风险项且**不误伤** seq_call 与普通工具。
回归：seq -race 全绿；internal/sdk/... internal/plugins/... 12 包全绿。
2026-09-27 13:05:28 +08:00
e329231c35
feat(seq): 序列存储、跨序列调用图与 missing 策略（插件线 P3）
...
store.go：
· **存 AST 不存文本**。执行期不重新解析原始文本 ⇒ 一次格式改动不会
悄悄改变已保存序列的行为。
· 先写 .tmp 再 rename，避免写一半被读。
· **路径穿越防护**：序列名来自模型且被直接拼进文件路径，不校验的话
`seq_load("../secret")` 能读任意文件、`seq_delete` 能删任意文件。
· CheckGraph：跨序列调用的**目标存在性** + **环检测**（三色 DFS），
报错时给出**环路径**（#A → #B → #A），便于定位。
· maxCallDepth = 4 是**结构常量**不是配置项 —— 沿用内核
MaxInterruptFrames 的做法（core/scheduler.go:271「结构上界，不是配置项」）：
上界一旦可配，总有人会把它调到栈溢出。
exec.go 补 missing 策略（动态注册下「工具不存在」是**常态**）：
· fail（默认）/ skip / degrade，与「执行失败」严格分开
· ⚠️ missing 分支**必须先于**通用 on_error 检查：否则「插件挂了」会被
on_error=abort 连坐整组中断，skip/degrade 形同虚设
· skip 时**不赋值槽**（与「条件为假」同一情形，下游要能应对槽缺失）
· 本包自带 errToolNotFound 哨兵而**不复用** io 包的同名错误：seq 是插件，
拿得到 sdk.ToolAPI，拿不到 io 包类型（见设计文档 §7 边界声明）
★ 过程中解决一个**设计死锁**（值得单列）：
我最初让 Save 校验「跨序列目标必须已存在」。但互调的两条序列
谁也存不下来——A 要 B 先在、B 要 A 先在，**依赖在设计上无解**。
⇒ Save 只校验**同序列内**的 group 引用（那部分信息自足）；
跨序列目标的存在性与环由 CheckGraph 在保存后统一兜底。
判据与实现都写明了这个分工的理由。
判据（store_test.go，7 条）：
· 存取往返保住 AST（含 out 声明——它是签名的一部分）
· 列表 / 删除；删不存在的**报错**（不静默成功，模型会以为删掉了）
· ★ 跨序列成环被拒且错误含环路径；无环通过
· maxCallDepth 是正的结构常量
· ★ missing 三种取值各有明确行为
· ★ 路径穿越：7 种恶意名既读不到也删不掉，且**在 store 目录外**放真实
文件断言它仍在（不是"读代码看着对"，是跑出来的）
过程中三次自伤：
1. 序列名我写成 "#A"/"#B"——`#` 只是 target 里的前缀标记，
落盘名不带它，于是 CheckGraph 找不到、误报「不存在」。
2. missing 策略与 on_error 检查的**顺序**反了，导致 skip/degrade 被
abort 连坐（判据直接暴露）。
3. 为压掉 unused import 写了 `var _ = os.Remove` 这种占位 hack ——
正是检查项 go-ignored-call-result 指出的那类东西，已删；
另把 rename 失败分支的 `os.Remove(tmp)` 加上注释说明
「清理失败有意忽略，否则会盖掉真正的失败原因」。
变异验证：去掉环检测（三色 DFS 全放行）⇒ 成环判据 FAIL
（"A→B→A 成环却通过检查"）。
回归：-race 下 seq 全绿；internal/plugins/... 全绿。
core 包偶发 TestResidualKeep 失败是**已记录的既有竞态**
（offload_test.go 的 SpawnResident 起了子调度器而测试无同步就读队列），
与本阶段无关，已在执行计划中记为待修。
2026-09-27 12:47:18 +08:00
1a5e00a493
feat(seq): 执行引擎 —— 组内并行 + 具名槽 + 条件求值（插件线 P2）
...
三个不变量（各有判据钉住）：
1. **组内并行、组间串行**。parallel=true 时各工具并发执行。
2. ★ **合并按声明顺序**，不按完成顺序。
并行下完成顺序不确定；若按完成顺序合并，同样的输入产出不同的结果，
整条序列**不可复现**。做法：各工具把结果写进 `results[i]`（按索引），
组屏障处按 tools 数组顺序一次性合并。
顺序合并顺带解决了并发写 map —— **执行期完全不写共享 map**。
3. ★ **条件求值失败必须报错**，不得降级成"条件为假"。
把求值失败当作跳过 = 序列安静地少做一步，而模型以为跑完了
—— 与「静默吞工具」同族（那正是 P1 判据里刚堵上的同类问题）。
条件求值（设计文档 §5 的 L1+L2，不引表达式引擎）：
· true/false、$args.key 裸引用（真值）
· == / != / > / < / >= / <= 、contains
· 字面量支持 "str" / 'str' / true / false / 数字 / 裸文本
· 布尔与字符串宽松比较（true == "true"），对齐 utils.getBool 的既有约定
变量插值两种形态（缺一不可）：
· **整值引用** "$args.count" ⇒ 替换为**原始值并保留类型**
（数字仍是数字；否则模型收到字符串 "3"）
· **文本内插值** "ssh $args.host" ⇒ 在字符串内替换
· 标量渲染：对象/数组用**紧凑 JSON**，绝不用 fmt.Sprintf("%v")
（那会产出 `map[k:v]` 这种模型读不懂的 Go 语法）
on_error：abort（默认）/ continue。失败时也留槽（记错误文本）——
否则后续组读到的是"缺失"，而"缺失"与"值为空"在下游难以区分。
判据（exec_test.go，8 条）：
· 具名槽写入正确
· ★ 结果按声明顺序合并（用 delay 让完成顺序**确实**打乱）
· array 槽同名 as 按声明顺序确定性追加
· 条件为假 ⇒ 整组跳过、槽**不赋值**、零工具被执行
· ★ 条件畸形（空键 / 引用未声明入参 / 语法不完整）⇒ 报错且**不执行任何工具**
· 条件为真 ⇒ 正常执行
· on_error 的 abort / continue 两种语义
· 插值：文本内替换 + 整值引用保留类型
过程中三次自伤：
1. ★ **toolRunner 接口第一版写成 call(name)**，不收 args ⇒ 插值判据成了
摆设（永远"通过"）。改为 call(name, args) 后插值才真正可观察。
2. toolRunner / compactJSON 定义在了 _test.go 里，exec.go 引用不到 ⇒
build 失败。toolRunner 是**引擎的依赖契约**，必须在非测试文件。
3. fixture 里给 "slow" 配了不存在的返回值，误以为它该返回 "B" ——
是我没配就断言，不是实现错。
变异验证：把合并改为"按完成顺序 append"⇒ array 槽顺序判据 FAIL，
报错直指 `[C A ran:slow]` vs 期望 `[A ran:slow C]`。
（第一版变异用了一个 no-op 的 sort.SliceStable，等于什么都没测，
已改成真正模拟完成序的实现。）
`-race` 全绿；回归 internal/agent/... internal/plugins/... 全绿。
顺带修正设计文档：两处 tools 示例原写成 `{tool:cmd_run,...}`，
**不是合法 JSON**（P1 判据实测会解析失败）。已改为合法 JSON 并加注
「键要带引号，这是实现时判据跑出来的真实缺陷，不是假想」。
2026-09-27 12:29:56 +08:00
c698ae031c
feat(seq): 序列文本 → AST 解析与静态校验（插件线 P1）
...
插件，不是内核：并行执行是内核提供的**唯一**基础设施（core 的
batchRunnable）；分组 / 具名槽 / 条件 / 调用图全部在本包内自建，
**不要求内核开任何新接口**。
实现（parse.go）：
· Sequence / Group / ToolCall 三个 AST 类型
· Parse：JSON → AST + **全部**静态校验一次做完
（而非留到执行期——group 有独立签名，具名槽的价值就在于构建期就能
查出错写的槽）
· splitToolList：`;` 仅在 brace 深度 0 且**不在字符串内**时才是分隔符
· 枚举/未知字段一律硬报错：DisallowUnknownFields + 显式校验
（missing / on_error 报错时列出合法取值，不当默认值蒙过去）
静态校验规则：
· `as:X` 未在 out 声明 ⇒ 报错（具名槽的核心价值）
· `$args.X` 未在 in 声明 ⇒ 报错
· group 名重复 ⇒ 报错（签名名必须唯一才能按名调用）
· 非 array 槽被同名 as 写多次 ⇒ 报错（组内并行下同名写入是数据竞争）；
array 槽则允许（组屏障按序追加）
· tools 分隔符畸形（漏中间 / 漏末尾 / 连续 / 未闭合）⇒ **硬报错**，
绝不静默吞掉一个工具
判据（parse_test.go，9 条），★ 两条最关键：
· 含分号的真实 command（取自 core 里那份线上日志 fixture）保持为 1 个工具
· ★ TestBracesInsideStringDoNotAffectDepth：字符串里的**不成对**花括号
不得影响 depth
★ 本阶段的三次自伤（都靠变异测试暴露，不是靠判据变红）：
1. **格式本身是错的**：我在设计文档里写的 `{tool:cmd_run,...}` 根本不是
合法 JSON（键没引号），encoding/json 直接解析失败。判据一跑就暴露
——"写了格式却从没验证它能解析"。已改为要求合法 JSON（键带引号），
这也是 DisallowUnknownFields 能生效的前提。
2. **判据验证的不是它声称验证的规则**：原本那条"分号在字符串内"的用例，
分号其实落在 args 对象的**花括号内部**，depth>0 就足以保护 ⇒ 删掉
分词器的字符串跟踪后**仍然全绿**。反复两次才找到真正的判别点：
必须用**不成对**花括号在 depth 恰为 0 处，才只有字符串态能救它。
3. 手写多层转义把引号写成 \"，使分词器永远进不了字符串态。改用
json.Marshal **分层构造** fixture——手写转义没有不出错的机会。
变异验证（两轮，均能检出）：
· 删掉"回到顶层必须紧跟 ;"检查 ⇒ 漏中间分隔符用例 FAIL
· 删掉字符串跟踪 ⇒ TestBracesInsideStringDoNotAffectDepth FAIL
（"结构未闭合（括号深度 1）"）
回归：internal/agent/... internal/plugins/... 全绿。
2026-09-27 12:05:27 +08:00
5cb409c974
docs(design): 补 0.2 阶段行
2026-09-27 11:56:19 +08:00
b334d1584e
docs: 同步两份文档的实现进度（内核主线 0~2.5 全部完成）
2026-09-27 11:56:01 +08:00
bc411e7426
feat(prompt): 提示词声明「同轮默认并行」及其例外（阶段 2.5）
...
⚠️ 本阶段有硬性顺序约束：必须在并行执行（阶段 2d）落地**之后**。
反序（先说"并发"、内核仍串行）会让提示词**对模型说谎** —— 模型据
"并发执行"推断安全性，写出真正依赖顺序的调用。宁可晚改，不可错改。
改动（tooldefs.go，buildSystemPrompt）：
· 新增【工具执行顺序】段，讲清四件事：
1. 同一条回复里的多个工具调用**默认并行**（同时跑），不是依次执行
2. **不要依赖执行顺序** —— 参数依赖前一个结果就分两轮
3. **例外一：同通道 output_send__ 保序**（用户可见消息顺序敏感）
4. **例外二：不并发安全的工具整批退回串行**（写类工具 / 未声明者）
· 顺带说明并发安全由**工具自己声明**（ParallelSafe），不由模型判断
· 改掉 spawn_child 的落空表述：原文「应并行 spawn，不要自己串行逐个执行」
在并行化之前是**落空**的（模型照做，内核仍串行）。改为机制性表述，
并补一句「一次 spawn 只是启动动作，要拿结果仍需另一次 child_result」。
⚠️ 措辞刻意与 batchRunnable 的**真实**判据一致（全批 ParallelSafe 才并发
+ 同通道保序），而不是理想化表述 —— 提示词与实现不符，比不说更坏。
判据（prompt_parallel_test.go，5 条）：
· 四要点齐全（并行 / 顺序 / 保序 / 并发安全声明）
· ★ 必须同时讲**例外** —— 只讲并行就是"说谎"的那一种
· 同通道保序须显式说明（保序是内核兜底，模型不知情就会浪费它）
· spawn_child 不再含旧的落空措辞
· 回归防护：既有要点（输出规则 / output_list_channels / 工具能力 / 记忆清理）不丢
★ 判据里的一次自伤：先写了 spawnChildDescription(a) 这个**不存在**的
helper（"工具名反查描述"），编译失败后改为 toolDefDescription —— 内部
遍历 buildToolDefs 的**真实产物**。判据必须对着代码真实输出，不能另建一套
注册表。
变异验证：把两条例外改写成"以上适用于所有工具"⇒ 3 条判据 FAIL
（缺"保序"、缺"例外"、同通道未说明）。即"提示词说谎"这一失败模式
现已被判据覆盖。
回归：internal/agent/... internal/sdk/... internal/plugins/... 全绿（15 包）。
2026-09-27 11:55:33 +08:00
cf016ca909
docs(plan): 阶段 2 标记完成，记录并发规则与 2c 判据闭合
2026-09-27 11:27:53 +08:00
1d111d7b39
feat(toolcall): 批次并发调度与同通道保序（阶段 2d，闭合 2c 判据缺口）
...
规则（三条全满足才并发）：
1. 批内 >1 个工具
2. **全部**工具声明 ParallelSafe —— 一个不声明就整批降级，不做部分并发
3. 不含需保序的同通道输出发送
SDK：
· ToolDef 加 ParallelSafe bool。⚠️ 零值 false 是刻意的：存量插件不改一行
就得到**保守**行为（整批串行），不会因升级被意外并发。声明它是责任
而非特权。纯新增字段，无签名变更。
· io.ToolDef 同步加该字段（设备/通道工具走 io 路径，只查 StageHost 会漏）。
core：
· 新增 StepToolBatch —— runTaskSteps 是单线程驱动状态机的，
「每步一个工具」的游标模型无法表达「一批同时跑」，故需独立 step。
· stepToolBatch：fan-out（每工具一 goroutine，各写自己的 toolCtxs[i]）
→ join → **按索引顺序**串行收尾（after_toolcall / 落消息 / 事件）。
收尾必须串行且按索引：f.Msgs 是共享切片，且按索引落才能让模型读到的
上下文顺序与它自己发出的顺序一致。
· runOneTool 抽出「before_toolcall + 执行」的单工具逻辑，串行/并发两条路共用。
· toolParallelSafe / batchRunnable 判据函数。
★ 修掉一个我自己引入的竞争：resolveTurnScenes 会把结果记进**共享**的
f.sceneDone / f.turnScene（memorypass.go:289）。最初在每个 goroutine 里
各调一次 —— 既是数据竞争，又会各自触发一次 EnterSceneWithHint，
重复计入场景强度（正是 sceneDone 注释警告过的问题）。改为在 fan-out
**之前**解析一次，goroutine 内只读。
判据（parallelsched_test.go，4 条）：
· 全批 ParallelSafe ⇒ 并发峰值 >= 2（用阻塞设备观察真实并发）
· 一个非 ParallelSafe ⇒ 整批串行，但**仍全部执行**
· 同 output_send__<通道> 连发 3 条 ⇒ 严格按声明顺序到达
· ★ 并发下每个工具的 ctx 只带自己的 ToolCalls、after 读到自己结果
★ 并关闭了 2c 的判据缺口：此前两条 2c 判据在**串行**下无法区分
per-tool 与单槽（变体验证后仍全绿）。新增的并发版判据在退回单槽时
触发 **6 处 DATA RACE 报告 + 串味断言失败**（dup:k_a 与 k_a 撞名）。
至此 2c 可记为已验证。
过程中三次自伤：
· resolveTurnScenes 竞争（上述）；
· 我的 harness 用 StageHost 注册 handler 遮蔽了设备工具，
slowDevice 根本没被调用（"实际 0"）——改为在 io.ToolDef 上声明；
· 批内并发峰值判据最初用 StageHost 声明 ParallelSafe，掩盖了
「设备工具也需要该字段」这一真实缺口。
回归：internal/agent/... internal/sdk/... internal/plugin/...
internal/plugins/... 全绿（17 包）；core 包 -race 全绿。
2026-09-27 11:27:24 +08:00
302986d894
refactor(toolcall): StageContext 拆 per-tool，为并发执行消除共享槽（阶段 2c）
...
问题：f.StageCtx 是**单槽**，批内每个工具都覆写它（ToolCalls=[单元素]、
ToolResults 覆写、Results[0] 回读）。串行下看不出问题，但并发下
N 个 goroutine 同写一个 ctx = 数据竞争，且 after_toolcall 插件可能读到
**别的工具**的结果。
改动（task.go）：
· TaskFrame 增 toolCtxs []sdk.StageContext（每工具一份）
· buildToolContexts 在 stepLLM 设 PendingTools 时建池；
Extra **逐份浅拷贝**——共享同一 map 即竞争（stage handler 会写它）
· toolCtxFor(i) 取第 i 份，越界/未建时回落 f.StageCtx（测试替身安全）
· stepToolBegin（before_toolcall + 参数回填）、stepToolExec（写结果）、
stepToolAfter（读结果）三处全部切到 per-tool ctx
判据（toolbatch_test.go 追加两条）：
· 每个工具的 before_toolcall ctx 只带自己的 ToolCalls[0].Name，
且 Extra[output_channel] 逐份带过去（stage.go:18 依赖它）
· after_toolcall 读到的 Result 必须属于当前工具，不能是批内另一个的
★ 诚实记录：这两条判据在**串行**下**测不出与单槽的差别**——串行时
每工具跑完才进下一个，不存在交错。变体验证（toolCtxFor 退回单槽）后
判据仍全绿。故 2c 记为「实现已就位、判据未闭合」，真正判据必须与 2d
（并发执行）一起写，并以 -race 确认无竞争。已在执行计划中标注。
过程中两次自伤：
· 我的 harness 没设 Extra[output_channel]（那是 prepareInputTask 才写的，
task.go:380），判据一度报「产品缺陷」——核实后是我造的场景，已对齐生产；
· 阶段 1 的 TestStageCtxSuccessIsHonestEndToEnd 读 f.StageCtx.ToolResults，
拆分后失效——判据跟随新结构改为按批索引取 toolCtxs[i]，
断言的仍是内核产出的 Success 值本身。
顺带记录（非本次引入）：TestResidualKeep/Drop 偶发失败，根因是
offload_test.go 的 SpawnResident 起了子调度器 goroutine，而测试
enqueue 后无同步就读同一队列。干净基线 3/3 全绿属运气。已在计划中
记为待修，避免后续误判为并行化引入的回归。
2026-09-27 11:17:06 +08:00
e70b7e954c
refactor(toolcall): 批内消息改为「一个 assistant 带全部 tool_calls」（阶段 2a）
...
问题：现状每个工具各自 append 一对（assistant[tool_calls=[tc]] + tool），
既不表达「这是一批」，也无法支撑并行：
· 产生 N 条 assistant 消息，同一段 assistant 文本语义上只该出现一次
· 并行下完成顺序不确定，若等结果回来再落消息，assistant 就必须等所有
结果齐了才能写——而 OpenAI 协议要求 assistant(tool_calls) 在结果**之前**
改动（task.go）：
· TaskFrame 增 assistantMsgIdx
· 新增 ensureBatchAssistant：惰性写入，全批只写**一条** assistant，
携带 f.PendingTools 全部 tool_calls；后续工具只补 tool 消息
· stepToolBegin 的 denied / unhealthy 分支与 stepToolAfter 统一改用它
· stepLLM 设 PendingTools 时清零 assistantMsgIdx
· msgContent 的 ContentOnce 归位移入 ensureBatchAssistant（仍是只挂第一条）
⚠️ 依赖：before_toolcall 阶段**不得**改写工具参数——已核实全仓无此用法
（grep ToolCalls[0].Arguments 赋值无结果）。若将来某插件要改写 args，
需改为「回填后重写该条 assistant」。该前提已写入代码注释。
判据（toolbatch_test.go 追加 TestBatchLayoutSingleAssistantCarriesAllToolCalls）：
· 带 tool_calls 的 assistant **恰好一条**且携带 2 个 tool_calls
· 其后紧跟 2 条 tool 消息且按声明顺序（c1、c2）
变异验证：让 ensureBatchAssistant 退化为「每工具一条」⇒ 判据 FAIL
「批内 assistant 应带 2 个 tool_calls，实际 1」。
stage 0.5 补的三条判据（配对完整性 / ContentOnce / denied 后继续）
在本改动后**仍然全绿**——它们正是为这种改动准备的保护网。
回归：internal/agent/... internal/sdk/... internal/plugins/... 全绿（18 包）。
2026-09-27 11:09:02 +08:00
72634d140b
feat(io): 多模态块改 per-call 归档，为并行执行铺路（阶段 2b）
...
问题：ConsumeToolBlocks 此前是 **IOManager 级单队列**（取走即清空），
没有 call_id 维度。并行化后同批多个工具各自注入媒体时，后执行的
Consume 会**抢走**前一个的块 ⇒ 媒体挂到错误的 tool 消息上。而
task.go 里「媒体必须走 user message 且紧跟自己的 toolMsg」那条结论
是三轮实测才定下来的，并行会直接破坏它。多模态插件在 3 处调
SetToolBlocks（multimodal/plugin.go:136,246,320），是真实使用面。
改动：
· 字段 toolPendingBlocks: []interface{} → map[string][]interface{}
· 新增 SetToolBlocksFor / ConsumeToolBlocksFor / ClearToolBlocks（按 call_id）
· 保留 SetToolBlocks / ConsumeToolBlocks 作兼容入口（走 callID=""），
存量调用方与串行单工具场景不受影响；其注释写明并行下该路径不可靠
判据（toolblocks_test.go，4 条）：
· 两个 call 各自注入、**交叉顺序**并发取回，各归其主
· 取走即消费（二次取回为空）
· 未知 callID 返回空且**不影响他人**的块
· 32 路并发零串味
变异说明：本阶段是从「单槽」直接改为 per-call，旧实现在这四条判据下
（per-call API 不存在）无法编译通过，等价于判据先失败；per-call 版
再经 `go test -race` 验证无数据竞争。回归：internal/agent/io 全绿。
2026-09-27 11:06:41 +08:00
def3d37947
feat(toolcall): 按 schema 预校验参数，在分派前拦下（阶段 1c）
...
问题：`required` 在仓内被声明 69 处，却**无任何消费方**（内核从不读）。
校验散落在每个工具内部手写成中文字符串（"path is required"），
要等工具真被调用才暴露——而模型看到这类与真因无关的报错只会原样重试
（实测 cmd_run 失败率 34%~48% 的成因）。
改动：
· core/argvalidate.go: validateToolArgs（纯函数）+ validateArgsAgainstSchema。
★ 校验器刻意**宽松**：只拦真正无法解析的形态，对模型实际会写的等价形态
一律放行。依据是工具内部 getter 的既有约定（utils.go 注释：
"实际调用里 bool/string/float 三种都出现过"；unitNumberRe 修的正是
`"20s"` 少引号那类）。**校验比工具更严就是在制造新失败**。
· required 判据是**键存在性** + 非空字符串；显式 null 视为已提供
（模型可能有意传 null，工具按零值处理，判成缺失即误伤）
· boolean 全放行（getBool 的 true/"1"/"0"/"yes"/0/1 全都合法）
· integer 接受 int/float64/"20"/"20s"；string 接受含 JSON 的长文本
· 无 schema / 无 required / 查不到 schema ⇒ 一律放行
· core/toolcall.go: 在 __arg_error 短路**之后**、分派**之前**接入。
· io/channel.go: 新增 IOManager.ToolDefOf——没有它就只校验到插件工具，
而 cmd_run / files_write 这类**设备/通道工具会完全绕过校验**。
判据（argvalidate_test.go，7 组）：
· 缺 required 被拦下并指名字段
· ★ 误伤防线：bool 传 "true"/"0"、integer 传 float64/"20"、
显式 null、字段顺序不同 —— 全部必须放行
· 类型确实不符报 type 错误
· 无约束场景一律放行（含 args 为 nil + schema 带 required ⇒ 应拦，
这条我最初**误放进放行组**，写完立刻发现改正）
· 错误文案含字段名/必填/改法（否则模型只会原样重试）
· 端到端：缺参时**设备真的没被调用** + 文案指名字段
· 端到端反向：参数齐备照常执行（校验不得阻塞正常路径）
变异验证（两轮）：
· 关闭分派前校验 ⇒ 端到端判据 FAIL「仍进入了工具」
· 把 boolean 校验改严格 ⇒ 宽松防线 FAIL 两个子用例（误伤 "true"/"0"）
过程中三次自伤：臆造 sdkToolError 别名；number 分支写了没有绑定的 x(v)；
把"显式 null"先当成缺失、过度修正后又漏掉"键不存在"的判定——
最终改为「键存在性 + 非空串」双条件，null 与缺失各归其位。
回归：internal/agent/... internal/sdk/... internal/plugin/...
internal/plugins/... 全绿（18 包）。
2026-09-27 10:56:02 +08:00
d55932bb53
feat(toolcall): 结果契约诚实化 —— Success 不再恒真 + 结构化失败可回填（阶段 1b/1d）
...
问题（实测，三条互相印证）：
· ToolResult.Success 硬编码 true（task.go 唯一赋值点）⇒ 该字段在结构上
不可能为 false，是**谎报字段**；
· 工具失败以 nil error + 错误**值**返回（files 的 errorResult、
pluginmgr 的 {"error":…}），上游无从判别；
· stepToolAfter 用 `Result.(string)` 断言，而插件返回的多是 map ⇒
断言几乎恒失败，after_toolcall 阶段对结构化结果的改写**静默失效**。
改动：
· third_party/homeagent-sdk: 新增 ToolError{Field,Reason,Detail,Hint}
与 Error()。纯新增、无签名变更，存量插件不必改动（零值语义：
内核的失败识别同时兼容既有三种约定，新类型是可选项而非迁移要求）。
· internal/sdk: 补 ToolError 别名。
· core/toolerror.go: isToolError / toolErrorText / renderToolResult。
⚠️ 判据必须同时兼容仓内**三种**既有失败约定，且**不得**把成功误判：
① {"error": msg} ② {"isError":true,content:…} ③ *ToolError
明确不判失败的：exit_code != 0（业务结果，带真实 stdout/stderr）、
stderr 非空（cmd 成功常带 warn）、字符串/数字/bool/数组/nil
（自由文本按成功处理：宁可少报失败，也不把正常结果报成失败）。
· core/toolcall.go: executeToolCallOutcome 返回 toolOutcome{Text,Raw}，
**Raw 必须在成功分支也带上**——否则结构化失败在 fmt.Sprintf("%v")
那一步被抹平，Success 又退回恒真。panic 与 60s 超时统一以 ToolError
表达（可执行 Hint，避免模型原样重试工具故障）。
· core/task.go: Success=!isToolError(Raw)；修恒失败的类型断言；
TaskFrame 增 CurRaw（未降级的原值）。
判据：
· toolerror_test.go 单元级：三种失败约定识别 / 成功形态不误判 /
非零退出不算工具失败 / ToolError 识别。
· TestStageCtxSuccessIsHonestEndToEnd 端到端读 f.StageCtx.ToolResults，
验证**内核产出的值本身**，而非辅助函数。
变异验证（两轮）：
· Success 退回硬编码 true ⇒ 端到端判据 3 个子用例 FAIL；
· 把字符串判据改成 strings.Contains(x,"error") ⇒ 「成功文本含 error 字样」
用例 FAIL。**第二轮暴露了判据缺口**（最初没有该用例），已补。
过程中三次自伤（均由判据/编译暴露）：用正则批量包装 return 时把
多行 fmt.Sprintf 截断；包装范围溢出到返回 string 的辅助函数；
测试里重复注册同名工具导致 IOManager 取到错误的 device。
遗留：全量 go test ./internal/... 在本机无法完整跑完——/tmp 是 9.8G
tmpfs 且已 98% 占用，link 阶段报 "no space left on device"；
/var/tmp 另有约 29G 陈旧 release worktree。与本次改动无关（未触碰
memory/* 等失败包），已在干净基线（ab1a17a）对比确认。
2026-09-27 09:17:16 +08:00
1a511b8b89
test(toolcall): 补批内路径的三条缺失判据（阶段 0.5）
...
同一批多个 tool_call 的循环（StepToolBegin→Exec→After）此前只被
scheduler_critical_test.go:125 一条用例覆盖「按序执行」，缺的三条正是
阶段 2（并行执行层）要改的地方：
· tool_call_id 配对完整性 —— 阶段 2 改消息落法（一个 assistant 带全部
tool_calls + N 条 tool）时，配对断裂上游会直接报错
· ContentOnce 批内语义 —— 同一段 assistant 文本在批内重复 N 次，撑爆上下文
· denied 后继续批内 —— 改成 abort 会丢掉本可执行的后续调用
判据 toolbatch_test.go（4 条），全部确定性断言：阶段 0 已消除 map
迭代随机性，同批工具的落序与配对可稳定断言。
变异验证：令 stepToolBegin 跳过批内最后一个工具后，4 条判据同时 FAIL
（既有那条也 FAIL），报错直指 ToolsUsed=[tool_alpha]、
tool_call_id "c2" 被声明 0 次。
更正一处此前的不准确表述：我曾说「无任何测试直接驱动批内路径」——
不准确。scheduler_critical_test.go:125 已驱动「同批两工具按序执行」；
漏查是因为只 grep 了 PendingTools/ToolIdx 字段名，没查断言内容。
真正缺的是上表三条。
过程中三次自伤（均由「判据先写」暴露）：臆造不存在的 helper；
stageHost 置 nil 后又使用；给 newTaskFrame 传 nil 导致 stepPrepare 于
task.go:519 nil 解引用 panic（改用仓内既有 a.stageCtxFromInput）。
顺带记录：生产两处 newTaskFrame 调用都传真实 ctx，但 stepPrepare 对
f.StageCtx 无 nil 兜底——本次不修（无生产触发路径），记为潜在缺口。
回归：internal/agent/... 与 internal/plugins/... 全绿。
2026-09-27 08:59:30 +08:00
ab1a17a74f
fix(toolcall): 工具「不存在」类型化 + 修父 io 兜底吞错误 + 修并行 tool_call 落序随机
...
主线：工具调用并行化改造（阶段 0 与 0.2）。
① flush 顺序随机（process.go）
flushToolCall 由 `for idx := range accs` 驱动，Go map 迭代顺序随机化
⇒ 同一批并行 tool_call 进入 resp.ToolCalls 的顺序每次运行都可能不同。
对 output_send__ 这类用户可见通道，分段消息到达顺序不可复现。
改为收集 index 后 sort.Ints 再 flush（两个调用点统一走 flushAll）。
判据 stream_flush_order_test.go（8 工具 × 200 轮），已变异验证可检测。
② 工具「不存在」类型化（io/channel.go、core/stages.go、core/toolcall.go）
工具是动态注册的，「不存在」是运行期常态而非异常。原先内核用
strings.Contains(err, "not found in any plugin") 判别——约定而非契约，
插件文案含该子串即被误判。改用哨兵 ErrToolNotFound + errors.Is
（沿用仓内 ErrInputChannelUnknown 的先例）。
⚠️ 顺带修一个静默 bug：IOManager 向父兜底时吞掉父的执行失败，
误报为「工具不存在」。后果是设备离线这类本该 retry 的失败被判为
「工具没了」⇒ 整组被跳过，与「插件真没加载」无法区分。改为只传递
「确实不存在」，其余如实上抛。
「不存在」的文案改为可执行指引（get_plugin_tools / output_list_channels），
而非含糊的「执行失败」——后者会让模型反复重试同一个不存在的名字。
判据：toolcall_error_test.go（类型化 vs 诱饵子串、%w 穿透、执行期文案）、
channel_error_test.go（父失败不吞、真的不存在仍可判别）。
两者均经变异验证。回归：internal/agent/... 与 internal/plugins/... 全绿（14 包）。
设计文档：docs/zh/toolcall-contract-and-sequence-design.md
执行计划：docs/zh/toolcall-parallel-execution-plan.md
2026-09-27 08:55:25 +08:00
762d442844
Merge branch 'feature/scene-writeback' — 场景式记忆修复 + WebUI 性能与星图改进
...
## 记忆：场景式记忆的 5 处根因（生产实测驱动）
现网 65 个场景里有 6 组是同一场面的双胞胎键，最严重的
auto:chan:qq+part:morning 累积到 strength=271 / 6 features / 0 refs，
日志里被「命中」179 次；孪生的 auto:chan:qq_part:morning 持有 210 refs
却有 0 features（聚类只读 scene_features，所以它永不被看见）。两套特征
体系各活各的，谁也发现不了谁。
- 833dc7f4eb2d7e4eb2d7e80cbda1⚠️ 本次合并会使 git_release_check 的「公开 SDK 接口冻结」项报 FAIL，
属预期：有意的新增接口，非破坏性变更。
## WebUI
- 29a9fab8a36be0b2c55232a230ee21a3a0b8132a74
2026-09-27 08:25:30 +08:00
2a230ee89d
fix(webui): 星图配色改中性灰蓝 + 图例按实际类型动态生成
...
### 为什么会出现「一片绿」
上一提交修好了「分类配色从未生效」那个 bug（服务端发 "Concept"、JS 键是
"concept" ⇒ 永不匹配 ⇒ 1150 个节点全回退兜底灰 0xcccccc）。修好之后
颜色值**一个字没改**（concept 键仍是 0x44ff88），于是 1148 个 Concept
节点第一次真的拿到了那个亮青绿 —— 1149 个节点里 1148 个是 Concept，
所以整张图变成绿的。
⇒ 结论：绿色不是渲染 bug，是「配色终于生效」后暴露出的真实数据形状。
之前的灰色恰好是「全都没匹配上」的症状。
### 换中性色（用户裁定）
默认色改为 SM_COLOR_DIM = 0x7d8a9e（中性灰蓝）。亮青绿配 1149 个
自发光球确实扎眼。
### 顺带把「图例说谎」也修了
原图例写死「人物/概念/对象/地点/来源」五项，而实测图谱里只有
Concept（1148）与 Source（1）—— 列出四个永不出现的类型，等于告诉
用户存在实际不存在的分类。
现在：
- 图例按**实际出现**的类型动态生成，标注占比
- 占比 <1% 的不单列（实测 1/1149 = 0.087%，单列会显示成「来源 0%」，
既难看又误导读者以为图里没有来源节点），归入「其他 N 个」
- 只有**一种有存在感**的类型时，附一句实话说明「节点同色不是分类图」
### 颜色规则也跟图例对齐
smColorFor：只有存在 >=1% 的第二类型时才按类型上色，否则全图中性色。
理由：99.9% 概念 + 0.1% 其他时按类型上色，得到的仍是一整片同色，
而那一两个异色点在视觉上就是噪点（实测 colors 只剩 ["7d8a9e"]）。
不动服务端类型识别（用户裁定）：nlp/extractor.go 至今不判类型、
graph.go:451 写死 Concept，根治要改记忆链路，本轮不碰。
### 途中修掉一个自己引入的 bug
图例空。首屏星图在**总览页**初始化，那时 #sm-legend 还不存在
（骨架由 renderStarmapTab 建），smLegend 内部 getElementById 返回 null
直接返回；而 renderStarmapTab 建完骨架后只调了 smUpdateStat()。
⇒ 浏览器实测图例 html 长度 0。在 renderStarmapTab 里补一次 smLegend()。
### 验证（真实 1149 节点数据集 + WebGL）
- 颜色：["7d8a9e"]（单一中性色）—— 改前 ["44ff88"] 一片绿
- 图例文本：「概念 100% 其他 1 个（图谱实体几乎都是同一类型，节点同色；
出现新类型后会自动分类）」
- 统计：1149 节点 / 865 关系；控制台零异常
- go vet 干净；全量测试通过
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com >
2026-09-27 07:14:34 +08:00
21a3a0bc84
style(webui): dashboard.js 两处表达式合并为单行
...
纯格式化，无语义变化：
- state.startedAt 的三元表达式（563 行附近）
- renderAll 里 Promise.all 的实参（624 行附近）
两处的表达式与参数列表逐字符相同，只是原先的换行被收拢。
已随二进制部署并验证上线：现网 `/` 返回的 HTML 里单行写法命中 1 处、
旧多行写法 0 残留。
2026-09-27 06:44:49 +08:00
8a36be0746
perf(webui): 前端按页签懒加载 —— 首屏不再拉隐藏页签的数据，空闲请求砍到 1/3
...
生产实测的问题：renderAll 无论当前在哪个页签，都无条件拉 9 个接口并
渲染全部 7 个页签。首屏 792,933 B 里**约 230KB 花在用户看不见的隐藏
DOM 上** —— /api/v1/kernel（152KB，只有内核页要）与 /api/v1/settings
（72KB，只有设置页要），而 renderKernel() / renderOneSettings() 是在
**隐藏的 tab 容器**里构建 DOM 的。更糟的是每 15s 重来一遍。
### 依赖关系是实测出来的，不是猜的
逐个 render 函数 grep 它读的 state.*：
renderOverview → 无（只读 status/runtime/dom）★ 总览最便宜
renderKernel → state.kernel
renderOneSettings → state.settings / state.meta
renderPlugins → state.kernel / installedPlugins / disabledPlugins
renderAdapters → 无（自拉 /api/v1/adapters）
renderChat → 自建布局；星图/终端/命令是其子面板
于是「切到哪页才拉哪页的数据」写成一张 TABS 表（唯一真相表），
正确性由结构保证，而不是靠一串 if 串联。
### 顺带治掉三个轮询器（浏览器 40s 空载实测）
改前停在总览页 40s 内 37 个请求：
/runtime 17 次、/terminals 8 次、/cmd/history 8 次、/status 3 次
1. **terminals/cmd/history 的 5s 轮询是无条件的** —— 但这两个面板只
存在于**聊天页**（buildChatLayout 里的 chat-panel-terminal/-cmd），
在总览/设置/内核页渲染它们既没人看也只改看不见的 DOM。
改为「仅聊天页可见时才轮询」。
2. **/runtime 有两个消费者各拉一遍**：startRuntimeTicker（3s）与
starmapPullActivity（3s）。星图现在只读 state.runtime，不再自己发请求。
3. 轮询改走共享数据块 starmapFetchBlock（带 3s 节流 + 单一数据源）。
改后 40s 内 17 个请求（-54%），且不再有任何接口用于渲染不可见的面板。
### 首屏
overview 首屏只拉 status/runtime/chat/history/persona/memory-graph，
**不再拉 kernel 与 settings**。
### 刷新语义
区分「活数据」与「近乎不变的数据」：status/runtime 每 3s 允许重拉；
kernel/settings/plugins 首次拉过后**不再每 15s 重拉**（这正是 53MB/h
的主因）。切回页签也不重拉（数据没理由变）。四个变更操作
（源/MCP 的增删）改调 renderAll(true) 强制刷新；启停插件/保存设置那几处
本来就自己 refetch 再局部重渲染，不依赖 renderAll。
### ★ 途中修掉一个被上一提交引入的真 bug
loadChatStarmapData 的空图分支硬写 getElementById("sm-container-chat")。
星图搬到总览后，总览页与独立页签都没有这个 id ⇒ 首页首帧必抛
「Cannot set properties of null」，被 catch 吞掉但 starmapInit 没置上，
于是**永不重试、星图永远空白**。改为取 starmapActiveContainer() 并加
空值保护。浏览器实测：修前 ERRORS 非空，修后 STARTUP + 7 个页签全 clean。
（教训：把 UI 元素挪到新位置后，必须把所有按 id 直取该元素的地方找全 ——
grep 该 id 一次。）
同时删掉被 starmapActiveContainer 取代的死函数 starmapContainer()。
### 验证（浏览器实测，非估算）
- go vet 干净；全量测试通过
- 首屏（overview）：只拉 status/runtime/chat-history/persona/memory-graph，
kernel 与 settings 确认**未出现**
- 逐页切换记录请求：每页只拉自己那几项
- 空载 40s：37 → 17 个请求
- 运行态面板仍正常渲染（rt-panel 存在、rt-sec-pipe / rt-sec-topo 均在）
- 启动 + 7 个页签全部无控制台异常
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com >
2026-09-27 00:23:04 +08:00
29a9fab942
perf(webui): 服务端 gzip —— 首屏 wire 字节 -70%
...
生产实测：首屏 API 合计 792,933 B，而服务端此前**完全没有** Content-Encoding
（直连 127.0.0.1:8080 与经 nginx 的公网入口两条路径都验过：响应头里没有
该字段，wire 尺寸 == 原始尺寸）。同一份数据 gzip 后：
/api/v1/kernel 152,667 → 37,697 (-75%)
/api/v1/chat/history?limit=40 554,764 → 174,594 (-69%)
这些是高度重复的 JSON（同批 key 名反复出现、中文实体名、时间戳），
压缩比自然地高。真实实例上实测首屏 wire 字节 77,943 → 23,339（-70%）。
位置：链改为 proxyDispatch → gzip → logged → mux。夹在 proxyDispatch
与 logged 之间，是因为 proxyDispatch 命中时直接 return、响应来自上游
（其 Content-Encoding 由 httputil 处理），我们不插手；门户自身的全部
响应（requireAPI 的 401/503、requireWeb 的 302、HTML/CSS/JS、全部
JSON API）都压。
### 三个必须显式处理的坑
1. **SSE 不能压。** text/event-stream 进 gzip 缓冲后 flush 语义就废了
（前端收不到流式，要等缓冲攒够）。对 SSE 请求直接透传。
2. **必须透传 http.Flusher。** handleChatEvents / streamOpenAI 里是
`w.(http.Flusher)` 类型断言；包装 ResponseWriter 会让断言失败 ⇒
flusher 为 nil ⇒ 走降级分支 ⇒ SSE **静默**坏掉（不报错，只是收不到
流式）。这不是「顺手加一下」能过的改动，有专门的判据守着。
3. **204/304/HEAD 没有 body**，压它们只浪费 CPU 并加坏头。
另外 webp/png/zip/gzip 等已压缩类型也跳过（mascot.webp 133KB 就在内）。
### 小于 1KB 的响应不压
gzip 头 23 字节，几百字节的 JSON 压完反而更大。与 nginx 的
gzip_min_length 1000 对齐。实测 /api/v1/status（197B）不带
Content-Encoding。
### 状态机写成枚举而非多个 bool
第一版用 passthrough/decided/buffering/allowBuf 四个 bool 交叉表示，
结果出两个 bug：小响应内容被写成空、已压缩类型仍被压。根因是
「该不该压」在 Write / WriteHeader / 收尾三处各判一次且判据不一致。
改成单一 mode 枚举（undecided/passThrough/buffering/streaming）、
判据只在 WriteHeader 与 Write 各求值一次后，两个 bug 同时消失。
### ★ 一条判据我自己写错了，值得记下来
TestGzipDropsContentLength 初版断言「压缩响应不应带 Content-Length」，
实测失败。追查后证明**判据错了、代码是对的**：
Go 在 Del("Content-Length") 之后，若响应体小到能被一次性缓冲（<2048B），
net/http 会**自动重算**并补上压缩后的真实长度（实测 14000B → 119B →
响应头 Content-Length: 119，正确）。真正要防的是**陈旧长度**：留着
14000 而实发 119 时，客户端按 Content-Length 读满会先拿到 119 字节再吃
unexpected EOF（已用对照探针实测复现）。判据改成两条：①声明长度 ==
实际读到字节数 ②该值 == 压缩后长度而非压缩前长度。另加一条对照判据
TestGzipStaleContentLengthWouldBreak，把危害钉成可执行断言。
### 验证（不是「应该能跑」）
- go vet 干净；全量测试通过；新增 12 条 gzip 判据；覆盖率 66.5% → 67.0%
- 真实实例（独立数据目录 + 18081 端口）实测：
· SSE：无 Content-Encoding，2 次独立 TCP 读（逐帧下发，未被缓冲）
· /api/v1/status（197B）：不带 Content-Encoding
· /api/v1/kernel -69%、/api/v1/settings -73%、/api/v1/plugins -63%
· 首屏 wire 字节 77,943 → 23,339（-70%）
· 内容完整性：gzip 解压后与明文逐字段相等（plugins/tools/build/
channels 名称集合与顺序均一致）
- ★ 途中被一个「MISMATCH」误导过一轮：/api/v1/kernel 两次请求字节不同。
追查发现是 IOManager.ListChannels 遍历 **map**（Go 每次迭代随机化），
**在本次改动之前就已不确定**，与 gzip 无关。差点被我误报成压缩 bug。
附：dashboard.js 被自动格式化器整体重排（6783 增 / 6293 删，纯空白与
引号风格）。已用 prettier 归一化后逐字节比对确认**零语义差异**。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com >
2026-09-27 00:02:28 +08:00
b2c55235b7
feat(webui): 星图跟随 agent 活动 + 搬到主页 + 修分类配色从未生效
...
星图此前只是静态展示：starmapAnimate() 只转星空，节点完全静止，
与 agent 的动作零关联。本轮三件事。
★ 修一个从未被发现的 bug：分类配色一直是坏的
服务端 type 是首字母大写（"Concept"，见 internal/memory/graph.go），
而 smTypeColors 的键全是小写 ⇒ 永远匹配不上 ⇒ 1151 个节点全渲染成
同一个灰色 0xcccccc。浏览器实测确认：改前 colors=["cccccc"]，
改后 ["44ff88"]（概念绿）。
一、跟随 agent 动（三路信号，全部在渲染循环里推进，不另起定时器）
1. tool_call / stage / agent_output 的 SSE 事件 → 命中节点发光冲高
+ 尺寸微扩。工具名按**词**匹配实体（knowledge_list → knowledge_*）。
2. /runtime 调度器（3s）→ 排队/中断/挂起时全图绷紧；中断或抢占计数
上升时来一记强脉冲。
3. /memory/graph/pulse（10s，新端点）→ 新记忆「生长」：从 0 弹到
正常大小并留余晖。
另：距上次活动越近，全图越亮（抽样呼吸）—— agent 一忙图就活。
二、搬到主页 + 独立页签
总览页内嵌 360px 星图；顶部导航加「星图」独立页签（全高 + 图例）。
同一套 renderer 用 appendChild 在容器间搬运 canvas（three.js 的
canvas 只能有一个父节点，同时渲染会一边黑屏）。
三、性能：保留全部 1151 节点，但全部降规格
改前每节点 = 独立 SphereGeometry(16,12) + 独立光晕球 + 一张 256x64
CanvasTexture ⇒ 2302 个独立 geometry、约 88 万三角形、1151 个
<canvas>，仅文字贴图就吃约 72MB 显存。全景远看根本读不清那些标签。
改后：共享 SphereGeometry(8,6)（约 84 三角形/节点）；标签改为 hover
时在容器角上显示 HTML 文本（零显存，且比 3D 贴图更清晰）；
866 条边按关系类型合并成 4 个 LineSegments（draw call 866 → 4）。
hover 复位随之改为 baseScale —— 旧的 set(1,1,1) 会把按 mention_count
缩放过的大节点缩成最小尺寸。
四、/memory/graph 瘦身：不再下发稠密向量
星图是本接口唯一消费者，却从不读 vector。生产实测该字段占
79,314 / 402,811 字节 = 19%，而 8 块记忆就这么多，200 块就是 ~2MB
白查白发白堆。真实数据集实测响应 402,811 → 326,997 字节（-18%）。
新增 /memory/graph/pulse：只回 since 窗口内变动过的实体（id/name/type/
mention_count/updated_at）。星图每 10s 拉它来判断「哪个节点新长出来」，
而不必重拉 400KB 全量。
验证（不是「应该能跑」）：
- go vet 干净；go test 全绿；新增 5 个测试（向量裁剪 / pulse 窗口 /
since 放大 / pulse 不带向量 / 类型断言失败时透传不丢数据）
- 覆盖率 65.5% → 66.5%
- 真实 1151 节点数据集上跑 headless chromium + SwiftShader 实测：
nodeMeshes=1151、edgeSegs=4、geoShared=true、控制台零报错、
图例与统计（1151 节点 / 866 关系）正常、canvas 在两个容器间正确搬运
- 脉冲匹配在浏览器里逐个 hint 验证：
knowledge_list → 2 个（只命中 knowledge_base / knowledge_list）
qq_get_message 等无匹配 → 8 个（走「整体活动」兜底）
★ 途中修掉自己的两个错：① 最早的子串匹配让 hint="knowledge" 命中
全部单字实体（一次 pulse 选中 250 个、队列顶到 260 上限）；
② 改成词匹配后，旧的「补齐到 20 个」逻辑又把 1 个真实命中补成 20 个
无关节点 —— 现象与①一样，只是成因不同。补齐现在只在**完全无匹配**
时启用。
未做（本轮范围外）：服务端 gzip（首屏 793KB 无压缩，实测可压到 ~240KB）、
renderAll 按页签懒加载（首屏仍在拉隐藏页签的 kernel+settings 共 230KB）、
setInterval 15s 全量重拉（空闲 53MB/h）。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com >
2026-09-26 23:31:58 +08:00
8132a740c6
docs(site): 介绍站补「场面涌现」板块
...
三层记忆那张图只讲了字面相关性召回，缺了按场合召回的那一半。
新增一段说明：场面指纹（通道/对象/工具/话题/时段）如何自己长成场面、
为什么只发生一次的不算场面、以及 ScenePolicy 声明项（默认参与）。
沿用现有 card/grid-3/reveal class，视觉与既有三张卡一致；
div 与 p 配平关系与改动前完全一致（142/142、差值 40 未变）。
2026-09-26 23:14:17 +08:00
80cbda1059
fix(memory): 场景键两路合并去重（现网日志实测 scenes=[chan:qq chan:qq]）
...
现网 21:49 的 QQ 轮次日志打出 `scenes=[chan:qq chan:qq]` —— 同一键
出现两次。查因：tooldefs.go:63 与 task.go:793 是同一段拼接写法，
scenes := a.sceneKeysFor(...) // 内部有 seen 去重
turn := a.resolveTurnScenes(...)
for _, k := range turn.Keys {
scenes = append(scenes, k) // ← 两路之间没有共同的 seen
}
而声明路与通道派生路都会产出 chan:qq（既是插件声明的、也是从
evt.Source 派生的），于是重复。
功能上无害（RecallByScene 内部会再去重），但有两个实际代价：日志里
的 scenes=[...] 误导排查——会让人以为场景集合本身有问题；以及每次
白走一遍前缀匹配。
修法：抽 mergeSceneKeys 共用函数（顺带消掉两处重复代码），两处调用点
都走它。判据 scenemerge_test.go 5 例：3 个合并场景（同名 / 归一化后
同名 / 多路重复）+ scene_policy=none 时两路皆空（防「声明路关了但
涌现路还开着」的半开状态）。
记忆 8 包 + agent/core 全绿，8 包齐全、无 FAIL/panic/race。
2026-09-26 21:55:12 +08:00
9f85e58c64
docs(memory): 标记步骤 3/5 完成，补步骤 4 部署前基线与硬约束
...
步骤 4 加了硬约束提醒：必须先部署含 R1 修复的二进制再清理，否则
重新涌现出来的还是带 +/# 的旧键。并记录部署前实测基线（PID 92115、
子进程插件 25、近 24h 异常日志 0、场景 65），以及 homed --version
这个 flag 并不存在（纪律清单那条要用 status 接口或 ps 核对）。
2026-09-26 20:17:17 +08:00
4eb2d7e126
fix(memory): 图整备覆盖 scenes + 证据桶按桶清（R3/R5）
...
R3：图整理心跳只查 entities/relations，scenes 完全没有整备路径。
Recall(nil,nil,1,"") 的全量路径只 SELECT 这两张表
（graph.go:609/631），于是同一场面的双胞胎键从建库起无人发现：
auto:chan:qq+part:morning 累积到 strength=271 / 6 features / 0 refs，
孪生的 auto:chan:qq_part:morning 持有 210 refs 却 0 features
（聚类只读 scene_features，所以它永远不被看见）。
新增 GraphDB.DedupeScenes：归一化后同名的场景合成一个——强度相加、
特征取并集（权重取大）、引用全部重定向，存活者保留 id 最小行，
跨 origin 也合。接到 mergeLoop 尾部。
为什么不塞进 detectEntityMerge 的双重循环：
- 实体是全库两两 bigram + LLM 裁决（1 万实体实测 5000 万次配对、
~224GB 瞬时分配每轮，是独立问题）；
- 场景的判重口径是**归一化后是否同名**——同名即同一场面，键相同
本身就是证据，不需要 LLM 裁决。而「像不像」是 EnterScene 聚类的
职责，不是这里的事。
只做同键合并、不做相似度合并：把 chan:qq 与 chan:webui 合并是危险
的，去重不是「把像的一律合并」。
生产库副本实测（sqlite3 备份式复制到 /tmp，未碰生产）：
65 个场景 → 合并 8 组 → 57 个；
auto:chan:qq_part:morning 的 refs/rel/ent 一条没丢，strength 1 → 272。
R5：createSceneLocked 新场景成立时执行的是
`DELETE FROM situation_evidence`（全表清），而证据表是多通道共用的
计数桶。后果不是「多清一点」：qq 的场景一长出来，就把 mc/webui/cli
尚未攒够 minSceneEvidence=2 的证据抹掉，它们的计数被反复清零，
于是**永远**攒不到 2 次。判据实测：6 个通道各来 3 次，只长出 2 个场景。
改为 `DELETE ... WHERE label = ?`，只清本指纹那个桶。
判据：scene_dedupe_test.go 8 例（含「不同场面不得被合并」与幂等）、
scene_evidence_test.go 3 例。均先红后绿。修 R5 时差点栽：桶键是
sig.Label(2) 本身、不带 auto: 前缀（base 才是带前缀的场景键），
第一版删错对象会「一条没删却看起来通过」，用探针实测真实桶键后改正。
记忆 8 包 + agent/core 全绿，8 包齐全、无 FAIL/panic/race。
2026-09-26 20:16:11 +08:00
be9c1dc5ac
feat(sdk+memory): 补 ScenePolicy 声明项，让通道能退出场面识别
...
缺口（R6）：ChannelDef 的记忆声明已有三件套——NoMemory 管「进不进
记忆计算」、ContextPolicy 管「裁不裁上下文」、RecallPolicy 管「召不召回
记忆」，唯独没有「这条输入算不算一场戏的一部分」。现状是无条件参与：
situationFeaturesFor 里只要 evt.Source != "" 就产出一个 chan 特征，没有
可关的开关 ⇒ chan:system / chan:kernel / chan:timer 这类纯内部信噪通道
也在撑场面，每次触发都让不相干的场景长出来或变强，召回时又会把
「内核在跑定时器」当成「用户在这类场景下说过的话」取回。
穷举确认不是查漏：go.mod replace 指向 third_party/homeagent-sdk，
plugin.go 中 scene 出现 0 次，SDK 自身 git 历史 -S'Scene' -- sdk/ 为空。
SDK（纯追加，老插件行为逐字节不变）：
- 常量 ScenePolicyAuto / ScenePolicyNone + ValidScenePolicy，形状与
ContextPolicy / RecallPolicy 完全一致
- ChannelDef.ScenePolicy 与 InjectOptions.ScenePolicy，均带 omitempty
- 默认取 auto（参与）而非 none：场景只附加检索路、不改记忆本体，
默认关会让存量通道突然失去召回；「关」是少数意图。与 ContextPolicy
刻意相反（同为破坏性操作，那里是默认关）。
内核：
- applyInjectOpts 搬运 scene_policy（与另外三个标志位同面）
- sceneSuppressed 完全照 recallDeclared 的形状：注入点 payload >
通道定义 > 默认。none 时连时段(part)特征都不产，也不派生场景键
（只停指纹采集而留声明路，等于给这个口子开后门）
- situationFeaturesFor / sceneKeysFor 由包级函数改为 Agent 方法
（需要 a.io 查通道定义），23 个调用点同步
判据：scenepolicy_test.go 7 例，改前编译期红（undefined:
pubsdk.ScenePolicyAuto），改后全绿。其中两例专门护住「未声明时行为
逐字节不变」，是纯追加承诺的护栏。
记忆 8 包 + agent/core 全绿，8 包齐全、无 FAIL/panic/race。
存量通道标注待定：kernel/timer/offload-*/child/* 是纯 0-refs 信噪，
可直接标 none；但 mc:system(12 refs) 与 system(3 refs) 带真实记忆，
性质不明，不擅自标。
2026-09-26 20:09:17 +08:00
c7d1aa06d2
docs(memory): 补 R6/R7 与 SDK 声明项方案，重排为 7 步
...
R6：ChannelDef 的记忆声明已有三件套（NoMemory/ContextPolicy/
RecallPolicy），唯独没有「这条通道是否参与场面识别」，现状是无条件
参与 ⇒ chan:system/kernel/timer 等内部信噪通道也在场面聚类里。
穷举确认非查漏：go.mod replace 指向 third_party/homeagent-sdk，
plugin.go 中 scene 出现 0 次，SDK 自身 git 历史 -S'Scene' 为空。
R7：payload[scene] 的层级键（chan:qq/peer:group_1）已支持前缀
召回（RecallByScene scene.go:351），但因 R6 无人使用而闲置。
步骤重排为 7 步：SDK 声明项提到步骤 2（用户已授权动公开 SDK，
开发阶段非 release 阶段），并把「peer 覆盖面」拆到步骤 6 单列，
先只读调查插件手上有什么再动。
2026-09-26 20:03:51 +08:00
90bd499ddd
docs(memory): 补 R4 覆盖面与 R5 证据桶两条根因
...
R4：现网 65 个场景键里 peer 主导 0 个、topic 主导 0 个，36 个
auto:chan + 26 个 chan: 全部锚在输入通道。两个独立原因：
采集侧全仓无插件在 InjectInput 填 peer/group_id/user_id/chat_id
（日志中 peer 出现 0 次）；排序侧 chan 与 peer 权重同为 1.0 而
NewSituation 稳定排序让 chan 恒在前，即使采集到也进不了 Label(2)。
这与 R1/R2 是不同层面：R1 修完只会得到「正确的单一维度」。
R5：createSceneLocked 新场景成立即 DELETE FROM situation_evidence
（全表清），会连带清掉别的场景尚未攒够门槛的证据。
2026-09-26 19:58:00 +08:00
833dc7f30f
fix(memory): 场景键归一化 + 排除最弱维度，修双胞胎与空转
...
现网实测：scenes 表 65 行里有 6 组是同一场面的双胞胎键，最严重的
auto:chan:qq+part:morning 累积到 strength=270、6 个 features、
0 条记忆，日志里被"命中"179 次；孪生的 auto:chan:qq_part:morning
则持有 201 条记忆却有 0 个 features（不参与聚类）。两套特征体系
各活各的，谁也发现不了谁。
病因：键构造不唯一。
- Label() 直接用 "+" 拼接且不过 NormalizeSceneKey，而
EnsureScene / effectiveScenes / RecallByScene 三处都过了归一化。
"+" 会被 normalizeSceneSegment 归一成 "_"，于是两个字符串都合法，
key UNIQUE 约束拦不住。
- Label(2) 会把权重仅 0.2 的 part（时段）挤进场景身份。实测
morning 场景吞掉 evening 指纹：共享 chan:qq 权重 1.0、并集含
part 0.2×2，相似度 1.0/1.4 = 0.714 > joinSceneThreshold 0.5。
这本就是加权 Jaccard 的正常行为，但键名不该写进时段。
- createSceneLocked 的 "#N" 冲突后缀同样会被归一成 "_"，
造成 auto:chan:mc:event+topic:mc#2 在库、而写侧归一化后去找
auto:chan:mc:event_topic:mc_2 —— 又一对匹配不上的双胞胎。
修法：
- Label 只取权重 ≥ 0.5 的主导特征，结果过 NormalizeSceneKey；
全部特征都弱于门槛时退回最强的一批（宁可名字信息量低，也不能
没有名字 —— 没名字就没有键，场景根本长不出来）。
- createSceneLocked 对 base 再做一次防御性归一化，并在 label 为空
时拒建无名场景。
- 冲突后缀由 "#" 改为 "."（'#' 会被归一化，'.' 是白名单字符）。
判据：新增 scene_key_test.go 6 例，参照物在生产代码之外（"同一场面
⇒ 同一个键"这条不变量 + 直查 scenes 表复算行数）。先跑红确认判据
在跑（4 红 1 绿，失败的正是键唯一性/时段污染/证据桶），再改实现。
其中 TestWrittenRefReachableFromItsScene 一开始就是绿的——写侧到读侧
那条路本身是通的，坏的只是键的构造。
记忆 8 包 + agent/core 全绿。
2026-09-26 19:56:28 +08:00
dc84e276f5
Revert "fix(agent): output_send 缺收件人时从输入事件自动补"
...
This reverts commit 6ee55ce
2026-09-26 19:11:51 +08:00
6ee55ce9c0
fix(agent): output_send 缺收件人时从输入事件自动补
...
## 现象（线上 2026-09-26 17:57）
用户从 QQ 私聊发来消息，agent 生成了回复也调了 output_send__qq，
但**没填 meta**：
17:57:45 qq_get_message → {user_id: 2198972886, message_type: private}
17:57:46 output_send__qq → 失败：meta 中需要 group_id 或 user_id 字段
17:58:14 output_send__qq_help → 查格式
17:58:14 output_send__qq → ok ← 靠重试成功，整轮耗时 74s
信息内核**本来就有**（输入事件里带着 user_id/group_id），却要模型从
qq_get_message 的返回里手抄进 meta。抄错就失败，失败才去查 _help。
而"回复"这件事的收件人是确定的（= 消息来源），本不该由模型负责。
运气差就不重试：同日 17:15 / 17:21 两次 `tools=[]` —— 模型压根没调
output_send，回复生成了但没发出去，日志连一行告警都没有。
## 改法
meta 缺收件人时，内核从**本轮输入事件**推导后补上。模型只需给内容。
## 边界（都刻意收窄：宁可不补，也不能补错）
- 显式传了 meta ⇒ 原样返回。主动 DM 别人等场景必须保持原行为。
- meta 里已有 group_id/user_id ⇒ 不覆盖。
- meta 是坏 JSON ⇒ 原样返回。让下游报"格式错"，而不是被静默替换成
一个模型没要求过的收件人 —— 那比报错更坏：消息会发给错的人。
- 非 qq 通道（如 webui）⇒ 不补。webui 走 ResponseCh，不过 output_send。
其余异步通道（wechat 等）不猜：猜错等于发错人。
- 输入事件里没有收件人信息 ⇒ 留空，让下游按原逻辑报"需要 user_id"。
宁可报错让模型重试，也不要编一个收件人。
- 群消息里 user_id 是**发送者**不是收件人 ⇒ group_id 非 "0" 时优先用
group_id，否则会把消息发回给群成员本人。
数字型 user_id 要按整数格式化：JSON 反序列化成 float64 时
fmt.Sprint 会得到 "2.198972886e+09"。
## 判据：7 条
私聊补 user_id / 群聊补 group_id 且不补 user_id / 显式 meta 不改写 /
已有收件人不覆盖 / 坏 JSON 不静默替换 / webui 不补 / 无信息留空（含 nil evt）。
★ 实现时我先自己写了个 payloadString，编译报错才发现包内已有更完整的
版本（memorypass.go:176，含 float64/int64/int/json.Number 分支），
直接复用 —— 不重复造轮子。
全量 42 包绿。
2026-09-26 18:29:23 +08:00
df872b9e86
chore(vendor): 主仓不再跟踪 SDK 示例代码（决策 A）
...
## 背景
`.gitignore` 第 26-45 行早已写明「外部插件与工具链维护在独立 SDK 仓
（决策 sdk_repo_only），本仓经 go.mod 的 replace 引用」，并忽略了
example/、tools/、docs/、site_build/、package/、scripts/。
但有 29 个文件**早于该规则**被跟踪，靠「已跟踪文件不受 .gitignore
影响」留着，注释还特意写了「这是有意的，不要『修』」。
本轮修 example/bili 时踩到了：那 87 行改动先落在主仓、再手动同步到
SDK 仓 —— 同一份代码两个仓各改一遍，正是这个遗留结构的成本。
## 核实：主仓到底需要什么
- 主仓 Go 代码只 import 两个包：`homeagent-sdk/sdk`（插件入口）、
`homeagent-sdk/meta`（版本号）
- `remotedevice/` 是 C 库，主仓 C 侧明确「不链接任何外部库」，
只有注释里提到它
- `tools/hmapdev/yaegi` 的 import 出现在 **SDK 仓自己的文件之间**
（yaegi/interp.go → yaegi/mocksdk），不是主仓依赖；
且 tools/ 本就在 .gitignore 里，从未被跟踪
所以 29 个文件全部可以删。实际仓库负担也只有 42 个文件 / 0.6MB
（工作树里那 971MB 绝大部分是未跟踪的构建产物，不是仓库体积）。
## 改动
- 删 21 个 example/ 文件（10 个示例的 plg.json + plugin.go + qq/plugin_test.go）
- 删 8 个 remotedevice/ C 文件
- 工作树里一并清掉（不受跟踪的构建产物顺带回收）
构建与全量测试均通过。
## 判据：3 条 + 变异（internal/meta/vendored_sdk_test.go）
- TestVendoredSDKHasNoExampleOrRemotedevice：防止示例代码被重新提交进来
- TestVendoredSDKKeepsRequiredPackages：**反向**保护，防止为省事把
sdk/ 与 meta/ 也删掉（上一条只防"多了"，删过头要靠这条）
- TestGoModStillReplacesSDKToVendoredPath：决策 A 依赖 replace 指向 vendored 路径
★ 判据自己踩了两个坑，都靠实跑抓出来：
1. `git ls-files` 的路径参数**相对当前目录**解析，而测试跑在
internal/meta/ 下 ⇒ 就地执行返回空，表现为「必需包全都不在」的假红。
改用 `git -C <仓库根>`。
2. 把 tools/hmapdev/yaegi 当成主仓依赖写进必需清单 ⇒ 又一次假红。
根因是把 SDK 内部的引用误当成主仓依赖（它本就在 .gitignore 里）。
变异验证：塞一个 example 文件进版本控制 → 判红。
2026-09-26 17:18:41 +08:00
eb14b3a1d2
fix(proc): 杀插件进程组 + readerWG 超时兜底 —— 修孙进程拖死关停
...
## 现象
线上关停必超时：systemd 报 `State 'stop-sigterm' timed out. Killing.`，
进程组里 23 个插件全退完了，最后那条 `[homed] stopped` 仍打不出来。
其中只有 bili 报 `[proc] bili SIGKILL 后 2s 仍未被收割`，之后近 90 秒无日志。
## 根因
bili 用 exec.Command 拉 yt-dlp（源码 example/bili/plugin.go:122/212），
无 CommandContext、无 Setpgid、Stop() 是空的。yt-dlp 再 fork ffmpeg，
**孙进程继承插件的 stdout 管道写端**。
插件被 SIGKILL → 孙进程仍存活、写端不关
→ readLoop 的 scanner.Scan() 永不 EOF
→ p.readerWG.Wait() 永不返回（Kill 的最后一行，**无超时**）
→ StopAll 的 wg.Wait() 永不返回 ⇒ 关停挂死 ⇒ systemd SIGKILL
内核 process.go:340 的注释早已预警过这个场景（"插件 fork 的孙子进程继承
同一 stdout 写端时，插件本体死了 EOF 也不会到"），但 Kill 没有对应保护。
## 内核三处修法（缺任一条都不够）
1. **spawn 时 Setpgid**：插件自成进程组，不再与内核同组
2. **Kill 杀整个进程组**（kill(-pgid)）：孙进程一起死，管道写端才关。
兜底：负 pid 失败时退回杀本体（老插件/非 Unix 平台）
3. **readerWG.Wait() 加超时兜底**：这是唯一能保证 Kill 一定返回的地方。
超时后主动关读端逼 readLoop 退出，再兜一层仍不退就放弃等待 ——
宁可少等 2 秒，也不能把关停无限期挂住。
## 插件侧（bili）
CommandContext + Setpgid + Stop() 里 cancel 并 wait：
- 只 cancel 不 wait 的话内核会先释放共享段，而 yt-dlp 还在写 stdout
- waitRunGroup 杀整个进程组（ffmpeg 也在内），不留孤儿
## 判据：5 条 + 3 组变异
判据用**真实模板编译的插件**（复用 buildPluginWithRealTemplate，
与 e2e_template_test 同一条路）+ NewHost 启动，不是自造 shim：
裸 Spawn 没有 Host 建共享内存段，插件握手会报 permission denied。
★ 判据自己踩了三次坑，都由变异/合跑抓出来：
1. 给孙进程也加 Setpgid ⇒ 它逃出插件进程组，kill(-pgid) 杀不到，
造出假失败（真实场景 yt-dlp 不会脱离进程组）
2. 各测试数全局孙进程数 ⇒ 前一个泄漏的被后一个数进去，
单跑通过、合跑变红。改为记录基线只关心自己新增的
3. readerWG 超时那条用纯构造 &Process{cmd:nil} ⇒ Kill 第 607 行
早退，根本走不到那段，撤掉超时照样绿。补了「脱组孙进程」
场景（Setsid 逃出进程组）才真正覆盖到
变异：去 Setpgid → 判红；只杀本体不杀组 → 判红。
全量 41 包绿。
2026-09-26 16:58:41 +08:00
f7f2fd2a53
fix(plugin): StopAll 并行停插件 —— 修关停必然超时被 SIGKILL
...
## 现象
systemd 每次都报 `State 'stop-sigterm' timed out. Killing.`
进程组里 23 个子进程插件**全退完了**，最后那条 `[homed] stopped`
仍打不出来，然后被 SIGKILL。
## 根因（算出来的，不是猜的）
单个插件的 Stop 最坏预算：
5s（CallContext plugin.stop）+ 5s（等 exited）+ 2s（Kill 后收割）= 12s
串行停 23 个 ⇒ 23 × 12s = 276s，而 systemd 只给 90s。
⇒ 关停必然超时。线上每一条 stop 记录都是 timed out，无一例外。
## 改法
StopAll 改为并行：取插件快照 + 各自的 SDK 句柄后**立即释放 registry 锁**，
每个插件一个 goroutine，等全部完成再释放共享段。
三处必须小心的点（都是并行化引入的新风险）：
1. **先释放 registry 锁再并行停**。p.Stop() 会触发
markExited → onExit → ReclaimOwner，那条链要读共享内存段。
持着锁并行跑，若某插件的 onExit 需要拿 registry 锁（摘通道等）
就是自死锁。
2. **stop handler 的快照要在清空 sdkRefs 之前取**。handler 挂在
PluginSDK 上（r.sdkRefs），先清空就再也拿不到了。
3. **单个插件 panic 不带崩关停**（那会让剩下的插件全停不掉），
也不静默吞（留日志）。
## 判据：5 条 + 3 组变异 + race
- TestStopAllStopsInParallel：8 个插件各 120ms，串行 960ms / 并行 120ms。
判据直接量耗时，串行实现必然变红（实测串行时 962ms）。
- TestStopAllSurvivesPanickingPlugin：panic 不外冒、其它插件照停、不死锁
（带 10s 超时，死锁会超时而不是挂住测试）
- TestStopAllFreezesAutoRestart / StopsEachPluginExactlyOnce：
冻结自动重启、每个插件恰好 Stop 一次（重复会二次释放共享段）
- TestStopAllRunsStopHandlerBeforeStop：handler 必须先于 Stop，
走真实的 PluginSDK.RegisterStopHandler 路径
变异：退回串行 → 判红并打出实测耗时；去掉 handler 调用 → 顺序判红；
假装并行只清空 → 4 条判红。
`-race` 通过（并行化必须验锁，这是本次改动的头号风险）。
全量 41 包绿。
2026-09-26 16:23:56 +08:00
a6103154f6
feat(knowledge): 目录批量导入 + 派生数据批量收口
...
## 能力缺口
导入只能一条条 Add（knowledge_create）。agent 拿到一份 200 页的
文档目录要调 200 次工具，且每次都得自己决定分类与名字。
新增工具 `knowledge_import_dir(dir, category?, include_media?, dry_run?, max_items?)`。
语义是**复制**不是引用：源文件删改不影响已导入的副本。
- 文本经 Write 整份写入 <知识根>/<分类>/<名>/content.md
- 媒体按 sha256 进媒体库（内容寻址天然去重），条目只存 digest 引用
## 目录约定（自动适配，不要求改造资料）
1. 含 content.md 的目录 ⇒ 整体作为一个条目（与 scanDir 既有语义一致，
所以知识库自身目录能被原样再导入而不会被拆散）
2. 否则 .md/.txt 等文件各成一条，**目录路径即分类**
## 三个语义决策
- category 是**前缀叠加**（tech + 源结构），不替换：替换会丢掉源目录
自身最有价值的层级信息
- 同名冲突**跳过并计数**，绝不覆盖：Write 对同名本就是覆盖语义
（knowledge_create 靠它做更新），若直接调它，一次重导就会把手工
补充的内容悄悄抹掉，而日志只写"导入完成"
- dry_run **默认 true**：批量写，agent 第一次试某目录应先看清会写什么
## 安全边界（批量操作，缺一道就可能读到不该读的）
- 必须绝对路径：agent 的 cwd 不受控，相对路径会静默导到别处
- 符号链接不跟随：否则一个软链就把知识根之外的文件导进来
- 拒绝把知识库自身当源（自导会无限自我复制）
- category 复用 normalizeName（与 Write 同一道闸，两处分叉就成了绕过）
- MaxItems 默认 500：防 agent 误传 "/" 把盘灌满
## ★ 批量导入暴露的既有 O(N²)
Write 每条末尾都调 flushDenseLocked，而 saveDenseCacheLocked 是
**全量序列化整个 items map 再重写整个文件**。按 512 维 float64 估，
单条约 10KB，导入 500 条累计要写约 1.4GB。
仓库里索引侧早已有 indexDirty 的「标脏+延迟收口」（实测 writeIndexLocked
6.7ms/次、占单条 Add 绝大部分），**稠密缓存却还是逐条全量重写** ——
同一类开销只修了一半。
照 indexDirty 的模式补 batchDepth：批量期只标脏，endBatch 收口一次。
用 defer 保证提前 return 也会收口 —— 否则这批向量会留成"标脏未写"，
下次启动被当作缺失而全量重算。
## 判据：17 条 + 变异
安全边界做了 4 组变异验证（去符号链接拦截/去绝对路径要求/去自导检查/
content.md 目录不下钻）。
★ 判据第一版有两处自己骗自己，被变异抓出来：
1. 符号链接判据造的是**目录软链**，而 WalkDir 对目录软链本来就不下钻
⇒ 有无防护结果都一样，是假绿。改成**文件软链**后才真正判红。
2. 同名冲突判据里已有条目写成 "a/b"、源映射出的是 "b"（不同名），
判据自己就错了 —— 修判据而不是改实现。
媒体路径用假 MediaPutter：验的是「调了 Put 且 digest 挂到条目上」，
媒体库自身的落盘去重是 media 包的判据，不该在这里重测。
全量 41 包绿。
2026-09-26 16:19:10 +08:00
30d78234b8
chore(meta): main 构建产出 1.4.0dev 路牌，不再自称旧 patch 线
2026-09-26 15:44:35 +08:00
6c557c1d10
feat(kbtree): 知识库暴露范围配置 —— 按树状只暴露指定分类
...
## 问题
kbtree 是**唯一**把知识库开放给外部进程的通道（HomeAgent 自己的 agent
走进程内直调 knowledge_* 内核工具，不经此），但它只有 listen_addr 与
token 两个配置，**没有任何范围限制**：拿到 token 的任何 agent 都能
/tree 列出全部条目、/search 取回任意条目全文。
本机库里混着个人内容（航空发动机教材摘录、课表、身份合并规则），
不该 broadly 可读。
## 改动
1. `internal/plugins/kbtree/scope.go`（新）：暴露范围语义
- 留空 = 全部可见（范围是"限制"不是"必填"，留空保持既有行为）
- 前缀按**路径分段**匹配：public 命中 public 与 public/tech，
但**不**命中 publication（否则 publication 意外暴露）
- 根下无分类的条目在范围非空时不可见 —— 它没有分类可匹配，
放行等于范围形同虚设
- 分隔符容忍逗号/分号/空白/换行/竖线：这是给人手填的字段
2. `plugin.go`：注册 `expose_categories` 配置项，接入**全部四个端点**
- /tree 服务端裁剪子树（就地改，不重建：TreeView 字段多）
- /categories 过滤路径列表
- /counts 过滤计数并**重算 total**（数量本身也是信息泄露）
- /search ★ 过滤结果条目；这处最关键：
只过滤 /tree 而放过 /search 等于范围形同虚设（换个 ?q= 就能拿到全文）。
同时修正 limit 语义 —— 范围外条目不占名额，范围内条目不会被挤掉。
3. SDK 契约补 `Knowledge.Category`（纯增量）
- 此前 `sdk.Knowledge` 只有 Name/Content，内核明明返回了 Category
却在 knowledge_impl 的拷贝里丢掉 ⇒ 外部服务无法按分类判定，
范围过滤在 SDK 层根本做不了。
- Name/Content 均保留，无删除。
## 判据（8 条 + 4 组变异）
范围过滤最容易"只做一半"，所以每个端点都单独钉。
★ 判据补强一处：初版只查条目名（priv1），结果「/categories 不过滤」
这个变异**完全逃过** —— 分类端点返回的是路径不是条目名。
补上分类路径断言（private）后判红。
变异验证：
- /search 不过滤 → 泄露 priv1 全文 ✓ 判红
- /categories 不过滤 → 泄露 private 分类路径 ✓ 判红（补强后）
- /counts 不过滤 → TestCategoriesAndCountsEndpoint 判红
- 前缀退化为字符串前缀 → publication 被误暴露 ✓ 判红
★ 过程中我的 fake 有两处与真实内核不符，先修 fake 再修实现：
1. 漏了内核 treeLocked 的"子分类提升一层" ⇒ 得到 children=0 的假空树
2. filterTree 无差别清空 t.Items ⇒ 整棵树只剩空壳节点
（第一版的实现是"看着测试红就改"，实际是 fake 在骗我）
全量 41 包绿。SDK 接口纯增量，未发布故无需冻结检查。
2026-09-26 15:31:15 +08:00
55c5419899
fix(kbtree): 修客户端脚本三处实测暴露的缺陷
...
都是本机装好后逐条跑命令发现的，不是设想：
1. **token 找不到**：脚本找 `scripts/../config.json`，而实际文件在
`<skill>/config/config.json`。症状极具迷惑性——「明明配了 token 却说
没找到」。改为两种布局都试，并在注释里写明为什么不能只写一种。
2. **`-h` 也要 token**：帮助段排在 token 检查之后，`kb_tree.sh -h` 会被
拦下报「未找到访问令牌」。把 help 提到最前。
3. **`-q` 被当成命令名**：`kb_tree.sh -q 并发`（不给子命令）报
「未知命令: -q」，而这是很自然的写法。改为：第一个参数是选项时不取作
子命令，解析完选项后再定——有 -q 走 search，没有走 tree。
另外把 curl -f 换成 -w + 自行判状态码：-f 在 4xx 时只吐一行
`curl: (22) 404`，把响应体丢掉，而 404 响应体里恰是「现有分类」清单，
是排查时最需要的。现在 401/404 都会给出可行动的中文提示，
退出码 0/2/3/4/5/7/8 各有语义。
2026-09-26 14:47:32 +08:00
b1b63497bc
docs(kbtree): 补客户端封装脚本 + 本机部署交接说明
...
SKILL.md 里原本只有 curl 示例，agent 用起来要自己拼 URL 与鉴权头。
补 scripts/kb_tree.sh（照 dify-ops 的做法把脚本随 skill 分发）：
- 子命令 tree/categories/counts/search，选项 -q/-c/-d/-i/-l
- token 读取顺序：KB_TOKEN 环境变量 → config/config.json。
**故意不接受命令行传 token**（会进 shell 历史与 ps 输出）
- 预检端口：不通时直接说明「服务未上线」并给出上线步骤，
而不是抛 curl: (7) Connection refused 让用户自己猜
- 错误翻译成人话：401 → 令牌无效；404 → 附上服务端返回的现有分类
（用 curl -w 而非 -f，否则 404 响应体里最有用的那份清单会被丢掉）
- 退出码：0 成功 / 2 参数 / 3 令牌 / 4 分类不存在 / 5 HTTP / 7 连不上 / 8 请求失败
DEPLOY.md 是给部署方的交接单：本机 kbtree 代码已合入 main 且 skill/token
已就位，但**运行中的二进制里没有 kbtree**（14:35 有人换过一版二进制），
故替换与重启留给部署方。含备份/替换/验证步骤、回滚方式、端口与 token 说明。
token 与 config.json **不入库**（config/ 目录留空），安装时由部署方从
配置库 config_kbtree 表读取后写入本机。
2026-09-26 14:43:46 +08:00
076e53c7ba
fix(webui): 星图依赖本地化 —— 不再从公网 CDN 拉 three.js
...
用户点「星图」看到「3D 星图不可用（CDN 加载失败）」。
服务端 curl 那两个 URL 都是 **200** ⇒ 不是服务端的问题，是**浏览器**
访问不到公网 CDN（内网 / 出口受限 / 断网）。dashboard.html 从 cdnjs 与
jsdelivr 拉 4 个库：three.js、OrbitControls、marked、DOMPurify。
换 CDN 只是把同一个赌注重下遍。HomeAgent 明确支持离线与内网部署，
前端却有 4 个硬依赖在公网上 ⇒ 断网即坏，且用户无从修复。
顺带两个收益：
- **安全**：DOMPurify 是净化 Markdown 的关键一环，它挂掉前端会退化到
「不净化」分支（dashboard.js 里有 typeof 检查）—— 那是安全降级，
比星图坏更值得修。
- **体积**：四个库共 ~700KB，embed 后由本服务同源提供，省掉 4 个跨域握手，
也不再受第三方可用性影响。二进制 84MB → 84.7MB（+0.8%）。
- `internal/plugins/webui/static/` 放四个库（固定版本，随二进制走）
- `//go:embed static` + 新增 `/static/` 路由
- dashboard.html 的四个 src 改指 `/static/...`
- 加载失败兜底 8s → 3s（本地是毫秒级；仍超时就说明真有问题）
`/static/` **不走 requireWeb**：未登录时页面也要加载这些库才能渲染登录框，
加认证会让用户看到白屏（比 401 更难自查）。这些资源不含用户数据。
- TestDashboardHasNoExternalCDN：页面不得引用任何公网 CDN
- TestStarmapDependenciesAreLocal：星图两个库必须来自本地
- TestVendorFilesExistInSourceTree：vendor 文件必须在（embed 的前提）
- TestStaticVendorRoutesServeRealLibraries：路由**必须真的返回库内容**
★ 最后一条的判据强度是补出来的：初版只判状态码，变异「返回 200 + 空体」
时**仍然绿** —— 而空体在浏览器里的症状与 404 完全一样（都报加载失败）。
改为同时判体积与特征串（REVISION / OrbitControls / marked / DOMPurify）
后，变异「只写前 10 字节」判红。
变异验证 3 条：HTML 改回 CDN → 2 条判红；路由挂回 requireWeb → 503 判红；
截断响应体 → 体积判红。
全量 38 包全绿。
2026-09-26 14:41:32 +08:00
ebf6df319b
feat(kbtree): 知识库分类树的独立只读服务 + agent 技能 + WebUI 树浏览
...
让**外部 agent** 也能按分类树用这套知识库。HomeAgent 自己的 agent 仍
直接调内部方法（knowledge_search/create 等），走进程内直调，不经此服务。
一、内核树视图（internal/knowledge/tree.go）
为什么不复用 TreeIndex：那个是**内部导出物**，面向 .index.json 落盘，
每个条目带 top-20 的 TF-IDF 特征向量。直接序列化给外部有三个问题：
体积（200 条时 .index.json 已 246KB 且冗余存了 preview，而正本在
content.md）、泄漏（稀疏特征表 = 分词/IDF 内部表示）、语义错位
（外部要的是"有哪些分类、每类下有什么"）。
新增 TreeView/Subtree/Categories/CategoryCounts：不含向量，带条目数
与可读摘要，支持 MaxDepth 懒加载、IncludeItems 只看结构。
节点 Name 是**本级段名**（"go"）、Path 是完整路径（"tech/go"）——
最初把全路径写进 Name，前端拼层级会得到 "tech/tech/go"，已修。
二、kbtree 插件：独立 HTTP 服务（默认 127.0.0.1:9892）
为何不挂在 WebUI 的 /api/v1/knowledge* 下：
1. 不共享鉴权与端口。WebUI 的 api_key 是给人操作界面用的，把它分发给
外部 agent 等于把管理面凭据扩散出去。本服务用**独立 token** +
独立端口，可单独关闭（token 未配置则启动时随机生成）。
2. 只读。写入要决定分类归属与媒体处理，外部自行拼装容易造出越界/重名
条目 —— 写入留给内核工具。
3. 形状按树组织，而不是平铺搜索接口。
端点：/tree（可指定 category/depth/items）、/categories、/counts、
/search、/ （自述）。全部需 token（X-API-Key / Bearer / ?token=），
非 GET 一律 405。无知识库时 Start 直接失败，不占端口。
鉴权与 Slowloris/超时设置照 remotedevice 范式。
三、agent 技能（assets/skills/knowledge-base/SKILL.md）
指令文档型 skill：教模型"先看树 → 定位分类 → 分类内检索"，并列出
易错点（name 已含分类别再拼、只看第一条、404 附现有分类）。
加载与校验由 internal/plugin/skill_bundled_test.go 守住 —— 这条断言
的由来：非白名单的二级标题会被 extractToolDefs 当成工具定义，报错
"invalid tool name"，而提示与真正原因（标题层级）毫无关联。
kbtree 的测试还会校验文档提到的端点与代码一致，防漂移。
四、WebUI 树浏览（前端真正用起来，而非留一个没人调的端点）
面板加可折叠的分类树：逐级点选即把搜索范围切到该子树（原先是让人
手打分类名）。当前范围有可见标签与「全库」复位。
2026-09-26 14:20:19 +08:00
531d7f41f4
test(knowledge): 端到端验证多模态与分层链路 + 修稠密路同分次序不确定
...
一、修缺陷：denseHits 同分次序随机
稠密路用 map 遍历 + 只按分数排序，**没有 tie-break**：同分条目的相对
次序随每次调用变化 ⇒ 同样的查询两次可能给出不同首位（用户看到结果在跳，
测试偶发变红）。Search 的主排序早就有「分数相同时按名字定序」，这条漏了。
补上同分按 id 定序，并加 TestDenseHitsTieIsDeterministic 反向守住
（撤掉 tie-break 后该测试在 5 次运行里稳定报出首位跳变）。
二、端到端验证（两个新文件）
- TestMultimodalEndToEndWithRealProvider：走**真实 embedding provider**
（内置 http provider + 一个符合内核契约的最小服务），覆盖
embedding.Open → AdaptProvider → media CAS → SetDenseSpace/SetMediaGetter
→ AddWithMedia（文本⊕图片融合）→ 以图搜知识 → .dense.json 落盘 →
重启命中缓存（ReindexDense built=0）。
不用 ONNX provider 是因为真模型 200MB 权重 + 3 分钟加载，进不了 CI；
该链路是 provider 无关的（AdaptProvider 之后内核只认 MultimodalEmbedder）。
- TestHierarchicalIndexEndToEnd：多层分类（tech/go/两段、tech/rust/两段）
的 Category 推导、树导出结构与挂载点、三级前缀过滤检索、范围外排除、
索引落盘、重启后不漂移、树在重启后仍可用。
反向验证：把 inScope 改成恒真后该测试稳定变红（报出范围外条目混入），
确认它真能抓到「分层不参与召回」这一退化。
三、额外实测（本机，非 CI）
带 onnxruntime tag（生产构建形态）下用真实 Qwen3-VL 模型跑通全链路：
provider dim=2048 modalities=[text image] fp=e43381246264...
photo.Dense = 文本⊕图片融合结果
以图搜知识 top1=photo score=0.757 ← 真正的跨模态召回
重启后 ReindexDense built=0（命中缓存）
另确认默认构建（无 tag）下 qwen3vl 是 stub、Open 明确报错，不会静默降级成
"看似可用"。Makefile 的 HOMED_TAGS 默认即 onnxruntime，故发行版默认启用。
2026-09-26 14:20:19 +08:00
c4ba7b148c
feat(kb-migrate): 存量知识库目录名迁移工具 + 启动期只报告
...
背景：旧版 Add 整串 sanitize 名字、逐段 sanitize 建目录，留下 tech/_go_/note、
Tech/Upper、a/b with space 这类「知识名与盘上目录不一致」的目录。修复后
normalizeName 要求二者逐字一致，故需一次性改名。
- 迁移逻辑放在 internal/knowledge/migrate_names.go（PlanMigration/
ApplyMigration），CLI 与 homed 启动**共用同一份实现**，避免口径漂移。
- 三条硬约束：
1. 默认只报告（-apply 才真改名）—— 批量 os.Rename 不可逆。
2. 检出目标名冲突（两条迁到同一目标 / 目标已存在）则**整批拒绝**，
不做部分迁移：半迁移状态比不迁移更难收拾。
3. 逐条失败不中断，最后统一报告；执行前重查冲突（计划生成与执行之间
可能有人改过盘上状态），并校验目标不越出知识根。
- homed 启动在 initKnowledgeStore **之前**调 initKnowledgeMigration：改名后
扫盘一次到位，避免先以旧名建索引再改名造成内存键与盘上目录短暂不一致。
defaultApply=false ⇒ 启动只扫描+报告+打印可执行命令行，不替人决定。
单次改名上限 200 条，防失控目录规模拖住启动。
实测：报告模式零改动；冲突场景整批拒绝且盘上原封不动；迁移后 Store
正确载入 4 条并可按规范名逐条删除。
2026-09-26 14:20:19 +08:00
d3a796fde2
fix(webui): 知识库不再把二进制当文本存 + 接上分类/媒体/删除 + 实时计数
...
后端（handler_memory.go 重写 handleKnowledge）：
- ★ multipart 分支原来无条件 file.Read → string(buf[:n]) → 当 Markdown 存进
content.md：传一张 PNG 得到的是一份乱码文本知识，还在 .index.json 占一份
preview，且**没有任何迹象**表明出了问题。
现在按 http.DetectContentType 探测的**真实类型**分流（不信客户端声明的
Content-Type——谎报 text/plain 的 PNG 在测试里是真实场景）：
媒体入 CAS 按 digest 挂条目 / 文本校验 UTF-8 后存正文 / 都不是则 400 明确
拒绝并回传 rejected 清单。
- 状态码语义修正：此前 POST/GET 一律 500、DELETE 一律 404，把「名称非法」
这类调用方能自己纠正的错报成服务器故障。现按 errors.Is 分流
400/404/503。
- 搜索支持 category 与 limit；返回 knowledgeView（不泄露服务端绝对路径，
不回传几百 KB 的 Dense 浮点数组）。
- 列表端点补 dense 状态（前端据此提示多模态是否就绪）。
- 媒体存储未接线时上传图片返回 503，而非退化成把二进制当文本存。
前端（dashboard.js）：
- 搜索结果从 <pre>{JSON}</pre> 改为结构化渲染（名称/体积/预览/媒体标记
+ 每条删除按钮）。此前前端根本没有删除入口。
- 新增分类输入框（走 category 参数）、多文件上传。
- 计数改实时：原先读 state.kernel 快照，知识条目经工具/上传增删后不会变
（实测创建完仍显示 "-"）。切到知识面板时拉 /knowledge 的真实 names.length。
- 顶部输入框变多文件；显示多模态就绪状态（ready/total）。
2026-09-26 14:20:19 +08:00
9e282ad774
feat(knowledge): 分类过滤与多模态打通到工具/插件边界
...
- internal/sdk：KnowledgeAPI 增加 SearchIn/AddWithMedia/AttachMedia/
ReindexDense/DenseStats；新增 MediaAPI（Put/Stat/Get）与 PluginSDK.Media()，
registry 装配。**公开 SDK 契约一字未动** —— third_party/homeagent-sdk/sdk/
的 diff 恒为 0（发布纪律的硬约束），走 internal/sdk 这条明确不受冻结约束
的内部扩展路径。
- proc：新增 knowledge.addWithMedia（正文与媒体清单都走共享内存，与
doc.insertWithMedia 同形）；knowledge.search 支持 category。
- corehandler 用**局部接口 + 类型断言**取扩展能力，而非直接引 internal/sdk：
后者已依赖 internal/plugin 的类型，直接引会成环（CoreSDK 注释已警示）。
断言失败明确报"能力不可用"，不静默退化成"媒体已写入"。
- agent 工具面：knowledge_search 增加 category；knowledge_create 增加
media_digests（复用 doc_commit 的 digest 前缀解析 + Stat 回读 MIME）。
顺带修 knowledge_search 的分类前缀重复（Name 已含分类，旧代码又拼一次，
实测输出 tech/go/tech/go/并发）。
- agent 启动接线多模态空间，顺序为先接线再 ReindexDense（否则首次启动
算出的向量因 MediaStore 未就绪而不落盘）。
2026-09-26 14:20:19 +08:00
e2b96e0686
fix(knowledge): 名称规范化/路径安全 + IDF 增量维护 + 多模态稠密路 + 派生数据落盘
...
一次知识库子系统的集中加固，四类缺陷各有实测复现：
1. 名称与路径（数据安全，最严重）
- sanitize 不过滤 .. ⇒ Remove("..") 直接 RemoveAll 掉整个数据目录
（实测把 <data> 整棵删掉，含 memory/documents/media），且返回 nil，
工具层回报"已删除"；Add("../../x") 写到知识根外，重启扫不回来
⇒ 幽灵条目。
- Add 整串 sanitize 而建目录逐段 sanitize，内存键与盘上目录从**第一次
落盘起**就不一致；重启后 name 漂移，knowledge_delete 静默删不掉
（RemoveAll 删空目录返 nil）。同一个根因。
- 修法：新增 normalizeName 作为唯一入口（逐段 + 拒绝空段/点段/隐藏段）；
Remove 改为取条目自记的 Path（不再用名字重拼）+ 返回 ErrNotFound。
- resolve 三层退让（原样 → 规范名 → 叶名大小写不敏感，唯一命中才接受）：
scanDir 按盘上目录原样建键，遗留大写目录若只查规范名会变成
"List 看得到、Remove 报不存在"。删的路径仍取自 Path，退让无风险。
2. IDF 与索引不同步（功能缺陷，非优化）
- TFIDF Vectorize 跳过 df<=0 的特征，而 Add 只往只增不减的 summaries
追文本、从不更新 DF ⇒ 库满(≥3篇) + 新词时，新知识**当场搜不到**，
重启才恢复（实测 Search("量子纠缠") == []）。
- 修法：vector.Store 新增 AddDoc/RemoveDoc（文档级去重口径与 Train 一致，
totalDocs 下界守卫，零频 DF 删除防表膨胀）；knowledge 删掉 summaries，
改 index/unindex/retrain 三件套，覆盖写先 RemoveDoc 旧文本。
3. 多模态稠密路（此前知识库端到端纯文本）
- 新增 SetDenseSpace/SetMediaGetter/ReindexDense/DenseStats 与
AddWithMedia/AttachMedia，媒体成为一等节点参与跨模态召回。
- 维度与指纹双守卫：维度不符的向量会被 FuseVectors 按最大维度拼成错维度
结果且被当成"已对齐"永久错下去（docStore 踩过）；模态不支持(音频)时
静默跳过该媒体、退化为纯文本向量，绝不拿别的模型的向量顶替。
- 未注入多模态空间时行为与此前逐字一致（退化为 0.5/0.5 两路融合）。
4. 派生数据落盘 + 分层参与召回
- 媒体引用是**作者数据**（丢失即丢信息）→ 条目目录内 .media.json；
稠密向量是**派生数据**（可重算）→ 全局 .dense.json，tmp+rename 原子。
混存会让派生数据损坏连带作者数据一起丢。
- 新增 SearchIn(query, category, topK)：分类前缀匹配子树，让分层真正
参与召回（此前检索全库平铺，分层只是存储布局）。归一化取作用域内
最大值，否则范围外的强命中会把域内分数压没。
- 删除 SearchTree/SearchCategories 死代码（零调用方，且停留在 Search
修复前的单路口径：无词法融合、0.05 阈值）。
顺带修掉 Add 的 O(N)/写：buildTreeLocked 逐条重算向量（s.vec 里已有）
改为一次建表复用；.index.json 改为标脏 + Flush/Stop 收口。实测单条 Add
2.1ms@50 → 13.7ms@400 压平到 ~400µs（34×）。
存量目录改名迁移落在 migrate_names.go，只报告不改名（os.Rename 不可逆），
冲突整批拒绝以免半迁移。
2026-09-26 14:20:18 +08:00
b381f34259
docs(sdk): 修正 ProxyReg 字段注释里的旧名（DeclareProxy→RegisterProxy）
...
Rename 时漏改了字段注释。代码本身一致（proxyReg 字段 + RegisterProxy 方法），
但注释里写着一个不存在的 API 名，读者按注释找不到方法。
2026-09-26 13:49:59 +08:00
8b85f9f9fe
fix(webui): 旧反代两条路径合并修复 —— 302变502/泄露内网URL/流式被缓冲
...
新反代（proxy.go）早已修掉这些，但**两条旧路径**没跟上，各自复制了一份
http.DefaultClient 实现：
proxyToPluginmgr （handler_settings.go）
handleDeviceGatewayProxy（handler_device.go）
同一个 bug 修了两遍还漏了两处。抽成共用的 reverseToUpstream，不再分叉。
## Bug 1：跟随上游 3xx → 302 变 502 + 泄露内网 URL
http.DefaultClient 默认跟最多 10 跳。上游回 302 时反代跟过去，目标可能是
内网另一个服务或不可达，于是把「上游的 302」变成「本层的 502」，
错误里还带着内网地址：
{"error":"device gateway unreachable: Get \"http://127.0.0.1:1/api/ ...\":
dial tcp 127.0.0.1:1: connect: connection refused"}
外部用户看到 Bad Gateway + 他访问不了的内网地址：既无用又泄露拓扑。
→ 反代**不应有重定向策略**（那是客户端的事），原样透传 3xx。
→ 上游错误细节只写日志，对外统一「上游服务不可达」。
## Bug 2：不逐帧 flush，流式响应被缓冲到结束
原实现 io.Copy(w, resp.Body)，ResponseWriter 自带缓冲 → 上游按帧下发的
SSE/长轮询内容全堆到上游结束才吐。裸 TCP 实测：上游每 80ms 一帧共 3 帧，
缓冲版本只产生 **1 次**读（集中在 161ms），客户端表现为「卡住不动然后
一次性全出来」。改用 flushCopy（4KB 块 + 块间 Flush）。
## Bug 3：不过滤逐跳头
Content-Length / Transfer-Encoding 描述的是**上游那条连接**的分帧方式，
照抄到本层连接会导致客户端按错误长度读；Keep-Alive/Connection 同理。
按 RFC 7230 §6.1 剔除。
## 附带修正
- 补 X-Forwarded-For / X-Real-IP / X-Forwarded-Host / X-Forwarded-Proto，
且**只在尚未设置时补** —— 外层 nginx 已注入时覆盖会丢掉真实客户端 IP。
- 与 proxy.go 新建了带超时的 upstreamClient（DefaultClient 无超时，
上游卡住会拖住 goroutine）。
## 判据（5 条）+ ★ 判据设计的两个坑
★ 这条判据我试错了三轮，过程留在测试注释里：
1. 「首帧早于末帧」→ **假绿**。Go 在响应结束后把缓冲一次吐出，首末帧仍有
微秒级差，任何 `> 0` 都绿。
2. 用 http.Client 量「首帧延迟 < 上游总时长 70%」→ 仍是**假绿**。实测直连
上游首帧 761ns、总时长 160ms：Go 的 HTTP **客户端**合并读，量到的
「首帧」是客户端首次取到数据的时间，与服务端何时 flush 无关。
3. 当前（正确）：**裸 TCP 直连被测服务**，看读到几次、分别在什么时刻。
对照组实测 3 次读 / 0.24ms / 80ms / 161ms —— 正是上游节奏。
第二个坑：不能按「累计 12 字节正文」判结束（首读含响应头 + 首帧正文，
会在首读就以为读完，后两帧时序全丢）。改为读到 EOF。
变异验证 4 条（均按预期打红后还原）：退回 DefaultClient → 跟随重定向判红；
错误信息带 err.Error() → 泄露判红；退回 io.Copy → 只读到 1 次判红；
不过滤逐跳头 → Keep-Alive 判红。
全量：35 包全绿。
2026-09-26 13:49:59 +08:00
aa08b1b903
fix(webui): Server 读侧超时（防 Slowloris）+ 反向判据守住流式不被腰斩
...
http.Server 原本**一个超时都没设**（只有 Handler）。后果是 Slowloris：
攻击者只占连接不发完整请求头，每个连接挂几 KB。MaxHeaderBytes 限的是
头部**大小**，「慢慢发」不占大小、不受它约束，几百个连接就能耗尽 fd。
## 为什么不是「把超时都设上」
webui 有一条长连接 SSE（/api/v1/chat/events）与可跑 300s 的流式
/v1/chat/completions。WriteTimeout 是「从请求开始到响应写完」的**总预算**，
会把它们腰斩 —— 表现为 SSE 每隔一段时间断一次、前端疯狂重连。而这类
回归在功能测试里很难立刻发现。
所以只设读侧三项，各管一段：
ReadHeaderTimeout 20s —— 请求头必须按时发完，Slowloris 的正解
ReadTimeout 60s —— 读完整请求（含 body）的预算，防慢速上传
IdleTimeout 120s —— keep-alive 空闲连接（另两项都管不到）
WriteTimeout 0 —— **刻意不设**（见上）
## 判据（3 条，含一条反向判据）
- TestServerHasReadSideTimeouts：三个读侧超时都必须 > 0
- TestServerHasNoWriteTimeout：**反向**钉住 WriteTimeout 必须保持 0，
防止将来有人「顺手补全超时」把 SSE 弄坏
- TestSSEConnectionSurvivesBeyondReadTimeout：SSE 连接确实活过读侧窗口
反向判据看着琐碎，但它守的正是「这次没做的那件事」——
不加 WriteTimeout 是个**决定**，不是疏漏，所以要用判据把决定固定下来。
变异验证：补上 WriteTimeout:30s → 反向判据判红；
去掉 ReadHeaderTimeout → 前向判据判红。
测试脚手架注意：newServerForTest 绑 127.0.0.1:0（内核分配空闲端口），
绝不用 :8080 —— 那是生产端口（见 a752ae1）。
全量：35 包全绿。
2026-09-26 13:49:59 +08:00
0f8ca6894a
fix(webui): 限流来源识别改为「只信任受信反代的 XFF」—— 修复把自己锁在门外
...
★ 这是在生产上亲手踩出来的：上一提交加了按 IP 限流后，我用 8 次错误登录
做验证，结果**把管理员自己锁在外面 10 分钟**。
## 现场证据
[webui] POST /api/v1/login from=127.0.0.1 auth=none status=429
webui 经 frp/nginx 穿透到公网时，**所有外部请求的 RemoteAddr 都是
127.0.0.1**。于是所有人共用一个桶：任何人爆破 5 次，就把**所有人**
（含管理员）一起锁死。限流从防护变成了 DoS。
## 我第一版还犯了个方向的错
当时我刻意**不采信** X-Forwarded-For，理由是「该头可伪造，换个头就能
绕过限流」。这个理由本身对，但结论下反了：完全不采信，在穿透部署下
**必然退化成全局限流** —— 而全局限流正是我试图避免的那个后果。
## 正确做法：中间路线
**只信任受信反代发来的 XFF**。判定「是否来自受信反代」不能靠
内网/回环 IP 猜 —— 穿透部署下反代恰恰就在本机 127.0.0.1，与直连请求
完全同源，猜不出来。所以由部署方**显式声明**（新设置项
`webui.trusted_proxies`，逗号分隔 CIDR 或裸 IP）。
权衡写明：未声明时穿透明场景下限流退化为「全局」。这是**刻意的保守
默认** —— 宁可限流偏保守，也不能因为采信伪造头而形同虚设。
## 判据（+4）
- TestLoginRateLimitUsesForwardedForFromTrustedProxy：受信反代下按真实
客户端 IP 隔离（否则就是全局锁）
- TestLoginRateLimitIgnoresUntrustedForwardedFor：换 XFF 头不得绕过限流
- TestLoginRateLimitNeedsExplicitTrustedProxyConfig：未配置 = 不采信
- TestParseTrustedProxies：合法项接受、非法项丢弃、空 = nil
全量：35 包全绿。
★ 附带教训（也记在判据注释里）：**用失败注入做验证时要意识到副作用
范围**。我那次「跑 8 次错误密码看看会不会限流」本身是合理的验证动作，
但它作用在**生产实例**上，且限流的作用域（全局化）正好覆盖了自己。
在带状态的安全机制上做破坏性验证，判据应该先证明作用域是对的。
2026-09-26 13:49:59 +08:00
f146781b4b
fix(webui): OpenAI 兼容面 —— 补 /v1/models + 真流式（原先是假流式）
...
/v1/* 是**给外部程序用的**（IDE、脚本、agent 框架），不是给人看的聊天页。
它的行为必须真符合 OpenAI 协议，否则调用方直接坏掉。下面两条都在
**生产实测**中确认过，不是推理。
## ① GET /v1/models → 404
几乎每个 OpenAI 客户端（curl 脚本、LangChain、OpenAI SDK、IDE 插件）
启动时都会先列模型来探测服务可用性。404 让它们直接判定「服务不可用」，
连试都不试 —— 这是集成方最容易踩空、也最难自查的缺口（表现为
「连不上」，而实际端点是通的）。
新增 handleOpenAIModels。返回什么模型**不重要**，结构合法才重要：
本端点不做模型选择（model 只是回显），所以只暴露 HomeAgent 自身。
不谎报 GPT 之类名字 —— 那会让用户以为能选模型，实际不能。
## ② stream=true 是假流式
实测：首字节 7.79s，随后**整段**内容在一个 chunk 里到达。
根因：两条路径都走 InjectTextSyncNoMemory —— **同步等完整回复**才返回，
之后才把已拼好的全文切成 3 个 chunk 吐出去。客户端的「生成中」/取消/
超时/进度条全部失效；300s 超时表现为「卡 5 分钟然后一次性出现」。
重写为真流式：先订阅 EventContentDelta / EventReasoningDelta **再**启动
注入（顺序反了会漏开头几个分片），边收边转成 chunk，最后用同步调用拿到的
完整回复补 usage、发 finish、[DONE]。沿用 handleSSE 的成熟结构
（批量 16ms 合并、独立 writer goroutine、done channel 而非 close）。
顺带处理内核的 reset 事件：流式失败回退非流式时内核会发
content="" + reset=true（见 internal/agent/core/process.go）。忽略它会让
客户端看到半截内容后又接上完整内容（重复且自相矛盾），故识别并丢弃累积。
## 判据（4 条，变异验证）
- TestOpenAIModelsEndpoint / RequiresAuth
- TestOpenAIStreamIsActuallyStreaming
- TestOpenAINonStreamUnchanged（别把非流式改坏）
★ **判据本身踩了两个坑，都已修正并记在测试注释里**：
1. `httptest.ResponseRecorder` 把整个响应**缓冲在内存里**，请求结束才交付
—— 它**根本观察不到流式**。用它写的流式判据必然是假的。故改用
`httptest.NewServer` + `bufio.Reader` 逐帧读。
2. 「要求首帧早于末帧」**抓不住**假流式：假流式确实是分多次 write 的，
帧间间隔是微秒级 > 0，任何 `> 0` 判据都绿（已实测）。
真正能区分的是：**首帧是否早于「内核产出最终答案」那一刻**。
于是假内核被构造成：发 3 个增量后**扣住**最终响应，直到消费者
表现出「已在读帧」才放行 —— 真流式首帧 0.35s，假流式首帧 3.30s。
3. 鉴权判据一度写错：未登录时门户 302 到 /login，若跟随重定向就会拿到
登录页的 200，把「被重定向」误判成「鉴权通过」。改用不跟随重定向的
客户端。
变异验证：去掉 /v1/models 路由 → 判红（还原 404）；
不转发增量 → 判红（首帧 3.30s）。
全量：35 包全绿。
2026-09-26 13:49:59 +08:00
b4c6b17721
fix(webui): 登录入口加固 —— 限流 + 常量时间比对 + 请求体限量 + 防用户名枚举
...
门户可经 frp 穿透到公网（https://homeagent.jianfgit.xyz/ 实测直达），
而 handleLogin 原先是**零防护**：无限流、无失败计数、口令用 == 明文比对、
失败不审计。等于把唯一��口令入口直接开到外网任人爆破。
## 改动
1. **按来源 IP 的失败计数限流**（login_limiter.go）
- 5 次失败后拦，10 分钟窗口。
- 退避而非永久封禁：窗口过期自动恢复。永久封禁意味着一旦误撞
（或被撞库）就再也登不进，只能上机器改配置。
- 成功即清零：手滑输错几次不该被永久记账。
- **刻意不采信 X-Forwarded-For** —— 该头可伪造，直接采信等于让
攻击者换一个头就能绕过限流，甚至把限流当成打别人来源的武器。
代价（已在注释写明）：若 webui 挂在反代后，限流会退化成「全局」，
那种部署应在反代层限流或用 PROXY protocol 传真实来源。
- **刻意不做账号级锁定**：本系统只有一个管理员账号，账号级锁定
相比 IP 级无额外收益，却多一个误伤面。
- 过期记录会被 prune —— 否则攻击者轮换 IP 就能喂成内存泄漏。
2. **常量时间比对**（crypto/subtle）：`==` 会在第一个不同字节处短路，
泄漏「猜对了几位」的时序信息。
3. **请求体限量**：ContentLength 前置拒绝 + MaxBytesReader 兜底。
★ 后者**不能只靠解码器报错** —— json.Decoder 按需读流，遇到
「超大 + 非法 JSON」会在第 0 字节就报语法错误、永远读不到上限，
于是 8MB 数据已进缓冲而 MaxBytesError 从未出现。只挂 MaxBytesReader
的写法对最省力的攻击载荷反而无效（实测确认）。
4. **防用户名枚举**：用户不存在与口令错误给完全相同的状态码与报文。
## 判据（8 条）
限流触发 / 按来源隔离（否则一个 IP 就能把所有人锁死，限流即 DoS）/
成功清零 / Retry-After / 请求体限量 / 防枚举 / 过期清理 / 重试时长非零。
变异验证（3 条打红后还原）：
- 去掉限流调用 → 3 条判红
- 去掉 ContentLength 前置检查 → 判红（回到 400）
- 去掉 Reset → **起初没打红**：原判据「跑 30 次看是否限流」在阈值只有 5
时无论有没有 Reset 都会限流，是条**假判据**。已改为**测出实际阈值**
（清零后应重新拿到完整额度），再去变异即打红。
诚实说明：常量时间比对那条**无法用单测可靠断言**（时序属性，噪声远大于
信号）。它由代码评审保证，不由测试保证 —— 写明以免后人以为有测试兜着。
2026-09-26 13:49:59 +08:00
428f148374
fix(webui): 服务入口「打开」改用路径形态 + 别名模式不补尾斜杠
...
验收时发现的**用户可见缺口**：API 早就同时返回 url（子域）与 url_portal
（路径），但「服务入口」卡片只用了 url —— 而子域形态在穿透部署下
**恰恰是打不开的那个**（外层只放行一个 Host、三级子域通配证书不匹配）。
用户点「打开」得到坏链接，还会以为是插件的问题。
## 改动
1. 卡片「打开」优先 url_portal（路径形态）：
无 DNS 依赖，单端口穿透 / 子域无证书时都能用。
子域链接保留为次选按钮（局域网内直连时更直观）。
文案补一句说明两者差别（子域需 DNS 能解析 `*.<基域名>`）。
2. **别名模式不再补尾斜杠**（顺带发现的 bug）：
原实现给所有 url_portal 无条件加 `/`。前缀模式下对（那是规范形态，
前端靠它算相对路径基准）；别名模式下错 —— 那里的 path 是上游真实
路径语义（/api/v1/device 是 /api/v1/device/xxx 的前缀），补成
/api/v1/device/ 会让人误以为存在一个可访问的根。
## 判据
+2 条：TestProxyServicesOffersBothForms（两种形态都必须给出，
且前缀模式的 url_portal 必须带尾斜杠）、
TestProxyServicesAliasKeepsExactPath（别名模式不得带尾斜杠）。
变异验证（2 条，均按预期打红后还原回绿）：
- 别名模式也加尾斜杠 → 判红
- 前缀模式不加尾斜杠 → 判红
另修正一条旧判据的期望值：它当年断言的是「所有 url_portal 都带尾斜杠」
（即把 bug 当成契约钉住了）。那条路由正是设备网关（别名模式），
现在改为断言不补尾斜杠，并注明理由。
全量：35 包全绿。
2026-09-26 13:49:59 +08:00
dfcfe3593d
fix(test): 测试不再抢生产端口 :8080（internal/plugins 加载内置 webui 所致）
...
部署过程中反复出现「8080 被 plugins.test 占用」导致生产 WebUI 起不来。
追到底：internal/plugins 的集成测试会 pluginReg.Load(全部内置插件)，
其中 webui 默认监听 :8080 —— **正是生产实例的端口**。
## 为什么这个 bug 特别难查
它不是测试失败，而是**测试与生产静默抢端口**：先到者胜，另一个 bind 失败。
- 跑测试的人看到「测试随机失败」（其实是生产先占了）
- 用生产的人看到「WebUI 随机死掉」（其实是测试先占了）
- 两边现象互不相干，且各自单独重跑往往都过
叠加 webui 已有的「bind 失败必须显式报错」修复后，症状从「静默死亡」
变成「随机报错」，这反而让归属更容易看错 —— 我一开始也是先怀疑自己的
部署脚本，直到采样 /proc/<pid>/cwd 才确认是测试进程。
## 修法
集成测试在 Load 之前用既有的 SetListenOverride 把地址指到
127.0.0.1:0（内核分配空闲端口），并在 cleanup 还原。
测试因此拿到真实可用的 HTTP 服务，且与任何固定端口实例完全隔离。
- webui 新增 ListenOverride() 读取当前值，供调用方保存/还原
（只有 setter 时无法在不破坏调用方状态的前提下做临时覆盖）。
## 验证
- 修复前：跑 ./internal/plugins/ 期间 8080 持续归 plugins.test（109/200 采样）
- 修复后：35 次采样全程 8080 归 homed，测试同时全绿
- 变异验证：移除 override 后立刻复现抢端口，判据有效
另记两个测试卫生问题（同一根源，已顺手清理泄漏进程）：
测试会启动**真实插件进程**（/home/newqqagent/plugins/*/plugin.bin）。
kill 测试进程后这些子进程会残留。已全部清理，生产 23 插件恢复正常。
2026-09-26 13:49:59 +08:00
fa5965e253
feat(webui): 路径挂载的 strip_path 两态 + 尾斜杠重定向（修 /p/huawei 打不开数据）
...
用户要求用方案 A（路径挂载）让 huawei 插件 UI 在外部可用，
并把「通过反代的插件必须使用单一入口」写入 SDK 声明。
## 实测暴露的两个真问题
1. **Path 的语义不能一刀切**。原设计「原样保留」只对**机器接口**成立
（设备客户端硬编码 /api/v1/device/ws，不可能知道反代的存在）；
而自带 UI 的服务需要**剥掉前缀**（/p/huawei/api/status → 上游 /api/status）。
猜错的结果是全部请求 404，且看起来像上游故障 —— 所以由声明者选：
strip_path=false 别名模式 / true 前缀模式。非法组合被 validate 挡住。
2. **前缀模式的尾斜杠是必需的**（自测发现的 bug）。
访问 /p/huawei（无尾斜杠）时页面能开，但页面里所有 fetch 都 404 ——
相对路径以「当前文档目录」为基准，没尾斜杠时浏览器把最后一段当文件名，
目录退回上一级，fetch('api/status') 打到 /p/api/status。
修：前缀模式且路径恰等于前缀时 301 到 /p/huawei/（保留查询串）。
**别名模式不做此事** —— 那类路径是上游真实语义，加斜杠会改坏它。
## 插件侧（huawei_smarthome）
- 前端 4 处根绝对路径（fetch('/api/status') 等）改为相对路径，
基准由 location.pathname 推导（BASE）。这是 Path 形态能成立的**前提** ——
否则请求会打到门户自己身上。
- plg.json 声明：host + path=/p/huawei + strip_path=true + auth=homeagent。
- SDK 升到 1.4.0，并用 hmapdev 1.4.0 重新打包（1.3.0 的 hmapdev 无
proxies 支持，会把声明**静默丢弃** —— 实测确认过，这是打包链路上
一个不报警的坑，值得记住）。
## 判据
+6 条：TestProxyPathAliasVsStrip（两态各自正确）、
TestProxyPathLongestPrefixWins（/p/app 不得劫持 /p/apple，
且长前缀胜出）、TestProxyStripPathRedirectsToTrailingSlash（尾斜杠，
含查询串保留 + 别名模式不得重定向）。
变异验证（4 条，均按预期打红后还原回绿）：
- 删尾斜杠重定向 → 判红（还原了真实 bug 形态）
- 让别名模式也重定向 → 判红（设备网关语义被毁）
- 从 hmapdev schema 探测体删 StripPath → 判红（漂移检测有效）
- 删 SDK 里的「单一入口原则」字样 → 判红（契约不能只剩口头约定）
全量：35 包全绿。
2026-09-26 13:49:59 +08:00
1527fa4e9b
feat(webui): 外部入口 base_url 配置 —— 穿透场景下链接不再靠猜
...
用户指出 webui 实际是经 https://homeagent.jianfgit.xyz/ 穿透出去的，
应当支持配置 base URL。实测确认了这个诉求的正当性。
## 实测发现的约束（决定方案）
1. **子域形态在外部不可用**：`*.homeagent.jianfgit.xyz` 泛解析存在，
但外层只给 `*.jianfgit.xyz` 通配证书 —— 该证书**不匹配三级子域**，
实测 `huawei-smarthome.homeagent.jianfgit.xyz` 外部握手失败（HTTP 000）。
外层只放行 `homeagent.jianfgit.xyz` 这一个 Host。
2. **路径挂载形态外部可用**：实测
`https://homeagent.jianfgit.xyz/api/v1/device/online ` → 200。
所以「一个外部 Host + 路径挂载」是这条链路的正解，且已经工作。
3. 外层 nginx/WAF 会带 `X-Forwarded-Proto: https` 与 `X-Forwarded-Host`，
因此即使不配置也能推出正确链接；配 base_url 则是显式兜底。
## 新增设置项 base_url
三级优先解析「对外入口」（resolveEntry）：
1. **配置项 base_url** —— 外部入口是部署事实，不该靠请求猜。
经多层网关时请求可能带内网 Host，按它推导会拼出用户点不开的链接。
2. **X-Forwarded-Proto / X-Forwarded-Host** —— 反代层给权威信息时可靠。
3. **请求自身** —— 直连时的正确来源。
base_url 的主机名同时用作**子域反代的基域名**：入口是 homeagent.example.com
时，插件服务自然是 <标签>.homeagent.example.com。
服务清单另增 entry_url 字段，直接给出「外部入口是什么」，便于前端与排错。
## 生效点
- `/api/v1/proxy/services`：url / url_portal / base_domain / entry_url
- `/api/v1/device/gateway`：url / url_portal / http_url / host
- 两处原先各自推导 portalHost，现统一走 resolveEntry，避免再次漂移
## 部署后实测（生产，经真实外部入口）
entry_url: https://homeagent.jianfgit.xyz
base_domain: homeagent.jianfgit.xyz
remotedevice | https://devices.homeagent.jianfgit.xyz
| https://homeagent.jianfgit.xyz/api/v1/device/ ← 外部可点
huawei_smarthome| https://huawei-smarthome.homeagent.jianfgit.xyz
发现端点（外部视角）：
url_portal = wss://homeagent.jianfgit.xyz/api/v1/device/ws ← 外部可连
## 判据
+3 条：TestBaseURLOverridesRequestDerived（内网 Host 场景下必须用 base_url）、
TestEntryPrefersForwardedHeaders（XFF 优先于请求自身）、
TestBaseURLTolerant（尾斜杠/空格容错 —— 手填配置最常见的两种手误）。
另更新一条旧判据的期望值：外部入口是 portal.example.com 时，子域基名应取
**实际入口**而非本机配置的 localhost（后者对远程用户无意义）。
2026-09-26 13:49:59 +08:00
3604171431
fix(webui): 服务入口 URL 端口必须恰好出现一次（生产部署后暴露）
...
生产部署后立刻暴露的真 bug：请求 Host 自带端口（实测 Host=127.0.0.1:8080），
而 url_portal 合成时无条件再追加监听端口，拼出
http://127.0.0.1:8080:8080/api/v1/device/ ← 链接点不开
单测抓不到的原因：此前测试用的 Host 不含端口。真实服务器上 Host 一定带端口
（除非经 nginx 剥掉），所以这个 bug 必然出现在生产。
修法：抽出 portalHostWithPort(host, hostPort) 统一合成 ——
- host 已含端口 → 原样（尊重调用方看到的真实入口）
- host 不含端口 → 追加监听端口
两处调用点（服务清单 url_portal、发现端点 url_portal/url/http_url）共用它。
新增 3 条判据，都刻意用**自带端口**的 Host：
TestPortalHostPortExactlyOnce（7 组输入，含带/不带端口、空值、无冒号端口）
TestProxyServiceURLsWithPortInHost
TestDeviceGatewayDiscoveryNoDuplicatePort
2026-09-26 13:49:59 +08:00
17b010d070
fix(gui): 设备桥 bind 结果判 ok + 暴露登记状态，与鸿蒙端对齐
...
GUI 主进程与 Go 客户端同病： 只打日志、不看 ok。
服务端 bind 被拒时回 {"ok":false,"error":"bind rejected"} 并关闭连接，
GUI 既不报错也不重连 ⇒ 设备静默失联（TCP/WS 通但从未登记进网关）。
另：成功时服务端不含 device 字段，原日志用 `msg.device || deviceBridgeId`
兜底才显得像成功，掩盖了「从未真的读 ok」。
鸿蒙端 DeviceBridge.ets:209 本来就是正确实现（检查 ok、区分 connected
与 bound），本次把 GUI 与 Go 客户端对齐到同一语义：
新增 deviceBridgeBound / deviceBridgeBindError，bind 被拒打 error 级日志
并说明常见原因（令牌不匹配 / 设备未授权）。
2026-09-26 13:49:59 +08:00
a15d8d048c
fix(devicebridge): 修复设备反复掉线/静默失联 —— ping 路径断连 + bind 结果无人处理
...
用户要求全面修复「设备桥自动链接」这条链路上的问题。三个真实缺陷，
前两个是**服务端/客户端真 bug**（生产日志实证），第三个是我起初误判的。
## 缺陷 1（最严重）：未 bind 时收到 ping → 服务端直接关连接
原实现：
err := r.wsWriteLocked(curID, writePong)
if err != nil { return } // ← 关连接
而 conns 表**只在 bind 成功后才写入**（bind 前刻意不暴露连接给查询/命令
路径）。于是「握手完成、bind 尚未到达」这个窗口里来的 ping 找不到写入口，
函数返回错误，读循环 return —— 把连接关掉了。
生产后果（journalctl 实证）：客户端每 30s ping 一次，只要有一次落在未 bind
窗口就断连。日志里同一设备 20 秒内多次 "ws connected"，online/offline 与
输出通道注销/注册反复交替：
17:29:14 ws connected → 17:29:17 ws connected → 17:29:24 ws connected
→ 17:29:29 → 17:29:35 → 17:29:40 online → 17:30:18 offline → ...循环
修法：pong 直接写本连接的 writer。此时该连接尚未进入 conns（没有 Push* 会
碰它的 writer），不存在并发写风险；已 bind 时才取写锁（Push* 可能正在写
同一 buffer）。
判据 TestPingBeforeBindDoesNotDropConnection 直打 bug 点（只握手、不发
hello/bind、发 ping、要求 pong），修复前报 `EOF`，修复后通过。
## 缺陷 2：bind_ack 的 ok 完全没被检查 → 失败静默失联
原实现（客户端）：
case "hello_ack", "bind_ack":
log.Printf("... device=%v", msg["device"])
两处错：
- **取错字段**：服务端成功时回 {"op":"bind_ack","ok":true}，没有 device
字段，于是日志永远显示 `bind_ack device=<nil>`。这让我起初误判成"绑定
失败"，实际连接是好的（直连与经反代现象完全一致）。
- **不看 ok**：bind 被拒时服务端回 ok:false + error 并关闭连接，客户端既不
报错也不重连，设备静默失联 —— TCP/WS 通但从未登记进网关。
修法：分别处理两种 ack；bind 判 ok，失败记原因并通知宿主。新增
Bridge.Bound() / BindError() / OnBoundState()：**连接成功 ≠ 设备可用**，
只看连接状态的健康检查会给出假阳性。
判据 TestBindFailureIsObservable / TestBindStateCallback。
## 缺陷 3：-chat 一次性模式下桥存活时间过短
不是我最初以为的"bind 失败"。真因：`-chat` 走进 oneshot 后立刻 return，
触发 defer stopDeviceBridge()，桥只活几百毫秒，设备来不及完成 hello→bind。
修法：退出前等 bind 确认（最多 3s）；bind 明确被拒则打印原因，不静默丢弃。
## 真实验收（隔离实例，命名 netns + 独立 data + 18080）
真 waiter 经**反代自动发现**连接，保持连接期间查询服务端：
device gateway discovered: ws://127.0.0.1:18080/api/v1/device/ws
bind 成功，设备已登记
/api/v1/device/online → waiter-mainserver, online=true, caps=[11 项]
长连接稳定性：70 秒（跨 2 个 ping 周期）三次采样设备始终在线，
无 read loop exit / bind rejected 日志。
## 附：反代通路本身的判定性对照
裸客户端（直接构造 hello/bind 帧）**经反代**与**直连 9890** 返回逐字节
一致（bind_ack ok=true、设备注册、online=true）。所以这条链路上反代
不背锅，问题全在 remotedevice 服务端与客户端自身。
2026-09-26 13:49:59 +08:00
43938729af
feat(clients): 设备桥自动链接改用服务端发现 + 路径挂载（无 DNS 依赖）
...
配套 webui 反代改造：网关现在可由 HomeAgent 反代出去，客户端不能再靠
「门户地址同 host 拼 /api/v1/device/ws」猜地址——基域名与子域标签都是
**服务端配置**，客户端无从得知。
## 服务端：/api/v1/device/gateway 发现端点
客户端问「网关在哪」是唯一不会漂移的做法：子域标签可改（插件声明）、
基域名可改（webui.base_domain）、实例可换形态，客户端都不用跟着改。
⚠️ **不返回设备令牌**：本端点用门户凭证鉴权，而设备令牌能执行设备命令；
把令牌塞进来等于「门户只读凭证 → 设备执行权」的越权。令牌仍由客户端
自配。已有判据钉住「不得泄漏凭证字段」。
## ★ 实测发现：*.localhost 只有浏览器能解析
这是本轮最重要的发现，直接决定了设计：
| 环境 | devices.localhost 解析 |
|---|---|
| 浏览器 | ✓（RFC 6761 内置） |
| curl | ✓（内置特例） |
| getent / Go / Node | ✗（系统 nsswitch 是 files,dns，无 nss-myhostname） |
设备客户端（waiter / GUI 主进程 / 嵌入式固件）用的正是系统解析器。
实测 waiter 报「lookup devices.localhost on 192.168.2.1:53」。
因此**两处**设计变更：
1. 发现端点同时返回两种形态，并标 preferred：
- url（子域）—— 浏览器用
- url_portal（门户同源，同一 host、同一端口，走路径挂载）—— 非浏览器用，
无任何 DNS 依赖
2. SDK 的 ProxyDecl 新增 **Path**（路径挂载前缀）：让同一服务同时挂到
门户自身 host 的路径下。remotedevice 声明 Path="/api/v1/device"，
设备客户端因此能沿用**它已硬编码的路径**，不需要知道反代存在。
路径挂载语义：请求路径**原样保留**（不剥前缀），上游按真实路径注册即可。
边界卡在路径分隔符上（/api/v1/device 不匹配 /api/v1/devicefoo）。
## 客户端
- **waiter**：新增 discoverGateway()，仅在用户配了门户地址时尝试，失败回退
自配地址（老版本 HomeAgent 无该端点）。抽出 normalizeGateway() 纯函数，
显式钉住「已带子域/完整端点的地址不得被改写」。
- **GUI**：renderer 新增 loadDiscoveredGateway()，renderDeviceChannel 优先用
发现值、回退旧口径。顺带修掉此前插入函数时 anchor 不匹配导致调用点
找不到定义的问题。
- **鸿蒙**：discoverGateway() + resolveGatewayUrl()，优先 url_portal。
- 三者都**优先 url_portal**（system resolver 的现实约束）。
## 遗留路由鉴权修正
`/api/v1/device/` 的旧路径反代原被 requireAPI 包裹 —— 但其调用方是设备
（带设备令牌而非门户凭证），套上门户鉴权会把它们全挡在 401（**真实实测**：
waiter 经此路径升级握手 401）。去掉这层包装，鉴权交给上游 remotedevice
自己的 requireToken，安全性不降级。
## 判据
webui +6 条、waiter +7 条。
★ 其中一条是**真实回归**：/api/v1/device/gateway 曾被 Path="/api/v1/device"
的路径挂载接走（那服务 auth=none），于是发现请求被转给上游、回 401，
客户端再也发现不到网关。修法是发现端点先于路径挂载判定，并补判据
（走完整生产链，同时确认同前缀的真实设备路径仍归反代）。
## 真实验收（隔离实例，命名 netns + 独立 data + 18080）
真 waiter 客户端 + 真 remotedevice 网关：
device gateway discovered: ws://127.0.0.1:18080/api/v1/device/ws
device bridge active: waiter-mainserver authorized=true
hello_ack / bind_ack 均经反代往返成功
说明：`bind_ack device=<nil>` 与在线列表为空的现象，**直连 9890 绕开反代
完全一致复现**，属 remotedevice 与 waiter 之间既有的握手细节，与本次
反代改造无关（反代侧职责已证：连接建立 + 双向帧往返都通）。
2026-09-26 13:49:59 +08:00
3a860b9b05
fix(webui): 反代两处真实故障 —— 凭证头按 auth 区分 + Host 分发先于门户路由
...
两处都是**隔离实例上跑真实端到端**才暴露的，单测（用不校验凭证的假上游、
直接调 serveProxyHost）全绿却线上出错。记录在此以免重蹈。
## 故障 1：auth=none 路由的凭证被无条件剥掉 ⇒ 设备链路全 401
Rewrite 里原本无条件 Del("Cookie"/"Authorization"/"X-API-Key")。但
auth=none 的语义是"请求原样交给上游"，凭证本来就是给**上游**的——
remotedevice 的接入令牌正是走 X-API-Key 传的。
实测症状：带设备令牌经反代访问 /api/v1/device/online → 401；
直连 127.0.0.1:9890 → 200。差异极难定位，因为两侧状态码语义相同。
修法：按路由 auth 分流。
- auth=homeagent：凭证是门户的，剥掉（避免泄漏给插件）
- auth=none：保留（上游要用）
复验：经反代与直连**逐字节一致**（HTTP 200 / 17B，cmp 相同）。
## 故障 2：插件子域被门户路由截走 ⇒ 401 且响应体是门户的 JSON
原实现把 Host 分发放在 mux 的 "/" 兜底里。但 stdlib ServeMux 是**最长前缀
优先**：任何更具体的模式都先命中。插件子域上的 /api/v1/device/online 被门户
为「旧路径反代」注册的 /api/v1/device/ 接走（requireAPI 包裹）→ 401。
判据（响应体格式）是定位关键：
webui requireAPI → {"error":"unauthorized"} 25B ← 实际拿到
remotedevice requireToken → "unauthorized" text/plain 13B
看响应体格式就能区分是谁拒的，比看状态码有效。
修法：Host 分发提为**最外层中间件**，包在整个 mux 之外，先于任何路径匹配。
## 顺带：消除判据与生产接线错位的可能
新增 Handler.Handler() 返回生产用的完整链（Host 分发 → 日志 → mux），
plugin.go 与测试共用同一条。本次踩过：测试自己组装 mux、中间件却挂在
plugin.go，判据全绿而线上 401；共享同一条链可结构性避免。
（写这条判据时还发现测试里 h.mux 为 nil 导致 panic——也正是这种错位的表现。）
## 新增判据 2 条
- TestProxyCredentialHeadersDependOnAuth：auth=none 必须转发上游令牌、
auth=homeagent 必须剥掉门户凭证（两个方向都钉）
- TestProxyHostTakesPrecedenceOverPortalRoutes：走**完整生产链**，确认
插件子域上的 /api/v1/device/online、/api/v1/status、/api/v1/plugins/ 都
归反代；同时确认门户自身的 /api/v1/status 仍返回门户 JSON（没被反代吞掉）
## 真实验收（隔离实例：命名 netns + 独立 data + 端口 18080）
- 设备网关：令牌经反代 200，与直连逐字节一致；WS 升级 101
- 未声明子域：404 且错误信息含具体标签
- huawei_smarthome（用新 hmapdev 重打包、真装载）：
匿名 401 + 可操作提示；带门户 key 拿到真实 UI（9444B，
<title>华为智慧生活管家）；页面内根绝对路径 /api/status 正确透传
2026-09-26 13:49:59 +08:00
5467a9f256
feat(webui): 通用反向代理 —— 插件声明服务，HomeAgent 按子域反代出去
...
用户要求：外部只装 HomeAgent 即可使用自带反代能力；用户只需穿透一个
webui 端口就能访问所有内部插件服务；认证与 WebSocket 支持都作为插件
的可声明项；插件 UI 要有可直接点击的入口。
实测 huawei_smarthome 插件的前端用**根绝对路径**（api('/api/status') →
fetch('/api/status')）。挂在 /p/<name>/ 这类路径前缀下，这些请求会打到
HomeAgent 自己的 /api/status —— 静默错路由；做 HTML/JS 内容重写对拼进
JS 字符串的绝对路径只是"按概率能用"，会产生"页面能开、某个按钮就坏"的
静默故障。子域路由下根路径天然正确，**插件前端零改动**。
且它天然匹配"只穿透一个端口"：webui 监听 0.0.0.0:8080 按 Host 分发，
外层 frp 单端口 TCP 隧道**一行都不用改**。
默认基座 localhost：RFC 6761 规定 *.localhost 强制解析到 loopback，
现代浏览器原生支持 ⇒ <标签>.localhost:8080 **零配置可用**，不需要 DNS、
证书、/etc/hosts。远程部署改 base_domain 即可。
- 外部插件 → plugin.json 的 proxies（静态可发现：插件没起来也能报
"声明了 ui 但目标不可达"，而不是静默 404）
- 内置插件 → s.DeclareProxy()（remotedevice 是内置的、没有 plugin.json，
却最需要被反代出去）
反代层在 webui 侧读清单：webui 已能拿到插件目录（PluginManager.PluginDir），
因此**无需给内核接口加方法**。manifest 解析忽略未知字段，加 proxies 对
"旧内核读新插件"与"新内核读旧插件"都无害。
新增 sdk/ProxyDecl 与配套校验（ValidProxyAuth / ValidProxyHostLabel /
NormalizeProxyHost / ValidateProxyDecl）；新增运行期 ProxyDeclarer 通道。
hmapdev 的 writePluginJSON 是**白名单 map 重建**——不同步加字段会让声明
被打包静默丢弃（插件作者本地正常、装上去失效），因此 PlgConfig 与
writePluginJSON 同时加，并在打包前校验声明（插件作者本地就能发现写错）。
auth=homeagent（默认，安全的默认）：门户会话 / X-API-Key / ?__token=；
auth=none：信任上游自身鉴权，供设备与嵌入式客户端使用——它们不可能持有
浏览器会话，强制走门户鉴权会把设备链路挡死。remotedevice 声明 none，
因为它自身用 ws_token 强制校验。
未声明时升级请求**明确拒绝**（400 + 原因），而不是静默降级成普通请求
（后者表现为前端不断重连、日志看不出原因）。
1. 不跟随上游 3xx：旧实现用 http.DefaultClient（默认跟最多 10 跳），
上游 302 到内网地址时反代自己跟过去、失败回 502 并把内网 URL 泄给
客户端。httputil.ReverseProxy 默认不跟随，3xx 原样透传。
2. 逐帧 flush：旧实现 io.Copy 导致上游流式响应被缓冲到上游关闭才下发
（实测 3 帧 200ms 间隔的流，客户端在 +600ms 一次性收到全部）。
设 FlushInterval=-1。
另补齐 X-Forwarded-For/Host/Proto（旧实现完全不注入，上游无法判断真实
来源），并剥掉上游 Set-Cookie 的 Domain（防止插件 cookie 打到主门户域）。
插件页新增「服务入口」卡片：列出全部被反代的插件服务（含被拒条目与
不可达原因），点「打开」直接访问。链接带 ?__token=<api_key>，因为子域
与门户不同源、浏览器不会自动带会话 cookie。
webui +35 条、SDK +4 条、工具链 +4 条。关键几条：
- 根绝对路径必须原样到上游（选 Host 路由的核心理由）
- 上游 302 必须原样透传、且反代不得跟随（旧缺陷）
- 已知 Content-Length 的慢速响应必须逐帧到达（**这条经过变异验证**：
把 FlushInterval 改回 0 后判据挂死 → FAIL，还原后回绿。
说明：最初写的 SSE/chunked 版本是假判据——ReverseProxy 对
text/event-stream 与 ContentLength=-1 会自动立即 flush，与
FlushInterval 无关，变异抓不到，已改正）
- 子域标签冲突不得静默覆盖（后者保留可见并带原因）
- 非法声明不进路由但必须可见（配置页要能看到原因）
- 未声明 websocket 的升级请求必须 400
- auth 逐条生效：none 放行匿名、homeagent 与默认档 401 且给可操作提示
- 自动发现：显式 host 不得被自动编号覆盖（**测试抓到的真 bug**：
remotedevice 声明的 "devices" 会被改成 "devices-2" 而静默失效）
- 真实端到端：生产实例 huawei_smarthome 的 UI（9444 字节）与其
/api/status 经反代正确透传
go build ./... 通过；相关包全量测试通过。
internal/plugin/proc 的 TestStreaming_PublishLatencyFlatAcrossSubscribers
是**预存在的不稳定测试**（同一份代码 10 次跑 9 过 1 败，且本改动完全
未触及该包），非本次引入。
2026-09-26 13:49:59 +08:00
bcf99d0259
merge: 内核编解码层 C 化 + C 基础设施门禁（feature/c-core）
...
## 内容
- C 化第一刀 L1 纯函数层（ha_codec）：token 估算/截断/上下文窗口推断
- 零分配 JSON 扫描层 ha_json_scan（scan/extract 两段分离，黄金对照 + fuzz）
- SSE 协议导航层 ha_sse（**默认关闭**，见下）
- C 基础设施门禁六项（make check-csrc / check-csrc-full，已接进 make test）
- 共享内存与 IPC 的成本地板基准（纯测量）
- 分词器热路径分配优化（差分 oracle 验收）
## 实测（main 同机对照，50000 次迭代）
| 场景 | main | 本次 | 提升 |
|---|---|---|---|
| Truncate zh_1k | 6570ns / 2 allocs | 174ns / 0 | 37.8× |
| Truncate long_zh | 5984ns / 2 allocs | 179ns / 0 | 33.5× |
| Truncate ascii_1k | 1580ns / 2 allocs | 95ns / 0 | 16.6× |
| Estimate ascii_1k | 445ns | 51ns | 8.7× |
| Estimate zh_1k | 2262ns | 1172ns | 1.93× |
| Estimate short_zh | 22ns | 35ns | -58%（cgo 边界固定成本） |
几何平均 4.20× / 中位 1.93×；**变快 7 项、变慢 2 项**（短串受 cgo 边界拖累，
如实记录未掩盖）。调用点在热路径：process.go 对每个上下文事件都调
EstimateTokens，tooldefs.go 的工具定义裁剪调 TruncateByTokens。
## 默认关闭的部分（实测更慢，不当作成果）
- chunkFastEnabled = false：SSE 分块快速路径。首版更慢 52~79%；
返工（5+ 次 cgo 边界压成 1 次）后为「三项赢、一项输」，toolcall 仍慢 15%
⇒ 不打开。TestChunkFast_BenchGate 断言该开关必须为 false。
- ha_json_scan 未接生产路径：库已验完（119 契约断言 + 黄金对照 5 组 +
4948 万次 fuzz 零崩溃 + 6 万+ 差分用例），作为可复用底座留存。
## 为什么共享内存没有 C 化（附成本分解基准）
编解码占端到端 34%，但 **C 的甜区（字节搬运）仅占 0.2%~2%**
（1KB 拷贝 18ns、16KB 210ns；Go copy 已 44~71 GB/s），大头是 JSON 反射 34%。
另：段内读是**不可信偏移**（offset 由插件转述，伪造会破坏块链），
保留 Go 边界检查 / panic / -race / 模糊测试覆盖比省 0.2% 更值。
IPC 的真正地板是 OS 调度：cat 管道 echo 就要 16µs，占最简 RPC 的 62%。
## 验证
- 全量 go test -count=1 ./... 38 包 0 FAIL
- C 六门禁全过：gcc+clang 零告警（-Wconversion 必备）、ASan+UBSan、
arm64 交叉编译、头文件自包含、libFuzzer 零崩溃、ABI 版本自述
- 端到端启动实测：14 插件 / 63 工具 / kernel ready / 0 panic
- make build-linux-arm64 → ELF aarch64
- SDK 公开接口 diff = 0 行（csrc/ 是内核 C ABI，不属 SDK 冻结范围）
- git-release-discipline 体检 FAIL=0
## 纪律
- meta.Version 未被污染（未动 internal/meta）
- main 上无 merge 来自 release 分支（仅本 feature 合入）
- 本分支未部署任何生产环境
2026-09-26 13:32:36 +08:00
0efcf6c4db
fix(knowledge): 拒绝越出知识根的知识名（可致整个数据目录被删）
...
sanitize 只做小写/去空格/换下划线，**不过滤 ".."**，而 Remove 直接把
sanitize 的结果 filepath.Join 到知识根后 os.RemoveAll。
后果（实测）：
- Remove("..") → RemoveAll(<data>)，把整个数据目录连同 memory/
documents/media 一起删掉；且 os.RemoveAll 对已不存在的目标返回 nil，
调用方（含 knowledge_delete 工具）会回报"已删除"。
- Remove("../..") → RemoveAll(<data 的父目录>)。
- Add("../../x") → 内容写到知识根之外；重启后 scanAll 扫不到该目录，
条目既不在盘上正确位置也无法重建 ⇒ 幽灵条目（内存有、索引有、盘上没有）。
- Add(".hidden") → 写到隐藏目录，scanDir 明确跳过隐藏目录 ⇒ 同样的幽灵。
修复：
- 新增 checkSafeName：拒绝空段、"."、".."，以及以点开头的段。
Add 与 Remove 在拼接路径前都过它。
- 双保险：拼接后用 filepath.Clean 复核结果仍在知识根内，
防止 checkSafeName 将来被改宽而重新引入越界。
反向验证：临时拆掉这两处防护后重跑新测试，Add/Remove 对 .. 与隐藏名
全部"成功"，测试稳定变红；恢复后全绿。
影响范围：该缺陷存在于 release/v1.0.x ~ v1.3.x 四条发布线（各自的
internal/knowledge/knowledge.go 的 Remove 均为同一写法），本次修复需按
hotfix 纪律 cherry-pick 回流 main 并前向传播。
2026-09-26 13:11:08 +08:00
ff1c615b53
test(proc): 建立进程间通信的成本地板（判定「优化 IPC」的空间）
...
目标：回答「工具调用往返 30µs 里，非编解码的 ~20µs 花在哪、能否优化」。
方法：先立地板 —— 任何跨进程方案都有 OS 调度决定的下界。
三层对照（同机同会话，3000 次迭代）：
| 层 | ns/op | allocs |
|---|---:|---:|
| ① OS 调度地板（cat 子进程管道 echo，无协议无 JSON） | **16071** | 0 |
| ② 最简 RPC（无载荷、不经共享帧） | **25840** | 20 |
| ③ 纯编解码（共享段 write+read+compact，纯内存） | 10200 | 84 |
## 两条判据
1. **① 已占 ② 的 62%**：一个什么都不做的 echo（两次进程唤醒 +
两次管道读写）就要 16µs。⇒ RPC 层的成本主要是 **OS 调度**，
不是协议解析或 JSON 序列化。
2. **②−① 只剩约 10µs**：这才是协议层（JSON 帧 + pending map +
channel 握手）可优化的全部空间，且其中还包含一次真实的 JSON
编解码往返。⇒ 「优化 IPC」的理论上限约为端到端 30µs 的三分之一。
## 结论
跨进程数据面的**协议侧已接近其地板**。若要把端到端再压下去，
方向不是「优化协议」，而是**改变通信形态本身**：
· 批量调用（一次往返做多件事，摊薄固定调度成本）
· 或对高频小调用改走共享内存 + 自旋/事件通知（绕过两次进程唤醒）
两者都是架构级改动，不是参数调优。
★ 这也解释了此前几轮的困惑：为什么 C 化数据面收益总是很小 ——
因为真正的大头（OS 调度 16µs）与语言无关。
验证：基准可复现；internal/plugin/proc 全量测试绿。
2026-09-26 13:06:10 +08:00
15e5e87fbf
perf(chineseclip): 分词器热路径分配优化 + 差分 oracle 验收（含一处真实语义修复）
...
嵌入式模型推理（ONNX）本身已是 C++，**可优化的 Go 侧是分词器与预处理**。
本轮先测出成本分布，再改，且**不假设 C 更快**。
## 实测（合成词表，无需 CHINESECLIP_MODEL_DIR）
| 场景 | ns/op | allocs |
|---|---:|---:|
| short_zh | 25681 | 60 |
| short_en | 19100 | 43 |
| mid_en | 117343 | 451 |
| mid_zh | 189260 | 1047 |
| punct_heavy | 283265 | 1388 |
| long_zh | 757746 | 4233 |
## pprof 指出的分配源（alloc_objects，mid_zh）
- splitOnPunctuation **33.5%**（每 token 都做 []rune + string(cur)）
- wordpiece **32.3%**（内层每轮候选都 string(runes[a:b])，多数未命中）
- stripAccents/NFD 33.6% cum
- basicTokenize 自身只 1.4%
## 改了三处
1. `basicTokenize`：`len([]rune(token))` → `utf8.RuneCountInString`
（原为「数个长度」就把整个 token 转 rune 切片）
2. `splitOnPunctuation`：去掉整串 []rune，改逐 rune 扫描 + 一次 flush
3. `wordpiece`：预建 rune 边界表，按字节区间取 substring，
消除「每轮候选都构造 string」
## ★★ 差分 oracle 抓到一处**真实语义缺陷**（非测量噪声）
本机无模型产物，权威的 TestTokenizerMatchesOfficialReference 会 **SKIP**
⇒ 仅靠现有测试，我的重写**没有被有效验证**。故把改动前的实现原样内联为
oracle 做差分（split/wordpiece/basicTokenize/Encode 四组 + 随机字节 2 万组
+ 随机 rune 5000 组）。
它立刻抓到：`"\xbc\xef=..."` 旧实现得 `["��" ...]`，新实现得 `["\xbc\xef" ...]`。
根因是 `[]rune(s)` 会把**非法字节归一成 U+FFFD**，而纯字节切片原样保留坏字节。
⇒ 真实差异（会进日志/去重/hash），已改为对非法序列写回 RuneError，与旧行为逐值一致。
## 诚实的收益结论：**基本没有**
改动后：mid_zh 189260（改前 186777）、long_zh 757746（改前 786416）、
mid_en 117343（改前 120422）。分配数 mid_en -40%、其余基本持平，
**时间无实质改善**（部分场景还略慢）。
复查原因（不掩盖）：重新做 CPU profile 后发现 **~25% 的样本是
runtime 锁/抢占**（unlock2 8.1% + lock2 6.8% + procyieldAsm 6.8% +
asyncPreempt 5.4%），而 utf8/unicode 相关不足 20%。
且 GOMAXPROCS 敏感：1→375365ns、4→209922ns、12→189543ns
⇒ **大量时间花在调度与 GC 而非分词算术**。
⇒ 结论：Go 侧微优化这条路**已到头**。真正的杠杆在别处：
① 提高 GOMAXPROCS/减少 GC 压力 ② 批量分词（降低每条输入的固定开销）
③ 减少送入模型的 token 量。三者都不是 C 能解决的。
改动本身保留（正确性等价、有 oracle 守护），但**不应据此宣称性能收益**。
与 C 化那几刀同一条纪律：没有数据支撑的优化不算优化。
验证：差分 oracle 6 组全过（含非法 UTF-8）；providers/... 全绿。
2026-09-26 11:44:49 +08:00
4ead049a52
test(proc): 共享内存数据面成本分解基准（纯测量，判断 C 化是否值得）
...
针对「共享内存应由 C 实现」这个直觉做量化。结论：**收益判据不成立**。
基准拆出三类成本，只有分开测才知道哪类是 C 的甜区。
## 实测（small：2 toolResults + 2 ctxMsgs）
| 项 | ns/op | allocs | 占比 |
|---|---:|---:|---:|
| ③ 描述符记账（18 个 Slice） | **51** | 0 | **0.4%** |
| ① 段内字节搬运 1KB | **18** | 0 | **0.2%** |
| ① 段内字节搬运 16KB | **210** | 0 | **2%** |
| ② JSON (Marshal+Unmarshal) | **3900** | 15 | **34%** |
| 整体 write+read+compact | 10376 | 84 | 100% |
字节拷贝 1KB=18ns / 16KB=210ns（3 次重复，稳定在 ±5%）：
Go 的 copy 已达 **44~71 GB/s**，接近内存带宽上限，**无余量可榨**。
## ★ 更正一处我自己的错误口径
我先前报「编解码只占端到端 9%」——**那是单次非成对采样，是错的**。
成对重测（各 3 次取中位）：
| | ns/op |
|---|---:|
| 工具调用往返（inline/small，跨进程） | 30305 |
| 纯编解码（small） | 10376 |
| **占比** | **34%** |
即编解码其实是**端到端的三分之一**，比 9% 重要得多。
但结论**不变**，且理由换成更有力的两条：
1. **C 的甜区恰好是最小的那块**：字节搬运仅占 0.2%~2%。
真正的大头是 **JSON 反射占 34%**、描述符记账 51ns 占 0.4%。
2. **JSON 恰是本轮三刀反复验证「跨语言重建语义不划算」的领域**。
顺带记：这轮我又被自己的**测量方式**坑两次 ——
① 基准脚本用 `CLOCK_MONOTONIC` 却只取 `tv_nsec`（漏 `tv_sec`），
算出 -4201ns 负值；② 用 `grep 'ns/op'` 批量取数时，
把 `JsonOnly/empty`（0.4ns）误当成 `small`（3310ns）读了进来。
⇒ 拿荒谬数值先怀疑工具；批量取数要确认匹配到的是**哪一行**。
## 三条判据
1. 大头是 JSON 反射（34% 时间、15 分配），不是内存带宽。
2. C 的甜区（memcpy 类）只占 0.2%~2%，无榨取空间。
3. 段内读是**不可信偏移**（arena.go 注释自述 offset 由插件转述，
伪造会破坏块链；payload 可达 MB 级）—— Go 的边界检查 + panic +
`-race` + 模糊测试覆盖它；C 越界是静默堆破坏。
## 另一条架构判据
格式常量在两仓各写一份（内核 `shm.go` 与 SDK `proc_main.go.tmpl`
各有 `shmStageFieldCount=18`/`sliceSize=8`/`offMagic`）。
C 化一旦动 ABI 须走 SDK 发版 + 两仓版本对齐（MIT vs AGPL），
否则「新内核 + 旧插件」静默错位。本文件只是基准，不涉及 ABI 变更。
## 「C 是共享内存原生语言」在本项目为何不成立
1. **插件侧根本不用指针**：SDK 模板只做 `syscall.Mmap` 拿 `[]byte`，
全程相对偏移 `{off,len}`、零指针重解释、零 unsafe。
跨进程 mmap 到不同虚拟地址 —— 这正是必须用偏移的原因，
C 的指针模型在这里用不上。
2. **真正原生的部分是 Go 更强的地方**：memfd 惰性物理内存
（未触碰页不占物理内存，MB 级 arena 近零常驻）+ first-fit +
邻块合并 + owner 校验；OS 语义 cgo 一样要调。
3. C 化还会破坏「整个新架构零 cgo」这条已达成的不变量。
验证：go test -benchtime 全绿，无回归。
2026-09-26 11:22:55 +08:00
7ae92e62aa
chore(api): 删除批量定位改造后遗留的 6 个未使用函数
...
首版逐字段设计（findKey/firstElem/scanArray/decBuf 路径等）在批量定位
改造后已完全被取代，保留它们会让人误以为这些路径仍在生效。
删除：findKey / firstElem / scanArray / locateChunkBatchInto /
sseABIVersion / argStringC。
保留 C_size（rootSpan 在用）与 stringifyC（文本数组路径在用）。
go vet 与 go test 均不报未使用的包级函数，故用调用点计数核验
（每个符号的非定义调用数均为 0）。build + 全量 api 测试绿。
2026-09-26 10:44:18 +08:00
8b376941cb
perf(api): SSE 导航层返工 —— 5+ 次边界压成 1 次（三项赢，仍默认关闭）
...
按 sse-codec-c.md §6.4 的架构改造方向返工。**部分成功**：从「五项全输」
变成「三项赢 / 一项持平 / 一项输」，且所有场景分配数都下降。
## 改造内容
| 项 | 前 | 后 |
|---|---|---|
| cgo 边界次数 | 5+（每字段一次 findKey） | 1（ha_sse_chunk_locate） |
| 键查找 | 每键各扫一遍对象（6 趟） | 单趟分派（遍历成员表一次即分发） |
| 解码 | 每字段一次往返 + 各自 decBuf | 同一趟内写进一块 sbuf（1 次分配） |
| 成员表遍历 | 6 趟 | 2 趟（顶层 + delta） |
顺带修掉两处自造的浪费（都是「先扫一遍拿个数、再扫第二遍拿首元素」）：
choices 数组的「数个数 + 取首元素」合一趟；choice0 内的 delta/finish_reason
合一趟。成员遍历实测 107ns/趟，省一趟就是省 107ns。
新增 ha_sse_chunk_locate：一次调用完成根校验 + 顶层分派 + choices[0] +
delta 分派 + content/reasoning/finish 解码，输出写调用方持有的 C 结构体
（C 结构体无 Go 指针 ⇒ 可安全传指针，消除 out-param 逃逸）。
choices_count>1 时直接回退（Go 侧 Unmarshal 会解析全部元素，本层只认 [0]，
其余元素可能类型不符而让 Go 整块作废 ⇒ 无法保证等价）。
## 实测（50000 次 × 3 轮取中位）
| 场景 | Entry | GoOnly | 判定 |
|---|---|---|---|
| content_zh | 1540ns / 5allocs | 1871ns / 13allocs | 快 18%，分配 -62% |
| content_ascii | 1250ns / 5allocs | 1304ns / 13allocs | 持平，分配 -62% |
| finish | 820ns / 6allocs | 921ns / 12allocs | 快 11% |
| usage | 2530ns / 9allocs | 2591ns / 12allocs | 持平偏快 |
| toolcall | 3450ns / 20allocs | 3000ns / 21allocs | 慢 15% |
## toolcall 仍输的根因（已定位，非猜测）
分解测量：C 侧纯 C 零边界 = 766ns；Go 侧 []openAIToolCall unmarshal =
1305ns/15allocs；对照 Go 整块 unmarshal ≈ 2980ns。
问题在第二行：tool_calls 元素是对象，Arguments interface{} 需要真实的
map[string]interface{}，必须走 encoding/json 的反射建树。
而为了定位已先做了一遍 C 扫描 ⇒ 同一份数据被解析了两次。
⇒ 不是 C 慢，是「扫两遍 vs 扫一遍」。
标量字段（content/reasoning/finish）C 能一次到位 ⇒ 那些场景赢；
需要建树的字段（tool_calls/usage）C 的定位是纯开销。
## 为什么仍默认关闭（理由充分，不是保守）
1. toolcall 是真实负载最常见的一类块（任何一次工具调用流），仍慢 15%
2. 18% 收益不足以抵消「与 encoding/json 语义并存的第二实现」的风险
3. 本刀原始动机在 toolcall 场景没有兑现：分配数 20 vs 21 几乎没降
⇒ 前提是先做「按字段类型决定是否 C 化」，让 toolcall 也不输，再重测。
## 正确性
6 万+ 差分用例（协议形态/真实负载/随机 JSON 3 万/随机字节 3 万）全过。
基准测量也修了：先前 C 基准脚本用 CLOCK_MONOTONIC 却只取 tv_nsec，
算出 -4201ns 的负值 —— 测量工具本身出错会直接毁掉结论。
## 验证
ASan+UBSan PASS；gcc+clang 零告警；arm64 交叉 0 告警；
libFuzzer 66 万次零崩溃；全量 go test 38 包 ok / 0 FAIL
2026-09-26 10:41:52 +08:00
bf8a01fb67
perf(api): SSE 分块 C 导航层 + 差分等价验收（实测更慢 ⇒ 默认关闭）
...
第三刀：把 ha_json_scan 接进 parseOpenAICompatibleStreamChunkFull。
**结论是否定的** —— 实测比原实现慢，故默认关闭并如实记录。这条提交的
价值在于「已钉死的正确性 + 已定位的根因 + 一条防静默回退的断言」。
## 设计：只做「结构导航」，序列化留在 Go
接线前实测出两条 wire 语义，它们让「整条解析全 C 化」不成立：
§5.1 重复键是**字段级合并**，不是替换：
{"choices":[{content:a}],"choices":[{reasoning:r}]} → 两个都保留。
机制：json.Unmarshal 的 object() 收尾做 v.SetIndex(i, subv.v)，
而 subv 拿到的是**已存在元素的指针** ⇒ 第二次是叠加。
§5.2 stringifyContent 的 default 分支 = json.Marshal(interface{})，
即**重新序列化**：{"b":1,"a":2}→{"a":2,"b":1}（键排序）、
1e2→100、<→\u003c、大 int 先舍入成 float64。
逐值一致 = 复刻 Ryu 最短浮点 + map 键排序 + HTML 转义 + int 舍入。
两条都只在**取值**阶段需要，故 C 只回答「值在哪里」（零分配零解码），
类型检查靠「用相同的 Go 类型 unmarshal 相同形状的子树」保证，不靠 C 复刻规则。
## 实测：新路径比原实现慢（20000 次迭代）
| 场景 | 新路径 | 原实现 |
|---|---|---|
| content_ascii | 2016ns / 20allocs | 1325ns / 13allocs |
| toolcall | 5854ns / 33allocs | 3270ns / 21allocs |
| usage | 3170ns / 24allocs | 2832ns / 12allocs |
分配数**也变多**（20 vs 13），与「消除 GC 抖动」的初衷相反。
根因（逐项测量，非猜测）：裸 cgo 调用 168ns；**每次带 out-param 的键查找
205ns + 2 allocs**（out-param 逃逸到堆）；一次解析需要 5+ 次查找
⇒ 边界与分配成本约 1µs，恰好吃掉全部收益。Go 侧只需**一次** Unmarshal。
一句话：**用很多次廉价调用换一次昂贵调用，在这个尺寸上不划算。**
## 天花板实验：方向对，但当前实现没到
假设拿到 span 完全免费，只测设计中必须由 Go 做的部分：
我的 Go 侧 505ns/7allocs vs 原实现 1239ns/13allocs
⇒ 边界归零后仍有 2.4× 时间、46% 分配的空间。故问题在**逐字段往返**
这个交互方式，不在 C 本身。正确改造：一次调用返回全部字段 span +
结果写调用方栈结构体 + 仅在确需重新编码时回退。
## 正确性：6 万+ 差分用例全过
同一批输入跑两条路径逐字段比对（Content/Reasoning/Done/Finish/ToolCalls/
Usage + bool），5 组：协议形态（含全部回退触发条件）、真实负载、随机 JSON
30000 例、随机字节 30000 例、优化有效性。
★ 差分测试当场抓出 4 个真实缺陷（其中一个正是「优化压根没生效」）：
1. ha_sse_arr_first 里「重新 init 到 sc.s+sc.i」使 base 变了 ⇒ start 恒 0
⇒ 返回的是**数组本身**而非首元素。症状是**快速路径永远不生效**——
而若只看「结果与 Go 一致」，这个 bug 会**完全隐形**（回退总是对的）。
⇒ 这就是必须单独断言「优化确实被走到」的原因。
2. chunkAssemble 的 bool 被丢弃 ⇒ 空对象被判 true（原实现 false）
3. 键匹配层级搞错：delta 是 **struct**（字段名 CI），不是 map。
我一度「推理」成 CS 并以为差分测试会通过——错的。
教教训：哪层是 struct、哪层是 map 要**回原实现读类型**，不能凭字段名推断。
4. cgo 边界：out-param 逃逸到堆
另修：C 代码从 cgo 前言移进 csrc/ ——前言里的 C **逃出全部 C 门禁**
（告警/sanitizer/交叉/模糊测试），而它恰是本刀最易出错处。
## 防静默回退
TestChunkFast_BenchGate 断言 chunkFastEnabled 必须为 false。
后来者看到「快速路径写得全 + 差分测试全过」，很自然会以为它已生效并打开它
—— 而实测更慢。断言把这个事实钉住，改动即判红。
## 实测汇总
- C 契约 119 项断言、黄金对照 5 组、差分 6 万+ 例：全过
- ASan+UBSan PASS；gcc+clang 零告警；arm64 交叉 0 告警（3 个源文件）
- 全量 go test -count=1 ./... 38 包 ok / 0 FAIL
- libFuzzer 4948 万次零崩溃（上一刀）
教训（与第一刀同源）：**「C 比 Go 快」不是前提，是待验证的假设。**
第一刀被 C.CString 的 82% 自找开销推翻一次，这一刀被逐字段往返推翻一次。
两次都是测量推翻直觉。
2026-09-26 10:32:20 +08:00
2b78a9288e
feat(csrc): 第二刀 —— 零分配 JSON 扫描/取值层 ha_json_scan（含黄金对照）
...
C 化第二刀：为协议编解码层铺 JSON 底座。**本刀只交付库 + 验收，
未改 Go 生产路径**（接线是独立一步，库先验完再换产线）。
为什么是它：SSE 单块解析（parseOpenAICompatibleStreamChunkFull）是每个流式
chunk 都要跑的最热路径，实测 1937ns/13allocs（content 块）、3122ns/21allocs
（toolcall 块），而纯字节扫描理论下限 133ns/1alloc —— 差距 15~23×。
一次 1 万块的会话 = 1~2 万次堆分配，正是 GC 抖动的来源。
为什么不复用 SDK 的 remotedevice/ha_json.c（实测三缺陷，不可直接复用）：
① 无 \u 解码：\u4f60\u597d → ?0?d?d?0（非 ASCII 全靠转义时内容直接损坏）
② 只有 _get_int 无浮点：temperature:0.7 静默变 0
③ null 与「键缺失」不可区分
外加它是 DOM + malloc，与本层「不 malloc / 零拷贝 / 纯函数」正交。
设计：scan（结构，零分配零解码）+ extract（取值，按需解码）两段分离。
content 可能是很大的多模态数组，而 stringifyContent 只需要 text 字段拼起来；
若 scan 就解码并分配缓冲，等于把成本付给不需要它的调用方。
★ 被测试抓出 7 个真实缺陷（写 C 时同一逻辑我读三遍都认为正确）：
1 代理对合成成功后未跳过 unconditionally 的 U+FFFD 发射（😀 → 两个 FFFD）
2 过长编码检查用了只含首字节位的 cp（「你」→ 6 个 FFFD）
3 members_next 只报值起点不消费值 → 游标停在值前（模糊测试第一轮抓到）
4 扫描阶段不校验转义字符合法性（{"a":"\q"} C 判合法、json.Valid=false）
5 扫描阶段不校验 \u 后四位十六进制（同上）
6 get_int 接受前导零（007 / 00）
7 cgo 桥接把 C 结构体声明为 Go 局部变量 → 运行时 panic
（cgo argument has Go pointer to unpinned Go pointer）
其中 4 个是「静默分叉」——不崩、不报错，生产里表现为「内容少一个字符」
或「某些块被静默丢弃」，极难归因。这正是黄金对照不可省的理由。
★ 另纠正我自己两次错误的「真值」（比代码 bug 更危险，会变成错误规格）：
第一版真值表里 content:{} 的花括号少了一层，把「我写错 JSON」误读成
「Go 对 content 严格」。修正后实测发现一对方向相反的语义：
content 走 interface{} 宽松（{}→"{}"、true→"true"），
reasoning_content/usage/finish_reason 强类型严格（123 ⇒ 整块作废）。
照错误表写 C 会产出「比 Go 更严格」的实现，静默丢弃本该生效的块。
两个由缺陷倒逼的设计决定：
- members_next 返回**完整值 span** 并内部跳过 ⇒ 「返回 1」蕴含「成员良构」。
要求调用方自己推进游标的 API 是错的：忘一次就解析到上一个值且不报错。
- members_complete() 区分「正常扫到 }」与「输入畸形」，否则无法复刻 Go 严格性。
同时修两个基础设施目标对「多源文件/多测试」的适配：
- csrc-sanitize：每个契约测试各自链接（多个 main 合链会 multiple definition，
而报错被吞后会被误报成「本机无 sanitizer」——一个假的 SKIP）
- csrc-cross：多源文件改用 -fsyntax-only 逐文件（gcc 不支持多源单 -o）
实测（全部当场可复现）：
- C 契约测试 119 项断言全过；黄金对照 5 组全过（语法/成员/解码/整数/随机字节）
- libFuzzer 4948 万次运行零崩溃（121s）
- ASan+UBSan PASS（两个契约测试各跑）；gcc+clang 零告警；arm64 交叉编译 0 告警
- 全量 go test -count=1 ./... 0 FAIL；make build-linux-arm64 → ELF aarch64
- 纪律检查 SDK 公开接口 diff = 0 行（未触碰 SDK）
决策关闭（jianf 本轮裁决）：C 实现留主仓 csrc/（它本就是替换内核 Go 实现，
SDK 从未被触碰，跨端复用才需进 SDK 而它们不调用本层）；ha_json.c 不复用；
下一刀即协议编解码层。
2026-09-26 10:07:27 +08:00
f877dff95f
docs(plan): 记录 C 基础设施门禁落地 + 下一刀决定 + ha_json.c 不可复用的实测证据
...
- §七 新增「C 基础设施门禁」小节（六个门禁 + 地基上线抓出的 5 个自身 bug）
- 记录首次把「C 函数体成本」与「cgo 边界成本」分开测出的基准表
- 下一刀定为协议编解码层，附 SSE 单块解析实测（1937/3122/2464ns vs 133ns 下限）
- ★ 推翻旧判断：SDK ha_json.c 有三个致命语义缺陷（\u 不解码 / 无浮点 / null 不可区分），
且 DOM+malloc 与设计约束正交 ⇒ 建议 csrc/ 新建零分配 ha_jsonscan.c，不建议内核热路径依赖别仓
待 jianf 拍板三项仍未决，未擅自开工。
2026-09-26 09:45:49 +08:00
d7df1dd1c9
build(csrc): C 基础设施门禁（ABI 版本 / 告警 / sanitizer / 交叉编译 / 模糊测试）
...
C 化从「一把刀」推进到「可持续推进」，本轮先把基础设施建起来：
不建它，后续每个 C 切片都在裸奔（无告警门禁、无内存安全检查、
无交叉编译验证、无 ABI 漂移检测）。
新增门禁（make check-csrc / check-csrc-full，已接进 make test）：
- csrc-lint gcc+clang 双编译器 × -Wall -Wextra -Wpedantic -Wshadow
-Wconversion，零告警才算过（-Wconversion 是为 cgo 窄化
准备的：size_t→int 截断在默认档下是静默的）
- csrc-abi ABI 版本运行期自述 + 荒谬值检查
- csrc-headers 头文件自包含性（每个 .h 能单独编过）
- csrc-sanitize ASan+UBSan 跑 C 契约测试
- csrc-cross arm64 交叉编译（homed 的真实发布目标）
- csrc-fuzz libFuzzer：内存安全 + 6 条不变式（可 CI 门禁）
新增 ABI 契约（csrc/include/ha_abi.h）：
- ha_codec.h 声明「签名冻结」，但冻结只写在注释里；现改为
HA_CODEC_ABI_MAJOR/MINOR + 运行期自述 + Go 侧常量，
三方交叉断言，版本漂移在测试期判红而非线上表现为行为诡异。
- 门禁当场抓出我自己的两个真 bug：①_Static_assert 是 C11 而项目
是 -std=c99（-Wpedantic 报的）；②##msg 不能拼接字符串字面量，
导致两个断言共用一个 typedef 名（clang 报的）。
基础设施当场抓出的三个真实缺陷（都是「本机 gcc 能编过、别处会炸」类）：
- bench 用了 POSIX clock_gettime，而 CMake 刻意 C_EXTENSIONS OFF
（严格 c99）→ 头文件未声明；补 _POSIX_C_SOURCE（须在任何头之前）
- 头文件缺 include 时只在「恰好被别的头先包含」处静默编过
- Go 不允许在 _test.go 用 cgo ⇒ C 侧 const 桥接只能放非测试文件，
且 cgo 生成的 *_Cvar_* 不是 Go 常量（「两边一起错成一样」的盲区，
改用 C 函数返回 + 编译期 _Static_assert 补上）
实测（全部当场可复现）：
- 双编译器 × c99/c11 零告警；ASan+UBSan PASS
- libFuzzer 91s 跑 3329316 次、零崩溃（6 条不变式全过）
- 变异测试：改 C 侧宏 / 让 Go 常量与 C 函数「一起错成一样」，
均被对应断言抓住（证明门禁不是摆设）
- C 侧纯函数基准（首次把函数体成本与 cgo 边界成本分开测）：
ascii_1k 121.7ns/8.4GB/s；zh_1k 1434ns；truncate 两者均约 128-134ns
- 全量 go test -count=1 ./...：57 包 0 FAIL
- make build-linux-arm64 → ELF aarch64
- 纪律检查 FAIL=0；SDK 公开接口 diff = 0 行
未动：csrc/ 是内核 C ABI，不属 third_party/homeagent-sdk 公开接口。
2026-09-26 09:44:17 +08:00
95a52bc1b3
docs(plan): 两条端口/限流 flaky 已修（4dcbdb1），标记关闭
2026-09-25 17:57:26 +08:00
4dcbdb1269
fix(plugins): 修三处端口/监听缺陷 + 让测试用临时端口（消除既有 flaky）
...
排查内核 SIGSEGV 时用 A/B 对照（我的树 20 轮 vs 干净树 20 轮）确认了
两条**既有** flaky，与 C 化改动无关。本提交把它们修掉。
## 缺陷 ①（真 bug，不只是测试卫生）：pluginmgr 监听地址是包级可变全局
`var HTTPAddr = "127.0.0.1:9876"` 是包级可变全局，`Start()` 还把 settings 读到的值
**反写**回它，`startHTTPServer` 再读它。后果：
- 多实例互相污染：后启动的实例把地址写进全局，先启动那个读到的是**别人的**地址
（实测与生产 homed 抢 9876）
- 全局读写无同步，属数据竞态
修法：改为实例字段 `p.httpAddr`（默认走 `const defaultHTTPAddr`），
不再有可被任意代码改写的包级状态；并新增 `HTTPURL()` 访问器。
## 缺陷 ②：remotedevice 用 ListenAndServe，监听失败静默且 :0 无法回报端口
`p.server = &http.Server{Addr: p.addr}` + `ListenAndServe()` 在后台 goroutine 里报错，
端口被占时只打一行日志、`Start()` 仍返回 nil —— 插件表面「已加载」而网关根本没跑。
且 `:0` 下拿不到真实端口。
修法：改为 `net.Listen` + `Serve`（与 webui/pluginmgr 同形）：
- 监听失败**同步**返回，交给加载器
- 用**实际绑定**地址回写 p.addr，日志与诊断面显示真实端口
## 测试侧：全部改用 :0，不再抢固定端口
新增 `ConfigRegistry.SetPluginConfig(name, key, value)`：插件表原本只在
`RegisterDef`（插件 Start 时）创建，导致「想在插件加载前预置配置」无从下手
（直接 Set 会因表不存在而失败，错误常被忽略）。新方法先建表再写，填补该时序缺口。
`setupIntegration` 在 `Load()` 前预置：
- pluginmgr.http_addr / remotedevice.listen_addr → `127.0.0.1:0`
- webui 走已有的 `SetListenOverride("127.0.0.1:0")`（它有独立旁路）
实测三个插件现在各自绑到 OS 分配的空闲端口（41895 / 35855 / 34021）。
## 缺陷 ③：deepsearch 测试把「上游限流」当成功能回归
`TestRealPlugin_DeepSearchInvoke` 的断言会在上游限流时失败，但插件此时返回的是
**正常结果**（err==nil，content 含 "未返回结果" 与无响应引擎列表）——那是外部条件。
实测失败信息：`brave(Suspended: too many requests), duckduckgo(CAPTCHA), google cse(...)`。
更糟的是它**不可控地随机红**：干净树连跑 20 轮复现 2 次，与代码改动无关。
这种判据会让真正的回归淹没在噪声里。
修法：区分「上游不可用（限流/CAPTCHA）⇒ t.Skip 并说明理由」与
「其他异常 ⇒ fail」。不用静默 return，避免环境退化时判据无声失效。
## 由此发现并修掉的真缺陷：监听地址被硬编码在三处
`127.0.0.1:9876` 曾硬编码在 pluginmgr / cli / webui 各一份。cli 与 webui 后来改为
运行时读 `pluginmgr.http_addr` 设置（本次核实），pluginmgr 自己却仍是全局 —— 三处
口径现在统一为「读设置 + 实例字段」。
## 验证
- 新增 `TestTwoInstances_ListenIndependently`（pluginmgr）：两个实例同时监听、
各自 HTTPURL 指向自己端口、两个地址都真的可连。
★ 经**忠实变异**验证有牙：复原「包级全局 + Start 反写 + 读全局」后该测试判红
（我第一版测试只断言字段不共享，变异证明它没牙，已重写为端到端判据）。
- `internal/plugins` 连跑 **30 轮：30/30 全过**（修复前干净树 18/20）。
- 全量连跑 3 轮：38 ok / 0 FAIL / 0 bind 冲突。
- go build ./... / go vet ./... 干净。
2026-09-25 17:57:15 +08:00
35aeb6f88b
docs(plan): 修掉重复块 + 补两条既有 flaky 的实测归属
...
## 修掉我引入的结构错误
plan.md 此前有**两套 §三~§七**（第 468 行起是第 265-410 行的完整副本），
是我早前替换 §七 时遗留的旧版本。现合并为一套：保留新版 §七
（含优化后基准与「完全 C 化」裁定），吸收旧版里仍有价值的
「已定事项（不再挂账）」小节，删掉过时内容：
- 旧的「C 比 Go 慢」基准表（该结论已被推翻）
- 旧的「按长度分派（短走 Go）」建议（已被 jianf 裁定否决）
行数 685 → 498，`grep '^## '` 不再有重复章节。
## 补两条既有 flaky 的实测归属（排查 SIGSEGV 时顺带确认）
用「我的树 20 轮 vs 干净树 20 轮」A/B 对照确认两者**均与 C 化改动无关**：
1. **测试间固定端口冲突**：pluginmgr `9876`（且是包级可变全局 `var HTTPAddr`）、
remotedevice `9890`、webui `8080`。干净树同样复现 2/20 失败
（`bind: address already in use` + `signal: terminated`）。
2. **TestRealPlugin_DeepSearchInvoke 依赖外部 SearXNG**（`127.0.0.1:8888`）：
上游限流时必红（实测报错 `brave(Suspended: too many requests)`、
`duckduckgo(CAPTCHA)`）。干净树同样复现 2/20。
两条都建议改用 `:0` 或区分「服务不可达（skip）/ 真回归（fail）」，
但不属本次「排查崩溃」范围，记入待办。
2026-09-25 17:27:55 +08:00
8f52bfc10b
fix(proc): 修 arena use-after-unmap 导致的内核 SIGSEGV（关停竞态）
...
## 症状
全量 go test 偶发 SIGSEGV，整个测试二进制被杀（recover 捕不到 runtime
致命错误）。崩溃栈（2026-09-25 实测捕获，完整）：
readLoop (process.go:334)
→ markExited → once.Do
→ onExit → Plugin.handleExit (plugin.go:209)
→ Host.ReclaimOwner (host.go:342)
→ arenaRegion.ReclaimOwner → blockBase → getU32
→ SIGSEGV 读已 munmap 的内存
## 根因（两个叠加缺陷，同一后果）
**① markExited 里 close(exited) 早于 onExit**
close(p.exited) // :394 —— 先关闭，唤醒所有等待者
p.sup.untrack(p.name)
p.onExit(...) // :399 —— 回调里要读共享内存
onExit（内核侧 Plugin.handleExit）会调 Host.ReclaimOwner 回收该插件残留的
共享槽，那是要读共享内存区域的。而 exited 一关闭，Stop()/Kill() 就返回
（process.go:566/587），StopAll 随即返回，调用方（Host.Close）立刻
freeShm 解除映射 —— 此刻 onExit 还没跑完，ReclaimOwner 就成了读已 munmap
的内存。
修法：把 onExit 提到 close(p.exited) **之前**，并明确 exited 的语义是
「**完全**收尾完毕」而非「进程已死」——任何等待者看到它关闭后，都可安全
释放共享内存、卸载资源。
**② StopAll 超时分支 `go p.Kill()` 发射后不管**
go p.Kill() // 不等待
本函数返回后调用方就 unmap，而 Kill 内部要等 markExited 跑完（含 onExit）。
改为等全部 Kill 完成（Kill 自带 killReapTimeout 上限，不会无限拖住关停）。
**③ 同类的第三处：事件环订阅在关停时从不退订**
EventRing.Subscribe 注册到 Bus 的 handler 会 ring.WritePush（写共享内存），
而 Host.Close 会 munmap 整块区域。此前：
- handleEvents 把 EvtRingSubscribe 的取消函数**直接丢弃**（corehandler_runtime.go:103）
- EventsUnsubscribe 是 no-op，注释还写着「子进程 Stop 时由内核统一清理」，
但 closeProcHost 根本没有退订
于是每个订阅过的插件都在 Bus 上永久留了一个写共享内存的 handler，
munmap 后任意一条事件经过 Publish 就会写已解除映射的内存 ⇒ 同类 SIGSEGV。
修法：EventRing 记为 unsubs、新增 EvtRingSubscribeTracked（订阅即登记），
Host.Close 在 freeShm **之前**调用 evtCloser.Close 统一退订。
## 回归测试（3 个，均经变异验证「修复前判红」）
1. `TestProcess_OnExitCompletesBeforeExitedCloses`（proc）
断言 Exited() 关闭时 onExit 必须已返回。变异（把 close(exited) 挪回
onExit 之前）→ FAIL。这是本次崩溃的直接判据。
2. `TestHost_CloseUnsubscribesEventRing`（proc）
断言 Host.Close 调用了 evtCloser.Close。变异（撤掉退订）→ FAIL。
3. `TestEventRing_CloseUnsubscribesFromBus`（plugin）
端到端：订阅 → Publish 有写入 → Close → Publish 不再写入。变异
（Close 不做事）→ FAIL。
顺带给 EvtRing 加了 Written() 访问器（诊断 + 上述测试的可观察量）。
## 验证
- 三个新测试全绿；-race 下 ./internal/plugin/... 全绿
- proc 包连跑 12 轮、internal/plugins 连跑 20 轮：SIGSEGV 0 次
- 全量 go test -count=1 ./... → 38 ok / 0 FAIL
- go build ./... / go vet ./... 干净
## 另有两个**既有** flaky（本次未动，与 C 化无关，单独记录）
排查过程中用「我的树 20 轮 vs 干净树 20 轮」对照确认了归属：
- 测试间固定端口冲突（pluginmgr 9876 / remotedevice 9890 / webui 8080）：
并行或残留实例时报 bind: address already in use。干净树同样复现。
- TestRealPlugin_DeepSearchInvoke 依赖外部 SearXNG（127.0.0.1:8888）：
上游限流时（brave "too many requests"、duckduckgo/quark CAPTCHA）断言失败。
干净树同样复现。属外部依赖，不是代码缺陷。
两者都不属本次「排查崩溃」的范围，已记入 plan.md 待办。
2026-09-25 17:25:43 +08:00
0d4399c173
perf(c-core): 完全 C 化 + 消灭初版的 malloc/拷贝开销（C 从「更慢」变「明显更快」）
...
上一提交的基准结论是错的："C 比 Go 慢" 不成立 —— 那是我把自己的
malloc/拷贝开销误当成了 cgo 的固有成本。本提交先拆解成本、再逐项消灭。
## 成本拆解（同机、百万次 benchtime）
| 场景 | ns/op |
|---|---:|
| cgo 边界（零拷贝传指针 + 空函数体）| 31.9 ← cgo 真实固有成本 |
| + 一次 C.CString + C 侧 strlen | 105-111（多出 ~75ns）|
| 初版 ModelContextWindow（另加 lower_dup malloc + 16×strstr）| 175 |
即 82% 开销是自找的。而初版还违反了自己写在设计文档 §四 的原则第 1 条
「C 接口只吃 const char* + 长度」——它没传长度，让 C 侧 strlen 再扫一遍。
## 逐项修复
1. C.CString（malloc+整串拷贝）→ unsafe.StringData 传指针+长度，零拷贝
2. C 侧 strlen 再扫一遍 → 长度由调用方传入，不扫
3. truncate 的 malloc 输出缓冲 + GoStringN 拷回 → C 只返回**字节数**
（结果必然是输入前缀），Go 侧 s[:n] 完成切片，全程零分配
4. lower_dup 每次 malloc 模型名 → 栈缓冲折叠，超长走零分配回退
5. 逐字节 utf8_next 函数调用 → 字级（8 字节）ASCII 检测
6. truncate 扫完整串才判断 → 数满 keep 个 rune 立即返回（提前短路）
7. 纯 Go 侧 len([]rune(s))/[]rune(s)（1KB 分配 4KB）→
utf8.RuneCountInString / DecodeRuneInString 游走，零分配
## 结果
| 基准 | 初版 C | 优化后 C | 纯 Go | 提升 |
|---|---:|---:|---:|---:|
| ModelContextWindow | 175 | 76.5 | 46.8 | 2.3× |
| EstimateTokens / 1KB ASCII | 2318 | 80.8 | 326 | 28.7× |
| TruncateByTokens / 1KB ASCII | 2594 | 71.7 | 411 | 36× |
| TruncateByTokens / 1KB 中文 | 3923 | 70.1 | 3097 | 56× |
## 完全 C 化（jianf 裁定）
撤掉我一度加的「短串 <32B 走回 Go」按长度分派：那会同时存在两份语义
可能分叉的实现。C 是唯一实现。
代价如实记录：EstimateTokens("qq") 这类极短串上 C 约 47ns（几乎全是
31ns 边界成本）vs 纯 Go 约 3ns，慢约一个数量级；绝对值纳秒级
（0.000047ms），单次请求尺度可忽略。若某循环对极短串高频调用，
正确应对是**把该循环 C 化（批量传一次）**，而不是按长度分派回 Go。
## 顺带补的正确性缺口（初版是真错的）
初版 C 的 UTF-8 解码只按首字节推断长度、**不校验后续字节**，
因此对畸形序列会与 Go 分叉：例 "\xE4\x41\x41"，Go 判 3 rune，
初版判 1 rune ⇒ rune 计数偏差 ⇒ token 预算与截断点偏移。
这类偏差**只影响计数、不会崩**，不测发现不了。
现在 C 侧做与 utf8.DecodeRuneInString 等价的完整校验（含过长编码、
代理对、超 U+10FFFF、截断序列），语义边界逐条注释。
代价：中文密集输入比初版慢（1467 vs 840）—— 这是刻意的正确性代价，
且仍比纯 Go 快 2×。
新增测试：
- TestGolden_InvalidUTF8：3000 组**任意字节**（含畸形序列）对拍，
覆盖初版会分叉的输入类别
- TestGolden_TruncateAlwaysPrefix：截断结果必为原串前缀且不超长
- C 契约测试从 21 项扩到 40 项（含非 NUL 结尾、超长名、畸形 UTF-8）
## 包现在要求 cgo 才能编译
删除 codec_nocgo.go：CGO_ENABLED=0 下整包构建失败（错误直指缺失符号）。
不保留回退的理由：只验证过一条路，就不该存在第二条。
实测这不影响任何构建 —— go list -deps 证明只有 cmd/homed 依赖本包，
而 waiter/initconfig/memgc/mock-server 均不依赖（逐个验过），
且 homed 本就强制 cgo（sqlite3 + gojieba）。仓库无 CI。
Makefile 把「不许有第二条路」变成可执行断言：check-codec-cgo-only
（断言 cgo 下全绿 **且** CGO_ENABLED=0 下必须失败）。
## 验证
- C 契约测试 40/40（gcc -Wall -Wextra 零警告）
- 黄金对照 6 个测试全绿（含 2000 组随机 + 3000 组畸形字节对拍）
- 变异测试：改 C 侧返回值后 go test 立即 FAIL（确认真的走 C）
- make check-codec-cgo-only 两项断言通过
- go vet ./... 干净；全量 go test -count=1 ./... → 38 ok / 0 FAIL
## 已知既有 flaky（与本改动无关，单独记录）
internal/plugins 在全量并发下偶发一次 SIGSEGV，栈在
internal/plugin/proc/{unified.go:234,arena.go:197}（arena 的 getU32）。
该两文件最后修改于 09-10，本提交 0 处触及；随后连跑 5 次单包 +
2 次全量均通过。初步判断是 arena/shared-region 的既有竞态，需单独排查。
2026-09-25 15:40:20 +08:00
1291379b9f
test(c-core): 补跨语言开销基线 —— 数据反驳「C 比 Go 快」的直觉
...
codec.go 的注释写着「EstimateTokens 是否该留在 C 侧由 codec_bench_test.go
的实测数据决定，不要凭直觉断言」，但那个文件此前并不存在（悬空引用）。
plan.md 与设计文档也都在说「需先有真实延迟基线（当前没有）」。本提交把它补上。
## 数据（ns/op，benchmem）
| 基准 | C（经 cgo）| 纯 Go | 谁快 |
|---|---:|---:|---|
| ModelContextWindow（短 ASCII）| 175 | 38 | Go 快 4.6× |
| EstimateTokens / 空串 | 100 | 0.43 | Go 快 230× |
| EstimateTokens / 短 ASCII | 115 | 6.5 | Go 快 17× |
| EstimateTokens / 短中文 | 100 | 29 | Go 快 3.4× |
| EstimateTokens / 中 200 字 | 229 | 509 | C 快 2.2× |
| EstimateTokens / 1KB 中文 | 840 | 2870 | C 快 3.4× |
| EstimateTokens / 1KB ASCII | 2318 | 332 | Go 快 7× |
| TruncateByTokens / 短中文 | 233 | 54 | Go 快 4.3× |
| TruncateByTokens / 1KB 中文 | 3923 | 6918 | C 快 1.8× |
（已用 -count 复测确认稳定；ascii_1k 的异常已单独隔离复测 3 次）
## 三条结论
1. **cgo 固定开销约 95–100 ns/次**，小输入下完全压倒算法差异。
2. C 只在**长中文**（UTF-8 步进重）上领先；长 ASCII 反而 Go 快 7×
（Go 的 utf8.RuneCountInString 对 ASCII 有快路径，C 侧逐字节跑）。
3. ⇒ 判据应是「哪个在**真实输入分布**下真能变快」，不是「哪个看起来更底层」。
## 对后续 C 化的影响（已写进 plan.md §七 与设计文档 §7.1）
- EstimateTokens 的真高频点在 process.go:476 的逐事件循环与 resident.go:552。
字段分布不单一：Source 是短标签（Go 快 17× 那一档），
Input/Response 是对话文本（长中文 C 快、短文本与长 ASCII Go 快）。
⇒ 当前一刀切走 C 会让短串净亏；正确做法是按长度分派，
但须先用真实长度分布复测，不要凭推测动手。
- ModelContextWindow（provider.go:333）与 TruncateByTokens（tooldefs.go:38）
调用点单一、非热路径，开销在单次请求尺度上无关痛痒。
这不否定 C 化方向：协议编解码（JSON 解析、SSE 分片）处理长文本，
才是 C 的主场，也是比「把短函数搬过去」更合理的下一步。
2026-09-25 14:51:10 +08:00
e3867b3481
feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链
...
第一刀只做三个纯函数（窗口推断 / token 估算 / token 截断），
价值不在功能（Go 版没问题），而在打通「Go → cgo → C」全链路并
建立可复现的对照范式，后面每扩一个函数都复用它。
## 为什么是这三个
按「无状态 → 有状态」分层，L1 协议编解码最安全：纯 string in → struct out，
不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术，最小可验证切片。
## 关键设计：包内符号链接，不链接静态库、不 include 包外源
三种做法都实测过，只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」：
1. ❌ 链接 `csrc/build/libha_codec.a`（原方案）
- .a 是构建产物、不入库（.gitignore 的 build/ 命中 csrc/build/），
而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空，
实测报 `cannot find .../libha_codec.a`
- 交叉编译 linux/arm64（homed 真实发布目标）时，宿主 x86-64 的 .a
被链进目标产物，实测报 `file in wrong format`
2. ❌ `#include "../../../csrc/src/ha_codec.c"`（包外相对包含）
★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测：包外源把返回值
7→8，`go test` 依然通过（缓存命中、静默沿用旧代码）；同样改动落在包内
文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。
（包内 shim `#include` 包外源同样漏跟踪，已实测排除。）
3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/`
文件在包目录内 ⇒ 缓存按内容正确跟踪；只有一份权威源 ⇒ 无副本漂移，
也不需要「同步 C 源」的 make 目标。
## 不需要额外 build tag
ha_codec 是零依赖纯 C99 源码内联编译，不需要外部库或工具链前提；
而 homed 本就强制 cgo（sqlite3 + gojieba），故 C 路径自然生效。
只用 `cgo` / `!cgo` 一组约束（对比 onnxruntime：那个需运行期 .so，故必须显式 tag）。
## 顺带修掉的既有缺陷（非 C 化引入，但一直缺覆盖）
- Makefile 的 arm64 目标缺 CC/CXX：cgo 回退到宿主 g++，报
`gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`
（deploy/packaging/build.sh:49 一直是对的，Makefile 漏了）
- Makefile 的 arm64 目标缺 .syso 隔离：cmd/{homed,waiter}/*.syso 是 Windows
COFF 资源对象，Go 会把同目录 .syso 无条件链进任何目标，交叉到非 Windows
平台报 `file format not recognized`（build.sh 有 hide_syso_for_target）
## 验证（每条可复现）
- `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64（82MB）
- `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64（79MB）
- 移走 csrc/build/ 后 homed（cgo）与 waiter（CGO=0）均能构建
- 变异 C 源（131072→777）后**同一缓存**下 go test 立即 FAIL（改前：仍报 ok）
- `make check-codec-paths` 两条路径 OK；`make csrc-test` C 契约测试 100%
- 黄金对照：手写用例 + 2000 次随机对拍，C 与纯 Go 逐值相等
- 全量 `go test -count=1 ./...` → 57 包：38 ok + 19 无测试 + 0 FAIL
新增 `make check-codec-paths` 防回归：只测一条路径时，另一条的破坏不会被发现。
## 文档
- `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」，并更正因
「Windows 原生已放弃」而过时的 §2.3（回退路径的理由需重述）
- plan.md 的 P0-1 标记为已修复，附实测证据
2026-09-25 14:45:08 +08:00
40669d7b9b
docs(plan): 按源码核实重写——剔除过时/跨仓项，只留 10 项真待办
...
旧 plan.md（1474 行）是「历史工单 + 路线图」混合档，混入两类错误：
1. 已实现却仍标 TODO（§13.12 L3 多模态、§11.4 Lua 快照锁、§12.2 setToolBlocks、
§13.11 主体 11 项）
2. 根本不属于本仓的跨项目工单（§13.9 在 llmsproxy 仓、§13.10 在 agentmail 仓）
本次回到源码逐项核实（grep 符号存在性 / go build / go test / go test -race），
新档只保留经证据确认的本仓待办，每条附 file:line 与可验证的验收条件。
- §一 结论速览（10 真待办 / 4 生产验证 / 8 已关闭 / 2 跨仓）
- §二 真待办 P0-P2：RuntimeManager 分组 worker、reload 语义说谎、arena 无
Grow/Shrink、事件环零真实负载、工具超时措辞、handleAgentAction 501、
Lua 独立 ABI、Windows 无真机验证、homed heap 常驻、3 个测试缺陷
- §三 已关闭 8 项（附源码证据，防复活）
- §四 生产部署后验证 4 项（代码已就绪）
- §五 跨仓工单归属说明
- §六 明确「不做」的决定
2026-09-25 09:17:11 +08:00
dc53cf48df
docs: 补站点基础设施运维手册（不含任何敏感信息）
...
本项目的生产部署是「多站点 + 统一入口 + 两层 TLS 终止」，此前只存在于
人和 agent 的临时记忆里 —— 换个人接手要重新摸索一遍，我这次就因此在
同一类问题上反复踩坑（误报「已修好」两次、并造成一次全站 TLS 故障）。
把机制写下来。
## 内容
- §0 拓扑：两层 TLS 终止（公网入口机 + 内网网关机），并指出「改一层 ≠ 改完」
- §1 部署一个静态站的完整流程（内网 drop-in → 证书 → 公网 drop-in）
含若干踩过的坑：为何用 drop-in 而非改生成的主配置、
为何静态站必须 `try_files ... =404`（回落 index.html 会让不存在的路径
返回 200，监控与链接检查全都「通过」）、反代为何要关缓冲攒包
- §2 验收：**必须用 `--resolve` / `--host-resolver-rules` 走真实公网路径**。
内网 DNS 会把域名解析到内网机，直连 curl 测的是另一条路 ——
这正是我此前误报「已修好」的根因。附 Playwright 片段
（强调 `ignoreHTTPSErrors` 必须为 false，否则等于没测）
- §3 证书续期：cron → 续期 → 钩子（内网 reload + 推公网），全自动；
以及**推送脚本必须保留的四道防线**（见下）
- §4 管理后台接口：先取 schema 别猜字段名；路由表是**整表替换**；
写完要轮询验证（apply 是异步的）；系统管理的分组不能手工加条目
- §5 已知陷阱与事故复盘（6 条，均来自本项目真实故障）
- §6 给 agent 的直读入口（llms.txt / 每页 .md，含两个必踩的坑）
- §7 脱敏约定
## 关于事故复盘
§5.1 记录了我这次造成全站 TLS 故障的根因：把 acme.sh 的证书目录名
（**字面含 `*`**）交给了 glob，glob 展开后误匹配到别的证书并写进全局默认
证书。由此提炼两条硬规则：字面 `*` 绝不用 glob；写生产前必须断言
「读到的是什么」。§5.3 记录了「删证书记录前先查全盘引用」——
我漏了 /opt/ 导致推送脚本失效。
## 脱敏
全文无真实域名、IP、token、云 AK/SK、实例 ID 与内部组件名，
一律占位符（`<PUBLIC_IP>` / `<GATEWAY_DATA>` 等），
取值指向本机私有笔记与基础设施面板。已用脚本对 8 类模式做终审扫描：
仅 `127.0.0.1` / `0.0.0.0` / `example.com` 这类结构性取值保留。
技术论断均与线上实际配置或上游源码逐条核对（drop-in 指令、钩子行为、
后台接口语义），文档本身不构成新的未验证声明。
2026-09-24 15:04:02 +08:00
ddbe720e5d
chore: 忽略 SDK 文档站的主题覆盖目录
...
上一批漏了 overrides/（只覆盖 footer.html 以补备案号）。它与 docs/、
mkdocs.yml 同属文档站，核心仓不应跟踪——规则漏一条就会在 git status 里
冒出来，正是之前 example/ 那类问题的来源。
2026-09-24 13:31:39 +08:00
e61d1b3929
docs: 更正 PluginMgr 的能力描述 + 挡住新文档站目录
...
## 更正一处实测证伪的断言
`assets/docs/{zh,en}/PLUGIN_DEV.md` 都写着「`PluginMgr()` 仅内置插件可用，
外部动态插件无法直接调用」——**这是错的**。
建 SDK 文档站时对照 `hmapdev` 桥接模板实测：
- `proc_main.go.tmpl:692` 显式 `base.SetPluginMgrAPI(procPluginMgr{})`，即桥接运行时
**为外部插件注入了** PluginMgr；
- 公开 `sdk/plugin.go:282` 的注释本身就写着「PluginMgrAPI 提供插件管理能力
（外部插件可调用）」。
真正的区别是**方法数**，不是有无：
| 接口 | 位置 | 方法数 |
|---|---|---|
| `sdk.PluginMgrAPI` | 公开 SDK | 3（ReloadOne / ListLoadedPlugins / IsPluginDisabled）|
| `internal/sdk.PluginManager` | 内核内部 | 9（另有 Enable/Disable/Remove/ReloadPlugins/IsBuiltinPlugin 等）|
两个接口名字相似但**不是同一个**，这正是混淆的来源。已在中英两版改写为准确描述，
并保留原有的「内置插件 API」代码块（那段示例用的确实全是内部面，加注说明）。
## 挡住新文档站目录
SDK 仓新增了 `docs/`（mkdocs 站点源码）与 `mkdocs.yml`。它们与 `README*`、`tools/`
同类——属于 SDK 仓，核心仓不该跟踪。规则带前导路径限定，核心仓自己的 `docs/`
不受影响（实测 `git check-ignore` 命中，工作区不再出现这两个路径）。
SDK 仓同批提交 0a6e2b7（文档站本体）。
2026-09-24 12:10:10 +08:00
75896784f4
license: 明确内核 AGPL / SDK MIT 的边界（插件不受 AGPL 传染）
...
SDK 仓改为 MIT（同批提交 e97cafc）后，核心仓几处「插件静态链接 SDK 故须同许可」
的论述不再成立，一并更正。
## 边界（现在写清楚了）
- **AGPL-3.0-only 覆盖内核与随包内置插件**：homed、internal/、internal/plugins/
下 18 个内置插件。§13 网络条款照旧适用。
- **MIT 覆盖公开 SDK**：sdk/ 零外部依赖、只依赖 Go 标准库，不引用内核任何代码。
- 因此**外部插件不是本项目的衍生作品**，作者可自行选择许可（含闭源、商业、
私有），既不必同许可、也不受 §13 约束。
## 改动
- README.md / README_EN.md「许可」章节：改写静态链接那段，写明上述边界与理由
（决定许可的是被链接的 SDK 代码，而它是 MIT；子进程隔离不再是关键论点）
- README.md / README_EN.md changelog：**按本仓惯例保留历史原文**，在既有更正
注记区追加一条「许可口径已变更（2026-09-24）」，而不是去改写 v1.2.0 的原文
—— 避免伪造当时的语境
- site/index.html footer：状态栏拆成「内核许可：AGPL-3.0-only」+「插件 SDK：MIT」
两行；声明区分「AGPL（内核与其内置插件）」与「SDK 以 MIT 发布，插件不受传染」
- .gitignore：example/ 注释里的计数 20 → 21（实际 10 个示例 ×2 + qq/plugin_test.go；
规则本身与「有意保留」的说明不变）
验证：go build ./internal/meta/ ./internal/agent/core/ 通过；官网 1440px 无横向溢出、
无控制台错误，footer 许可两行正确渲染（/tmp/lic-footer.png）。
2026-09-24 10:55:23 +08:00
5c7f3f82c5
chore(sdk): 同步 SDK 仓 SetAutoRestart 文档修正
...
SDK 仓 5af2a86 把 `SetAutoRestart` 的「崩溃后自动重载」改准为
「崩溃后自动重启」，并补上真实约束（线性退避 1s→2s→3s、
5 分钟窗口内第 4 次崩溃即停止、与「重载」是两回事）。
主仓以 vendored 方式跟踪该文件（third_party/homeagent-sdk/sdk/plugin.go，
主仓只跟踪其 40 个文件、不含 README），故此处同步同一改动，
保持两处一致。
2026-09-21 10:35:12 +08:00
0a3cddbc9e
fix(plugin): 退避注释里无实测支撑的「感知不到工具缺席」
...
`scheduleProcRestart` 的注释写：
线性退避：1 次→1s，2 次→2s，3 次→3s。崩溃循环时不至于打满 CPU，
又足够快到用户感知不到工具缺席。
前半句是事实（退避确实只为防崩溃循环打满 CPU），后半句是主观断言：
首次重启就要等 1s，这 1s 内该插件的工具是缺席的、调用会直接报错。
「用户感知不到」既无实测支撑，也会让读代码的人误以为是无感恢复。
这正是另一处文档（README「崩溃到恢复 <1s」）同源的问题 ——
实测退避为 1s/2s/3s，故 <1s 从未成立（`procRestartBackoff = time.Second`
由 56498d3
2026-09-21 10:34:41 +08:00
5e704e233c
site: 正名「驻留子 agent」+ 删净页面小字注解
...
用户两点意见：
1. 那个东西不叫「分诊助手」，叫**驻留子 agent**
2. 页面上加的小字注解全是废话，全删
## ① 正名：分诊助手 → 驻留子 agent
「分诊」只是 offload.go 里对**职责**的描述（triage），
`resident.go` 顶注给的正式名是「驻留子」，`docs/zh/resident-subagent-design.md`
也把它列为独立概念（根 agent / 驻留子 / 工作式轻量子三类）。
7 处全部改正，含图内 SVG 文字、`aria-label`、架构流程图、FAQ 正文：
| 位置 | 原 | 现 |
|---|---|---|
| 图 5 框标题 | 分诊助手 | 驻留子 agent |
| 图 5 框内第二行 | 临时驻留子 | （删，与标题重复） |
| 图 5 的 aria-label | 转投给分诊助手 | 转投给驻留子 agent |
| 正文 | 转给一个临时驻留的**分诊助手** | 转给一个**驻留子 agent** |
| 架构图转投分支 | → 转投临时分诊助手 | → 转投驻留子 agent |
| FAQ | 这正是「分诊助手」的用途 | 这正是驻留子 agent 的用途 |
| CSS 注释 | 分诊助手接到消息 | 驻留子 agent 接到消息 |
## ② 删掉 11 处注解小字
原则：**复述图上已画出来的、或标题已说过的** → 删；
**承载数据**（插件版本 / 源码路径 / SVG 图内必要标签）→ 留。
- `.duty-note` ×6：架构图里 6 个阶段下面那行灰字
（「构建消息与工具表 · 插件可在此短路」等）—— 阶段名本身已经说清，
而这 6 行会把循环框右半边撑空
- `.flow-note`：重复解释 `on_input` / `before_output` 跑在什么时候
- `.dv-caps` ×3：图 4 的「任何中断都能插它前面」「被打断的现场压入中断栈」、
图 5 的「不必干等」—— 图上插队动线和回执 chip 已经把它们画出来了
- `.dv-note` ×2：图 2「实测：statically linked，无动态依赖」、
图 3「实测整段写入+读回 3.5µs」—— 数字重复
- `.dv5-tnote`：「默认关闭，需部署方打开」—— FAQ 里有完整说明（含理由）
- `.duty-ev` ×4 + `.sm` ×4：证据行/注释行，数字并回正文
（「实测整段写入 + 读回 3.5µs。」等）
## ③ 删小字的连带修正
- **11 处死 CSS 全部清掉**（`.duty-ev` / `.flow-note` / `.dv-caps` /
`.dv-note` / `.dv5-tnote` / `.sm`），单文件不留无人引用的规则
- 循环框删掉 6 行灰字后**右半边空了一大块** → 改为 `fit-content` 收窄居中
## 自己踩到并改掉的坑
- 循环框收得太窄（16rem），回边徽标「有工具调用则回到 ①」**压住**
`after_toolcall` → 加 `min-width` 并加大底部 padding
- 想让循环框占满宽度，试过**阶段项排两列** → 截图发现编号被 grid
按行填充排成 `1/3/5 · 2/4/6`，线性流程顺序全乱。已回退单列，
并把这条教训写进 CSS 注释（免得后人再试一次）
- 图 5 触发条件框删掉小字后留白偏大 → 高度 56→42
## 验证
- 三档宽度（1440/768/390）：无横向溢出、回边徽标与阶段项**零重叠**、
文字未被截断
- 深浅双主题 / JS 禁用 / reduce 回归全绿；控制台零错误
- 死 CSS 计数全部归零；「分诊」全站残留 0
- CSS 括号平衡，文件 141,847 字节（原 143,960，净减 2.1KB）
2026-09-21 10:23:06 +08:00
c1d3265cc4
site: 重做第 3/5 张示意图 + 删冗长文案 + 修中文排版
...
用户反馈：3/5 页面图片不够精致、动画单调；hero 与架构节两句文案啰嗦；
图 1 那句注释要删。
## ① 删掉两处冗余文案
- 图 1 的 `<p class="dv-note">箭头只进出插件 —— 内核一列都没有</p>`：
图上已经画出来了（光球只打插件、内核周围无连线），注解是重复
- 架构节副标题的「插件可改写或短路」：与组件表里 `Stage` 那行完全重复
（那行还更具体，带 1/4/2 的阶段分布）
## ② hero 副标题重写
原文「内核只管编排、记忆与调度，消息 / 文件 / 网络 / 设备一律交给插件。
插件崩了不牵连内核 —— 换掉一个二进制就热重载。」三重堆叠、句子太长。
改短后又发现**两处与源码不符**，一并改准：
- 「热重载」不是崩溃后的行为。崩溃走的是退避重启
（`scheduleProcRestart`：1s/2s/3s，`AutoRestartEnabled` 默认 true），
`ReloadOne` 是换二进制那条路径。混成一句等于说错。
- 改为「崩了自己重启，波及不到内核」。
## ③ 图 3（共享内存）：从稀疏线框重画
原图 19 个元素、层次扁平。重画后 53 个元素、三层递进：
- 两个进程做成带玻璃高光的卡片，各标自己的**虚拟地址**（0x7f2a… / 0x55c1…）
- 中间一句桥接：「不同虚拟地址 · 同一物理页」——这才是零拷贝的关键
- 物理页外框呼吸描边 + 极淡填充
- 段内标出 `header`（魔数·版本）与 `arena`，并加**字节刻度**，
把「一片区域」讲成「有结构的区域」
## ④ 图 5（长任务转投）：填掉大片空白
原图下三分之一完全空着，且「两种出路」只写在文案里、图上没有任何体现。
- 主 agent 加**忙碌进度条**（一直爬不到头，呼应「占住很久」）
- 积压消息由 2 条改 3 条、宽度递减成「一摞」，并逐条被取走
- 右上空白填入**触发条件**，给的是源码实测默认值
（`defaultOffloadBusyAfter = 5min`、`defaultOffloadMinPending = 3`），
并注明「默认关闭，需部署方打开」
- 新增回执区：`① 简单 → 直接办完，发回原通道` /
`② 需主 agent → 回「忙碌中，请稍候」`，并用光点示意回执送达用户
## ⑤ 排版：中文之间夹空格
改文案时实测发现正文里有「实时 渲染」这类中文间空格 —— 源码换行被浏览器
渲染成一个空格。找出真实渲染有空格的位置并修掉（改用 innerText 判定，
textContent 会把 `<em>` 等块边界误判为空格，实测误报了 2 处）。
## 自己踩到并修掉的几个坑
- 「各自的虚拟地址」两句标签被竖向虚线穿过（压字）→ 改为一句居中桥接
- 图 3 标题靠左时被 `x=72` 的写入虚线穿过 → 改居中
- 玻璃高光整块铺满像蒙了层白纱 → 收到上半部、透明度 .3
- 巡行光点框看起来像页内多了一层框 → 去掉，改为外框呼吸
- 内层标题与外层桥接都在说「同一物理页」→ 内层改为描述段布局
## 验证
- 深浅双主题逐图截图核对（图 3、图 5 各两套）
- 动画：图 3 从 5 → 11 个动画元素、图 5 从 8 → 10；元素总数 19→53、17→45
- reduce 下新增的 CSS 动画（physBreathe、dv5-pile、忙碌条）全部停；
SMIL 仍靠 pauseAnimations，8/8 SVG 已暂停
- 回归：深浅主题 / JS 禁用 / reduce / 390·768·1440 三档，零横向溢出、无控制台错误
- 结构：CSS 括号平衡、HTML 无未闭合标签
2026-09-20 23:37:16 +08:00
5ab10f679b
site: 修正 FAQ 三处与源码不符的描述
...
用户指出「常见问题部分描述不太符合事实」。逐条对着源码核了六条，
查出三处不准（第 4 条是实质性误导），另修掉一个由此暴露的滚动缺陷。
## ① 第 3 条：「L4 是内核保留的」漏了一半
源码 `interruptLevel(evt, privileged)` 有**两条**放行 L4 的路径：
`privileged=true`（内核）与 `isKernelLevelSource`（编译期内置插件）。
`scheduler.go:74` 的注释也写明「只给内核与编译期内置插件」。
原文只说「内核保留」，会把内置插件的能力说没。已补上。
（「外部插件声明 L4 会被夹到 L3」这句本身没错，`clampPluginLevel` 确实如此。）
## ② 第 4 条：自动转投默认是关闭的 —— 原文读起来像默认行为
`DefaultOffloadOptions()` 返回 `Enabled: false`，源码注明理由：
「默认关闭、由部署方显式打开，与『显式才是特权』同一条理由」。
原文说「内核拉起临时驻留子接手」，通篇没提这个前提，读者会以为开箱即用。
已补上「默认关闭」并给出默认阈值（实测 `defaultOffloadBusyAfter = 5min`、
`defaultOffloadMinPending = 3`，原文只说「忙超阈值」「积压够多」，没给数）。
## ③ 第 5 条：「媒体跟着记忆块走」不完整
`payloadHeld()` 的存在说明有**共享**一说：同一份字节可能被多个块持有，
此时**不删**。两个删除点（`medialoop.forgetPayloads` 与 `sdk/memory_impl.go`）
都各自做了 `stillHeld` / `payloadHeld` 检查，注释写明
「同一张图可能被多个块引用」。「跟着块走」会让人以为按块计数即可。
已改为「如果同一份字节仍被别的块共享，则不删」。
## 核对无误的四条（未改）
- 第 1 条：`现场保存/恢复`、`中断栈` 都是 `scheduler.go` 的原词；四级中断、
上下文预算、蒸馏与召回均在
- 第 2 条：三通道准确（`proc/shm.go` 顶注：`stdio JSON-RPC` 控制面 /
`shm + 偏移` 数据面 / `eventfd` 通知面「事件环 post-and-forget」）；
「摘除工具、阶段与通道」对应 `UnregisterPluginTools` /
`UnregisterPluginStages` / `releasePluginChannels`；`onProcCrash` 注释即
「摘注册面、喂健康计数、排一次重启」
- 第 6 条：`go:embed adapters/*.lua` 真嵌入；9 个名字与 `internal/lua/adapters/`
下文件逐一对应（`server.lua` 是网关脚本，不计入）
## ④ 顺带修掉：FAQ 全部展开后滚不到底
改动后我照例量了末尾能否到底，发现**全部展开时卡住、页脚不可见**：
展开后 faq 712 + footer 367 = 1079 > 一屏 900，`mandatory` 又把滚动锁住。
这里走了两次弯路，都记进注释了：
- 先想只让 faq 退出吸附 → **死锁**：它下方没有吸附点，而 mandatory 只允许
停在吸附点，实测卡在 plugins 的吸附位（y=9455）不再前进
- 阈值先误用「视口高」→ 展开后 faq 高 712 < 892，判不出超限，类根本加不上
最终改为「展开超过『视口高 − 页脚高』时整页切到自由滚动」，
因为 faq 是最后一个吸附节，它一旦装不下，末尾就必须整体自由。
## 验证
- 折叠态：到底=true，页脚可见，faq 标题不被导航遮挡（h2 顶 210 > 67）
- 展开 1 条 / 展开全部 6 条：两种状态都到底=true、页脚可见
- 一滑一页仍生效（8/8 次停靠不同节，72px 偏移为导航高度）
- 深浅双主题 / JS 禁用 / reduce / 390·768·1440 三档：全绿，零横向溢出，无控制台错误
2026-09-20 22:49:56 +08:00
199e5effa5
site: 修首屏滚不到底 + 交错行出入方向 + 让示意图真动起来
...
用户反馈三点：① 拉不到最下面 ② 文字与图片没有进出动画，单调
③ 图片仍是「框框住文本」，且希望有「外界光球打到插件上」。
## ① 滚不到底：真 bug，且是两个独立根因叠加
实测（滑到底后读 scrollY）：停在 10283，上限 10669，**差 386px**，
页脚完全不可见。两个原因：
- **末尾两节合计超过一屏**。faq 高 635 + footer 367 = 1002px > 一屏 828px。
`scroll-snap-type: y mandatory` 只允许停在吸附点，于是浏览器被迫二选一：
要么 faq 标题对齐（则页脚滚不到），要么页脚可见（则标题被导航压住）。
实测两种坏法都出现过：h2 顶 = -57 / -38（导航底 67）。
修法：FAQ 六条改双列（省下约 190px），收尾段取消整屏高度，
合计压到 762px，两个要求即可同时满足。
- **只在 footer 单独设吸附点会形成死锁**。试过给 architecture 设
`scroll-snap-align: none`（它高 1180px），结果前一个吸附点把它自己吸回来、
后面又无吸附点接住，实测卡死在 y=5791，怎么滑都不动。
教训写进注释：高节退出吸附不是解法，「装得进一屏」才是。
## ② 交错行：方向与布局相反（结构性错误）
原文给每行写死 `slide-l`（文）与 `slide-r`（图）。但翻转行里图在**左边**，
却仍从右侧飞入 —— 图穿过文字进场，方向与布局相反。5 行里 3 行错。
修法不是逐行改正，而是**从布局推导方向**：`.alt:not(.flip)` 文左图右、
`.alt.flip` 图左文右，方向跟着 `.flip` 走。这样不可能再写错。
退出时不加 `.in`，transform 回到同侧 ——「从左进就从左出」是自动的。
## ③ 示意图：从静态线框变成有语义的动画
现状实测很糟：5 张图共 116 个元素，**只有 4 个在动**（各 1 条虚线），
图 2 完全静止 —— 用户说「框框住文本」是准确的。
按每张图的语义给它自己的动作（13 种 keyframes，47 个动画元素）：
- **图 1 隔离**：外部光球从画面外飞入，四种颜色命中四个插件，
激起涟漪 + 插件闪一下；内核一列都没有。这正是「外面的一切都落在插件上」。
- **图 2 零依赖**：四项依赖被**逐条划掉**。用 `pathLength=1` + `stroke-dashoffset`
让线自己「划」过去，不是淡入。
- **图 3 共享内存**：写入/读回两个包沿链路跑，arena 上有光带自左向右扫过。
- **图 4 优先级**：金色包沿四条曲线**插队**到 L1–L4 之前；
四级强度条依次点亮；队列条逐条被取走（先到先处理）。
- **图 5 长任务转投**：积压消息被接走飞向分诊助手，收到时闪一下。
配套修掉三处我自己引入的缺陷：
- `.dv-pkdot` 原用 `pkPulse` 动 `r`，与行进包叠加会闪烁 → 改只动透明度
- `.dv-ripple:nth-of-type(2n)` 按 `<circle>` 计数，误配到数据包圆点，
四个涟漪全被染成金色 → 改显式逐色
- 涟漪原画在插件框**内部**，像框里画了个圆 → 移到框下层，从背后漾开
## ④ 顺带发现并修掉的真问题
- **CSS 的 `prefers-reduced-motion` 管不到 SMIL**：实测 reduce 下 6 个
数据包照跑。加 JS 调 `svg.pauseAnimations()`，实测 8/8 SVG 已暂停。
- **窄屏横向溢出 26px**：源于我这次加的入场位移（`translateX(42px)`）
在未入场时探出视口。修法是 `overflow-x: clip`（不用 hidden，避免新建滚动容器）
并窄屏收到 ±20px。实测 390/768/1440 三档溢出均为 0。
## 验证
- 滚动：到底=true，页脚可见，faq 标题不被遮挡（h2 顶=210 > 导航底 67）
- 方向：5 行全部「文在左侧就从左进」，翻转行正确反向
- 入场：逐节停留 13 节全部入场，0 未揭示；
滑到底后 23 个 opacity=0 的元素**全在视口上方**（退场生效），无一是「场内却不可见」
- 回归：深浅双主题、JS 禁用、reduce、390/768/1440 三档 全绿，无控制台错误
- 结构：HTML 解析无未闭合，CSS 括号平衡
2026-09-20 22:37:06 +08:00
f5939979c2
docs: 更正三处无实测支撑的性能断言
...
用户指出现有文档里的性能数字可疑。逐个实测后发现三类问题，都不加改原文地
标注更正（历史条目保留原文，仓内已有此惯例）。
## ① 「崩溃到恢复 <1s」——从未成立
写于 v1.0.0 发版说明。但**当时的退避代码就已是 1s**（查 v1.0.0 tag 的
`procRestartBackoff = time.Second`），首次重启就要等 1s。
实测（新增临时测试测量 scheduleProcRestart 延迟）：
第 1 次崩溃 → 1s 第 2 次 → 2.001s 第 3 次 → 3.002s
顺带纠正我自己刚在站点写错的阈值：并非「崩 3 次停下」。实测第 **4** 次
才停（`procMaxRestarts=3`，判定为 `n > 3`），前 3 次都会重启。
## ② 「RPC 往返 p50 24.1µs」——量级对、数字不符
实测 `BenchmarkToolInvoke`：inline/small **30.4µs**、frame/small 51.5µs、
inline/large 767µs、frame/large 398µs。原文与实测同为几十微秒量级，
但具体值对不上，且未注明测的是哪种 payload。
## ③ 「CLIP 实测常驻 1.15GB」——采样点不对（6 处）
实测加载 chineseclip 两塔，RSS 会**自己降下来**：
加载前 0.00 GB
两塔加载后 1.59 GB ← 峰值
GC + 静置 0.89 GB ← 稳态（内核回收未用页）
1.15GB 落在两者之间，既不代表峰值也不代表稳态。线上稳态实测 0.39~0.58GB
（更长时间静置后更低）。同源问题：qwen3vl 的「常驻 9.4GB」实为**峰值**，
其视觉塔本就是按需加载（源码注释：每张图约 1.6GB，故按需）。
6 处全部改为「稳态 X（峰值 Y）」双值，消除口径歧义：README 中英、
docs/zh/multimodal-space.md、config/registry.go（2 处 + 1 处注释）、
providers/chineseclip/tokenizer.go。
## 验证
- `go build`（含 `-tags onnxruntime` 与不带）与 `go vet` 均通过
- 全仓 `grep 1.15GB` 已清零
- 测量用的临时测试文件已删除，无残留
2026-09-20 19:56:49 +08:00
4e39c1f05d
feat(site): priority 图补上「排队输入」这一类（用户指出的漏项）
...
## 漏项
文案写「输入走两条路」，但图上只有 L1–L4 —— **排队的完全没出现**。
源码 `scheduler.go` 开篇就写明是**两类别**：
- TaskInterrupt（InjectInterrupt*）：带 L1..L4，可抢占
- TaskQueued（InjectText*/InjectInputSync*）：**无级别**，可被任何中断打断
「级别只属于中断」是这套调度模型的关键一句，图里不表达就等于漏了一半。
## 改法
图改成左右两列，标题直接写清差异：
中断 · 带级别 排队 · 无级别
├ L4 内核独占 ├ 队列条（先到先处理）
├ L3 需及时处理 └ 任何中断都能插它前面
├ L2 消息类 │
└ L1 完全可等 │
└───────────┬──────────────┘
正在跑的任务
- 排队列用**虚线框 + 素色条**（不发光），与左侧的实线发光级别条刻意区分 ——
「无级别」这件事本身就该在视觉上体现
- 两路汇入「正在跑的任务」，并标注「同一时刻只一个」
## 顺带修的两处
- **浅色下排队条看不见**：原先复用 `gCard`，而浅色下 gCard 是白的，
白底白条等于没画。改用独立的 `--dv-queue-item` 令牌
- **横向虚线穿过队列条**：原想表达「处理方向」，结果画在了条内部。
改为右侧竖线 + 向下箭头
## 验证
- 双主题：控制台错误 0、横向溢出 0、图元零越界
- 一滑一页仍生效；JS 禁用 24/24 可见；reduce 下吸附停用
- 390/768/1440 溢出均 0
2026-09-20 10:39:53 +08:00
82a19d91d6
feat(site): 示意图升级为玻璃面板 + 修 priority 图两处错误
...
## 根源（用户指「图太平，没有高级 UI 效果」）
问题不在画得不够花，而在**手法本身就平**：纯 SVG rect + 平面文字浮在平坦
背景上，本质上就是工程草图。换基础：
- **玻璃面板**：每张图裹一层带内上高光、内下厚度、外分层投影的玻璃底 +
`backdrop-filter: blur(8px)`，图形才像「浮在界面上」而非浮在空背景上
- **顶部柔光 + 细颗粒**：径向渐变给受光面，`feTurbulence` 噪点抿掉矢量图的塑料感
- **渐变节点 + 投影**：所有节点从纯色填充改为竖向渐变面 + `feDropShadow`
- **悬停提亮**：`fLift` 滤镜（更远的阴影 + 青色泛光）
- **流动虚线**：连接线 `dashFlow` 动画，看起来「有东西在跑」
- 全部走主题令牌，深浅各自调参（浅色受光方向相反）
## 修 priority 图两处真错误
**① 文案与源码语义错位**（用户报的）
原文写「可以等的 / 不能等的，不能等的再排 L1–L4」——
但源码 `LevelBackground = L1` 的注释是「**完全可等**」。我把 L1 归进了「不能等的」。
实际是：**排队无级别（谁都能插它），中断才带 L1–L4**。已改。
**② L4 文字溢出框外 57px**
`dv-ts` 是 `text-anchor: middle`，但我按左对齐给了 x=46，长的那行
（「L4 内核独占 · 立即打断」）以 46 为中心向两边展开 → 左溢 57px。
新增 `.dv-tsl`（`text-anchor: start`）专供左对齐行。实测四行现均整齐落在框内。
## 顺带修
- 「抢占」标签贴边 99.8%，玻璃面板内边距会裁掉它 → 整条线内移
- 抢占方向原为「从 L4 顶部绕出去悬在半空」，既没连上目标也读反了 →
改为「从级别条右侧指向正在跑的任务」
- 图 4 内容仅占 viewBox 70%×71%（其余图 88–93%），显空 →
重画为「强度条背景 + 级别徽标 + 场景标注 + 抢占回边」，现 81%×90%
## 验证
- 双主题：5 面板、控制台错误 0、横向溢出 0
- **全部图元与文字零越界**（含 viewBox 内边界检测）
- 一滑一页仍生效；JS 禁用 24/24 可见；reduce 下 snap 与流动动画均停
- 390/768/1440 溢出均 0
2026-09-20 10:33:20 +08:00
abcc15984a
feat(site): 总起页改为「真正的 AgentOS 长这样」+ 修页脚状态栏不可点
...
## 总起页：从对比改为展示（用户要求）
前几版是对照表（「别人说 X → 我们要做到 Y」）。用户指出重点不是对比，
而是**把自己作为「真正的 AgentOS 样例」展示出来**。改为四张并列卡片，
每条给「机制 + 可测数字」，不做比较。
标题「真正的 AgentOS，长这样」；四题：隔离 / 调度 / 通信 / 资源 ——
操作系统躲不开的四道题，逐题给答案。
## 文案改了第三轮（用户指「读着太难受」）
按「短句、有节奏、不堆从句」重写四段正文。举一例：
旧：插件不是进程内的一个库，是内核 spawn 的独立进程。崩了就把它的
工具、钩子、通道一并摘掉，其余照跑。
新：插件不在内核里，是另一个进程。崩了就把它注册的东西一并摘掉，其余照跑。
## 修页脚「状态」栏不可点（用户报的 bug）
三行原为 `<span class="muted">` 死文本，点不动。改为链接：
- 最新发布：v1.3.x 线 → /releases
- main 在研：1.4.0 → blob/main/internal/meta/meta.go（版本号的实际来源）
- 许可：AGPL-3.0-only → blob/main/LICENSE
## 一处自查纠正
我一度在卡片里写「插件崩溃 → 恢复 <1s」，那是照抄 README 的旧说法。
查源码 `dynamic_proc.go` 发现退避实为 **1s / 2s / 3s**（`procRestartBackoff=1s`，
5 分钟内崩 3 次 `procMaxRestarts=3` 即停手等人），**<1s 不成立**。
改为如实写明退避序列与停手机上阈值。README 那句待另开一轮核实。
## 验证
- 双主题：4 卡片、控制台错误 0、横向溢出 0
- 一滑一页仍生效（6 次滑动偏差恒为 72px = scroll-padding-top）
- JS 禁用 24/24 可见；reduce 下 snap 自动关闭
- 390/768/1440 溢出均 0
- 页脚 9 个 gitcode 目标逐个对照 origin/main 的树：**全部存在**
（不只看 HTTP 200 —— gitcode 对错误路径也返回 200，此前踩过）
2026-09-20 10:11:02 +08:00
9b18852285
feat(site): 重写首屏文案 + 交错图文布局 + 一滑一页
...
## 口号与文笔（用户指「不够响亮、部分文笔不好」）
Hero 改为「是…更是…」句式：
是记得住的管家 / 更是从不让你干等的搭档
## 五个设计决定：从卡片改为交错图文
原来 4 张卡片平铺。改为 5 行交错（文/图左右互换），每行配一张内联 SVG
示意图，纯 CSS + 主题令牌，深浅自适应，零外部依赖。
**换掉一条、新增一条**（用户指出「插件跑在独立进程」不算特色 —— MCP、LSP
都这么做，不是差异点）：
| | 内容 | 依据 |
|---|---|---|
| ② | 部署，从未如此便捷 | 实测插件 `statically linked`、`not a dynamic executable` |
| ③ | 数据如水，随流，随改，随走 | 共享内存 + 相对偏移零拷贝；实测整段写入读回 3.5µs |
标题按用户给的句式写（②③ 原文照用），正文不给形容词、给可核验的做法与数字。
## 一滑一页
`scroll-snap-type: y mandatory` + 每节 `min-height: 100svh`。
为此把 features 的 5 条决定各拆成独立 section（原 2.74 屏塞 5 行，
mandatory 下会锁死底部），architecture 的流程图也单独成节。
现 13 节，实测连续 8 次滑动精确停在第 1..8 节，间距 828px = 一屏。
## 两处实测纠正（都是我先判断错、再被数据推翻）
1. **`proximity` 做不到「一滑一页」**：实测滑 500px 落点就是 500，离最近
节边界 395px，不触发吸附 —— 只是「有时粘一下」。改用 mandatory。
2. **我误报 architecture「底部锁死」**：按 `h > innerHeight` 判定，忽略了
溢出行仍可滚动。用真实 wheel 实测 13 节末元素全部可达（含该节 828 < 900）。
所以没有锁死，压缩 vertical rhythm 是顺带的，不是修复。
## 验证
- 深浅双主题：13 节 / 5 交错行 / 5 示意图、控制台错误 0、横向溢出 0
- 一滑一页：8 次滑动停在 8 个不同节，落点间距精确 828px
- 72px 落点偏移经查是 `scroll-padding-top`（导航高 67px），确保标题不被遮挡 —— 有意为之
- JS 禁用 24/24 可见；reduce 下 snap 自动关闭（`prefers-reduced-motion`）
- 390/768 无 snap（窄屏强制一屏反而难受）；1024/1440 启用
- 真人式滚动（wheel 与 400px 步进两种）未揭示元素均为 0
注：本轮前期用了几个 Python 补丁脚本改 HTML，用户指出「不好」。后续改为
直接编辑以产出可审阅的 diff，脚本已删除。
2026-09-20 09:46:18 +08:00
47fd1e8d24
fix(release): .hmap 纳入发布产物白名单 + 路径解析
...
## 白名单（真问题）
`upload_assets.py` 的 ARTIFACT_SUFFIXES 只有 .tar.gz/.zip/.deb/.rpm/.pkg/_win64.exe，
**没有 .hmap** —— 即使插件包已经构建好放在 dist/ 下，上传时也会被静默跳过。
这正是「release 里一个插件包都没有」的直接原因之一。
补 `.hmap` 与 `SHA256SUMS.plugins`（插件包的汇总校验和，与内核包的 SHA256SUMS 分开，
避免混用）。实测 is_artifact() 现能正确识别两者、仍跳过 README.md。
## 测试路径解析
`HMAP_BUNDLE_DIR=dist/plugins` 这种相对仓根的写法原先会失败：测试的 cwd 是包目录
（internal/plugins/pluginmgr），相对路径解析到包内，报 "no such file or directory"，
看起来像产物不存在。改为相对路径按仓根解析（向上找含 go.mod 的目录）。
实测三种调用都正确：相对路径、绝对路径、不设时 skip。
2026-09-20 09:07:33 +08:00
3500744ff5
test(pluginmgr): 校验发布用插件包能被内核真实安装
...
配套 SDK 仓新增的 scripts/build_plugin_bundles.sh：**能构建出来 ≠ 内核装得上**，
这个测试用内核自己的 extractPackage 把产物真解一遍，验证三种包形态都落成规范入口。
覆盖的三种形态（都由真实产物验证过）：
- 多平台 bundle：`plugin.bin.<os>.<arch>` → 按当前平台挑出并**重命名为 plugin.bin**
- 单平台包（qq 的 plg.json 是 bundle:false）：只有 `plugin.bin`
- Lua 包（luademo）：入口是 `main.lua`，不编译 Go
不设 HMAP_BUNDLE_DIR 时 skip（不作为常规 CI 的必跑项，避免依赖 hmapdev 工具链）：
HMAP_BUNDLE_DIR=/path/to/plugins go test ./internal/plugins/pluginmgr/ \
-run TestBuildPluginBundlesInstallable -v
实测 21 个真实产物全部通过（含 Lua 与单平台两种非 bundle 形态）。
2026-09-20 09:02:42 +08:00
9f3bd1df62
fix(site): 逐条对照源码修正描述（含两处真错误）
...
上一版有几处表述与源码不符。这轮把页面上每条可核验的说法都对着代码重新查一遍，
改掉 15 处，其中两处是**事实错误**而非措辞问题。
## 事实错误
**① L4 的归属说反了（FAQ）**
原文让读者「用更高级别的中断（如 L4：内核与内核级插件）」插队，暗示插件能用 L4。
源码 `scheduler.go` 的 `clampPluginLevel` 把 **>L3 一律夹到 L3**，注释也写明
「L4 由内核独占（panic、内核事件 selfip）」。照原文写插件会静默拿到 L3。
改为：插件可声明 L1–L3，L4 是内核保留的「立即打断」。
**② 驻留子的父侧动作列错**
组件表写「父可查看/收发/压缩/回收」。"收"不存在 —— 源码的动作集是
`list | create | send | inspect | compress | reclaim | destroy`，
子持有状态面由**父 pull**（resident.go 开篇注释：父持登记表，子持 inputch 处理表，
父 pull 不打断子）。改成「查看/发送/压缩/回收/销毁，子是父拉取而非推送」。
## 措辞不准确（12 处）
- **Context 层**「最近若干条受保护」→ 源码 `pCount := 10` **写死十条**；
「预训练词向量 → 余弦相似度，TF-IDF 回退」→ 实为优先稠密向量余弦、
未配置时退到稀疏词向量（TF-IDF / fastText）；「自动下沉」→ 归档进 Document 层
- **PluginSDK「四通道」**→ 不是四个"通道"，是三面接口（工具/钩子/事件）+ 输出通道声明
- **管道「7 个阶段钩子」**→ 会被读成都在管道内。实际分布是进管道前 1（on_input）、
轮次中 4、收尾 2（before/after_output），两处都标明
- **sanitizer** 只写了"清工具调用残留"，漏了它更常做的是洗坏 UTF-8/U+FFFD/ANSI
（而这类字节会被模型复读），且不注册工具只挂钩子
- **rss**「推送通知」→ 实际是按间隔轮询 + 中断注入；补上"订阅时记历史条目，
所以订一个源不会把旧文章全推一遍"
- **memo** 补上可核验的机制：每 5 分钟检查未完成待办
- **ocr / bili** 补外部依赖（tesseract + chi_sim / yt-dlp）—— 不写清楚装完才发现缺
- **mc**「两阶段激活」原样照抄没解释；实为「想连着（意图）」与「确实连着（连接）」
两个状态分开，所以 bridge 被 kill -9 后能自动重登恢复会话
- **qq** 一句话太单薄，补 20 工具 + 权限模型要点（身份绑帧、取交集、前缀拒绝）
- **a2a / music / weather** 分别补：两个方向与端点、只读无副作用、NoMemory 取舍
## 顺带修掉两个我上一轮引入的 HTML 缺陷
用行替换时失手：Context 卡丢了一个 `</p>`、mc 卡多了一个 `</span>`。
这次写了栈式配对检查才发现（简单的计数对比看不出来）。
## 验证
- 栈式标签配对：p/span/div/button/code/section/h2/h3/details/ul/ol/a/li **全部平衡**
（修复前 p 差 1、span 差 -1）
- 事实终检 10/10：内置插件 16（all.go 导入数）、LLM 适配器 9 且**逐个名字对上**、
Go 行 109241→109k、go.mod 1.25.0、L4 归属、resident 动作、Stage 分布、备案号
- 浏览器回归：深浅错误 0、JS 禁用 47/47 可见、reduce 动效停、390/768/1440 溢出 0、
滚到底未揭示元素 0
- mc 工具数：本写「12 个动作工具」，实测 `tp+"act"` 去重后 activate/deactivate/status
之外是 **11** 个，已改
2026-09-20 08:48:15 +08:00
1b206209d8
fix(site): 更正媒体机制描述 + 页脚补备案号
...
## 描述性错误（用户指出）
1. **「引用计数 GC」已不存在**。「有引用绝不删」「媒体靠引用计数 GC」
两处都在讲一个已废弃的账本 —— 实测源码里已无 media_refs/ref_count，
`internal/memory/media/media.go` 明确写「这不是 GC，也不看引用计数」。
现行规则是「删除持有它的记忆块即删内容」，与文本块同一套
（medialoop.go 的 payloadHeld 只在确认无块共享时才删字节）。
2. **「描述才是持久语义」整张卡已过时**。旧实现靠视觉模型生成的描述当索引；
现已弃用 —— `mediaref.go` 写明标签「不再包含任何生成的描述文本」，
图片改按统一空间向量检索，`graphmedia.go` 还带一个把旧描述式实体
迁移成原生记忆块的迁移函数。卡片改为「图片靠自己的向量被检索」。
## 备案号
页脚补 豫ICP备2024074105号-1 与 豫公网安备41070202001579号，
链接到 beian.miit.gov.cn / beian.mps.gov.cn。取值来源是现网
门户配置（/root/portal/dashy/conf.yml），未凭记忆编造。
## 验证
深浅双主题下渲染正确、两条链接 href 实测无误、无 JS 错误。
2026-09-20 00:00:23 +08:00
e16a67d025
feat(site): 「一条消息进来之后」改为真正的流程图
...
原来是 ASCII <pre> 图。它有三个问题：
1. **画不出循环**。真实执行序是 7 步状态机，其中工具循环要回到开头
再来一轮 —— ASCII 只能表达上下关系，这一点只能靠文字暗示。
2. **7 个钩子排成一行是错的**。on_input 在进管道前跑，
before/after_output 在**全部轮次结束后**才跑一次；把它们与管道内的
钩子并列，读起来像一条直线。
3. 漏掉了 post_action 之后才发生的工具调用，以及"上下文裁剪 + 相关记忆召回"
这一步（在 after_toolcall 里）。
## 现在的结构
五层节点 + 分支 + 循环体：
外部输入 → 输入调度器（三条分支：入队列 / 抢占 / 转投）
→ 处理管道 →〔① pre_action ② LLM ③ post_action ④ before_toolcall
⑤ 执行工具 ⑥ after_toolcall〕↻ 循环 → 三层记忆 → 输出通道
事实全部对照源码核过（不是照抄旧图）：
- 7 个 Stage 常量取自 SDK `third_party/homeagent-sdk/sdk/plugin.go`
- 顺序取自内核 `internal/agent/core/task.go` 的 Step 状态机
（StepPrepare→StepLLM→StepToolBegin→StepToolExec→StepToolAfter→StepTurnEnd）
- 脚本末尾补一句说明 on_input / before_output / after_output 的时机
## 视觉
节点用色与三层记忆的三色一致（蓝=Context/青=管道/金=Graph，紫=转投）；
连接线上的光点错峰下行，序号依次点亮。全部是内联 SVG-free 的纯 CSS，
无外部依赖。
## 关键取舍
- **删掉了贯穿全图的中轴线**：节点背景是半透明令牌，轴线会直接透出来，
实测在「处理管道」里穿过整个编号列表，看着像画错了。连接线本身就是主轴。
- **循环回边改为内嵌徽标**：先做成从框底绕出的弧线，但它会压到下一条
连接线 —— 同样像画错。
- **给连接线补了静态箭头**：动画关掉时（reduce）方向也要看得出来。
## 验证（独立 headless 实跑）
深浅双主题控制台错误 0、页面溢出 0；图内溢出 0（390/620/900）；
**JS 禁用下 14 个节点全部可见、7 个钩子名齐全**（流程图是内容不是装饰）；
reduce 下光点/图标动画确为 none 而静态箭头仍在（宽 7px/2px）；
**7 个钩子名与 SDK 常量逐一比对通过**，防止文案漂移；
滚动到底未揭示元素 0。
2026-09-19 22:38:06 +08:00
d8b64dbd47
feat(site): 文案精简 + 插件可点击 + 版面精致化
...
## 文案（净减约 25%，信息量不变）
删的是解释性赘语与重复限定，不是信息：
- 「内核不直接读写任何外部世界…于是「内核有多可信」与…」→「内核不碰任何外部世界…可以分开评估」
- 「大多数框架先写功能再补边界。HomeAgent 反过来：先把边界和调度定死，再往上加能力。」
→「先定边界与调度，再加能力。」
- FAQ 六条逐条收紧；副标题从句子改回短语
- AI 声明与许可段去重复（两段都在讲同一件事）
## 插件徽章从装饰变为可交互（这是用户报的「无法点击」）
每个徽章现在是真按钮：点开显示该插件的**版本 + 用途**（取自各 plugin.json，
共 20 个），可多开、可收起，末尾「展开全部 20 个」一次全开。
键盘可达（Enter/Space），选中态用 aria-pressed 表达。
初版是纯 <span>，带 hover 效果却不可点 —— 看起来能点但点了没反应。
## 修正一处事实错误
统计卡原写「**36 外部插件**」。实测 36 是**加载总数**（16 内置 + 20 外部）；
外部插件实为 20 个。同时：
- 「110k Go 代码行」→ 109k（实测 109,241）
- 「10 LLM 协议适配器」→ 9（server.lua 是 zen 网关脚本，不是厂商适配器）
每张卡补一行小字说明口径，避免再被误读。
## 版面
section 统一 4.5rem 节奏、卡片内边距与标题间距收敛、组件表代码列定宽对齐、
统计卡加口径小字、三层记忆卡收紧。插件选中态从实心青底（20 个齐亮像一堵墙）
改为淡青底 + 主色描边，并给 color-mix 加了 rgba 回退。
## 验证（独立 headless 实跑，全部通过）
深浅双主题 console 错误 0；JS 禁用 47/47 可见且插件卡默认全隐（0 张）；
reduce 下粒子停、全可见；主题切换刷新保持、首绘无闪白；
390/768/1440 横向溢出均 0；移动端点插件正常展开；
插件交互逐项验过：单击展开 → 再点收起 → 多开 3 张 → 全展开 20 张 → 收起。
★ 一度报「19 个元素未揭示」，查证是我测试脚本没滚动所致 ——
逐步滚到底后实测 0 个未揭示，非真回归。
另把取数命令写进 site/README.md，并注明「36 = 加载总数」这个易错点。
2026-09-19 22:24:03 +08:00
aa4fda3188
feat(site): 深浅双主题 + 动效层，并按用户要求移除立绘
...
## 深浅双主题
跟随系统偏好，导航栏按钮可手动切换（存 localStorage）。首绘前在 <head> 里
定好 data-theme，无闪白（实测 reload 首绘即正确背景色）。
语义色全部令牌化，:root[data-theme="light"] 只覆盖取值；品牌三色两主题共用
（对应三层记忆，换主题不该换语义）。
## 动效层（1 → 11 个 keyframes）
极光漂移 + 细网格背景、粒子网络（近邻连线，密度按面积自适应、上限 72）、
三色滚动进度条、标题渐变流动、分块上错落入场、卡片聚光 + 3D 微倾、
三层记忆色条自上而下灌注、架构图流光带 + 节点脉冲、数字滚动到位、
分节标题下划线展开。
三条硬约束（都吃过亏）：
1. **内容默认可读** —— 初始隐藏只在 .js-fx 下生效，而 .js-fx 仅当 JS 真跑起来才加。
实测 JS 禁用时 30/30 元素可见（旧版把 opacity:0 写默认样式里 → 26/30 永久不可见）。
2. **尊重 prefers-reduced-motion** —— 不启粒子、不画进度条、元素直接可见。
3. **装饰不得产生滚动条** —— canvas 改用 documentElement.clientWidth
（window.innerWidth 含滚动条，实测多出 15px 撑出横向滚动），body 加 overflow-x: clip 兜底。
## 移除立绘（用户要求）
删掉 HTML/CSS/JS/资源/令牌全部痕迹，Hero 改单栏。README 记下为什么最终不放图：
原图是不透明 WebP（mode=RGB 实测），白底与角色白裙子同色，flood-fill 会渗进轮廓
让约 42% 身体透明 —— 这类素材要么出透明图，要么就别放。
## 顺带修掉 3 个真 bug（都是主题化后暴露/复核出来的）
1. **代码块换行全丢** —— .code 缺 white-space: pre，实测整段命令挤成一行。
（这个 bug 在我这次改动之前就存在）
2. **浅色下导航看不清** —— header 背景硬编码 rgba(11,16,32,.78)，改用 --nav-bg。
3. **浅色下立绘处有灰块** —— .mascot::after 硬编码深色，改用 --mascot-fade
（该规则已随立绘一并删除）。
另把 .badge / .btn-ghost:hover / 按钮光泽里 3 处 rgba(255,255,255,…) 令牌化为
--hover / --sheen，否则浅色下是白压白。
## 验证（共享 Chromium 实跑）
深/浅首屏 + 记忆段 + 架构段截图逐张看过；console 错误 0；坏图 0；
JS 禁用 30/30 可见；reduce 全可见且粒子/进度条已停；主题切换 → 刷新后保持；
390/768/1440 三档横向溢出均为 0；CSS 花括号平衡、8 个 keyframes 无孤儿。
2026-09-19 21:49:59 +08:00
11ace9fb53
feat(site): 新增产品官网落地页（单文件 · 零构建 · 零外部依赖）
...
用户要求写一个官网介绍页面。做成纯静态单文件，与仓库 WebUI 的既有做法一致
（原生 HTML/CSS/JS，无打包步骤）。
## 内容（每一条都对着源码/运行实例核实过）
- Hero：一句话定位（常驻型个人 Agent 框架）+ 看板娘立绘
- 四个设计决定：内核零 IO / 插件独立进程 / 输入有级别 / 忙时有人顶班
- 三层记忆：Context → Document → Graph，含媒体一等节点、描述即语义记忆、统一多模态空间
- 架构：一条消息进来之后的完整路径图 + 核心组件表
- 数字（**实测值，非估算**）：36 外部插件 / 340 工具 / 110k Go 行 / 10 LLM 适配器
- 上手命令、插件徽章墙、6 条 FAQ、页脚（文档/深入/项目/状态）
## 两个设计决定，都有理由
1. **配色取自品牌指南**：蓝/青/金正好对应三层记忆，故三层记忆那节直接用三色做色条。
2. **立绘按「有意的圆角卡面」呈现，不抠图**：原图是白底 + 蓝紫渐变外框，
而白底与角色的白裙子同色 —— 连通域分析显示 flood-fill 会让 42% 的身体变透明
（围裙、发丝高光被吃掉）。改为圆角 + 发光边框 + 底部渐隐，方形图与深色页自然衔接。
## 修掉一个真实的可访问性缺陷
初版把 `opacity:0` 写在**默认样式**里、由 IntersectionObserver 加 `.in` 揭示。
实测：30 个 .reveal 元素里 26 个停在不可见 —— **JS 被禁用或报错时整页永久空白**。
改为渐进增强：内容默认可见，仅当 JS 真跑起来才加 `.js-reveal` 接管动画。
复测两种场景均 30/30 可见（正常滚动 + 禁用 JS）。
## 验证（用共享 Chromium 实跑，不只是看代码）
- 控制台错误 0；两张图均加载（logo 400x400、立绘 1024x1024）
- 移动端 390px：无横向溢出，导航折叠，立绘置顶
- FAQ 手风琴展开正常（open=true）
- a11y：图片 alt 齐全、单一 h1、lang=zh-CN、无空文本链接
- 标签配对全 OK；34.6 KB；**无任何外部依赖**（无 CDN/字体/JS 库）
2026-09-19 21:15:00 +08:00
fa7cdb7b3f
docs(readme): 按源码修正 README 的过时事实（中英同步）
...
上一轮只补了 v1.3.x 变更日志，没系统核对全文。本次逐条对照源码，修掉 5 处硬错误：
1. **消息时序图漏掉输入调度器**（最严重）：还画着 `IO->>EV: inputCh` 直连
eventLoop，而当前输入必须先进调度器。补 participant 与调度阶段
（两类别+四级中断、同级不排队/更高级抢占、转投分诊助手）。
2. **图里的 `drainInterrupts` 已不存在**：实测该函数在源码中查无此项，
改为「安全点：中断求值/让位」（真实机制见 scheduler.go）。
3. **内置插件数 11 → 18**：漏列 ai_image / data / localuse / multimodal /
remotedevice / skillmgr（实测 `ls internal/plugins/` = 18）。
4. **Lua 适配器 8 → 10**：漏列 ollama / server（实测 = 10）。
5. **`agent/api/` 描述错误**：它只有 provider.go，不含 Lua 适配器
（适配器在 internal/lua/adapters/）；改为如实的「provider.go 调 vm」。
另修一处**自相矛盾**：构建章节写「依赖 Linux/Windows」，而下载章节说
homed 已放弃 Windows 原生（`package-windows.sh` 明确「不往 Windows 装 homed」，
只建 waiter.exe + 引导 WSL2）。改为「依赖 Linux」并说明 Windows/macOS 的真实边界。
并给「设计要点」补上两个当前核心机制（此前只有域分离与三层记忆）：
输入调度（两类别+四级中断）与驻留子/分诊助手。
验证：全仓文档断链 0；6 个 mermaid 图块配对全 OK；上述数字逐条实测复核。
2026-09-19 20:59:42 +08:00
d2733da0ba
docs: 删除迁移期临时文档，现行内容搬进正式文档
...
用户指出迁移评估那批是**过程性临时文档**，迁移已完成就该退场。
## 删除（38 个文件）
- docs/zh/架构迁移评估.md（1621 行）—— 评估稿。开头的「❗ 现网正在发生的问题」
（output_send 永远成功 / cgo 超时泄漏 26 次 / stage 污染）**全部已修复**，
留着是误导性告警。其 §三「目标架构」已被 ARCHITECTURE.md 完整覆盖
（且后者更细，含子进程生命周期管理）。
- docs/zh/plugin-interface-matrix.md（428 行）—— 迁移基线矩阵。
- docs/zh/experiments/（36 文件）—— 18 项可行性实验，验证的是"该不该迁移"，
迁移早已完成；实测无任何构建/测试依赖它。
## 现行内容先搬走（不能随临时文档一起丢）
- plugin-interface-matrix §九「接口扩展规则」→ 搬进 docs/git-branching.md 新增 §八
（只增不减/签名不改、新增必须"插件调用内核实现"方向、hmapdev 模板必须同步接线
否则全体插件编译失败、"接口纯追加"≠"无需重编"、合回 main 的同步清单）。
- git-branching §六 原写「接口冻结是合回门禁」—— 冻结是**迁移期**约束，v1.1.x 起
已到期，改为标注失效并指向 §八。
## 引用清理
8 处引用全部改指现行文档：plan.md ×3、两篇设计文档各 ×1、
4 处源码注释（proc/shm.go、proc/process.go、dynamic_proc.go、entry_dispatch_test.go、
proc/bench_test.go）。仅 third_party（SDK 独立仓）保留 1 处，不动。
## 验证
- `go build ./...` 通过；`go test ./internal/plugin/...` 两个包全绿
- 本项目文档**断链 0**（另 2 处断链在 oh_modules 第三方依赖内）
2026-09-19 19:22:48 +08:00
4aed6c445a
docs: 全面按当前源码更新文档 + 删除已过时文档
...
## 删除（内容已落地/已被替换，保留只会误导）
- demo.md ................... failback 与 recoverydiag 均已实现，0 引用
- docs/defect-qq-output-send-loop.md .. 已修复（本身也标了「已修复」），0 引用
- docs/embedding-comparison.md ....... 一次性选型报告，仅被 agent 产物引用
- docs/zh/plan.md ............ 描述的旧 nav 布局已重写、死配置已清，全部完成
- docs/zh/plugin-migration-plan.md ... 迁移已上生产，纯过程稿（Part 0~6 全完成）
## 更新（按当前源码核对）
- assets/docs/{zh,en}/ARCHITECTURE.md（README 指向的用户文档，最重要）：
把只讲 cancel/intercept 的旧「中断机制」章节重写为「输入调度器与中断机制」——
补上两类别 + 四级中断（L1~L4，默认 L1、外部插件 L4 夹到 L3）+ 抢占/挂起/中断栈
+ 饥饿防护（PreemptCount 提升，封顶 L4）+ 抢占冷却（2s）+ 停止语义（cancelBudget）
+ 驻留子/分诊助手/残余任务；新增「上下文预算」章节（窗口 ≠ 工作面，600K 封顶，
预算是上限非填充目标）。中英章节数现已对齐（各 13 节）。
- assets/docs/{zh,en}/PLUGIN_DEV.md：插件示例表补 6 个缺失项
（acp/deepsearch/plugindev/recoverydiag/vanblog/vikunja）；qq 工具数 17 → 20（实测）。
- README.md / README_EN.md：补 v1.3.x 线（此前只到 v1.2.0，而 1.3.x 已发布 12 个 patch）——
驻留式子 agent、输出通道寻址、输入调度器、轻量内核 profile、积压及时反馈。
- plan.md：开头两个「⚠️ 紧急/正在持续污染」是过期告警（实测 残留 = 0），
改为「已解决」并加文档定位说明；§13 仍是活跃路线图故保留。
- docs/zh/plugin-interface-matrix.md + 两处源码注释：清理指向已删文档的断链。
全仓 md 断链检查：仅剩 1 处，位于 third_party 的 oh_modules（第三方依赖，非本项目）。
2026-09-19 19:14:55 +08:00
ee3e0da7de
fix(offload): 内核说明不能被再转投（自我循环）+ offload_owned 未接线
...
★ 线上实测两个缺陷：
1. **自我循环**：转投会在队列留一条 [系统] 说明（source=kernel），
而转投条件把这条说明也算进「积压够了」⇒ 每次转投都产生下一轮要转投的东西。
实测 5 秒内连续触发两次，分诊助手不断收到「N 条积压已转投」这类噪音。
修法：takeQueuedInputs 排除 isKernelNotice（source=kernel）。
2. **offload_owned 永远为 false**：我加了 ResidentInfo 字段、加了状态面映射，
却漏了在 rc.info() 里赋值 ⇒ 线上转投子明明存在，读出来是 null。
这类「加了字段但没接线」不会报错，只会让父的判断悄悄失效
（父据此决定回收策略，读到 false 就会把临时助手当成正式子）。
测试 +3：说明不转投 / 循环必须终止 / offload_owned 会被上报。
前两条已实测「禁用守卫会失败、恢复后通过」，是真回归测试。
2026-09-19 17:47:44 +08:00
15315ad684
feat(resident): 分诊助手定位 + 残余任务由父显式决定
...
用户澄清（重要定性）：这不是「内核替父决定」，而是**及时反馈** ——
主 agent 忙时不该让用户干等十几分钟。子 agent 是**分诊助手**：
简单的直接处理并回复，需要主 agent 的立刻回「忙碌中，请稍候」、不勉强作答。
三处补齐：
1. 分诊助手的职责提示词（之前完全没给 ⇒ 子不知道自己为什么存在）：
两条路（直接办 / 报忙碌）、拿不准时报忙碌、必须 output_send 到原通道。
2. 驻留子继承父的 SystemPrompt（之前没传 ⇒ 子只用一句兜底文案，
拿不到「异步通道必须显式 output_send，否则回复被静默丢弃」这条铁律。
webui 这类同步通道能回是因为走 ResponseCh，掩盖了这个缺陷）。
3. 残余任务由父显式决定（用户要求）：reclaim/destroy 时子手头未处理的消息
不再由内核悄悄处置 —— 内核只负责列清楚，父用 residual=keep/drop 决定。
之前 pendingEvents 只收带 ResponseCh 的，异步（qq）残余任务完全不在内，
被销毁时静默消失、用户零反馈且日志无痕。
配套：
- scheduler.takeAllPendingEvents：取走全部未执行事件（不筛通道）
- ApplyResidual(keep|drop)：keep 转回父队列（保留 ResponseCh），
drop 逐条记日志 + 给同步调用方补终态（否则 cli/a2a 永久挂起）
- 状态面暴露 offload_owned，让父分清「我建的子」与「内核临时拉的助手」
- 工具 schema 加 residual 参数并说明 drop 的代价
这也是用户观察到的「机制很自然」的落点：分诊助手就在同一张登记表里，
父能 inspect/send/compress/reclaim/destroy，控制面 6 动作按 id 生效不区分来源。
测试 +7（残余 keep 转回且保留 ResponseCh / drop 通知同步调用方 /
空残余如实报告 / 分诊提示词 / 继承 SystemPrompt），
其中 drop 那条已实测「对着静默丢弃的旧实现会失败」。全套绿。
2026-09-19 17:43:16 +08:00
0fd96d6630
fix(offload): 转投必须保留 ResponseCh，否则同步调用方永久挂起
...
线上实测第二个 bug：转投生效、子也正常处理（日志各 ~3s），但 webui 的 HTTP
请求一直挂着不返回，最终 504。
根因：第一版用 InjectInputTo 转发，它会**重建** InputEvent ⇒ ResponseCh 被丢掉。
而 cli / a2a / webui 这类**同步**调用方正阻塞等这个 channel。
仓库反复警告过同一件事（Agent.Stop 的注释：「带 ResponseCh 的同步注入方
（cli / clawhubadapter 均无超时）会永久挂起」）。
修法：改走既有的跨 agent 投递原语 DeliverRouted —— 它推**原事件**，保留
ResponseCh/RequestID，只往 payload 里补转投标注。
回归测试 TestForwardKeepsResponseCh 断言**最强的那条性质**：真的等同步回执回来。
（不用「读子的 InputChan」来断言：SpawnResident 会启动子自己的调度循环，
它会与测试抢同一个 channel，那样写出来的测试是 flaky 的 —— 我第一版就是这样，
实测挂死过一次。）
已实测该测试对着错误实现会失败（10s 超时）、修后通过。
2026-09-19 17:16:24 +08:00
93172508f9
fix(offload): 积压可能全堵在 io 输入 channel，不在就绪队列
...
线上实测发现上一版**永不触发**：主 agent 跑着 6×45s 的长任务、我连发 4 条消息，
scheduler 始终显示 queue=0、residents=0，转投一次都没发生。
根因：schedulerLoop 是**同步执行**任务的，所以「正忙」期间它根本回不到循环顶部
去调 pumpInbox —— 后到的输入全堆在 io.inputCh（容量 256）里，压根没进 sched.queue。
而 takeQueuedInputs 只看 s.queue ⇒ 恒取不到东西。
★ 仓库里早记过同一个坑：armStop 的注释写着「pending 是还没被 pumpInbox 搬进队列
的那一段……只数 s.queue 会得到 0（实测），配额随之失效」。我重犯了它。
修法：转投前先 drainInboxToQueue() 把 channel 里的输入搬进队列。
与 pumpInbox 的区别是**不要求 hasRoom** —— pumpInbox 满时会停下保留背压，
而转投场景恰恰是「队列空、输入堵在 channel」（调度器回不到 pumpInbox）。
队列上限仍由 enqueue 把关，放不下的给同步调用方 skipped 终态（不丢、不阻塞）。
回归测试 TestOffloadSeesInputsStuckInChannel 精确复现该现场状态：
已实测它对着修复前的逻辑**会失败**（期望 3 实际 0），修后通过 —— 是真回归测试。
2026-09-19 17:05:38 +08:00
f2e0d55c5b
feat(scheduler): 主 agent 忙时把积压任务自动转投给驻留子
...
问题（2026-09-19 线上实测）：主 agent 被长任务占住时（现场：12 分 8 秒、69 次
工具调用），后来到达的消息全部以 level insufficient 排进中断队列干等 —— 同级
中断不能抢占同级运行任务（canPreempt），只能等前一个跑完。而内核本有驻留子
（独立 agent + 独立调度器）可并行干活。
行为（用户 2026-09-19 明确要求）：
- 触发：运行任务持续 > offload_busy_after(5m) 且积压 >= offload_min_pending(3)
- 拉起/复用「转投专用」驻留子，把积压的纯排队输入转投过去
- 在原队列位置留下说明「[系统] N 条积压任务已转投给驻留子 agent X 处理…」
通道配置（按用户口径，与人工创建的子刻意不同）：
- 不配 inputch（内核的干活 agent，不接收插件用户输入）
- 持有全部输出通道（结果要能发回 qq/webui 等正确通道）
三个设计要点（都是实测撞出来的，写进代码注释与设计文档 §7.1）：
1. 检查必须在**独立 goroutine**：schedulerLoop 同步执行任务，放它里面在
「正忙」期间根本回不到循环顶部 ⇒ 永不触发（我第一版就写错了，测试才发现）。
2. 只转投 TaskQueued 纯排队输入：中断任务带级别语义、self 任务与父的记忆面绑定。
3. 转投失败/关闭时必须把任务**放回队列前端**：吞一条输入比多处理一条更糟。
这是设计 §7「决策在父的模型手里」的**刻意例外**（父正忙、物理上无法决策，
而积压任务本来就是空的），已在文档中显式记录，且默认关闭、由部署方显式打开。
测试 11 条：只取排队输入 / 不足量不取 / 放回不丢任务 / 说明自解释 / 默认关闭 /
空闲不触发 / 端到端转投 / 上限不增殖 / 独立 goroutine 确实会触发。
2026-09-19 16:59:47 +08:00
499a4f3aa1
fix(llm): 参数无法解析时给出真因，不再静默丢弃整条调用
...
★ 上次修复误判了成因。真实根因（本次运行日志 34/34 同形）：
{"command": "…完好的长命令…", "timeout": 20s}
command 一字节没错，只是 timeout 值少了引号 —— cmd_run 的 schema 把 timeout
声明成 string、示例写着 "10s, 1m, 30s"，模型照抄格式却忘了引号。
finish_reason=length 出现 0 次 ⇒ 上次那条"截断"分支从不生效。
旧行为把**整个参数**丢掉，模型只看到 "command is required"，看不出坏在 timeout，
只能原样重试。实测本次运行 cmd_run 失败率 35%（34 败 / 71 成），
12 分钟的任务里更是 48% 时间耗在这上面 —— 每次失败都付一次完整 LLM 往返。
三处改动：
1. repairToolArgsJSON：解析失败时先试窄修复 —— 只给"值位置上未加引号的带单位
数字"补引号，且修完必须真能解析成功才接受。不碰合法 JSON、不动正文里的 20s、
不会把真截断"修好"。
2. 修复仍失败时不再静默降级成空 map，改为带 __arg_error 交给模型，并按成因
分流文案：截断→拆小参数；JSON 写坏→提醒带单位的值要加引号。
3. 统一键名 __arg_error（原 __truncated_error 只覆盖截断，语义过窄）。
同一缺陷面不止 cmd：agentcli/healthcheck/timer 都有 string 类型却以
"5m, 1h" 作示例的参数，此修复一并覆盖。
回归测试：真实日志样本修复、保守性（不碰合法/正文/截断）、
端到端（修复后 timeout 仍能被 time.ParseDuration 接受）。
2026-09-19 16:49:16 +08:00
6dca498bc8
fix(llm): 参数解析失败不再丢弃完好字段（改错值格式，不是截断）
...
★ 上次修复误判了成因。真实根因（日志 11/11 同形）：
{"command": "…完好的长命令…", "timeout": 20s}
command 一字节没错，只是 timeout 值少了引号 —— 而 cmd_run 的 schema 把
timeout 声明成 string、示例写着 "10s, 1m, 30s"，模型照抄格式却忘了引号。
实测 finish_reason=length 出现 0 次，所以上次那条"截断"分支从不生效。
旧行为把**整个参数**丢掉：模型只看到 "command is required"，看不出是 timeout
写坏了，只能原样重试 —— 12 分钟的任务里 30 次失败 / 32 次成功（48% 浪费），
每次失败都付一次完整 LLM 往返。
改法：parseToolArgsJSON 失败时先试 repairToolArgsJSON，只做一件很窄的事 ——
给"值位置上未加引号的带单位数字"补引号，且修完必须真能解析成功才接受。
因此不会改坏合法 JSON、不会动字符串正文里的 20s、不会把真截断"修好"。
真实日志样本 + 保守性 + 反伪造三组回归测试已钉死。
2026-09-19 16:47:13 +08:00
6c9b164081
feat(llm): 声明真实上下文窗口 + 工作区间与窗口分离
...
问题：core.llm.model=AUTO，而 ModelContextWindow("auto") 匹配不到任何分支、
掉进 default 32768 —— 该源真实窗口是 1M（实测 990,034 token 的 prompt 通过），
内核却按小 30 倍的窗口算全部预算。
三处改动：
1. ModelContextWindow 补 deepseek-v4/v3 → 1M；推断不出时打日志（静默降级是
这次问题的成因，不能再默默退回一个小值）。
2. sourceFieldDefs 补 context_window 声明：它早已被 readInt 读进 LLMSource
并透传到 provider，但没进这张表 ⇒ WebUI 里看不见也改不了。
3. ComputeTokenBudget 新增 maxTargetTokens=600000：窗口 1M 不等于按 838K
（80%）干活。标称窗口≠有效窗口，600K 是该源最优工作区间，所以把
「窗口上限」（会不会被上游拒）与「工作区间」（预算分配）分开。
配套 core.llm.max_tokens 4096→32768（实测长输出样本达 18,272 token，
16384 仍会截断；上限是 cap 不是目标，短问答零成本）。
测试：tokenbudget_test.go 钉死封顶生效且小窗口不受影响；
context_window_test.go 钉死推断值与显式声明优先级。
2026-09-19 14:24:31 +08:00
1e2c914119
test(llm): 钉死截断必须短路工具分派
...
补一条端到端断言：截断的 tool call 绝不能拿着空 map 走到 files_write
（那会回 'path is required'，模型据此原样重试）。断言 executeToolCallInner
的短路 + 指引可执行。
2026-09-19 13:53:56 +08:00
ee4d079c49
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
fa61247eec
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
fcaf3ffdb7
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
545d3b45a1
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
333c0ec119
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
2022875642
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
f340adb1e1
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
89259b3508
fix(ohos): 聊天改用 seq/after 增量轮询，修「不滚动/己方消息不显示/新消息不加载」
...
jianf 报的三个现象其实同一个根因：WebUI 前端在 commit f145e88
2026-09-18 10:49:30 +08:00
e90f3a629e
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
3ad6d3bf0e
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
4ca82c03d1
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
6b4f470b62
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
f671632915
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
e00c94bc43
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
c5128a3971
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
d6e0a930df
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
d9b2f2c81c
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
e4e112ce92
fix(ohos): 历史刷新不再整表替换，避免刚发出的消息凭空消失
...
sync_required 触发的 reloadHistory 会与刚发出的 POST 竞争：若历史快照
里还没有这条 user 消息，整表替换会让它消失（“客户端侧发出的消息不显示”）。
改为合并：历史为权威，但保留本地两类消息追加在末尾——
- user 且 source 为空（乐观消息）且内容未出现在历史里；
- assistant 且 !isFinal（仍在流式输出）。
2026-09-15 12:09:58 +08:00
78d857620c
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
847af53e9a
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
2b6e430154
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
76d0a22c41
docs(release): §四 补客户端版本必须与内核同步 + make 门禁
2026-09-15 11:04:31 +08:00
e1e3183918
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
2b145b5d96
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
b5a20113cb
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
246306a989
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
0bb3191284
fix(memory): SceneStats 的 strength/features 不再说谎
...
- 旧行经 ALTER 加列后 strength 为 NULL，直接 SELECT 会显示成 0（实际是 1 次）；
改为 COALESCE(strength,1)，并补上 features 计数（场景长出了几个特征）。
- 两栏一起看才能判断「场景是不是真在涌现」，而不是被一次性写出来的。
2026-09-15 09:29:46 +08:00
b9f638a297
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
59607a7ef5
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
d3f7e61760
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.59a4e1a，已核实 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
59a4e1a296
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
accf1923fc
fix(memory): doc→graph 补回常用词闸门 + 存量噪音/孤立节点清理
...
问题：图记忆里堆着「结果(192) / 什么(59) / 哪个(99) / 待命(176) / 报告(174) /
context_archived(43)」这类节点，mention_count 冲到几百、度数只有 1~2——
占着热实体位、挤满召回预算，却不带任何结构。
根因：这层过滤原本存在，后来被换掉没补回。61fbc55（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
990e740a37
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
c34e7cbb25
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
fd03e8b905
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
6547506704
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
6c8ce237dd
merge: 桌面版/鸿蒙端同步阶段管道工具格滚动展示最新一条调用（feature/stage-pipe-tool-cell-clients）
2026-09-14 20:09:57 +08:00
642c55c948
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
4f84465305
merge: webui 阶段管道工具格改为滚动展示最新一条调用（feature/webui-tool-cell-scroll）
2026-09-14 20:07:33 +08:00
b27ef885be
feat(webui): 阶段管道的工具格改为滚动展示最新一条调用
...
「工具」是循环格：一轮里可能调几十次工具/输出通道。此前每一次都追加成
chip，这一格被撑成一长条，反而看不出「现在在调什么」。改为固定一行的
滚动视口——只留最新一条，右侧给出本轮累计次数；新调用到来时旧条向上
滚出、新条滑入（morph 就地改文本不会重放 CSS 动画，故摘类 + 强制 reflow
+ 重加类）。并给 chip 名称加 .rt-chip-t 承接省略号，窄框不再硬切半截。
配套 TestStagePipelineToolCellShowsLatestOnly 钉住该口径。
2026-09-14 20:07:29 +08:00
81a0aa09d8
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
c7218157eb
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.8d0ce2c` + `HomeAgent · 8d0ce2c`；管道
`输入=输入 | 行动=思考 | 工具=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
7ae87ac14c
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
8d0ce2c576
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
4a54f6de0e
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
f3d1d526f1
feat(webui): 总览显示内核身份、图标全 SVG 化、队列改格槽、阶段管道下方按阶段列事件
...
四个问题一起改（都出在总览/内核页的展示层，不动内核逻辑）：
1) 内核版本不再"看不见"
- 3885f34⚡ ）、
工具卡与思考卡的下拉箭头（原 ▾）。
- 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.753c3a2 / HomeAgent · 753c3a2；内核页构建卡齐全
- 注入一轮轨迹：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
ac31bbc371
fix(webui): 拓扑 +N 提示改用输出带顶部锚点，修提示串行
...
无输出通道的 agent 那条带上 outTop 在渲染时才确定，而提示行仍在用
循环变量 y（已累加到别的带），所以「+N 更多」会跑到隔壁带上。
改用该带自己的 outTop，并把基线从 +13 收到 +11（紧贴最后一行）。
2026-09-14 17:40:46 +08:00
753c3a2082
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
455aca4430
chore(vendor): 同步 qq 插件权限身份绑帧修复（sdk cfa72df）
2026-09-14 16:45:17 +08:00
50d3b9de92
fix(core): 插件拒绝工具时把 ctx.Response 的理由透给模型
...
before_toolcall 的 ctx.Response 是插件写的**拒绝理由**，但工具结果被写死成
「工具 X 已被插件拒绝」，理由从不到达模型——模型于是不知道能不能重试，
会反复重试被拒的调用。抽出 denialResultText 并在有理由时原样透出。
2026-09-14 16:45:04 +08:00
ed4826f7c3
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
3885f34304
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
82512e18a0
chore(sdk-vendor): 同步 qq 插件的消息合并改动（对应 SDK 仓 a01fe21）
...
本仓 vendored 了 SDK 的部分文件（third_party/homeagent-sdk，经 go.mod replace
引用），其中 example/qq/plugin.go 被跟踪。SDK 仓的 qq 消息合并提交同步过来，
保持 vendored 副本与 SDK 仓一致。
2026-09-14 16:11:22 +08:00
f145e88192
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
7310f0d190
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
66e8f7f957
chore(docs): 收编 QQ output_send 循环缺陷记录，标记已由 max_tool_turns 修复
...
仓库根目录的 problem.md（未跟踪）是一份 QQ `output_send` 回声/无限循环的
定位记录，状态写着「待修复」，但核心早已有轮次上限（core.agent.max_tool_turns，
默认 10，task.go 到达即强制收尾，测试 TestMaxToolTurns_CapsRunawayLoop）。
把它移进 docs/ 并更新状态，避免一份过期结论长期挂在根目录；同时删掉根目录的
临时基准脚本 tmp_fusion.py。
2026-09-14 15:35:31 +08:00
41272d12b4
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
a65e33af8a
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
62ec9950b1
polish(webui): 拓扑图只在容量非默认时写数字（去掉十几行「默认」文字）
2026-09-14 11:24:34 +08:00
61de261c36
feat(webui): 通道归属合并进拓扑图，整张图改 SVG（少文字、多图形）
...
上一版把「通道分配（按归属）」单开一段，等于把同一件事拆成两张表——
而通道属于谁是**拓扑的一部分**（左边这些输入口分别被谁接管），拆开反而
看不出关系。按用户要求合并，并整体改成图形化：
- 整张拓扑用 SVG：左侧按归属画出输入通道容器（根=青色虚线框，驻留子=彩色
实线框并标轮次/上下文满），→ 汇集母线 → 内核 → 输出母线 → 右侧输出通道。
**连线即路由**。
- 信息全部改用图形编码：归属=容器/配色、容量=节点内细条（默认容量不画填充）、
输出能力=五个彩色圆点（text/file/image/audio/structured）。
- 文字降到最少：去掉四个数字块的副标题、排队队列那行只留 "FIFO"、
通道行不再写"回程由来源决定"这类说明。
- 段名改为「通道拓扑（连线即路由；左框 = 归属）」。
验证：node --check 通过；go build ./... 干净；webui 测试全绿。
2026-09-14 11:22:20 +08:00
ba16ce3e38
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
dca43a8f53
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
1687433330
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
701574056b
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
499ae40209
fix(scheduler): 安全点重新求值中断队列 + 抢占/背压计数修正 + 停机补终态
...
对照 docs/zh/input-scheduler-design.md 原文修四处（前两处是真缺陷，后两处是
观测面与设计承诺不一致），均配回归用例：
1. §4.3/§5.2「临界区结束后的第一个安全点重新求值」此前**没有实现**：
全仓唯一的武装点是 registerInterrupt，凡被拦成「入队」的中断只能等当前任务
自然结束。可达症状：WebUI 终止按钮连按两次，第二次落在 2s 抢占冷却窗内 →
入队 → 再也不会被求值。修：runTaskSteps 的安全点先 rearmPending()——
判据与 registerInterrupt 完全同一套（canPreempt + 冷却 + 临界区闸门）。
2. PreemptsByLevel 的语义是「进入 immediate 槽的次数」，但计数发生在
setImmediateLocked 之前：immediate 是单槽，同一安全点前到达的两条同级中断里
被降级的那条也被计成抢占。修：setImmediateLocked 只在真占住槽时返回 true，
计数随之为真；同时把「降级入队」的责任收归调用方，消除同一任务被入队两次的
隐患（实测该隐患会让中断任务执行两次、Executed 虚高）。
3. 状态面 Preempted 此前拿 Stats.Suspended 顶替，与 preempts_by_level 自相矛盾。
修：Preempted = Σ PreemptsByLevel[1..4]。
4. §4.4/Q4「满时阻塞发送方 + 计数并打日志」只做了阻塞：pumpInbox 满时直接返回，
一个字都不计。修：新增 Stats.Backpressure(+DTO 字段) 与只报一次的状态翻转日志；
同时显式处理 enqueue 返回值（静默丢弃会让同步调用方永久挂起）。
另：Stop() 停机前排空待办——给从未运行与已挂起的、带 ResponseCh 的任务补
skipped 终态，否则 cli/clawhubadapter 这类无超时同步注入方永久挂起（§7 I5、§11.3 X4）。
emitResponse 的 ResponseCh 写入改为非阻塞 + 告警，避免一行写错就卡死调度器 goroutine。
验证：go build/vet 干净；go test -count=1 ./internal/agent/... ./internal/plugin/...
./internal/sdk/... ./cmd/... 全绿；go test -race ./internal/agent/core/ ./internal/sdk/ 干净。
新增 scheduler_rearm_test.go 六个用例（冷却期满重新求值/同级降级不计数/Preempted 求和/
停机补终态/背压计数与翻转/pumpInbox 满计数）。
2026-09-14 10:39:25 +08:00
47808fced0
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
7dce320a31
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
86898ba41c
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
2e35ba2169
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
fc61e2268a
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
0db5a31de0
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
b23644ad74
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
1b0a5b1dc2
fix(config): 插件 def 查询不再越界 —— ListDefs 作用域 + 新增 ListCoreDefs
...
两个方向相反的越界，合起来把 WebUI 设置接口的 meta 撑成 5208 条（96% 重复）：
1) PluginSettings.ListDefs(prefix) 把 prefix 直接透传给全局 ListDefs，
等于「返回全仓所有 def」——调用方以为在问某个插件，实际拿到全部。
修复：限定到 plugin.<name>. 命名空间，并把 Key 剥回插件内局部键
（调用方看到的键必须与 Set/Get/ListPlugin 的局部键一致）。
2) DefsCore(prefix) → reg.ListDefs(prefix) 会连插件 def 一起返回，
于是 meta 里出现 plugin.<name>.<key> 的「核心侧副本」。
修复：新增 ConfigRegistry.ListCoreDefs，显式排除 plugin.* 命名空间。
生产实例实测（旧代码）：GET /api/v1/settings 的 meta = 5208 条，
其中 core.agent.* 等每个 def 都被复制 28 份（每个插件命名空间一份），
并派生出 plugin.<a>.plugin.<b>.<key> 这类幻影键。
⚠️ 幻影键不只是脏数据：设置接口的 PUT 走 SplitN(key, ".", 3)，
对 plugin.<a>.plugin.<b>.<key> 会解出 (a, "plugin.<b>.<key>")，
即按 UI 上的幻影条目保存会**写进错误插件的配置表**。
新增 TestPluginDefsAreNamespaced 钉住两条作用域。
2026-09-14 06:53:58 +08:00
653e13b470
refactor(homed): main() 696 行按启动阶段拆成 25 个阶段函数
...
main() 原本是一整条 696 行的启动脚本：日志、目录、记忆、配置、Lua、守护、
追踪、内核 API、文本记忆、LLM 源、文档/知识、人格、插件、Agent、ONNX、
IPC、心跳、关停全挤在一个函数里，变量跨 500 行互相引用。
现在 main() 只剩「顺序编排 + 就地交接」（**149 行**，低于 funlen 阈值 150）：
opt := parseFlags()
logDir := setupLogging(opt.dataDir)
agentWorkDir := ensureDataDirs(opt.dataDir)
mem, closeMem := initMemoryStack(opt.dataDir)
...
共 25 个阶段调用，实现体在同包 bootstrap.go（一一对应）。
零漂移保证：
* 阶段体逐字取自原 main，只做机械替换（`*dataDir`→参数、`memIdx`→`mem.indexer`）；
* 原 main 的每个 defer 都换成一个在**同一位置**注册的 cleanup，
LIFO 释放顺序不变；多资源阶段内部再按原注册顺序取反；
* 语句级比对：原 main 的 525 条可执行语句全部有对应，无遗漏。
仅 3 处为**有意**的结构改写（其余为同义替换）：
1. initLuaVM / initTextMemory：「启动成功才 defer Stop」改为
「失败返回 no-op cleanup，成功返回 Stop」——调用点语义不变；
2. startIPCServer：同上（用 started 标志保证失败时不 Stop）；
3. resolveBaseAPIKey：把三级兜底 API key 解析提成一个纯函数。
* defaultPrompt 提为包级 const defaultSystemPrompt（不含版本号字面量）。
验证（A/B 实测，不是只跑编译）：
* go build ./... / go vet ./cmd/homed/ / go test ./cmd/... ./internal/agent/... ./internal/plugin/... 全绿
* 重构前后二进制各起一次（-data 临时目录，SIGTERM 收尾），日志集合**完全一致**：
63 个注册工具、同名插件全部 loaded、kernel ready、插件逆序关停、'stopped'
—— 差异仅为并发加载插件的打印顺序。
全仓非测试 Go 函数现状：≥300 行 **0 个**，≥200 行 9 个，≥150 行 16 个。
2026-09-14 06:30:45 +08:00
232c41b7bb
refactor(proc): coreHandler.Handle 550 行按 method 组拆成 14 个分部函数
...
原 Handle 是一个 550 行的巨型 switch（C ABI 51 个 case 的整块平移），
按协议面拆进同包 5 个新文件、14 个小函数：
corehandler_register.go handleRegister 注册面（tool/stage/output/api/input）
corehandler_inject.go handleInject IO 注入 + SetToolBlocks
corehandler_memory.go handleGraphMemory 图记忆
handleDocMemory 文档记忆
handleKnowledge 知识库
handleTextMemory 文本记忆
corehandler_settings.go handleSettings 设置（14 个 method 共用一条实现）
handleLLM LLM 源
handleSocial 社交图只读
handleLifecycle 生命周期开关
corehandler_runtime.go handlePluginMgr 插件管理
handleStageLocks 段锁仲裁
handleEvents 事件订阅
handleArena 共享槽池
Handle 保留 capability 强制检查，只做「method → 分部函数」一跳。
零漂移保证：case 标签由脚本从原文提取（不手抄常量名），case 体逐字搬迁，
逐函数比对确认 59 个标签 / 510 行 case 体与原文件完全一致（仅行首缩进经 gofmt 重排）。
验证：go build ./... / go vet / go test ./internal/plugin/... / -race 全绿。
2026-09-13 23:29:13 +08:00
bb77607887
refactor(lua): replaceSDKReal 633 行按 SDK 子表拆分
...
抽 luaReg 上下文（L/t/plg/s + subTable/pushVal/pushList/pushErr/pushNil
五个助手方法），把单函数拆成 registerRegistrars / registerInjectors /
registerDataAPIs / registerSettings / registerEventsAndMgr 五个方法。
被移动的代码体**逐字保留**：各方法头部把 L/t/s/plg 与五个助手注入为局部
别名，所以内部一行未改，行为零漂移。luaSyncUnavailable 提为包级函数
（原来它在被拆到另一个方法的作用域里会 undefined）。
实测：replaceSDKReal 从 633 行消失，最大子方法 265 行；非测试函数
>=300 行的数量 3→2。go build/vet/test -race 全绿。
2026-09-13 22:44:39 +08:00
16df55597f
docs(ohos): README 两处事实修正（产物路径前置条件、≤400 行约定的边界）
...
1. **安装小节的产物路径**：`entry/build/` 是纯构建产物、不入库，干净 clone 或清理过
工作区时该文件不存在。补明"必须先跑完第 2 步"，并说明目录名随
`-p product=<名字>` 变化、同目录还有 unsigned 版（`hdc install` 要用 signed）。
本次实际构建校验过路径：`entry/build/default/outputs/default/entry-default-signed.hap`。
2. **≤400 行约定补边界**：不到 400 行的文件不要为了拆分而拆分 ——
`@Component` 的 `build()` 只允许一个根节点，多节点 `@Builder` 改组件会多出一层
Column 包裹，布局等价是推理出来的、不是看出来的，每拆一次都要付一次
"未上机验证"的账。并记下 `pages/Index.ets`(396) 属于"不越线就不动"的一类。
无代码改动，纯文档。
2026-09-13 22:42:37 +08:00
d817e9e10d
docs(ohos): 本地构建前置条件 + 运行时验证清单 + 工程结构表刷新
...
1. **oh_modules 前置条件**：该目录被 .gitignore 忽略但必须存在 —— hvigor 不会
自动 ohpm install，移走后构建直接报 arkts-no-untyped-obj-literals（依赖类型
声明缺失）且不重建目录。写明"clone 后先 ohpm install，别当垃圾清掉"，
同时说明 entry/build 与 .hvigor 是纯产物、可随时删（冷构建 ~8s）。
2. **hvigorw 绝对路径**：仓库里的 ./hvigorw 是符号链接，启动脚本按
$(dirname $0) 定位，会报 File not found: <repo>/cmd/ohos/hvigor/bin/hvigorw；
统一改用 <command-line-tools>/bin/hvigorw（本机 /opt/huawei/command-line-tools/bin/hvigorw）。
3. **运行时验证清单**：把"构建通过 ≠ UI 行为不变"这件事写进仓库而不是留在邮件里
（流式对话/思考卡与工具卡/附件上传/设置与设备与插件的二级页/宽屏分栏），
并注明无提权环境起不来模拟器时需在真机补验证。
4. 工程结构表按前几轮拆分后的实际情况刷新（common/components/pages 新增文件与职责），
并记下"单文件 ≤400 行、页面只做壳"的约定。
无代码改动，纯文档。
2026-09-13 22:35:29 +08:00
64aa019046
refactor(ohos): DevicePage 560→307 行（入口列表/四个面板/模型拆分）
...
- common/DeviceModel.ets（73）：device_id 兜底（桥 id 优先 → 持久化 → 生成并落盘，
顺序与原 aboutToAppear 一致）、/device/online 响应解析、四个二级页路由 id
- components/DeviceRootEntries.ets（92）：一级入口（本机/通道两组 NavRow 列表）；
宽屏高亮自己读 AppStorage 的 isWideScreen，页面只给 activeSub 与 onOpen
- components/DevicePanes.ets（316）：DeviceLocalPane（基本信息 + 授权开关）、
DeviceCapsPane（能力清单）、DeviceGatewayPane（网关信息 + 刷新）、
DeviceListPane（在线设备列表）、DeviceKvRow；每个面板自带 SubPageLayer
页面保留导航栈、openSub/closeSub、授权开关、toast、refreshDevices 与
SubDestination 分发。所有文案、图标、颜色、过渡与失败分支逐字保留；
面板内容多了一层无 padding 的 Column 根节点（@Component 的 build() 只允许
一个根），宽度 100% + Start 对齐，与 SubPageLayer 内容槽的布局一致。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:34:20 +08:00
3f3b9bf693
refactor(ohos): DeviceBridge 409→296 行（协议类型与帧构造移到 BridgeProtocol）
...
- common/BridgeProtocol.ets（168）：hello/bind/cmd_result/cmd_data_start/
cmd_data_end/event/status 七个消息结构、CHUNK_SIZE、BridgeCmdHandler 回调类型，
以及 bridgeHelloFrame / bridgeBindFrame / bridgeResultFrame /
bridgeDataStartFrame / bridgeDataEndFrame / bridgeEventFrame /
bridgeStatusFrame / bridgeChunkSlices 八个纯构造/切片函数
- common/DeviceBridge.ets（296）：只剩 socket 生命周期、重连代际、绑定状态机
与命令分发
**DeviceBridgeClient 的对外方法名与签名一字未改**（isConnected / getDeviceId /
setCmdHandler / setStateListener / connect / updateAuthorized / disconnect /
sendResult / sendDataChunked / sendEvent / sendStatus / send），
`send*` 仍是"拼帧 + 发出去"两步，拼帧那一步搬走；分块发送的
"start → chunks（失败即 break）→ end"顺序与 `bytes.slice` 语义保持不变。
外部只有 deviceBridge 单例被 import（BridgeRouter / DeviceBridgeSession /
DevicePage），无其它符号依赖。
验证：hvigorw assembleHap BUILD SUCCESSFUL；diff 中 DeviceBridge.ets 无
状态机/回调/重连逻辑改动。
2026-09-13 22:28:53 +08:00
0b019f0d2b
refactor(ohos): Attachment 463→344 行（纯函数与字节解码移出 components）
...
- common/AttachmentMeta.ets（106）：parseAttachment / attachmentFromChannelOutput /
fileNameOf / formatBytes / oneDecimal / extLabel / sanitize，纯函数无平台依赖
- common/AttachmentImage.ets（37）：loadPixelMap（沙箱 file:// 与远端 /files 两条路径）
components/Attachment.ets 只留 UI：AttachmentCard 与 AttachmentDetailContent。
**两者的导出名、@Prop 形状与 import 路径均未变**（ChatPage 仍从
'../components/Attachment' 取 AttachmentDetailContent），组件内部的布局、
过渡、提示文案与失败分支逐字保留，仅函数体搬走。引用方 5 处 import 路径同步更新。
验证：hvigorw assembleHap BUILD SUCCESSFUL；diff 中 Attachment.ets 只有
"-删除纯函数 + import 改写"，无属性/布局改动。
2026-09-13 22:27:34 +08:00
7d7377a47e
refactor(ohos): ChatPage 1962→207 行（状态机/SSE/气泡/输入区拆分）
...
- common/ChatStore.ets（388）：消息数组、分页游标、新消息入场标记、
SSE 连接与重连、防抖刷新（50ms）统一成一个单例状态机
- common/ChatSse.ets（192）：SSE 事件 → 状态的翻译层，逐分支照搬
channel_output/agent_output/reasoning/delta/tool_call/stage/agent_error/
sync_required；通过 ChatStreamSink 接口写入，避免与 ChatStore 形成循环依赖
- common/ChatSession.ets（176）：POST /chat 与 POST /chat/file 的发送、
超时兜底、POST 响应与 SSE 的合并判定
- common/ChatFormat.ets（223）：mime 推断、ForEach 键 structSig、工具卡
状态/颜色、渠道判定与头像配色
- common/ChatHistory.ets（96）：历史载荷与 tool_calls 解析
- components/ChatBubble.ets（247）：气泡（头像/渠道名/思考卡/工具卡/附件卡/正文）
- components/ChatToolCard.ets（253）：思考卡 + 工具卡
- components/ChatStream.ets（210）：消息列表 + 顶栏遮罩 + 底部淡出 + 触顶懒加载
- components/ChatComposer.ets（357）：输入行、选图/选文件、沙箱落盘、发送
- components/ChatAttachBar.ets（139）：加号菜单 + 待发送附件条
响应式语义刻意保持不变：数组不进 AppStorage，改用自增版本号 K_CHAT_REV
通知订阅组件重取快照（ChatStream 把它镜像进 @State messages，ForEach 每次
拿到的仍是新数组引用，与拆分前 this.messages = this.messages.slice() 等价）；
structSig 仍不含 content，正文靠 MarkdownView 的 @Prop 流式更新；
markNew 仍不切片、入场动画交给紧随其后的 refresh()；
animateTo 只能存在于组件里，所以折叠翻转的动作留在 ChatStream 内。
验证：hvigorw assembleHap BUILD SUCCESSFUL；SSE 各分支、ensureToolCall、
markNew、sendChat/sendWithAttachment 的守卫顺序均与原实现逐条比对过，
守卫从"页面方法内"移到输入区组件时保持了原有先后（连接判定先于清空输入）。
2026-09-13 22:19:05 +08:00
8ea7a2a11e
refactor(ohos): SettingsPage 1463→389 行（模型/条目卡/四个面板拆分）
...
- common/SettingsModel.ets（313）：设置载荷解析、分类归并、分页切片、
路由常量，纯逻辑无 UI
- components/SettingsEntryCard.ets（215）：单条设置卡（值编辑/保存）
- components/SettingsRootEntries.ets（100）：一级入口行 + 状态汇总卡
- components/SettingsHome.ets（95）：一级页壳（顶栏/浮层/提示条）
- components/ConnectionsPane.ets（347）：后端连接 CRUD（自带二级页壳）
- components/AppearancePane.ets（265）：主题/背景/透明度（自带二级页壳）
- components/BackendSettingsPane.ets（172）：分类与条目两个二级面板
页面保留 @State 集合、加载/保存编排与 SubDestination 分发；数组仍走
@Link 直传（未引入 AppStorage 数组）。相册选择、重启前台桥等既有行为
与提示文案逐字保留。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:18:56 +08:00
a45f742339
refactor(ohos): PluginsPage 995→374 行（接口/状态/列表/详情/浮层拆分）
...
拆分方向按职责切，页面只留导航与数据编排：
- common/PluginApi.ets（174）：fetchPluginRows / fetchPluginDetail
- common/PluginStatus.ets（78）：状态判定、文案、颜色、副标题
- components/PluginListView.ets（166）：列表卡 + 列表
- components/PluginDetailPane.ets（291）：详情面板
- components/PluginsOverlays.ets（65）：安装表单
- components/ToastBar.ets（48）：提示条，PluginsToast 与 SettingsPage 的
toast 合并成这一个组件（此前两处各写一份）
UI 结构与文案逐字保留（含 92%/layoutWeight 等既有布局修法）。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:18:49 +08:00
0c833bdc33
refactor(ohos): StaticMarkdown 604→332 行（Markdown 解析抽到 common/MarkdownParser）
...
把"文本 → 块/片段"的纯解析逻辑（MdBlock/MdSpan、parseBlocks、parseInline、
表格/分隔线/有序列表判定）整体搬到 common/MarkdownParser.ets（282 行），
StaticMarkdown.ets 只留 StaticMarkdownView 组件（332 行）。
解析规则逐字保留，未改任何排版行为；MdBlock/MdSpan 原本只被
StaticMarkdown.ets 使用（唯一引用方是 components/MarkdownView.ets，
它只用 StaticMarkdownView）。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:18:43 +08:00
608fff2315
refactor(tooldefs): buildToolDefs 614→273 行（抽 toolDef 助手，schema 形状不变）
...
原实现每条工具都是 4 层嵌套的 map[string]interface{} 字面量（约 20 行/条），
40+ 条堆成 614 行的巨型函数。新增 toolDef(name, desc, props, required...)
助手消除外层样板；所有 name/description/properties/required 文本**逐字保留**
（用 go/ast 定位原样搬迁，非重新键入），schema 形状与 JSON 输出不变。
验证：go build ./... / go vet / go test ./internal/agent/core/ 全绿；
AST 实测 614→273 行，非测试函数 ≥300 行数由 4 降到 3。
2026-09-13 22:17:45 +08:00
9d53a79d0d
fix(lua): 同步注入在 Lua 中明确报不可用（避免自锁）+ 文档/mock 同步
...
sdk.inject_input_sync / *_opts / inject_input_media_sync* 在 Lua 里必然自锁：
Lua 代码只在 Start/工具/阶段/输出/事件回调中执行，这些路径都持有 plg.mu，
而同步注入要等本轮回复（回复路径上的回调又需要同一把锁）。原实现会挂死
直到超时；现改为立即返回明确错误，并在中英文 PLUGIN_DEV 里标注不可用 +
指向 Go 插件/异步注入。mock sdk.lua（SDK 仓为事实源）同步为同样的错误语义。
新增 TestLuaSyncInjectUnavailable 钉住不挂死。
2026-09-13 21:59:23 +08:00
6abdce16aa
fix(resident): CreateResident 注册入站 inputch 后加 defer 回滚
...
注册点与 residents 登记之间当前无可失败步骤，但缺回滚路径就是 child/<id>
残留那只 bug 的另一条入口。加 registered 标志 + defer：未走到成功返回就注销。
2026-09-13 21:59:10 +08:00
2a0e3bd3a8
fix(io): ChannelRegistry 补 UnbindOutputTarget，Unregister 清理 outputTargets
...
outputTargets 只增不减：Unregister 一个 inputch 后，指向它的输出目标登记仍
留在表里，ResolveOutputTarget 会继续把消息路由到已不存在的 agent/inputch。
与刚修的驻留 inputch 残留同属「注册未注销」类。现补 UnbindOutputTarget
（幂等），并让 Unregister 顺手清掉显式绑定与同名回退两种目标登记。
2026-09-13 21:59:10 +08:00
08ac63af49
chore(lint): 加 .golangci.yml（funlen/gocyclo/lll/dupl，warn-only）+ make lint-full
...
main 上曾有 4 个 >=300 行函数、12 个 >=200 行函数；没有复杂度 linter 是它们
长期存活的直接原因。先以 warn-only（issues.exit-code:0）立阈值、只出清单，
历史债下降后再收成硬门禁。测试与 testdata/third_party 排除长度类规则。
2026-09-13 21:59:10 +08:00
0391ea4c92
fix(lua): events.subscribe 改用内部 Subscribe + 订阅生命周期（修死锁/use-after-close）
...
上一版 Lua 对齐引入的 sdk.events.subscribe 有两个真问题，本提交修掉：
1) 用了公共 SDK 的 Events()，但本内核从未注入 event subscriber
（SetEventSubscriber 全仓无调用点），拿到永远是 nil ⇒ subscribe 只会
返回 "events unavailable"。改用内部 SDK 的 s.Subscribe——内置插件走的就是
这条路径（cli/webui/skillmgr 全用它）。
2) 自死锁：subscribe 会在 Lua 的 plugin.start(sdk) 回调里被调用，而
luaPlugin.Start 正持有 p.mu；原实现在 subscribe 里再 lock p.mu 追加 subs，
不可重入 ⇒ 测试实测 30s 超时。改用独立的 subsMu。
3) use-after-close：Stop 会 Close LState，但事件订阅此前无人取消，残留回调
再触发就会碰已关的 L。现在：Stop 先（不持 p.mu，避免与 Bus.Publish
锁序反转）取 subsMu 取消全部订阅，再置 closed 并关 L；事件回调持 p.mu 后
先查 closed，已进入等锁的旧回调会直接返回。
4) plugin_mgr 访问补 nil 保护（部分单测构造的 SDK 不含 pluginMgr）。
回归：TestLuaEventsSubscribeAndStopCleanup——订阅后 Publish 命中、Stop 后
再 Publish 不 panic。全套 Lua 测试在 -race 下通过。
2026-09-13 20:33:13 +08:00
eadda42b6d
fix(resident): 销毁驻留子时注销其入站 inputch（child/<id>）—— 修登记表脏数据累积
...
根因：residentInboundChannel 在 create 时把 child/<id> 登记进共享登记表
（Plugin=resident, Owner=父），但 teardownResident 只把划入的 inputch
（如 timer）归还为未分配，从未注销这条入站登记。于是每次 create/destroy
都在登记表里留下一条脏记录，且随次数单调累积。
实测（HomeAgent 侧，HΔ-Kernel v1.3.10 / 0ad3e6d）：
resident_agents destroy 之后，input_channels by_agent 仍列出 child/<id>，
归属 main；而 HomeAgent 没有任何工具能单独注销 inputch，只能重启 homed 清。
修法：teardownResident 里用纯函数 inboundChannelName 算出名字并 Unregister。
不能复用 residentInboundChannel——它有重新登记的副作用。
该路径同时覆盖 destroy / reclaim / StopResidents（父退出）。
测试：TestResident_LifecycleAndNoOrphans 增加两条断言——销毁后与父退出后
child/<id> 都必须从登记表消失。
2026-09-13 20:19:37 +08:00
b87a8f71ea
feat(lua): Lua 插件桥全量对齐 SDK 1.3.0（媒体/注入标志位/优先级/事件/通道注销）
...
内核 Lua 桥（internal/plugin/lua_plugin.go）此前停在 v0.8.0 时代能力面，
1.1/1.2/1.3 新增能力只在 Go 侧存在，而 PLUGIN_DEV.md 宣称『能力完全对齐』。
本补丁把 Lua 侧补齐到与公开 SDK 1.3.0 对齐：
- 1.1 媒体：memory.commit 支持 sentence_text/media_digests；
doc.insert_with_media + attachments；text_memory.append attachments；
set_tool_blocks / inject_input_media(_sync) / inject_interrupt_media。
- 1.2 注入语义：inject_input_sync(_opts)、六个 *_opts 变体
（no_memory/context_policy/cleaner_name/priority）；
ToolDef/ChannelDef 解析 context_policy。
- 1.3 优先级与动态通道：priority 常量透传；unregister_output_channel。
- StageContext 暴露 reasoning_content/context_msgs/token_usage/memory/extra/errors。
- 新增 sdk.events.subscribe 与 sdk.plugin_mgr.*。
- sdk.lua mock 同步（单一事实源在 SDK 仓 sdk/lua/sdk.lua，内核副本由
third_party/homeagent-sdk/scripts/sync-lua-sdk.sh 同步）。
契约测试（lua_surface_test.go）：
- 守住内核内嵌 mock 与 SDK 仓事实源一致；
- 守住 mock 承诺的每个函数都有运行时 RawSetString 绑定；
- 覆盖 opts/media/attachments 解析与 context_policy 透传。
文档：中英 PLUGIN_DEV.md 的 Lua API 表补齐并改为『对齐至 SDK 1.3.0』。
2026-09-13 19:56:32 +08:00
d3f6d3cbee
docs: 记下 gitcode 附件的"同名只写一次"硬约束（校验和首次没传全就永远补不回来）
...
实测证据：同一个名字（ZZprobe.txt）传两次不同内容，下载端始终返回第一次那份；
资产列表里该名字只有一项。删除接口走不通 —— release JSON 不含 `id`，附件列表接口 404，
`DELETE .../releases/<tag>/attach_files/<name>` 返回 400「参数类型错误」（要数字 id）。
后果（1.3.1–1.3.10 全都踩了）：首次上传 `SHA256SUMS` 时只有 linux/amd64 四个产物，
之后补 arm64/darwin/win 时"合并后重传"**全部无效** —— 线上那份至今仍是 4 项、带 `./` 前缀，
arm64/darwin/win 的产物没有校验依据。
⇒ 纪律：**打包全部平台后才第一次上传校验和**；分批上传时先传产物、最后传校验和，
校验和只传一次。补救只能换名（`SHA256SUMS.complete`）或重建 release（需重传全部产物）。
2026-09-13 18:50:06 +08:00
4b814fa418
fix(packaging): package-windows.sh 支持 NSI 覆盖 + payload 预检
...
上一步失败：`File "..\..\build\linux-payload\*.*" -> no files found`。
原因：NSIS 的 `File` 路径**相对 .nsi 所在目录**解析，而我用了主仓的 installer.nsi
（它去找主仓的 build/linux-payload），payload 却 stage 在 tag 的 worktree 里。
改法：`NSI` 可覆盖 —— 在 tag 的 worktree 里构建时用**该 tag 里的** installer.nsi
（与产物同源，也正是可复现发布该有的样子）；另加 payload 空载荷预检（空载荷=装不上，
必须直接失败而不是打出一个没内容的安装器）。
2026-09-13 18:29:13 +08:00
c9960fa25f
docs: 补两条流水线纪律（脚本必须 set -e；tag worktree 里的驱动脚本）
...
今天连踩两次，都是"脚本本身"的问题而不是打包逻辑的问题：
1. **没 `set -e`**：`package-windows.sh` 在 tag worktree 里找不到（新脚本只在 main），
bash 报 No such file or directory 之后**流程照旧往下走**，把只含 4 项的校验和
传上去覆盖了原本覆盖 10 项的那份 ⇒ 只能把产物下回来重建。
2. **驱动脚本不在 tag 里**：发布件在 tag 的干净 worktree 里构建，而刚补的脚本还没进 tag。
⇒ 让脚本支持 `DIST_LINUX` / `BUILD_DIR` / `DIST_RELEASE` 覆盖，用"主仓脚本 + 产物目录
指向 worktree"来解；文档写清这条约束。
同步进发布技能的同名小节（这两条和"分批上传要全量重算校验和"是同一类：**校验和的完整性
比产物本身更容易被流程吃掉**）。
2026-09-13 18:23:22 +08:00
43e240dc47
fix(packaging): package-windows.sh 支持 DIST_LINUX/BUILD_DIR/DIST_RELEASE 覆盖
...
我在 v1.3.10 的 tag worktree 里调这个脚本，而它提交在 main（tag 里当然没有）⇒
`No such file or directory`；又因为脚本没加 `set -e`，它继续往下跑，把只含 4 项
（linux amd64）的校验和传上去，覆盖掉了原本覆盖 10 项的那份。
目录可覆盖后就能「用主仓脚本、产物目录指向 worktree」，两个坑一起消掉。
2026-09-13 18:22:33 +08:00
7e27c3bcf6
feat(packaging): 补 Windows(WSL) 安装器的驱动脚本，并按变体定向 payload
...
用户要求：**Windows 的 homed 安装包应当是往 WSL 里安装**。口径本身早已落地
（installer.nsi 注释 + install-via-wsl.ps1 + build.sh 的 WSL 分支），但缺两样东西：
1. **没有驱动脚本**：`build.sh` 里没有 `makensis`，仓库里也没有任何脚本调用它 ——
build/ 下那几个历史 .exe 是手工打的。新增 `deploy/packaging/package-windows.sh
<server|client|full> [arch]`：按变体准备 payload、必要时编 waiter.exe、调 makensis、
把产物落到 dist/release。
2. **payload 不分变体**：`build.sh` 的 `stage_linux_payload` 把 dist/linux 下所有 deb+tar
全塞进 payload ⇒ 现在 server/full 的 deb 各带 ~719MB 模型，任何变体的安装器都会
膨胀到 ~2.4GB。而 WSL 侧脚本只取 payload 里的**第一个** `.deb`
（install-via-wsl.ps1:141）⇒ 按变体只放对应的那一个包。
同时：client/full 需要 Windows GUI payload（HAS_GUI=1），本机无 electron-builder 时
**明确失败并给出命令**，不产出"装完没有界面"的半残包。
docs/git-branching.md §七.5 补上这条口径与三条命令。
2026-09-13 18:13:04 +08:00
86bcea7955
docs: 补「分批上传时后一轮必须全量重算 SHA256SUMS」
...
实测踩到：v1.3.10 先传 amd64 的 9 个资产（含只覆盖 amd64 的 SHA256SUMS），
后补 arm64 时按 arm64 那 4 个文件重算 ⇒ 同名附件覆盖 ⇒ amd64 的校验和消失。
校验和是附件的唯一完整性依据，丢了等于没有校验。已同步到技能的同名小节。
2026-09-13 17:35:02 +08:00
7824aabff2
fix(prompt): 去掉"每轮只能发一次 output_send"的凭空限制；type 缺省即 text
...
用户现场指出：**qq 插件的输出通道判据太严了**（那条判据在插件侧，已单独修：
`output_send__qq` 不再受"当前会话身份"限制）。同时内核提示词里还有一条**同类的凭空限制**：
「每轮对话**通常只需调用一次** output_send__{通道名} 即可完成回复。
仅在内容确实超过单条消息长度上限（如 >4000 字）时才拆分为多条」
可设计上输出是 agent 的**主动调用**：收到一次输入后，可以往**任意（已授权的）通道**
发**任意多次**（分段播报、先回执后结论、同时通知多个通道都合法）。这句话会让模型
自己收起合理的多次输出 —— 而且它不是任何机制的要求，只是当初为压 output-loop 写的
措辞（真正的防环机制是"回执只回 ok、不回传富结果"，那条保留）。
改法：
- 提示词改为明确授权：**输出次数与目标通道由你自己决定**，没有「一轮只能发一次」的限制；
只保留两条真话：单条长度上限（超长拆完整段落）、别反复重发**完全相同**的内容。
- `output_send__*` 的 `type` 参数改为**可选**（缺省 text）：判据该拦的是"不知道发什么"，
不是"没写众所周知的默认值"——此前缺 type 会直接失败并让模型重试一次。
判据 3 条（新增 `output_rules_test.go`）：提示词不得含输出次数限制且必须显式授权 /
省略 type 时按 text 发送成功且 schema 的 required 只有 payload / 空 payload 仍被拦。
(cherry picked from commit 58e927b08c
2026-09-13 16:04:16 +08:00
6f16355603
chore(sdk-mirror): qq 插件 1.4.1（输出工具不再受当前会话身份限制）
...
镜像 SDK 仓的插件修复：被子的中断唤醒的一轮里，父带齐 meta 调 output_send__qq 也被
「可信 QQ 会话身份不完整」拒掉；输出改为先放行（目标由 meta 决定），读取类工具仍限当前会话。
2026-09-13 16:03:28 +08:00
bcf86064d7
fix(resident): 子的「轮次」一直显示 0 —— info() 根本没填 Rounds
...
现象（用户线上联调实录 + 我复验）：父侧 `resident_agents` 列出 `输入ch=[timer] 轮次=0
处理表=2` —— **处理表已有两条记录，轮次却是 0**，自相矛盾，容易被读成"子没干活"。
根因：`residentChild.info()` 构造 `ResidentInfo` 时**从来没有填过 Rounds 字段**
（结构体里有这个字段，于是永远输出零值），不是计数漏加。
改法：`Rounds = 已执行轮次数`（调度器执行计数，单调不减）。新增 `Agent.roundsExecuted()`
并写明为什么**不能**用 inputch 处理表条数当轮次：那张表记的是"当前上下文窗口内"的轮次，
压缩会清空（设计 §8.3）—— 用它会让父看到轮次倒退。
判据：inputch 路由测试里补一条断言 —— 子处理完输入后 `info().Rounds > 0`。
(cherry picked from commit 28ad25f2f0
2026-09-13 15:41:07 +08:00
f876be6f63
fix(scheduler): inputch 划给子后输入只流向子 —— 补上「进内核之前」的输入路由
...
用户指出的语义（设计稿 §4.1 早已写明）：
**inputch 是可分配资源**，「路由发生在**进内核之前**」—— 划给某个 agent 后，
该通道的输入**只流向那个 agent**；outputch 不同，授权是**非独占**的，
父依旧可以通过它发送内容。
而代码里 inputch 划拨只做了**登记**，没有做**路由**：
- 插件注入输入的 io 是**根 agent 的**（`cmd/homed` 里 `pluginReg.SetIOManager(iom)`）；
- 唯一消费输入的是「该 io 自己的调度器」（`scheduler.go` 读 `a.io.InputChan()`）；
- `ChannelRegistry.Assign` 只把 Owner 写进登记表，**没有任何转发动作**。
⇒ 现场表现（用户线上联调）：子挂 `inputch=[timer]`，**timer 的输入却打在父身上**
（日志 `[agent] interrupt from timer/timer`），子侧 `轮次=0` 永远不动。
登记表里的 Owner 于是沦为标签。
改法（按 §4.1 把路由放回"进内核之前"）：
- `IOManager` 增加 `InputRouter`（`SetInputRouter`），并把**五处直接入队**收口到
`deliverInput`：`InjectInput` / `InjectInputSync` / `InjectInputTo` /
`InjectInputSyncTo` / `InjectInterrupt`（排队与中断两条路都过路由）。
- 内核注入路由器 `Agent.routeInputByOwner`：查 inputch 的 Owner —— 归自己/未分配 ⇒
本内核处理；归自己的某个驻留子 ⇒ `DeliverRouted` 交给它（**不再进父的队列**）；
归一个不存在的 agent ⇒ **不吞输入**，父兜底 + 留痕（吞掉输入比多处理一条更糟）。
- `DeliverRouted` 是"已路由"的投递口，不再二次路由（避免成环）。
- 同步输入的 `ResponseCh` 随事件一起走 ⇒ 回答由持有者写回同一回程（§4.3）。
判据（新增 6 条）：
- io 层：被接管时排队/中断都**不入本内核队列**（且中断确实经过路由）/ 放行与未设
路由器时与历史行为一致 / `DeliverRouted` 不再触发路由
- 内核层：划给子的 inputch 输入进**子**（子 Executed>0）且**父 Enqueued 不变** /
归属到不存在的 agent 时父兜底（不吞）/ 未分配的 inputch 仍归父
(cherry picked from commit 3c263ed0b4
2026-09-13 15:35:59 +08:00
cd7aebe224
docs(resident): 补写「子的 io 通道视图 = 对父的实时回退」（N3 落地口径）
...
输出通道在 io 层就是 Device，由插件登记在父的 IOManager 上；驻留子只共享了 inputch
登记表 ⇒ 子侧 childIO 空壳（现场：子调 output_send__cli 被判「通道不存在或不可用」）。
文档写清：继承方式（SetParentIO）、四个受影响的方法、为什么是实时回退而非快照、
以及回退只解决看得见、授权仍在白名单之后。附线上实测结果（result: ok）。
2026-09-13 15:16:58 +08:00
fb2f3a5875
fix(resident): 驻留子继承父的输出通道 —— 修「子侧 childIO 空壳、子不会发消息」
...
现场（用户在线上跑驻留子联调，日志实录）：
父 agent 侧「通道装载完整」，子 `demo-resident` 侧 `childIO` 是**空壳**：
子的 `output_list_channels` 为空、`output_send__<通道>` 一律被判
「通道 [X] 不存在或不可用」，连 `output_send__*` 工具都不生成 ⇒ 子不会发消息。
根因：**输出通道在 io 层就是 Device**，而它们由插件登记在**父**的 `IOManager` 上。
`SpawnResident` 给子建的是全新 `IOManager`（它确实该有自己的输入入口与 outputCh），
却只共享了 inputch 登记表，**没有继承设备/输出通道视图**：
- `executeOutputSendTool` → `a.io.GetChannelCapabilities(ch)` 查的是 `devices[ch]` ⇒ 0
- 投递路径 `a.io.GetDevice(ch).Execute("output", …)` ⇒ nil
- 工具面 `tooldefs.go` 从 `a.io.ListChannels()` 生成 `output_send__*` ⇒ 空
改法：给 `IOManager` 增加**上级回退**（`SetParentIO`）——驻留子创建时把自己的 io 挂到
父的 io 上，`GetDevice` / `GetChannelCapabilities` / `ListChannels` / `ExecuteTool`
在自己没有时回退到上级。
为什么是**实时回退**而不是创建时复制快照：设备随资源生灭（远程设备上线/掉线以分钟计，
现场日志 60 秒一个来回），复制出来的表转瞬即过期；而回退永远与父一致。
**授权不受影响**：回退只解决"看得见"，能不能用仍由各自的 `AllowedOutputs` 白名单把关
（`executeOutputSendTool` 的授权闸 + 工具生成时的过滤都在白名单之后）；
自己的登记优先，子可以覆盖/屏蔽同名通道。
判据（新增 5 条）：
- io 层：无上级时行为与以前完全一致 / 挂上级后看得见 / **实时**（父新登记立刻可见、
注销立刻不可见）/ 同名自己的优先且不重复列出 / `ExecuteTool` 同样回退
- 内核层：子看得见父通道 + 真能发出（父通道收到 1 次 output）/ 白名单外被拒且未送达 /
子工具面只生成授权通道（含 `_help`）/ 父后登记的通道立刻可见 / 默认即完整授权
(cherry picked from commit 88ae0f0a14
2026-09-13 15:09:44 +08:00
84198ad5e1
docs: 两仓文档对齐当前版本状态 + 补发版产物清单；同步 SDK meta 路牌
...
用户指出：SDK 版本又带 patch 位、agent 自称 1.0.3、两个仓库文档都没更新。
docs/git-branching.md：
1. **§三 状态表**重写（停在 2026-09-12：main 还写 1.3.0、release/v1.2.x 还被当成"本条发布线、
尚无 tag"、SDK main 还写 1.2.0、完全没有 release/v1.3.x）。现按事实更新，并写明
`v1.3.0` 是已撤回的坏 tag。
2. **§2.3** 增补：发布线的 `meta.Version` 必须跟着该线已发的最后一个 patch 走；
只用 `-ldflags -X` 打版本而不改源码会让二进制与源码对不上账（1.3.1–1.3.4 就是这么打的）。
3. **反例表**补两行：人格文本在**播种时**固化版本（生产实例自称 v1.0.3）、
发布线路牌不随 patch 推进 / 给 SDK 误发 patch tag。并澄清"插值"必须在**渲染时**，
把算好的结果固化进配置库与写死没有区别。
4. **§七.5 新增"发版产物清单（可复现）"**：核心仓（tar.gz + 3 个 deb + SHA256SUMS，
校验和必须在全部产物生成后统一算）、SDK 仓（5 平台 hmapdev + SHA256SUMS）、
上传脚本的用法与两个坑（release 条目必须先存在；`hmapdev_*` 无扩展名不会被自动识别）。
起因就是本次"推了 tag 却没建 release、没打包"——推 tag ≠ 完成发版。
third_party/homeagent-sdk/meta/meta.go：镜像 SDK 仓 main 的路牌（1.3.0 → 1.4.0）与
版本语义注释更新（1.3.0 已定版 ⇒ 该号归发布线，main 推进）。
2026-09-13 14:41:24 +08:00
10b68ab4e0
chore(meta): main 的版本路牌推到 1.4.0（1.3.0 已归 release/v1.3.x 所有）
...
规范 §2.1 / §七.4：切出 release/v1.3.x 后，1.3.0 就归发布线所有，main 立即推进到
下一个未发布中版本。此前停在 1.3.0 属遗漏 —— 会让 main 构建出来的二进制自称已发布版本。
2026-09-13 14:34:46 +08:00
960e765349
fix(config): 播种时不再把版本号写进人格文本 + 存量实例一次性去版本化
...
用户发现：agent 自报版本 **1.0.3**，内核早已 1.3.x。
根因（两层）：
1. `SeedDefaults` 当年用 `fmt.Sprintf("…HΔ-Kernel v%s…", meta.Version)` **在播种时**
就把版本写进了 `core.agent.system_prompt` —— 装完即冻住，之后每次升级都不会
去改配置里的文本，于是实例终生自称装机那天的版本。默认模板用 meta.Version
插值本是"不写死"的做法，但**播种 = 把插值结果固化**，等于写死。
2. `core.agent.personal_prompt`（新人格机制）本身是对的（DefaultPersonaPrompt
无版本字面量，由 TestDefaultPersonaPromptHasNoVersionLiterals 钉住），
但旧键仍在系统提示词里说话，模型就照抄旧键的版本。
改动：
- **不再播种** `core.agent.system_prompt`：留空 → 组装时取 cmd/homed 的内置底座
提示词；人格由 personal_prompt 承载。全新安装不再预置会腐坏的文本。
- 新增 `migrateSeededSystemPrompt()`（在 SeedDefaults 最前，故不被播种标记早退）：
只对"当年那段播种模板"（前缀 + `HΔ-Kernel v<数字>` 字面量双判据）做
`v<数字>` → `v{{kernel_version}}`；用户自己写的人格卡一律不碰。
一次性标记 `core.internal.system_prompt_deversion_v1` 守住幂等 ——
幂等语句不等于语义幂等，重复执行会把用户后来手写的版本号也改掉。
- 与 v1.3.5 的占位符展开配套：占位符在组装系统提示词时按真实构建展开。
回归判据 4 条（`prompt_migration_test.go`）：存量卡被去版本化且正文不动 /
迁移只跑一次 / 用户自写卡不动 / 全新安装不播种该键。
2026-09-13 14:34:44 +08:00
446b63b1ce
fix(prompt): 系统提示词支持版本占位符 —— 人格卡不再写死版本号
...
现象（用户发现）：agent 向用户自报版本是 **1.0.3**，而内核早已 1.3.x。
根因：**人格卡是配置项**，线上 `core.agent.system_prompt` 里写死了
「HΔ-Kernel v1.0.3 型号的家政型 AI 管家助手」——那是当年装机的文本，
之后每次发版都不会去改它，模型于是照抄给用户。默认模板用 `meta.Version`
拼接（`registry.go` 的 `fmt.Sprintf`）所以一直是对的，**只要被自定义过就会漂**。
修法：在 `buildSystemPrompt` 组装处展开占位符，让这类文本跟随真实构建：
{{kernel_version}} → meta.Version（如 1.3.5）
{{kernel_commit}} → 构建 commit
{{sdk_version}} → 所兼容 SDK 版本（如 1.3.0）
- 未知占位符**原样保留**：写错了要看得见，而不是被静默换成空串；
- 不含 `{{` 时原样返回（提示词在热路径上）；
- 覆盖所有路径：主 agent 与驻留子都经 `buildSystemPrompt`，
`persona_set` 写入的文本同样在读取时展开（存的是模板，不是渲染结果）；
- 配置项描述里写明可用占位符，引导用户别再写死版本。
回归判据 `TestExpandPromptVars`：展开正确 / 内置占位符不残留 /
线上真实人格卡文本能被纠正 / 未知占位符不被吞 / 无占位符不改写。
2026-09-13 14:34:44 +08:00
8a47d72287
chore(sdk-mirror): a2a 1.3.0→1.3.1、acp 1.2.0→1.2.1 的 plg.json 跟上 SDK 仓
...
SDK 仓 11303e3 升了两个示例插件的版本（补 RegisterInputChannel 后按插件自身语义升 patch），
外层仓镜像里这两个 plg.json 忘了同步 —— 镜像与源头不一致会让"装的是哪个版本"对不上账。
2026-09-13 14:30:56 +08:00
4dcfee30f2
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
6924865077
perf(memory): 静态词向量改用 float32 存储（省 ~0.65GB 常驻）
...
生产实测：`[static_embedder] loaded 200000 words`(zh) + `378151 words`(en) = 57.8 万词 × 300 维，
`map[string][]float64` 光向量本体就 **1.29GB**（外加 map 开销 ~0.1-0.2GB），占 homed
4.14GB RSS 的约三分之一。
源数据（fastText 文本格式）本身就是 float32 精度，用 float64 存没有任何收益：
- `words map[string][]float32` / `unkVec []float32`；
- 加载时按 `ParseFloat(..., 32)` 解析（与源精度一致）；
- 相似度累加仍在 float64（`sum []float64`，读时提升），计算精度不受影响。
⇒ 向量本体 1.29GB → 0.65GB，**省 0.65GB**。（与配置侧 `#topN` 可叠加：
生产把两份 vec 各限 5 万词后，向量降到 ~0.22GB。）
防复发：`TestStaticEmbedder_VectorMemIsFloat32` 用**编译期类型断言**
（`var typed []float32 = vec`）+ 字节数断言（词数×维数×4）钉住 —— 改回 float64 会直接编译失败。
验证：`go test ./internal/memory/ ./internal/agent/core/ ./internal/nlp/` 全绿。
2026-09-13 14:09:35 +08:00
d72141fc04
fix(plugin): "只声明出站通道"的告警改为插件加载完成后判定（此前按注册顺序误报 qq）
...
## 现象
生产日志（v1.3.1 启动）出现：
`[plugin] qq 只声明了输出通道 "qq"，已按双向通道兜底登记 inputch；若要明确意图请显式 RegisterInputChannel`
用户据此问"qq 插件你没更新？"
## 查证：qq 没漏，是我的判据错了
- SDK 示例 `example/qq/plugin.go`：`RegisterOutputChannel("qq")` 在 368 行、
`RegisterInputChannel("qq", {NoMemory:true, Cleaner: inputCleaner})` 在 399 行 —— **先出站后入站**；
- 生产 `plugins/qq/plugin.bin`：版本 1.4.0，且二进制里含 `inputCleaner` 痕迹 ⇒ 确实调用了入站声明；
- 我的兜底告警在 **RegisterOutputChannel 的那一刻**判"有没有入站声明" ⇒ 对"先出站后入站"
这种完全合法的写法必然误报（a2a/acp/weather 同理）。
## 修法
告警判据从"注册时刻"改为"**插件 Start 结束后最终声明了什么**"：
- `regOutput` 只保留兜底登记（功能不变），不再告警；
- 新增 `warnOutputOnlyChannels(plugin)`，在插件加载/重载成功后统一判定：
遍历该插件**最终**声明过的出站通道，只有始终没有对应入站声明的才告警，
且措辞改为"内核已兜底登记 inputch，若这是有意为之可忽略"。
- 判据与顺序解耦后，告警才代表真实缺口（例：weather 的 `weather_out` 与
`weather_in` 名字不同，出站名从未被声明为入站 —— 那条告警就是真的）。
## 验证
- 新增 `TestWarnOutputOnlyChannels`：①先出站后入站（qq 写法）**不告警**；
②只声明出站（weather 写法）**告警且只报那一个通道**。
- `go test ./internal/plugin/ ./internal/plugins/...` 全绿。
2026-09-13 13:40:24 +08:00
62d42150b3
chore(sdk-mirror): 同步 SDK 仓 v1.3.1 的文档 —— 通道名会进 LLM 函数名（命名约束）
...
镜像文件：`third_party/homeagent-sdk/sdk/plugin.go`（`RegisterOutputChannel` 的命名约束）。
SDK 仓对应提交/tag：v1.3.1。
说明：内核 v1.3.1 的 tag 已指向功能修复提交 30c1688，本镜像提交在其之后 ——
文档镜像不参与二进制构建，故不影响已部署产物；功能与文档的对应关系见两仓 tag 说明。
2026-09-13 13:10:38 +08:00
46d5e705b6
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
b6514f25be
chore(meta): SDKCompatibleVersion 升到 1.3.0（内核已实现 SDK 1.3.0 的全部新增面）
...
SDK 1.3.0 相对 1.2.1 的公开面新增（`git diff v1.2.1..main -- sdk/` 逐条核对）：
- `InjectOptions.Priority` + `PriorityL1/PriorityL2/PriorityL3/PriorityL4`
- `UnregisterOutputChannel` + `OutputChannelUnregistrar` + `SetOutputChannelUnregistrar`
内核侧两样都已实现，故按既有先例（f868975 随"实现 SDK 1.2.0 新增方法"同步声明）在此声明：
- Priority：`applyInjectOpts` 落 payload → 调度器 `interruptLevel` 按四级中断阶梯调度，
L4 归内核自身与内核级插件；
- UnregisterOutputChannel：插件登记表的 `regOutputUnreg` + io 设备表注销
（远程设备 `device/<id>` 掉线即注销，不留死通道）。
不调新面的存量插件照旧可用（新增方法由插件调用、内核实现），无需重编。
2026-09-13 12:46:31 +08:00
1c4cad0b79
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
64e36088ec
test(kernel-stress): 把"真二进制压力测试"harness 固化进仓库（私有 netns + mock LLM + 多连接驱动）
...
本轮压测是从 /var/tmp 里现写脚本跑的，能复现才能长期用 —— 固化到这。
为什么要有它（与 go test 的分工）：单测都在进程内、参数显式给，抓不到集成面问题；
这一轮它抓到了三个只有真二进制才暴露的问题（DataDir 漏接线、插件通道未登记为
inputch、create 后子不开工），以及两处生成器缺陷（旧 SDK 导致生成工程编译失败；
模板工程从不示范通道登记）。
- `launch.sh`：在**私有 netns** 里同时起 mock LLM 与内核实例。
必须隔离的原因：生产实例占着 *:8080/*:9890/*:9876 且插件设了 SO_REUSEADDR，
同机再起一个实例会在 127.0.0.1 上与之并存绑定（首次实测抢到 9890 约 1 分钟）；
netns 里只有 lo，结构上不可能碰到生产端口。unix socket 是文件系统对象，
所以驱动脚本在 netns 外照样能连。
- `mockllm.py`：OpenAI 兼容 mock（可控延迟 + SSE 分块 + 按 `!resident`/`!notify`
标记回工具调用），让无外网也能跑、且**流式段可被中断**（压抢占路径的前提）。
注意必须实现 `do_HEAD`：内核探活用 HEAD，501 会被判不可达 → degraded → rollback 循环。
- `stress.py`：多并发连接轰炸（单连接是串行的，造不出队列压力）+ 中断线程 + 峰值采样。
- `kcli.py`：CLI socket 客户端（`/auth` → `/kernel` / 广播）。
- README：前置配置（含探活端点、rollback 关掉）、用法、指标读法、已知坑。
实测结果（详见 ed76695
2026-09-13 11:38:31 +08:00
d7cc960b0f
chore(sdk-mirror): 同步 SDK 仓 4cb3a0b —— 通道方向契约 + 示例插件显式登记 inputch
...
镜像文件（外层仓按策略只跟这些；`example/` 被 .gitignore 忽略，已跟踪文件用 -f 提交）：
- `sdk/plugin.go`：RegisterInputChannel/RegisterOutputChannel 的方向契约文档
（入站 vs 出站分开登记；用哪个通道名注入就要登记哪个）。
- `example/{a2a,acp,browser,memo,calendar,rss}/plugin.go`：补 RegisterInputChannel。
未镜像（外层 .gitignore 忽略，按策略不入镜像）：
`README.md`（README*）、`tools/hmapdev/{templates.go,cmd_sdk.go,cmd_build.go}`（tools/）
—— 即"模板工程"与"`sdk install --from`"两项改动只存在于 SDK 仓，详见该仓提交 4cb3a0b。
注：这 6 个示例此前未 gofmt（`example/*` 共有 9 个未格式化文件），
本次改动文件被 gofmt 顺带规范，diff 里含格式噪音（calendar 49 行、a2a 33 行）。
2026-09-13 11:38:10 +08:00
ed76695802
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
a80ca95987
fix(lightkernel): 传统上下文落到实处 —— 子不做策略性裁剪（并修掉裁剪估算的字节/rune 单位混用）
...
用户指出实现不自洽："子 agent 是传统上下文，没有裁剪"。查证属实：子仍走
`formatMergedTimeline` 的预算裁剪、也可能走 `pruneOnInput`（既裁剪又向 doc 记忆归档）。
即"动态上下文"（父专属能力）漏进了轻量内核。
## 三处闸门（按 isLightKernel() 判）
1. **拼装预算**：新增 `contextTokenBudget(b)` —— 父用动态上下文的 `ContextTokens`，
子用**整个窗口** `MaxContext`。两个调用点都改（`stepPrepare`、`rebaseFramePrefix`；
漏掉后者时 prepare 之后的重建仍会裁，实测就是这么被抓出来的）。
2. **pruneOnInput**：轻量内核前置返回 —— 不做按相关度裁剪、不向 doc 记忆归档。
3. doc 记忆 / 整理流水线：早已由 `a.memory == nil` 关闭（N2c）。
## "不裁"的准确含义
不做**策略性**裁剪（不按相关度挑、不归档），只受"模型能收多少"这个硬上限约束；
且在撞到硬上限之前，contextfull（90% 窗口）已按 L4 上报父 agent ⇒
**丢事件的决定权在父**（压缩/回收/销毁），不在内核。文档 §16.0.0 记录三处闸门表。
## 顺带修掉的既有 bug（单位混用）
`formatMergedTimeline` 逐事件估算原来是 `len(e.Source)+len(e.Input)+40` 再 ×2 ——
`len()` 是**字节**，而 `EstimateTokens` 是 rune×2 ⇒ 中文事件被高估 3 倍：
实测 2384 字的中文事件被估成 14398 token > 8192，于是窗口还有余量也提前 break、
把更早的事件整段丢掉。改为统一走 `EstimateTokens`（对父同样生效：中文长会话不再被过早裁剪）。
## 测试
- 新增 `TestLightKernel_TraditionalContextNoTrimming`：用**记录模型实收消息**的 provider
断言"更早的事件仍在"（为什么不看 TaskFrame：`prepareInputTask` 只做前半段，
消息在 `runTaskSteps`/`stepPrepare` 才拼出来 —— 我第一版断言就打在了空帧上）；
填充量取"超过动态份额、但仍在窗口内"，从而能区分父/子两种行为。
- 新增 `TestFullKernel_StillUsesDynamicContext` 作对照（父仍用动态份额）。
全量 go test ./... 37 包 ok / 0 FAIL；-race 干净。
2026-09-13 10:36:04 +08:00
34453aefe7
test(resident): 压力规模可用环境变量放大（RESIDENT_STRESS_N / RESIDENT_STRESS_ROUNDS）
...
默认仍是 8 子 × 12 轮（CI 友好）；要跑加重压力就放大：
RESIDENT_STRESS_N=64 RESIDENT_STRESS_ROUNDS=40 go test -race -count=2 ./internal/agent/core/ -run TestResident_E2EAndStress
实测已跑：
- 24 子 × 25 轮（-race）：通过
- 64 子 × 40 轮（-race -count=2，即 5120 轮次）：通过
2026-09-13 10:25:49 +08:00
73654080f5
feat(resident): N3–N7 驻留式子 agent 全量落地（生命周期/双向投递/处理表/contextfull/e2e+压力）
...
设计：docs/zh/resident-subagent-design.md §6/§7/§8/§9/§10。
## N3 生命周期（resident.go）
- `SpawnResident`：主库**受限句柄** + 自己的 temp 实例（`LightMemory`）⇒ 子的轻量内核；
划入 inputch（登记归属）、授权输出通道、注入任务提示词；为父登记 `child/<id>` 入站 inputch；
建独立 `IOManager`（共享通道登记表）；启动子。
- `DestroyResident`：停子内核、归还划入的 inputch（回到未分配）、丢弃 temp 目录、出登记表。
- `Stop()` → `StopResidents()`：**父退出必须销毁全部子、不留孤儿**（设计 §10 硬约束）。
- `Residents()` 登记表快照；`ResidentTable(id)` 父 pull 子的处理表（不打断）。
## N4 跨 agent 投递
- 子→父：`notify_parent` → 投进父的 `child/<id>` inputch，优先级 **L3**。
- 父→子：`SendToResident` → 投进子的 inputch，优先级 **L4**；
`isKernelLevelSource` 泛化为"该 agent 的上级"（`AgentConfig.KernelSource`）⇒
只有父能在子的阶梯上产生 L4（子内部一律 ≤L3）。
- 子的 contextfull → 父侧 `raiseKernelInterrupt`（内核级事件，带子标识，父侧 L4）。
## N5 inputch 处理表
- 子持有；`inputch_note` 主动写**优先**，轮末 `autoRecordInputch` 兜底 ⇒ 每轮必有记录。
- 压缩时清表（表记的是被压掉那段窗口的逐轮处理）。
## N6 contextfull（判据修正）
❗ 初版判据是"拼好的 `f.Msgs` 估算 > 90% 窗口"，**结构上永不成立**：
`buildMessages` 拿到的 `budget.ContextTokens` 由 `targetUsage = 0.8 × 窗口` 推出，
时间线**在拼进消息之前就被预算裁过**，`f.Msgs` 封顶在 ~80% 窗口。
（初版测试用一个比系统提示词还小的窗口才勉强越线 —— 那等于什么都没测。）
现判据 = **未裁剪的积累上下文**（`a.context.Recent(0)`）超过窗口 90%：
它超过就说明下一轮必须丢事件，这正是"上下文满"。
三处置：`CompressResident`（保留语义：`TrimKeepRecent` 保留最近 N 条 + 清表）/
`ReclaimResident`（取消语义：`ExportTriples` 读 temp → 父选出要保留的 → `Commit` 进 main → 取消该子）/
`DestroyResident`（立刻销毁并移除）。
## 工具面
`resident_agents`（父，单工具多动作：list/create/send/inspect/compress/reclaim/destroy）、
`notify_parent` + `inputch_note`（子）。声明条件式：父才有前者，子才有后两者。
## 验收
`resident_test.go` 五项：生命周期与不留孤儿、双向投递（含"子的主动消息不得以 L4 出现"）、
处理表（自动写 vs 主动写优先）、contextfull + 三处置、
**压力 8 子 × 12 轮（父→子 L4 与普通输入各半）+ 双向汇报 + 父退出清理**。
全仓 go test ./... 37 包 ok / 0 FAIL；`-race`（agent/memory/plugin）干净；
压力 `-race -count=3` 通过。
2026-09-13 10:20:06 +08:00
66fb0b687a
feat(lightkernel): N2c —— 轻量内核 profile（窄接口 GraphMemory + nil 即禁用整理面）
...
按用户指出的关键点（a.memory 多数使用点属"主 agent 整理记忆"与"记忆整理流水线"，
子不该有那些路径）实现，方案见设计 §16.0。
## 窄接口：只有 Recall + Commit
新增 `GraphMemory` 接口（memoryface.go）—— 按调用方实测分类后，真正"根与子都要"的只有这两个：
- `Recall`：上下文检索 / memory_recall
- `Commit`：自动写入路径的图部分 / memory_commit
新增 `Agent.graph`（共同面）与 `Agent.graphMem()` 访问器：
- `graph` 显式为 nil 时**回落**到 `memory` ⇒ 既有"只用 Agent 字面量设 memory"的测试无需改动
（原本会出现"必须同时设两个字段"的脚坑，实测踩到后去掉了）
- 轻量内核：`graph = *memory.LightMemory`，`memory = nil`
## nil 即禁用：整理面自动消失，不需要受限包装
子的 `a.memory == nil` ⇒ 既有的 22 处 `if a.memory != nil` 关卡自动禁掉全部整理面：
- 记忆整理流水线（distill.go 的 archive/review/merge 循环）
- 记忆块 + 媒体桥（graphmedia.go / medialoop.go）
- 记忆整理工具（memory_merge / memory_delete_entity / memory_block_merge /
memory_purge / memory_edit / memory_introspect）—— 它们本就在 `if a.memory != nil` 块内
唯一拆开的一处是自动写入 `commitTriplesWithMedia`：
图部分走 `graphMem().Commit`（父落 main、子落 temp），块/媒体部分仍由 `a.memory != nil` 守卫。
`executeMemoryTool` 的读路径改走 `graphMem().Recall`；整理类 case 加 `requireFull()` 闸门，
被直调时明确报"本 agent 是轻量内核：记忆整理不可用"，不静默降级。
## 验收（3 项新测试）
- `TestLightProfile_MemoryFaceWiring`：整理面为 nil、写入只落 temp（主库无子痕迹）、
读是并集（主库实体 + temp 实体都看得到）
- `TestLightProfile_OrganizeToolsAbsentAndRefused`：整理类工具**不进工具表**；
即便被直调也明确报"轻量内核不支持"
- `TestFullProfile_KeepsOrganizeFace`：对照，根 agent 仍保留整理面与整理工具
全仓 go test ./... 37 包 ok / 0 FAIL；-race（agent/memory）干净；gofmt 干净。
2026-09-13 10:02:02 +08:00
fab7f4cb02
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
287115beea
docs(resident-subagent): 更正 N2c 方案 —— 窄接口（只剩 Recall/Commit）+ nil 即禁用
...
用户指出：a.memory 的多数使用点属于**主 agent 整理记忆**与**记忆整理流水线**，子根本不该有那些
代码路径。据此把上一版"约 20 方法的接口 + 受限包装"改成**实测分类 + 窄接口**。
按调用方实测分类（42 处）：
- A 记忆整理流水线（distill.go 10 处：archive/review/merge 循环）→ root-only
- B 记忆块 + 媒体桥（graphmedia.go 18 + medialoop.go 4）→ root-only
- C 记忆整理工具（executeMemoryTool 8 处：merge/delete/block_merge/purge/edit/stats）→ root-only
- D 共同面：**只有 Recall + Commit**（自动写入路径 + memory_recall 工具）
- E 22 处 if a.memory != nil 既有关卡 + 状态/工具表判空
更正后的方案：
- `GraphMemory` 接口**只含 Recall + Commit**
- 根：a.graph = a.memory = 同一个 *GraphDB
- 子：a.graph = *LightMemory，**a.memory = nil** ⇒ 既有 22 处 nil 关卡自动禁掉全部 root-only 路径
（executeMemoryTool 开头本来就是 `if a.memory == nil { return "图记忆系统不可用" }`）
- 唯一要拆的：自动写入 commitTriplesWithMedia（图部分走 a.graph.Commit；块/媒体部分用 a.memory != nil 守卫）
- 整理类工具**不进子的工具表**（而不是进去再报不可用）
⇒ 不必写"18 个方法都返回错误"的受限包装 —— 子压根没有那些路径。
2026-09-13 09:42:43 +08:00
e88753d2c6
feat(memory): N2a 第二块砖 + N2d 数据面 —— 轻量图记忆装配（temp 可写/主库只读/并集）与回收合入
...
按用户确认的形态：**独立存储实例**（不给共享记忆层加 space 列）。
## LightMemory：子的图记忆装配（设计 §5.6）
temp 实例（独立存储，读写） ← 子的一切图记忆写入落这里，与子同生共死
主库受限句柄（只读） ← 子只能读（query_only 结构性拒绝写入）
子的查询 = 两实例各查一次 + **应用层合并**（并集）
- 写入**只落 temp**（`Commit` 不接受 main 方向）
- 并集合并规则：实体按**名字**去重（同名保留 mention_count 较大者）、
关系按 (源名, 关系, 目标名) 去重；结果排序确定（便于断言与展示稳定）
- 单侧查询失败不影响另一侧（只有两侧都失败才报错）
- `AllowWrite=false`（用户给的备选简化）：**没有 temp 实例**，子对图记忆完全只读，
写入被拒；读主库照常
## ExportTriples + 回收合入（设计 §9，N2d 数据面）
- `GraphDB.ExportTriples(limit)`：导出**活跃**三元组，把实体名一并带出
⇒ 合入侧直接复用 `Commit`（按实体名 upsert + 关系唯一约束）
- 回收主流程：子写 temp → 父导出 → **父选哪几条** → 写进 main。
未选中的**不进**主库；重复收割**幂等**（不产生重复实体）
## 验收（7 项新测试）
`light_memory_test.go`（5）：
- 写只落 temp、查询是并集、主库无子的痕迹
- **两个子的 temp 互不可见**（只有 main 共享）
- 写禁用时完全只读（无 temp 实例、写入被拒、读照常）
- 并集去重（同名实体只出现一次）
- 合并确定性（去重 + 排序 + mention_count 取大）
`reclaim_test.go`（2）：
- 导出只含活跃关系且带实体名、limit 生效
- 回收主流程（选中的进主库、未选中的不进、重复收割幂等）
全仓 go test ./... 37 包 ok / 0 FAIL。
2026-09-13 09:38:54 +08:00
8aa856a747
feat(memory): N2a 第一块砖 —— 主图记忆的受限句柄（query_only），子是"读得到写不进"
...
按用户确认的形态：**独立存储实例**（不是给共享记忆层加 space 列）。
## 结构性保证
新增 `OpenGraphDBReadOnly(path)`：以**受限句柄**打开图库 ——
连接保持正常打开能力（可读、可恢复 WAL），但 `PRAGMA query_only=1` 让
任何 INSERT/UPDATE/DELETE 被 SQLite **直接拒绝**。
为什么不用 DSN 的 `mode=ro`：只读连接在 WAL 库上无法自行恢复 -wal，
而主库在父 agent 手里是持续写入的。query_only 只堵写、不堵读，语义正好。
⇒ "子改不了主记忆"是**结构性**的，不靠调用方自觉；也不建表、不迁移
（库由父建好，受限句柄不会凭空造出一个空主库）。
## 设计文档
新增 §5.6「实现形态：独立存储实例（不做 space 列）」，写明轻量内核的记忆装配：
子的轻量内核
├─ temp 图记忆实例（独立存储，读写） ← 与子同生共死
└─ 主图记忆的受限句柄（只读）
子的查询 = 两个实例各查一次 + 应用层合并（并集）
回收时由父读 temp、选记录、写进主图记忆
并记录用户给的备选简化：`AllowTempGraphWrite` 开关（默认开）；设为 false 时
子对图记忆完全只读，没有 temp 实例、没有合入。
## 验收
`internal/memory/graph_readonly_test.go`（2 项）：
- 受限句柄读得到、写被拒（Commit/Purge 双双报错），且**主库不留痕迹**
- 库不存在时受限句柄的查询报错，而不是凭空建表后返回空结果
全仓 go test ./... 37 包 ok / 0 FAIL。
2026-09-13 09:32:29 +08:00
dcae461873
docs(resident-subagent): 子的记忆面收窄为「传统上下文 + 图记忆」
...
用户澄清：**doc 记忆**与 **context 动态上下文**是内核独立设计的记忆能力（父专属），
子 agent 的记忆面只有 **图记忆**。据此更正设计：
- §5 开头加适用范围界定：两级空间（读 temp∪main / 写 temp）**只针对图记忆**
- 新增 §5.5「子的记忆面」对照表：
| 能力 | 根 | 驻留子 |
| 图记忆（含向量检索） | ✅ main 读写 | ✅ 作用域化 |
| doc 记忆 / context 动态上下文 / 蒸馏 / 归档 / consolidation / 文本 / 知识库 / 媒体 / 社交 | ✅ | ❌ 父专属 |
- 修正「轻量内核」的表述：不是"记忆变轻"，而是**记忆面裁到只剩图记忆 + 图记忆被作用域化**
- §16.1 记忆面清单加「子可用？」列；**v1 只给图记忆（含其向量检索）加 space 维度**
—— 其余面子根本够不到，加 space 是白工
- 里程碑：N2a = 图记忆 space 维度；N2b = 图记忆的向量检索接入同一过滤
- 决策表补 R3b
纯文档更正；全仓 go test ./... 37 包 ok。
2026-09-13 09:24:09 +08:00
33ee0880c7
docs(resident-subagent): 把 N2 拆成 N2a–N2d（记忆作用域逐面铺开）+ 记忆面清单
...
N2（轻量内核 + 记忆作用域）是目前最大的一块：记忆子系统有 7 个面
（图记忆/向量索引/文档/知识库/文本/媒体/社交），每个面都要加 space 维度。
拆成可独立验收的四步：
- N2a 作用域对象 + **图记忆** space 维度（先做这一条纵切）
- N2b 其余记忆面加 space（逐面验收）
- N2c Agent 级作用域接线（根 = {main,[main]}；驻留子 = {sub/<id>,[sub/<id>,main]}）
- N2d 晋升与丢弃（回收时父把选中的 temp promote 进 main；销毁/回收丢弃 temp）
文档新增 §16.1 记忆面清单（面 → 载体 → 表），说明为何先做图记忆这条纵切。
2026-09-13 09:15:58 +08:00
eb74ac77a5
feat(channel): N1b —— 输出通道授权集合（三处过滤一致）+ 输出通道→目标 agent 的 inputch 解析
...
设计：docs/zh/resident-subagent-design.md §4.5（里程碑 N1b）。
## 输出通道授权集合（默认完整授权，父可收窄）
`AgentConfig.AllowedOutputs`（nil/空 = 完整授权）。三处过滤点必须一致，
否则会出现「列表里看不到、按名字还能调」的裂缝：
1. **工具表**：不为未授权的通道生成 output_send__X（模型看不到就不会调）
2. **列表工具**：output_list_channels 只列授权的
3. **调用点**：凭名字直调未授权的输出门必须被拒（纵深防御）
## 输出通道 → 目标 agent 的 inputch 解析
`ChannelRegistry.BindOutputTarget / ResolveOutputTarget`：
把输出通道解析成「目标 agent + 目标 inputch」，这是"输出可寻址到具体 agent"
（子→父、父→指定子）的**数据面**；真正的跨 agent 投递在里程碑 N4。
未登记的输出通道 ok=false —— 表示由传输层 device 自行处理（qq/webui 这类）。
已登记目标的输出通道，在 output_list_channels 里会标出「目标: <agent> / inputch <名字>」。
## 验收
`internal/agent/core/output_grant_test.go`（3 项）：
- 默认完整授权：全部输出门生成 + 列表含全部
- 白名单收窄：三个过滤点同时生效（工具表 / 列表 / 直调被拒）
- 目标解析：绑定/解析、未登记由传输层处理、列表标出目标、空名报错
全仓 go test ./... 37 包 ok / 0 FAIL。
2026-09-13 09:13:19 +08:00
5a66b8eea1
chore: 撤回误提交的未跟踪文件 internal/plugins/deepsearch_e2e_test.go
...
该文件是工作区里**别人 in-flight** 的未跟踪文件（我上一步用 git add -A internal/ 时被顺带收进来）。
它不是我这次改动的一部分，因此从索引里撤出，文件本体保留在工作区（仍为未跟踪状态），
由它的作者决定何时提交。
2026-09-13 09:07:02 +08:00
63b6f852aa
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
7545f5869c
refactor(core)!: N0 无状态化 —— 删除 Agent.currentOutputChannel，通道只跟输入事件/帧走
...
驻留式子 agent 设计（docs/zh/resident-subagent-design.md）的里程碑 N0。
## 问题
`a.currentOutputChannel` 是 **agent 级可变字段**，只在 prepare 段写入，而被打断任务
恢复时**不重新 prepare**（resumeTask 只 rebase 前缀）。于是中断任务 prepare 时把它
覆盖成自己的通道，被恢复的任务再把回复发到**中断任务的通道**上——两个任务串台。
后果不只是标签错：工具提示词里那句"当前输入来源通道是 X，对应输出门工具是
output_send__X"会诱导模型**把回复主动发到错误的通道**。
## 两处一起改（用户指出的两件事）
1. **内核不应持有"当前通道"**：通道是随输入事件带进来的，路由发生在**进内核之前**，
输出是 agent 的**主动调用**。删除该字段，改为一律从输入事件推导
（`outputChannelOf(evt)`）或读本任务的帧（`f.OutputChannel`）。
2. **提示词不应预设 outputch**：删掉"当前输入来源通道是 X → 用 output_send__X"那两行，
改为"不要假设当前通道是固定值；先看消息本身与上下文的来源信息，不确定时先调
output_list_channels"。
## 改动面（把通道一路显式传下去，而不是读共享状态）
- `agent.go`：删字段
- `task.go`：新增 `outputChannelOf` / `isCriticalChannel`；帧记录通道；
安全点与 setCritical 用帧/事件推导；步骤内事件标签改用 `f.OutputChannel`；
`executeToolCall(f.CurTool, f.OutputChannel)`；`callLLMWithFallback(..., f.OutputChannel)`
- `process.go`：`chatStreamWithFallback` / `accumulateStream` 增加 channel 参数
（增量事件的 channel 标签由此而来）
- `stage.go`：`runStage` 从 `ctx.Extra["output_channel"]` 读（发起方写入）
- `eventloop.go`：`emitResponse` 用 `outputChannelOf(evt)`；stageCtx 带上通道
- `spawn.go` / `toolcall.go`：`executeSpawnChild` 的 parentChannel 由调用方（帧）传入
（子任务完成通知要回到**发起这次 spawn 的那个任务**的通道）
- `distill.go`：删掉 consolidation 路径里的赋值
- `tooldefs.go`：删掉提示词里的通道预设
## 验收
- `scheduler_channel_routing_test.go`（N0 守卫）：中断任务跑过之后，被恢复任务的
输出通道仍是它自己的（改前实测为 cli，期望 qq）
- `TestCriticalSection_ConsolidationMarked`：补上推导链
「输入事件 → 通道 → isCriticalChannel → scheduler.critical」的集成断言
- 全仓 `go test ./...` 37 包 ok / 0 FAIL；`-race ./internal/agent/...` 干净
- 残留 `currentOutputChannel` 引用为 0（只剩描述历史的注释）
2026-09-13 08:59:15 +08:00
c912f47246
docs(resident-subagent): inputch 是最基本的输入路由单位（插件可注册多个）
...
按用户补充收窄定义：
- inputch 是**最基本的输入路由单位** —— 路由粒度到此为止（比「插件」细、比「通道名字符串」实）
- **由插件注册，且一个插件可注册多个**（登记接口即现有 RegisterInputChannel，
调 N 次就是 N 个 inputch；同一插件的多个 inputch 彼此独立，可绑给不同 agent、可分别限额）
- 「划入输入通道」的单位 = **inputch**（不是插件、不是通道组）
- 通道注册层以 inputch 为键（一个插件 → N 个 inputch），每个 inputch 带
归属/被划给的 agent · 容量 · 可接收类别 · 输出目标解析
新增测试点 S21（同一插件两个 inputch 分别划给父与子，互不串台）。
2026-09-13 08:40:04 +08:00
3443d8864a
docs(resident-subagent): 驻留式子 agent 设计稿（轻量内核 · 两级记忆 · 父子中断）
...
把用户口述的设计固化成文档，与已落地的 input-scheduler-design.md 配套。
定下来的核心：
- inputch = 对「中断输入/排队输入」两者的高层抽象，是**路由与分配**单位
（路由发生在进内核之前；类别与级别是每条输入的属性，不是 inputch 的属性）
- 输出是 agent 的**主动调用**（output_send__{通道}）；内核不持「当前通道」可变状态、
提示词不预设 outputch
- 通道不配对：父**划入若干输入通道** + 授权**一组可用输出通道**；输出可寻址到具体 agent
- 驻留子 = **独立轻量内核**：读 temp∪main、写 temp（记忆层按 agent 作用域化 ——
这才是「轻量」的真正理由，不是砍功能）
- 两条独立中断阶梯：父侧 子的主动消息=L3 / contextfull=L4；子侧 **父的消息=L4**
（L4 通则：某 agent 的 L4 只属于它的内核 ⇒ isKernelLevelSource 泛化为「该 agent 的上级」；
子内部一切来源被夹到 ≤L3，所以父的消息确定能打断子）
- 父对子 6 个动作：创建/发送消息/查看/压缩/回收/销毁（原语在内核、决策在父的模型）；
插件与工具由父授权，**默认完整授权**
- contextfull 三处置：压缩=保留（清处理表）/ 回收=取消（promote 选中的 temp 进 main）/
销毁=立刻销毁并移除
- inputch 处理表：子持有、父 pull；主动写入优先，否则系统自动写；生命周期 = 当前上下文窗口
- 登记表 + 硬约束：父可随时销毁，父退出必须销毁全部，子不得比父活得久
- 工作式轻量子 agent **原样保留**，两类并存
含 20 个测试点（S1–S20）与 8 个里程碑（N0–N7，每步独立可验收）、
12 条待确认决策（全部带可逆默认值）。
2026-09-13 08:39:40 +08:00
0ab2d39a9b
test(scheduler): 优先级压力测试（100 排队 + 100 中断各级混合、嵌套到 4 帧上限）
...
按需造一个固定内容的 fakeprovider，做两件事：
E4：混合载荷（用户指定的形状）
100 条排队输入 + 100 条中断（L1/L2/L3/L4 各 25）混合打入。每条中断都等到
“该被它打断的受害者正在跑”时才注入——调度器是单线程的，闭着眼睛猛灌只会
让绝大多数中断退化成排队，压力就压不到抢占/挂起路径上。
判据：200 个任务全部到达终态、Rejected=0、各级登记数=25、**各级抢占数都>0**、
排空后 Suspended==Resumed、每次“取消流式段”都换来一次挂起。
E5：嵌套到结构上限
排队任务运行中依次注入 L1→L2→L3→L4（每级都等上一级在跑）。判据：栈深峰值
恰好 4（= 结构上限，此时 canSuspend()=false），恢复顺序严格 LIFO
[L3,L2,L1,排队]，Suspended==Resumed==4。
顺带修掉两处：
- **Resumed 双计**：nextRef 弹栈与 resumeTask 各计一次，使“排空后
Suspended==Resumed”这条不变量失真。现在只在 resumeTask 计（nextRef 只负责选出）。
- 新增分级可观测：SchedulerStats.InterruptsByLevel[1..4] / PreemptsByLevel[1..4]。
只看总数会掩盖“总数一样但级别分布完全不同”，按级别验收才是这套调度器的判据。
注意 PreemptsByLevel 是“判定可抢占并进入 immediate”的次数，与 Suspended 不等价：
受害者可能在让位生效前就自行结束，此时抢占者只是“下一个运行”，没有挂起发生。
教训：provider 必须感知 ctx 取消。第一版没做，结果 LLM完成==任务数、挂起≈0——
抢占全落在“步骤之间”，流式段（真正需要保存/恢复现场的地方）一次都没压到。
验收：go test ./... 37 包 ok 0 FAIL；-race 全绿；压力连跑 3 次稳定；
新内核 go build 通过并真实启动冒烟 OK。
2026-09-13 07:31:32 +08:00
b3889e059a
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
b3daeb6cf8
feat(scheduler)!: 中断/排队两类别模型 + 插件声明 L1-L3、L4 内核独占
...
用户澄清推翻了早期设计的三处前提，本提交按新模型重做调度核心（行为有意变化）：
1) 类别由注入 API 决定，与通道名无关
- InjectInterrupt* -> TaskInterrupt（带级别，可被严格更高级中断打断）
- InjectText*/InjectInputSync*/内核自循环 -> TaskQueued（无级别，可被任何中断打断）
- 删除按通道名推断的 taskLevel()：qq 走 InjectInterruptTextOpts，本就是中断
2) 级别只属于中断
- 插件在 InjectOptions.Priority 声明 L1-L3（空/非法降级 L1，声明 L4 夹到 L3）
- L4 内核独占：新增 raiseKernelInterrupt（panic / selfip）；requestKernelPreempt 不夹取
- panic 现在产生一条带 kernel 标记的 L4 中断；L4 自身 panic 不再产生新 L4（防自我放大）
3) 选择结构：四容器固定次序，删除统一比较器
- immediate（抢占者立即运行）-> 中断队列 L4..L1 -> 栈顶(与队头比级别) -> 排队 FIFO
- 删除 pickTaskIndex/taskBefore 与“同级 pending 优先”补丁（根因是抢占者进了队列）
- 中断栈上界改为结构推论 = 4（= 中断级数）；删除“超限转 pendingInterrupts”降级
公开 SDK（feature 分支有意新增，纯追加）：InjectOptions.Priority + PriorityL1/2/3；
内核 io / proc 桥 / 插件模板同步透传。
设计稿 §2/§3/§4.1/§6.3/§9/§11/§12/§13/§15 按新模型重写。
验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿；
e2e（抢占-挂起-恢复）+ 压力（200 排队 + 50 中断，L1/L2/L3 轮转）通过。
2026-09-13 07:00:51 +08:00
c701bb5386
fix(scheduler)!: 中断栈语义（嵌套抢占 LIFO），并修掉抢占空转
...
用户指正：存在**中断被中断**的场景，所以被打断的现场要进**中断栈**。
我此前把 suspendPool 明确写成“不是栈、按优先级取”，是错的。
改动：
- suspendPool 改名 suspendStack，恢复纪律改为**严格 LIFO（只比栈顶）**；
栈内不做优先级重排——嵌套抢占天然使栈自底向上基础级递增，
且“后被打断的先恢复”才是栈语义。取出即弹栈。
- 修掉一个由此暴露的真 bug（抢占空转）：一次抢占生效后，被挂起的原任务
会因饥饿防护提升有效级，与抢占者同级；此时若按“先到先服务”，原任务
（入队更早）会被立刻选回，抢占者永远排不到 —— 抢占等于没发生。
现在**同级时 pendingInterrupts 优先于其它两类**，保证抢占必然生效。
- 状态 DTO：SuspendPool/suspend_pool → SuspendStack/suspend_stack
- 设计稿：§2 用语更正（它**就是**中断栈）、§4.1 选择函数（候选只含栈顶 +
pending 同级优先，并说明为何必需）、§6.2/§6.3/§9/§11 用例同步
测试新增 scheduler_stack_test.go 3 项：
- 嵌套 L1→L2→L3，恢复严格 LIFO（B 先于 A）
- 只比栈顶：人为构造“栈底 L3、栈顶 L2”，必须取栈顶（区分两种实现）
- 嵌套下的深度上限
验收：agent 全量 + -race；全仓 build/vet 通过
2026-09-13 06:30:23 +08:00
bf0d2510cc
fix(scheduler)!: D1 更正为「中断从上一个任务之前的完整状态开始」，并实现现场合回
...
用户明确语义（我此前对 D1 的解析就是错的——当时回答里的“A”指的是 git 选项，
D1 实际要的是方案 B）：
中断打断时，上个任务到达以来的所有上下文现场被保护（含 toolcall），
然后中断在「上个任务前的那个完整状态」上开始运行；
中断结束后再把被挂起的任务与其上下文现场加载回中断任务之上，并继续运行。
实现：
- 删除 SeedMsgs 与 D1=A 的“只读前缀”机制：中断任务不再继承被打断任务的任何内容，
它就是普通新任务，正常走完整 prepare（system prompt + timeline + 自己的输入）
- TaskFrame 新增 PrefixLen（基础前缀长度）与 InputBlocks；
stepPrepare 在 buildMessages 之后记录 PrefixLen
- 新增 rebaseFramePrefix：恢复时重建基础前缀（中断已提交进 a.context，
重建的 timeline 含中断效果＝“加载回中断之上”），再把本任务自己的尾部
（Stage 上下文 + 工具轮产物 + 占位）接回；并补回 IsInterrupt 标记与多模态块
- resumeTask 在 runTaskSteps 之前调用 rebaseFramePrefix
- 设计稿 §5.3 改写为「已定：D1=B」并写明实现对应；§6.2 补“重建前缀→接回尾部”；
§12 的 D1 行更新
测试：
- TestPreempt_HigherPreemptsAndResumes 改为断言「中断不继承、恢复后看得见中断内容」
- 新增 TestPreempt_ResumeRebaseRestoresTailDecorations（前缀重建后尾部装饰补回）
- 原 TestPreempt_SeedPathDoesNotLeakInterruptFlag 随之删除（机制已不存在）
验收：agent 全量 + -race；全仓 build/vet 通过
2026-09-13 06:24:20 +08:00
bad29c00dc
fix(scheduler)!: 撤掉“优先级=可配置策略表”的错误设计，回归内核内部属性
...
用户指正：**优先级是内核内部属性**，不是配置项，更不该由插件声明。
我此前把它建模成“策略表 + 字符串解析”，甚至准备接配置中心
（core.agent.priority.<channel>）——方向性错误，故整体撤销。
撤销：
- 删除 ParseLevel（字符串解析只服务于“外部可配”这个错误前提）
- 删除 AgentConfig.PriorityLookup / Agent.priorityLookup 及 taskLevel 中的查表分支；
taskLevel 回归为纯内核内部规则（cli/webui/http→L3，system/_consolidation_→L1，
其余 L1），注释明确“不对外暴露、不做运维可调项”
- 设计稿 §3.2 改写为“内核内部属性，不做成配置项”，并删除 §15 里
“ChannelDef.Priority / InjectOptions.Priority 进公开 SDK”这一方向（同属外化）
- 未触碰配置中心（registry.go/main.go 的优先级配置一行未加）
同时落地 D6（与本撤销无关、此前遗漏的承诺）：
- AgentConfig.MaxToolTurns + runTaskSteps 在发起新一轮 LLM 前按 f.Turn 收尾；
0 = 不限；cmd/homed/main.go 从既有 core.agent.max_tool_turns 取值
- 新增 task_test.go 2 项：上限 3 时恰好跑 3 批工具/3 次 LLM 并收尾；
0 = 不限（跑完脚本）
验收：agent 全量 + -race；全仓 build/vet 通过
2026-09-13 06:17:49 +08:00
e999c1d95d
fix(scheduler): 补齐 M3 与设计稿的两处语义偏离（发现即修）
...
两处都不是风格差异，而是真的偏离设计语义（其一为回归），
已按“先写判据确认失败、再修”的方式处理，判据保留为回归测试。
1. 空闲时到达的中断永远不会被处理（设计 §5.1 ③ 未落地）
调度器空闲时只阻塞在 select{InputChan, selfInputCh, ctx.Done}，
而 pendingInterrupts 不是 channel——interceptLoop 把中断入队后
没有任何东西唤醒调度器，中断要等“下一条输入”才被看到。
修复：调度器加 wake channel，enqueueInterrupt 非阻塞 signalWake，
空闲分支增加 wake 分支。
2. 临界区内只“不让位”却仍被“取消”（设计 §4.3/§5.2）
requestPreempt 不判临界区，interceptLoop 照常 cancelLLM，
于是正在流式的记忆整理被中断，stepLLM 以 error 提前结束——
整理任务被砍掉一半，而设计要求的是“请求排队等它结束”。
修复：scheduler 增加原子 critical 标志（帧仍只由调度器读写），
runInputTask 在 prepare 后设置、结束（含挂起）时清除；
requestPreempt 在临界区内不 arm、不取消，中断只入队。
- 新增 scheduler_regression_test.go 2 项（先失败后通过）
- 验收：agent 全量 + -race；全仓 vet 通过
2026-09-13 06:10:44 +08:00
32f801a775
docs(scheduler): 回写 M1–M7 实现状态与 5 处实现期偏差
...
- 里程碑表补提交号与验收结果
- 记下与设计稿的偏差：M3 拆分、a.mu 移除、interceptCh 删除、
M0 伪时钟未做（用阻塞 provider 替代）、工具执行临界区由结构保证
2026-09-13 00:48:20 +08:00
193e400a89
feat(scheduler): M7 可观测性 + 压力测试 + 端到端测试
...
设计依据 docs/zh/input-scheduler-design.md §11.5（O1/O2）、§11.6（E1/E2）。
- 可观测性：KernelStatus 新增 Scheduler 段（running/三集合深度/计数/
深度上限），由 GetKernelStatus 从 DumpScheduler 原子快照填充；
新增 events.EventScheduler，挂起/恢复各发一条（action/task/level）
- TaskKind.String() 便于日志与状态输出
- 新增 scheduler_e2e_test.go 3 项：
· 压力：200 排队输入 + 50 中断全部经真实 loop 执行，结束时三集合排空、
LLM 调用数精确等于输入数、无 Rejected
· 可观测性：挂起/恢复事件齐备，状态快照计数一致
· 端到端：完整启动 schedulerLoop+interceptLoop，经真实 channel 投递
L1 任务与 L4 中断，验证「LLM 流式中断 → 挂起 → 中断先完成 → 原任务恢复」
整条链路（LLM 调用数 = 丢弃1+中断1+恢复1+常规1）
- 验收：agent 全量 + -race；全仓 build/vet 通过
2026-09-13 00:45:28 +08:00
cc0e8ed0b5
feat(scheduler): M6 任务级回执 + 断链点统一为终态事件
...
设计依据 docs/zh/input-scheduler-design.md §7（I5）、§11.3（X1/X2/X4）。
- 新增 emitSkippedReply：跳过路径（去重命中、空输入）给同步调用方一个
skipped 终态，但**不发 agent_output 事件**（避免 WebUI 聊天记录凭空多出
空消息）。修复前 cli/clawhubadapter 这类无超时的同步注入在去重命中时永久挂起
- 回执按任务归属：中断任务的回执只写自己的 ResponseCh，绝不误投给被挂起的等待者；
被挂起任务恢复并结束后才拿到自己的回执
- 新增 task_terminal_test.go 3 项：X1 回执不误投、X2 空输入有 skipped 终态、
X4 无超时同步调用方 1s 内拿到终态（回归判据）
- 更新 M3a 去重用例：由「不得回执」改为「必须有 skipped 终态」
- 验收：agent 全量 + -race；全仓 build/vet 通过
2026-09-13 00:39:56 +08:00
1b7c3fa53e
feat(scheduler): M5 饥饿防护（抢占计数提升有效级 + 抢占冷却）
...
设计依据 docs/zh/input-scheduler-design.md §9、§11.5（G1/G2）。
- Task 增加 PreemptCount / LastPreemptAt；effectiveLevel(t) =
min(L4, Level + min(PreemptCount, 2))：被抢占越多越“值钱”，
逐步追上抢占它的流，但封顶 L4 因而抢不过真正的紧急输入
- 选择函数 taskBefore 改用有效级；requestPreempt 与 preemptGrantedFor
同样以有效级比较
- 抢占冷却 preemptCooldown=2s：刚被抢占的任务期内不再被抢占，
避免同一任务被反复打断到永不完结
- 新增 scheduler_starvation_test.go 4 项：提升与封顶、冷却期内不得再抢占、
提升后同级不得抢占而更高可、选择函数确实用有效级
- 验收：agent 全量 + -race；全仓 build/vet 通过
2026-09-13 00:38:30 +08:00
0f78d7094d
feat(scheduler): M4 临界区显式化 + 清掉被 pendingInterrupts 取代的 interceptCh
...
设计依据 docs/zh/input-scheduler-design.md §4.3、§11.1（P5/P6）。
- 临界区语义显式化：让位检查**只在 step 之间**做，执行中的 step
（工具 RPC / ONNX / CAS 落盘）天然不可抢占；_consolidation_ 整任务
经 inCriticalSection() 判为不可抢占（它直接改图库）
- 删除 interceptCh 与 drainInterrupts：M3b 起中断一律走 pendingInterrupts，
旧的「同行注入 + 三处 drain + 批次放弃」已无写入者，属死代码
- 新增 scheduler_critical_test.go 3 项：
P5/P6 工具执行中 arm 了让位信号也不得挂起、必须等工具返回后的安全点；
_consolidation_ 判为临界区；无抢占时同批工具必须全部执行（新语义回归）
- 验收：agent 全量 + -race；全仓 build/vet 通过
2026-09-13 00:34:39 +08:00
a77e1aacae
feat(scheduler): M3a+M3b 任务生命周期重构 + 四级优先级抢占
...
设计依据 docs/zh/input-scheduler-design.md §3–§8、§14。
M3a（行为等价的所有权重构）：
- processInput 拆为 prepareInputTask / runTaskSteps / finishInputTask，
帧覆盖 prepare→step…→finish；提交与回执只在 finish 段发生一次，
为安全点挂起做准备（挂起不重复提交）
- process() 不再持 a.mu（挂起不能持锁），a.mu 字段随之移除
- TaskFrame 增加任务层现场（Evt/CleanInput/IsInterrupt/StartedAt/Terminal/
Level/SeedMsgs）与 taskTerminal / outcomeSuspended
- 新增 task_lifecycle_test.go 5 项：正常恰好一次终态、去重 skipped、
on_input 短路、错误终态、consolidation 路由
M3b（优先级与抢占）：
- interceptLoop 重写：只做「收中断 → 定级 → requestPreempt → 必要时取消
LLM」，绝不触碰帧（不变量 I2）；三条降级路径与 interceptCh 兜底退场，
改为统一的 pendingInterrupts
- scheduler：pendingInterrupts / suspendPool / 让位信号，nextRef 在三集合上
按统一排序键取值；深度上限 4（canSuspend 在安全点拦下）
- 抢占判据 incoming.level > running.level；相等与更低只入队
- 安全点只在 step 之间；执行中的 step（工具 RPC/ONNX/CAS）天然不可抢占；
_consolidation_ 整任务视为临界区
- 恢复走 resumeTask：从 frame.Step 继续，不重跑 prepare
- D1=A：suspend 把被打断任务的只读前缀交给抢占比它的中断任务（SeedMsgs）
- 新增 scheduler_preempt_test.go 5 项：抢占-挂起-恢复（含 R1/R5）、同级更低
不抢占、深度上限、空闲中断不丢、seed 路径不污染标志位
验收：agent 全量 + -race 通过；全仓 build/vet 通过
2026-09-13 00:25:52 +08:00
91782685cf
docs(scheduler): M3 拆为 M3a（所有权重构）/M3b（抢占语义）
...
真正的中途挂起要求帧跨越 prepare→step…→finish 全生命周期；若只让
process() 可挂起，processInput 会在挂起返回后继续 context.Append 与
emitResponse，造成重复提交。故 M3 分为两步：M3a 行为等价的所有权重构
（含移除 process() 整轮持有的 a.mu），M3b 再引入优先级与抢占。
2026-09-12 23:51:13 +08:00
e037cef11c
feat(scheduler): M2 调度器骨架（就绪队列 + 选择函数 + 快照 + 任务级 panic 隔离）
...
设计依据 docs/zh/input-scheduler-design.md §14 M2。
- 新增 scheduler.go：四级 Level 常量（默认 L1，显式才是特权）、
Task/TaskKind、scheduler（有界队列/running/统计）、纯函数 pickTaskIndex
（排序键 -Level → EnqueuedAt → ID）、schedulerLoop/pumpInbox/executeTask、
DumpScheduler 原子快照
- eventLoop 退场，职责由 schedulerLoop 承担；M2 全部任务为 L1，
因而行为等价于原先的 channel FIFO
- 每任务 panic 隔离（不变量 I6）：panic 只失败该任务，调度器存活，
取代原先「重启整个循环」
- Start() 改起 schedulerLoop；interceptLoop 暂不动（M3 重写）
- 新增 scheduler_test.go：Q1 排序 4 组、Q4 背压、生命周期、K1 panic 隔离、
O1 快照一致性、Level 取值契约
- 验收：agent 全量 + -race 通过
2026-09-12 23:49:55 +08:00
a4daacdc13
refactor(scheduler): M1 把 process() 拆成 step 状态机 + TaskFrame（行为等价）
...
设计依据 docs/zh/input-scheduler-design.md §14 M1。
- 新增 task.go：Step 游标、TaskFrame，以及 stepPrepare/stepLLM/
stepToolBegin/stepToolExec/stepToolAfter/stepTurnEnd 六个 step；
原函数内嵌的 provider 回退/重试抽为 resolveProviders + callLLMWithFallback
- process() 改为驱动状态机的薄壳：签名不变，调用方（processInput/
processConsolidation/测试）零改动
- StepToolExec 显式标注为临界区：工具副作用不可回滚，执行中不是安全点
- 步数上限护栏：转移缺失时以错误退出而非死循环
- 新增 task_test.go：R3（工具往返结果与配对正确）、X3（多轮必然终止）、
批中途中断必须放弃剩余工具、未知 step 必须失败退出
- 验收：既有 agent 全量测试通过；-race 通过（TMPDIR 指向真实磁盘，
/tmp tmpfs 已 98% 满会导致链接失败，与代码无关）
2026-09-12 23:47:12 +08:00
a28eb989ca
docs(scheduler): 输入调度器设计稿（四级优先级/可抢占/现场保存 + 测试点与里程碑）
...
背景：现状排队与中断两条语义建立在串行 eventLoop 上，存在队头阻塞、
中断三条隐式降级路径、回执无任务归属、断链点静默、背压策略分裂、
假取消、不可观测七个已确认问题。
设计：四级内核预定义优先级（严格大于才抢占）、显式临界区、
单调度线程 + 单中断线程、step 化任务帧与安全点、suspendPool/pendingInterrupts/
readyQueue 三集合统一选择函数、任务级 responseCh。
含 11 组测试点（优先级/恢复/回执/队列/深度饥饿并发/端到端），
测试方式与预期结果逐条写明；M0–M7 里程碑逐步实现。
公开 SDK 在 v1 保持冻结（diff 必须为 0）。
2026-09-12 23:39:10 +08:00
ee7ac0bc0f
chore(sdk-mirror): 同步 vendored SDK 到 SDK main（browser_search 现代 Bing 版式解析修复）
...
镜像追平 SDK main（`ebd700e`）：
- browser 示例：browser_search 三处根因修复（www.bing.com 302 → cn.bing.com；
标题取 h2 > a 而非块内第一个 <a>；摘要兼容 p.b_lineclamp*）并解开 /ck/a 跳转包装，
解析不出结果时显式报错；附真实响应夹具与 5 项单测；版本 2.4.0 → 2.4.1。
注：SDK 仓新增的 example/deepsearch（联网检索 + SearXNG 生命周期托管）与
example/vikunja（任务管理）按本仓策略（.gitignore 忽略 example/ 下未跟踪文件）不入镜像。
2026-09-12 23:39:10 +08:00
a20270f795
docs(plan): 记忆与多模态目标纠正（媒体为一等节点、同一指纹空间、音频 unsupported）
...
把计划里过时的描述式索引路线改正：媒体/媒体块是 L3 一等节点与原生边，
multimodal doc/context 的向量与裁剪须与 text/媒体块在同一指纹空间共同参与；
音频在该模型下明确 unsupported（不做文本描述式索引）。
2026-09-12 20:21:01 +08:00
f57eb25f74
feat(waiter,devicebridge): 设备桥连接带授权态，命令处理器类型统一
...
- `runDeviceBridgeLoop`/`connectDeviceBridge` 增加 `authorized` 入参（未授权不再尝试建立桥连）；
- `Bridge.OnCmd` 的处理器类型改为具名 `BridgeCmdHandler`，与 waiter 侧签名对齐。
2026-09-12 20:21:01 +08:00
2e2d6c3c06
feat(ohos): 设备桥会话管理、状态/设备信息载荷与能力路由完善
...
- 新增 `DeviceBridgeSession.ets`：会话生命周期（创建/复用/回收）与 TTS 会话显式 shutdown；
- `BridgeCaps`/`BridgeRouter` 与内核实际支持的本机命令保持一一对应，补齐 status/deviceinfo；
- 页面与状态存储调整（DevicePage/Index/SettingsPage/StatusStore/SubPage）、新增 ScreensuePage；
- module.json5 与 string.json 同步（新增页面与文案）。
2026-09-12 20:21:01 +08:00
88ad345f42
chore(sdk-mirror): 同步 vendored SDK 到 SDK main（qq 插件重写、browser 会话超时必填、路牌 1.3.0）
...
核心仓 `third_party/homeagent-sdk` 是 SDK 仓的 vendored 副本，内容以 SDK 仓 main 为准
（本仓 `.gitignore` 忽略 example/ 下的未跟踪文件，已跟踪的镜像文件用 `git add -u` 更新）。
本次把镜像追平到 SDK main（`8c10b7e`）：
- qq 插件重写（+498 行）：`output_send` 回声/自激路径的根因修复与去重；
- browser 示例：交互式会话 `timeout` 由默认 10m 改为**必填**（附参数校验与测试）；
- `meta.Version` 1.2.0 → **1.3.0**（SDK v1.2.0 已定版，SDK main 按纪律推进到下一个中版本）。
2026-09-12 20:21:01 +08:00
b77ee492eb
fix(packaging): SHA256SUMS 只列本批产物，且用平铺名（此前会带上历史版本、且与附件名不符）
...
v1.2.2 出包时发现：dist/ 跨多次构建累积，而清单用 `find $DIST_DIR` 全目录扫，
于是 SHA256SUMS 里混进了 1.2.0/1.2.1 的包名——用户从发布页下载这份清单后
`sha256sum -c` 必然报「文件缺失」（那些包并不在本页）。
两处一起修：
- 按本批 `$PKG_VERSION` 过滤（只列这次真正打出来的产物）；
- 名字用 basename（平铺名），与发布页附件名一致；哈希取真实路径（此前若直接
对 basename 求哈希会找不到文件——就在 `deb/`、`tar/` 子目录里）。
验证：对含 1.2.0/1.2.1/1.2.2 的 dist/ 跑新逻辑 → 4 条（旧逻辑 12 条）；
并拿发布页真下载的 SHA256SUMS 逐条核对四个产物的实际哈希 → 全部一致。
2026-09-12 19:18:26 +08:00
8e7e04305f
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
5df5ad110a
fix(knowledge): 知识库检索改为「稠密 + 词法」两路融合（真实 KB 自检索 MRR 0.271→0.376）
...
追「实例看起来没更新」时发现知识库检索本身也不可信，先把病因查清再动手：
- **两段式召回不是瓶颈**：Store 的结果与全量暴力 cosine 完全一致；
- **真因是向量没有区分度**：词向量取平均后各向异性明显，真实 KB（33 条）上自检索
top-1 只有 15%、前两名平均只差 0.013，排序基本是噪声；
- 且全为停用词的查询会得到**空向量**（"最近更新"），直接搜不出任何东西。
先在真实数据上把候选方案量了一遍（用自检索 top-1 / MRR）再动手：IDF 维度加权零收益、
去均值反而更差，**都不做**；唯一有收益的是与词法路（TF-IDF）融合。
改动：
- `Store` 增设词法路索引，`Search` 融合两路：各自按**查询内最大值**归一化后加权。
权重 0.5 由权重扫描定：1.0（旧行为）MRR 0.271 / 0.8→0.354 / 0.7→0.358 / **0.5→0.376** /
0.3→0.336 / 0.0→0.307；语义查询也从"全是 openharmony 噪声"变成命中正确条目
（「首启人格门禁」→changelog_v1.2.1、「插件怎么开发和部署」→plugin_dev_build）；
- `vector.Store` 的候选中选阈值改为**可设**（默认 0.05 保持既有行为）：TF-IDF 余弦量级
只有 0.0~0.2，沿用 0.05 会把词法路有效候选**静默砍掉**——这一条正是 0.376→0.197 的
差距来源，且当时没有任何报错；
- Add/Remove/scanAll/ReindexWithVectorizer 同步维护两路；分数相同时按名字定序（结果可重复）。
**顺带修一个真实毛病**：Add/Remove 原先用**无追踪的 goroutine** 写索引（因为
writeIndex→BuildTree 会 RLock，而调用方持写锁，同步调用会死锁）→ 失败只打日志，
且与调用方竞态（测试的临时目录清理就撞上了）。改为持锁就地 flush
（buildTreeLocked / writeIndexLocked）。
判据（不依赖人工标注问答对）：新增 `internal/knowledge/rankdiag_test.go`，用**自检索
top-1 / MRR** 量区分度，`KB_DIAG=1` 跑、`KB_DIAG_ASSERT=1` 断言（MRR ≥ 0.34）。
另有不依赖真实数据的单测 6 条（空稠密向量靠词法路救回、稠密并列时词法路定序、
词法路阈值接线、Add/Remove 双路一致、并列时确定性、空库不 panic）。
**反向验证**（证明判据真能发现缺陷）：权重退回 1.0、词法路阈值改回 0.05、
把阈值写死回 0.05 —— 对应测试逐条变红。另：我第一版夹具余弦 0.365/0.273 远高于阈值，
注入缺陷也不报错（等于没验），故加了「夹具前提」断言并改成两层判据
（语义层由 vector 包测试证明、接线层由知识库测试钉住）。
顺带纳入上一轮漏提交的 `TestAddOverwriteReplacesVector`（同名覆盖必须摘掉旧向量，
生产改动当时已提交，测试一直未入库）。
2026-09-12 18:14:22 +08:00
47c57208b2
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
9f83324e68
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
f37b73a1f5
docs(branching): 明确开发者文档的发布归属——以 rel 分支的形态为准，再合入 main
...
用户裁定：开发者文档应当在每个 rel 分支被修正为对应 rel 的形式，随后合入 main。
新增 §二.7，写清：
- 规则与做法（release 上按本版口径改 → cherry-pick 到 main，遵守 §三 只 pick 不 merge）
- 为什么不能直接改 main：main 语义是「下一个未发布版本」；assets/docs 会随发行包
分发并在 WebUI 被阅读，服务的是「这一版」；版本号/工具名/机制有无都随版变动
- main 上描述「下一版才有」的行为必须显式标注（如「（下一版）」）
- 反例表（本仓真实踩过）：人格卡写死 v0.9.0 + 已删除的 C ABI、架构文档把已移除的
描述式索引/引用计数写成现行、README 停在旧版本
- 配套硬约束：任何会被当作事实的文本不得写死版本号，须插值或读运行时快照并加测试
2026-09-12 13:05:24 +08:00
2578f4eafa
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
052ca06581
docs(architecture): 记忆流转图对齐统一多模态空间
...
流程图里 Context/Prune/DocStore 三行仍只写 StaticEmbedder 与 TF-IDF，
读起来像"向量化只有词嵌入一条路"，与 1.2.0 实际（多模态统一空间为主，
带 fingerprint；词嵌入/TF-IDF 是降级层）不符。
- Context Append：补三层向量层级说明
- Context Prune：改为 DenseCosine（仅同指纹比较）→ StaticEmbedder 回退
- DocStore：改为稠密向量 + dense_fp 同指纹要求（不符即重算）
- 中英双版同步
2026-09-12 12:46:21 +08:00
6805a682dd
feat(persona): 人格设定配置项化 + 默认模板契约测试 + 腐坏告警
...
起因（v1.2.0 压测）：线上实例内核日志/接口都报 1.2.0，agent 被问版本时却按人格卡
自述 v0.9.0 + C ABI v2（该机制 v1.0.0 已删除）。根因是人格只有「文件」一个来源且无人
维护——写死的版本号必然随发版腐坏。
改动：
1. 新增配置项 core.agent.personal_prompt（多行文本），默认值为内置模板
config.DefaultPersonaPrompt，随其它默认值同批播种（老安装不注入，语义不变）
2. 默认模板**不含任何版本号字面量**，并显式要求「被问到版本/构建信息时以运行时快照
（healthcheck_kernel）为准」——从根上消掉这类腐坏
3. 人格来源优先级：personal/personal.md（存在且非空）> 配置项 > 无
启动日志明确打印来源；文件含腐坏内容（版本号字面量 / 已删除机制的说法）时告警并
建议迁移到配置项
4. internal/agent.PersonaStaleHints：腐坏检测（版本号正则 + 已删除机制词表）
契约测试（防复发）：
- TestDefaultPersonaPromptHasNoVersionLiterals：默认模板不得含 v?\d+\.\d+\.\d+，
且必须含「运行时快照」要求
- TestPersonaPromptRegisteredWithDefault：注册存在、默认值一致、播种真的写入
- TestPersonaStaleHints：线上人格卡原文必须被识别（v0.9.0 / C ABI v2），干净文本不误报
验证：go build ./cmd/homed ok；go vet 三个包 ok；go test ./internal/config ./internal/agent ok；
端到端两场景（无文件→来源=配置项 1307 字节；有旧文件→来源=文件 + 告警列出 v0.9.0 与 C ABI v2）。
2026-09-12 12:42:43 +08:00
c4611ea8e9
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
0fdf79b830
fix(memory): 修 beta.2 压测发现的三个向量/文档缺陷
...
来源：v1.2.0-beta.2 全方位压测（报告 /var/tmp/stress/REPORT.md）
1. 文档向量迁移结果不落盘（生产已复现）
- BuildDenseIndex 改完内存不置 dirty；docStore.Stop() 全仓无调用者 → flush 成死代码
- 后果：每次启动重算同一批文档（线上 496 篇约 17s），磁盘 dense_fp 永不收敛
- 修：迁移当场落盘（抽出 flushLocked 以免重入锁）+ main.go 关停链 defer docStore.Stop()
- 生产证据：线上 488 篇文档仅 4 篇含 dense_fp，且这 4 篇均为运行期 Insert 的新文档
2. 块指纹对但维度错时污染文档向量（健壮性缺口）
- denseFor 只校验 b.Fingerprint，不校验长度；FuseVectors 取最大维度并跳过长度不符者
→ 512 维文本 + 2048 维块 = 2048 维且打上当前指纹
→ 该文档在检索侧被长度守卫永久跳过，且每次启动重算（不收敛）
- 修：denseFor 要求 len(b.Vector) == 空间维度
- 可达性：内核两个块产出点均成对取自同一行（it.Vec ↔ it.VecModel），故属防御性修复
3. Insert 与 loadAll 的 ID 约定不对称（低）
- Insert 落盘任意 <id>.json，loadAll 只加载 doc_ 前缀 → 自定义 ID 文档重启后静默消失
- 修：loadAll 只要求 .json（空 ID 仍跳过）
回归测试 4 条：迁移跨重启落盘 + 已对齐 0 重算（用向量空间调用计数判定，
不靠日志）、坏块不参与融合且同维度正常块仍参与、自定义 ID 可加载、Stop 落盘。
反向验证（纪律要求）：临时回退本次修复后，前 3 条均变红且报错正是缺陷签名
（dim=999/space-OLD-999 永不收敛、文档向量 2048 维、文件重启后消失）；恢复后全绿。
验证：go build ./cmd/homed ok；go vet ./internal/memory/document ./cmd/homed ok；
go test ./internal/memory/... 7 包全绿。
2026-09-12 11:05:11 +08:00
0c6f239104
docs(matrix): 记录 v1.2.x 的接口扩展，以及本次审计抓出的两处漂移
...
§九 原本只写到 v1.1.x。补上 1.2.0 的接口增量（注入侧的 InjectOptions 与六个
*Opts 变体、ContextPolicy 取值、ChannelDef.ContextPolicy 与它的 JSON tag），
并明确一件容易被误读的事：**「接口纯追加」不等于「无需重编」**——同版把插件运行
协议升到了 2（fd3 布局改变），协议不匹配会在握手时被明确拒绝，这两件事必须分开说。
同时把这次扩展自己抓出来的两处漂移入档（都属于本节第 3 条要防的类型）：
1. 模板接线守卫 `TestProcTemplate_CoversAllCoreMethods` 红了：模板不再发
io.injectTextNoMem（改走 io.injectText + NoMemory），而内核保留该 id 是刻意的
向后兼容面。修的是判据（显式 deprecated 表 + 反向保护）。
2. mocksdk 与公共 SDK 机械求差，差集为旧的三参数 InjectInputSync（通道类插件闭环
要调的方法）；git log -S 证实从来就缺，已补齐。
验证表按**本机实跑结果**填写：示例 vet 17/17、plugindev 测试全绿、
sdk -race -count=5 通过、mocksdk 差集为空。
2026-09-12 09:41:39 +08:00
fe61bbfe7a
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
76a99c0d39
docs: README 更新到 v1.2.0，并纠正已在 v1.2.0 删除的机制
...
README 的「项目状态」停在 **v1.1.1**，而且其中两条描述与当前实现**相反**：
「媒体以 `[<mime> <短digest>] <描述>` 标记存在于纯文本记忆中，描述是可检索的
语义记忆」与「引用计数式 GC（有引用者绝不删）」——这两套机制正是 v1.2.0 拆掉的。
本次不重写历史条目（它们记录了演进），而是：
1. 「项目状态」顶部新增 **v1.2.0** 条目：统一多模态向量空间（模型中立 SPI +
Chinese-CLIP 默认，含「纯文本语义弱于 MLLM 型嵌入器」这一已知代价）、
媒体升为图记忆一等节点（并写明具体删掉了什么）、数据面全量走共享内存
（协议 2、不支持滚动升级）、注入标志位、发行包默认启用 ONNX 且随包模型、
homed 改走 WSL2、以及三个安装链静默失败的修复。
2. 在 v1.2.0 条目后加一条显式提示：下方历史条目中的「描述式索引」与
「媒体引用计数式 GC」**已在 v1.2.0 移除**——避免读者按旧文档理解现行行为。
3. 「下载」：Windows 安装器的版本号改到 v1.2.0，并写明自 v1.2.0 起因 homed
不再支持 Windows 原生，安装器改为引导到 WSL2 并在其中按 Linux 方式安装；
同时注明安装器含 AGPL 许可页。
中英双份同步。SDK 仓 README 另在 SDK 仓提交（d893bfa）。
2026-09-12 09:27:28 +08:00
cee4e89363
docs(license): 核心仓采用 AGPL-3.0-only，并写进包内与安装器
...
本仓此前**没有任何许可文件**，README 里也没有许可声明，而 rpm 元数据里甚至写着
`--license "Proprietary"`（与我们实际的分发意图相反）。
## 选择了什么
`LICENSE`：GNU Affero 通用公共许可证第 3 版官方全文（gnu.org 正本，
661 行 / 34523 字节，
sha256 0d96a4ff68ad6d4b6f1f30f713b18d5184912ba8dd389f86aa7710db079abcb0）。
选 AGPL-3.0-only 的理由：GPL 家族里**传染性最强**的一档，并且不允许选后续版本。
它比 GPL-3.0 多出 §13（Remote Network Interaction）——通过网络提供服务时也要向
使用者提供源码。这正是「最严格」在 GPL 家族里的落点。
依赖许可已核对为全部宽松且兼容：go-sqlite3 / gojieba / gopher-lua / bubbletea /
bubbles / lipgloss / yaml.v3（MIT）、golang.org/x/{sys,text}（BSD-3）、
Chinese-CLIP 产物（Apache-2.0，与 GPLv3+/AGPLv3 双向兼容）、ONNX Runtime（MIT）。
没有 GPL-2.0-only 这类与 AGPL 不兼容的依赖。
## 落在哪些地方
- `README.md` / `README_EN.md`：新增「许可 / License」章节，写明 §13 的含义、
插件因**静态链接 SDK 源码**而成为衍生作品须同许可发布、以及随包第三方组件清单
- `deploy/packaging/package-linux.sh`：
· 新增 `stage_license()`，**四个变体（full/server/client/tar）全带**
`/usr/share/doc/homeagent/{LICENSE,copyright}`（copyright 为 DEP-5 机器可读格式，
含第三方条目）
· fpm 的 `--license "Proprietary"` → `"AGPL-3.0-only"`
- `deploy/packaging/installer.nsi`：新增 MUI 许可页
（`..\..\LICENSE`，NSIS 以 .nsi 所在目录解析相对路径）
- `third_party/homeagent-sdk/LICENSE`：vendored SDK 的许可一并入库 —— 本仓
`.gitignore` 有意不镜像 SDK 的 README/tools/package/example，但依赖的许可
应当随依赖可见
## 待办（下一步）
README 的「项目状态」仍停在 v1.1.1，且写着已被 v1.2.0 **删除**的机制
（引用计数式 GC、`[<mime> <digest>] <描述>` 描述式索引）——单独一个提交修。
2026-09-12 09:17:03 +08:00
ecc568077d
docs(git): 修正上一提交的错字（但声两仓 → 但两仓）
2026-09-12 09:01:59 +08:00
e9db929f1f
docs(git): 写清「两仓 main 同步推进」的前提，修正 SDK 路牌
...
§七.4 原来只说「在 1.1.x 线发布期间，两仓 main 上的值都是 1.2.0」，容易被读成
「两仓 main 永远同值」，我正是据此把 SDK main 也推到了 1.3.0（已回退为 1.2.0）。
补写前提：推进以**该中版本已正式发布**为条件。
- 核心切出 release/v1.2.x 后 1.2.0 归发布线所有 → main 立即到 1.3.0（beta 也算占号）
- SDK 因 §七.2（beta 不发 SDK）要等核心正式 tag 才定版 → 在那之前 main 停在 1.2.0
并明确：**此阶段核心 main(1.3.0) 与 SDK main(1.2.0) 故意不对称**，
不是遗漏同步。§三 的 SDK 表行同步修正。
2026-09-12 09:01:34 +08:00
5932fd4eb4
fix(sdk-mirror): vendored SDK 路牌回到 1.2.0（SDK 不跟 beta 发版）
...
SDK 仓 44bd915 把 main 的 meta.Version 推到 1.3.0 是错的（12cabcb 已改回 1.2.0）。
按 §七.2，beta 不伴随 SDK 发版：SDK 1.2.0 要等核心的**正式** tag 才定版打 tag
（§七.3），在那之前 1.2.0 仍是 SDK 尚未发布的中版本，路牌不得越过它。
核心 main 的 1.3.0 不受影响（1.2.0 已归 release/v1.2.x 所有），两仓在此阶段
故意不对称——这一点已写进 SDK meta.go 的注释，避免再被「对齐」回去。
本提交只同步 core 里跟踪的镜像：sdk/ 目录与 SDK 仓仍然逐字节一致。
2026-09-12 09:00:41 +08:00
3d1eb7a1ab
docs(git): 1.2.x tag 历史补上 v1.2.0-beta.1
...
release/v1.2.x 已按 §2.4 走出 beta 通道：tag v1.2.0-beta.1（提交 215804c），
注释里写明通道、不兼容点与验收证据；beta 阶段不发 SDK（§七.2）。
正式 tag 待试运行无回退问题后再打，届时同步 SDK 仓。
同时把 tag 名资产整理记录在案：历史大写 tag V0.8.0 / V0.7.1 已按用户确认删除
（提交本身未受影响），现在主仓 tag 全部符合 SemVer 小写 v 约定。
2026-09-12 08:54:09 +08:00
a5408a1efe
build(packaging): 统一 -buildvcs=false，版本/提交只认 ldflags 注入
...
发布分支的产物上出现了 `vcs.revision=1715b5c`——一个本机任何仓库都不存在的提交。
原因：VCS 信息**不进 build cache key**（Go 文档明确说明 VCS 变化不会触发重建），
命中缓存时会把上一次的 revision 一并带回来。
而 build.sh 本来就用 ldflags 注入 meta.Version / meta.Commit（权威来源），
所以这个额外信号既不可靠又会误导溯源：拿 `go version -m` 去查源码提交，会指向
一个幽灵提交——正是本项目一直在治的「静默不一致」。
处置：三处 go build 统一 `-buildvcs=false`，并在 LDFLAGS 旁写明溯源方法
（`strings homed | grep -x '<短 hash>'`，meta.Commit 是字符串常量）。
验证：重新构建 homed linux/amd64 →
· `go version -m` 中 vcs.revision 0 处（此前 1 处且是错误值）
· strings 中恰好 1 处等于当前 HEAD 短 hash
· `-tags=onnxruntime` 仍在
2026-09-12 08:42:18 +08:00
d108140c6e
docs(git): 分支对齐更新到 2026-09-12（1.2.x 线开启）
...
- main 路牌调到 1.3.0；release/v1.2.x 承载 1.2.0（vendored SDK 定版 1.2.0）
- release/v1.1.x 按 §2.6 退役（保留供追溯）；两个历史 feature 分支
（memory-media / plugin-proc-migration）已从远端删除，旧表待删项清掉
- 新增「1.2.x 发布线 tag 历史」表（当前尚无 tag），并写明它与存量插件
**不兼容**（RPC 协议 2、fd3 布局改变、不支持滚动升级）以及
**不满足 §2.4 跳级条件**的理由（改动面大，非单点修复）
- SDK 仓的 release/v1.2.x 尚未创建：按 §七.3 随核心**正式** tag 一起做
2026-09-12 08:39:05 +08:00
679c31cf8e
fix(knowledge): 覆盖同名条目时摘掉旧向量
...
从一次真实的知识库更新里发现：在线实例更新一个已有条目之后，
knowledge_count=32 而 vector_count=33——多出来的那一条是上一版的副本。
成因：vector.Store.Insert 是**追加**语义（s.docs = append + index.Add），不按 id 去重；
而 Store.Add 走的是「写 content.md + 覆盖 items[id] + Insert 向量」。
文件与内存条目都被正确替换了，只有向量索引多留了一份。
危害不在于多占内存：**检索可能命中已被替换掉的旧内容**，而且完全静默——
条目数看起来是对的，只有向量数比条目数多。
修法：Insert 之前先 s.vec.Remove(id)（Remove 已按 id 过滤 docs 与倒排索引）。
回归测试 TestAddOverwriteReplacesVector 钉住 knowledge_count / vector_count /
content.md 三者都必须只剩新版。
注：该文件在 origin/main 上本就有 32 行 gofmt 差异（结构体字段注释对齐），
不属本次改动，按纪律不做整体重排。
2026-09-12 08:30:22 +08:00
633de87580
fix(build): GUI 输出目录用 --config.directories.output，-o 是 --mac 的别名
...
electron-builder 的 `-o` 是 `--mac`/`--macos` 的短别名（见 --help 的
Building 段），不是 output。于是 `-o "$BUILD_DIR"` 被当成 macOS 的 target
列表，报：
⨯ Unknown target: /home/program/trueagent/build
路径被 lowercase 后去匹配 target 名表，所以错误信息里的路径是全小写的
——这也是它看起来像「路径错」而实际是「参数位置错」的原因，v1.0.1 与
v1.0.3 两次发布都因此手工组装过 GUI。
改用 --config.directories.output=<dir>，已实测确认产物落在指定目录。
同时把 GUI 构建失败降级为警告：homed/waiter/initconfig 是发布主体，
而 GUI 依赖 electron 运行时下载（离线机器、arm64 缺缓存都会失败）。
set -euo pipefail 下不接住的话，一个可选组件会让整轮跨平台构建全废——
v1.0.3 就是这样只产出了 linux/amd64 三个二进制、arm64 与 windows
压根没跑到。
2026-09-12 08:26:12 +08:00
dc8620d28f
chore(meta): main 的版本路牌推到 1.3.0
...
按 docs/git-branching.md §2.1，main 的 meta.Version 始终是**下一个未发布中版本**。
1.2.x 线已开（release/v1.2.x 承载 1.2.0），所以 main 指向 1.3.0。
它标记「main 正在积攒 1.3 的东西」，不表示 1.3.0 已经存在——1.3.0 没有任何 tag。
1.2.0 已由 release/v1.2.x 承载；main 不能再挂着 1.2.0，否则 main 的版本号
就与某一次发布的版本号相同，违反 §2.1「main 的版本号不是任何一次发布的版本号」。
两仓同步：SDK 仓 main 也在同一时刻推到 1.3.0（commit 44bd915）——SDK 版本跟随
核心中版本（§七.1），且两仓 main 都表示下一个未发布中版本（§七.4）。
本 commit 同时把 vendored SDK 镜像（third_party/homeagent-sdk/meta/meta.go）
更新到与 SDK 仓一致。
SDKCompatibleVersion 保持 1.2.0：那是本内核**实际实现并兼容的最高 SDK 接口版本**，
与「下一个未发布中版本」是两件事（参见 0dee567
2026-09-12 08:25:30 +08:00
62d4ba2742
style: gofmt 两处对齐（graphmedia_test.go 注释、tfidf.go 结构体字段）
...
这两处是本次特性分支带入的格式回归（origin/main 上不脏）。
纯空白/对齐调整，无语义变化；不整体重排文件。
2026-09-12 08:23:30 +08:00
0cba58d82c
merge: 多模态统一向量空间与子进程数据面收敛（feature/multimodal-embedding）
...
合入 43 个提交，主线内容：
- 统一多模态向量空间：公共 provider SPI（pkg/embedding）+ 注册表，
chineseclip 为 text+image 默认空间（512 维，Apache-2.0），qwen3vl 保留
- 共享内存接管全部数据面：工具调用帧、Cleaner、输入/输出 lane、媒体块、
文档/知识正文；RPC 只传偏移描述符（协议版本 2）
- 图记忆原生媒体节点：媒体是一等节点与边，删除 media_refs 与描述式索引
- 注入行为可声明 no_memory / context_policy（默认不裁剪）
- SDK 1.2.0：注入标志位纯追加 + 示例 hmap 随发版
- 发行包默认启用 ONNX 向量空间；本批起模型与运行库随 server/full 包发布
- homed 放弃 Windows 原生支持，改走 WSL2
2026-09-12 08:21:34 +08:00
503b1149af
chore(sdk): 同步 vendored SDK 镜像到 1.2.0
...
core 仓里跟踪的 SDK 镜像落后于 third_party/homeagent-sdk（那是个独立仓库）：
已提交的 sdk/memory.go 仍带 MediaAttachment.Description，而 SDK 仓 b2eafdf 已把它
删掉（媒体不再以文本描述参与索引）。磁盘上的文件其实就是 SDK 仓当前的版本，
只是 core 的索引没有跟上——于是**干净检出 main 拿到的是一个与它构建所用 SDK
不一致的镜像**。
clean worktree 能编译（内核已不再引用 Description），所以这个不一致不会被构建
发现，只能靠比对发现——属于本项目一直在治的「静默不一致」。
同步内容：sdk/memory.go 与 SDK 仓 HEAD 逐字节一致。
2026-09-12 08:21:21 +08:00
c01d8e864e
feat(packaging): 模型与 ONNX Runtime 随 server/full 包发布
...
模型与运行库是发行版能力的一部分，不做成「装完再自己下载」：
- package-linux.sh：新增 stage_multimodal_assets()，打 server/full 前校验产物
SHA256SUMS、逐文件非空、运行库架构与目标一致，缺一即失败；client 包不含。
顺带修掉三个让打包在最后一步才炸的既有缺陷：
· 版本串直接取 git describe（v1.0.0-68-gxxx-dirty）不是合法包版本——deb 要求
数字开头、rpm 不允许 '-'。以前只有显式 VERSION=1.0.3 才打得出来；默认路径
从来没通过过。现在归一化，非数字开头时显式报错。
· 三处 mktemp -d 落在 /tmp（本机 9.8GB tmpfs），而 staging 要复制 719MB 模型，
中途 ENOSPC；报错文本指向某个 .onnx 文件，看着像资产坏了。改为落在与构建产物
同盘的 build/.stage-tmp。
· 开工前删掉旧的 SHA256SUMS：失败时脚本直接退出、不重算，留着像在为残缺产物背书。
- setup.sh：把包内 /usr/lib/homeagent/models/chinese-clip-vit-b16-onnx 软链到
<dataDir>/models/…（不复制 754MB、保持 dataDir 可迁移、已有自定义目录不覆盖）
- homeagent.service：ExecStart 改 /usr/bin/homed（deb 装在那里，此前写 /usr/local/bin，
装了也不会被 unit 用上）、加 ONNXRUNTIME_DIR 与 StateDirectory、MemoryMax 2G→8G
（实测常驻约 4.5GB，2G 会在首次全量建索引时被 cgroup OOM）
- control-{full,server}：补 libstdc++6 / libgcc-s1（libonnxruntime.so 需要）
- providers/{chineseclip,qwen3vl}：findOnnxLib 支持 ONNXRUNTIME_DIR / ONNX_ML_DIR
与包内 /usr/lib/homeagent/onnxruntime，随包的运行库才真的会被用上
- postinst：修掉两个让「装完即用」失效的点——它检查 /lib/systemd/system/ 下的 unit
而 deb 装到 /etc/systemd/system/，于是 daemon-reload/enable **从未执行**；以及
setup.sh 的失败被 `|| true` 吞掉（正是 initconfig 静默缺陷被藏住的原因）。现在
三个候选路径都查、失败可见并给出补救命令、首装 start / 升级 restart。
- docs/zh/multimodal-space.md：新增「随包分发」一节，并修正播种判据的说明
验收（从真实 deb 走一遍，不是读脚本）：
- 包内 initconfig 已是动态链接，凭据真的写进 config.db
- 解包 → 按 postinst 顺序跑 setup.sh → 包内 homed 冷启动：
multimodal space active: provider=chineseclip dim=512 fp=cd2a495cf990
modalities=[text image]
- 全新安装的默认值确实被播种（core.plugin.dir / provider / model_dir 都在）
- 真实对话拿到回复（3.4s，回复中含唯一标记）
- 包内模型 SHA256SUMS 5/5 通过；包内 ORT 与源同 sha256；server 包 722MB
（旧版 17MB，差额即模型与运行库）；full 包同样含全部资产；client 包不含
2026-09-12 08:10:44 +08:00
3f772d6e94
fix(config): 全新安装的默认值播种判据改为显式标记
...
播种判据曾经是「config 表为空」。而发行包的 postinst 先跑 setup.sh →
initconfig，后者会写一行 webui.listen_addr，于是**全新安装**被判定为
"已有配置"并整体跳过播种：没有 core.plugin.dir（装完 0 个插件）、没有
core.memory.* 路径、也没有随包模型对应的多模态 provider——754MB 产物与
24MB 运行库全成死重量。同样的机制此前已在协议 2 迁移演练里被观察到。
也不能改成"每次都补缺键"：老安装升级时被注进新默认值，会让它突然去加载
一个 1.8GB 的模型，那是刻意要避免的静默变重。
故改为显式标记 core.internal.seed_version：
有标记 → 已播种，返回
无标记但有 core.daemon.data_dir → 老安装，只补标记、不播种
两者都没有 → 全新安装，播种并打标记
测试：TestSeedDefaultsAfterInitconfigPrepopulate（精确复现 initconfig 的
那一行写入）、TestSeedDefaultsDoesNotInjectIntoLegacyInstall。
2026-09-12 08:10:34 +08:00
2bf0a0d4de
fix(initconfig): 必须带 cgo 构建，且失败不再静默
...
cmd/initconfig 通过 database/sql 使用 mattn/go-sqlite3，而 build.sh 一直用
CGO_ENABLED=0 构建它：该库在非 cgo 下退化成 static_mock.go 里的桩，sql.Open
是惰性的所以不报错、第一次 Exec 才失败，而 main.go 丢掉了所有返回值。合起来
是一个完全静默的空操作——打印凭据、退出码 0、config.db 里一个字节都没写。
安装脚本把这份凭据写进 credentials.txt，用户照着登录必然失败，全程无报错。
- build.sh: initconfig 改 CGO_ENABLED=1，并写明为何不能图省事去掉 cgo
- main.go: 每个 Exec 都检查；写完**回读比对**（不看返回码，看真实落盘内容），
不一致即非零退出
反向验证：仍用 CGO_ENABLED=0 构建时，现在 stderr 报
"Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work"
且 exit 1（此前是 exit 0 并把凭据照打印出来）。
2026-09-12 08:10:26 +08:00
a328dfe31d
feat(release): 发行版默认启用本地向量空间（onnxruntime 标签 + chineseclip 默认）
...
用户要求：后续发行版默认带 ONNX 模型能力。这条要求落到两处，并顺带修掉一个
被它**暴露出来**的真缺陷。
## 1. 构建默认带 onnxruntime（deploy/packaging/build.sh）
`HOMED_TAGS` 默认 `onnxruntime`，需要极简构建时显式 `HOMED_TAGS=` 关闭。
不带标签时 provider 仍注册、但打开即报「requires build tag」并优雅降级——
不静默假装成功。运行期还需要 `libonnxruntime.so`（provider 按
/opt/onnxruntime、/usr/local/lib、/usr/lib 顺序查找），缺失时同样是
「日志里明确错误 + 降级」。
## 2. 新装默认选 chineseclip（internal/config/registry.go）
`SeedDefaults` 写入：
core.memory.multimodal_space.provider = chineseclip
core.memory.multimodal_space.options.model_dir = <dataDir>/models/chinese-clip-vit-b16-onnx
选它而不是 qwen3vl：后者实测常驻 9.4GB，多数机器装不下；chineseclip 是
1.99GB（实测，见下）。同时更新两个 ConfigDef 的默认值与描述（WebUI 显示用）。
**老安装不会自动拿到这两个默认值**，这是有意的：`seedDBValues` 对非空配置库
直接返回，`GetString` 缺键时回落到调用方默认值（main.go 传的是空串）。
升级就静默加载 ~1.8GB 模型不是无副作用的事，应由部署显式开启。已写进文档。
## 3. 修掉 ORT 环境被重复初始化 + 误销毁（internal/nlp/onnx.go）
这是「默认带标签」才暴露的缺陷：此前不带标签时进程内不会有多个 ORT 消费者。
- `NewONNXParser` 无条件 `InitializeEnvironment()` → 若多模态 provider 先初始化，
这里报「The onnxruntime has already been initialized」并**降级**（实测日志：
`ONNX parser init: init onnx env: ... using fallback`）。
- 更严重的是失败路径与 `Close()` 里的 `DestroyEnvironment()`：它会把别人
（多模态 provider）正在用的进程级环境一起拆掉，让对方的会话失效。
改为：初始化前先 `IsInitialized()`；**任何消费者都不销毁环境**（随进程存活），
只销毁自己的会话。providers/chineseclip 与 providers/qwen3vl 本来就是这个约定，
现在三处一致。
## 验证（实测）
- 全新数据目录启动：配置库出现上述两个默认值。
- 模型未安装：`multimodal space active` 不出现，代之以明确错误
（点名缺失的 embed_config.json 路径 + 已注册 provider 列表）+ 降级，不静默。
- 模型就位：`multimodal space active: provider=chineseclip dim=512 fp=cd2a495cf990
modalities=[text image]`。
- 内存：同一份 homed，启用时 RSS **1.99GB**（峰值 2.09GB），不启用 **0.17GB**。
- NLP 修复：日志由 `ONNX parser init: ... using fallback` 变为 `dep parser initialized`。
- 构建矩阵：`go build/vet ./...` 与 `-tags onnxruntime` 两种都过；
`bash -n deploy/packaging/build.sh` 通过。
## 未做（明确记录）
- `libonnxruntime.so`（24MB）与 Chinese-CLIP 产物（754MB）目前都需自行安装/导出，
发行版尚未打包它们。若要让「默认启用」在干净机器上真正开箱可用，需要决定
是随包分发、安装时下载、还是保持文档指引。
2026-09-12 00:10:32 +08:00
929fb94e7a
feat(memory): 新增 chineseclip provider —— text+image 的小体积可商用向量空间
...
## 为什么
用户决定「本轮不覆盖 video，先支持 text+image」。这一刀正好解锁了此前
「小 + 可商用 + 覆盖视频」三者不可兼得的僵局：不要求视频后，唯一同时满足
**小、可商用、中文原生** 的选项是 Chinese-CLIP ViT-B/16。
实测对比（同机、真实跑出来的数字）：
| | Chinese-CLIP | jina-v5-omni-nano | Qwen3-VL-Emb-2B |
|---|---|---|---|
| 参数量 | 188M | 1.04B | 2B |
| 产物 / 常驻内存 | 754MB / **1.15GB** | ~2GB / 2.23GB | 8GB / 9.4GB |
| 维度 | 512 | 768 | 2048 |
| 许可 | **Apache-2.0** | CC BY-NC（不可商用） | Apache-2.0 |
| 视频 | 无 | 有 | 有 |
本机可用内存只有 5.3GB，Qwen 的 9.4GB 无法进程内使用；而 ORT format + mmap
那条路被证实当前不通（转换器对三段图段错误；走通还需同时升 ORT 运行时与
Go 绑定，v1.36 要求 API 29 而本机只有 28）。1.15GB 则可以直接进程内跑。
**代价已写进包注释与文档**：CLIP 是双塔对比学习，text↔image 是强项，但纯文本
语义明显弱于 MLLM 型嵌入器；文本检索仍由既有词向量/TF-IDF 路径兜底。
需要更强文本语义或视频时切回 qwen3vl。
## 内容
- `providers/chineseclip/`：按公共 SPI 实现的 provider（注册名 `chineseclip`），
含 BERT WordPiece 分词器、图像预处理、ONNX 双塔推理、无标签 stub。
- `scripts/export_chineseclip_onnx.py`：从官方权重导出规范产物 + 冻结参考，
自带逐用例 PyTorch 对比与覆盖度断言（计划集合≠执行集合即非零退出）。
- `cmd/homed/main.go`：空白导入两个 provider，由配置选其一。
- `go.mod`：`golang.org/x/text` 由间接依赖转为直接依赖（删音标需要 NFD）。
## 实现要点
- **分词器逐 token 对齐官方**。第一版探针自己拼 BertTokenizer（只给 vocab.txt、
没删音标、中文没逐字切），中文被整体切成 [UNK]，三个不同句子产出几乎相同的
向量（余弦 0.98）——差点把「模型坏了」当成结论。官方配置是 do_lower_case=true
+ 删音标生效 + 中文逐字切分；`TestTokenizerMatchesOfficialReference` 钉住
逐 token 一致。
- **图像缩放自写 bicubic**（复刻 PIL 的 precompute_coeffs + a=-0.5 核），不引
golang.org/x/image：它未进本机模块缓存，且最新版要求把整个工具链升到 Go 1.26，
为一个缩放函数动工具链不划算。
- **归一化在 provider 侧**（两个塔的图里都没归一化），检索按余弦。
- **指纹覆盖全部影响语义的产物**：两个 ONNX 图 + vocab.txt + embed_config.json，
读不到就写 MISSING（跳过等于对缺件不敏感）。
- 会话 Run 用 runMu 串行化（ORT 会话不保证并发安全），创建/销毁用 mu。
## 模态范围
只声明 `text` 与 `image`；`audio`/`video` 明确返回 `ErrUnsupportedModality`，
绝不用别的模型向量冒充（这是「音频明确 unsupported」纪律的落地）。
## 验证（实测）
导出侧：10 个用例（5 文本 + 5 图像）ONNX vs 官方 PyTorch 全部
`cos = 1.000000000`，覆盖度断言 10/10 通过。
Go 侧（`CHINESECLIP_MODEL_DIR=... go test -tags onnxruntime ./providers/chineseclip/ -v`）：
11/11 通过，其中
- 文本 5 用例 `cos = 1.000000000000`（逐位一致）
- 图像 4 纯色用例 `cos = 1.000000`（与官方预处理在 6 位小数内一致）
- 跨模态判别：红图对「红色」文本高于「蓝色」文本
- 模态拒绝 / 空输入 / 指纹稳定 / 产物缺失报错
顺带修掉测试自身的一个假通过：参考向量是**未归一化**的原始输出（模长 10~36），
原先「点积当余弦 + 单侧下界」会让 13.6 也判过，已改为真余弦 + 双侧容差。
构建矩阵：`go build/vet ./...` 与 `-tags onnxruntime` 两种都过；
`providers/... pkg/... internal/config/... internal/memory/vector/...` 回归通过
（qwen3vl 的 TestVideoModelInputMRope 需要 QWEN_ONNX_MODEL_DIR 指向含视频档的
v3 目录，缺该环境变量时用的是只有文本+图像的目录，与本改动无关）。
## 未做（明确记录）
- 发行版默认 provider 与构建标签变更：留下一提交（涉及打包与模型分发策略）。
- 模型产物（754MB）不进仓库，由导出脚本生成。
2026-09-11 23:58:53 +08:00
f868975c0e
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
6f8525cd83
refactor(memory): 核心不再适配具体模型——公共 embedding provider SPI + 注册表
...
问题：cmd/homed 里 `case "onnx": qwen.New(modelDir)` 把模型适配写进了核心，
`type=onnx` 名义上是格式、实际写死了一个模型家族；2117 行 Qwen 专属代码
（BPE、chat template、M-RoPE、Vision_gN 命名）住在内核树里，还带着一对
`//go:build onnxruntime` 的 stub。加任何新模型都要改内核。
现在核心只认一个模型无关的公共契约（pkg/embedding）：
- 输入是不透明的 Data+MIME，解码/预处理/时序分组全归 provider
- 能力是数据（Info.Modalities），不是接口方法——新增模态无需改核心接口
- 不支持的模态返回 embedding.ErrUnsupportedModality（可 errors.Is 识别）
- 按名字注册，重复注册 panic；Options 是 provider 私有命名空间，核心不解释
改动：
- 新增 pkg/embedding：Modality/Purpose/Input/Info/Provider/Config + 注册表
（Open 校验 Info，ValidateVector 在入库前拦下维度错与非有限值）
- providers/qwen3vl：Qwen 实现整体移出内核（git mv），实现公共 SPI 并自注册
- internal/memory/vector：新增 ProviderAdapter（公共 SPI → 内部小接口）；
ErrModalityUnsupported 改为公共哨兵别名；删除 VideoEmbedder 可选接口
（那正是「核心为每个新模态长方法」的坏味道）
- http embedder 也变成普通 provider（注册名 http）
- cmd/homed：删除 qwen import 与 onnx/http 分支，改为按 provider 名打开 +
透传 options.*；provider 打开失败只警告并禁用多模态检索，不影响启动
- config：multimodal_space.type/onnx./http.* → provider + options.*
- 删除 internal/memory/qwen（整体搬迁）
测试：
- pkg/embedding：注册表隔离/未知名字/非法 Info 自动关闭/ValidateVector
- vector：适配器原样透传字节与 MIME、维度错被拦、Close 幂等且停止使用、
两个哨兵 errors.Is 互通
- providers/qwen3vl：新增公共 SPI 全链路集成测试（Open→Info→Embed→
未知模态哨兵），并明确断言 Info 不声明 video
已知未完成（不得当作已验证）：
- 视频冻结回归 TestEmbedderVideoMatchesONNXReference **显式跳过**：Go 侧
video 模板缺少 processor 按时间组插入的字面时间戳文本
（<0.0 seconds>/<1.0 seconds>），同一输入 Python seq=1190(1152+38)、
Go 只有 22 个文本 token。时间戳也占 M-RoPE 位置，故现有 M-RoPE 自洽断言
通过不能证明与官方实现一致。修复属 provider 内部工作。
- 视觉侧三档已导出并逐档校验通过（cos 1.000000119/1.000000119/1.000000000）
验证：go build ./... ；go vet -tags onnxruntime ./... ；
go test -short ./internal/memory/... ./internal/agent/core/... ./internal/sdk/... ./pkg/...
；onnxruntime 下 providers/qwen3vl 全绿（视频为显式 skip）
2026-09-11 18:26:19 +08:00
1de1b5598d
feat(memory): 千问三段式 ONNX 嵌入补齐——可复现导出脚本 + Go 侧首次完整验证
...
此前三段式拆分后 ONNX 路径从未从 Go 侧跑通：embedder_onnx_test.go 仍引用
分段前的 API（e.renderInput、TextTower.onnx、旧目录），go vet -tags onnxruntime
直接编译失败。导出脚本只在 /tmp 且硬编码本机路径、从第三个目录拷贝固定形状的
Vision.onnx，完全不可复现。音频会被视觉塔编码，静默往统一空间灌入错误坐标。
本提交补齐这些缺口：
一、可复现导出脚本（scripts/export_qwen3vl_embedding_onnx.py）
- 自动拉取模型（HuggingFace 优先，失败回落 ModelScope，支持 HF_ENDPOINT 镜像）；
- 导出 TokenEmbedding + Transformer + Vision 三段图，图文共用同一 token
embedding、28 层 Transformer、last-token 池化与 fingerprint；
- 双重自检（不可省）：分段 PyTorch vs 完整模型 + 导出后的 ONNX vs 完整模型，
cos < 0.999999 即非零退出——「能加载」不等于「算得对」；
- 默认把 L2 归一化后的冻结参考向量写入产物目录（qwen_reference.json）——
Go 测试据此做逐维冻结回归，且「该目录是哪次导出的」从文件本身可追溯；
- --verify-only 校验既有产物不重新导出，可用来确认线上在用的图没坏。
关键实测结论（已写入 docs/zh/multimodal-space.md 与长期记忆）：
原生多帧视频不可行——Qwen3-VL 视觉塔把 grid_thw 当 Python 值消费
（grid_thw.tolist()），legacy tracer 固化为常量，导出后图中根本没有 grid_thw
输入，换帧数调用直接 Invalid input name: grid_thw。故视觉塔固定 (1,48,48)，
视频由上层抽帧后逐帧按图像编码（同模型/同维度/同 fingerprint），音频明确
unsupported。
二、模态边界（vector.ErrModalityUnsupported）
- 新增 vector.ErrModalityUnsupported：表示「该模态不在本统一空间的原生覆盖
范围内」，与普通错误语义不同——调用方应把它当「永远不会有向量」而非
「本次失败、下次重试」；
- qwen.EmbedImageDense 按 mime 拒绝 audio/* 与 video/*：此前它会拿视觉塔
去解音频字节，往统一空间灌入语义错误的坐标且静默；
- reembedStaleMedia 对 ErrModalityUnsupported 不计失败、不重试、不用别的
模型向量顶替（TestReembedStaleMedia_SkipsUnsupportedWithoutFaking 守住）。
三、Go ONNX 测试首次完整通过
- 重写 embedder_onnx_test.go：修复编译 + 文本冻结回归 + 图像冻结回归 +
两条阴性对照（不同输入必须不同、图像与文本必须不同）+ 不支持模态断言；
- 参考值从产物目录的 qwen_reference.json 读取（不在测试里硬编码浮点）；
- 用线上部署产物实测全部通过（text cos=0.999999940, image cos=0.999999762）。
四、.gitignore 修复
- /scripts/ 此前被列在「运行时产物」下，但它是作者维护的工具目录
（模型导出、侧车、部署校验），deploy/systemd/embed-sidecar.service 直接
引用 scripts/embed_sidecar.py，忽略它会让那份 unit 在别人的机器上指向
不存在的文件。改为只忽略 __pycache__。
五、文档（docs/zh/multimodal-space.md）
- 获取/启用/产物契约/模态边界/验证/资源成本/与现有部署产物的等价性。
验证：go build ./...、go vet ./...、go vet -tags onnxruntime ./...、
go test -short 全部通过；ONNX 标签测试对线上部署产物全部通过。
2026-09-11 13:45:25 +08:00
e48b4bb006
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
2330db8a2b
refactor(memory): 移除 media_refs/引用计数，媒体成为一等记忆块
...
媒体此前是"文本块 + digest 引用 + owner 账本 + 独立 GC"：ContextEvent.Media
记 digest，media_refs 表用 owner_kind/owner_id 保活，ref_count 决定 GC 能否清。
这与文本记忆块的管理方式不一致，也是本次一并纠正的核心偏差。
改为与文本块完全一致的生命周期：
1. 一等记忆块直接由所在层持有
- ContextEvent.Blocks / Doc.Blocks / GraphDB memory_blocks
- 块带 modality/digest/MIME/size/vector/fingerprint，文本、图片、视频同构
- Context→Document→Graph 迁移的是块本身（ID 不变），迁移后清空源容器，
同一块不同时存在于两层
2. 删除平行生命周期账本
- media.Store 去掉 media_refs 表、OwnerKind 常量、RefCount 字段、
AddRef/DropRef/DropOwner/Refs、ref_count 列与索引
- 删除 mediaGCLoop、GC(keep,minAge)、容量上限与 media.gc_* / media.max_mb 配置
- 媒体内容在块被永久删除时一并删除（media.Store.Delete + forgetPayloads），
与"删除文本块即删除内容"同一语义
3. L3 原生结构
- memory_blocks / memory_block_edges（contains/depicts/derived_from）
- 边端点必须是真实图节点，不再用 owner 字符串伪装关系
- BlocksForNode 支持 sentence --contains--> block 反查
4. SDK 与检索同步
- 插件附件/标记直接变成块，不再 AddRef
- 跨模态检索改用 QueryMediaScored（CAS 内不再有孤儿缓存需要过滤）
测试全部改写为块语义：删除 refcount/media_refs/GC 断言，新增块迁移、
单层不变量、Delete 语义与并发删除回归。
注：cmd/homed/main.go 同时携带工作区中既有的 CLIP→Qwen 模型目录接线改动。
2026-09-11 10:57:22 +08:00
46f833cb79
feat(memory): Graph 原生一等记忆块节点与结构边(§13.12)
...
媒体/文本在 L3 不再是正文标记反解出的代理实体，而是带原生
modality/digest/MIME/size/vector/fingerprint 的 memory_blocks 节点；
contains/depicts/derived_from 等语义边落在 memory_block_edges，
端点必须是真实图节点（block/entity/sentence），不复用 owner 字符串。
本步只建立存储与查询能力，不接入 media_refs，也不改变 L0/L2 路径。
2026-09-11 10:08:59 +08:00
77bccbb96a
fix(memory): 千问文本塔补齐 tokenizer post_processor 与真实 ONNX 回归
...
验证 Go 端到端路径时发现：HuggingFace 的 tokenizer.json 带 TemplateProcessing
post_processor，规则是 `$A <|endoftext|>`——即每段输入末尾都会追加一个
`<|endoftext|>`(151643)。它正是图内 last-token 池化的锚点：
- 漏掉它：ONNX 仍能运行（不会报错），但池化取到的是模板末尾的 assistant
起始符，而非 post token，整条嵌入向量与上游不一致；
- 截断语义：HuggingFace 在 truncation=true 时先把正文截到 maxLen-1，
再保留末尾 post token（实测 600×"记忆"→ [511 正文][151643]）。
改动：
1. Tokenizer 新增 encodeModelInput(text, maxLen)：Encode 后追加 post token，
并在超长时先截到 maxLen-1；缺 <|endoftext|> 直接报错（防静默错误）。
2. Embedder.VectorizeDense 改用 encodeModelInput。
3. 测试：
- TestEncodeModelInputPostProcessor：短文本+post token；长文本按 512 截断
且尾 token 为 post token（用 600×"记忆"确保真的触发截断分支）。
- embedder_onnx_test.go（onnxruntime 标签）：用 Python onnxruntime 1.28
生成的冻结参考向量验证完整 Go 路径（模板渲染→BPE→ONNX→L2 normalize），
逐维 diff ≤ 2e-5；同时断言模型输入恰好 23 token 且末尾是 post token。
产物不在时跳过（与 tokenizer_test 相同约定）。
- 修正先前测试误用 400×"记忆"：BPE 把"记忆"合并为单 token，400 次只有
400 token 不触发截断；改用 600 次后确实走到 maxLen-1 分支。
其余（ORT 库路径、指纹纳入 .onnx.data）一并随本提交带上。
验证：go test ./internal/memory/qwen 与 -tags onnxruntime 全绿；
FP32 图与 PyTorch 在短/长/等长批次/真实 padding 批次上余弦均 ≥0.99999994。
2026-09-11 03:09:01 +08:00
e1bdc2ab27
feat(memory): 千问文本塔 ONNX 嵌入器（onnxruntime 标签，含 stub）
...
与 internal/memory/clip 同模式：`//go:build onnxruntime` 编真实实现，无标签时
走 stub，默认构建不链接 onnxruntime、行为不变。
加载契约（目录由 core.memory.multimodal_space.model_dir 指定）：
TextTower.onnx + 外部权重分片、tokenizer.json、embed_config.json。
图内已含 last-token 池化，输出即 [batch, dim]；L2 归一化在 Go 侧做。
两个刻意的设计选择：
1. **EmbedImageDense 明确报错，不返回零向量**
导出的是文本塔，视觉塔未导出。返回零向量会让「写入了但检索不到」，
把跨模态检索失效变成静默故障；明确报错则调用方（mediaref.go）log 后
跳过写向量，文本路径不受影响。
2. **Fingerprint 只哈希图文件 + 配置 + 外部权重的文件名与大小**
该目录有 6.5GB 权重分片，启动时全读一遍要几十秒、会阻塞 homeagent 启动。
换模型必然改变文件集合或大小，足以识别切换；代价是理论上存在
「大小相同但内容不同」的漏判，对本地单机部署可接受。已写入注释。
模板渲染（renderInstructionInput）放在无构建标签的 tokenizer.go，因此可被
测试覆盖：参考数据里有该模板串的用例，逐 token 对齐验证——模板差一个字符，
池化取到的「最后一个有效 token」位置就变，向量就不同，且不会报错。
验证：6 个测试全绿；go build ./...（stub）与 go build -tags onnxruntime
（真实实现）均通过。
2026-09-11 00:16:45 +08:00
4712d945e8
feat(memory): 千问字节级 BPE 分词器 + 与上游逐条对齐的回归测试
...
为「千问嵌入模型导出 ONNX 并内嵌」的 Go 侧准备。CLIP 那套 tokenizer 不能复用：
CLIP 是「小写化 + 空白规整 + 词表 BPE」，千问是 **GPT-2 式字节级 BPE**
（先按字节映射到安全 unicode，再对映射结果做合并），中文与空白输入的切分
完全不同。
实现中撞到两个与上游对齐的坑，都由测试暴露：
1. **`\s+(?!\S)` 的语义依赖正则回溯**，不是「等价于 `\s+`」。
`\s+` 先贪婪吃完整段空白，发现后面是非空白导致 `(?!\S)` 失败，于是回退
一个字符，**正好留下末尾一个空白**给前面以 ` ?` / `[^…]?` 开头的分支合并。
这直接决定切分点：`" leading"` 会切成 `" "` + `" leading"`，
而不是 `" "` + `"leading"`。RE2 不支持 lookaround，近似改写必然对不上，
所以改成按分支顺序**显式实现**（含 `\s*[\r\n]+` 的回溯语义）。
实测：近似改写时 26 条里错 3 条，全部是空白串用例。
2. **Go 的 `\s` 只有 ASCII，且 regexp 不支持二进制属性 `\p{White_Space}`**
（只支持 script/category，直接写会报 invalid character class range）。
而上游 Rust regex 的 `\s` 正是 White_Space。改用 `unicode.IsSpace` 作为
唯一判据，避免全角空格/NBSP/行分隔符的切分点漂移。
另外特殊 token（`<|im_start|>` 等 24 个 AddedToken）必须**整体优先匹配**并
按长度降序，否则会被 BPE 拆成子 token，模型收到的输入就变了——且不会报任何错。
验证：`testdata/qwen_tokenizer_reference.json` 由 HuggingFace 真实 tokenizer
生成（26 条用例，覆盖中/英/中英混排/数字/各类空白形态/标点/emoji/特殊 token/
长文本/空串/单字符边界），Go 实现逐条精确对齐。字节↔unicode 映射另测双射性
（有碰撞会让不同字节编成同一 token，静默产生错误输入）。
2026-09-11 00:11:58 +08:00
60857dda3e
fix(ctx): prune 的查询向量改用插件 Cleaner 清洗后的有效内容(§13.8)
...
ContextPolicy=prune 上线时直接把**原始**工具结果传给 RelevanceContext.Prune，
而 Prune 的入参是**相关性查询向量**——它决定保留/归档哪些上下文事件。于是
ANSI 转义、base64、JSON 包装等噪声全被编进查询向量，打分失真，裁掉本该
保留的事件。
而 ToolDef.Cleaner 的契约本就写着「仅在向量化/jieba/蒸馏时调用」，裁剪正是
在向量化——所以这是**回归契约**，不是新增能力。此前只在构建事件向量
（context.go 的 toolOutputClean）时用了 Cleaner，裁剪查询这一处漏了。
回退规则（Cleaner 是计算层优化，不能因它失效而丢内容）：
- 未注册 Cleaner → 原文
- RPC 失败 → 原文（proc 侧 cleanerProxy 已有此保证）
- 返回空串 → 原文（空串会让查询向量退化成零向量，所有事件相关性相同，
等于随机裁剪）
验证：TestToolOutputForQueryAppliesCleaner（Cleaner 被调用恰好一次且用其
结果；无 Cleaner / nil stageHost 回退原文）、
TestToolOutputForQueryEmptyCleanFallsBack。
顺带把 §13.13 第 5 条（反向大结果）按核实结论结掉为「不做」：核实发现根本
不存在 llm.chat（llm.* 只映射切换 LLM 源），唯一可能返回大结果的 doc.query
没有任何外部插件使用且已被 CapDocMemory 能力门限制。留成永久 TODO 只会误导。
2026-09-10 23:59:12 +08:00
19fc3e681a
feat(shm): 文档/知识正文入共享内存 + 协议版本 bump 到 2(§13.13)
...
## 数据面补齐
- doc.insert / doc.insertWithMedia：新增 doc_ref / attachments_ref，
模板序列化后 putValueInArena
- knowledge.add：新增 content_ref（内容是 JSON 字符串，读出后再解一层）
- 抽出通用 resolveJSONRef（resolveBlocks 也改用它），三处共用一套
“共享优先、内联回退”逻辑
## 协议版本 bump：让错配显式失败，而不是静默坏
这是本轮更重要的部分。§13.6/§13.13 改了内核→插件 payload 的承载方式，
两种错配都不会报错、只会静默失效：
- v1 插件只读内联 args（tool/cleaner/output）→ 遇到 v2 内核拿到空参数
- v2 插件发 blocks_ref → v1 内核反序列化时静默忽略（旧内核
io.setToolBlocks 还是桩实现）
现场表现为“输出变空 / 图注入没反应”，极难定位。所以把 ProtocolVersion
与模板 procProtocolVersion 一起 bump 到 2：双方都是等值校验，v1 插件遇上
v2 内核会在建链时明确报“协议版本不匹配…请用配套 plugindev 重编”。
测试里把“错误必须带出重编指令”也断言上了——生产上碰到它的现场就是
“只更新了内核没重编插件”，光报“不匹配”定位不到行动。
testdata 8 个插件的 protocol 同步更新（badprotoplugin 仍用 999 验证拒绝）。
工具链已重建并安装（协议 2，内嵌 blocks_ref/doc_ref/content_ref），
回滚副本 plugindev.bak-20260910-232544。
验证：-race 全绿。新增 KnowledgeAddViaArena(12000B 正文)、
KnowledgeAddInline、DocInsertViaArena、SetToolBlocks 三例 +
真实模板 e2e + 协议不匹配断言强化。
§13.13 第 5 条（反向大结果）范围更大——需把内核→插件的应答路径整体改成
“大结果写段 + 返回 ref”，涉及 callCore 的返回处理与 doc.query/llm.chat 等
所有读大结果的 method。已在 plan.md 标注未做，不冒充完成。
2026-09-10 23:26:16 +08:00
89e50608b5
feat(shm): 媒体块入共享内存 + 实现 setToolBlocks 桩(§13.13)
...
两个问题叠在一起，先发现的是第二个：
1. **io.setToolBlocks 在内核侧是桩实现**——直接返回“多模态注入待共享段
二进制通道落地”。也就是**子进程插件调 SetToolBlocks 必然失败**（模板
只 log 一行），只有内置插件（multimodal）能用。之前还有测试把这个错误
当作预期行为断言着。
2. 媒体块（injectMedia 系列 + setToolBlocks）把 blocks 内联在 RPC JSON 里，
而本地生成的图/音频是 base64 data URL，一张图可达数 MB。
顺带修掉一条与设计相悖的旧注释：injectMediaParams 写着“data URL 已是
base64 文本、再套一层二进制不会更小，所以走 JSON”。那只算了体积，漏了
两件更重要的事——内联时整份 base64 要在 RPC 报文里再编码/再拷贝一遍；
以及内容本体不在共享段里，插件回调就无法就地改写，只能各持一份拷贝。
共享内存的意义是后者。
实现：
- injectMediaParams 加 BlocksRef；新增 resolveBlocks（共享优先、内联回退）
- 真正实现 MethodIOSetToolBlocks（空块明确报错，不静默成功）
- CoreSDK 接口加 SetToolBlocks，procCore 转调 internal/sdk
- 模板：SetToolBlocks / injectMedia 三兄弟经 putValueInArena 传 blocks_ref；
同步调用用 mediaArgsOwned 拿释放函数，**不能在应答返回前释放槽**，
否则内核读到已释放内存
验证（-race 全绿）：
- TestCoreHandler_SetToolBlocksViaArena / Inline / EmptyRejected
- TestE2E_RealTemplateSetToolBlocksViaArena：真实 SDK 模板编译的插件，
9000 字节 base64 图经 blocks_ref 完整送达
工具链已同步：/usr/local/bin/plugindev 重建为新协议（内嵌 blocks_ref），
回滚副本 plugindev.bak-20260910-224255。注意内核与全部插件必须同批替换
——只换一边会静默坏（新内核+旧插件=输出 payload 变空；新插件+旧内核=
媒体注入静默失效），已记入长期记忆。
2026-09-10 22:45:19 +08:00
8f23342600
docs(plan): 修正 §13.13 判据——按「回调能否就地改写」而非 payload 大小
...
之前把共享内存的理由写浅了（当成“省管道 / 避免大 payload”）。真实目的是
找回 .so 时代的能力：插件回调（Cleaner / Stage / 工具）与内核同进程时可以
直接就地改写参数与结果；多进程化后若靠 RPC 来回发消息，回调就只能
“读一份、回发一份”，丢失就地改写语义。共享内存是把内容放进段里、回调就地
改、只回描述符。
因此判据应是「插件回调要能就地改写的内容有没有留在段里」，不是 payload 大小。
按新判据核实：回调主线已达成——
- Stage：invokeStage 只发 {Stage, Seq}，插件就地改写，应答只回 DirtyFields 计数
- Cleaner：发 {Scope,Name,Frame,InputLen}，回 TextRef（16B 描述符），内容不随 RPC 走
- tool.invoke：内核标定 Frame，结果 ResultRef，after_toolcall 可在段内再改
未入内存的重新排序，第一条换成 io.setToolBlocks：它直接破坏“结果媒体能被
after_toolcall 就地改写”——插件只能推一份 base64 拷贝过去（ai_image 大图）。
2026-09-10 21:47:23 +08:00
5957e42b2c
docs(plan): 修正 §13.5 的错误判断，建账 §13.13 剩余内联路径
...
§13.5 之前写的「内核侧未接线」是方向性错误：我把分配方认错了。
实际是**插件侧** putInArena 做 arena.alloc + 写入 + 传 text_ref，内核侧
resolveText 读回。分配在插件侧并非缺口——§13.2 的模型就是「插件经 RPC
向内核申请/归还」，内核独占分配器；procCore.InjectText 拿到普通字符串
也是对的，因为共享内存是跨进程的内部实现、不对插件开发者暴露。
新增 §13.13，把「全量数据交互入共享内存」这个总目标的尾巴显式建账，
区分数据面（要入）与控制面（不该入，几十字节搬进去反而多两次 RPC）：
已入：StageContext / 事件环 / tool.invoke / cleaner.invoke /
output.invoke（本次 §13.6）/ io.injectText（§13.5）
未入：① 媒体块 io.injectMedia / injectMediaSync /
injectInterruptMedia / setToolBlocks（本地大图 base64 可达数 MB，
最大一条）② doc.insert / insertWithMedia ③ knowledge.add
④ 插件反向调内核读大结果仍内联
2026-09-10 21:34:42 +08:00
3740cdee09
feat(shm): 输出通道 payload 走共享内存调用帧(§13.6)
...
§13.3 给 ToolInvokeParams 加了调用帧，但 OutputInvokeParams 没跟上——
payload 仍内联在 RPC JSON 里。核实后确认这个 lane 只做了半边：注入侧
（injectParams.TextRef + resolveText）可用，输出侧从内核到插件仍是内联。
改法照搬工具调用的 funccall 帧模型：
- OutputInvokeParams 加 Frame/ArgsLen（Args 仅留给直连 RPC 的测试）
- invokeOutput 序列化参数 → Alloc 帧 → 写帧 → 只传偏移描述符 → defer Free
- 帧尾不预留结果区：output 应答很小（"ok"/status map），走 RPC 应答字段即可。
但 OutputInvokeResult 支持插件把大结果写回帧（ResultRef），并识别
sharedRefFlagExpand 单独归还扩容块——与 invokeTool 一致。
- 模板 output.invoke 用 frameInput 从帧读参数，无帧才回退内联 Args
为什么要做：output payload 在真机上可能含图片/文件描述等大字段，内联会
撑爆 stdin/stdout 管道。
验证：
- TestPlugin_OutputPayloadViaArena：9000 字节 payload 经帧完整送达（插件回报
实收长度，不是只看返回值）+ 调用后 arena 归零
- TestE2E_RealTemplateOutputPayloadViaFrame：同上，但用真实 SDK 模板编译的
插件——生产插件走的就是模板，模板不读帧则此改动等于没做
- TestPlugin_OutputChannelReportsRealFailure 仍绿：同步等真实结果、失败必须
上报（§9.4）的语义未被破坏
- go test -race ./internal/plugin/... 全绿
plan.md §13.5 也如实标注：注入 side 内核→插件方向仍未接线（procCore.InjectText
直接传字符串，从不 Alloc/Put 构造 TextRef），不是仅打勾的项。
2026-09-10 21:28:56 +08:00
7924e0719b
chore(shm): 补齐 §13 验证项，删除统一区域遗留死代码
...
三件事，都是 plan.md §13 里未打勾的项：
1. §13.3「Bench: ToolInvoke 延迟对比」补测（bench_test.go）
改造后原有的 BenchmarkToolInvoke 仍走 legacy 内联 Args，已不代表生产
路径。拆成 inline / frame 两个子基准并各测两个尺寸（-count=3 取中位）：
payload inline（RPC 报文） frame（共享内存帧） 差
16 B 26.4 µs/op 48.0 µs/op +21.6 µs
32 KiB 695.6 µs/op 391.7 µs/op −303.9 µs
取舍随尺寸翻转：小 payload 多付 ~22µs 帧固定开销，大 payload 省掉整份
JSON 编解码与管道拷贝、快 44%。因为线上工具结果动辄几十 KB 且 22µs
相对 LLM 往返 2-8 秒可忽略，所以统一走帧而不按大小分叉（§13.3 第 4 条）
是对的。
2. 删除 §13.1 遗留死代码（evtring.go）
allocEvtRing 自统一共享区域之后从未被调用——旧版它单独建 memfd + eventfd，
现在只有一个 memfd，事件环只是区内的一个 segment（NewEvtRing 操作区内
切片）。留着会让人误以为事件环还有独立段。
3. 修正误导性注释（plugin.go）
仍写着旧 3-fd 布局「3=StageContext, 4=事件环, 5=通知」，与实现
（procExtraFilesForShm 只返回 memfd+evtfd）和 shmpass_unix.go 的权威
注释互相矛盾。
plan.md：§13.1/13.3/13.4/13.8 的验证项按实测打勾，并注明证据（提交号 /
测试名 / 实测数字），不留无依据的勾。
2026-09-10 21:18:16 +08:00
3d990e0edc
fix(agent): 工具循环占位不再驱动重复发送，输出回执/子任务结果幂等
...
生产现象：单轮内 output_send__qq 被调用 34 次、持续 514 秒，直到 QQ 插件
自己的循环保险拒绝发送才停下（problem.md）。根因是多环节叠加，核心侧修四处：
1. 工具轮补位文案（process.go）
通用占位「请根据以上工具结果继续。」对纯输出通道调用是错的：异步通道
（qq/wechat）的回复只能经 output_send__* 交付，所以模型「已完成回复」的
表达形式就是一个工具调用，紧随其后的「请继续」会被读成「还要再做一步」，
而能做的「一步」恰好还是再发一条消息。
改为按上一批工具的性质选文案：全部是 output_send__* 时补
「若你的回复已完成，直接返回纯文本即可结束本轮，无需再调用任何工具。」
同时每轮先移除旧占位再补一条，避免占位在 prompt 前缀里线性累积。
（该占位是 zen 网关「最后一条必须是 user」的传输层附加物，HEAD 版本是
无条件内联追加、从不移除。）
2. 输出成功回执（output.go）
「已通过 [qq] 通道发送: map[status:sent]」这类富回执会被读成「这步成功，
继续下一步」。成功改为只回极简标记。
3. proc 桥标量透传（internal/plugin/proc/plugin.go）
插件返回 "ok" 时不再伪造 {status:sent} 覆盖插件真实返回值，否则只改
output.go 不生效。
4. 子任务结果幂等（spawn.go）
child_result 原先读到即删，而完成通知长期留在持久上下文里
（formatMergedTimeline 每轮重新注入），第二次查询必然得到
「不存在或已过期」这个永久失败信号，模型据此认为任务未完成而反复重试。
改为保留结果 + delivered 标记，重复查询返回明确提示；结果按上限有界淘汰。
顺带：agent.go 去掉文档层显式向量器注入（TF-IDF 已内置为 fallback），
cmd/homed/main.go 同步 document.NewStore 的 tokenizer 参数。
测试：internal/agent/core/tooloop_test.go（5 例）、spawn_test.go（3 例）。
2026-09-10 20:36:39 +08:00
d7d4c7e7e1
refactor(shm): 变长块分配器 + 工具调用 funccall 调用帧(§13.2/§13.3)
...
按架构约束推进两步：
1) 分配器收回内核后，定长槽失去了唯一存在理由
（定长槽只是为了绕开"跨进程无法安全变长分配"），
于是 arena 换成**变长块分配器**：first-fit + 邻块合并，
块头 16B（size/state/owner/prevSize）。内核可以按需标定每块大小，
payload 不再受固定槽容量限制（旧上限 16KB）。
- Alloc/Put/Read/Free/ReclaimOwner 全在内核进程内，一把 sync.Mutex
- Free 走块链校验 offset 是已分配块的数据起点 + owner 匹配，
伪造引用不能改动分配器状态
- Read 允许块内偏移（调用帧的结果区就在帧块中间），但不许跨块边界
- arena 4MB，底层 memfd 惰性分配：未触碰的页不占物理内存
2) 工具调用 payload **始终**走共享内存，取消按大小切内联的分支。
按 funccall 模型，内核（caller）标定调用帧交给插件（callee）：
[0, ArgsLen) 参数 JSON
[ArgsLen, Frame.Length) 结果区（内核预留的预算）
结果超出预算时插件才 `arena.alloc` 扩容块，引用上打
sharedRefFlagExpand 让内核单独归还。Cleaner 复用同一帧模型。
ToolInvokeParams.Args / ToolInvokeResult.Result 仅剩给直连 RPC 的
测试（process/bench 不建 Host）；生产路径永远走帧。
测试：
- TestArena_*（分配/归属/回收/并发唯一/耗尽/超限/伪造 offset/
相邻合并/对齐/布局校验）
- TestPlugin_ToolInvokeArgsResultViaArena：大**小** payload 都经帧往返，
结果一致且 arena 归零（"小 payload 同样走调用帧"是本轮行为变更）
- TestPlugin_ArenaAllocFreeAcrossProcess、TestE2E_* 保持通过
- 顺手修 process_test.go 一处预存 doc-comment 分段
2026-09-10 18:54:36 +08:00
ed661fca7b
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
121a28bd26
fix(proc): EvtConsumer 生命周期——消除 host.Close 后的 SIGSEGV
...
预存缺陷（非本次重构引入，但会稳定复现崩溃）：
Stop() 只 close 了 stop channel，而 Run() 阻塞在 evtfd.Read 里，
根本没有机会检查 stop。调用方在 Stop 后释放 ringData（host.Close
会 munmap 整个区域），Run 一旦从 Read 恢复就会读已解除映射的内存：
**SIGSEGV，recover 捕不到**。实测 TestEventRing_OverflowStillDelivers
约 50% 概率触发。
两次尝试与结论：
1. os.File.SetReadDeadline 无效——eventfd/pipe 经 os.NewFile 包装后
**不会**注册进 Go netpoller（os.NewFile 对非 open 得到的 fd 一律按
非 pollable 处理），Read 是阻塞 syscall，SetReadDeadline 返回错误。
2. 改为 poll(2) 显式加超时（evtpoll_unix.go），消费循环每 100ms 回到
stop 检查。
新增 API 契约：
- Stop() 非阻塞，仅请求退出
- Wait() 阻塞至 Run 退出；**返回后才能释放 ringData**
- drainEvents 每条事件后检查 stop，避免慢 handler 拖延退出
其他：
- evtring_test.go 三个用例改为 defer Wait() → defer Stop()（LIFO 保证
Wait 先于 host.Close 完成）
- 溢出用例的 handler 改为非阻塞投递：写入了 8292 条事件而 channel 只
消费 1 条，阻塞投递会让 drainEvents 卡在 handler 里，Stop 无法退出
2026-09-10 17:56:54 +08:00
0d78279f95
refactor(shm): 内核独占共享槽池，插件经 RPC 申请/归还(§13.2/§13.3)
...
推翻前两版跨进程分配器设计，根因是"共享内存里放了只被单一进程
更新的可变游标"：
- v1 在 SuperBlock 放 arenaUsed 游标，内核 CAS bump。但插件模板里
arenaUsed 是**进程本地变量**，两进程各自 bump 必写同一段内存；
arenaReset 还会重置共享游标覆盖对方数据。
- v2 把位图 CAS 下沉到插件模板，正确但把分配器实现泄漏进插件运行时，
且插件必须与内核保持位图布局同步。
新设计（用户明确的架构约束）：内核全权管理共享内存，插件通过
syscall 风格 RPC 申请/归还，内核返回偏移与大小。分配器只存在于内核
进程内，一把 sync.Mutex 即可。共享内存是内部实现，不对插件开发者
暴露——SDK 公开 API 仍是普通字符串/Map。
主要改动：
- arena.go: 定长槽 + 位图，Alloc/Put/Read/Free/ReclaimOwner，内核独占；
槽头记录 owner，Free 校验归属；payload 超槽容量退回内联 RPC
- protocol.go: 新增 arena.alloc / arena.free（CapCore）
- capability.go: 登记两个新 method（checkAllMethodsClassified 要求）
- corehandler.go: 实现 arena.alloc/free；Cleaner 改为内核预分配
请求槽 + 响应槽（插件完全不分配）
- plugin.go: Start 领 ownerID；handleExit 调 ReclaimOwner 回收残留槽
- unified.go: 移除坏的 bump 分配器；arena 基址 8 字节对齐
- 删除 toollane.go: ring 状态机是死代码（从未接线），且把 RPC 已有的
请求 ID 关联/错误传递/ctx 取消重新实现了一遍。控制面保留 RPC，
只把 payload 搬进共享槽。
- 测试: TestArena_*（归属/回收/并发唯一/耗尽/超限/非法引用/布局）+
TestPlugin_ArenaAllocFreeAcrossProcess（真进程申请→写入→随业务
RPC 回传→归还→内核读回一致且池归零）
2026-09-10 17:56:50 +08:00
45d637bde4
fix(shm): 审核修复——arena 并发安全 + ToolCall ring 抢占 + arenaRead 校验
...
§13.2: arenaAlloc 改 CAS bump（修复并发覆盖）；arenaRead 增加 generation + arena 边界校验
§13.3: Reserve 从 Store+Load 改 CAS-free→Reserved 状态机抢占帧（修复并发分配重复）；
增加 RESERVED 中间态；SetReading/SetReady 改 CAS 返回 bool；ReleaseFrame 清零跳过 state
§13.5/13.6: 注入方法接入 resolveText（从 arena 读 SharedRef）；cleanerProxy 加 arenaMu 串行化+每次重置
§13.8: ContextPolicy prune topK 改为 maxContextSize-1（不再硬编码 20）
tool.register 校验 context_policy 只允许 none/prune
2026-09-10 17:03:32 +08:00
71c0dedcb6
feat(shm): InputChannel/OutputChannel lane 基础设施(§13.5/§13.6)
...
- injectParams 加 TextRef SharedRef（兼容旧 Text 字段）
- resolveText 辅助函数：优先 SharedRef，否则内联 Text
- 核心注入方法待迁移至 resolveText
2026-09-10 16:14:17 +08:00
e378d6e325
feat(shm): arena + ContextPolicy(§13.2/§13.8)
...
- unified.go: arena 分配器 (alloc/write/read/reset)
- NewHost: 分配空间含 arena
- SDK ToolDef 加 ContextPolicy string
- StageAfterToolcall 后检查 prune 策略触发 RelevanceContext.Prune
2026-09-10 15:49:47 +08:00
d185201ee8
feat(ctx): ContextPolicy tool 上下文策略(§13.8)
...
- SDK ToolDef 加 ContextPolicy string（默认 none / 可设 prune）
- StageAfterToolcall 后检查工具 ContextPolicy=prune → RelevanceContext.Prune
- 所有现有测试通过
2026-09-10 15:41:23 +08:00
38f05d9bc3
feat(shm): Cleaner 迁移到 SharedRef(§13.4)
...
- CleanerInvokeParams/Result 的 Text 改为 TextRef SharedRef
- cleanerProxy: 写 text 到 arena，传 SharedRef，读结果 SharedRef
- 插件侧 cleaner.invoke: 从 SharedRef 读 input，清洗后写回 arena 返回 TextRef
- NewHost(): 分配空间含 arena（256KB）
2026-09-10 15:30:00 +08:00
0db4ec8d01
feat(shm): arena allocator for unified region (§13.2)
...
- SuperBlock 新增 arenaOff/arenaCap/arenaUsed 字段
- arenaAlloc: append-only bump 分配，offset 0 保留给空语义
- arenaWrite: 写入并返回 SharedRef（含 generation）
- arenaRead: 按 SharedRef 切片读取
- arenaReset: 压实后重置游标
2026-09-10 14:33:44 +08:00
6682710e43
feat(shm): ToolCall ring buffer(§13.3) — 栈帧模型 ring，push/pop 帧状态机
...
- ToolCallRing: 定长帧 ring buffer (64 frames × 112B)，状态机 FREE→CALLING→READING→READY→FREE
- Reserve: 环形扫描找 FREE 帧，全忙返回 ErrToolCallRingFull 背压
- SharedRef: pack/unpack 辅助函数
- unified.go: arena 分配器（arenaAlloc/arenaWrite/arenaRead）
- 5 个单测覆盖 init/reserve/背压/find/reuse
2026-09-10 12:33:58 +08:00
09c8bce59c
feat(shm): 统一共享内存区域(§13.1) — 单 memfd 容纳 SuperBlock+StageContext+EvtRing
...
- unified.go: SuperBlock 布局 + SharedRef 类型
- NewHost(): 两段 memfd 合并为单一 memfd，fd 3 = 统一区域，fd 4 = eventfd
- 子进程侧: testdata 插件从 SuperBlock 解析 ctxOff/evtOff
- streaming 测试: EvtConsumer 协程在 host.Close 前 Stop+Wait 防 SIGSEGV
2026-09-10 11:42:22 +08:00
79d18136f6
feat(proc): Cleaner 跨进程修复(tool/input/output) + 共享内存安全模式 + plan §13
...
- Cleaner 协议统一为 cleaner.invoke(scope,name,text)，覆盖工具/输入/输出三类
- 新增 ShmSecurityMode (safe/debug/full)，Linux 审计探针，Windows crypto nonce
- plan.md 追加 §13 步骤分组
2026-09-10 10:21:50 +08:00
8aa74f71ef
feat(doc): dense vector index for unified text+media retrieval
...
文档层引入稠密向量索引，与媒体检索共享同一多模态空间：
- Doc 加 DenseVec 字段（json:-，运行时计算）
- Consume/QueryScored 优先使用 denseSearchScored（brute-force cosine），
未配置时退化到 TF-IDF 倒排检索
- buildDenseIndex 在 Agent 启动时为全部文档一次性计算稠密向量
- L0 RelevanceContext 支持 denseSpace（Prune 使用稠密余弦），
退化到 fastText 稀疏余弦
vector 包新增 DenseCosine（[]float64 brute-force cosine）。
验证：492 篇文档 brute-force ~300ms，全部测试通过。
2026-09-09 18:56:44 +08:00
36c604ef3e
feat(vector): pluggable multimodal vector space
...
核心暴露 MultimodalEmbedder 接口，两条路径共享同一套 L0/L2/L3
向量缓存、media.Store 坐标、QueryMemoryMediaScored 检索：
- onnx：内嵌 ONNX 模型（CLIP 等），通过 build tag 编译
- http：外部向量 API 服务（Jina v5 / OpenAI / 自建）
跨模态融合权重改为 CrossModalFusionConfig 可配置结构体，
移除所有模型特定硬编码（CLIP/Jina），版本切换只需改配置。
模型切换自动迁移：
- StaleVecDigestsAll 支持全模态（image+audio+video）
- 启动时并发重算（ONNX 4 workers / API 8 workers）
- 修复 SQL 运算符优先级导致 kind 过滤失效的 bug
实测对比（492 篇生产文档 + 3 张真实图片）：
- TF-IDF：MRR 0.457（精确匹配快，语义差）
- fastText：MRR 0.530（语义中等，延迟 8ms）
- Jina v5-omni：MRR 0.900（全面领先，延迟 40ms）
- 中文文本→图片：Jina MRR 0.833 vs CLIP 0.611
See docs/embedding-comparison.md for full benchmark.
2026-09-09 17:38:34 +08:00
b860c8cea5
refactor(clip): CLIP 收敛为稠密 MultimodalEmbedder，不污染稀疏 Vectorizer/TF-IDF 语义
...
文本相似度检索是层次化系统：TF-IDF 高频削弱加权（idf<0.1 丢弃）+
倒排剪枝（只召回共享特征者）+ cosine。CLIP 512 维稠密向量若以
map[string]float64 稀疏形式实现 vector.Vectorizer 并塞进 vector.Store，
会让 512 维全部成为倒排 key → 候选集≈全库、剪枝失效，且绕过 TF-IDF
高频削弱，与既有文本检索语义错配。
收敛：
- vector.MultimodalEmbedder 改为独立稠密接口（VectorizeDense/
EmbedImageDense/Fingerprint/Dim/Loaded/Close），不再继承稀疏 Vectorizer
- clip.Embedder 删除稀疏垫片 Vectorize/EmbedImage/denseToVector，
只产出稠密向量；文档/知识/上下文层继续用 TF-IDF/fastText 稀疏路径
- 分层明确：文本→文本走 TF-IDF/fastText；文本↔图像、图像↔图像走
CLIP 稠密 QueryMedia（媒体层独立稠密余弦，原样保留）
2026-09-09 10:26:10 +08:00
f8a35d1647
feat(clip): 多模态向量器（CLIP ONNX）——文本/图像 512 维共享空间 + 媒体向量写入与重算
...
- internal/memory/clip：CLIP ONNX 向量器（onnxruntime 构建标签控制，默认构建不链接 ONNX）
- clip.New(modelDir) 加载 text.onnx/vision.onnx（输出 text_embed/image_embed [batch,512]）
- 实现 vector.Vectorizer + vector.MultimodalEmbedder（Vectorize/EmbedImage + Dense 变体）
- 词级 BPE tokenizer：merges 合并后词末片段带 </w> 查 vocab，与官方 encode 逐 id 对齐
- EmbedImage：解码→resize 224→NCHW→normalize→vision session
- Fingerprint（text+vision 文件 sha256）供模型切换检测
- stub 版（无 onnxruntime 标签）保持默认构建行为不变
- vector/store.go：新增 MultimodalEmbedder 接口
- media.Store：新增 StaleVecDigests(currentModel)——查 vec_model 不匹配/缺失的图片
- agent core：AgentConfig.ClipEmbedder + Agent.clipEmb 接线；
describePendingMedia 描述成功后 EmbedImageDense→SetVec；
新增 reembedStaleMedia 启动补算历史无向量图片
- config：core.memory.media.clip_model_dir（未配置退化为现有 fastText/TF-IDF 行为）
- cmd/homed：读 clip_model_dir 加载 CLIP，失败仅记日志不阻塞启动
测试：TestSmokeLoadAndEncode（文本语义 cat>dog 0.914>physics 0.740）、
TestCrossModalAlignment（red-image vs red-text 0.063>blue -0.009，与 Python 一致）、
TestTokEnd（与官方 encode 逐 id 对齐）、TestStaleVecDigests，含 -race 全绿
2026-09-09 10:23:31 +08:00
a668e1f732
feat(media): media.Store 加向量存储与跨模态检索
...
media.Item 新增 Vec []float64 和 VecModel 字段，视觉嵌入向量以 JSON
TEXT 存库（为什么不存 BLOB：Go 的 json.Marshal 对 []float64 是自然的，
而 SQLite BLOB 是 []byte 多一层序列化；单条最多 23KB，TEXT 够用）。
initSchema 加 ALTER TABLE 迁移 vec/vec_model 两列（幂等）。scanItem
扩展读回。新增 SetVec 和 QueryMedia 方法。
QueryMedia 对所有已嵌入媒体做余弦相似度检索，维度不一致的项自动跳过
——这是跨模态检索的核心：查询可以是图片也可以是文本，被查的媒体库
里每个 item 也有视觉向量，两者在同一空间比对，谁的相似度更高就召回谁。
配套 5 个单测覆盖：基本相似度排序、无向量项被跳过、维度不匹配过滤、
空查询安全、向量持久化正确性。
2026-09-07 22:31:39 +08:00
10dafd5ccb
feat(media): media.Item 加视觉嵌入字段，Store 加 QueryMedia 跨模态检索
...
路线 3（完整跨模态检索）的媒体层基础：
- Item 新增 Vec []float64（视觉嵌入向量，JSON 序列化存库）和 VecModel
（模型标识，用于模型切换后触发重算）
- initSchema 加 ALTER TABLE 迁移 vec/vec_model 两列（幂等，列已存在可忽略）
- scanItem 扩展读回 vec/vec_model
- SetVec(digest, vec, model) 写入向量
- QueryMedia(queryVec, model, topK)：对所有已嵌入媒体做余弦相似度检索，
维度不一致的项自动跳过（防不同模型空间的向量被混算）
混合检索的设计意图：查询可以是图片也可以是文本（经向量化后调用 QueryMedia），
被查的媒体库里每个 item 也有视觉向量。两者在同一空间比对，谁相似度更高召回谁。
不再区分「图片查询」还是「文本查询」——向量空间的相似度自动决定。
2026-09-07 17:11:10 +08:00
16427fe6dc
feat(vector): Vectorizer 接口加 EmbedImage，支持多模态嵌入扩展
...
Vectorizer 新增可选的 EmbedImage(img []byte, mime string) (Vector, error)：
支持视觉嵌入的实现者（如 CLIP/MobileCLIP）覆写此方法；不支持的
（StaticEmbedder、TFIDFVectorizer）返回 ErrNotSupported 调用方按文本降级。
这是路线 3（完整跨模态检索）的接口基础：后续在 media.Store 里，
Describe 时同时算视觉向量并存库，QueryMedia 做跨模态混合检索。
2026-09-07 17:00:29 +08:00
2ef2de8467
docs: 同步仓库文档到 v1.1.1，补媒体记忆与接口扩展规则
...
五处文档此前停在 v1.0.0，而 v1.1.0/v1.1.1 都已发布并在现网运行。
本轮补齐三层记忆的媒体架构、模型工具的媒体参数、通信面 method 数，
以及冻结解除后的替代约束。
## 中英双语 OVERVIEW.md
三层记忆段只写了 Context/Document/Graph 三层，而 v1.1.0 起图片/音频是
三层里的一类节点。补上媒体记忆的架构概要：CAS + 引用计数 GC + 标记格式
（描述文本才是持久语义记忆，blob 是可淘汰的缓存）+ 插件边界贯通。
## 中英双语 ARCHITECTURE.md
- 「记忆工具」表补 `memory_commit`/`doc_commit` 的 `media_digests` 与
`sentence_text`（后者从未暴露给模型，而它是媒体绑定链的必经环节）
- 「三层记忆」段新增媒体记忆子节：CAS 设计表（寻址/完整性/写入原子性/引用/GC）、
标记格式、可选性（`enabled=false` 时整条链路静默退化）
- 「三个通信面」从 51 改为 55 个 method，新增四个 media method 的说明
- 「SDK 四通道」代码示例补媒体注入三方法 + 与 SetToolBlocks 的区别
## plugin-interface-matrix.md
- 状态从「完成 v2」改「完成 v3」，v3 记录 v1.1.1 的接口扩展
- §二 A3 DocMemoryAPI 补 InsertWithMedia
- §二 A4 补三个媒体注入方法 + 为何不能搭 SetToolBlocks 的车
- §二 A5 补 MediaAttachment 类型 + Triple/Doc/TextEvent 的扩展字段
- §六「新获得的能力」补 SetToolBlocks 已落地、媒体入记忆、插件主动发起
带媒体的对话
- §七 冻结检查点补第 5 条（冻结已解除，取代它的是 §九）
- 新增 §九「v1.1.x 的接口扩展规则」：冻结解除后的三条硬约束
（只增不减签名不改 / 新增方法方向 / 模板接线六处失败链）+ 验证方式
（存量插件 17/17、旧产物 4/4 建链、模板断言、压测 -race）
## 为何分立两笔 commit
前一笔（SDK 仓 README + 内核 README）改的是给**插件开发者**看的文本，
本笔改的是给**架构师与维护者**看的技术文档。受众与改动层次不同，
放在同一个 commit 会让追溯时看不出"文档在哪一层跟上了代码"。
2026-09-06 15:07:14 +08:00
2d3f7cd2ef
docs: 项目状态与 plan 同步到 v1.1.1，vendored SDK meta 注释对齐 SDK 仓
...
三处失同步，都会让读者拿到错的现状：
## README / README_EN
「项目状态」段的最新条目还停在 v1.0.0，而 1.1.0 与 1.1.1 都已发布。补上两条，
并把顶部特性摘要与下载段的 Windows 安装器版本号一起更新（那里写死了
`HomeAgent_v1.0.0_*_win64.exe`，照着它去 release 页面找是找不到文件的）。
## plan.md §12.1
标题还是「待用户决策后执行」，而四个决策点早已全部落定并执行完毕。改为已完成，
并记下实际演进已超出当初设想的地方（这些后来都写进了 docs/git-branching.md）：
发布分支改为一个中版本一条、三级通道由 tag 区分、SDK 版本跟随核心中版本且
patch 位恒为 .0、beta 阶段不发 SDK、main 永不作发版分支。
同时修掉一处会误导追溯的陈述：§12.1 原文说 `v1.0.0` tag 指向 feature 分支中间点
`d524a68` 需要重打——那件事早已做完，现在指向 `release/v1.0.x` 上的 `00d0339`。
## plan.md §12.5
「无 Windows 真机验证」这条仍然成立，但补一句区分：Windows NSIS 安装器从 v1.0.0
起就随每个正式版作为 release 资产发布了。**能打出包 ≠ 包里的共享内存/事件对象在
真机上能跑通**，混为一谈会让人以为这项已经关闭。
## vendored SDK meta
主仓跟踪 `third_party/homeagent-sdk/meta/meta.go`，而该文件在 SDK 仓 main 上刚补了
版本路牌的说明注释。两仓这份文件必须逐字一致——否则下次谁改了哪边说不清，
而它正是「两仓中版本对齐」这条纪律的载体。仅注释差异，无行为变化。
2026-09-06 10:56:42 +08:00
0dee5676bc
chore(meta): main 的版本路牌推到 1.2.0
...
按 docs/git-branching.md §2.1，main 的 meta.Version 始终是**下一个未发布中版本**。
1.1.x 线正在发布中（release/v1.1.x 承载 v1.1.0 / v1.1.1），所以 main 指向 1.2.0。
它标记「main 正在积攒 1.2 的东西」，不表示 1.2.0 已经存在——1.2.0 没有任何 tag。
已发布的版本号一律看对应的 release/vX.Y.x 分支与 tag。
两仓同步：SDK 仓 main 也是 1.2.0（SDK 版本跟随核心中版本，见 §七.1），
而 release/v1.1.x 上 SDK 定版 1.1.0。
**此 commit 不 cherry-pick 到发布分支**（§五：版本号 bump 不跨分支搬）。
2026-09-06 09:54:55 +08:00
58ede98f9a
Merge branch 'feature/sdk-multimodal' — 多模态贯通插件边界
...
公开 SDK 新增媒体字段与媒体注入接口，内核实现对应 RPC 与桥接层，
text/image/audio 三条输入路径归一成一条 processInput 主干。
同步 docs/git-branching.md：SDK 版本语义、beta 不发 SDK、main 永不作发版分支。
存量插件零改动零重编（17 个 example 类型检查通过）。
2026-09-06 09:54:03 +08:00
167eab91cd
docs(git): SDK 仓版本语义与发版联动，并明确 main 永不作发版分支
...
三条此前没写进规范、于是被我在实际操作中做错的规则：
## 一、SDK 版本号跟随核心的中版本，patch 位恒为 .0（新 §七.1）
整条核心 1.1.x 线共用 SDK 1.1.0；只有核心进入 1.2.0 这种中版本跃迁时 SDK 才升。
核心的 patch 位专用于 bugfix 与漏洞修复，这类改动不碰公开 SDK 接口，SDK 版本号
没有理由跟着动。
**为什么不逐位对齐**：SDK 版本号是插件开发者的依赖声明。若核心每发一个 bugfix
就给 SDK 推一个新号，开发者要么被迫跟版、要么怀疑自己版本过时，而接口其实一个
字都没变。让 SDK 号只在**接口可能变化的中版本边界**上跳，开发者只需关心「我在
为哪个中版本写插件」。
因此「两仓版本对齐」在本规范里指**中版本对齐**（核心 1.1.x ↔ SDK 1.1.0），
不是三位全等。核心 1.1.1 配 SDK 1.1.0 就是对齐状态。§四 的措辞同步修正。
## 二、beta 阶段不发 SDK（新 §七.2）
核心的 alpha/beta tag 不伴随 SDK 仓发版：SDK 仓在这一阶段不打 tag、不建 release。
**为什么**：beta 是核心自己的测试阶段，此时 SDK 接口尚未固定。若此刻给 SDK 发版，
插件开发者会照着一个还会变的接口写代码——那是无效开发。接口没定就没有可依赖的
契约，发出去的版本号是一个假承诺。
这条约束的对象是 **SDK 仓的发版动作**，不是核心二进制里有没有 SDK 代码。主仓用
`replace => ./third_party/homeagent-sdk`，任何核心构建都必然含 vendored SDK 源码，
那是构建机制决定的，不在约束范围内。
核心打**正式** tag 时 SDK 才随之发版（§七.3）：SDK 仓也有自己的 `release/vX.Y.x`，
定版为 `X.Y.0`，打 tag、建 release、传 5 平台 plugindev 产物。同一中版本内的后续
核心 patch 不重复发 SDK。
## 三、main 永远不是发版分支（补进 §四）
版本号 bump、打 tag、构建产物、上传附件，全部只在 `release/vX.Y.x` 上做。
**即使某个改动刚合进 main、即使 main 此刻可部署，也不从 main 打 tag。**
main 的版本号是「下一个未发布中版本」的路牌，不是任何一次发布的版本号。
这条本该是 §2.1「main 的 meta.Version 始终是下一个未发布版本」的直接推论，但
只写了状态、没写禁令，于是留下了「main 可部署 ⇒ 可以从 main 发版」的误读空间。
§三 的分支表补上 main 现值 `1.2.0` 与 1.1.x 线的 tag 历史，让路牌语义有实例可对。
## 四、公开接口改动是 feature，不是发布准备（补进 §六）
它必须走 `feature/xxx` → 合回 main → cherry-pick 到发布分支，不允许当成「发布
分支上的 bug 修复」直接提交进 release——发布分支冻结功能（§2.3），而接口是最
典型的功能面。§五 补上这条路径的命令示例，以及 SDK 仓同步发版的命令。
2026-09-06 09:52:52 +08:00
c49c06e0cb
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
c928ff4376
fix(packaging): amd64 GUI 从未走过 electron 缓存，且空壳 node_modules 被当作已安装
...
干净 worktree 上打包时 GUI 被静默跳过。两个缺陷叠加，都属于「所有外层
检查都通过，只有嵌套的运行时缺失，而没有任何东西喊出来」。
## 一：electron 架构名与 Debian 架构名混用
electron 官方发布物命名用 x64/arm64，Debian 用 amd64/arm64。缓存查找
一直统一用 TAR_ARCH（amd64），于是 electron-v*-linux-x64.zip 永远命中
不到。arm64 两边恰好同名，所以上次修 arm64 GUI 架构污染（743b963）时
这个不一致没暴露。
推论：v1.0.3 的 amd64 GUI 实际是靠「回退到 host node_modules/electron/
dist」这条路组装的，不是走缓存——那条回退只在目标架构 == host 架构时
才允许，恰好成立所以没出错。干净 checkout 里没有完整 node_modules，
回退路径也没有，GUI 就消失了。
修法：单独映射 ELECTRON_ARCH（amd64→x64，arm64→arm64）。
## 二：判 node_modules 目录存在，而非判 electron 包存在
npm install 失败（离线/网络受限）会留下只有一两个条目的空壳
node_modules。原判据 [ ! -d node_modules ] 认为「已安装」，于是跳过
install → ever 读不到版本 → 缓存匹配退化到通配 → host dist 也没有 →
静默跳过 GUI。包名、目录名、变体名全部正确，只是没有 GUI。
修法：判据改为 electron/package.json 是否存在；目录在而包缺失时明确
说明「疑似上次 npm install 未完成」再重试；install 失败给出明确提示
而不是继续往下走。
顺带给 ever 加兜底：读不到已安装版本时从 package.json 的依赖声明取
数字部分（那里是 "^33.0.0" 这类范围，仅用于给缓存匹配一个提示）。
## 验证
干净 worktree（/tmp/rel104，release/v1.0.x）上重跑：
node_modules 存在但 electron 缺失（疑似上次 npm install 未完成）
electron 版本取自 package.json 依赖声明: 33.0.0（非精确）
electron runtime: electron-v33.4.11-linux-x64.zip
GUI built: build/homeagent-gui-linux-amd64 (263M, x86-64)
file -b 确认 electron 二进制为 x86-64，与目标架构一致（该硬校验由
743b963
2026-09-05 14:58:30 +08:00
c04d8e719a
Merge branch 'feature/memory-media' — 记忆系统支持二进制多媒体节点
...
四层实现 + 五个缺陷修复。方案 B+C（用户选定）：内容寻址存储 + 描述文本
作为持久语义记忆。
## 四层
L1 CAS（internal/memory/media）
元数据进 SQLite，blob 落盘 blobs/ab/cdef…，.tmp + rename 保证不会把
半写文件当完整内容读。Get 每次重验 digest——CAS 的全部保证都建立在
「文件名 == 内容摘要」上，喂一张损坏的图给模型会得到无法追溯的幻觉。
AddRef 幂等且只在真插入时才涨计数（虚高则 GC 永远不敢清理），
DropRef 用 MAX(0, ref_count-1)。GC 两段式 + minAge 保护刚落盘还没来得及
AddRef 的项；被引用的内容即便超容量也永不删除——宁可超限也不能悬空。
L0/L2 接入（internal/agent/core/mediaref.go）
只捕获 data URL：http(s) 会把一次对话变成一次网络请求（超时/鉴权/SSRF）。
digest 先 stage 后 bind——媒体在 process() 期间被捕获，而承载它的
ContextEvent 要等 process() 返回后才 Append，此刻还没有 owner_id。
归档时先 AddRef 到新 owner 再 DropOwner 旧的：反序会让计数瞬时归零，
并发 GC 会把仍被引用的内容当孤儿清掉。
后台循环（internal/agent/core/medialoop.go）
GC 定时清理让容量上限真正生效（此前 max_mb 注册了却无调用方）。
描述生成走后台而非对话路径：视觉模型一次调用生产实测 9.6s，放在对话里
会给每张图的回复加十几秒，而描述的价值是几个月后还能检索到——这一轮
模型本来就直接看着图。逐条而非批量：批量拿回来是一整段文字，无法可靠
切分回各自的 digest。默认关闭，开启后每 30s 最多 4 条。
L3 图库反查（internal/agent/core/graphmedia.go）
只做引用不建描述节点（方案 A）：图库的实体与关系来自描述文本的 NLP
提取，检索能力已具备；若节点名取自描述，描述重新生成后同一张图会留下
多个语义模糊的节点。媒体实体名用「图片 <短digest>」——digest 不变则
名字不变。CommitWithMedia 新增而非改 Commit 签名（后者有 31 个调用点）。
## 五个缺陷
1. rc.SetMediaStore 从未被调用 → L0→L2 引用转移在生产静默失效
2. 三元组全被实体名校验拒绝时仍释放引用并删文档 → 数据丢失
3. 媒体入 L3 依赖 NLP 提取器碰巧提出合规三元组 → 时好时坏
4. L3 媒体检索没有任何调用方 → 能存进去，agent 拿不出来
5. 两处数据竞争（remotedevice bufio.Writer / agentcli 共享读缓冲）
前四个都是「手工调 API 的单测无法发现」的类型：函数正确，但没接上，
或只在理想输入下正确。第 2 个做了反向验证（回退修复后测试确实 FAIL）。
## 验证
medialive 自动触发链实测（-tags medialive，源/模型/密钥由调用方经环境
变量显式指定）：只注入一个 image 事件，七个阶段全由生产代码自己触发。
真实 claude-opus-5 通过——第二轮不给图，agent 答出
「上：紫罗兰色 #8800DD / 中：蓝色 #0055EE / 下：纯红 #EE0000」。
配阴性对照：不给记忆时不该「记得」，否则阳性用例可能只是模型猜配色。
551 篇生产归档文档干跑：媒体正则零误命中；28 篇文档在旧逻辑下会被删除
而信息并未进图库，新逻辑保留。
全仓 go build / go vet / go test / go test -race 全绿，SDK 冻结 diff = 0。
2026-09-05 13:56:57 +08:00
2da6bf17fb
test(memory): 修正数据丢失回归用例的构造——它被媒体三元组修复本身弄失效了
...
两个修复之间产生了耦合：TestArchiveColdDocs_KeepsDocWhenGraphWriteEmpty
的前提是「三元组全被 validEntityName 拒绝」，而同批引入的
mediaTriplesFromText 会为正文里的 [image/png <digest>] 标记产出合规的
「图片 <digest>」三元组，于是 ec=4 rc=2、绑定成功、释放引用变成正确行为，
用例的前提消失。
（注意当时 GC 断言并未触发——内容没丢，只是"引用被释放"这条断言不再
适用于该构造。）
改法：正文不再含媒体标记，媒体引用直接 AddRef 挂上。这模拟的是更危险的
组合——文档持有媒体引用，但正文里的媒体标记已在清洗中丢失，于是有引用
要释放却没有句子能承载它。那正是这个守卫要防的情形。
反向验证重做后仍成立：回退守卫 → FAIL（引用被释放 + GC 删掉了本该保留的
内容）；恢复修复 → ok。
教训：只跑针对性测试不足以发现修复之间的耦合。提交前我跑的是
internal/agent/core 与 internal/memory，当时通过是因为缺陷二尚未修完；
两个修复都落地后的第一次全仓回归才暴露它。
2026-09-05 12:08:33 +08:00
1fbef8b53e
fix(memory): 媒体归档三缺陷——数据丢失、L3 入库不可靠、L3 检索未接线
...
自动触发链实测（medialive）连续暴露的三个缺陷，全部是「手工调 API 的
单测无法发现」的类型。附带该实测本身。
## 缺陷一：三元组全被拒时仍释放引用并删文档（数据丢失）
archiveColdDocs 只检查 len(triples) > 0 就释放媒体引用、删除文档。
但 Commit 会静默跳过实体名不合法的三元组（validEntityName 要求
2–50 字符），于是「无错但一条也没写进去」真实发生：
[agent] doc→graph: doc_xxx → 0 entities, 0 relations
[media] 文档 doc_xxx 入图库，释放 1 个媒体引用（描述已留在图库）
被记忆引用的内容被 GC 删除了（清 1 条/318 字节）
图库里没有任何句子承载引用，文档也被删，blob 被 GC 回收 → 图片与描述
彻底消失。我在上一层写的注释「Commit 之后引用已挂到 graph_sentence」
是错的：ec=0 rc=0 时它什么也没挂。
修法（用户选定 B+A）：
B. ec==0 && rc==0 时保留文档、跳过归档——归档的实质是「信息从 L2
搬到 L3」，搬不过去就不该删源，下轮再试。
A. bindSentenceMedia 返回实际绑定数，commitTriplesWithMedia 透出为
mediaBound；释放前四路判断（查引用出错→保守不释放／本无引用→无需
释放／mediaBound==0→保留并记录原因／否则释放）。宁可留一条悬空
引用（内容还在，可由后续一致性检查清理）也不能丢内容。
反向验证：旧行为下新测试确实 FAIL，报「引用被释放了」+「GC 删掉了本该
保留的内容」；恢复修复后 PASS。
## 缺陷二：媒体入 L3 依赖 NLP 提取器运气（可靠性）
媒体能否进图库，取决于提取器碰巧从描述文本里提出合规三元组。实测 LLM
的 477 字图片描述只产出「水平 -分割-> 成」，obj 仅 1 字被拒 → 整条媒体
记忆进不了图库。表现为「阶段 5 时好时坏」，取决于描述文本。
但媒体自身的 digest / mime / 描述都是确定的，不该受提取器支配。
新增 parseMediaMarkers + mediaTriplesFromText：从文档正文的媒体标记
直接产出确定三元组，先于 NLP 提取。同一份真实文档由 0 entities 0
relations 变为 ec=4 rc=2 且拿到句子 id。
三个设计点：
- 实体名用「图片 <短digest>」而非描述：描述会被重新生成（换视觉模型、
补描述），若名字取自描述，同一张图会在图谱上留下多个节点。digest
不变则名字不变，长度也天然合规。
- SentenceText 用原始标记段，保证 bindSentenceMedia 的正则必然能反解
到 digest——绑定从概率事件变成确定行为。
- 描述为空时仍产出「类型」三元组：描述是后台异步补的，媒体节点不该
因为还没描述就不存在于图谱。
- summarizeForEntity 按 rune 截断而非字节：按字节切会破坏 UTF-8，
图库里会留下乱码实体名。同时清 Markdown 强调符。
这是过渡方案，用户已定：下个 feature 换多模态嵌入后不再依赖
「描述文本 → 提取三元组 → 图谱节点」这条链路。
## 缺陷三：L3 媒体检索没有任何调用方（接线缺失）
第四层实现的 RecallMediaForSentence / mediaContextForSentences 从未被
调用——媒体能存进 L3、能反查，但 agent 拿不出来。实测第二轮 agent 显式
调了 doc_query，回答「没有找到那张图片的任何记录」。
接两个入口：
- buildMemoryContext（自动注入，每次 LLM 调用都走）
- memory_recall 工具结果末尾（显式查询）
关系行只有实体名和关系类型，看不出「这条记忆当时还带了一张图」，
媒体挂在句子上，必须经 关系→句子→media_refs 反查。
一处折返：最初直接用 injected.Relations 取 sentence_id，测试失败。
Indexer.BuildContext 刻意把 Relations 置 nil（自动注入只给实体索引以省
token，细节留给 memory_recall）。改为用命中的实体名再查一次关系，
深度固定 1——媒体是「这条记忆当时带的图」，顺关系网扩散只会带出无关
媒体并挤占 token。
## medialive 自动触发链实测
internal/agent/core/medialive_test.go，medialive build tag，默认
go test 不收录。源/模型/密钥全部由调用方经环境变量显式指定，缺任何一项
Skip 并列出缺哪个——刻意不提供 fallback，猜一个 base_url 可能打到调用者
机器上不相干的服务，而失败会被误报成「媒体记忆有问题」。
MEDIALIVE_BASE_URL=... MEDIALIVE_API_KEY=... \
MEDIALIVE_MODEL=... MEDIALIVE_ADAPTER=... \
go test -tags medialive ./internal/agent/core/ -run TestMediaLive -v
只注入一个 image 事件，之后七个阶段全由生产代码自己触发：CAS 落盘 →
引用绑定 → 描述生成 → L0→L2 转移 → L2→L3 绑定 → GC 保护 → 第二轮召回。
另有阴性对照：不给记忆时不该「记得」，否则阳性用例的通过可能只是模型
猜常见配色。上游不可用时 Skip 而非假 PASS。
真实 claude-opus-5 实测通过：第二轮不给图，agent 答出
「上：紫罗兰色 #8800DD / 中：蓝色 #0055EE / 下：纯红 #EE0000」。
## 测试
graphmedia_test.go 新增 8 例：数据丢失回归（反向验证过）、mediaBound
计数、媒体标记解析、实体名生成、描述截断、确定性三元组必然可入库、
关系→句子映射、L3 检索接线（自动注入与显式查询两路）。
全仓 go build / go vet / go test 通过，internal/agent/core 与
internal/memory 全绿，SDK 冻结 diff = 0。
2026-09-05 12:03:30 +08:00
bce1a043f2
fix(memory): core.New 漏接 rc.SetMediaStore，L0→L2 引用转移在生产从未生效
...
RelevanceContext.transferMediaRefs 依赖 c.mediaStore，而该字段只有
SetMediaStore() 能设置。搜遍全仓非测试代码，调用点为零——core.New() 里
没有，cmd/homed/main.go 里也没有。
上一层（1b634e7）把 AgentConfig.MediaStore 接到了 Agent.mediaStore，
漏了 rc 这一路。
后果是静默的：Prune 归档时 c.mediaStore 为 nil，transferMediaRefs 直接
return，而携带引用的 ContextEvent 已被归档删除 → 引用永久悬空在
context owner 上、计数永不归零 → 对应 blob 永远不会被 GC 回收。
## 为什么测试没抓到
mediaref_test.go 里我手工调了 rc.SetMediaStore(ms) 才测转移逻辑。
**测试验证了函数正确，没验证它被接上了。** 与 findPluginPID 那次同一
个教训：测了一件不会自然发生的事。
## 顺带全字段审计
写脚本比对 AgentConfig 的 32 个字段与 New() 函数体的引用情况，
确认无第二处漏接。
2026-09-05 12:02:34 +08:00
12cb456316
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
d1373ef44a
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 05:53:17 +08:00
2533ccd8e0
feat(memory): L3 图库媒体反查 + 修 L2→L3 引用泄漏
...
媒体记忆四层收尾。方案 A：只做引用，不建媒体实体节点。
## 为何不把媒体建成图库实体
图库里的实体与关系全部来自**描述文本**的 NLP 提取——描述经
mediaSummaryForEvent 进 L0 事件的 Input，随归档进 L2 文档的 Content，
蒸馏时提取器自然从描述文字里抽出实体和关系。检索能力已经具备。
若再把媒体本身建成节点，节点名只能从描述里取，而描述会被重新生成
（换个视觉模型、补一次描述，名字就变了），于是同一张图会在图谱上留下
多个语义模糊的节点。代价换不来能力。
所以这一层只做一件事：**反查**。图库句子写着「[image a1b2c3d4e5f6]
一张紫蓝红三色带图」，要能从这条句子取回那份字节。
## CommitWithMedia：新增方法而非改签名
Commit 有 10 个非测试调用点 + 21 个测试调用点。为一个多数调用方都不需要
的返回值改全部签名不划算。新增 CommitWithMedia 返回
map[句子文本]sentences.id，Commit 内部转调同一份落库逻辑。
## digest 靠正则从文本反解
三元组由 NLP 提取器从纯文本产出（nlp.ToMemoryTriple 只填 Subject/
Relation/Object/Confidence/SentenceText），提取链路上没有任何位置能塞进
结构化的 digest。要贯通就得改 internal/nlp 的整条数据流。而媒体标记本身
是我们自己按固定格式写进文本的，反解是最省的可靠做法。
配套加 media.ResolvePrefix：文本里是 12 位短 digest（完整 64 位会把一行
撑爆且无助人眼辨认），media_refs 主键要完整 digest。
**前缀歧义视为错误而非"取第一个"**：挂错引用会让 GC 删掉仍被引用的内容。
完整但不存在的 digest 也报错，否则调用方会挂一条孤儿引用。
## 顺带修掉 L2→L3 的引用泄漏
这是上一层（1b634e7）留下的缺口：我当时只处理了 L0→L2 的引用转移，
漏了 L2→L3 这一跳。archiveColdDocs 调 docStore.Remove(doc.ID) 时不注销
媒体引用——文档一旦消失就再没有任何东西能告诉我们它引用过哪些 digest，
media_refs 里那条记录永久悬空、引用计数永不归零，对应 blob 永远不会被
GC 回收。
新增 releaseDocMedia。L2→L3 这一跳是**释放**而非转移，因为图库存的是从
描述文本抽出的实体与关系，不再持有字节；媒体此时已完成使命。
顺序有讲究：必须在 commitTriplesWithMedia 之后释放。那一步已把引用挂到
graph_sentence owner 上，先销后挂会让引用计数瞬时归零，此时若后台 GC
正在跑就会把内容当孤儿清掉。
## 顺带修 Pending 的排除逻辑遗漏（承上一提交）
## 测试
graphmedia_test.go 11 例。核心是 TestBindSentenceMedia_RoundTrip：
写入 → 提交 → 从句子 id 反查 digest → 取回字节逐字节比对 → 跑 GC(0)
确认被引用的内容不被清。
其余覆盖：正则不误命中普通方括号（[注意]/[TODO] 不能当 digest，否则会拿
假前缀去 ResolvePrefix）、无法补全的 digest 不挂引用、媒体关闭时全链路
静默 no-op、releaseDocMedia 释放后 GC 真能回收、200 个样本的前缀补全
要么唯一命中要么明确报歧义。
TestCommit_StillWorksAfterRefactor 记录一个既有行为：重复提交时
entitiesCreated 不归零，因为 SQLite 的 ON CONFLICT DO UPDATE 也算一行
affected。用 main 分支的 graph.go 单独跑过基线确认与本次重构无关，
该字段只用于日志，故记录现状不改行为。
全仓 go build / go vet / go test 通过，internal/agent/core 与
internal/memory 全部 -race -count=2 通过，SDK 冻结 diff = 0。
2026-09-04 22:52:30 +08:00
7ac40811e7
feat(memory): 媒体 GC 与描述生成两条后台循环
...
补齐媒体记忆的最后两块：容量上限真正生效，描述文本成为持久语义记忆。
## mediaGCLoop：让容量上限不再形同虚设
CAS 的 GC 只在被显式调用时执行，Put 路径不触发它。此前配置项
core.memory.media.max_mb 注册了却没有任何调用方——一次 see_video 抽 10 帧，
帧本身在工具结果被 Prune 后就没人引用了，若无人清理会一直堆在磁盘上。
现在按 gc_interval（默认 6h）周期调 GC(gc_min_age)。两个不变量：
- 有引用的内容永不删除，即使超容量（宁可超限也不断引用）
- gc_min_age（默认 1h）保护刚 Put 还没来得及 AddRef 的项——它们
refcount 也是 0
## mediaDescribeLoop：描述才是能活过 GC 的那部分
blob 会被容量 GC 淘汰，而描述留在 media 表里，并经 mediaSummaryForEvent
写进 L0 事件、随归档进 L2 文档、经蒸馏进 L3 图库。于是「那张紫蓝红三色
带图」在原始字节早已被清掉之后仍然可被检索到。
复用既有的视觉回退链（resolveModalFallback + chatModalFallbackBatch），
不新造一套模型调用。
三个刻意的决定：
- **走后台而非入库时同步**：视觉模型一次调用生产实测 9.6s。放在对话
路径上会让每张图都给回复加十几秒，而描述的价值是几个月后还能检索到，
不是这一轮——这一轮模型本来就直接看着图。
- **逐条而非批量**：批量拿回来是一整段文字，无法可靠切分回各自的
digest（模型未必按序号输出，也可能把两张图合并成一句）。宁可多几次
往返也要保证「描述 ↔ digest」的对应关系确定。
- **默认关闭**（describe_on_ingest=false）：它消耗视觉模型配额。开启后
每 30s 最多处理 4 条，不跟对话抢额度。
失败处理分三类：
- 网络抖动/配额 → 不标记，下轮重试
- 空回复 → 视作失败（上游剥离媒体时通常回空，与 modalfallback 同理）
- 不可描述（kind=other、blob 已丢失）→ 标记 described_by=unsupported/
content-missing，退出队列
## 顺带修掉 Pending 的一个真缺陷
测试写出来才发现：Pending 原先只看 `description = ''`，于是被标记为
described_by=unsupported 但 description 仍空的项**每轮都会被重新取出来
重试**，永久占着 LIMIT 的名额，真正需要描述的新项永远轮不到。
改为同时要求 described_by 也为空。
这是「先写断言再看它是否成立」抓到的——原本我以为标记一下就够了。
## 测试
medialoop_test.go 7 例：两条循环在禁用时立即返回（nil store / 零间隔 /
describe 关闭三种形态，不留空转 goroutine）、GC 清孤儿保留有引用项、
minAge 保护新项、无可用源时不误标记、不可描述大类被标记后退出队列。
media_test.go 补 1 例专测 Pending 的排除逻辑。
全仓 go build / go vet / go test 通过，SDK 冻结 diff = 0。
2026-09-04 22:00:03 +08:00
84092fc05a
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:45:17 +08:00
6c797ddb04
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
1b634e77a7
feat(memory): 媒体接入 L0/L2——digest 挂到对话事件，归档时引用随之转移
...
在 aeb1c97
2026-09-04 20:53:32 +08:00
8462a4c380
fix(packaging): arm64 GUI 塞了 x86-64 electron——按目标架构取运行时并强制校验
...
## 现象
v1.0.0 与 v1.0.1 的 arm64 full/client 包里，homed 与 waiter 都是正确的
aarch64，但 GUI 目录下的 electron 是 x86-64。实测从 gitcode 下载的
homeagent-full_1.0.1_arm64.deb：
usr/bin/homed ELF 64-bit ARM aarch64 ✓
usr/bin/waiter ELF 64-bit ARM aarch64 ✓
usr/lib/homeagent-gui/electron ELF 64-bit x86-64 ✗
在 arm64 机器上装完，双击 GUI 得到 Exec format error。
## 根因
build_gui 无条件 `cp -r "$gui_dir/node_modules/electron/dist"/*`，而那里
永远是 **host 架构**（本机 x64）。目录名 homeagent-gui-linux-arm64 只是
命名，内容从未跟着目标架构变。
这与 v1.0.0 arm64 缺 homed 是同一类错误：**产物名声称的架构与实际内容
不符**，且都因为没做交叉验证而漏过整个发布流程——包名对、目录名对、
主二进制对，只有一个嵌套的运行时是错的，没有任何一环会喊出来。
## 修法：三层取 + 一道强制校验
1. 优先从 electron 缓存取目标架构的 zip
（~/.cache/electron/<hash>/electron-v<ver>-linux-<arch>.zip）。
版本号从已安装的 node_modules/electron/package.json 读，保证运行时
与 app 依赖一致。
2. 回退到 host node_modules/electron/dist 前**先比对架构**：只有目标
架构 == host 架构才允许；否则打印缺哪个 zip、该放哪里，然后跳过 GUI。
3. 最后用 `file -b` 校验 electron 二进制的实际架构必须匹配目标架构，
不符就删掉 GUI 目录并跳过。
第 3 步是关键。前两步是「尽量拿对的」，第 3 步是「绝不发错的」——
宁可不发 GUI，也不发装了跑不起来的包。`GUI built:` 日志行也加上架构
标注，日常构建就能看见。
## 验证
下载 arm64 electron 运行时（electron-v33.4.11-linux-arm64.zip，106MB，
unzip -t 无错，解出的 electron 确认为 ARM aarch64）放入缓存后重打包，
三个 arm64 deb 实测：
server homed=aarch64 waiter=aarch64
full homed=aarch64 waiter=aarch64 electron=aarch64
client waiter=aarch64 electron=aarch64
amd64 对照 electron=x86-64
arm64 tar.gz 从 120M 涨到 125M，也印证运行时换成了正确架构。
2026-09-04 20:12:35 +08:00
fc2b01c81a
fix(packaging): arm64 GUI 塞了 x86-64 electron——按目标架构取运行时并强制校验
...
## 现象
v1.0.0 与 v1.0.1 的 arm64 full/client 包里，homed 与 waiter 都是正确的
aarch64，但 GUI 目录下的 electron 是 x86-64。实测从 gitcode 下载的
homeagent-full_1.0.1_arm64.deb：
usr/bin/homed ELF 64-bit ARM aarch64 ✓
usr/bin/waiter ELF 64-bit ARM aarch64 ✓
usr/lib/homeagent-gui/electron ELF 64-bit x86-64 ✗
在 arm64 机器上装完，双击 GUI 得到 Exec format error。
## 根因
build_gui 无条件 `cp -r "$gui_dir/node_modules/electron/dist"/*`，而那里
永远是 **host 架构**（本机 x64）。目录名 homeagent-gui-linux-arm64 只是
命名，内容从未跟着目标架构变。
这与 v1.0.0 arm64 缺 homed 是同一类错误：**产物名声称的架构与实际内容
不符**，且都因为没做交叉验证而漏过整个发布流程——包名对、目录名对、
主二进制对，只有一个嵌套的运行时是错的，没有任何一环会喊出来。
## 修法：三层取 + 一道强制校验
1. 优先从 electron 缓存取目标架构的 zip
（~/.cache/electron/<hash>/electron-v<ver>-linux-<arch>.zip）。
版本号从已安装的 node_modules/electron/package.json 读，保证运行时
与 app 依赖一致。
2. 回退到 host node_modules/electron/dist 前**先比对架构**：只有目标
架构 == host 架构才允许；否则打印缺哪个 zip、该放哪里，然后跳过 GUI。
3. 最后用 `file -b` 校验 electron 二进制的实际架构必须匹配目标架构，
不符就删掉 GUI 目录并跳过。
第 3 步是关键。前两步是「尽量拿对的」，第 3 步是「绝不发错的」——
宁可不发 GUI，也不发装了跑不起来的包。`GUI built:` 日志行也加上架构
标注，日常构建就能看见。
## 验证
下载 arm64 electron 运行时（electron-v33.4.11-linux-arm64.zip，106MB，
unzip -t 无错，解出的 electron 确认为 ARM aarch64）放入缓存后重打包，
三个 arm64 deb 实测：
server homed=aarch64 waiter=aarch64
full homed=aarch64 waiter=aarch64 electron=aarch64
client waiter=aarch64 electron=aarch64
amd64 对照 electron=x86-64
arm64 tar.gz 从 120M 涨到 125M，也印证运行时换成了正确架构。
2026-09-04 20:12:35 +08:00
2764b90f4c
docs(git): 发布分支改为一个中版本一条，补三级发布通道规范
...
## 一个中版本一条发布分支
原规范写 release/vX.Y.Z（含 patch 位），实践中 1.0.0 与 1.0.1 各建了一条
分支，导致同一条 1.0.x 发布线被切成互不相连的碎片——追溯时无法用一条
分支看完整条线的演进。改为 release/vX.Y.x，patch 位用 x 占位，
承载该中版本全部 patch 直到下一条中版本分支切出。
## 三级发布通道（alpha / beta / 正式）
通道由 tag 区分而非分支：三者共用同一条 release/vX.Y.x。
alpha vX.Y.Z-alpha.N 功能齐了未充分验证 仅内部自测
beta vX.Y.Z-beta.N alpha 问题已修 小范围试用
正式 vX.Y.Z 通过验证可上现网 所有用户
这是 semver 标准预发布语义（1.1.0-alpha.1 < 1.1.0-beta.1 < 1.1.0），
版本比较逻辑天然认得，无需额外约定。允许跳级但要在发布说明写明理由；
alpha/beta 产物不上现网——预发布通道的存在就是为了不拿 24/7 服务冒险。
## 回流仍是 cherry-pick
明确不改 merge：merge 会把已发布的版本号带进 main，与「main 的
meta.Version 始终是下一个未发布版本」直接矛盾。
新补一条：修复落地当天要 pick 到所有活跃 feature 分支，否则它们合回
main 时可能带回旧代码（2026-09-04 的 stage 双重解锁修复即同时 pick 到
main 与 feature/memory-media）。
## 运维纪律沉淀
把今天走通的部署流程写进第四节，其中两条是踩过的坑：
- 备份配置库用 sqlite3 .backup 而非 cp（WAL 模式下 cp 可能拿到
不一致快照）
- install -m 0755 替换而非 cp（原子 rename，不写坏运行中的进程镜像）
健康检查列出六项，含「一次真实对话」与「fatal error 计数为 0」。
## 当前分支对齐
第三节更新为 2026-09-04 的实际状态，并记录 1.0.x 的 tag 历史表
（含 v1.0.2 未使用的原因、v1.0.3 直接跳正式 tag 的理由）。
按 patch 号命名的历史发布分支标注为应当删除的遗留形态。
2026-09-04 20:11:19 +08:00
b292a1dd99
fix(proc): stage 协调器双重解锁——内核本体 fatal 崩溃的真因
...
## 现象
2026-09-04 06:56:18 生产 homed 主进程直接死亡，退出码 2，
带走全部 27 个子进程插件。
fatal error: sync: unlock of unlocked mutex
proc.(*Host).endStage(...) host.go:189
proc.(*coreHandler).runStage.func1() stage.go:94
core.(*StageHost).RunStage.func1() stages.go:190
stage.go:94 与 stages.go:190 各有一层 recover，专为「插件出错不拖垮内核」
而设，却全部失效：**sync.Mutex 的双重解锁走 runtime fatal，不是 panic，
recover 结构上就拦不住**。这就是本次「插件崩溃被隔离」的设计没能生效、
内核本体整体死亡的原因。
## 根因
endStage 把 coord.leave()（递减 inflight、判定「我是最后离开者」）放在
coordMu 临界区**之外**，而摘除 h.coord 在临界区**之内**，留出窗口：
A.endStage: leave() → inflight 1→0, last=true，尚未摘除 h.coord
B.beginStage: 看到 h.coord != nil，以「后到者」身份 enter，inflight 0→1
（后到者按设计不取 stageMu）
A.endStage: h.coord = nil；stageMu.Unlock() ← 第 1 次
B.endStage: leave() → inflight 1→0, last=true → stageMu.Unlock() ← 第 2 次 💥
B 从未持有 stageMu，却因挂进一个正在收尾的协调器而被判成「最后离开者」，
对同一把锁解了两次。崩溃前一行日志是 config_list_keys 的结果——那一刻
正好有 stage 扇出，与竞态窗口重合。
## 修复
把「递减 inflight → 判定最后离开者 → 摘除 h.coord」收进同一个 coordMu
临界区，后到者再不可能挂进已收尾的协调器。为此把 leave() 拆成：
- depart()：纯计数，由 endStage 在 coordMu 内调用
- finish()：共享段回读 + arena 压实，在 coordMu 外、但仍在
stageMu.Unlock() 之前（先放锁会让下一轮 stage 在回读未完时改写共享段）
leave() 保留给单测。
同一函数的第二个隐患一并修掉：首进者的 enter()（含 WriteAll 写共享段）
原先在 coordMu 之外，后到者可能拿到 coord 就去读**写了一半**的段。
现在 enter() 在锁内完成。
beginStage 错误路径的 stageMu.Unlock() 必须保留并已加注释说明：
runStage 的 defer endStage(coord) 是在 beginStage 返回 err 的检查**之后**
才注册的，这条路径上没有任何人会替它解锁，漏掉就是整个 stage 通道永久卡死。
锁序 stageMu → coordMu；endStage 只解锁 stageMu 不获取，无环。
## 验证
反向验证：把 host.go stash 回旧版跑新测试 → fatal error: sync: unlock of
unlocked mutex；恢复修复 → 通过。测试抓的确实是这个缺陷。
5 个回归用例（host_stage_test.go）：
- 后到者不复用已收尾的协调器（直接构造那个时序，不靠调度巧合）
- 8 worker × 40 轮并发进出（旧实现下整个测试二进制 fatal 而非 FAIL）
- 同阶段多插件扇出共用一个协调器、仅最后离开者解锁
- 50 轮串行不泄漏（少解锁会在第二轮卡死）
- 四阶段序列 pre_action→chat→after_toolcall→post_action
internal/plugin/... 全量 -race -count=2 通过。
## 同类缺陷审计（本 commit 未改动其他文件，仅记录结论）
针对「recover 拦不住的 runtime fatal」这一整类做了全仓审计：
1. 跨函数持锁（本缺陷的形状，脚本枚举 Lock/Unlock 不配对的函数）
- proc/lock.go 的 Release/ForceRelease 同样「只 Unlock 不 Lock」，
但两者都在 ownerMu 下先检查 held/owner 再解锁，非持有者直接返回，
不存在双解锁路径。
- 其余 22 处 Lock/Unlock 计数不等的函数逐一复核：全部是多分支早退各自
解锁（waiter 的 goto nextMessage、sidecar.call 的五个错误分支、
lua adapterPool 的 cond.Wait 池模式等），配对正确。
2. 并发 map 读写（同样是 runtime fatal）
- 16 处「无锁访问 map」全部复核为安全：Locked 后缀约定（orderedLocked、
defsLockedRegisterSource）、调用方持锁（document 的 addSummary/
removeDoc/loadAll、registry 的 runStopHandlers/runOnRemoveHandlers）、
或启动期单线程（knowledge.scanAll、static_embedder 构造后只读）。
3. close of closed channel
- 全仓仅 sidecar.go 有同名变量的两处 close(ch)，但作用于不同集合成员，
且 Close() 前有 readerWg.Wait() 与 stopped 标志，reader 侧已 delete
出 pending，不会双关。
- 各插件 stopCh 的 close：healthcheck 用 select 守卫、clawhubadapter 用
stopOnce、evtring 用 running 标志、timer 交给 StopHandler 单次调用。
agentcli.Stop() 是裸 close(p.stopCh) 无幂等守卫，但 Registry 的六处
Stop 调用点都在同一把 r.mu 下先 delete(r.plugins)+摘 r.instances 再
Stop，不存在二次调用路径——记录为「依赖调用方约定」而非当前缺陷。
4. WaitGroup 误用：未发现 Add 出现在 goroutine 体内的形状。
5. 全仓 go test ./... -race：零 DATA RACE、零 FAIL。
2026-09-04 18:45:19 +08:00
299331015a
fix(proc): stage 协调器双重解锁——内核本体 fatal 崩溃的真因
...
## 现象
2026-09-04 06:56:18 生产 homed 主进程直接死亡，退出码 2，
带走全部 27 个子进程插件。
fatal error: sync: unlock of unlocked mutex
proc.(*Host).endStage(...) host.go:189
proc.(*coreHandler).runStage.func1() stage.go:94
core.(*StageHost).RunStage.func1() stages.go:190
stage.go:94 与 stages.go:190 各有一层 recover，专为「插件出错不拖垮内核」
而设，却全部失效：**sync.Mutex 的双重解锁走 runtime fatal，不是 panic，
recover 结构上就拦不住**。这就是本次「插件崩溃被隔离」的设计没能生效、
内核本体整体死亡的原因。
## 根因
endStage 把 coord.leave()（递减 inflight、判定「我是最后离开者」）放在
coordMu 临界区**之外**，而摘除 h.coord 在临界区**之内**，留出窗口：
A.endStage: leave() → inflight 1→0, last=true，尚未摘除 h.coord
B.beginStage: 看到 h.coord != nil，以「后到者」身份 enter，inflight 0→1
（后到者按设计不取 stageMu）
A.endStage: h.coord = nil；stageMu.Unlock() ← 第 1 次
B.endStage: leave() → inflight 1→0, last=true → stageMu.Unlock() ← 第 2 次 💥
B 从未持有 stageMu，却因挂进一个正在收尾的协调器而被判成「最后离开者」，
对同一把锁解了两次。崩溃前一行日志是 config_list_keys 的结果——那一刻
正好有 stage 扇出，与竞态窗口重合。
## 修复
把「递减 inflight → 判定最后离开者 → 摘除 h.coord」收进同一个 coordMu
临界区，后到者再不可能挂进已收尾的协调器。为此把 leave() 拆成：
- depart()：纯计数，由 endStage 在 coordMu 内调用
- finish()：共享段回读 + arena 压实，在 coordMu 外、但仍在
stageMu.Unlock() 之前（先放锁会让下一轮 stage 在回读未完时改写共享段）
leave() 保留给单测。
同一函数的第二个隐患一并修掉：首进者的 enter()（含 WriteAll 写共享段）
原先在 coordMu 之外，后到者可能拿到 coord 就去读**写了一半**的段。
现在 enter() 在锁内完成。
beginStage 错误路径的 stageMu.Unlock() 必须保留并已加注释说明：
runStage 的 defer endStage(coord) 是在 beginStage 返回 err 的检查**之后**
才注册的，这条路径上没有任何人会替它解锁，漏掉就是整个 stage 通道永久卡死。
锁序 stageMu → coordMu；endStage 只解锁 stageMu 不获取，无环。
## 验证
反向验证：把 host.go stash 回旧版跑新测试 → fatal error: sync: unlock of
unlocked mutex；恢复修复 → 通过。测试抓的确实是这个缺陷。
5 个回归用例（host_stage_test.go）：
- 后到者不复用已收尾的协调器（直接构造那个时序，不靠调度巧合）
- 8 worker × 40 轮并发进出（旧实现下整个测试二进制 fatal 而非 FAIL）
- 同阶段多插件扇出共用一个协调器、仅最后离开者解锁
- 50 轮串行不泄漏（少解锁会在第二轮卡死）
- 四阶段序列 pre_action→chat→after_toolcall→post_action
internal/plugin/... 全量 -race -count=2 通过。
## 同类缺陷审计（本 commit 未改动其他文件，仅记录结论）
针对「recover 拦不住的 runtime fatal」这一整类做了全仓审计：
1. 跨函数持锁（本缺陷的形状，脚本枚举 Lock/Unlock 不配对的函数）
- proc/lock.go 的 Release/ForceRelease 同样「只 Unlock 不 Lock」，
但两者都在 ownerMu 下先检查 held/owner 再解锁，非持有者直接返回，
不存在双解锁路径。
- 其余 22 处 Lock/Unlock 计数不等的函数逐一复核：全部是多分支早退各自
解锁（waiter 的 goto nextMessage、sidecar.call 的五个错误分支、
lua adapterPool 的 cond.Wait 池模式等），配对正确。
2. 并发 map 读写（同样是 runtime fatal）
- 16 处「无锁访问 map」全部复核为安全：Locked 后缀约定（orderedLocked、
defsLockedRegisterSource）、调用方持锁（document 的 addSummary/
removeDoc/loadAll、registry 的 runStopHandlers/runOnRemoveHandlers）、
或启动期单线程（knowledge.scanAll、static_embedder 构造后只读）。
3. close of closed channel
- 全仓仅 sidecar.go 有同名变量的两处 close(ch)，但作用于不同集合成员，
且 Close() 前有 readerWg.Wait() 与 stopped 标志，reader 侧已 delete
出 pending，不会双关。
- 各插件 stopCh 的 close：healthcheck 用 select 守卫、clawhubadapter 用
stopOnce、evtring 用 running 标志、timer 交给 StopHandler 单次调用。
agentcli.Stop() 是裸 close(p.stopCh) 无幂等守卫，但 Registry 的六处
Stop 调用点都在同一把 r.mu 下先 delete(r.plugins)+摘 r.instances 再
Stop，不存在二次调用路径——记录为「依赖调用方约定」而非当前缺陷。
4. WaitGroup 误用：未发现 Add 出现在 goroutine 体内的形状。
5. 全仓 go test ./... -race：零 DATA RACE、零 FAIL。
2026-09-04 18:43:05 +08:00
c552948d10
test(memory): 媒体存储的压力、冒烟与长稳测试
...
在 aeb1c97
2026-09-04 11:29:18 +08:00
aeb1c973ba
feat(memory): 内容寻址媒体存储（CAS）——图记忆支持二进制多媒体节点的底座
...
此前四层记忆全是纯文本载体，没有任何一层能存二进制：
L0 ContextEvent — Input/Response/ToolResults[].Output 全 string
L1 text.Event — 同上
L2 document.Doc — Summary/Content/Tags 全 string
L3 图库 — sentences.text TEXT UNIQUE，节点身份就是那串文本
于是 multimodal 插件注入的图只在本轮对话内可见（走 message 数组，不经
记忆），下一轮起只剩 ToolResultItem.Output 里那句
"[已将图片注入后续对话] /tmp/x.png"——一条路径字符串。那个文件被删或
被覆盖之后连线索都断了。
## 为何内容寻址而不是存路径
- 路径会失效。/tmp 下的探针图、下载缓存、别的进程的临时产物，记忆里
留个路径等于留个悬空指针。
- 同一内容常被反复注入（连问几轮同一张截图、see_video 相邻帧高度相似），
按 sha256 寻址天然去重。
- 内容即身份，与 L3 图库 sentences.text UNIQUE 思路一致：文本节点用文本
本身做身份，媒体节点用内容摘要做身份。
## 结构
元数据（SQLite media.db）与内容（磁盘 blobs/ 两级前缀分桶）分离，不把
blob 塞进库：单张图动辄几 MB，塞进去让每次 VACUUM/备份都拖着几百 MB 走，
WAL 也会迅速膨胀。
media(digest PK, kind, mime, size, width, height, origin_path, tool,
description, described_by, ref_count, first_seen, last_seen)
media_refs(digest, owner_kind, owner_id, created_at, PK 三列)
digest 既是主键也是文件名，所以没有 Path 字段——路径由 digest 推导，
不落库（落了就又是个会失效的引用）。origin_path 仅供人类溯源，注释里
明确标注不可用于读取。owner_kind 预留 context/document/graph_sentence。
## 几处刻意的决定
- Get 强制校验 digest：CAS 的全部保证建立在「文件名 == 内容摘要」上，
位翻转或外部误改必须被发现——把损坏的图喂给模型只会得到无从追溯的幻觉。
- 先写 .tmp 再 rename：中途崩溃不留半个 blob 被当成完整内容读走。
- AddRef 幂等：只有真插进 media_refs 才递增，否则计数虚高会让 GC 永远
不敢清。DropRef 用 MAX(0,...) 兜底防负数。
- Put 的空描述不冲掉已有描述（先到的可能来自更强的模型），但尺寸/工具名
这类前一次缺失的信息会被补写。Describe 是显式操作，允许覆盖。
- GC 两段 + minAge 保护：刚 Put 还没 AddRef 的项 refcount 也是 0，minAge
防「落地后还没挂上就被清掉」。有引用的项永不删除，即使超容量——宁可
超限也不断引用。
## 测试
21 例，覆盖去重 / MIME 归类 / 损坏检测 / 无残留临时文件 / AddRef 幂等 /
计数不为负 / DropOwner / GC 保留有引用项 / minAge 保护 / 容量淘汰 /
描述覆盖与补写策略 / Search 按描述与 kind 过滤 / Pending / data URL
往返 / Stats / 跨重启持久化。
本 commit 只加存储层，尚未接入 L0/L2/L3 与描述生成。
2026-09-04 11:03:36 +08:00
2f3f7a3db5
fix(release): upload_assets.py 按 go.mod 定位仓库根，不再数 dirname
...
脚本从 scripts/ 移到 deploy/scripts/ 后目录深度 1→2，而两层 dirname
是写死的，于是资产目录解析成 deploy/dist/release，上传直接
FileNotFoundError（v1.0.1 首次上传即因此失败）。
这与 v0.7.2 的 5006712
2026-09-04 10:34:51 +08:00
ef77e1eefe
fix(build): arm64 交叉编译补 CXX——「刻意不设 CXX」的注释判断是错的
...
build.sh 的 linux/arm64 分支此前刻意不设 CXX，注释理由是「设了会让
Go 用 aarch64 的 g++ 去链接，而它对 host 产生的 .o 报 file format
not recognized」。
那个判断是错的。那个报错的真因是 cmd/{homed,waiter}/*.syso（x86-64
COFF Windows 资源对象）被 Go 无条件链进了目标，与 CXX 无关。四组对照：
syso 在 + 无 CXX → Relocations in generic ELF (EM: 183)
syso 在 + 有 CXX → 000000.o: file format not recognized
syso 隐藏 + 无 CXX → Relocations in generic ELF (EM: 183)
syso 隐藏 + 有 CXX → 成功，ELF aarch64
两个条件缺一不可。之前诊断时只单独试了其中一个，得出错误结论后写进
注释固化了下来，于是 arm64 的 homed 一直编不出（v1.0.0 发布时 arm64
deb 里只有 waiter/initconfig）。
本脚本的 hide_syso_for_target 已处理 syso 那半，这里补上 CXX 那半。
实测 v1.0.1：build.sh linux/arm64 直接产出 ELF aarch64，arm64 的
full/server deb 里 homed 与 waiter 均为 aarch64。
2026-09-04 10:24:55 +08:00
51627fa96c
fix(multimodal): 媒体改挂独立 user message，落实「注入后续对话」的原意
...
插件三个工具的返回文案一直写着「已将图片注入后续对话」，d75ba51 的提交
说明也写着「模型在下一轮 LLM 请求里直接看到图」。但实现是把 block 挂在
tool message 的 content 数组上——role=tool 上的多模态 content 不被当作
可视内容。
同一张图、同一个模型、三轮实测：
图在 user message → 3/3 读到，prompt_tokens 7089
图在 tool message → 0/3（模型答「我没能读到这张图」），tokens 7967
tool 纯文本 + 后接 user → 3/3 读到，tokens 7570
tool message 那轮 token 反而更高，说明 base64 确实进了上游，只是模型看
不到它。这解释了为什么此前只有回退链（转文字进 tool message 的纯文本
content）能用，而「主模型直接看图」这条路从 d75ba51
2026-09-04 07:49:30 +08:00
75dfff5406
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
00d0339f99
docs: 文档与发布脚本同步到 v1.0.0 子进程架构
...
README/架构文档仍在描述 C ABI 动态库加载，与 v1.0.0 实际实现不符。
新用户按文档走会去做 -buildmode=c-shared，产物新内核根本不加载。
README.md / README_EN.md：
- 设计要点补子进程架构段（三面通信、崩溃自愈、真热重载）
- 代码结构 plugin/ 描述：.so 动态加载器 → 子进程加载器
- 项目状态补 v1.0.0 条目（6 类缺陷 + 实测数字），v0.9.0 标注 ABI 已退场
- 新增「下载」章节：三变体对照 + 各平台包格式 + macOS 限制
assets/docs/{zh,en}/ARCHITECTURE.md：
- 四种加载方式表：外部 .so/C ABI → 外部子进程/握手+stdio JSON-RPC
- 加载流程改写为 exec.Command → 继承 fd → 握手 → init → start
- 内置 vs 外部对照表 7 行更新
- 新增「子进程插件的三个通信面」小节，含每个面的选择理由
assets/docs/{zh,en}/OVERVIEW.md：插件系统段落改写
deploy/ 发布脚本三处回归（v0.7.2 的 5006712
2026-09-03 19:26:17 +08:00
44a66ee837
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 的桩，43b199a）只定义了
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
d0ba833728
Merge branch 'feature/plugin-proc-migration' into main
...
插件架构子进程化迁移（8-9 周）+ 崩溃自愈收尾。
## 消除的 6 类 C ABI 前提缺陷（对照 plan.md §11.0）
| 缺陷 | 原状 | 现状 |
|---|---|---|
| 热重载失效 | DF_1_NODELETE 让 dlclose 成 no-op | 换 plugin.bin 即生效 |
| 崩溃隔离缺失 | 插件 panic 带崩 homed | 子进程独立崩溃 + 自动重启 |
| stage lost update | 副本模型互相覆盖 35.8~36.8% | 共享内存段，0% |
| cgo 超时泄漏 | 现网泄漏 26 次线程 | 整套架构零 cgo，Kill 真取消 |
| output_send 假成功 | 永远返回 queued+nil | RPC 同步等真实结果 |
| 能力断层 | Windows 只见 3 字段无写回 | 18 字段全可见可写回 |
## 架构
- 控制面：stdio JSON-RPC（51 个 core.* method）
- 数据面：共享内存段（全部子进程共用一块，避免退化成副本模型）
- 通知面：事件环 + 三平台通知（Linux eventfd / macOS pipe / Windows Event）
- 权限梯度显式化为三道闸：procCore 命名字段 + manifest 能力声明 + RPC 边界拒绝
- C ABI 通道整体删除（-3198 行）
## 子进程生命周期管理
- 每子进程专职 waitLoop（cmd.Wait 唯一调用点），不依赖 stdout EOF
- proc.Supervisor 集中台账，Host.Close 先 StopAll 再拆段
- 崩溃自愈：摘注册面（工具+stage+IO通道）→ 移除注册表 → 退避重启
- Linux Pdeathsig 兜底 homed 被强杀场景
## 门禁
make test 零失败 / go vet 无告警 / SDK 公开接口 diff 为空（接口冻结不变量）
2026-09-03 13:46:51 +08:00
56498d3592
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
ad1b05e6ef
docs(plan): 第 12 节 —— 子进程化迁移剩余工作与目标效果
...
迁移主体已完成上生产（内核 v1.0.0，17 插件全部子进程化），
但有若干项未做完或未达成。写进 plan.md 而非只留在对话里，
避免下次接手时靠猜。
八个小节按「阻塞程度」排：
**12.1 合并到 main + 发布分支** —— 卡在四个决策点，非技术阻塞：
merge 方式（--no-ff vs squash）、是否删 feature 分支、release 构建是否
再替换生产二进制、SDK 仓是否同步。附完整执行序列。
记了一个易错点：v1.0.0 tag 当前打在 feature 分支中间点 d524a68，
按规范应在 release 分支上，需删除重打。
**12.2 验收清单两项未达成** —— 这两项在迁移计划里已如实标 ⚠️ ：
- SetToolBlocks 仍未实现。C ABI 时代也是空实现故不算回归，
但 §3.8 明确承诺过「二进制写入 arena + Slice 描述符回传」，没兑现。
- 内存 88MB 远超「基线 +29MB」。根因是每插件静态链接整个 Go runtime，
15 个不同二进制无共同物理页（PSS/RSS 99.9% vs 基线 44%）。
基线用 2.68MB 最小插件复制 17 份，绝对数字本就不可比。
**12.3 事件环零真实负载检验** —— 机制完成、压测通过（2.29ms 与实验 4
一致），但 grep 确认无任何插件使用 Events().Subscribe。压测是我构造的
负载，生产上这条路径从未被真实插件走过。只写 ✅ 会掩盖这一点。
**12.4 三套 ABI 只收敛两套** —— C ABI 删了、Windows DLL 收敛了，
Lua 仍走独立解释器路径。§9.2 那句「三套收敛为单一 RPC」本轮兑现 2/3。
不阻塞是因为 Lua 不经 C ABI，不属于要消除的 6 类缺陷。
**12.5 Windows 无真机验证** —— 只做了交叉编译 + 单元测试。
已知语义差异（Event 是二元信号非计数器）推理上不影响正确性，
但没在真机确认过。§9.2 声称 Windows「从受害者变受益方」缺实证。
**12.6 stage 往返省两次 IPC** —— 132µs 里编解码只占 3.7µs，
其余是 3 次进程往返（invoke + 插件侧反向 lock/unlock）。合并后预期
降到 ~30µs。风险是锁持有时机改变，插件若在 handler 里再请求锁会死锁。
**12.7 遗留项** —— homed 主 heap 2.36GB（与插件无关）、鸿蒙端未提交改动。
**12.8 已达成目标留档** —— 6 类缺陷逐条对账，每条附证据
（测试名或生产日志），便于日后确认哪些是真解决了。
2026-09-03 08:50:48 +08:00
da560e6fbf
chore: 修 .gitignore 误伤源码目录（4 类，28 个已跟踪文件）
...
`git ls-files | xargs -n1 git check-ignore --no-index` 查出 49 个已跟踪
源码文件落在 ignore 规则下。它们现在能提交只是因为「已跟踪文件不受
.gitignore 影响」这条 git 规则在兜着——**新增文件会默默不入库**。
## 根因一：缺前导斜杠（28 个文件）
`knowledge/` / `memory/` / `scripts/` 不带前导斜杠，git 把它们当作
「任意层级的同名目录」：
memory/ → 吞掉 internal/memory/ 24 个文件
knowledge/ → 吞掉 internal/knowledge/ 3 个文件
assets/knowledge/
scripts/ → 吞掉 deploy/scripts/ 1 个文件
本意只是忽略根级运行时数据目录。旁边的 `/adapters/` 就写对了，
这三条是漏了斜杠。
修法：补 `/` 前缀。验证两侧行为：
根级 knowledge/y.md memory/z.db scripts/tmp.sh 仍被忽略 ✓
深层 internal/memory/new.go internal/knowledge/new.go
deploy/scripts/new.sh 可入库 ✓
## 根因二：internal/meta/ 整目录被忽略（1 个文件）
引入于 19e51e6（2026-07-12），同批还有 `.go/`、`.local/`、
`internal/plugins/openclaw/{manager,pysimulator}/`（后两个目录现已不存在）。
`internal/meta/meta.go` 是内核版本号与元数据的唯一数据源，本轮升 1.0.0 时
`git add` 报「paths are ignored」，就是这条。已跟踪所以改动能提交，
但新增 meta 文件会丢。直接删掉这条规则。
## 保留的 20 项不是缺陷
`third_party/homeagent-sdk/example/` 下 20 个已跟踪文件（plg.json +
plugin.go）仍在规则覆盖下，这是**有意的**：外部插件维护在独立 SDK 仓
（决策 sdk_repo_only），主仓只需要这 20 个源码文件参与构建，不要 SDK 仓的
main.go/go.mod/go.sum。删掉该规则会让 60+ 个文件涌进主仓——实测确认过。
已在两处 ignore 段落写明理由，避免后来人「修」错方向。
验证：修复后 check-ignore 扫描从 49 降到 20（全部是有意保留的 example/）；
go build ./... 通过。
2026-09-03 08:39:23 +08:00
217f35d0e9
docs: Part 6.6 文档收尾 —— 迁移计划/接口矩阵/PLUGIN_DEV 全量更新
...
## plugin-migration-plan.md
Part 6 标记完成，并**记录实际执行与计划的偏离**而非假装一致：
原计划「逐插件迁移，随时回退」。用户决策改为彻底舍弃 .so、无回退通道，
本轮直接删 internal/plugin/cabi/。因此【V】的「.so ↔ .bin 混跑集群冒烟」
不再适用——新内核根本不认 .so。改为验证「新内核面对旧 .so 给可操作错误
且不崩溃」，已在真实二进制上确认。
最终验收清单加「结果」列，13 项逐项对账。**两项未完全达标，如实标注**：
- #9 SetToolBlocks：method 已定义并划入 CapCore，但内核侧仍返回未实现。
C ABI 时代它也是空实现（§1.4），故不是回归，但也没兑现 §3.8 的承诺。
- #13 内存：15 进程 RSS=88.0MB，远超「基线 +29MB」。根因是每插件静态链接
整个 Go runtime，15 个不同二进制无共同物理页（PSS/RSS 99.9% vs 基线 44%）。
实验 5 基线用的是 2.68MB 最小插件，绝对数字不可比；结构性指标
（均摊线程 5.5 vs 4.9）同量级。
新增两节实录：Part 6.5 生产切换（执行顺序为何不能反过来、hmap 正规通道
vs 手工拷贝的对照表、真实 QQ 消息的端到端证据链）与 Part 6.6 压测数据。
## plugin-interface-matrix.md
状态从「基线 v1」升为「完成 v2」。三个合同面逐一标注达成情况：
- 合同面 B：51 个整数 method id 已平移为 Method* 字符串常量。保留原表作
历史对照，但注明 case 25（CoreFreeString）无对应 method（内存管理是 C 层
特有问题），以及 io.setToolBlocks 已定义但内核侧未实现。
- 合同面 C：C1 标题从「今天」改为「迁移前」（迁移已完成，「今天」会误导）；
C2 补上「全部插件共享同一块 memfd」这个关键决定及其理由——第一版设计
是每插件一段，那会退化成副本模型复现 lost update。
- 第六节「新获得的能力」加「实际结果」列。事件订阅标注机制已完成但
零用户使用，故未经真实负载检验——这比只写 ✅ 诚实。
「刻意不给」清单同步为带 API 后缀的新命名（SelftestAPI 等），与
capability.go 的 withheldCapabilities 对齐，并说明为何加后缀：
不加时子串匹配会把 tool.register / io.setToolBlocks 误判为泄漏 ToolAPI。
## PLUGIN_DEV.md（中英双份）
C ABI 时代的描述全部改掉：
- 「动态 .so/.dll 插件」→「子进程插件」
- 「生成 C ABI bridge（z_bridge_gen.go + z_entry.c）」→ 子进程运行时三文件
- 「go build -buildmode=c-shared」→「go build（CGO_ENABLED=0）」
- 平台二进制表：三平台统一 plugin.bin（bundle 包内按 goos.goarch 区分）
- 「不能跨 C ABI 边界序列化」→「不能跨进程序列化」
- 「ABI v2 写回」→「Stage 写回」
新增 v1.0.0 破坏性变更提示框，五条要点：.so 不再加载、业务代码不需改、
entry 字段对 Go 插件已无意义、不再需要 cgo、Windows 从 3 字段升到全字段。
保留 .so 字样的只有变更说明本身（3 处），其余全部清理。
2026-09-03 08:12:30 +08:00
d524a68ead
sdk: 同步 SDK 仓 meta 到 1.0.0（vendored 侧）
...
SDK 仓的 5ed8d65 在主仓这边的对应提交。主仓经 replace 引用
third_party/homeagent-sdk，其 sdk/ 与 meta/ 由主仓一并跟踪
（只有 example/ 与 tools/ 被 .gitignore 忽略）。
2026-09-02 23:02:26 +08:00
1c18b57ae7
meta: 内核版本升到 1.0.0；生产切换脚本改走 hmap 正规通道（Part 6.5）
...
## 版本号
1.0.0：外部插件从 C ABI 动态库迁到子进程 + 共享内存。首个不再加载
`.so`/`.dll` 的版本，与 0.9.x 不兼容（存量插件必须用新版 plugindev 重编）。
SDKCompatibleVersion 同步升 1.0.0。
同时删掉 ABIVersion / CABINum / 51 个 Core<Method> 整数 ID —— 随 Part 6.2
删 internal/plugin/cabi/ 就已无使用者（grep 确认只剩定义处）。留着会让人
以为 C 层协商还在生效，或以为加 method 要同步维护那张整数表。
⚠️ 注意 Makefile 的 `VERSION ?= $(shell git describe --tags --dirty)`：
实际注入值来自 git tag，meta.go 里的默认值只在不带 ldflags 时生效。
make build 当前注入 v0.9.1-56-g2572688-dirty。要让 1.0.0 真正生效需打
v1.0.0 tag 或显式传 VERSION=1.0.0。
## 生产切换脚本重写
第一版是手工拷 plugin.bin + 手改 plugin.json 的 entry —— 那等于**重新实现
了一遍 hmap 解包逻辑，且实现得更差**。漏掉的东西：
platforms 字段 hmap 内的 plugin.json 本来就写对了
平台二进制选择 我硬编码 _linux_amd64，正规路径用 platformBinary()
overwrite 语义 StopAndUnload 停旧实例但**保留配置表**
失败回滚 os.Rename 备份旧目录，解包失败自动恢复
校验 validatePackage 查 manifest + 各平台二进制齐全
配置保留那条尤其关键：生产 17 个插件都有配置（qq 账号、weather 默认城市、
browser profile 路径）。我的脚本恰好没碰配置表所以侥幸不丢，但那是运气
不是设计。
改为 POST 到 pluginmgr 的 HTTP 端点（127.0.0.1:9876/plugins），
传 {path, overwrite:true} 走 installFromPath → installFromData。
保留的一个设计：**先全部校验再动手**。任一插件缺 hmap 就整批中止——
新 homed 不认 .so，「一半装了一半没装」的中间态最难排查。
## 生产切换已执行
顺序（先换二进制再装包，而非反过来）：
1. systemctl stop homeagent
2. 换 /usr/local/bin/homed
3. 起服务 —— 15 个 .so 插件报可操作错误被跳过，homed 本体与 16 个内置正常
4. 逐个 POST 装 17 个 hmap（overwrite=true）
5. 待重启核对
第 3 步顺带在真实二进制上验证了 Part 6.2 的可操作错误：
[plugin] dynamic weather: 检测到旧 C ABI 产物（plugin.so/.dll/.dylib）。
外部插件已改为子进程模式，请用新版 plugindev 重编产出 plugin.bin
（业务代码无需修改）
不崩溃，只跳过。若反过来先装包，旧 homed 的 StopAndUnload 会停掉 qq
消息通道且无法重载 .bin，会卡在「插件全挂」的状态。
结果：17/17 成功，全部 config_kept=true；0 个残留 .so；17 个 plugin.bin
均有执行位；17 个 manifest 的 entry 均为 plugin.bin；无 .bak 残留。
bundle 包正确挑了当前平台（weather 目录只留 8.7MB 的 linux/amd64 那份）。
备份：/home/newqqagent-migration-backup-20260902-214812
（plugins 全目录 + homed.old + homeagent.service，162MB）
验证：go build ./... 通过；go test ./... 全仓无失败。
Ref: docs/zh/plugin-migration-plan.md Part 6.5
2026-09-02 22:40:47 +08:00
930d4090fc
proc: 性能基准 + 流式压测（Part 6.6 验收项）
...
此前只做了功能冒烟与内存快照，延迟与压测都没测。这两项是计划里
明确列出的验收条件，补上。
## 基准结果（AMD Ryzen 7 7840HS）
| 项目 | 实测 | 基线 |
|---|---|---|
| 工具调用 RPC 往返 | 24.1 µs | 实验 11: 19.6 µs（同量级） |
| 锁仲裁（内核侧） | 0.76 µs | 见下注 |
| 事件环写入 | 95 ns | — |
| 事件环并发写入 | 83 ns | 无锁竞争恶化 |
| 完整 stage 往返 | 132 µs | 含 3 次进程间往返 |
| 共享段编解码 | 3.7 µs | 占 stage 的 2.8% |
**锁仲裁 0.76µs 不可与实验 3 的 19.40µs 对照**——测的不是同一个东西：
实验 3 测插件经 RPC 请求锁的完整跨进程往返，本基准只测内核侧
lockRegistry.acquire/release。真实成本仍在 20µs 量级。
基准原名 BenchmarkStageLockRoundTrip 有误导性，已改为
BenchmarkStageLockArbitration，并在注释里写明不可对照的理由——
否则日后有人拿 0.76µs 去比 19.4µs 会得出「优化了 25 倍」的错误结论。
**stage 往返 132µs 的成本构成**：共享段编解码只占 3.7µs，其余是
一次 stage 要走 3 次进程间往返（stage.invoke + 插件侧反向的
stage.lock / stage.unlock）。相对 LLM 往返 2-8 秒可忽略；要优化的方向是
把 lock/unlock 合入 stage.invoke 的请求/应答，省掉两次往返。
## 流式压测：§4.3 标记「风险高」的那一项通过
原文担忧：「Bus.Publish 路径禁用任何锁/阻塞——流式输出逐 token 发布，
任何等待都会卡顿」。事件环是 Part 5 新加在这条路径上的，必须验。
```
5000 次 Publish + 每条睡 20µs 的慢消费者
实测 2.29ms，均摊 457 ns/token
同步语义理论下限 100ms
订阅者 1 个：1.547ms（515 ns/次）
订阅者 8 个：1.518ms（506 ns/次） ← 无线性恶化
环溢出（无消费者写 30000 次，cap=8192）：均摊 35 ns/次 ← 仍 O(1)
```
2.29ms 与实验 4 的数字完全一致（那次也是 2.29ms / 0.46µs per token），
post-and-forget 在实现中成立。
第三项的意义：消费者完全停摆时写端覆盖最旧 slot，这条路径仍是 O(1)，
故「消费者卡住」不会连带拖慢内核主循环。
Ref: docs/zh/plugin-migration-plan.md Part 6.6、docs/zh/架构迁移评估.md §4.3
2026-09-02 21:42:18 +08:00
4afb4a81d6
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
8b9f74c195
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
50fe98b4d3
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
5d2f21fe1e
proc: Windows 共享内存 + 事件通知适配（Part 6.2 内核侧）
...
补齐内核侧的 Windows 创建端，与 6.1 的插件侧打开端配对。三平台
（linux/darwin/windows）现在都能构建 internal/plugin/proc。
## Windows 走命名内核对象（无 fd 继承语义）
os/exec 的 ExtraFiles 在 Windows 实现里不被支持，故：
- shmalloc_windows.go：CreateFileMappingW（INVALID_HANDLE_VALUE + 命名 →
系统页文件支撑的匿名段，不落盘）+ MapViewOfFile
- evtfd_windows.go：CreateEventW 命名 Event 对象 + SetEvent 通知
- shmpass_windows.go：把段名/对象名经环境变量注入子进程
（HOMEAGENT_SHM_STAGE / HOMEAGENT_SHM_EVTRING / HOMEAGENT_EVT_EVENT）
名字带 PID + 递增序号：多个 homed 实例并存时不能撞名。
Event 与 eventfd 的语义差异：Event 是二元信号，多次 SetEvent 只对应一次
唤醒，不累积。不影响正确性——消费者被唤醒后按 readSeq 追 writeSeq 批量
drain，丢的是"唤醒次数"不是"事件"；事件环本身就允许溢出丢弃并让消费者
知道丢了（dropped 计数），通知面从来不是可靠投递语义。
## 传递机制抽象为 shmpass_*.go
Plugin.Start 不再直接构造 ExtraFiles 列表，改为问 Host 要：
Env: p.host.procEnvForShm() // Windows 返回段名，Unix 返回 nil
ExtraFiles: p.host.procExtraFilesForShm() // Unix 返回 fd 列表，Windows 返回 nil
平台差异被收敛到这一对函数，Plugin/coreHandler/stage 全部平台无关。
## macOS pipe 生命周期修正
原实现只返回读端 fd，写端 *os.File 无人持有 → 可能被 GC 回收 →
读端收到 EOF 而非阻塞 → 消费循环变忙转。改为 pipePair 表同时持有两端，
evtfdClose 一并关闭。
## E2E 测试跟进模板拆分
模板从单文件拆成三个（主体 + unix/windows 挂载），测试需要一并落盘，
否则编译报 attachStageShm undefined。procRuntimeTemplates 表必须与
SDK 仓 proc_runtime.go 的 procRuntimeFiles 一致。
验证：三平台 go build ./internal/plugin/... 通过（gojieba 的 cgo 依赖
导致 internal/memory 在非 linux 失败，与本次无关）；
go test -race ./internal/plugin/... 全绿，含 2 项真实模板 E2E。
Ref: docs/zh/架构迁移评估.md §9.2、docs/zh/plugin-migration-plan.md Part 6
2026-09-02 19:07:14 +08:00
2a64d6d715
docs: Part 5 标记核心已完成，进度快照更新事件环
...
Part 5 通知面内核侧 + 模板侧均已完成，端到端测试通过。
事件订阅从 C ABI 的空实现（case 23/24）变成真正可用。
测试数量更新：proc 38 项 + plugin 16 项（含 -race）。
下一步转 Part 6 逐插件迁移。
2026-09-02 17:07:43 +08:00
91b22978fa
plugin: 事件环内核侧实现（§3.6 Part 5 核心）
...
事件环（EvtRing）是子进程首次获得事件订阅能力的基础设施。
此前 case 23/24 明确返回未实现，现在经事件环真正可用。
核心设计（§3.6，实验 4 已验证 post-and-forget 加速比 2218x）：
- 事件环放**独立共享段**（不与 StageContext 混放）：stage compact 会清 arena，
事件要独立于 stage 生命周期。Host 持有两块 memfd：fd 3 = StageContext，
fd 4 = 事件环段，fd 5 = eventfd。
- 无锁数据结构：内核 WritePush 追加写 slot，子进程 EvtConsumer 消费。
writeSeq 原子递增（Bus.Publish 并发调用），readSeq 每订阅者独立。
- eventfd 通知：Linux 用 unix.Eventfd（计数合并，1000 token 只唤醒几次），
macOS 用 os.Pipe（阻塞模式走 netpoller，只 park goroutine，实验 1 验证
200 等待者仅 +1 OS 线程）。两者行为一致：Read 阻塞直到有新事件。
- 溢出语义：落后超 cap 时跳到最新，丢弃计数记入 dropped（消费者知道丢了）。
不静默覆盖最旧（写端直接覆盖 slot，读端靠 seq 判断跳过）。
- 事件类型编码：pubsdk.EventType 字符串 ↔ uint32 位索引（编译时映射表），
typeMask 位掩码过滤（1<<idx）。
Host 改动：
- NewHost 同时创建事件环段和 eventfd（惰创建，一次分配）。
- Host 持有 evtSubscriber 接口（EvtRingSubscriber），由 Registry 注入
EventRing 实现——proc 包不依赖 internal/plugin（避免循环依赖）。
corehandler 改动：
- events.subscribe（原 case 23）：子进程传事件类型列表，coreHandler
通过 evtRing 接口调用 EvtRingSubscribe，注册到 Bus 上。
事件经 EventRing 写入环后由子进程 mmap 读取。
- events.unsubscribe（原 case 24）：当前由内核统一清理（子进程 Stop 时）。
Registry 改动：
- ensureProcHost 在创建 Host 后同时创建 EventRing（Bus → EvtRing → eventfd），
并通过 Host.SetEvtSubscriber 注入给 coreHandler。
测试 3 项：
- BasicWriteAndConsume：Host 创建 → EventRing 写入 → 消费者读到
- OverflowStillDelivers：写入超过 cap 后消费者仍能读到最新事件
- TypeMaskFiltering：typeMask 只订阅 tool_call，agent_output 被过滤
验证：go build ./... 通过；go test -race ./internal/plugin/... 全绿；
既有事件环测试 3/3 通过；proc 包测试未受影响。
Ref: docs/zh/架构迁移评估.md §3.6、docs/zh/plugin-migration-plan.md Part 5
2026-09-02 16:48:27 +08:00
77e6c70712
docs: 更新迁移计划进度（Part 2/3/4 完成标记）
...
Part 2（子进程通道）、Part 3（plugindev .bin 构建）、Part 4（RunStage 接线）
标记为已完成，下一步转 Part 5 通知面。
记录两处与原计划的偏差及原因：
- Part 3 模板落地方式从 templates.go 的 raw string 换成真实 .go 源文件 +
//go:embed —— 900+ 行代码塞在字符串里写错只能等生成插件时才炸。
- Part 2 最初每插件一块共享段，等于副本模型换壳，已改为全部插件共享同一 memfd。
另记 lifecycle.autoRestart 缺口：公开 SDK 的 SetAutoRestart 是纯 setter
无 hook，隔着进程边界内核读不到，需模板在 Start 返回后显式上报。
2026-09-02 13:12:08 +08:00
88913f7297
plugin: 子进程通道接通 registry（proc 通道端到端可运行）
...
Part 3 收尾。tryLoadProc 从桩位变成真实加载路径，plugin.bin 插件现在
经 registry 完整跑起来：spawn → 握手（共享段 fd 3）→ init/start →
反向注册 → 工具调用 → stage 共享内存读改写。
registry 侧：
- Registry 持有 procHost（惰性创建，**全部 .bin 插件共用一块段**）。
每插件一段会让「内核 ctx → 段 → 插件改 → 回读 ctx」在多插件下退化成
副本模型，lost update 原样复现（§8.4 实测 35.8~36.8%）。
- tryDynamic 分派到 Registry.loadProc；tryLoadProc 退为纯静态校验
（构造需要 Host，只有 Registry 有）。
- StopAll 在锁外释放共享段：插件还持有映射时拆段，它们下一次访问就是
SIGBUS；且持锁调用会与 onProcCrash 回调产生锁序风险。
- onProcCrash 把子进程退出转成 EventSystem 事件，不在回调里直接重载
（重载需 registry 锁，而回调可能来自持锁路径的 goroutine）。
proc_core.go —— 权限梯度的类型系统落点（§3.8）：
- procCore 用**命名字段**持有 *isdk.PluginSDK，不是嵌入。嵌入会提升全部
方法，外部插件就能经类型断言拿到 Supervisor/Tracker/Adapter/Indexer/
Status/Selftest。命名字段下只有显式写出的方法存在——权限梯度从
「C ABI 表达能力的意外产物」变成显式声明并强制的策略。
- 能力访问器把内部超集接口收窄到公开面（isdk.KnowledgeAPI 内嵌
pubsdk.KnowledgeAPI 再加 Stats/Remove，isdk.MemoryAPI 加 GraphData，
isdk.LLMAPI 加 Chat/ReloadFromConfig）；nil 保护避免类型化 nil 让
corehandler 的判空失效。
- procPluginAdapter 转接 Start(*isdk.PluginSDK) → Start(proc.CoreSDK)，
Close 对 closeDynamic 可见故重载能真 kill 子进程（对比 dlclose 对
Go c-shared 是 no-op，§1.1）。
共享段分配按平台拆分（原先 host.go 直接调 unix.MemfdCreate，darwin/windows
交叉编译失败）：Linux memfd；macOS 立即 unlink 的临时文件（无 memfd_create，
但语义一致：无残留、fd 可经 ExtraFiles 传递、子进程 mmap 同一 inode）；
其余平台明确报错而非静默降级成「无共享段」——那会让 stage 静默失去数据面。
测试 +13 项：
- e2e_template_test.go 用**真实 plugindev 模板**（而非 testdata 手写假插件）
编译插件跑全链路，验证「模板 ↔ 内核」协议/布局真的对齐，不只是内核自己
跟自己对齐。含 lifecycle.autoRestart 上报、工具调用、stage 读改写、
FinalText 回传（C ABI 下 after_toolcall 看不到此字段，§8.3 10→16）、
只读插件不覆盖改写插件。
- proc_load_test.go 验证 Host 唯一性/惰性、chmod +x 错误提示、
Close 可见性，以及 procCore 不暴露内核内部机制的断言。
验证：go build ./... 通过；go test -race ./internal/plugin/... 全绿；
全仓 go test 无新增失败；git diff third_party/homeagent-sdk/sdk/ 为空。
既有告警 cabi/loader.go:156 unsafe.Pointer 非本次引入。
Ref: docs/zh/架构迁移评估.md §3.3/§3.4/§3.8、docs/zh/plugin-migration-plan.md Part 3
2026-09-02 13:03:57 +08:00
27f10ab6ef
feat(proc): Plugin 加载器 + 51 method handler + RunStage 接共享段（Part 2 完成 / Part 4 闭环）
...
corehandler.go —— cabi/loader.go 51 个 case 体的整块平移（§3.2）:
- 参数从「s1/s2/s3 + i1/i2 五个固定槽」改为结构化 JSON，语义不变
- CoreSDK 接口刻意只含外部插件应得能力：无 Selftest/Supervisor/Tracker/
Status/Adapter/Config/Tool/Indexer/OutputChan/Publish
→ 权限梯度从「C ABI 表达能力的意外产物」变成「显式声明并强制的策略」（§3.8）
- 事件订阅(case 23/24)与 SetToolBlocks 明确返回未实现，不再像 C ABI 那样静默成功
（静默成功后收不到事件比报错更难排查）
- ToolDef.Cleaner / ChannelDef.Cleaner 是函数，跨进程置 nil（§3.5 回调型资源）
host.go —— 共享段所有权中心:
- ❗ 全部子进程插件共享**同一块 memfd**。若每插件一段，
「内核 ctx → 段 → 插件改 → 回读 ctx」在多插件下退化成副本模型，
最后回读者覆盖前者，§8.4 的 35.8~36.8% lost update 原样复现
- stageMu 串行化整次 stage 对段的独占（内核可能并发触发 RunStage）
- 首个进入者写入段，最后离开者回读 + Compact（此时无插件持锁，满足 §3.3 前提）
stage.go —— RunStage 接线（风险 3.4 落点）:
- 并发扇出保留（§0.2 第 1 条：并发扇出是原始设计，不是缺陷）
- 插件失败时 ForceReleaseLock，避免后续插件死锁（实验 9，无需 robust mutex）
plugin.go —— registry 可加载的插件实体:
- Start: spawn（fd 3 传共享段）→ 握手 → plugin.init → plugin.start
- Close: **真 kill + wait**，对比 cabi 的 Close 只做 dlclose 而后者是 no-op（§1.1）
- invokeOutput **同步等真实结果**，失败上报 error —— §9.4 根治
验证（34 项测试全绿，含 -race，全部用真实子进程）:
- 单插件 stage 读改写经共享段回到内核 StageContext
- sanitizer(改写) + weather(只读) 并发：清洗结果不被覆盖（现网场景）
- **5 个独立进程并发 append 同一 FinalText：5 个标记全部保留，零丢失零撕裂**
（实验 8 在真实 RPC + 真实 RunStage 下的复刻）
- 工具注册可调用 / 输出通道真实失败上报 / start 期间反向调用
- 未知 method 与未实现能力被拒绝 / stage 外加锁被拒绝
接口冻结: git diff third_party/homeagent-sdk/sdk/ 为空
2026-09-02 11:34:33 +08:00
093811daf0
feat(proc): 子进程通道 —— RPC 协议 + 进程管理（Part 2 核心）
...
协议面（protocol.go，§3.2 method id 平移为 method 名）:
- NDJSON 帧，双向复用同一对 stdio；ID>0 需应答，ID==0 为通知(post-and-forget)
- 51 个 C ABI method id 全部平移为可读 method 名并标注原编号对照
编号本身扔掉——加能力不用改两边常量表，不再有 47 夹在 7 和 8 之间的痕迹
- case 25(CORE_FREE_STRING) 无对应 method：进程模型下各自 GC，概念消失
- case 23/24(事件订阅) 与 io.setToolBlocks 今日均为空实现「给不了」，
子进程下首次真正可给（§3.8 能力对齐）
- 新增 stage.lock/stage.unlock（C ABI 下不存在跨进程锁概念）
- StageInvokeParams 不含 StageContext 数据本身——数据在共享段，只带 stage 名 + seq
进程面（process.go，§2.3 保留现有生命周期机制）:
- Spawn: 启动 + 握手（协议版本不匹配显式拒绝，不半兼容运行）
- readLoop: NDJSON 分派应答/插件反向请求，1MB 单帧上限（大 payload 走 arena）
- CallContext: ctx 取消时立即返回**且清理 pending 条目**
对比 cgo：超时只让调用方返回，goroutine 永久卡在 C 调用里（现网泄漏 26 次）
- Notify: ID=0 不占 pending 表，满足约束 B（流式逐 token 发布不得等待消费者）
- markExited: EOF/退出 → 唤醒全部在途调用 → onExit 回调
这是「把 panic 捕获换成进程退出检测」的落点，plugin_health 逻辑完全复用
- Stop: plugin.stop → 宽限期 → 超时 Kill；Kill 后 OS 回收全部资源，零泄漏
- serveRequest 带 panic 隔离：内核 handler panic 不带崩 readLoop
验证（10 项，真实子进程而非 mock，含 -race）:
- 握手/工具调用/错误上报（插件失败调用方收到 error，非假成功）
- 插件反向调用内核（tool.register + settings.get 双向往返）
- **崩溃隔离**：插件 panic → 子进程 exit 2，内核存活、收到 onExit、在途调用不挂死
- 优雅停止 / **Kill 卡死插件**（ctx 超时返回 + pending 清零 + 资源回收）
- 通知不等应答（100 条 < 1s）/ 50 并发调用应答不串 / 协议版本不匹配拒绝
接口冻结: git diff third_party/homeagent-sdk/sdk/ 为空
2026-09-02 10:59:59 +08:00
f3461d072f
docs(plan): Part 1 完成 + Part 4 核心完成标记，0.3/0.4 标记跳过
...
- Part 0.3/0.4 标记 ⏭️ 跳过并记录理由（子进程模型下问题整体消失，不给待删代码打补丁）
- Part 1 加载分派骨架 ✅ 完成（修改/审查/验证三步逐条勾选）
- Part 4 共享内存数据面 ✅ 核心完成（段/编解码/锁仲裁，RunStage 接线待 Part 2）
- 目录加进度快照
2026-09-02 10:43:40 +08:00
43b199a1e4
feat(plugin): entry 双通道分派 + 共享内存 stage 数据面（Part 1 + Part 4 核心）
...
Part 1 加载分派骨架（迁移可逐插件推进、随时回退的前提）:
- dynamic.go: 新增 binEntry/skillEntry 常量 + entryKind 枚举 + classifyEntry/detectEntryKind
manifest entry 优先级最高（改回 plugin.so 即回退 cabi）；无 manifest 时按目录探测，.bin 优先
- registry.go: tryDynamic 按 entry 分派 proc/cabi 双通道；
entry 声明 .bin 但二进制缺失时报明确错误，不静默回退（否则'已迁移插件跑回旧通道'极难排查）
- registry.go: pluginEntryHash 候选顺序与 detectEntryKind 对齐（.bin 优先），
否则增量重载会用错文件算 hash
- dynamic_proc_{unix,windows}.go: tryLoadProc 桩位（权限/类型校验已实现，进程管理属 Part 2）
Part 4 共享内存数据面（迁移评估 §3.3/§3.4/§3.7，最关键一环）:
- proc/shm.go: 段布局（Header + ShmStageCtx 描述符数组 + append-only arena）
相对偏移设计——各进程 mmap 到不同虚拟地址仍能正确解引用
arena 用尽显式报错而非静默截断（§4.4 风险登记）；Compact() 回收 append-only 垃圾
- proc/shmcodec.go: StageContext 16 字段跨进程编解码
字段级描述符消除 lost update：只改 FinalText 的插件不触碰 ToolResults 描述符
WriteDirty 只写脏字段——只读插件零写入，不可能覆盖他人改写
Snapshot 存序列化字符串（切片共享底层数组的坑，C ABI 侧修 11.3 时已踩过）
Extra 4 键提升为具名字段；Response 用标志位表达 nil vs 空串
- proc/lock.go: 锁仲裁回归内核（§3.7 已裁定，零 cgo）
ForceRelease 实现实验 9 的崩溃自愈——排除 robust pthread_mutex 必要性
重复加锁显式拒绝（否则死锁 30s）；等待超时有补偿 goroutine 防锁泄漏
验证:
- proc 包 16 项测试全绿（含 -race）：全字段往返/只读零写回/原地改切片识别/
现网 sanitizer+weather 场景/5插件×40轮并发零丢失/arena 耗尽报错/压实不破坏字段/
锁互斥·串扰拒绝·崩溃自愈·临界区串行化
- entry 分派 9 项测试全绿；go build ./... exit 0；接口冻结 git diff sdk/ 为空
2026-09-02 10:41:18 +08:00
74b9db7bf9
docs: 固化当前分支对齐记录（update→feature/plugin-proc-migration）
2026-08-31 12:37:43 +08:00
881d938f1b
docs: Git 分支管理规范（main 长命 + feature/release/hotfix cherry-pick 流程)
...
- main 唯一长命、永远可部署；现网永远部署 release tag 构建
- feature/xxx 从 main 开出合回；release/vX.Y.Z 切出打 tag 构建
- hotfix 提交 release 分支 + 版本号分离提交，只 cherry-pick 修复回 main
- 明确'不需合并 release 回 main'（hotfix 已逐个 pick 回，避免冲突）
- 两仓（TrueAgent + homeagent-sdk）同用本规范
2026-08-31 12:36:44 +08:00
476ebdcdf0
docs(plan): Part 0.1/0.2 勾选 + 迁移计划进度标记
...
- plan.md 11.1 (3 checkbox)、11.3 (3 checkbox) 全部勾选
- plugin-migration-plan.md: 0.1/0.2 标记 ✅ 完成（含踩坑记录与待部署项）
2026-08-31 12:33:24 +08:00
81705a782e
fix(cabi): applyStageResult 支持 diff 回传（plan 11.3 配套）
...
外部插件 bridge 模板改为只回传变更字段后（SDK 仓 5648519），内核侧配套：
- applyStageResult 的 tool_calls/tool_results 去掉 len(v)>0 拦截——改为键存在即应用，
使插件「清空全部工具调用」的显式回传 [] 能被表达（旧插件仅 len>0 才带键，不误清空）
- 逐字段应用，未回传的键保持原值（diff 语义：只改变更字段，不覆盖他人改写）
- output_test.go 新增 TestApplyStageResult_ClearedSlicesAreApplied / _OnlyPresentKeysApplied
验证: go build exit 0; go test ./internal/plugin/... ./internal/agent/... 全绿
2026-08-31 12:30:04 +08:00
7e01b1062e
fix(cabi): output_send 等待真实发送结果，消除假成功（plan 11.1 / Part 0.1）
...
根因：CORE_REGISTER_OUTPUT_CH handler 无条件返回 {status:queued}+err=nil，
模型永远收到「已发送」，实际失败（如 meta 缺 user_id）只写日志，模型无法感知不会重试。
现网近 7 天成功 44 次、失败 2 次全部谎报成功。
改动：
- loader.go: 新增 awaitOutputResult（+可注入版 awaitOutputResultWith）+ outputSendTimeout=10s
goroutine 执行 cgo 发送 + 带超时 channel 等结果 → sent / error / unconfirmed 三态
handler 由 executeOutputSendTool 从 Go 侧调起，非 cgo 栈，不构成 cgo 嵌套
- output.go: executeOutputSendTool 识别 unconfirmed|queued，回报「发送结果未确认」而非「已发送」
- output_test.go: Success/Failure/Timeout 三用例
验证: go build exit 0; go test ./internal/plugin/... ./internal/agent/... 全绿
接口冻结: git diff third_party/homeagent-sdk/sdk/ 为空
2026-08-31 12:16:39 +08:00
7a298cb0a4
docs(plugin-arch): 外部插件多进程化适配计划（修改→审查→验证三步微循环）
...
7 个 Part,每 Part 一个微循环:
- Part 0 脆弱基线先行(11.1/11.3/11.6,现网止血,不依赖迁移)
- Part 1 加载分派骨架(entry 双通道共存,可回退前提)
- Part 2 子进程通道原型(spawn/JSON-RPC/procPlugin,参考 sidecar.go)
- Part 3 plugindev 工具链改造(.bin 产物,SDK 仓)
- Part 4 共享内存数据面(StageContext 并发改写,最高风险)
- Part 5 通知面(EvtRing + eventfd,post-and-forget)
- Part 6 迁移收尾(17 插件 + 删 cabi + 权限显式化)
每 Part 含修改对象/审查要点/验证标准 + 13 项最终验收 + 风险回退表
2026-08-31 12:01:11 +08:00
c3d303ea85
docs(plugin-arch): 外部插件接口不变矩阵（多进程化整改基线 v1）
...
钉死「暴露给外部插件的接口不变」约束的合同面：
- 合同面A: 公开SDK类型/接口（sdk/plugin.go等，纯Go无cgo）
- 合同面B: bridge 51个method id ↔ SDK方法映射表（RPC平移清单）
- 合同面C: StageContext 跨ABI 10字段 → 共享内存16字段（能力扩展）
- 外部插件实测触达面 ⊆ 公开SDK合同面（接口不变成立的依据）
- 迁移后新获得能力/刻意不给项/检查点
2026-08-31 11:52:31 +08:00
40a3efa955
docs(plugin-arch): 归档插件架构迁移评估 + plan 第11节整改计划
...
- docs/zh/架构迁移评估.md: C ABI→子进程+共享内存完整迁移论证(1621行)
- docs/zh/experiments/: 18项可复跑可行性实验(架构评估的所有数字来源)
- plan.md §11: 11.1~11.9 插件架构缺陷修复清单(唯一权威编号)
- main 保持干净,本批次为 update 特性分支的整改起点
2026-08-31 11:45:52 +08:00
c4219767d4
feat(ohos): MotionBase 统一按压动效 + 分层图标随主题切换
...
## 动效统一
各组件重复实现按压反馈（@State pressed + scale + animation + onTouch 四件套），
时长各写魔数导致全局手感不一致。
- 新增 components/MotionBase.ets：通用动效的"父组件"。ArkUI V1 的 @Component
struct 无法继承他人 build，改用组合表达继承——调用组件把内容经 @BuilderParam
内容插槽传入，MotionBase 在包装节点统一挂动效修饰器。
pressEnabled 默认关（纯展示容器零开销）；fillWidth=false 供气泡内卡片按内容
自适应宽度；flexWeight 供等分排列按钮参与剩余空间分配。
onPress 只作按压瞬时轻量钩子，导航/提交语义仍由调用组件 onClick 负责，
避免"按下即触发"的手感偏差。
- Constants.ets 新增动效 token：ANIM_FAST(150) / ANIM_NORMAL(220) /
ANIM_ENTER(280) / ANIM_SLOW(400) / PRESS_SCALE(0.97)。
取值依据：状态切换 150-250ms（>300ms 显拖沓），大位移进出场 300-400ms
才不突兀；曲线统一 EaseOut 起步快收尾缓。
- NavRow / StatusSummaryCard / AttachmentCard / 插件卡片等公共组件接入
MotionBase，移除各自的按压四件套。组件专属动效（聊天输入框上弹、加号菜单
浮起、折叠面板展开、toast 进出场）保留在各组件内，不塞进父组件。
## 图标与启动页随主题切换
原先直接指向位图 app_icon.png，浅色底被烧进图标，深色模式下桌面与启动页跳脱。
- 改用分层图标 layered_image：foreground 为字形，background（沉淀色）在
base/ 与 dark/ 各一份，随系统主题切换。app.json5 与 module.json5 的
icon 均指向 :layered_image。
- startWindowIcon 改用透明底 start_icon.png，配合 start_window_background
的 base(#F1F3F5) / dark(#000000 ) 两份取值，浅深模式遮罩与图标都能对上。
## 验证
清空 entry/build 后全量重编：hvigorw assembleHap BUILD SUCCESSFUL（9.8s），
零 ArkTS 错误。提交内容已确认不含 build/ oh_modules/ .hap 与签名材料。
2026-08-30 17:23:40 +08:00
6c6634ef08
chore: 同步 vendored SDK（qq v1.2.0 + plugindev bridge 修复）
...
third_party/homeagent-sdk 同步至 SDK 仓 61f307b：
- fix(plugindev): bridge 模板补 dispatchIO.SetToolBlocks
SDK v0.9.2 给 IOInjector 加了该方法但 C ABI bridge 模板未同步，
导致任何外部插件编译失败（missing method SetToolBlocks）
- feat(qq) v1.2.0: msg_id→get_history 7 天兜底（不缓存正文）
+ qq_list_chats / qq_mark_read 会话列表（按最新消息排序 + 未读数）
+ 中断模板补 fallback 路径与私聊 user_id
.gitignore 补 HarmonyOS 构建工具链缓存（.hvigor-home/ .npm-cache/ .ohpm/），
这些由 HVIGOR_USER_HOME/ohpm 生成，非源码。
go build ./cmd/homed/ 通过。
2026-08-30 17:14:07 +08:00
8f2b632838
fix(agent): 修正系统提示词的回复投递规则，补充事实性约束
...
问题一：提示词说反话，导致 qq 回复大量丢失。
v2 架构曾有「回复自动回投来源通道」的能力（IOManager.routes + RegisterOutputRoute），
但 304c3ae
2026-08-29 14:43:23 +08:00
3907fef0a3
fix(ohos): 移除硬编码后端凭据，地址规范化默认 https
...
- Model.ets: defaultConnection 不再内置 url/apiKey，改为空白模板
- 新增 normalizeBaseUrl：补协议（默认 https）、去尾斜杠、去误粘的 /api/v1
裸域名走 http 会被反代 302 到门户站，客户端只拿到 404，表现为"连接直接失败"
- ConnStore: 增删改与读取存量数据时统一规范化 url
- 去掉 ensureDefaultConnection，首启不再预置连接，未配置时走统一提示
2026-08-29 13:49:30 +08:00
1d428f7990
feat(ohos): 鸿蒙端聊天历史分段懒加载 + 首次提交完整工程
...
原有 cmd/ohos/HomeAgent 是未入库的鸿蒙原生 ArkTS 工程，本次随改动一并入库，
保证他人 clone 后可直接编译（含 .gitignore 排除 build/oh_modules/签名材料，
提供 build-profile.json5.example 模板）。
本次功能改动（与 WebUI / GUI 三端对齐）：
- /chat/history 首屏只拉最新 CHAT_PAGE_SIZE(40) 条，1.26MB → 48.5KB
- 抽出 parseHistoryPayload() 复用解析，记录 chatOffset/chatHasMore
- 新增 loadOlderChat()：向上滚动触顶（yOffset<60）懒加载更早页
- 工具调用 args/result 与 reasoning_content 完整还原，不做裁剪
构建验证：hvigorw assembleHap BUILD SUCCESSFUL（7.8s，ChatPage 零告警）
2026-08-29 10:25:12 +08:00
de7d686651
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
bcbd8d28a4
perf(webui): /chat/history 分段懒加载 + lean 瘦身模式
...
问题：/api/v1/chat/history 无分页返回全量 1.26MB（200条），移动端/弱网首屏很慢。
实测体积构成：tool_calls args/result 占 71.8%，reasoning_content 11.6%，content 仅 3.4%。
后端 handler.go：
- 新增查询参数 limit（1..maxChatHistory）/ before（游标）/ lean（瘦身）
- 全部可选，省略时返回全量 → 向后兼容旧客户端
- 响应加 total/offset/has_more，供前端判断能否继续向上加载
- lean=1 裁剪 tool_calls 的 args/result 并置 truncated 标记、省略 reasoning_content
- ChatToolCall 新增 Truncated 字段（前端可显示'详情需展开加载'而非误判执行失败）
前端 WebUI + GUI（两端同步）：
- 首屏只拉最新 40 条（CHAT_PAGE_SIZE），1.26MB → 48.5KB（lean 26KB）
- 新增 loadOlderChat()：滚动触顶（<60px）自动拉上一页，插入后按 scrollHeight 差值补偿
滚动位置避免视口跳动
- state 新增 chatOffset/chatTotal/chatHasMore
- syncChatFromHistory 改用重叠区对齐（分段后不能再用长度比较判断新增），
找不到重叠点安全退化为全量刷新最新页
实测：无参数 1287.9KB / limit=40 48.5KB / limit=40&lean=1 26.0KB；
before 游标翻页、limit 越界/非法值、before=0 等边界均正确
2026-08-28 23:21:13 +08:00
680683b5c5
fix(plugin): DisablePlugin 禁止禁用未安装插件，防止脏写 disabled_plugins
...
问题：POST /api/v1/plugins/<name>/disable 对不存在的插件也会把它写进
disabled_plugins 表（registry.go DisablePlugin 无条件 AddDisabledPlugin），
产生脏数据堆积，且同名插件日后真实安装会被误判为已禁用。
修复：
- registry.go 新增 pluginInstalled(name)：已加载 / 已注册工厂(内置) / 插件目录存在，
任一命中视为已安装
- DisablePlugin 开头校验：未安装返回 'plugin X not installed'，不写 disabled_plugins
- webui handler：未安装→404，已禁用→409（原都返回500）；enable 失败含'failed'→404
- 新增 registry_disable_test.go：覆盖未安装拒绝/内置判定/目录存在判定/普通文件不算
本机端到端验证：disable 不存在插件返回404且表无脏数据；真实插件 disable/enable 正常
2026-08-27 23:29:49 +08:00
ee7788e834
feat(webui): 请求IP日志记录中间件
...
- clientIP(): 提取真实客户端IP，优先 X-Forwarded-For(取第一跳) / X-Real-IP，回退 RemoteAddr
- logged(): 最外层中间件，覆盖全部路由，记录方法/路径/IP/认证方式/状态码/耗时
- 认证方式判定: api-key(X-API-Key/Bearer) / session(cookie) / none
- SSE长连接(/chat/events)启动即记，不阻塞等待完成
- statusWriter 捕获响应状态码，支持 Flush/Hijack 透传
- 用于排查'谁调用了什么接口'（如插件禁用等变更操作）
2026-08-27 23:04:48 +08:00
a9639800f1
fix(gui): SSE消息同步不及时，同步webui修复
...
- 新增 syncChatFromHistory()：增量同步，仅追加新消息不重建已有DOM→无闪烁
- handleSSEEvent 监听 sync_required 事件 → 增量补拉历史
- SSE 断连(pump退出)后先 syncChatFromHistory 补偿再重连
- startUptimeTicker 增加30s轮询兜底（补偿跨渠道消息丢失，CLI连接跳过）
2026-08-27 11:29:20 +08:00
6dedff419c
fix(webui): SSE消息同步不及时 + 后端缓冲加固
...
handler.go:
- writeCh 512→2048，新增 sendSSE() 函数（100ms短超时重试替代立即丢弃）
- After(id) 为空时发送 sync_required 事件通知前端补拉历史
- 批量 flush 阈值 64→128
dashboard.html:
- 新增 syncChatFromHistory()：增量同步，仅追加新消息DOM节点，不重建已有消息→无闪烁
- 监听 sync_required 事件触发增量补拉
- SSE onerror 立即 close 阻止双连接竞态，2s后手动重连（原5s）
- init 顺序：先 loadChatHistory 再 connectSSE（避免事件与历史加载竞态）
- 30s轮询兜底（补偿SSE断连窗口期丢失的跨渠道消息）
2026-08-27 11:10:53 +08:00
f82d007a6c
chore: sdk v0.9.2 vendored副本同步 + go.mod 依赖更新
...
- third_party/homeagent-sdk/meta/meta.go: 0.9.1 → 0.9.2
- go.mod: require v0.9.2（replace 保留，指向本地 vendored 目录确保可编译性）
- CoreVersion 同步更新
2026-08-27 09:36:49 +08:00
d066afe533
feat(waiter): daemon模式 + localuse本机外设插件
...
waiter 新增 --daemon 后台驻留模式 (daemon.go):
- 维持 homed 连接，TUI实例经 Unix socket 接入
- 单客户端串行模型：每个TUI独占homed响应，新客户端回放缓冲(256行)
- 设备桥场景可无 homed 运行（纯设备桥驻留）
- 设备桥看护循环：WS断开自动重连(3-5s间隔)
- conn.go 新增 daemonConn 类型，dial() 优先检测 daemon
localuse 插件 (internal/plugins/localuse/):
- local_screensee / local_camerasue / local_speakeruse
- local_screensue / local_clipboardsee / local_clipboardsue / local_computeruse
- 跨平台实现(Linux/macOS/Windows)，能力与 waiter device.go 对齐
- headless服务器上缺依赖工具自动返回安装提示
SDK sync: third_party SetToolBlocks 多模态类型同步
README 补充 daemon 模式使用文档
2026-08-27 09:27:15 +08:00
d75ba512b0
feat(multimodal): 内置多模态感知插件 + process.go 原生支持 tool message 多模态块
...
【新插件 internal/plugins/multimodal】
- see_picture(path): 读取本地图片/URL，base64 注入 image_url block，
模型在下一轮 LLM 请求的 tool message 里直接看到图（1024×1024 图约 8500 token）。
自动识别 MIME，限 3MB 防爆 context。
- see_video(path, frames): ffmpeg 提取关键帧，多帧作为 image_url block 注入。
默认 4 帧，最大 10 帧，每帧限 2MB。
- listen(path): 读取音频文件，转为 audio_url block 注入，支持 mp3/wav/ogg/m4a。
限 5MB。
【内核多模态 tool message 支持】
- agent/api 新增 ToolOutput 类型（为后续 handler 直接返回 blocks 预留）
- SDK 公共层新增 ContentBlock/ImageURL/AudioURL（OpenAI 多模态格式）
- IOManager 新增 SetToolBlocks/ConsumeToolBlocks（interface{} 避免循环依赖）
- PluginSDK.SetToolBlocks(blocks) 插件工具调用后注入 blocks
- ioAdapter 桥接 IOInjector.SetToolBlocks
- process.go 工具执行后消费 pending blocks → 追加到 tool message 的 Blocks 字段
→ MarshalJSON 输出 content 数组格式 → LLM 看到图/音频
【验证】
multimodal_see_picture 注入 1024×1024 PNG 后 llmsproxy 统计：
prompt_tokens=44407（含 ~8500 image token），模型正确描述了图片内容。
2026-08-27 08:39:21 +08:00
d4da999d35
feat(sdk): SettingsAPI.DataDir() 插件专属数据目录 + ai_image 本地交付
...
【SDK DataDir API】
- SettingsAPI 新增 DataDir() string：返回插件专属数据目录
<data>/plugin_data/<name>（内核保证存在），解决此前插件只能
靠 GetCore("daemon.data_dir") 手工解析的缺陷
- settingsImpl 新增 dataDir 字段 + SetDataDir；Registry buildSDK
注入（<data>/plugin_data/<name> 并 MkdirAll）；main.go 接线
- cabi 新增 CORE_SETTINGS_DATA_DIR (id 51)；plugindev dispatchSettings
模板补 DataDir() 实现
【ai_image 交付本地路径】
- 生成后下载临时 S3 URL 到插件数据目录，返回本地文件路径（永久不
过期），而非 1 小时过期的 S3 URL。带 UA 规避图床对无 UA 客户端拦截
（此前 agent 裸 curl 验证被拒导致误报失败）
- 返回 local_paths 字段 + 提示用 output_send(type=image) 展示
端到端：ai_image_generate → plugin_data/ai_image/*.png 有效 PNG(1024²)，
经 llmsproxy→siliconflow 生成。
2026-08-26 21:40:29 +08:00
31a348de37
feat(ai_image): base_url 设置项支持自定义 OpenAI 兼容网关 v1.1.0
...
generateOpenAI 原硬编码上游为 https://api.openai.com，无法接入
本机 llmsproxy(ModelRouter) 等标准 OpenAI 兼容网关。新增：
- 设置项 base_url（string，默认空）：为空保持官方直连；非空时
上游改为 {base_url}/v1/images/generations（约定不带 /v1 尾缀，
拼接时自动去重避免 /v1/v1）
- Plugin.baseURL 字段 Start 时读入；注册 ConfigDef（category
ai_image）供 WebUI 配置页展示
部署：plugindev 打包 1.1.0 → pluginmgr overwrite:true 升级安装
config_kept=true → plgreload 热加载。
配置（category ai_image）：api_key=sk-gw-local-0001,
base_url=http://127.0.0.1:8081 , provider=openai,
model=Kwai-Kolors/Kolors, size=1024x1024
验收：agent 实调 ai_image_generate 出图成功——llmsproxy audit
记录 type=image src=siliconflow model=AUTO ok=true（经网关非直连），
返回临时 S3 URL 下载为有效 PNG (1024x1024)。
2026-08-26 19:46:59 +08:00
0823c3a1e0
feat(a2a/acp): 会话历史查询 session.get + 客户端 session_id 透传
...
a2a:
- tasks.get 从空壳改为按 session_id 返回会话内近 N 条消息（默认10）；
新增 session.get 别名同语义
- a2a_query（出站）接受 session_id 参数透传给目标 agent，
响应回显 session_id + 延续提示
- A2AParams/A2AResult 加 session_id 字段；工具描述补说明
acp:
- 新增 JSON-RPC method session/get：按 session_id 返回近 N 条消息
- acp_query（出站）接受 session_id 透传给 session/new，
响应回显 + 延续提示
- params 结构体加 limit 字段
端到端验证（回环本机）：
a2a tasks.send→建会话；session.get→返回[user/agent]交替消息列表
同 session 第二轮延续上下文正确（记数字→答数字）
acp session/new + session/get 同样通过
2026-08-26 19:30:32 +08:00
f12521d033
fix(a2a/acp): 回复闭环 + 会话延续 + 同步注入（不再抢占打断）
...
【问题】
1. 入站请求用 InjectInterruptText 抢占打断当前对话，立即回 202 submitted，
agent 的回复 emit 到未注册的 channel（a2a/acp）→ 请求方永远拿不到回复文本，
只能干等超时。（acp 的 session.Replying 从未被填真回复 → SSE 永远 "(未收到回复)"）
2. 无法指定/延续 session：a2a 无 session 概念；acp session/new 每次新建、
不接受调用方 session_id，多轮上下文断裂。
3. a2a/acp 通道未注册为输出设备 → emitResponse 的回复无落点，
output_list_channels 也不可见 → agent 困惑"回复该发到哪"。
【修复】
- 入站改用 SDK InjectInputSync 同步注入：阻塞等待 agent 处理完成，
直接把最终回复文本返回给 HTTP 请求方（不再回 202）。
这是 A2A/ACP 协议的合理形态——客户端控制超时，服务端同步返回。
- session 支持：a2a tasks.send 与 acp session/new 均接受 params.session_id，
指定则延续已有会话（拼上下文前缀），不指定则新建并返回 session_id。
单会话保留最多 10 轮历史防膨胀；30min GC 清理 2h 未用会话。
- a2a/acp 注册为输出通道（RegisterOutputChannel）：回复有落点，
output_list_channels 可见，agent 可主动 output_send 推消息。
- 注入提示词明确"直接以文本回复即可，无需调 output_send"——
agent 不再把回复走 queued 入队而返回干净文本。
端到端验证：
单轮：status=completed, reply=真实回复文本（非 submitted）
多轮：同 session_id 第二轮准确复述第一轮问题（上下文生效）
a2a v1.2.0 / acp v1.1.0 安装 config_kept=true
2026-08-26 19:16:46 +08:00
25acf50d10
fix(webui): /files/ /uploads/ 静态路由接受 X-API-Key 鉴权
...
requireWeb 此前只认 cookie session，ArkTS/GUI 等 API key 客户端
加载 agent 输出的附件 URL（/files/xxx、/uploads/xxx）一律 302 到
/login。现 requireWeb 先校验 validAPIKey 放行非浏览器客户端；
无凭证仍 302 登录页，行为不变。
handleFiles/handleUploads 已有严格防穿越（拒 / \ ..），暴露给
key 客户端安全面可控。
端到端验证：X-API-Key 访问 files/uploads 均 200，无凭证 302。
2026-08-26 18:54:26 +08:00
8ffdcc2b32
fix(webui): SSE writer 批量合并 flush 修复流式 delta 丢包延迟
...
【根因】SSE writeCh 缓冲仅 64 且 writer 每条 delta 单独 flush。
reasoning/content 增量是高频小包（单轮 200+ 条），socket
写慢时 writeCh 迅速填满，delta 大量 DROPPED——浏览器收不到
逐 token 增量，只能等最终 agent_output 整段到达，体感明显延迟。
实测一轮 16s 纯文本回复：content_delta DROPPED 202 次、
reasoning_delta DROPPED 345 次，前端全程无流式渲染。
【修复】
- writeCh 缓冲 64 → 512
- writer 加 16ms 批量合并窗口：窗口内收集的增量一次性 flush，
或满 64 条立即 flush；done 退出前 flush 残留。
flush 次数从 N 降到约 N/64，socket 写压力骤降。
修复后实测 0 DROPPED，delta 全部实时送达前端。
2026-08-26 17:59:33 +08:00
e9119edd9a
fix(plugins): bili output_dir 系统目录黑名单 + recoverydiag db_path 沙箱限制
...
P3 bili: output_dir 配置项此前未校验，yt-dlp 可被配置写到任意系统目录。
加系统目录黑名单（/、/etc、/usr、/var 等），命中直接拒绝执行。
P4 recoverydiag: db_path 参数 LLM 可控，可探测读取任意 sqlite 文件。
现强制限制在 data 目录内（前缀校验），越界返回提示。
两插件重打包升版（bili 1.2.0 / recoverydiag 0.2.0）安装验证
config_kept=true，内核重启加载正常。
2026-08-26 16:57:34 +08:00
860e914428
fix(plugins): 全插件审查修复（qq/a2a/memo/calendar/rss/browser）
...
17 个生产插件全量审查：编译/vet 全过、无硬编码密钥、内核
executeToolCall 有 panic recover + 超时兜底。发现并修复：
P1 qq: downloadURL 裸 http.Get 无超时 → 120s client（挂起泄漏）
P2 a2a: inbound http.Server 无超时 → Read 30s/Write 120s/Idle 60s
（慢速连接占用 goroutine）
P5 memo/calendar/rss: 数据持久化直写 → atomicWriteJSON temp+rename
（崩溃截断 JSON 丢全部数据）
P6 qq: 3 处后台 goroutine（已读标记/rcon转发/下载任务）加 recover
（工具调用外 panic 会带崩 homed 进程）
P7 browser: dump-dom failback Kill 后补 wait 回收僵尸进程
已知可接受项：bili output_dir 用户可控（本机单用户）、recoverydiag
db_path 可读任意 sqlite（诊断工具固有权限，argv 传参无注入）。
全部经 plugindev 重打包 v+0.1 安装验证 config_kept=true。
2026-08-26 16:46:06 +08:00
cfd1653529
fix(agent): 流式并行 tool_call 按 JSON index 分桶，修复空参数调用
...
【根因】内核流式解析层丢弃了上游 SSE 分片的 OpenAI index 字段：
- openAIToolCall 结构体无 index 字段，JSON 解析即丢
- homed 的 openai.lua 转换为扁平结构时同样未透传 index
- accumulateStream 退而用 Go range slice 序号做累积桶 key，
但每个 SSE chunk 只含一个 tool_call 元素，序号恒为 0
于是并行多工具调用（index=0,1,2,3）的所有分片全部写入同一个桶：
name 相互覆盖、args 碎片混拼成非法 JSON → parseToolArgsJSON
失败返回空 map → 工具以空参数被调用（spawn_child 报'请提供 task'、
cmd_run 报'command is required'等），agent 只能串行重试自愈。
单工具场景只有一个 index 无污染，故简单请求一直正常；
pi 直连同一 llmsproxy 正常（其实现标准按 index 累积）。
【修复】
- ToolCall 增加 StreamIndex（json:stream_index），openAIToolCall
解析上游 index 并透传；openai.lua 输出 stream_index 字段
- accumulateStream 以 tc.StreamIndex 为累积 key
- flushToolCall 区分三种空参：未收到分片/碎片非合法 JSON/合法空
对象({})，分别打诊断日志，避免误报
- 回归测试 TestAccumulateStreamParallelToolCallsByIndex 模拟
4 路并行分片流验证按 index 正确分组与参数完整性
另含 spawn_child max_turns 参数、child_result 运行中状态区分、
provider 层非流式空参诊断日志。
2026-08-26 16:10:02 +08:00
02ca88489a
feat(agent): spawn_child 支持 max_turns + 并行策略引导
...
1. spawn_child 新增 max_turns 参数（1-30，默认 5）
子 Agent 工具轮数此前硬编码 5，复杂任务跑不完即截断。现可按任务
复杂度调整；返回消息带轮数上限提示。
2. 工具描述与 system prompt 增加并行策略引导
明确'多个互不依赖的子任务应并行 spawn 多个子 Agent，不要串行
逐个执行；长耗时任务交给子 Agent 避免阻塞对话'——针对生产实例
观察到的 agent 倾向自己串行处理所有子任务的问题。
小宅自定义 prompt 同步补充并行策略段。
2026-08-26 13:38:27 +08:00
8821ebc4e8
fix(browser): render 改走共享后端（带登录态），v2.2.1
...
browser_render 原实现每次独立 chromium --dump-dom 冷启动：不带共享
profile 登录态、每次 ~2s 启动开销。现改为主路径经 CDP 9222 开临时
标签页渲染（Title+OuterHTML）后即关——登录态与 interactive 会话一致；
后端不可用时保持 dump-dom failback（补 30s 超时防挂死）。
返回新增 mode 字段（backend-tab / local-dump-dom）便于 agent 判断。
修复过程中清理 python 重写残留的重复函数定义。
2026-08-26 12:38:53 +08:00
38ac2b4fe8
feat(browser): systemd 托管共享浏览器后端 + 全机 agent 标签页架构 v2.2.0
...
浏览器插件重新定位为本机所有 agent 的统一浏览器操作壳：
1. 主路径：homeagent-browser.service（systemd 托管）
- chromium --headless --remote-debugging-port=9222
--user-data-dir=<data>/browser_profiles/shared
- 独立于 homed 生命周期，崩溃自动重启，登录态持久保存
- 本机所有 agent（HomeAgent/pi/opencode/deepseekharness 等）
共享同一实例：登录一次全机可用
2. 每 agent 一个标签页（CDP Target 隔离），同 source 复用已有标签页
3. browser_start 探测链：CDP 9222 在线 → 直连；服务已装未跑 →
systemctl start 等待就绪；未安装 → 返回 need_install+guide 引导
4. 新工具 browser_install：探测 chromium 二进制 → 写 systemd 单元 →
daemon-reload + enable --now → 验证 CDP → 返回全机共享使用指南
（含其他 agent 经 connectOverCDP 接入的说明）；无 root 权限时
返回手动安装命令清单
5. failback：无法联网装 chromium 的机器，重试 start 自动降级本地
spawn 临时模式（登录态不持久，仅保证功能可用）
工具链打包 v2.2.0 已部署验证：need_install 引导 / install 装服 /
start 复用与开新标签页全链路通过。
2026-08-26 12:22:15 +08:00
bbe7c5fe15
fix(webui): 附件死锁 + qq 插件文件发送收敛到 output 通道
...
1. webui 附件死锁修复（output_send__webui 发图 60s 超时根因）
EventAgentOutput 订阅者已持 chatMu，附件分支调 addChatMsg（内部
再次 Lock）——sync.Mutex 不可重入导致 Publish 永久阻塞，工具超时、
图片永远发不出来。改为持锁状态下直接操作 chatHistory+persist。
2. qq 插件 image/file 分支收敛到 output 通道
output_send__qq 的 type=image/file 此前只透传 payload 给 CQ 码，
发本地文件必须绕道 upload_group_file 独立工具。现在与 voice 分支
同模式：本地路径拷入 NapCat 共享目录转 file:///app/files/<name> URI，
http(s)/file:// URL 保持透传。upload_group_file 保留作为群文件柜
专用入口。
验证：工具链重编译 → qq.hmap 重打包 → pluginmgr overwrite 安装
（config_kept=true）→ agent 经 output_send__qq 用本地路径发图成功，
mascot.webp 已落共享目录。
2026-08-26 11:14:03 +08:00
cb8b8eba48
fix(cmd/files/webui): shell 语义修复 + 根沙箱误判 + 上传注入走 interrupt + UI 区分附件来源
...
1. cmd_run 改经 /bin/bash -c 执行完整 shell 语法
旧实现 shellUnquote 拆词后直接 exec：'pwd; ls /' 变成执行名为
'pwd;' 的程序（exit -1）、heredoc 被截断、管道/命令替换全部失效——
agent 多次反馈命令解析奇怪即此。危险命令拦截（kill homed 等）保留。
2. files 沙箱根目录判断修复
pathWithinSandbox 在 base='/' 时 prefix 变 '//'，所有绝对路径误判
逃逸（生产实锤：files.dir=/ 下 files_read/write/ls 全部报 outside
sandbox）。根沙箱直接放行。
3. webui 文件上传注入改走 interrupt（system 角色）
文件元信息不再混入用户消息气泡；用户附言作为正常消息先行注入，
文件说明紧随其后以 no_memory interrupt 补充——对齐 terminal_watch/
timer 工具提醒模式，聊天流保持干净。
4. 前端附件卡片按 role 区分来源
user=右侧+『你发送的』标签+accent 底色；assistant=左侧+『小宅发送的』。
📌 emoji 按钮换为 SVG 图标，前端 emoji 清零。
2026-08-26 10:24:47 +08:00
70f9b32a11
fix(webui): 附件消息历史持久化 + 用户文件上传（对齐 qq 插件收文件设计）
...
1. 附件展示链路补全
- ChatMsg 新增 Attachment 字段（type/url/size/name），channel_output
订阅提取 output_type/url/size 存档——修复刷新后附件变纯文本路径
（如 '/tmp/homeagent.png'）的问题
- EventRawInput 订阅支持 upload_* 字段：用户上传的消息也带附件卡片
2. 用户→agent 文件上传（POST /api/v1/chat/file）
设计对齐 qq 插件收文件模式：
- multipart(file + message) 落盘 <data>/uploads/<原文件名>（重名加
毫秒后缀，路径穿越消毒），单文件上限 64MB
- 注入文本「[用户通过 webui 发送了图片: 名字 (大小)] + 保存路径」，
agent 用 files_read 等工具按路径消费
- 回复走与普通消息相同的 SSE 流式管道
- GET /uploads/<name> 下载，与 /files/ 同一鉴权与安全模型
3. 前端
- 输入区 📎 按钮；拖拽到聊天区直接发送；粘贴截图即发送
- 本地预览用 URL.createObjectURL 即时显示
2026-08-26 10:03:46 +08:00
9716e95ecd
feat(webui): agent 可向 webui 发送图片/文件，前端内联展示与下载
...
输出通道能力升级：webui 通道从 CapText(1) 扩展为
CapText|CapFile|CapImage(7)，agent 经 output_send__webui 即可发送
image/file（此前仅文本）。
服务端：
- stageWebFile 把本地路径文件拷贝到 <data>/webui_files/<hex>.<ext>
（随机名防猜测、危险扩展名强制 .bin），http(s) URL 直接透传不落盘
- 新增 GET /files/<name>（requireWeb 与 dashboard 同鉴权）：扩展名
白名单映射 Content-Type，图片/音视频 inline、其余 attachment 下载，
nosniff + 路径穿越拒绝
- SSE agent_output 事件携带 output_type/url/size 字段
前端（dashboard.html）：
- channel_output 识别附件消息：image 渲染内联预览（点击原图）、
file 渲染下载卡片（含大小）；formatBytes 人性化显示
典型场景：agent 把 remotedevice 回传的录像/截图（device_media/*.mp4）
直接发给 webui，用户在聊天里看到视频预览或一键下载。
新增 TestStageWebFileAndDownload / TestHandleFilesAuth 覆盖。
2026-08-26 09:17:07 +08:00
b78fd4f342
fix(remotedevice): 媒体回传落盘 + webui SSE panic + GUI 相机跨平台
...
1. remotedevice 媒体落盘（核心改动）
设备录像/照片二进制聚合后写入 <data>/device_media/<reqID>.<ext>，
cmd_result 返回 file 路径，不再 base64 内联——10s 录像数 MB 的
base64 会撑爆 LLM 上下文与工具结果管道。未配置目录时保持旧内联行为。
新增 TestWSBinaryMediaToFile 覆盖。
2. webui SSE 'send on closed channel' panic（生产单日 4924 次）
handleChatEvents 的 defer close(writeCh) 与 Subscribe 回调闭包竞态：
handler 退出后总线仍可能异步触发回调向已关闭 channel 发送。
改为 writer goroutine select on done 退出，不 close channel；
defer 中等待 writerDone 保证无残余写入。
顺带补 mockPluginMgr.StopAndUnload（3ceb69f 接口变更漏改测试）。
3. GUI camerasue 平台分支
ffmpeg 参数原硬编码 Linux v4l2(/dev/video0)，Windows 上必然失败。
现按平台探测：win32=dshow(枚举设备名取第一个视频设备)、
darwin=avfoundation、linux=v4l2；录像编码 Windows 交给 mp4 muxer 默认。
2026-08-26 01:25:40 +08:00
8e66b49873
fix(remotedevice): WS 握手 Accept 改用 SHA-1（RFC6455 合规）
...
wsAccept 误用 sha256 计算 Sec-WebSocket-Accept，RFC6455 §4.2.2 规定
必须为 base64(SHA1(key + GUID))。后果：所有标准 WS 客户端（浏览器/
Electron/各语言标准库）校验 Accept 失败后立即断开连接，设备永远无法
完成 hello 注册——devicedetect 恒返回空列表，核心看不到任何设备，
而设备端本地授权状态正常，形成'已授权但核心看不见'的表象。
验证：openssl sha1 对照 + 干净实例端到端握手 Accept 完全一致。
2026-08-25 23:48:20 +08:00
3ceb69fb13
feat(pluginmgr): 插件更新接口（upgrade/downgrade 保留配置）+ skill_install overwrite
...
内核 Registry 拆出 StopAndUnload：
- 停止并从注册表移除插件但保留 config_<name> 表
- 不触发 onRemove 回调（那是删除专用语义）
- RemovePlugin 改为追加清理配置表示清除，更新场景调 StopAndUnload
pluginmgr:
- installFromData/installFromURL/installFromPath 加 overwrite 参数
- 已存在+overwrite=true：StopAndUnload→备份旧目录→解压新包→失败回滚→
返回 action=upgraded/downgraded/reinstalled+previous_version+config_kept
- 已存在+overwrite=false：返回 error+hint（指向 overwrite 用法）
- cmpVersion 点分版本号数字比较（非字典序）
- 测试覆盖：首次安装→重装拒绝→升级保留配置→降级→失败回滚
skill_install 加 overwrite 参数：
- 同名技能存在时先卸载旧实例+删除目录再安装新包
SDK PluginMgr 接口同步加 StopAndUnload(name string) error
工具链 plugindev 已重建到 /usr/local/bin（7/29→8/25 版本）
QQ 插件诊断日志版（webhook recv 到达+isAtBot 失败日志）已打包并
通过 upgrade 接口热更新部署，配置保留验证通过。
2026-08-25 22:02:17 +08:00
b10868f7cb
feat(skillmgr): 原生技能管理器插件 + OpenClaw 兼容层职责分离
...
新增 internal/plugins/skillmgr（native skill 全生命周期 owner）：
- skill_list/info/load/unload/enable/disable/create/export/install
- skill_create 两步式：先生成骨架模板，LLM 补全后传 content 覆盖写入
（plugin.ValidateSKILLContent 校验）并自动加载生效
- .skm 分发包（tar.gz）：packSkill/unpackSkill 含 TarSlip 防护
（拒绝绝对路径/../逃逸、强制单根目录、校验包内 SKILL.md）
- skills 目录扫描：纯 SKILL.md/skill.json 条目归本插件；
sidecar(main.js/main.py)/OC plugin(openclaw.plugin.json) 留给兼容层
clawhubadapter 职责分离（OpenClaw 兼容层不再持有 native skill）：
- 删除 p.skills 字段与 default 分支 LoadSKILL 逻辑
- 发现纯 SKILL 条目改为发布 events.EventSkillDetected 移交事件，
由 skillmgr 订阅注册；启动时序 c<s 下全扫兜底，事件用于热新增
- claw_list/plugin_info 不再输出 SKILL 段，统一走 skill_list
方案B prompt 注入：
- agentCore 新增 SkillIndexProvider 接口 + SetSkillIndexProvider
- buildSystemPrompt 注入【可用技能】轻量索引（名称+版本+描述），
LLM 匹配场景时主动 skill_info 拉全文按文档执行
- main.go 在插件加载后将 skillmgr 实例接线到 agent
内核小修：
- extractDescription 跳过 YAML frontmatter 块（此前所有带 frontmatter
的 SKILL.md 描述都被误判为 '---'）
- extractField 剥离 YAML 成对引号（version: "1.0" 不再带尾引号）
- plugin.ValidateSKILLContent 导出供生成侧校验
2026-08-25 20:25:57 +08:00
a4e0cfcaa1
fix(mcp+adapter): 流式 tool_calls 解析修复 + MCP transport 超时保护
...
openai adapter transform_stream_chunk:
- OpenAI 流式分片是嵌套格式 function.{name,arguments}，原样透传后
json.Unmarshal 到扁平 ToolCall{name,arguments} 时 name 恒为空，
accumulateStream flushToolCall 因 acc.name=="" 静默丢弃整个工具调用
（流式路径自上线起 tool_calls 全部丢失的根因）
- 现在正确解包 function.name → name，function.arguments → raw_arguments
（保留原始 JSON 字符串分片，由 accumulateStream 按 index 拼接）
- 不按 name 过滤分片：OpenAI 流式续传块 name 为空但携带 arguments 分片
mcp stdio/sse transport:
- stdio Send() 无超时：server 进程卡死时插件加载永久阻塞
- sse http.Client 无超时：远程 server 网络抖动/无响应时永久阻塞，
导致 webui 等后续插件全部无法启动（生产实例偶发启动卡死根因）
- stdio 加 60s 请求超时；sse client 加 30s 整体 + 10s 拨号超时
2026-08-25 18:59:00 +08:00
