2 Commits

Author	SHA1	Message	Date
JianFeeeee	ba281a855a	feat(update): 差分 OTA + 安装形态分派 + 事件总线统一受安全监控 ... 三条主线，由 e2e 实测驱动。 ## 一、差分 OTA（internal/update/delta.go） 实测：改一行逻辑，88MB 的二进制逐字节只差 80 字节，而 OTA 一直下整包。 用 rsync 族的滚动哈希块匹配（4KB 粒度），不是 bsdiff —— 后者需 17×N 峰值内存（88MB → 1.5GB），而升级恰可能发生在内存紧张时。 真实二进制实测：88,036,728 字节 → 补丁 77,316 字节（0.088%）。 三道闸：应用前验旧文件 sha256（错基线会静默产出垃圾）、应用后验结果 sha256、COPY/LITERAL 越界防护。任何失败**退回整包**，不向上抛 —— 差分是优化，不是可用性前提。 接入：Source.Resolve 优先试 delta；CheckRelease 按 -from-<commit8>.delta 匹配（不猜基线）；CLI 新增 -make-delta；打包脚本 build_delta（需 PREVIOUS_HOMED），delta 进 SHA256SUMS。 ## 二、安装形态分派（internal/update/install.go + channel.go） 内核对「能不能自己升级」此前只有一个答案：直接替换二进制。而 deb/rpm 形态下那样做会让 dpkg/rpm 数据库与实际内容不一致（下次 apt upgrade 覆盖回旧版，或 dpkg 拒绝后续升级）。 新增探测：deb/rpm/tar/container/source 五类形态 + 变体（full/server/ client/toolchain）+ 目录写权限。判据全部来自可观测系统事实（dpkg 的 info 目录、容器标记文件），不做路径推断。 三端统一走 PlanUpgrade 分派；形态闸门放在**下载 880MB 之前**。 ## 三、事件总线统一受安全监控（internal/events + security） 用户指正：「eventbus 上所有事件都要接受安全模块的监控」。 此前 EventPolicy 只被 internal/sdk/events.go 调用，而那是四条路径中的 一条。s.Publish / s.Subscribe / s.EventBus() 拿的是裸 *events.Bus， 任何插件都能绕过策略发任意事件（含伪造内核事件）。 现在闸门在 Bus.Publish/Subscribe 本体上（Guard 接口注入，避免 events ↔ security 成环），四条路径全部覆盖。sdk.EventBus() 改返回带身份的 BusHandle。内核身份免授权，但载荷照样过凭据闸门。 白名单按主体收窄：agent_output/stage/terminal_output 只允许承载者 （webui/cli/agentcli）发布 —— 它们是内核向外的输出面，谁都能发就等于 能伪造 agent 说的话。 ## e2e 暴露并修掉的三个真实回归 [bus] subscribe denied: pluginmgr type=update_request [bus] subscribe denied: skillmgr type=skill_detected 前两个让升级请求静默丢失、职责链交接断掉。内部协作事件必须可订阅 （安全边界在发布侧，订阅只是「听得到」）。 ## 顺带的止血修复 - 回滚判据从 `--version` 改为 digest：旧内核（1.3.x 及以前）没有该 flag，而它恰是最常见的回滚目标 —— 原逻辑让「从旧版升级失败」永久 无法回滚。 - CopyFile 补 fsync（替换 homed 本体时掉电会留半截文件）。 - restore 完整还原才清 marker（原先先清再还原，还原失败就失去第二次 自愈机会）。 - 回滚时移除升级中新增的 depgraph（否则「旧 homed + 新 depgraph」 会因 digest 不匹配崩溃循环）。 - homed-upgrade 不再硬编码 systemctl restart（丢 guard 状态、unit 名 漂移）；改用内核已有的 restartCh → exit 42 语义。 - homed-upgrade 不再用 CGO_ENABLED=0 编却依赖 go-sqlite3（stub 下 静默失效，该路径从未工作过）；改用 internal/config。 - 服务单元补 User=hologramagent + 三条安装路径补建用户（此前发行物里 完全没有落实降权）。 - rpm 的 fpm 调用补 --after-install（此前 rpm 装完根本不建用户）。 ## 判据 新增 30 条：差分 8（往返/压缩比/错基线/截断/篡改/边界）、通道 8、 执行器 6、事件闸门 8、按主体授权 8。全仓 go test ./... 0 失败。	2026-10-29 09:54:55 +08:00
JianFeeeee	4af07d08fe	fix(memory,llm): L2 预填充并入召回主路 + 回退换 provider 时换 model（视觉失效真因） ... ## 1. L2（冷上下文）预填充此前只走「注入文本」，等于没有 设计：prune 与 recall 是一对 —— 工具声明 ContextPolicy=prune + RecallPolicy=auto 时，工具输出既触发裁剪、也触发预填充（memoryPass → recallTextFor）。 但 L2 那一路只写在 buildSystemPrompt 里，query 用的是**注入文本**； QQ 注入的是「来自「X」的私聊消息(message_id=…)，先用 qq_get_message 取正文」， 与用户真正说的话毫无相似度 ⇒ 冷上下文预填充恒为空。 （现场：头天晚上讲的冷笑话，第二天早上完全唤不回；14 小时里 memory recall (input…) 只有 5 次、且 query 是元信息。） 改法：把 L2 检索并入 buildMemoryContext —— 输入路用输入文本、工具路用工具正文， 两条路共用同一次召回与预算；buildSystemPrompt 里那份重复注入删掉。 中断消息仍然 NoMemory + RecallPolicy=none（不裁剪、不召回、不进记忆）， 这是设计要求，未改动。 ## 2. 回退换 provider 时必须换 model（视觉失效的真因） 现场日志： deepseek 402 Insufficient Balance → 回退 llmsproxy，但 req 仍带 model=「deepseek-flash」 → llmsproxy 403 model_not_allowed → llmsproxy 被整源标记 unavailable（冷却） → 视觉回退 resolveModalFallback 跳过它 ⇒「配置了视觉却说没有视觉」 两处修正： · 每个 provider 用自己的 model 发请求（model 是 provider 的属性） · 403 区分「模型不被该 key 允许」与「凭证失效」：前者只否一个 model， provider 仍可用于其他 model 与视觉回退 判据：internal/agent/core/provider_model_fallback_test.go	2026-10-27 11:49:26 +08:00