|
|
e8d12db871
|
fix(packaging): amd64 GUI 从未走过 electron 缓存，且空壳 node_modules 被当作已安装
干净 worktree 上打包时 GUI 被静默跳过。两个缺陷叠加，都属于「所有外层
检查都通过，只有嵌套的运行时缺失，而没有任何东西喊出来」。
## 一：electron 架构名与 Debian 架构名混用
electron 官方发布物命名用 x64/arm64，Debian 用 amd64/arm64。缓存查找
一直统一用 TAR_ARCH（amd64），于是 electron-v*-linux-x64.zip 永远命中
不到。arm64 两边恰好同名，所以上次修 arm64 GUI 架构污染（743b963）时
这个不一致没暴露。
推论：v1.0.3 的 amd64 GUI 实际是靠「回退到 host node_modules/electron/
dist」这条路组装的，不是走缓存——那条回退只在目标架构 == host 架构时
才允许，恰好成立所以没出错。干净 checkout 里没有完整 node_modules，
回退路径也没有，GUI 就消失了。
修法：单独映射 ELECTRON_ARCH（amd64→x64，arm64→arm64）。
## 二：判 node_modules 目录存在，而非判 electron 包存在
npm install 失败（离线/网络受限）会留下只有一两个条目的空壳
node_modules。原判据 [ ! -d node_modules ] 认为「已安装」，于是跳过
install → ever 读不到版本 → 缓存匹配退化到通配 → host dist 也没有 →
静默跳过 GUI。包名、目录名、变体名全部正确，只是没有 GUI。
修法：判据改为 electron/package.json 是否存在；目录在而包缺失时明确
说明「疑似上次 npm install 未完成」再重试；install 失败给出明确提示
而不是继续往下走。
顺带给 ever 加兜底：读不到已安装版本时从 package.json 的依赖声明取
数字部分（那里是 "^33.0.0" 这类范围，仅用于给缓存匹配一个提示）。
## 验证
干净 worktree（/tmp/rel104，release/v1.0.x）上重跑：
node_modules 存在但 electron 缺失（疑似上次 npm install 未完成）
electron 版本取自 package.json 依赖声明: 33.0.0（非精确）
electron runtime: electron-v33.4.11-linux-x64.zip
GUI built: build/homeagent-gui-linux-amd64 (263M, x86-64)
file -b 确认 electron 二进制为 x86-64，与目标架构一致（该硬校验由
743b963 引入，此处继续生效）。
|
2026-09-05 14:58:30 +08:00 |
|
|
|
5c214cac23
|
fix(packaging): arm64 GUI 塞了 x86-64 electron——按目标架构取运行时并强制校验
## 现象
v1.0.0 与 v1.0.1 的 arm64 full/client 包里，homed 与 waiter 都是正确的
aarch64，但 GUI 目录下的 electron 是 x86-64。实测从 gitcode 下载的
homeagent-full_1.0.1_arm64.deb：
usr/bin/homed ELF 64-bit ARM aarch64 ✓
usr/bin/waiter ELF 64-bit ARM aarch64 ✓
usr/lib/homeagent-gui/electron ELF 64-bit x86-64 ✗
在 arm64 机器上装完，双击 GUI 得到 Exec format error。
## 根因
build_gui 无条件 `cp -r "$gui_dir/node_modules/electron/dist"/*`，而那里
永远是 **host 架构**（本机 x64）。目录名 homeagent-gui-linux-arm64 只是
命名，内容从未跟着目标架构变。
这与 v1.0.0 arm64 缺 homed 是同一类错误：**产物名声称的架构与实际内容
不符**，且都因为没做交叉验证而漏过整个发布流程——包名对、目录名对、
主二进制对，只有一个嵌套的运行时是错的，没有任何一环会喊出来。
## 修法：三层取 + 一道强制校验
1. 优先从 electron 缓存取目标架构的 zip
（~/.cache/electron/<hash>/electron-v<ver>-linux-<arch>.zip）。
版本号从已安装的 node_modules/electron/package.json 读，保证运行时
与 app 依赖一致。
2. 回退到 host node_modules/electron/dist 前**先比对架构**：只有目标
架构 == host 架构才允许；否则打印缺哪个 zip、该放哪里，然后跳过 GUI。
3. 最后用 `file -b` 校验 electron 二进制的实际架构必须匹配目标架构，
不符就删掉 GUI 目录并跳过。
第 3 步是关键。前两步是「尽量拿对的」，第 3 步是「绝不发错的」——
宁可不发 GUI，也不发装了跑不起来的包。`GUI built:` 日志行也加上架构
标注，日常构建就能看见。
## 验证
下载 arm64 electron 运行时（electron-v33.4.11-linux-arm64.zip，106MB，
unzip -t 无错，解出的 electron 确认为 ARM aarch64）放入缓存后重打包，
三个 arm64 deb 实测：
server homed=aarch64 waiter=aarch64
full homed=aarch64 waiter=aarch64 electron=aarch64
client waiter=aarch64 electron=aarch64
amd64 对照 electron=x86-64
arm64 tar.gz 从 120M 涨到 125M，也印证运行时换成了正确架构。
|
2026-09-04 20:12:35 +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 |
|
|
|
93efb1773f
|
打包: 直接使用仓内 third_party/homeagent-sdk 作为 replace 目标；gitignore 忽略本地 codegraph.json
|
2026-08-03 16:56:55 +08:00 |
|
|
|
3a5a16c916
|
bump version to v0.8.0
|
2026-07-29 15:45:24 +08:00 |
|
|
|
2c5f9ff262
|
v0.7.2: 根目录清理 + Agent 心跳重构 + 内嵌 ONNX 模型
- 根目录清理: branding/docs/knowledge -> assets/, package/tools/deploy -> deploy/
- meta.go: Version 0.7.2, SDKCompatibleVersion 语义改为最高兼容
- Makefile: 版本回退 0.7.2
- registry.go: 系统提示词改用 meta.Version 格式化
- Agent 心跳: reorgGraph 拆分为三个独立循环(archive/merge/review)，各自可配间隔
- GraphDB: 新增 sentences 表 + 关系句子溯源 + ClearSentenceID + CleanupOrphanedSentences
- Knowledge: 支持词嵌入向量化器
- NLP 四阶段流水线: Parse -> Extract -> Verify -> Fuse + SentenceRef
- 移除远程 HTTP 解析器(remote_parser.go)
- 新增内嵌 ONNX 模型(vocab + dep_parser.onnx):
+build onnxruntime: 全量 ONNX Runtime 推理
!build onnxruntime: 内嵌词表规则式降级解析器
- config: core.agent.onnx_model_path 替代 dep_parser_url
|
2026-07-28 09:56:26 +08:00 |
|
