3c961b7bd7
feat(channel): N1a —— inputch 一等化（归属插件/归属 agent/容量/共享登记表）+ 单工具多视图总览
...
设计：docs/zh/resident-subagent-design.md §4.6（里程碑 N1a）。
## 用户要求
「父 agent 可以看到所有已注册的 inputch 以及 inputch 的划分情况，用**单工具多视图**方式构筑」
## 登记层（internal/agent/io/inputch.go）
inputch 是**最基本的输入路由单位**（由插件注册，一个插件可注册多个），
所以登记表以 inputch 为键，每条记录：
名字 / 归属插件 / 归属 agent(被划给谁) / 容量 / 默认回程 outputch / 记忆策略(ChannelDef)
- 新增 `ChannelRegistry`，设计成**可共享对象**（`*ChannelRegistry`）：
根 agent 与驻留子共用同一份，"划入/授权"才有意义；`SetChannelRegistry` 注入。
- **插件重载不得抹掉划分**：重复登记只更新「归属插件 + 策略」，
保留已有 Owner/Capacity/Output（否则一次 reload 就把父做的划分清空）。
- `Assign` 语义按设计 R6 默认：**读写授权，不转移所有权**（Plugin 与 Owner 分别记录）。
- 原 `inputChannels map[string]ChannelDef` 被登记表取代；`GetInputChannelDef` 保持兼容。
- `plugin.Registry` 注册时带上**归属插件名**（此前完全无归属信息）。
## 总览工具（internal/agent/core/inputch.go）
单工具 **`input_channels`** + `view` 参数（不是一堆小工具）：
all（默认）= 全部已注册（带归属插件）
mine = 划给本 agent 的
unassigned = 尚未划出的
by_agent = 划分情况总览（按归属分组）
detail = 单个 inputch 全字段（需 name）
未知 view **报错并列出可用值**（拼错不得被静默当成默认视图）；登记表为空时明确说明。
## 验收
- `internal/agent/io/inputch_test.go`：归属记录、重载保划分、Assign/视图数据面、
**跨 manager 共享登记表**、策略查询向后兼容 —— 5 项
- `internal/agent/core/inputch_test.go`：单工具多视图逐视图断言（含未知 view 与空表）—— 2 项
- 全仓 `go test ./...` 37 包 ok / 0 FAIL；`-race ./internal/agent/... ./internal/plugin/...` 干净
2026-09-13 09:06:50 +08:00
f3232000f4
feat(scheduler): L4 也归内核级插件 —— WebUI 终止按钮可用“立即打断”
...
上一提交把 L4 写成“内核独占（panic / selfip）”，漏了内核级插件这类来源。
用户澄清：**内核级插件应当能声明 L4，用于实现中断能力**，例如 WebUI 的终止按钮。
判据（两道闸，纵深防御）：
1. proc 桥（外部进程唯一入口）一律把 L4 夹到 L3。在这里夹而不是只按 source 判，
是因为 source 是插件自报字段、可以冒名；本函数所在位置能确知“来自外部进程”。
2. core：isKernelLevelSource(source) 查 pluginReg.IsBuiltinPlugin，只有编译期内置
插件（init() 自注册的工厂）才承认 L4。
source 约定 `插件名` 或 `插件名/实例`（webui/<deviceID>），判据取第一段——
否则带设备身份的 WebUI 来源会被误判成外部插件而拿不到 L4。
改动：
- core: interruptLevel(evt, privileged bool)；新增 isKernelLevelSource；
requestPreempt 不再夹取（级别已由 interruptLevel 解析，否则内核级插件的 L4 被削掉）。
- eventloop: 传入 a.isKernelLevelSource(evt.Source)。
- proc 桥: 新增 clampExternalPriority，pubSdkInjectOpts 一律夹取。
- internal/sdk: 再导出 PriorityL1..L4（内置插件用 sdk.PriorityL4）。
- webui handleChatInterrupt（终止按钮）声明 PriorityL4。
- timer 声明 PriorityL3：定时器是“时钟那种实时工作”，比 QQ 那类可无限等待的
异步消息高（L1）——这是对用户“它不是时钟那种实时工作”的直接推论，可改。
- 测试: L4 特权矩阵（非特权夹取 / 特权承认）、source 判据（内置、内置/实例、
外部、空、前缀不误匹配）、内核级插件 L4 一路到达调度器、proc 夹取两条。
- 设计稿 §2/§3.2/§11.1/§14/§15 按“L4 = 内核 + 内核级插件”更正。
验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿（含 webui/timer）。
2026-09-13 07:18:03 +08:00
cb32032f76
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
b15d0bd114
refactor(plugin)!: 重编提示与模板路径改用 hmapdev；文档全面对齐 1.2.0
...
工具链在 SDK 1.2.0 更名为 hmapdev（原 plugindev）。核心侧三处功能耦合同步：
1. 用户可见报错：旧 C ABI 产物 / 协议版本不匹配 / 共享段版本不匹配
三处「请用配套 plugindev 重编」→ hmapdev（对应两条测试断言同步）
2. e2e_template_test 的模板路径改为 tools/hmapdev/templates，
并保留旧路径回退（旧 SDK 检出仍能跑测试）
3. 注释与文档同步
文档更新（用户可见面）：
- assets/docs/{zh,en}/PLUGIN_DEV.md：工具链章节整体改为 hmapdev，
补改名说明与 SDK 存储目录迁移；命令示例全部更新
- assets/docs/{zh,en}/ARCHITECTURE.md：**流程图与章节对齐 v1.2.0** ——
· 向量化章节改为三层降级：统一多模态空间（主）→ 词嵌入 → TF-IDF（回退），
写明「同指纹且同维度才参与融合」
· 媒体记忆章节重写：媒体是一等记忆块（无独立 GC / 无引用计数 / 无描述式索引 /
正文不再写 media marker），并写明 reembedStaleMedia 的跨空间迁移与写回
- README{,_EN}.md、docs/zh/plugin-interface-matrix.md：工具名与模板路径同步
（历史条目标注「当时名为 plugindev」）
验证：go test ./internal/plugin/ ./internal/plugin/proc/ ok，
含 4 条真实模板 E2E（模板路径切换后仍通过）。
2026-09-12 12:42:43 +08:00
d1959cbe80
feat(core): 注入行为的记忆/裁剪标志位落地 + jieba 词库内嵌 + Windows 改走 WSL
...
配套 SDK 提交：homeagent-sdk ba49dfd（公开 API 纯追加，无签名变更）。
本仓第三方的库镜像同步至该版本，以保证全新 clone 能编译。
## 1. 注入标志位（内核侧）
- 7 条注入路径（排队/中断/同步 × 纯文本/带媒体 + 旧 NoMem 变体）解析并转发
no_memory / context_policy / cleaner_name；策略在入口**校验**，
非法值报错而不是静默降级成 none（降级会让调用方以为自己声明的裁剪在生效）。
- 新增 validateContextPolicy（与 tool.register 同一套规则）与 pubSdkInjectOpts。
- input.register 不再手写字段白名单重建 ChannelDef，改为整体传递 + 补 ContextPolicy。
- io 层：applyInjectOpts 把标志位写进事件 payload，仅非零时写
（零值与旧 payload 逐字节一致，事件订阅方与旧内核都不受影响）。
- ioAdapter / procCore / internal-sdk 别名补齐六个 *Opts 实现。
## 2. 修掉「输入无条件裁剪」这个真缺陷
eventloop 此前对**每条非中断输入**都调 `context.Prune(...)`：破坏性（低相关事件被
归档移出上下文）且无法从调用点看出是谁触发的。改为 pruneOnInput/pruneDeclared：
优先级：注入点声明（payload.context_policy）> 通道声明（ChannelDef.ContextPolicy）
> 默认**不裁剪**
查询向量仍取清洗后的内容；新增 cleanInputFor 解析清洗文本，优先级为
注入点声明的 cleaner（cleaner_name）> 按 source 查到的通道 cleaner > 原文，
名字查不到时**记日志再回退**（注入是 fire-and-forget，插件看不到错误，
至少要在内核日志留下「你声明的清洗没生效」的痕迹）。
## 3. jieba 词库内嵌（修「猜 GOMODCACHE → 静默失效」）
原 jiebaDictDir() 去猜 GOMODCACHE/GOPATH/~/go/pkg/mod，部署机上通常没有 Go 模块
缓存 → GetJieba() 返回 nil → 分词/关键词提取/NLP 依存解析（进而 doc→graph 三元组
抽取）/静态词向量 tokenizer **一律静默返回空列表**，只有一行日志。本机看起来正常
只因开发机与生产机重合、恰好有那份缓存。
现在词库随二进制分发：internal/memory/jiebadict/ 5 文件约 11.6MB + go:embed，
按**内容哈希**命名缓存目录落盘（词库升级不复用旧文件），已齐全则跳过写入。
模块缓存降为兜底。homed 体积 32MB。
顺带确认（并有测试佐证）：gojieba 的 Tag() 不需要 pos_dict/ 目录——
cppjieba 的 PosTagger 从主词典每行的词性列取 tag。
## 4. homed 放弃 Windows 原生，改走 WSL2
插件体系依赖「继承的 fd」+「统一共享内存区的段内偏移解引用」，Windows 既无 fd
继承语义，其句柄模型也无法表达后者；强行适配等于再维护一套平台专属 ABI
（C ABI 时代三套 ABI 并存曾导致改写型插件在某平台静默失效）。
- cmd/homed/platform_{windows,other}.go：原生 Windows 启动即拒绝并打印 WSL2 指引。
- internal/plugin/proc/shmalloc_windows.go：allocShm 直接返回「请用 WSL2」，
**不返回半可用的段**（与 shmalloc_other.go 同风格：未支持平台显式报错）；
procEnvForShm 返回 nil。顺手修掉两处长期编译错误
（cryptorand→rand、h.evData→h.unified.evtData），使 GOOS=windows 至少能编译。
注：homed 本就编不出 Windows——internal/memory 依赖 cgo-only 的 gojieba。
- deploy/packaging/installer.nsi：不再安装 homed.exe/initconfig.exe，改为携带
**linux payload** 并调用新的 install-via-wsl.ps1；退出码 20/21 表示
「需先装 WSL/发行版」，走指引而非报错。
- deploy/packaging/windows/install-via-wsl.ps1（新）：检测 WSL → 引导安装 →
确保 WSL2 → 送包进发行版 → 在 WSL 内按 Linux 方式安装。**复用 Linux 包与
linux/setup.sh**，不另写一套安装逻辑；落点与 deb 布局统一
（/usr/bin/homed + /usr/lib/homeagent/setup.sh）。
- deploy/packaging/linux/setup.sh：API Key 允许 HOMEAGENT_API_KEY 覆盖
（否则安装器界面显示一份、config.db 里另一份 → 登录不上）。
- deploy/packaging/build.sh：windows 目标只构建 waiter + gui，并新增
stage_linux_payload 把 Linux 包暂存给安装器；homed/initconfig 在 windows
目标下明确拒绝。
## 5. 插件调用点统一写明意图
- webui 的 OpenAI 兼容端点（固定提示词模板）→ InjectTextSyncNoMemory。
- agentcli 的 5 处纯状态通知（已启动/超时/执行结束/进程退出/读取结束）→ NoMemory；
**带输出**的 2 处（定时反馈、有新输出）刻意保留记忆并注明理由。
- timer 的定时提醒 → NoMemory（中断本来也隐含 NoMemory，这里是写明意图）。
## 6. 版本
meta.Version 仍为 1.2.0（main 是下一个未发布中版本）；
SDKCompatibleVersion 1.1.0 → **1.2.0**（本内核已实现 SDK 1.2.0 全部新增方法）。
## 测试
- core：默认不裁剪（无声明/none/空）、通道 opt-in、注入点双向覆盖通道、
nil context/io 安全、cleaner 优先级与未知名回退。
- io：零值 opts 与历史 payload 逐键相同；text/中断/媒体三类注入标志位都落到
payload；旧方法仍生效。
- proc：validateContextPolicy 只接受 ""/none/prune，报错含位置与实际值；
**跨进程** e2e——testdata 插件经 io.injectText 送出三个标志位，断言它们穿过 RPC
到达内核。
- memory：模块缓存不可见时内嵌词库仍可用（分词与 POS 内容词均非空）、
落盘幂等、内容哈希稳定。
验证：go build ./... / go vet ./... / go vet -tags onnxruntime ./...
go test -short ./internal/memory/... ./internal/nlp/... ./internal/plugin/...
./internal/agent/{core,io}/... ./pkg/...
2026-09-11 20:31:50 +08:00
5836c2ce5c
refactor(memory): 拆除描述式媒体索引，媒体成为一等块并按原生向量融合
...
背景：此前媒体是靠「生成的描述文本」将就进记忆的——写 marker 进正文、
再由正则反解成 media_refs 与图库里的 type=Media 实体。这条链路有三个
致命缺陷：描述由异步模型生成（未生成前媒体等于不存在）、语义检索实质上
只搜描述文字、图库里的「媒体节点」是描述文本的投影而不是媒体本身。
本提交把这条链路整体拆除，媒体改为按自己的原生向量参与记忆：
一、描述链彻底删除（无残留、无兼容分支）
- media.Item 去掉 Description/DescribedBy 与对应列；
- 删除 Store.Describe / Store.Search / Store.Pending；
- 删除 Agent.mediaDescribeLoop / describePendingMedia 与配置项
core.memory.media.describe_on_ingest；
- SDK 侧 MediaAttachment 去掉 Description（见 SDK 仓独立提交）。
二、marker 机制删除，媒体归属改为结构化块边
- 删除 mediaMarkerLine/parseMediaMarkers/mediaEntityName/mediaTriplesFromText/
extractMediaDigests/sentenceWithMediaMarkers/docMediaContext；
- memory.Triple 新增 MediaDigests 结构化字段；句子文本保持原样，
不再被 marker 污染；
- 块以 sentence --contains--> block / document --contains--> block 结构边
挂到承载节点（新增 documents 表与 document 节点种类）；
- 模型未给原句时用「主谓宾。」拼一句自然语言作落点，不造 marker 文本。
三、旧数据迁移（幂等）
- 新增 GraphDB.MigrateLegacyMediaEntities：把 type=Media 的旧实体按短 digest
还原成原生块、挂回原句子、删除旧实体与描述关系；Agent 启动时执行；
- CleanupOrphanedSentences 同时看关系引用与块边，避免把只靠块存活的句子
连同块边一起删掉。
四、向量融合：媒体按图本身被召回
- 新增 vector.FuseVectors（逐维求和 + L2 归一化）；
- Doc.DenseVec = 文本向量 ⊕ 文档块的媒体向量（同 fingerprint 才融合），
新增 Doc.DenseFP，指纹变化触发重算；
- ContextEvent.DenseVec 同理融合事件块；事件新增 DenseFP，Prune 只在
同一统一空间内比稠密余弦；
- 跨模态视觉路只召回「仍被某层记忆块持有」的媒体，CAS 全库字节不再
直接充当记忆检索结果。
五、同时纳入本分支既有的嵌入基础改造（此前工作区未提交，缺它 HEAD 不可构建）
- internal/tfidf 懒回退包、千问三段式多模态 ONNX 空间的 Go 侧
（qwen/embedder.go、image.go、model_input.go）、CLIP 移除、
sdk.NewStore 分词器签名与调用点、embed 侧车 systemd 单元。
验证：go build ./... 、go vet ./...（含 -tags medialive）均通过；
在 HEAD 的独立 worktree 上重放本次暂存集后 go test -short ./internal/...
全部通过（端口冲突类用例在隔离环境中亦通过）。未提交工作区中与本改造
无关的改动（HarmonyOS、waiter、devicebridge、plan.md 等）。
2026-09-11 11:45:24 +08:00
50ba4a64cb
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
15d912ef34
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
e2672c56d6
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
b71a88a471
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
e218d0f100
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
b096e8ba2c
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
c03de9878d
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
ca584bda3f
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
cf3c99233b
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
2bc813be13
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
9cfdfc9de8
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
5608abdf5a
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
cf098a1d4f
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
a8e3633174
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
ad016e4410
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
7a328679da
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
687e5655bc
feat(sdk): 多模态贯通插件边界——公开接口、内核桥接与统一输入主干
...
记忆系统在 1.1.0 支持了二进制多媒体节点，但那条链路只对**内核自己**开放：
用户在 qq 发图能落进 CAS、能被记忆引用，而插件调 Commit / DocMemory().Insert
交进来的媒体一律无处安放。原因是三层都断着，且**每一层都不报错**。
## 一、公开 SDK：补上媒体的表达能力（全部新增，无签名变更）
- `Triple` += `SentenceText`、`MediaDigests`
- `Doc` += `MediaDigests`、`Attachments`；新增 `MediaAttachment`
- `TextEvent` += `Attachments`
- `DocMemoryAPI` += `InsertWithMedia`
- `IOInjector` += `InjectInputMedia` / `InjectInputMediaSync` / `InjectInterruptMedia`
- `PluginSDK` 补上一直缺失的 `SetToolBlocks` 包装（接口里有、便捷方法里没有）
`MediaAttachment` 一个类型服务两个方向：给 `Data`+`MIME` 是新内容（CAS 按字节
去重），只给 `Digest` 是引用已有内容。读路径**只回元数据不回字节**——一次检索
可能命中几十份媒体，全塞回去会把跨进程消息撑爆。
媒体注入不能搭 `SetToolBlocks` 的车：那个方法只在工具处理函数内部可用，且媒体
要等下一条 tool message 才到模型手上。插件主动发起一轮带媒体的对话、以及中断
注入，需要自己的签名，且媒体在**本轮**就送到模型。
## 二、内核桥接层：原先在静默裁字段
`internal/sdk/memory_impl.go` 此前只搬自己认识的几个字段，其余丢弃且返回 nil：
- 图记忆丢 `Confidence`/`SubjectType`/`ObjectType`/`SentenceText`，又走 `Commit`
而非 `CommitWithMedia`（不回 sentenceIDs）→ 媒体绑定链 `SentenceText → sentences
→ sentence_id → media_refs` 一步都走不通，插件即便按格式写好标记也永远挂不上；
- 知识库 `Query` 只回 ID/Title/Content，`Insert` 只写这三个；`Remove` 不解引用，
于是那些媒体永久处于「被引用」状态，GC 收不掉、磁盘只增不减
（内核的归档路径 `releaseDocMedia` 做了这一步，插件路径漏了同一步）。
规则改为：**内部结构有的字段一律透传**。标记格式处理作为包级私有辅助留在桥接
层自己手里，但必须与内核 `mediaSummaryForEvent` 字节兼容——两边要能互读对方
写下的标记。
标记插入必须在 `ds.Insert` **之前**（向量索引取 `Summary + " " + Content`，
之后补的标记检索不到），引用绑定必须在**之后**（owner_id 是 Insert 生成的 ID）。
## 三、跨进程链路：不接线就是全体外部插件编译失败
`go test` 直接把这一层拍出来了——`procIO does not implement sdk.IOInjector`。
公开接口加方法后，生成模板不跟上，**每个外部插件都编不过**，是硬失败不是软降级。
六处接线：`protocol.go` 四个 method 常量、`capability.go` 能力归属、
`corehandler.go` 四个分派分支、`proc_core.go` 委托、`proc_main.go.tmpl` 模板侧
实现、以及三个测试替身。
## 四、统一输入主干：把模态从「函数选择」降级为「字段」
`processTextInput` / `processMediaInput` 合并为 `processInput`。这个分叉是历史
产物而非设计：`processTextInput` 本来就处理媒体（`bindEventMedia` +
`mediaSummaryForEvent`，与媒体路径尾部完全相同），`process()` 只看
`stageCtx.Extra["media_blocks"]`、根本不认识 `evt.Type`。模态是输入的**属性**，
不是输入的**种类**。
媒体路径由此获得它一直缺的六项：去重、`no_memory`、通道 `Cleaner`、中断语义、
`_consolidation_` 路由、正确的 `EventRawInput`。
最后一项是个真 bug：媒体路径发布 `"content": evt.Payload`（一个 map），而
`webui/handler.go` 断言 `.(string)` → 断言失败、`content == ""`、提前返回。
**用户发的图从来没出现在 WebUI 聊天记录里。**
`media_blocks` 同时接受 `[]agentAPI.ContentBlock` 与 `[]pubsdk.ContentBlock`：
字段一致但 Go 不自动转换，只认一种的后果是另一种被静默丢弃。
## 五、模型可调用的三个工具
`memory_commit` 的 `sentence_text` **从未暴露给模型**，而它是绑定链上的必经环节；
连同 `media_digests` 一起补进 JSON schema 与工具文档。`doc_commit` 加
`media_digests`。`doc_query` 把关联媒体单独一行附在结果末尾（正文按 2000 字截断，
标记通常就在尾部）。
标记由**内核**生成而非插件/模型拼装：要求调用方知道格式，等于让一个拼写错误
静默切断引用绑定，而全链路无人报错。
## 六、WebUI 上传走真实媒体链路
图片/音频读回字节拼 data URL 注入 `media_blocks`（8MB 上限，超限退回按路径处理）。
此前只注入一句「文件已保存到 <路径>」，指望模型自己调 `files_read`——但那返回
文本，图片字节对模型永远不可见。附件类型识别扩展到 audio 并在缺 Content-Type
时按扩展名兜底（判错不只是卡片样式问题，图片被当普通文件就进不了视觉链路）。
## 测试
- `internal/sdk/memory_impl_test.go`（12 例，此前该包**没有任何测试文件**）
- `internal/agent/core/inputunify_test.go`（统一主干 + 双静态类型 + 三工具媒体）
- `third_party/homeagent-sdk/sdk/stress_test.go`（13 例并发压测）
压测抓到两处**真**竞态（不是理论风险）：`PluginSDK` 的 API 字段与 `autoRestart`
无锁，而写方（内核注入 API、插件 `SetAutoRestart`）与读方（插件后台 goroutine
注入、内核 registry 读 `AutoRestart`）天然跨 goroutine。加 `apiMu` 修掉；约定
只在持锁期间取字段值，取完即释放再调用——持锁调用会把 `InjectInputSync` 这类
阻塞到 agent 回复（可达数分钟）的方法与 `SetIOInjector` 串起来，让插件重载卡死。
测试还抓出两个自身缺陷：`bindDocMedia` 把同一份媒体数两次（`AddRef` 幂等所以表
是对的，但日志说「绑定 2 个」而实际 1 条——误导后续排查），以及用单字符实体名
时 `validEntityName` 静默跳过、`Commit` 返回 nil 却什么都没写。
存量插件不需要改一行也不需要重编：新增方法由插件调用、内核实现，不调就不受影响。
17 个 example 插件源码零改动通过类型检查。
2026-09-06 09:51:31 +08:00
e272c686d3
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
f91b27aedb
fix: WebUI 版本显示 + Windows 交叉编译 + 发布脚本三处回归
...
## WebUI 版本链路修复
问题：handler.go:949 报的是 sdk.SDKVersion，那条链最终指向
SDK 仓 meta.Version 的硬编码值，与 -ldflags 注入的内核版本
完全不相交。构建时间、commit hash 全部丢失。
dashboard.html 兜底值是 '0.1.0'——碰巧版本号相等时不显眼，
一旦不等就报错。
修复：
- KernelStatus 新增 BuildStatus 字段（Version/Commit/BuildTime/SDKCompatible/KernelName）
取自 internal/meta（-ldflags 注入点），与接口冻结无关（KernelStatus 只在 internal/sdk）
- /api/v1/status 改用 meta.Version，另加 sdk_version 字段暴露 SDK 版本
- dashboard.html 概览卡显示 HomeAgent vX.Y.Z + commit/日期/SDK 兼容版本，
去掉 || '0.1.0' 误导性兜底
## Windows 交叉编译修复
问题：internal/plugin/dynamic_proc_windows.go（Part 1 的桩，610e9d0）只定义了
tryLoadProc，但平台中立的 registry.go 还在调 loadProc / closeProcHost——这两个
函数只在 dynamic_proc_unix.go 里。Windows 下整个 homed 从 Part 1 起编译不过。
plan.md §12.5 声称「Windows 只做了交叉编译，无真机验证」——实际是连编译都没通过。
修复：dynamic_proc_unix.go / dynamic_proc_windows.go 合并为平台中立的
dynamic_proc.go（文件内无任何平台专属调用，proc 包内部通过
shmalloc_* / evtfd_* / shmpass_* / procattr_* 各自带构建标签处理差异）。
## 发布脚本三处回归修复
deploy/packaging/build.sh（从 package/build.sh 移到 deploy/packaging/ 后）：
1. PROJECT_ROOT 少一层目录（.. → ../..），产物落进 deploy/build/ 而非根目录
2. initconfig 从未被构建，但 installer.nsi 和 package-linux.sh 都引用它
3. GO 兜底路径指向 /home/jianf/go1.26.5（陈旧硬编码）改为 command -v go
4. electron-builder --config package.json 校验整个文件导致 devDependencies 被判为 unknown
property，去掉 --config 让它从 build 键读配置
deploy/packaging/package-linux.sh：
1. build_go() 补上 initconfig 构建步骤
2. GO 兜底路径同步修复
知识库 3 条重写 + 1 条新增：
- homeagent_identity：v0.9.0 C ABI → v1.0.0 子进程
- homeagent_architecture：全篇重写为子进程架构（三面通信、Supervisor 台账、
崩溃自愈、权限三道闸）
- homeagent_recent_updates：在 v0.9.0 前插入 v1.0.0 主线摘要
- changelog_v1.0.0（新建）：6 类缺陷消除、架构、实测、已知限制、迁移指引
2026-09-03 15:38:31 +08:00
02cc74ce11
fix(proc): 子进程崩溃自愈 + 集中台账 + 注册面摘除
...
根因：子进程插件被 kill 后，内核只发了一个无人订阅的事件，
工具/stage handler/IO 通道全留在注册表里指向死进程，
模型继续调用只吃 ErrProcessExited，没有任何路径把插件拉回来。
## 四层修复
### 1. 专职 waitLoop（进程收割）
- 每个子进程配一根 waitLoop goroutine，是 cmd.Wait() 的唯一调用点
- 不再依赖 stdout EOF 判定死亡（孙子进程继承 stdout 时 EOF 永不到来）
- 手工 os.Pipe 替代 cmd.StdinPipe/StdoutPipe，避免 waitLoop 与
os/exec 的内部关闭竞争
- host.go: Host.Supervisor()，Host.Close() 先 StopAll 再拆段
### 2. 集中台账 Supervisor
- proc/supervisor.go: 插件 Spawn 握手成功即 track，进程退出即 untrack
- StopAll: 并发发 plugin.stop 走优雅路径，到期仍在的一律 Kill
- 关停后才完成握手的进程被立即结束，不会活过内核
- 消除「孤儿进程持共享段映射 → SIGBUS」的隐患
### 3. 注册面摘除（detachPlugin）
- 新增 StageHost.UnregisterPluginStages：摘除指定插件的全部 stage handler
- 新增 Registry.pluginChannels 台账：记录每个插件注册的 IO 通道
- 三条路径统一走 detachPlugin：Disable / ReloadOne / RemovePlugin
- StopAndUnload 漏了 IO 通道也一并补上
### 4. 自动重启
- onProcCrash 从「只发事件」改为「摘注册面 → 从注册表移除 → 异步排重启」
- scheduleProcRestart: 窗口 5 分钟内最多 3 次，线性退避 1s/2s/3s
- 超限停手留日志；重启前复核是否已被 Disable 或被其他路径加载
- 崩溃计数窗口过期自动归零
### 5. 主动停止 vs 崩溃的区分
- proc.Plugin 新增 stopping 标志：Stop()/Close() 里 Set(true)
- handleExit 读 stopping 标志，主动停止不上报 onCrash
- 防止重载/禁用/卸载被误判为崩溃触发多余重启
### 6. Linux Pdeathsig 兜底
- procattr_linux.go: SysProcAttr.Pdeathsig = SIGKILL
- 兜 homed 自身被 SIGKILL/OOM 时子进程变孤儿的场景
- macOS/Windows 无等价物，空实现
### 7. pluginmgr 升级
- PluginManager 接口新增 PluginRuntime / ListPluginRuntimes
- plugin_list 输出运行态：loaded / alive / pid / crash_count / channel
- 新增 plugin_status: 全量运行期快照 + dead/unhealthy 汇总
- 新增 plugin_restart: 无条件重启单个插件（plgreload 不动未改二进制的插件）
### 测试
- process_test.go: 3 例（grandchild stdout 感知 / Supervisor track-untrack /
StopAll 无孤儿）
- crash_recovery_test.go: 8 例（detach 三项齐全 / 通道重注册 / 崩溃不阻塞 /
退避阈值 / 窗口过期 / 关停中跳过 / PluginRuntime 通道识别）
- stages_plugin_test.go: 4 例（stage 按插件摘除 / 空 stage 清理 / 空名 no-op /
工具+stage 双摘后可重新注册同名）
2026-09-03 12:37:58 +08:00
2572688c51
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
2ebdb9a5b7
plugin: 权限梯度显式化（Part 6.4）
...
迁移前，「外部插件拿不到 Selftest/Supervisor/Tracker」是 C ABI 表达能力的
**意外产物**——C 结构体不好传函数指针，这些能力自然到不了插件侧。那是运气
不是策略：任何人给 dispatch 加个 case 就能捅穿。
现在变成显式声明并强制，分三道闸：
1. **类型层**（proc_core.go，Part 6.2 已落地）：procCore 用命名字段持有
内核 SDK 而非嵌入，未在收窄面写出的方法编译期就不存在。
2. **能力集**（新增 capability.go）：54 个 plugin→kernel method 划入 11 个
capability 组，manifest 未声明的组被拒。
3. **RPC 边界**（corehandler.Handle 入口）：被拒时返回**明确错误**而非
静默忽略。
第 3 条针对一类真实故障：C ABI 时代 case 23/24（事件订阅）是空实现，
返回成功但永远收不到事件（§1.3 的「给不了」而非「不给」），插件作者无从得知。
错误消息含四要素：哪个插件、哪个调用、缺什么能力、在哪声明。
## 能力划分的两个判断
**粒度按能力域而非单 method**。逐 method 授权看似更精细，但插件作者要在
manifest 里列 60 个名字，且内核每加 method 所有 manifest 都得改。
**空声明 = 不受限，而非「只有 core」**。17 个存量插件的 plugin.json 都没有
capabilities 字段。若空声明当作最小权限，它们会全部失去 IO 注入、记忆读写
而**静默降级**——违反「外部插件零改动」的硬约束。收紧的路径是让插件显式
声明，而不是默默拒绝老插件。
## core 与受限能力的边界
core（无需声明，始终可用）：注册自身工具/阶段/通道/API、读写**自己的**配置、
共享段锁仲裁、握手、autoRestart 自述、setToolBlocks。没有这些插件无法工作。
受限（需声明）：io / memory / doc_memory / knowledge / text_memory / llm /
social / events / plugin_mgr / settings_cross。
settings 刻意拆成两级：读写自己的配置属 core（正常工作所需），读写**其他插件**
配置或**内核核心**配置属 settings_cross（能改别人/内核的行为）。
## withheldCapabilities：让「不给」可见
10 项刻意不提供的内核内部机制列在表里并附理由。它们没有对应 method 常量——
不是忘了加，是决定不加。列表存在本身就是「这是策略而非疏漏」的证据，
读代码的人能看到边界在哪，而不是从「protocol.go 里没有」这个负面事实去推断。
## 测试
proc 包 10 项：
- AllMethodsClassified：**最重要的一项**。漏登记的 method 会按 CapCore 放行，
等于绕过整套检查。新增 method 忘登记时当场报出。
- EmptyDeclarationIsUnrestricted / DeclaredSetRestrictsOthers / CoreAlwaysAllowed
- SettingsScopeSeparation：自身配置 vs 跨插件配置的归属
- DeniedErrorIsActionable：错误消息四要素
- HandleEnforcesAtRPCBoundary：被拒的调用不进 switch
- WithheldListIsDocumented：每项都有理由，且不被任何 method 暴露
- UnknownMethodFallsThrough：未知 method 报「未知」而非「权限被拒」，
否则作者会以为是漏声明能力
写这个测试时踩到自己的坑：第一版用子串匹配查 withheld 泄漏，"Tool" 匹配到
tool.register 和 io.setToolBlocks 误报——那两个是合法开放的（注册自己的工具）。
改成前缀 + unregister 关键字匹配，withheld 项也改名带 API 后缀以示区分。
internal/plugins 2 项接线验证：
- RestrictedPluginStillLoads：只声明 io 的 weather 仍能加载并注册工具
（它在 Start 里读 Settings，属 core）
- LegacyManifestUnrestricted：无 capabilities 字段的存量插件正常加载
真实 homed 实测：
[plugin] weather-capped 声明能力: [io]
[plugin] weather-capped: 经 proc 通道加载（子进程）
registering tool: weather-capped_current / _forecast / _set_location
验证：go build ./... 通过；go test ./... 全仓无失败；
go test -race ./internal/plugin/... 全绿；go vet 干净。
Ref: docs/zh/架构迁移评估.md §3.8、docs/zh/plugin-migration-plan.md Part 6.4
2026-09-02 21:27:13 +08:00
b20121f703
plugin: 删除 C ABI 通道（Part 6.2 完成，-3198 行）
...
外部插件统一走子进程 + stdio RPC，三套独立 ABI 实现收敛为单一 RPC 实现。
用户决策：彻底舍弃 .so 能力，不保留双通道回退。
## 删除清单
internal/plugin/cabi/ 1156 行（loader.go/loader.c/types.go/output_test.go）
internal/plugin/dynamic_dll_windows.go 272 行（§9.2 记录的能力退化实现）
internal/plugin/dynamic_loader_unix.go 79 行（唯一 cabi 引用点）
internal/plugin/dynamic_dll_test.go 32 行
internal/plugin/dynamic_dll_stub.go 11 行
internal/plugin/dynamic_loader_windows.go 11 行
internal/plugin/bridge_e2e_test.go （测的是 cabi 路径）
third_party/.../plugindev/templates.go 1296 行（取消跟踪，SDK 仓才是权威副本）
dynamic.go：entryCABI 通道删除，soEntry/dllEntry 常量删除。
registry.go：tryDynamic 探测顺序从 .so → .dll → .lua 变成 proc → lua。
## 旧 .so 给明确错误，不静默跳过
静默跳过会让「插件目录在但没加载」看起来像配置问题，而实际原因是需要
用新版 plugindev 重编。故保留 legacyCABIEntries 表专门用于识别残留：
plugin legacy: 检测到旧 C ABI 产物（plugin.so/.dll/.dylib）。
外部插件已改为子进程模式，请用新版 plugindev 重编产出 plugin.bin
（业务代码无需修改）
错误消息里「业务代码无需修改」这句是有测试守着的——迁移的核心承诺就是它。
## pluginmgr 安装逻辑跟进 bundle 命名
子进程模式下各平台产物统一叫 plugin.bin（进程边界即 ABI 边界），故 zip 内
按平台加后缀 plugin.bin.<goos>.<goarch>，解包时挑当前平台那一份重命名。
platformBinary 改为按 runtime.GOOS+GOARCH 生成条目名；platformBinaries 固定表
换成 isPlatformBinary 前缀判断（平台组合会增长：linux/arm64、darwin/arm64…，
按前缀判断无需维护清单）。
新增 chmod 0755：zip 保留了原权限位，但经某些工具链/传输后可能丢失，
内核加载时会因缺执行位报错。提前补上比事后让用户 chmod 更好。
## 测试
entry_dispatch_test.go 重写（12 项）：
- classifyEntry 对 .so/.dll/.dylib 现在返回 unknown
- LegacyManifestFallsBackToProbe：存量插件 manifest 仍写 "plugin.so"
（17 个插件没人去改），须靠目录探测找到 plugin.bin —— 这是
「外部插件零改动」的直接后果
- LegacyCABIGivesActionableError：错误消息须含 plugindev / plugin.bin / 业务代码
- PluginEntryHash_IgnoresLegacyCABI：.so 不参与 hash（内核已不认它）
upgrade_test.go 的 .hmap 构造改用 plugin.bin。
验证：go build ./... 通过；go test ./... 全仓无失败；
go test -race ./internal/plugin/... 全绿；三平台构建通过。
Ref: docs/zh/架构迁移评估.md §3.1/§9.2、docs/zh/plugin-migration-plan.md Part 6
2026-09-02 19:26:40 +08:00
d027c964e2
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
5bbfcc02fb
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
11c1bbcebb
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
82dcc86173
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
d62430a71b
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
610e9d0bbb
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
9bb9cb3b1a
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
b74ee15321
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
5fccc31afc
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
f0cdbdb030
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
ae42e486de
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
5f126d4d10
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
ba5785036a
feat: 设备鉴权迁移至客户端 + 插件卸载保护
...
安全修复（客户端鉴权）：
- remotedevice 服务端移除授权状态存储（authorized map/SetAuthorized/handleDeviceAuth）
- DeviceMeta.Authorized 改为设备 hello 自报，服务端仅透传展示
- device_ctl_* 工具移除服务端授权检查，无条件转发，设备端自行决定是否执行
- 共享设备桥库 Bridge 新增本地 authorized 状态，未授权收到 cmd 直接拒绝
- waiter: --device-authorized / device_authorized 配置控制本地授权
- GUI: 授权存 gui-prefs 本地文件；设备页仅本机可切换开关
- webui /device/auth 旧路径返回 410 Gone
- 根因：agent 可经 config_set 篡改服务端授权配置自行授权设备
插件管理强化：
- 内置插件禁止卸载（IsBuiltinPlugin + 409），外部插件卸载即时生效
- 卸载不存在插件返回 404；移除误导性 reload_required 提示
- webui 插件路由：名称白名单校验防路径穿越、保留字路径保护
2026-08-24 19:26:11 +08:00
2338f3f4f3
fix: 插件增量重载 + clawhubadapter ipcGoroutine 优雅退出
...
- Registry.Reload 改为增量: 对比插件入口文件(plugin.so/main.lua) SHA256, 仅重载有变更的插件, 未变更保持运行, 消除 plgreload 触发全量 StopAll+Load 导致的重复加载与内置插件状态错乱
- Registry 新增 pluginHashes 记录 + pluginEntryHash 辅助
- clawhubadapter.ipcGoroutine 无退出条件导致重载后旧 goroutine 永久残留(线程累积): 增加 stopCh/stopOnce, Stop() 关闭, ipcGoroutine 用 select 监听退出
- 新增 TestRegistryIncrementalReload 验证无变更跳过/变更重载
2026-08-17 08:53:39 +08:00
e43b7aa216
test: PluginManager 接口含 ReloadOne 的编译期契约验证
2026-08-16 18:52:56 +08:00
da327ac3e1
feat: 导出单插件重载到 SDK (CORE_PLUGIN_RELOAD_ONE/48 + LIST/49 + IS_DISABLED/50)
...
- PluginManager 接口新增 ReloadOne(name) error
- cabi dispatch: case 48 单插件重载, 49 列已加载, 50 查询禁用
- 外部 SDK 新增 PluginMgrAPI(ReloadOne/ListLoadedPlugins/IsPluginDisabled) + bridge dispatchPluginMgr 注入
2026-08-16 18:27:25 +08:00
b4006212e7
feat: Lua 插件 stage 写回支持(与 C ABI v2 对齐)
...
makeStageHandler 现在把 ctx 以 Lua table 引用传给 handler,
handler 修改的字段(raw_message/llm_text/final_text/response/tool_calls/
tool_results/user_id/group_id/no_memory)同步写回内核 StageContext。
新增 TestLuaStageWriteback 验证 on_input/post_action 的写回。
2026-08-15 18:02:50 +08:00
014870a0e0
fix: 兼容旧 ABI 插件 + 移除 plugin.Open 致命 fallback
...
- CABINumMin 恢复为 1: 旧工具链编译的插件写入整数 version=1/2,
与新版内核结构体兼容(仅缺 stage 写回能力), 应允许加载而非拒绝
- tryLoadSO 移除 Go plugin.Open fallback: 本项目插件统一为 c-shared,
对 c-shared .so 调用 plugin.Open 会 fatal (no plugin module data) 不可恢复,
直接返回 cabi.Load 错误避免启动崩溃
2026-08-15 16:31:51 +08:00
710b1afdf9
C ABI v2: invoke_stage 写回 + ABI 版本对齐核心版本号 (v0.9.0)
...
- C ABI invoke_stage 增加 result 输出参数，外部插件 stage 回调可将修改后的
StageContext(RawMessage/LLMText/FinalText/Response/ToolResults) 写回内核
- ABI 标识版本改为字符串 semver 与核心 Version 对齐(ABIVersion="0.9.0")，
C 层协商用派生整数 CABINum=900(major*100+minor)，不再使用独立数字编码
- version_min 保证 v0.8.x(800) 旧插件向后兼容可加载
- 修复工具循环 zen 兼容补位误伤首轮 system 上下文(仅尾部为 assistant/tool 时补位)
- 更新 README 项目状态说明
2026-08-15 15:38:57 +08:00
a62f5ba0fa
agentcli: Windows ConPTY 适配分支（原生实现替代剔除桩）+ cabi loader.c build tag 修复
...
- agentcli 平台无关化：plugin.go 拆为公共层 + ptyTerm 接口，新增
pty_linux.go（/dev/ptmx 原实现搬移，行为不变）与 pty_windows.go
（ConPTY 原生实现，CreatePseudoConsole + PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE
注入子进程，双管道读写/ResizePseudoConsole/GetExitCodeProcess，零第三方依赖）
- plugin_stub.go 收紧为 !linux && !windows（darwin 等仍走桩）
- plugin_test.go build tag 放宽到 linux || windows
- cabi/loader.c 补 linux || darwin build tag，修复 Windows 下
cgo 禁用时残留 C 源文件的编译错误
- 验证：Linux 全量构建+测试通过；Windows CGO 交叉编译 + go vet 全包零错误
2026-08-07 12:32:45 +08:00
bc9ef15eb0
三层回退恢复机制（L0写前留档/L1恢复梯子/L2离线回滚）+ guard 父守护
...
- L0: files 插件写受保护系统路径(/etc 等)前自动留档，AbstractBeforeWrite 到 data/file_baseline
- L1: failback 受限 worker 执行恢复梯子 probe→还原DNS/proxy→还原LLM配置+ReloadFromConfig→probe，N轮有界
- L2: tracker changeset 持久化原文 blob，guard 离线 RollbackFromDisk 回滚 agentfs；SystemSnapshot 支撑
- guard 父守护: 心跳 IPC(PING/ACK unix socket, 文件心跳回退)、失败计数、退出码协议(42/43/44)、最后手段
- 发行版路径适配: system.protected_paths/network_paths 可注入，默认面向主流 Linux
- Windows 兼容: guard.go/failback.go 加 //go:build linux, guard_windows.go 提供 no-op 桩
- 修复: guard.yaml last_resort 键冲突、changeset Content 不落盘导致离线回滚丢原文
Build 全绿, vet 干净, system/recovery/ipc/tracker 单元测试全过
2026-08-05 16:00:08 +08:00
