|
|
bd1d5fff2b
|
chore(vendor): 主仓不再跟踪 SDK 示例代码（决策 A）
## 背景
`.gitignore` 第 26-45 行早已写明「外部插件与工具链维护在独立 SDK 仓
（决策 sdk_repo_only），本仓经 go.mod 的 replace 引用」，并忽略了
example/、tools/、docs/、site_build/、package/、scripts/。
但有 29 个文件**早于该规则**被跟踪，靠「已跟踪文件不受 .gitignore
影响」留着，注释还特意写了「这是有意的，不要『修』」。
本轮修 example/bili 时踩到了：那 87 行改动先落在主仓、再手动同步到
SDK 仓 —— 同一份代码两个仓各改一遍，正是这个遗留结构的成本。
## 核实：主仓到底需要什么
- 主仓 Go 代码只 import 两个包：`homeagent-sdk/sdk`（插件入口）、
`homeagent-sdk/meta`（版本号）
- `remotedevice/` 是 C 库，主仓 C 侧明确「不链接任何外部库」，
只有注释里提到它
- `tools/hmapdev/yaegi` 的 import 出现在 **SDK 仓自己的文件之间**
（yaegi/interp.go → yaegi/mocksdk），不是主仓依赖；
且 tools/ 本就在 .gitignore 里，从未被跟踪
所以 29 个文件全部可以删。实际仓库负担也只有 42 个文件 / 0.6MB
（工作树里那 971MB 绝大部分是未跟踪的构建产物，不是仓库体积）。
## 改动
- 删 21 个 example/ 文件（10 个示例的 plg.json + plugin.go + qq/plugin_test.go）
- 删 8 个 remotedevice/ C 文件
- 工作树里一并清掉（不受跟踪的构建产物顺带回收）
构建与全量测试均通过。
## 判据：3 条 + 变异（internal/meta/vendored_sdk_test.go）
- TestVendoredSDKHasNoExampleOrRemotedevice：防止示例代码被重新提交进来
- TestVendoredSDKKeepsRequiredPackages：**反向**保护，防止为省事把
sdk/ 与 meta/ 也删掉（上一条只防"多了"，删过头要靠这条）
- TestGoModStillReplacesSDKToVendoredPath：决策 A 依赖 replace 指向 vendored 路径
★ 判据自己踩了两个坑，都靠实跑抓出来：
1. `git ls-files` 的路径参数**相对当前目录**解析，而测试跑在
internal/meta/ 下 ⇒ 就地执行返回空，表现为「必需包全都不在」的假红。
改用 `git -C <仓库根>`。
2. 把 tools/hmapdev/yaegi 当成主仓依赖写进必需清单 ⇒ 又一次假红。
根因是把 SDK 内部的引用误当成主仓依赖（它本就在 .gitignore 里）。
变异验证：塞一个 example 文件进版本控制 → 判红。
|
2026-09-26 17:18:41 +08:00 |
|
|
|
44cc824b28
|
chore(sdk-mirror): a2a 1.3.0→1.3.1、acp 1.2.0→1.2.1 的 plg.json 跟上 SDK 仓
SDK 仓 11303e3 升了两个示例插件的版本（补 RegisterInputChannel 后按插件自身语义升 patch），
外层仓镜像里这两个 plg.json 忘了同步 —— 镜像与源头不一致会让"装的是哪个版本"对不上账。
|
2026-09-13 14:30:56 +08:00 |
|
|
|
ae9b06976c
|
chore(sdk-mirror): 同步 SDK 仓 4cb3a0b —— 通道方向契约 + 示例插件显式登记 inputch
镜像文件（外层仓按策略只跟这些；`example/` 被 .gitignore 忽略，已跟踪文件用 -f 提交）：
- `sdk/plugin.go`：RegisterInputChannel/RegisterOutputChannel 的方向契约文档
（入站 vs 出站分开登记；用哪个通道名注入就要登记哪个）。
- `example/{a2a,acp,browser,memo,calendar,rss}/plugin.go`：补 RegisterInputChannel。
未镜像（外层 .gitignore 忽略，按策略不入镜像）：
`README.md`（README*）、`tools/hmapdev/{templates.go,cmd_sdk.go,cmd_build.go}`（tools/）
—— 即"模板工程"与"`sdk install --from`"两项改动只存在于 SDK 仓，详见该仓提交 4cb3a0b。
注：这 6 个示例此前未 gofmt（`example/*` 共有 9 个未格式化文件），
本次改动文件被 gofmt 顺带规范，diff 里含格式噪音（calendar 49 行、a2a 33 行）。
|
2026-09-13 11:38:10 +08:00 |
|
|
|
5fb15f5045
|
feat(a2a/acp): 会话历史查询 session.get + 客户端 session_id 透传
a2a:
- tasks.get 从空壳改为按 session_id 返回会话内近 N 条消息（默认10）；
新增 session.get 别名同语义
- a2a_query（出站）接受 session_id 参数透传给目标 agent，
响应回显 session_id + 延续提示
- A2AParams/A2AResult 加 session_id 字段；工具描述补说明
acp:
- 新增 JSON-RPC method session/get：按 session_id 返回近 N 条消息
- acp_query（出站）接受 session_id 透传给 session/new，
响应回显 + 延续提示
- params 结构体加 limit 字段
端到端验证（回环本机）：
a2a tasks.send→建会话；session.get→返回[user/agent]交替消息列表
同 session 第二轮延续上下文正确（记数字→答数字）
acp session/new + session/get 同样通过
|
2026-08-26 19:30:32 +08:00 |
|
|
|
14aa0c880b
|
fix(a2a/acp): 回复闭环 + 会话延续 + 同步注入（不再抢占打断）
【问题】
1. 入站请求用 InjectInterruptText 抢占打断当前对话，立即回 202 submitted，
agent 的回复 emit 到未注册的 channel（a2a/acp）→ 请求方永远拿不到回复文本，
只能干等超时。（acp 的 session.Replying 从未被填真回复 → SSE 永远 "(未收到回复)"）
2. 无法指定/延续 session：a2a 无 session 概念；acp session/new 每次新建、
不接受调用方 session_id，多轮上下文断裂。
3. a2a/acp 通道未注册为输出设备 → emitResponse 的回复无落点，
output_list_channels 也不可见 → agent 困惑"回复该发到哪"。
【修复】
- 入站改用 SDK InjectInputSync 同步注入：阻塞等待 agent 处理完成，
直接把最终回复文本返回给 HTTP 请求方（不再回 202）。
这是 A2A/ACP 协议的合理形态——客户端控制超时，服务端同步返回。
- session 支持：a2a tasks.send 与 acp session/new 均接受 params.session_id，
指定则延续已有会话（拼上下文前缀），不指定则新建并返回 session_id。
单会话保留最多 10 轮历史防膨胀；30min GC 清理 2h 未用会话。
- a2a/acp 注册为输出通道（RegisterOutputChannel）：回复有落点，
output_list_channels 可见，agent 可主动 output_send 推消息。
- 注入提示词明确"直接以文本回复即可，无需调 output_send"——
agent 不再把回复走 queued 入队而返回干净文本。
端到端验证：
单轮：status=completed, reply=真实回复文本（非 submitted）
多轮：同 session_id 第二轮准确复述第一轮问题（上下文生效）
a2a v1.2.0 / acp v1.1.0 安装 config_kept=true
|
2026-08-26 19:16:46 +08:00 |
|
|
|
75447aa7f8
|
fix(plugins): 全插件审查修复（qq/a2a/memo/calendar/rss/browser）
17 个生产插件全量审查：编译/vet 全过、无硬编码密钥、内核
executeToolCall 有 panic recover + 超时兜底。发现并修复：
P1 qq: downloadURL 裸 http.Get 无超时 → 120s client（挂起泄漏）
P2 a2a: inbound http.Server 无超时 → Read 30s/Write 120s/Idle 60s
（慢速连接占用 goroutine）
P5 memo/calendar/rss: 数据持久化直写 → atomicWriteJSON temp+rename
（崩溃截断 JSON 丢全部数据）
P6 qq: 3 处后台 goroutine（已读标记/rcon转发/下载任务）加 recover
（工具调用外 panic 会带崩 homed 进程）
P7 browser: dump-dom failback Kill 后补 wait 回收僵尸进程
已知可接受项：bili output_dir 用户可控（本机单用户）、recoverydiag
db_path 可读任意 sqlite（诊断工具固有权限，argv 传参无注入）。
全部经 plugindev 重打包 v+0.1 安装验证 config_kept=true。
|
2026-08-26 16:46:06 +08:00 |
|
