JianFeeeee
83a5787ac9
## 现象
`go test ./...`（在该包内）红：
--- FAIL: TestSDKPinMatchesBuildMachinePointer
go.mod 的 SDK 钉子偏离了构建机指针：
钉子: /root/.homeagent/hmapdev/sdk/v1.3.0
指针: /root/.homeagent/hmapdev/sdk/v1.4.0
后果不是「编译不过」，是**照原样重编会再造一个旧版本插件**：
内核升级后装上去启动即崩、崩溃循环、要人介入（2026-09-14 的形状）。
## 为什么这个包的红一直没被发现
`plugins/homeagent-mail-bridge/` 有**独立 go.mod** ⇒ 不在主 module 内
⇒ 仓库根的 `cd server && go test ./...` **覆盖不到它**。
（主 module 覆盖率实测：`go list ./... | grep -c homeagent` → **0**。）
## 改法
`go.mod` 的 replace 改成指针指向的目录（判据给出的改法，一行），
然后按 `build.sh` 重编并部署。
## 验证（判据自己写明的口径：不是版本号相等，是建链成功）
- 判据：✅ 过
- 重编：`hmapdev build` 成功，`SDK=v1.4.0 hash=ba5cece0ca8a52ad version=1.4.0`
- 部署：`install -m 0755` 原子替换 + 留档 `plugin.bin.bak-20260928-093600`
- **建链**：内核日志 `homeagent-mail-bridge` 经 proc 通道加载、
`protocol=2 sdk=1.4.0`、工具全部注册（`loaded: homeagent-mail-bridge`）
- **端到端**：真发一封 `.new` → 20s 内回信「SDK v1.4.0 重建后正常」
★ 顺带记一条：build.sh 自己注明 `go build ./...` 会报
`function main is undeclared` —— 那是正常的（入口由 hmapdev 包装），
真正的编译在 hmapdev 那一步。拿 `go build` 当"能不能编"的判据会误报。
21 lines
1.0 KiB
Modula-2
21 lines
1.0 KiB
Modula-2
module homeagent-mail-bridge
|
||
|
||
go 1.25.0
|
||
|
||
require gitcode.com/JianFeeeee/homeagent-sdk v1.3.0
|
||
|
||
|
||
|
||
replace gitcode.com/JianFeeeee/homeagent-sdk => /root/.homeagent/hmapdev/sdk/v1.4.0
|
||
|
||
// 这个 replace 是**构建机的 SDK 指针**，不是源码常量：它跟着
|
||
// `<SDK_ROOT>/current` 走（判据 TestSDKPinMatchesBuildMachinePointer 管）。
|
||
//
|
||
// 更正（2026-09-14 晚，pi 用只读文件系统逐条反驳）：我先前写的
|
||
// "内核链另一条 SDK 血脉（0.9.x）"是**错的** —— 本机有 6+ 份
|
||
// `third_party/homeagent-sdk` checkout，而 build.sh 当时按候选根目录"第一个命中就算"，
|
||
// 命中的是 /root/ha-test 那份 C-ABI 时代的老 checkout。内核自己用的是 1.3.0 那份，
|
||
// 与这里的钉子**一致**。两点教训：① 别用"第一个存在的路径"当权威来源；
|
||
// ② 别把模块版本字符串当身份（`replace => local (devel)` 时它只是 require 行的残留）。
|
||
// 真正的不变量是 wire 协议（protocol=2）+ 一次真实握手，不是版本号相等。
|