|
|
4f0a6e6097
|
fix(homeagent): 构建不许弄脏源码树 —— hmapdev 会重写 plugin.json，构建后还原并出声
实测：`hmapdev build` 会重写受版本管理的 `plugin.json`（只吃掉了文件末尾换行）。
"构建把树弄脏"这件事在 electron 那边刚定过规矩（脏树产物不得自称发布候选），
所以这里同样处理：构建前留快照，构建后若被改写就还原 + 打印一行说明
（不静默还原 —— 下一个人要知道这条工具会动源码）。
验证：`bash build.sh`（HOMEAGENT_SDK_DIR=…/sdk/v1.3.0）产出 build/plugin.bin（9018271 字节），
构建后 `git status plugins/homeagent-mail-bridge/` 只剩我自己改的 build.sh。
|
2026-09-14 16:41:54 +08:00 |
|
|
|
7e696f9a8c
|
fix(homeagent): 撤回"另一条 SDK 血脉"的错误结论；build.sh 不再猜路径；清单判据改成一致性口径
pi 用只读文件系统逐条反驳了 357662e 的根因，三条我都验证并接受：
1. **"内核链 0.9.x 血脉"不成立 —— 那是我的搜索顺序造出来的事实。**
本机有 6+ 份 `third_party/homeagent-sdk` checkout：
/root/ha-test/…（0.9.0，C-ABI 时代，无 plugin.bin 支持）
/var/tmp/rel-1.3.12/…、/var/tmp/rel-1.3.11/…（1.3.0）
/var/tmp/release-main/…、/var/tmp/clean-check/…、/var/tmp/homed-p3/…（1.2.0）
而 build.sh 第一版按候选根目录**第一个命中就算**，命中的正是 ha-test 那份老 checkout。
内核自己用的是 1.3.0 那份，与钉子 `sdk/v1.3.0`、与 `<SDK_ROOT>/current` **一致**。
两条教训写进注释了：别用"第一个存在的路径"当权威来源；别把模块版本字符串当身份
（`replace => local (devel)` 时它只是 require 行的残留）。
2. **"API 不兼容"也是同一个错造成的。** 换成正确的 SDK 之后：
HOMEAGENT_SDK_DIR=/root/.homeagent/hmapdev/sdk/v1.3.0 bash build.sh
→ hmapdev build 成功，产出 build/plugin.bin（9018271 字节）
也就是说**这个插件在本机编得出来**，先前的 `SettingsAPI.DataDir` 报错是拿老 checkout 编的产物。
3. **判据把能工作的配置判红**（pi §2）：第 4 步原先硬校验"产物 SDK 模块版本 == 内核模块版本"，
而生产上能跑的组合恰恰是"内核 + v1.3.0 编的插件"。已删掉这个相等性判据：
SDK 源码**只认显式指定**（HOMEAGENT_SDK_DIR），不猜、不试探；
内核那条 dep/=> 只作为**提示**打印（并且按模块名精确联接、只接受紧跟 SDK dep 行的 `=>`，
不再取"输出里第一个 =>"）；身份改记 **realpath + 内容哈希**；
`meta.Version` 读取先剥注释（注释里的 `Version = "9.9.9"` 不再能赢）。
真正的不变量是 **wire 协议 protocol=2 + 一次真实握手**，写在脚本末尾（部署后回看日志）。
4. **清单判据改成一致性口径**（pi §5）：不再"禁止 sdk 字段"——那会把正在工作的那份清单
（/home/newqqagent/plugins/homeagent-mail-bridge/plugin.json 声明 sdk=1.3.0，正是 08:30
那次恢复的处置动作）判红，而我没有"内核不读该字段"的证据。现在：可以不声明；
声明了就必须与构建机指针一致。
|
2026-09-14 16:38:28 +08:00 |
|
|
|
357662ed08
|
fix(homeagent): 不再把 SDK 版本钉在源码里；构建期按内核的依赖表校验对齐
崩溃循环的根因不是"忘了重编"，是**把 SDK 版本钉死**：
- `plugin.json`/`plg.json` 写死 `"sdk": "1.3.0"`（本机已装 21 个插件里只有 3 个声明该字段）；
- `go.mod` 的 replace 指向 `/root/.homeagent/hmapdev/sdk/v1.3.0`（绝对路径 + 具体版本目录）。
于是"照原样重编"只会再造一个装上去就崩的包。实测本机内核链的是**另一条 SDK 血脉**：
$ go version -m /usr/local/bin/homed
dep gitcode.com/JianFeeeee/homeagent-sdk v0.9.2
=> ./third_party/homeagent-sdk (devel)
所以判据改成**两个二进制的依赖表一致**，而不是"版本号看起来像"：
- `build.sh`：读内核的 SDK 依赖（`go version -m`）→ 据此解析 SDK 源码目录 →
用 `-modfile` 临时替换（不改动受版本管理的 go.mod）→ 构建 → **回头验产物**：
产物与内核链的 SDK 版本不一致就报错退出，绝不产出"装上去就崩"的包。
- `manifest_sdk_test.go`：① 清单不许写死 `sdk`；② go.mod 的钉子不得偏离构建机指针
（取不到基准就红，不许默默放过）；③ `build.sh` 必须在（它是与内核对齐的硬校验点）。
三条都做过变异验证（写死 sdk / 钉子漂到 v1.2.0 / 删掉 build.sh → 各自红）。
顺带查出一个比"重编"更根本的事实：本机 `build.sh` 跑到编译就失败 ——
./plugin.go:217:18: sett.DataDir undefined (type sdk.SettingsAPI has no field or method DataDir)
即本插件源码用的是 **1.3.0 SDK 的 API**，而本机内核链的是 0.9.x 血脉：**重编解决不了**，
要么内核改成链 1.3.x 的 SDK，要么把插件移植到内核那份 SDK（这是 HomeAgent 侧的决定）。
|
2026-09-14 16:27:02 +08:00 |
|
