jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-27 12:53:35 +00:00
Code Issues Packages Projects Releases Wiki Activity
636 Commits 5 Branches 27 Tags
78806efa0f82819451d6e8ebe9fcf8791d2a93e7
Commit Graph

636 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
JianFeeeee
78806efa0f 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
JianFeeeee
5a889007d7 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
JianFeeeee
7212ab4aad 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
JianFeeeee
41d754334e 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
JianFeeeee
ce694bc1a1 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
JianFeeeee
81cd8231d7 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
JianFeeeee
8842d76aff 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
JianFeeeee
144564f5c2 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
JianFeeeee
9f2ec31cb0 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
JianFeeeee
6c33bfdb82 docs(sdk): 修正 ProxyReg 字段注释里的旧名（DeclareProxy→RegisterProxy） 
Rename 时漏改了字段注释。代码本身一致（proxyReg 字段 + RegisterProxy 方法），
但注释里写着一个不存在的 API 名，读者按注释找不到方法。
 2026-09-26 13:49:59 +08:00
JianFeeeee
a7fbdb3110 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
JianFeeeee
3273c507b3 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
JianFeeeee
35df6f4366 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
JianFeeeee
667b9fdc8a 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
JianFeeeee
5ebc4481b0 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
JianFeeeee
6d0c1188f6 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
JianFeeeee
125bf57cfa 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
JianFeeeee
2c810bbbce 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
JianFeeeee
5da0f8f9fb 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
JianFeeeee
a96ad9ca97 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
JianFeeeee
a781f8e1ba 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
JianFeeeee
94c74b2ee6 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
JianFeeeee
7f5bf1670f 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
JianFeeeee
5d278cffdb 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
JianFeeeee
1e58af79d3 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
JianFeeeee
4e40597954 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
JianFeeeee
241f5fac04 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
JianFeeeee
a006237105 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
JianFeeeee
84d2d7c313 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
JianFeeeee
4340232bb0 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
JianFeeeee
84c7559b0e 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
JianFeeeee
7a1322c97f 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
JianFeeeee
7748ec450e 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
JianFeeeee
4d3962a845 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
JianFeeeee
d9f60bcd68 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
JianFeeeee
8070844fe9 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
JianFeeeee
cbe024f6a6 docs(plan): 两条端口/限流 flaky 已修（17e7094），标记关闭 2026-09-25 17:57:26 +08:00
JianFeeeee
17e7094967 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
JianFeeeee
10a8d04deb 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
JianFeeeee
b4fb254bf5 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
JianFeeeee
7799ca4559 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
JianFeeeee
5ccdf24f18 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
JianFeeeee
7351c6ca2e 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
JianFeeeee
b6027f3ff8 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
JianFeeeee
39a0c626b6 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
JianFeeeee
0ca1b96cd8 chore: 忽略 SDK 文档站的主题覆盖目录 
上一批漏了 overrides/（只覆盖 footer.html 以补备案号）。它与 docs/、
mkdocs.yml 同属文档站，核心仓不应跟踪——规则漏一条就会在 git status 里
冒出来，正是之前 example/ 那类问题的来源。
 2026-09-24 13:31:39 +08:00
JianFeeeee
a2cba0ceb1 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
JianFeeeee
4f3de61d8f 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
JianFeeeee
11144c62b5 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
JianFeeeee
d05161ac8d fix(plugin): 退避注释里无实测支撑的「感知不到工具缺席」 
`scheduleProcRestart` 的注释写：

    线性退避：1 次→1s，2 次→2s，3 次→3s。崩溃循环时不至于打满 CPU，
    又足够快到用户感知不到工具缺席。

前半句是事实（退避确实只为防崩溃循环打满 CPU），后半句是主观断言：
首次重启就要等 1s，这 1s 内该插件的工具是缺席的、调用会直接报错。
「用户感知不到」既无实测支撑，也会让读代码的人误以为是无感恢复。

这正是另一处文档（README「崩溃到恢复 <1s」）同源的问题 ——
实测退避为 1s/2s/3s，故 <1s 从未成立（`procRestartBackoff = time.Second`
由 02cc74c 引入，且该提交是 v1.0.0 的祖先）。

改为写明真实代价与插件侧的正确做法（在 OnStart 里自建重连与状态重建），
与 SDK 仓 README 刚补的说明保持一致。
 2026-09-21 10:34:41 +08:00