jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-11-01 14:57:38 +00:00
Code Issues Packages Projects Releases Wiki Activity
880 Commits 5 Branches 29 Tags
aafd971b7a751d8a0aa2d7ad2e7b8449da2e8971
Commit Graph

880 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
JianFeeeee
aafd971b7a fix(docs): PLUGIN_DEV 与 SKILL 的 module 路径 host 改为 github 2026-10-21 19:42:28 +08:00
JianFeeeee
ee2b7d7bac fix(docs,site): 回退上一批错误口径 —— SDK 仓名与站点域名改回实际活链 
上一批（37b8c26 / 228fae2）把文档与站点里的 SDK 仓名统一改成了
`JianFeeeee/HologramAgent-sdk`、把站点域名改成了 `*.hologramagent.jianfgit.xyz`，
前提「本机无外网、无法验证」是错的。实测外网通畅，两处改动都是真实死链，本批全部回退。

## 一、SDK 仓名 HologramAgent-sdk → homeagentsdk（104 处）

| 文件 | 处数 |
|---|---|
| site/index.html | 23 |
| README.md | 7 |
| README_EN.md | 7 |
| assets/docs/zh/PLUGIN_DEV.md | 29 |
| assets/docs/en/PLUGIN_DEV.md | 29 |
| assets/docs/zh/OVERVIEW.md | 2 |
| assets/docs/en/OVERVIEW.md | 2 |
| docs/git-branching.md | 2 |
| docs/zh/ci-cd-runbook.md | 3 |
| **合计** | **104** |

含 `.git` 形态与 `cd homeagentsdk` 目录名。PLUGIN_DEV.md 里原本就是
`import "github.com/JianFeeeee/homeagentsdk/sdk"` 的两处示例（zh 253/448、en 255/455）
与 6a 前基线逐行 diff 无差异，未被改动成第三种形态。

## 二、站点域名 hologramagent.jianfgit.xyz → homeagent.jianfgit.xyz（15 处）

| 文件 | 处数 |
|---|---|
| README.md | 4 |
| README_EN.md | 4 |
| docs/zh/deploy-runbook.md | 2 |
| deploy/scripts/deploy-sdk-site.sh | 5 |
| **合计** | **15** |

deploy-sdk-site.sh 只改探活/注释里的域名，nginx 语义（SNI 透传、
server_name → root 的链路描述）未变。

## 三、明确未动

- go.mod 两行、third_party/homeagent-sdk 路径、internal/**/*.go 的 import —— 零改动
- deploy/scripts/upload_assets.py:23 默认值 `JianFeeeee/HologramAgent` 保留（主仓确已改名）
- cmd/gui/package.json homepage 保留 HologramAgent（GitHub 200）
- docs/git-branching.md:420 的 GITCODE_REPO 改为 `JianFeeeee/homeagent-sdk`：
  gitcode 上只有 homeagent-sdk(200) 与 HomeAgent(200)，HologramAgent-sdk 与
  HologramAgent 在 gitcode 均为 404

## 四、实测证据（curl -L -o /dev/null -m 25 -w '%{http_code}'）

GitHub 侧（经 http://127.0.0.1:7890 出口）：

    200  https://github.com/JianFeeeee/homeagentsdk          ← 回退目标，活链
    200  https://github.com/JianFeeeee/HologramAgent         ← 主仓，确已改名
    404  https://github.com/JianFeeeee/HologramAgent-sdk     ← 上一批写成这个，死链
    404  https://github.com/JianFeeeee/homeagent-sdk         ← 不是这个名字
    200  https://github.com/JianFeeeee/HomeAgent             ← 301 → HologramAgent

深链抽查（回退后全部 200）：

    200  .../homeagentsdk/tree/main/example/weather
    200  .../homeagentsdk/tree/main/example/plugindev
    200  .../homeagentsdk/tree/main/example/luademo
    200  .../homeagentsdk/blob/main/LICENSE
    200  .../homeagentsdk/tree/v1.1.0

站点域名（直连，不走代理）：

    200  https://sdk.homeagent.jianfgit.xyz/                ← 回退目标，已部署
    200  https://introduce.homeagent.jianfgit.xyz/
    200  https://sdk.homeagent.jianfgit.xyz/llms.txt
    200  https://sdk.homeagent.jianfgit.xyz/llms-full.txt
    404  https://sdk.hologramagent.jianfgit.xyz/            ← 上一批写成这个，未部署

新子域 404 的原因不是网络：证书是 CN=*.jianfgit.xyz 通配符可用，
但 nginx 里没有 hologramagent 的 server_name，站点根本没部署。

gitcode 侧（决定 §三 那行的连字符形态）：

    200  https://gitcode.com/JianFeeeee/homeagent-sdk
    200  https://gitcode.com/JianFeeeee/HomeAgent
    404  https://gitcode.com/JianFeeeee/HologramAgent-sdk
    404  https://gitcode.com/JianFeeeee/HologramAgent

## 五、验收

1. 全仓 `HologramAgent-sdk` 计数 = 0（.md/.html/.py/.sh/.yml/.yaml/.txt/.json/.go/.mod/.sum）
2. 全仓 `hologramagent.jianfgit.xyz` 计数 = 0
3. site/index.html 23 条 SDK 链接全指向 homeagentsdk，0 条指向 HologramAgent-sdk
4. curl -L 三条必测均 200（见 §四）
5. `TMPDIR=/home/newqqagent/tmpbuild6 go build ./...` 退出码 0
   （/tmp 已 98% 满，用独立 TMPDIR 避开 No space left on device）
6. git status 干净；11 个改动文件全为 .md/.html/.sh，零 .go 改动
 2026-10-21 19:36:53 +08:00
JianFeeeee
228fae252d fix(docs): 回退 PLUGIN_DEV 的 SDK import 示例，并修正 upload_assets/gui homepage 的仓名 
上一批 37b8c26 把文档里 4 处 Go import 示例改成了
`github.com/JianFeeeee/HologramAgent-sdk/sdk`，但该 module 路径并不存在：
主仓 go.mod:16 仍是 `github.com/JianFeeeee/homeagentsdk v0.9.2`，:46 replace
目标未变，third_party/homeagent-sdk/go.mod 首行仍是
`module github.com/JianFeeeee/homeagentsdk`，GitHub 上 HologramAgent-sdk
与 hologramagentsdk 均 404。照着文档抄这行 import 会直接 module not found，
比不改更坏。本次回退成真实可编译的 homeagentsdk。

改动：
- assets/docs/{zh,en}/PLUGIN_DEV.md 各 2 处（zh:253、448；en:255、455）
  import 路径回退为 github.com/JianFeeeee/homeagentsdk/sdk。该行附近未加任何
  「已改名」说明——等 SDK 仓真改名、主仓 go.mod 与第三方 module 一起改时
  再统一处理，属另一批。全仓已无 HologramAgent-sdk/sdk 形态。
- deploy/scripts/upload_assets.py:8、:23 默认目标仓
  JianFeeeee/HomeAgent → JianFeeeee/HologramAgent（主仓确已改名，HomeAgent
  在 GitHub 上 301）。:8 括号里「SDK 仓传 JianFeeeee/homeagent-sdk」按要求保留。
- cmd/gui/package.json:5 homepage 元数据同步为 HologramAgent；该文件仅此
  1 行变更，name/author/description 等其它字段未动。

保留不动（已获确认属正确形态）：
- go.mod 两行与 deploy/packaging/package-linux.sh 六处 homeagentsdk
  （必须与 go.mod 逐字一致）
- internal/**/*.go 的 74 处真实依赖 import
- deploy/packaging/packaging_test.go:99,101 对 gitcode.com/JianFeeeee/HomeAgent
  的反向断言（它断言 build.sh 不得使用历史路径）
- internal/plugins/webui 三处注释里的 homeagent.jianfgit.xyz（历史实测记录）
- cd HologramAgent-sdk / clone ...HologramAgent-sdk.git（操作指令目录名与 URL，
  非 import 路径）

判据：7 条正向（含「文档 import 路径必须与 go.mod 的 SDK module 同源」）；
变异 4 次均按预期报红——分别还原 zh:253 import、upload_assets.py:23 默认值、
gui homepage、以及把 packaging_test.go 反向断言那两行也改名。
go build ./... 通过，go test ./deploy/packaging/ 通过。
 2026-10-21 19:25:05 +08:00
JianFeeeee
37b8c26675 refactor(docs): 批6a 清理介绍站与文档的旧仓名/旧链接 
改名 HomeAgent → HologramAgent 后，介绍站与仓内文档仍指向旧仓地址、旧站点
域名，点击即 404 / 落回旧站。本批只动文档与静态站，代码零改动。

映射（严格按主管给定的唯一权威口径）：
- github.com/JianFeeeee/HomeAgent → .../HologramAgent（含 /blob /releases /tree）
- github.com/JianFeeeee/homeagentsdk → .../HologramAgent-sdk
- introduce.homeagent.jianfgit.xyz → introduce.hologramagent.jianfgit.xyz
- sdk.homeagent.jianfgit.xyz → sdk.hologramagent.jianfgit.xyz
- 品牌名/链接文本 homeagent-sdk → HologramAgent-sdk（含 `cd homeagent-sdk`
  克隆后的本地目录名，跟随新仓名）

改动面（12 个文件，138 行，纯替换无逻辑变更）：
- site/index.html 36 处：13 处主仓链接 + 23 处 SDK 仓链接（22 个 example/
  与 LICENSE、仓库首页）
- README.md / README_EN.md 各 12 处（9 处 URL + 3 处链接文本）
- assets/docs/{zh,en}/PLUGIN_DEV.md 各 34 处、OVERVIEW.md 各 2 处
- docs/zh/ci-cd-runbook.md 9 处、docs/zh/deploy-runbook.md 2 处（站点域名）
- deploy/scripts/deploy-sdk-site.sh 5 处（注释里的 server_name + 3 处 curl
  探活地址，否则改完站脚本仍在验旧域名）
- docs/git-branching.md 2 处、assets/skills/commondev-discipline/SKILL.md 1 处
  （gitcode module 路径）

刻意不动（动了会坏）：
- 真实目录 third_party/homeagent-sdk（只改 URL 里的 homeagentsdk）
- go.mod 的 module / replace、所有 .go import（module 仍是
  github.com/JianFeeeee/HologramAgent，SDK 仍 homeagentsdk）
- deploy/packaging/package-linux.sh 里的 `replace github.com/JianFeeeee/
  homeagentsdk` 与 clone URL —— 它必须与未改动的 go.mod 逐字一致，属代码非文档
- 数据目录 ~/.homeagent、二进制 homed、产物名 hologramagent_*、
  插件名 homeagent-mail-bridge
- systemd 相关行（homeagent.service / systemctl / journalctl）—— 待上级确认，
  本批不动，清单见汇报
- docs/api/*.md（首行「请勿手改」，生成型）

判据（含变异验证）：
- 三条旧串 grep 全仓清零；third_party/homeagent-sdk 目录仍在
- site/index.html 标签配平（HEAD/WORK 双跑）+ section 数 13→13 未减
- 变异：分别还原 deploy-sdk-site.sh:206、site/index.html:3041、README.md:243、
  ci-cd-runbook.md:11 各一处，以及删一个 </footer>，判据均按预期报红
- go build ./... 通过（仅把 TMPDIR 指到 /var/tmp 规避 /tmp tmpfs 满，仓内文件无关）

未执行任何线上动作：不 push、不开 PR、不重命名 GitHub 仓。注意 SDK 仓在
GitHub 侧目前仍叫 homeagentsdk，本批把文档指向 HologramAgent-sdk 是「改名
在路上」，该仓改名完成前这批 SDK 链接会 404。
 2026-10-21 19:22:02 +08:00
JianFeeeee
dfc4e16e65 Merge pull request #16 from JianFeeeee/refactor/rename-batch4b-ci-mirror 
refactor(ci): 批4b 清理 CI/镜像链路旧仓名，并加 gitcode 目标仓前置检查
 2026-10-21 19:09:45 +08:00
commondev
a7331251ab refactor(ci): 批4b 清理 CI/镜像链路旧仓名，并加 gitcode 目标仓前置检查 
改名 HomeAgent → HologramAgent 后，CI 里仍写死旧仓库路径，且镜像链路
一旦目标仓缺失只会得到 git 的原始报错，看不出「仓没建」。

改动：
- ci.yml: sync-gitcode-main 推 main 目标改为 JianFeeeee/HologramAgent，
  并在 push 前新增「前置检查 gitcode 目标仓是否存在」独立 step。
- release.yml: sync-gitcode 的 push / releases API / GITCODE_REPO 统一
  走 GC_REPO=JianFeeeee/HologramAgent 变量；同样新增前置检查 step。

前置检查语义：
- GITCODE_TOKEN 未配置 → 沿用既有「跳过镜像同步」（可选项，不算错误）；
- token 有但目标仓不存在 → 打印要建的仓与地址，exit 1 硬失败；
- 探测与 push 用同一 URL、同一凭据（git ls-remote），贴近真实失败面；
- 日志对 URL userinfo 做结构脱敏，避免 token 被 git 报错带出。

gitcode 报错文本按 2026-10 实测校准：目标仓不存在时返回
  remote: <CH...> The project you were looking for could not be found.
  fatal: ... The requested URL returned error: 403
是 "could not be found" + 403，不是 GitHub 那种 404 / Repository not found，
故分类同时匹配这两种形态（401/403 单列一支，提示仓未建或 token 无权限）。

未执行任何线上动作：不重命名 GitHub 仓、不建 gitcode 镜像仓、不 push/开 PR/打 tag。
 2026-10-21 18:11:59 +08:00
JianFeeeee
5d7e26edf2 Merge pull request #15 from JianFeeeee/refactor/rename-batch5-docs-site 
改名批 5-a：仓库内文档与站点改名 + 修 make install 真破损
 2026-10-21 17:11:09 +08:00
JianFeeeee
9bc2687972 refactor(docs): 补正 git-branching 主仓名，接上批 5-a 改名 
批 5-a 复核发现 docs/git-branching.md 两处仍以 TrueAgent 指代主仓，漏改。
只动这两行，`third_party/homeagent-sdk` 是 SDK 仓目录名，原样保留。

- 第 4 行：`本仓（TrueAgent/HomeAgent）` → `本仓（HologramAgent）`
  （整段收敛成一个名字，不再留 "旧目录名/旧展示名" 的复合写法）
- 第 183 行：`### 主仓（TrueAgent）` → `### 主仓（HologramAgent）`

TrueAgent 在本仓其余 6 个文件里都是磁盘上真实存在的路径 /home/program/TrueAgent
或本机工作副本名，一行未动：deploy/systemd/embed-sidecar.service、
assets/skills/commondev-discipline/SKILL.md、docs/zh/commondev-design.md、
docs/zh/commondev-agent-runtime-design.md、internal/security/store_test.go、site/README.md。

判据口径同步收紧（判据 2）：
- 豁免只允许三类并逐条打印 —— A 仓库 URL（批 4-b）、B 本机真实路径、C 既有契约
  （HOMEAGENT_*、homeagent-sdk/homeagentsdk、homeagent.service、插件名）；
  ~/.homeagent 单列为 D 遗留项（须与 cmd/ 侧同改）
- 原 `TrueAgent/HomeAgent` 常驻豁免已撤销（该串已不存在，留着会掩盖它复活）
- 新增 TrueAgent 守卫：git-branching 内 TrueAgent 必须 0；全仓 TrueAgent 逐行集合
  必须 == base e3584bb 集合减去这两行，命中文件数 7→6
- 新增安装路径断言：/usr/lib、/usr/share/doc、/etc、/var/lib 旧值必须 0

自证：docs/git-branching.md 里 HologramAgent 3 处、TrueAgent 0 处；全仓 TrueAgent
文件数 7→6，逐行与基线 diff 仅这两行。四条判据正向全绿，13 条变异全部被咬住。
 2026-10-21 17:07:46 +08:00
JianFeeeee
931c803421 refactor(docs): 核心仓文档与介绍站展示名改名为 HologramAgent 
只改仓库内文件的纯展示品牌名与已随批 2 落地的安装路径；运行时契约、仓库 URL、
域名、环境变量、可执行名、插件名一律不动。

一、纯展示名（HomeAgent → HologramAgent，共 44 处 / 18 个文件）
- README.md 4、README_EN.md 4（标题、client 变体说明、Windows 安装包名、AGPL 段）
- docs/ 8 个文件 14 处（git-branching 1、ci-cd-runbook 1、commondev-design 3、
  commondev-agent-runtime-design 4、deploy-runbook 1、legacy-issues 1、
  prod-migration-checklist 1、triple-extract-attention 2）
- assets/docs/ 6 个文件 14 处（zh/en 的 OVERVIEW 2+2、ARCHITECTURE 2+2、
  PLUGIN_DEV 3+3）
- assets/branding/mascot-xiaozhai-guide.md 2 处（身份行、标志名）
- site/index.html 6 处（title、meta description、og:title、logo alt、页头字、
  插件卡片文案 "HologramAgent 接入 AgentMail"）

二、安装路径对齐批 2 产物（共 10 处）
- /usr/lib/homeagent → /usr/lib/hologram（7 处：README 2、README_EN 2、
  multimodal-space 3）
- /usr/share/doc/homeagent → /usr/share/doc/hologramagent（3 处：README 1、
  README_EN 1、multimodal-space 1；注意 Doc 路径带 agent 后缀）
- site/index.html 的 19 处 HomeAgent 里，13 处是 github.com/JianFeeeee/HomeAgent
  仓库 URL，属红线整串保留；只改 URL 之外的展示文案（其余 13 处零改动）

三、明确不改（红线 / 一致性冲突）
- site/index.html 的 23 个 github.com/JianFeeeee/homeagentsdk 外链（21 条
  example + 2 条纯仓库），SDK 仓改名属批 4-b，一个未动
- 核心仓仓库 URL、sdk./introduce.homeagent.jianfgit.xyz 域名、HOMEAGENT_ 前缀、
  homed/waiter/hmapdev、.hmap、homeagent-mail-bridge 等插件名、third_party/、
  internal/ 与 cmd/ 全部零改动
- ~/.homeagent 路径本批保持原样：cmd/waiter/main.go:109、daemon.go:290 硬编码
  仍为 .homeagent，全仓无 .hologram 命中；照规格改文档会指向程序不用的目录，
  需与代码侧那条线一起改（遗留项，已单独上报）

判据：文档区展示名残留归零（44 文件）、红线计数与 base e3584bb 逐项相同、
三条变异均被咬住且还原后复绿。
 2026-10-21 17:00:48 +08:00
JianFeeeee
2b4b29a995 refactor(docs): 修复 make install 真破损（服务单元名与安装路径对齐批 2 产物） 
批 2 已把 deploy/homeagent.service 改名为 hologramagent.service，但 Makefile
install 目标仍引用旧文件名 —— cp 源不存在，make install 直接失败。这是本批
唯一的真破损。

- Makefile:374 cp 源 deploy/homeagent.service → deploy/hologramagent.service，
  目标单元名同步为 /etc/systemd/system/hologramagent.service
- Makefile:371 systemctl stop homeagent → hologramagent（与 374 行装出去的
  单元名逐字一致；只改一半会变成"停 A 装 B"）
- Makefile:373 /etc/homeagent /var/lib/homeagent → /etc/hologram /var/lib/hologram
- Makefile:376 安装提示语里的服务名
- Makefile:23 GUI_BINARY=homeagent-gui → hologram-gui（批 2 产物已叫 hologram-gui）
- Makefile:438 run 目标 -data /tmp/homeagent → /tmp/hologram

验证：make -n install 展开的 recipe 里 cp 源全部存在；判据 1 全绿，
变异回旧文件名必红。仅改值，未动 Makefile 结构。
 2026-10-21 17:00:24 +08:00
JianFeeeee
e3584bb9b6 Merge pull request #14 from JianFeeeee/refactor/rename-batch4-ci 
改名批 4-a：CI 产物名同步为 hologramagent-*（修 main 上的发版即挂破损）
 2026-10-21 16:37:40 +08:00
JianFeeeee
be5192d956 refactor(ci): release 流水线产物名同步为 hologramagent-*（批 4-a） 
批 2 已把打包产物改名为 hologramagent-*（8380fcbb），但 release.yml 仍按
homeagent-* 找包，main 处于「下次发版必挂」的中间态。本批只补 workflows。

运行时真读包（改错即发版即挂）：
- 253/256 行 dpkg-deb -c hologramagent-full_*_amd64.deb
- 259 行    dpkg-deb -c hologramagent-server_*_amd64.deb
依据 deploy/packaging/package-linux.sh:675 的 deb 产物模板
hologramagent-${variant}_${PKG_VERSION}_${DEB_ARCH}.deb（variant 见 845 行，
CI 跑 amd64 ⇒ DEB_ARCH=amd64）。

release notes 文本（须与脚本产出名逐字一致）：
- 314 行 hologramagent_${VERSION}_linux_amd64.tar.gz
  依据 714 行 hologramagent_${PKG_VERSION}_linux_${TAR_ARCH}.tar.gz，
  amd64 ⇒ TAR_ARCH=amd64（非 x86_64）
- 315/316/317 行 hologramagent-client/server/full_${VERSION}_amd64.deb
rpm 未列：CI 只上传 ./*.deb ./*.tar.gz ./SHA256SUMS，不含 rpm。

未改动：notes 首行 "HomeAgent $VERSION"（展示名，规格只点名产物名，归批 4-b）；
ci.yml 的 mirror push 路径与首行注释（平台改名/展示名，归批 4-b）。
 2026-10-21 16:22:33 +08:00
JianFeeeee
8380fcbb0d Merge pull request #13 from JianFeeeee/refactor/rename-batch2-packaging 
refactor(deploy): 改名批 2 · 打包发行（deploy/ 品牌落地）
 2026-10-21 16:10:42 +08:00
JianFeeeee
350e92057f Merge remote-tracking branch 'origin/main' into refactor/rename-batch2-packaging 2026-10-21 16:01:07 +08:00
JianFeeeee
746fad4402 Merge pull request #12 from JianFeeeee/refactor/rename-batch1-module 
改名批 1：核心仓 Go module 路径 HomeAgent → HologramAgent（不含 SDK 仓与目录改名）
 2026-10-21 15:58:30 +08:00
JianFeeeee
67d0d90888 refactor(deploy): Windows 安装器与 WSL 引导脚本改名，并修两处跨脚本不同源 
installer.nsi / install-via-wsl.ps1：产品名、输出名
HologramAgent_v*_win64.exe、GUI 目录 hologram-gui-win32-x64、快捷方式、
自启注册表项、HOMEAGENT_* → HOLOGRAM_*（安装器写、setup.sh 读，必须同改）、
WSL 内数据目录 /var/lib/hologram 与 hologramagent.service。

package-windows.sh 两处顺带修：
 1. GUI payload 目录名**不假设上游已改名**。它由 Makefile:331
    （GUI_BINARY=homeagent-gui）或 build.sh 的 electron-builder
    （productName=HomeAgent）产出，两者都归别的批；而 .nsi 现在期望
    hologram-gui-win32-x64。直接改引用会让 Windows 包以
    "[FAIL] 需要 GUI payload" 挂掉（或者更糟：有人放宽检查，安装器
    File 一个不存在的目录）。改成找到哪个用哪个、统一 stage 成 .nsi 期望名。
 2. 版本号解析与 package-linux.sh/build.sh 同源。原先直接
    `git describe --tags`，无 tag 分支上拿到的是分支名，于是拼出的
    DEB_GLOB 永远找不到包 —— 报错信息看起来像"Linux 包没打出来"，
    真因是版本号被解析成分支名。现改为「形如 vX.Y.Z 才采用，否则回退
    meta.Version」，并加数字开头守卫。

deploy/scripts/deploy.sh：单元文件名与 systemctl 提示改成 hologramagent。
（deploy-plan.sh 不动：它的 SVC 指的是**本机正在跑的那个**旧单元，
 归部署 runbook；deploy-sdk-site.sh 的域名归批 5；upload_assets.py 的
 仓库名归批 4。）
 2026-10-21 13:21:12 +08:00
JianFeeeee
79688386b1 refactor(deploy): package-linux.sh/spec 产物与安装布局改名，并补结构判据 
package-linux.sh（只动包名/安装路径，不动 SDK module 路径）：
  - 产物名 hologramagent-{variant}_*.deb / hologramagent-*.rpm /
    hologramagent_*.tar.gz
  - 安装路径 /usr/lib/hologram/{sdk,models,onnxruntime,setup.sh}、
    /usr/share/doc/hologramagent/（DEP-5 惯例按包名）
  - GUI：build/hologram-gui-linux-<arch>、/usr/bin/hologram-gui、
    /usr/lib/hologram-gui、hologram-gui.desktop
  - 单元从 deploy/hologramagent.service 取，装成 hologramagent.service
  - staging /var/lib/hologram

**故意没动** prepare_gomod 里那段 replace 的匹配串
（github.com/JianFeeeee/homeagentsdk）：那是批 3 的 module 改名，
匹配串先改而 module 未改，sed 会整段不匹配且**不报错**，继续用旧路径编
—— 正是清单第四节第 2 条点名的静默失效。等批 3 一起改才安全。

spec：homeagent.spec → hologramagent.spec（git mv），包名/unit/datadir/
changelog 同步；%{_varlibdir} = /var/lib/hologram。

packaging_test.go：第 171 行的 toolchain 关键字跟着改；**第 99-106 行那两处
module 路径断言一行未动**（批 1 的地盘）。另新增四条结构判据，把本批
「日志全绿但包内容还是旧路径」这一类钉住：
  · TestPackagingUsesRenamedInstallPaths   —— 脚本里不许残留旧路径，且新值必须真出现
  · TestDebMaintainerScriptsUseRenamedService —— postinst/prerm 的 SERVICE_NAME
  · TestDebControlFilesUseRenamedPackage   —— 四个 control 的 Package 与 SDK 路径
  · TestSystemdUnitUsesRenamedPaths        —— 单元指令行（注释除外）+ 旧单元已删

判据形态仍沿用本文件的原则：断言的是「某个必需处置存在」，不是接线/顺序。
端到端（真装再看内核）由发版流程做。
 2026-10-21 13:21:06 +08:00
JianFeeeee
503579ae18 refactor(deploy): deb control 与 postinst/prerm 改用 hologramagent 包名与 /var/lib/hologram 
四个 control：Package: homeagent-{client,server,full,toolchain} →
hologramagent-*，Maintainer/Homepage 品牌名，toolchain 的 SDK 安装路径
/usr/lib/homeagent/sdk → /usr/lib/hologram/sdk。

postinst/prerm：SERVICE_NAME="hologramagent"。
这一行是「改一半就静默失效」的典型：
  systemctl enable/start/stop 全部带 2>/dev/null || true，
  单元名不对时**不报错**——装完既不 enable 也不 start，用户以为装好了。
现在 postinst 的 DATA_DIR/SETUP_SH 也一起指向 /var/lib/hologram、
/usr/lib/hologram/setup.sh，否则 setup.sh 会在旧目录里初始化凭据，
而内核按新单元从新目录读 —— 表现为「装完登录不上，credentials.txt 找不到」。

setup.sh 同步：HOLOGRAM_DATA / HOLOGRAM_API_KEY 前缀、模型目录
/usr/lib/hologram/models/...。与 postinst 传的变量名必须一致，
否则 DATA_DIR 回落到默认值、凭据写到另一个目录。

Homepage/Documentation 用 trueagent/HologramAgent（与原值同源，只换品牌词）；
仓库 owner 与地址本身归批 4，这里不动。
 2026-10-21 13:21:00 +08:00
JianFeeeee
3748d01094 refactor(deploy): systemd 单元改名 hologramagent.service + 路径品牌化（改名批 2/5） 
批 2 的范围只有 deploy/ 的品牌落地：包名、单元名、安装路径、control、
spec、nsi、ps1。域名归批 5、仓库名归批 4、SDK module 路径归批 3，
LDFLAGS/Makefile 的 module 注入归批 1 —— 本批一行未碰。

单元：deploy/homeagent.service → deploy/hologramagent.service（git mv）
  - Description/Documentation 品牌名
  - ExecStart --data /var/lib/hologram、WorkingDirectory 同步
  - StateDirectory=homeagent → hologram（不跟着改的话，systemd 会按旧名
    建 /var/lib/private/homeagent 并把 ReadWritePaths 指向另一个目录，
    内核起得来但写的位置是错的）
  - ONNXRUNTIME_DIR=/usr/lib/hologram/onnxruntime
  - LoadCredential :/etc/hologram/security.key、ReadOnlyPaths=/etc/hologram

注释里刻意保留一条 /var/lib/homeagent（"从旧版磁盘钥升级时"的说明）：
那条讲的就是**旧路径**上的历史密钥，改成新路径反而会误导升级操作。

embed-sidecar.service 只改 Description 里的品牌名（它与内核安装布局无关）。
 2026-10-21 13:20:56 +08:00
JianFeeeee
ed8d5d83a7 fix(sdk-meta): 清掉旧 module 路径的注释残留，使判据4 口径可含 third_party 
批 1，不含 SDK 仓与目录改名。

背景（复核意见一）：原判据4 为
  grep -rl 旧路径 --include=*.go . | grep -v ^./third_party | wc -l == 0
而 M3 的变异点 CoreModule 就在 third_party 内 ⇒ 被判据自身排除，
口径恒真、M3 永远咬不住。改为全仓 *.go（含 third_party）后，
meta.go:80 的这行注释会成为永久命中，使判据恒假 —— 同样不可用。

故连同常量一起把该行注释里的旧路径换掉（它本就描述 CoreModule，
属批 1 改动的必然附属，不是批 5 的品牌展示名）。

改后两个口径均为 0：
- 全仓 *.go 含 third_party：0
- 排除 third_party（旧口径，保留对照）：0

M3 自证：把 CoreModule 改回旧路径 ⇒ 新口径计数 = 1（红），旧口径仍 = 0（恒真已复现）。
 2026-10-21 12:34:30 +08:00
JianFeeeee
f8adf246c5 refactor(sdk-meta): CoreModule 常量跟随核心仓 module 路径 
批 1，不含 SDK 仓与目录改名。

CoreModule 喂给 hmapdev 生成插件 go.mod；漏改会让生成的 go.mod
指向不存在的模块路径。

只改这一个常量串：
  github.com/JianFeeeee/HomeAgent → github.com/JianFeeeee/HologramAgent

未动（按批 1 边界）：
- SDK 自身 go.mod module 与 SDKModule/LegacySDKModule 常量（批 3）
- 同文件第 80 行注释里的旧路径字样（文档性，批 3/批 5）
- go.mod:46 replace 目标路径

★ 待办：SDK 主仓（github.com/JianFeeeee/homeagentsdk）里同样的 CoreModule
  常量需在批 3 同步。
 2026-10-21 12:19:03 +08:00
JianFeeeee
db6753ee2b build(ldflags): 版本注入串同步到新 module 路径（Makefile:62/318、build.sh:69/230/240） 
批 1，不含 SDK 仓与目录改名。

不同步的后果：go build 全绿但 -X 对未知路径静默忽略，
homed --version 的 Version/Commit/BuildTime 回落成默认值。

- Makefile:62    -X .../internal/meta.{Version,Commit,BuildTime}
- Makefile:318   -X .../internal/kernelboot.EmbeddedGraphHash
- build.sh:69    同上三个 meta 变量
- build.sh:230   -X .../internal/security.embeddedKeyHex
- build.sh:240   -X .../internal/kernelboot.EmbeddedGraphHash
 2026-10-21 12:17:32 +08:00
JianFeeeee
4e70b8d5d8 refactor(module): 核心仓 Go module 路径改为 github.com/JianFeeeee/HologramAgent 
批 1，不含 SDK 仓与目录改名。

- go.mod 第 1 行 module 路径
- 366 个 .go 文件的完整前缀 github.com/JianFeeeee/HomeAgent 机械替换
  （857 处，仅完整前缀；展示名/注释里的 HomeAgent 字样留给批 5）
- 未改：third_party 目录名、SDK 自身 go.mod module、go.mod replace 目标、
  homed/waiter 可执行名、.hmap 后缀
 2026-10-21 12:17:19 +08:00
JianFeeeee
4e66e644da test(security): 修 -race 下 TempDir 清理假红 —— 断言已过却被清理判失败 
## CI 实证（run #86 / #87，Race detector 连续两次红）

失败信息自相矛盾：

    --- FAIL: TestE2E_ResponseSecretNeverReachesContext (0.00s)
        persist_leak_test.go:94: ✅ 回复侧明文未进 context；变量库 1 条
        testing.go:1369: TempDir RemoveAll cleanup: unlinkat /tmp/TestE2E_.../001: directory not empty

断言全过、变量库也拦住了，唯一失败点是 `t.TempDir()` 的严格清理：RemoveAll
要 rmdir 那一刻，变量库还有一次落盘（saveLocked 的 tmp→rename）在途/刚落完，
于是判 "directory not empty"。本地不复现是因为机器快、时序不同；CI 在 -race
下慢一拍就撞上。

## 修法

`newScrubStore` 改为自建 MkdirTemp + 重试清理（50×20ms），最后尽力删除且
**不让清理失败污染判据**。安全判据本身没有放宽——只修测试基础设施。

## 验证

本地 `go test -race ./internal/agent/core/ ./cmd/waiter/ -count=1`：
两个包全绿（16.2s / 1.0s）。
 2026-10-20 10:24:31 +08:00
root
8a2503796e feat(persona): 说话方式增加「主动发表情包」——情绪到位别只干说话 
配套 QQ 表情能力（qq_list_stickers / qq_send_sticker / qq_add_sticker）：
人格里补一条表达习惯，让模型在有表情能力时**主动**用，而不是等用户点名要。

分寸也写进人格（一轮最多一两张、要真对得上情绪、没合适的不发），避免刷屏。
实例 personal.md 同步。

注：人格只写"表达习惯"，不写工具名/调用方式——那些在 qq-tools 技能里。
 2026-10-20 10:06:49 +08:00
JianFeeeee
679536692f fix(pluginmgr): 升级后恢复运行状态 —— 重装不该把正在用的插件静默停掉 
## 日志实证（2026-10-20 09:54）

重装 qq 插件后，agent 的工具清单里 qq_* 全消失，它只能：

    terminal_list → get_plugin_tools ×2 → plugin_start(qq) → plugin_status
    → output_send__qq_help → get_plugin_tools → 才摸到 qq_list_stickers

根因：升级路径 `installFromData` 里 StopAndUnload 停掉旧实例后，**再也没有
把它拉回来**。安装的语义应当是"换个包"，不是"把正在用的插件关掉"。

## 修法

- 升级前通过 ListPluginRuntimes 记录 `wasLoaded`
- 解压成功、skill 交接完成后，若升级前在跑则 StartPlugin 拉回
- 返回体暴露 `was_running` / `running_restored`，失败不阻断安装（插件已装好）

实测：`reinstalled qq, was_running=true, running_restored=true`，装完
loaded/alive 均为 true、PID 更新。

## 测试

- TestUpgradeRestoresRunningState：升级前在跑 ⇒ StartPlugin 恰好调用一次
- TestUpgradeDoesNotStartStoppedPlugin：升级前没跑 ⇒ 不得强行拉起

## 同批日志里的另外两条（非代码问题，仅记录）

1. llmsproxy 在 09:52:21 / 09:53:14 被重启，其间 homed 收到 connection refused，
   经「stream 失败→非流式 + 2s 重试→换 provider」兜底，用户侧无失败但多耗一轮。
2. 上游返回 404「The model is not registered」与 429 限流（channels-codearts），
   属 llmsproxy 侧渠道配置/配额问题，建议在 llmsproxy 里核对该模型注册。
 2026-10-20 10:01:59 +08:00
root
276553727f fix(persona): 默认人格补「一条消息内不空行分段」 
与 SDK 仓的 QQ 通道收敛配套：提示词层先要求不空行（模型大概率照做），
通道层再确定性收敛（模型没照做时兜底）。实例 personal.md 已同步。
 2026-10-20 09:44:29 +08:00
root
f33ee3e396 docs: 把「业务语义归插件、联动走事件总线」补进 OVERVIEW 与 PLUGIN_DEV 
上一提交只在 ARCHITECTURE 里记了终端归属。本次把这条**通用原则**补到另外两份
文档，避免只读 OVERVIEW / 插件开发指南的人仍旧按旧直觉写代码。

## OVERVIEW（中英）

设计要点新增一条「业务语义留在插件层」：内核不定义业务对象（终端、命令历史、
设备状态、媒体库都是插件域）。以终端为例说明：PTY/生命周期/输出缓冲归
agentcli，WebUI/CLI 订阅总线自攒视图，内核只提供事件总线与注册面 —— 新增一类
能力不需要改内核，也不会在核心里堆出第二套业务真相。

## PLUGIN_DEV（中英）

PluginSDK 章节新增「与其它插件联动 — 走事件总线，不要依赖内核内部组件」：
- 代码示例：订阅 terminal_output + tool_call 自己攒视图
- 两条稳定事件表（谁发布、用途）
- ★ 外部插件只能订阅、不能发布（Publish 属 withheld 能力），所以「能力所有者
  需要广播状态」的插件必须内置（agentcli 即此例）
- 指向 internal/pluginview 作为参考实现，并写明「视图不是权威、晚启动会缺早期
  事件」

一个准确性修正：公开 SDK **没有** EventTerminalOutput 常量（属内核内部事件
类型），所以示例里外部插件用 sdk.EventType("terminal_output") 字符串订阅，
并注明内置插件可用 internal sdk 常量 —— 避免文档给出编不过的示例。

验证：四份文档代码围栏配对（74/74、0/0）；仅文档改动，无代码影响。
 2026-10-20 09:41:07 +08:00
root
3119d48625 refactor(terminal): 终端逻辑回归 agentcli，内核不再编码终端语义 
按用户指正调整架构：终端是 agentcli 的职责，内核不该有终端逻辑；插件与
agentcli 的联动应走事件总线，而不是内核内部组件。

## 删掉内核里的终端语义

`internal/agent/core/terminal_registry.go`（280 行）整体删除。它做了两件不该
内核做的事：定义「什么是终端会话」、从 EventToolCall 的 Go map 文本里解析
terminal id / command 并归并会话与命令历史。连带移除：

- Agent 的 terminalReg 字段、构造、subscribeTerminalRegistry 订阅
- StatusAPI 上的 ListTerminals / CmdHistory
- sdk.TerminalAPI + PluginSDK.Terminal() + Registry.SetTerminalAPI 及接线
- 对应测试（迁到插件侧视图包）

保留 `sdk.TerminalStatus` / `CmdExecStatus`：它们只是线上 JSON 格式，WebUI/CLI
返回给前端时口径一致。

## 插件侧订阅事件总线自攒视图

新增 `internal/pluginview`（TerminalView）：把原先内核那份归并逻辑原样搬过来，
由插件自己持有。数据源仍是两条总线事件：

    EventTerminalOutput（agentcli 发）→ 会话输出 + 生命周期
    EventToolCall      （内核发）    → cmd_run 历史、terminal_create/close 归并

WebUI 在 NewHandler 订阅、Close 退订；CLI 在 Start 订阅、Stop 退订。
两边共用同一实现，避免历史上「两份推导各踩一次 Go map 文本」的坑。
视图不是权威：真值在 agentcli，插件晚于会话启动会缺早期会话（注释写明）。

## agentcli 保持内置

它现在仍需要 `Publish`（进程内事件总线写入）——外部插件没有上行事件通道
（`EventPublish` 在 withheldCapabilities 里，proc 只有 events.subscribe）。
按判定标准留内置；将来要外置，须先开一条受控的插件→内核上行事件通道，
本次刻意不开（用户决定：先保持内置）。

## 文档

中英 ARCHITECTURE 新增「终端归属」小节：说明职责边界、两条事件、视图非权威、
以及 agentcli 为何仍内置；内置判定表里 cli/webui 去掉 TerminalAPI 一项。

## 验收（本机实例实测）

- 内核编译通过，删除后 `go build ./... && go vet ./...` 干净，`go test ./internal/...` 全绿
- 实例重启后：让 agent 开终端跑 `echo term-view-test` →
  WebUI `GET /api/v1/terminals` 返回 term_1（output 正确、running=false）
  CLI `/terminals`（unix socket）返回同一份；
  两处都是从事件总线自攒，内核侧无终端代码参与
- cmd 历史分支由迁过来的单测覆盖（Go map 文本解析、生命周期、上限裁剪）
 2026-10-20 09:33:08 +08:00
root
b9097986c8 fix(prompt): 拼装时空行翻倍 + 人格支持版本占位符 + 配置项说明对齐分层原则 
## 1. 提示词里的空行翻倍（用户实测发现）

抓包看实际 payload，system 里出现 3 处连续 3~4 个换行：

    …别包装成"稍等我看一下"。\n\n\n【人格设定】
    …/mascot.webp 直接能看。\n\n\n\n【场景记忆】
    …能否同轮发出。\n\n\n【输出规则】

根因：拼装统一用 `prompt += "\n\n" + block`，而块自己常以换行结尾
（人格块是 "【人格设定】\n%s\n"，自定义 system_prompt 也常带尾部换行）。
空行不致命但推高 token，也让「提示词到底长什么样」难以肉眼核对。

修法：新增 appendPromptBlock（trim 块两端 + 只拼一个 "\n\n"），所有拼装点改用它。
重新抓包：连续 3+ 换行 0 处。

## 2. 人格块支持版本占位符

buildSystemPrompt 只对 systemPrompt 调 expandPromptVars，人格块没展开 ——
人格里写死版本号仍会随发版说谎（实测线上人格卡写 v1.0.3）。现在人格同样展开
{{kernel_version}}/{{kernel_commit}}/{{sdk_version}}。

## 3. 人格/系统提示词两个配置项的说明重写

- core.agent.personal_prompt：DisplayName 改为「人格设定（称呼/语气/说话方式/形象）」，
  说明只写人设；工具用法写工具描述、多步流程写技能；支持占位符；文件优先。
- core.agent.system_prompt：DisplayName 改为「系统提示词（身份与行为规则）」，
  说明只写跨工具/跨通道成立的内容；运行时通道投递/并行/时序语义由内核注入无需重复；
  留在提示词里的工具用法会随插件外置而失真。

## 4. 【记忆清理指令】→【记忆维护】

具体选哪个 memory_* 工具、各自副作用早已写在工具描述里（【记忆清理】前缀），
提示词里那份逐条列举属于重复。只保留「必须真做、不能只描述计划」这条
不看工具描述也会犯的错，并要求用一句人话说结果。

## 5. 新增 opt-in 提示词抓包（排查用）

HOMED_PROMPT_DUMP=<path> 时把每轮实际发给 LLM 的 messages 落 jsonl（0600）。
环境变量而非常规配置项：内容是用户隐私，只该在诊断时临时开。
本次排查即由它拿到证据；诊断后已移除临时 drop-in。

验证：go test（agent core / config / sdk / healthcheck）全绿；
实例重启后抓包复核空行归零；对话口吻仍为「短、口语、不列清单」。
 2026-10-20 09:16:07 +08:00
root
d35b7b7275 feat(status): ONNX 状态补 dep_parser 字段；人格改成「说人话」的说话方式 
## 1. ONNX 状态补依存句法分析器（onnx.dep_parser）

此前 onnx.enabled 只反映**多模态向量空间**，解析器状态完全不可见 —— 于是
只能靠翻启动日志猜，而日志又曾把「内嵌模型已启用」错报成「规则引擎」
（见上一个提交）。现在健康快照直接给：

    "dep_parser": { "enabled": true,
                    "model_path": "/home/newqqagent/nlp/dep_parser.onnx",
                    "embedded": true }

- sdk.ONNXStatus 增加 DepParser / DepParserStatus（enabled/model_path/embedded）
- agent 侧由 nlp 包级默认解析器反查实际状态（判据是「真能 Parse 且报得出路径」，
  不是「配置里写了 onnx_model_path」）
- healthcheck_kernel 的描述同步说明该字段

## 2. 人格：从「交报告」改成「聊天」

用户反馈实例说话一股人机味。实测原文：

    第一件·文件读写：
    - 写：files_write 往 /tmp/... 写入 hello-files，回执 11 字节
    - 读：files_read 读回来，内容就是 hello-files，对上了

问题不在语气词，而在**结构**：清单体 + 小标题 + 加粗 + 把工具名/字节数/耗时
当成绩单报出来。旧人格只禁了「客服腔四件套」，没禁这些。

DefaultPersonaPrompt 的说话方式一节重写，明确：
- 短句为主；先给结果/情绪，再补解释
- 不用清单体（“-”/“1.”/“•”）、不用小标题/加粗/表格
- 不报工单式细节（不罗列工具名、参数、字节数、耗时）——说人话
- 不用客服腔，拿不准/失败直说
- 只有用户明确要清单/步骤/数据时才结构化

## 3. 本机实例人格同步优化（personal.md，优先级高于配置项）

按同一套规则重写 /home/newqqagent/personal/personal.md，并保留「照大肥鱼那股
活人味来」与形象特征。重启后实测（问「在吗？状态咋样」）：

    在呢在呢 (｀・ω・´)
    刚拉了个运行时快照看了眼，状态挺好——内核 1.4.0dev 跑着，29 个插件全部 loaded……
    刚忙完就赶紧来找我聊天，老大你这节奏也太充实了呗～

无清单、无小标题、无工具名报账。

验证：go test（sdk / agent core / healthcheck / config）全绿；
本机实例重启后 onnx.dep_parser 三字段正确返回。
 2026-10-20 09:08:20 +08:00
root
48ca95f964 fix(onnx): 启动日志错报「走规则引擎」—— 实际一直用内嵌 ONNX 模型 
用户质疑「编译的内核没启用 onnx」。核查结论：**ONNX 是启用的**，是我上一版
日志改错了，误导了判断。

## 事实

- 编译：`make build` 默认 `HOMED_TAGS=onnxruntime`（Makefile 有明确注释，
  产物里 `go version -m` 可验 `-tags=onnxruntime`、CGO_ENABLED=1）。
- 多模态向量空间：`provider=chineseclip dim=512` 已加载，健康快照
  `onnx.enabled=true`。
- 依存句法分析器：`core.agent.onnx_model_path` 留空时走**二进制内嵌模型**
  （`//go:embed models/*` → 解到 `<data>/nlp/dep_parser.onnx` 后加载），
  同样是 ONNX 推理，不是规则引擎。

## 上一版错在哪

我只回显了**配置值**（空串），于是打出
`dep parser ready (内置规则引擎；未配置 ...)` —— 把「内嵌模型已启用」
说成了「降级到规则引擎」。原始日志 `initialized (model: )` 的空括号
本来就是同一个信息缺失，我把它改成了**更确定的错误结论**。

## 修法

- `nlp.ONNXParser` 记录实际加载的 `modelPath` 并暴露 `ModelPath()`
  （stub 构建下恒为空，两套构建接口一致）。
- 内核启动日志改为报实际路径：
  `dep parser ready (ONNX，模型: /home/newqqagent/nlp/dep_parser.onnx)`

部署后实录：该行正确输出实际模型路径；`onnx.enabled=true`；
启动告警仅剩两条 CLI 型技能降级说明（已在上一个提交解释）。
 2026-10-20 09:04:11 +08:00
root
16c9d4f69e fix(startup): 启动阶段两类噪声归零 —— 插件 stdout 日志与 CLI 型技能误判 
用户反馈启动日志里有报错。实测定位到两处，都是真实问题：

## 1. huawei_smarthome 往 stdout 打日志（8 条「收到非法 JSON 帧」）

stdout 是 JSON-RPC **协议通道**，它在 plugin.go/handlers.go/service.go 等处
用了 fmt.Printf（31 处），内核每收到一行就把协议解析失败一次。
这不是内核的错，是插件写法错 —— 已在其源码（/home/newqqagent/plugindev/
huawei_smarthome）把 fmt.Printf/Println 全部改成 log.Printf（stderr），
重新 hmapdev 打包并安装。重启后非法帧 0 条、10 个工具正常注册。

## 2. clawhubadapter 把 CLI 型 main.py 当 JSON-RPC sidecar

判定规则原为「有 main.py 就按 pysidecar 拉起」，但 ClawHub 上大量技能的
main.py 是 **CLI 入口**（`python3 main.py <tool> '<json>'`），对它发 ping
必然超时（bilibili、gaode 各等 5 秒）。旧代码只打一行错误就完事 ——
启动日志一片红，而技能既没变成工具、也没交给 skillmgr，等于半死不活。

改为：sidecar 就绪失败即降级为「CLI 型技能」，移交 skillmgr 并给出说明，
日志措辞从「错误」改为「未就绪 → 按 CLI 型处理」。两个技能现已可经
skill_info 读到文档、再用命令执行。

## 3. 顺带修一条看着像配置泄漏的日志

`dep parser initialized (model: )` —— 空括号是「未配置 ONNX 模型、走内置规则
引擎」的正常回退。改为显式说明，避免误读成缺配置。

## 验收（本机实例重启后实录）

- 「非法 JSON 帧」0 条（此前 8 条）
- dep parser 日志：`ready (内置规则引擎；未配置 core.agent.onnx_model_path)`
- 剩余 3 条均为说明性：mail-bridge 出站通道兜底、两个 CLI 型技能降级移交
- 13 个内置 + 13 个自启外部插件全部 loaded，agent main started
 2026-10-20 09:00:58 +08:00
root
b5f024b054 refactor(prompt): 提示词去工具化 + WebUI 插件状态按运行期真相展示 
## 1. 系统提示词/人格瘦身（工具用法搬去 tooldef 与 skill）

用户指出：默认系统提示词与 personal 里有大量本该属于 skill / 工具描述的内容。
核对属实，且已造成**真实故障**：提示词教模型用 cmd_run，而 cmd 外置按需后
工具根本不在清单里 ⇒ 模型第一轮调用不存在的工具，拿到「工具 cmd_run 不存在」。

改动：
- kernelmod/agent.defaultSystemPrompt：删掉 output_* 用法、工具分类清单、
  cmd_run/terminal/files 策略、并行策略、媒体工具清单、emoji 风格要求。
  只留：身份 + 「工具描述与技能索引会注入，先读再用」+「只依据工具返回值作答」。
- config.DefaultPersonaPrompt：只留身份/称呼/语气 + 版本以运行时快照为准
  （后者由 TestDefaultPersonaPromptHasNoVersionLiterals 钉住）。
- 命令与文件策略下沉到工具描述：cmd_run 补「完整 bash，支持管道/heredoc/重定向」，
  files_write 补「原子替换 + 覆盖受保护路径前留档」。
- 对话时序块自带语义说明（原先靠提示词解释，提示词一精简就丢语义）。
- 文档新增「提示词分层」章节（中英），写明归属判据与这次的反面教材。

## 2. WebUI：插件「启动状态」按运行期真相展示

旧实现只看内核 status 的 loaded 一个布尔，三种形态被混成同一个「未加载」：
auto_start=false 的按需待命（正常）、该起没起（异常）、plugin_stop 后的运行态停止。
用户看到一屏「未加载」以为插件全坏了。

- sdk.PluginRuntimeInfo 新增 AutoStart / RuntimeStopped；registry 从清单填充。
- pluginmgr /plugins 列表暴露 auto_start / runtime_stopped / builtin / tool_count。
- webui 新增 POST /plugins/<name>/start|stop（运行态，不动持久禁用清单）。
- dashboard 状态列改为五态：已禁用 / 进程丢失 / 已运行 / 按需待命 / 未运行，
  并额外标注「自启 / 按需」；按钮改为 启动/停止（运行态）与 禁用/启用（持久态）分列。
- 新增两条回归判据（引用 auto_start/runtime_stopped/alive 字段；startPlugin 走 /start）。

## 验收（本机实例实测）

- files 保持 auto_start=false（按需）；问 agent 写文件 → 它先 plugin_start cmd+files，
  再 files_write/files_read，内容校验一致；未用 shell 代替文件操作。
- WebUI 插件页截图确认：a2a/acp/agentcli 显示「已运行 自启」，
  ai_image 显示「按需待命 按需」+「启动」按钮。
- go test（config/agent core/plugin/pluginmgr/webui/sdk）全绿。
 2026-10-20 08:57:36 +08:00
root
2aab90c508 fix(plugins): 内置清单终审 15 → 13 —— kbtree/multimodal 翻案加回 
## 翻案依据（逐方法对照公开 SDK，非方法名 grep）

初判把 kbtree/multimodal 归入"只用公开 SDK"，错了。两边的
s.Knowledge() / s.LLM() **同名但接口面不同**：

- kbtree 需要 KnowledgeAPI.Subtree/CategoryCounts/SearchIn/Categories
  与 KnowledgeTreeView/KnowledgeCategoryCount 类型 —— 公开 KnowledgeAPI
  只有 Search/Add/List，树视图类型公开面根本没有
- multimodal 需要 LLMAPI.Chat + LLMMessage/LLMContentBlock ——
  公开 LLMAPI 只有 ListSources/SetSource/CurrentSource，没有 Chat

外置它们 = OCR/看图/转写、知识树浏览静默失效。

## 最终内置 13 个

  cli webui agentcli healthcheck pluginmgr seq remotedevice
  clawhubadapter kbtree multimodal cfgmgr skillmgr seemedia

外置 5 个（SDK 仓 example/ 已提供工程并已部署验证）：
  cmd localuse mcp（本轮）+ ai_image files（此前）+ timer（更早）

## 文档同步（中英 6 份）

数量 11 → 13；判定标准小节补「终审翻案」与教训：
**判外置与否必须逐方法对照公开接口，同名方法不等于同面。**

验证：go build/vet/test 全绿；生产实例已部署新内核 + 新插件包，
四个按需插件经 plugin_start 拉起、工具全部注册（cmd_run /
local_screensee / mcp_* / files_edit_line 实核）。
 2026-10-19 22:09:09 +08:00
root
835688c94a refactor(plugins): 按「内置插件判定标准」收敛内置清单 16 → 11 
## 判定标准（写进 all.go 与 ARCHITECTURE）

**只有必须使用内部 SDK 能力（公开 SDK 没有的接口面）的插件，才留在
编译期内置清单**；其余一律外置为 .hmap 插件，独立编译、独立发版。

依据是 internal/plugin/proc/capability.go 的 withheldCapabilities：
内部 SDK 的 TerminalAPI/TrackerAPI/StatusAPI/SupervisorAPI/AdapterAPI/
SelftestAPI/ToolAPI/Publish 等能力面，外部插件在类型层就不存在。
需要它们的插件外置后功能会**静默消失**（不报错），必须内置；
只要公开能力的插件，留在内核里是白付重编成本。

## 内置 11 个（all.go 单一权威清单）

  cli webui       TerminalAPI/Tracker/Status/Supervisor/Adapter
  agentcli        EventPublish（终端输出走 Publish，公开 SDK 无此方法）
  healthcheck     SelftestAPI
  pluginmgr       failback 恢复链必需
  seq             ToolAPI
  remotedevice    RegisterChannel
  clawhubadapter  InjectInputSync
  cfgmgr skillmgr seemedia（保留）

## 外置 8 个（源码保留，.hmap 由 SDK 仓 example/ 提供）

  timer（此前）ai_image files cmd kbtree localuse mcp multimodal

## 同步修正

- kbtree 归位：它一直是编译期内置插件，却长期被 main.go 单独导入，
  游离在 all.go 清单之外（文档盘点因此数错）。现移入 all.go，
  main.go 不再单独导入任何插件，并加注释禁止该做法。
- integration_test：外置插件的 7 个用例（cmd_run/terminal_*）加
  requireExternalTool 跳过保护——用例保留（行为判据仍有价值），
  在纯内置装配下 Skip，不造假失败。
- 全部文档同步 11 个的清单与判定标准（中英四份 + 两份 README）。

## 已核实不做的事

- 保留的 11 个内置插件无一在代码里硬依赖被外置的插件：
  cli 对 terminal_* 是 ExecuteTool 按名动态调用（运行时依赖）；
  healthcheck/seq 只在白名单与示例文本里出现；webui 只订阅事件。
- kernelmod/（内核模块）与 plugins/（插件）严格区分：
  kernelmod/multimodal 是内核装配模块，与外置的 multimodal 插件无关。

验证：go build ./... 全绿；go test ./internal/plugins/... 全绿；
webui 新增 5 条命令历史渲染回归判据（TestCmdHistory*）全绿。
 2026-10-19 21:13:23 +08:00
root
515cf2deb1 docs: 按源码全面校正（插件数/内置 timer/RPC 数/工具数/失效行号） 
逐条对着源码核过，修掉 5 类与实现不符的陈述（中英四份文档同步）：

1. **内置插件数 20 → 17**
   `internal/plugins/all.go` 的空白导入实际是 17 个。旧文档还列了 `timer`
   （已外置）与 `data`/`kbtree`（根本不是内置插件，前者只有 skills 目录，
   后者未进 all.go）。清单按 all.go 重写。
   涉及：README、README_EN（含「许可」章节的 AGPL 覆盖范围）、OVERVIEW 中英、
   ARCHITECTURE 中英的加载方式表。

2. **删除所有把 timer 当内置插件的表述**
   ARCHITECTURE 中英目录树里的 `internal/plugins/timer/` 行、
   PLUGIN_DEV 内置插件示例表的 Timer 行（该行还与同页下方「timer 已移出内置插件」
   的说明自相矛盾）。示例表改用 healthcheck（真实存在、30m 定时自检）。

3. **子进程 RPC 方法数 55 → 82**
   权威清单是 `internal/plugin/proc/protocol.go` 的 Method 常量，
   实际 82 个（settings 16 / plugin 9 / io 8 / secrets 7 …）。
   v1.1.1「51 → 55」作为历史叙述保留，但补注说明 82 才是当前值，
   避免读者把 55 当现值。

4. **qq 示例工具数 20 → 24**
   按 `example/qq/plugin.go` 的 `Name: tp + "..."` 实数。

5. **修掉整张失效的「文件:行号」引用表**
   原文写 `context.go:155` / `document.go:206` / `indexer.go:96+111`，
   但 memory 重组后 `context.go` 已迁到 `agent/core/`，行号全部错位。
   改为**函数名锚点**（`RelevanceContext.Prune`、`Store.Query`、
   `Indexer.vectorSearchEntities`），并改正 `distill.go` 的算法描述：
   文档写 Bigram Jaccard，源码是**加权** Jaccard（`scene_emerge.go` 有明确注释），
   阈值 `sim > 0.75` 在 `distill.go`。

同时补 Provider 接口漏项：实际有 4 个方法（Name / Chat / ChatStream /
MaxContextTokens），文档只写了前 3 个。

验证：`go build ./...` 通过；文档内相对链接 0 坏链；
引用的 22 个 .go 路径逐个 stat 存在（`internal/memory/media/` 两处是
「已删除机制」的历史叙述，指向不存在路径是正确语义，保持不变）。
 2026-10-19 20:49:43 +08:00
root
852d6a2891 chore(gitignore): 忽略本地 NLP 模型权重 /nlp/ 
nlp/dep_parser.onnx（48MB ONNX 依赖句法分析器）是**有意不入库**的本机资产：
二进制大文件一旦进 git 就永久留在历史里，且需要与本机加载路径配套。

此前它只是碰巧没被 git add（untracked），没有忽略规则保护 —— 任何一次
`git add -A` 都会把它带进来。补规则把这个意图固化下来。
 2026-10-19 20:38:03 +08:00
root
d9e1a44884 chore(sdk): 同步 SDK 仓 sdk/autostart.go 到 vendor 副本 
sdk/autostart.go 在 SDK 仓已随 74e2c65（22 个示例插件配齐 skill +
三态启动声明 + 打包期校验）提交，但外层仓锁定的 vendor 子集没跟上，
导致本仓 checkout 出来的 SDK 源码缺这个文件 —— 直接依赖 auto_start
契约的代码在本仓内无法编译/阅读。

同步方式：逐字节取自 SDK 仓 HEAD（sha256 = 2869619… 两边一致），
不做任何本地修改，保持 vendor 是远端内容的镜像。
 2026-10-19 20:37:44 +08:00
JianFeeeee
875c75445b chore(gitignore): 忽略内置 pi 的会话日志 .pi-sessions/ 
每条工程对话会在工作目录留下 .pi-sessions/*.jsonl（本次 592K 单文件），
属 agent 工作产物而非源码。内部按本机路径组织、且随对话无限增长，
故按 / 锚定忽略，不影响仓库其它位置同名目录。

(cherry picked from commit 223752b622f637040ab3d3c6e348bfe26fd925b1)
 2026-10-19 16:09:03 +08:00
JianFeeeee
7e371c1304 docs(plugin-dev): 补记「装上≠生效」——旧内核上装 timer 仍走内置工厂 
loadOne 先查 factories[name]，命中就不再读 plugin.bin；旧内核里内置 timer 工厂还在，所以落盘安装后 plugin_status 仍是 builtin=true / tools=[timer_set]，外部版本要等内核升级重启（工厂消失）才真正接管。plgreload 在这中间是空动作。

这样「先装插件再升级内核」的顺序约束才有可执行的含义：先落盘，再换二进制重启。

(cherry picked from commit 9e72898170386526425f8abe474d0f9622242422)
 2026-10-19 16:09:03 +08:00
JianFeeeee
47272adffe docs(plugin-dev): 注明 timer 已外置，并写明「先装插件再升级内核」的顺序约束 
timer 移出内置插件后，升级路径上有个静默故障点：若先升级内核、后装 timer 插件，
就会有一段窗口期三个 timer 工具全部不存在 —— 不报错、日志无线索，只是 LLM
视野里工具没了，表现为「定时提醒功能不见了」，极难归因。

在 zh/en 两份 PLUGIN_DEV.md 的「内置插件」表下补注记（原 Timer 示例行就删在这里，
正是读者会产生疑问的位置）：
  - timer 已改为外部 hmap 插件提供，三个工具与 timer 输入通道均由它注册
  - 升级顺序：先装 timer 插件，再升级内核
  - 外部版是严格超集：原内置版只有 timer_set 且重启丢在途倒计时，
    外部版增加 timer_list / timer_cancel 并跨重启保留待触发列表

assets/docs 是纯文档，无 go:embed、无代码引用，改动不影响构建。

(cherry picked from commit 62332562a80165b6e86af77315c07d18e743e7fa)
 2026-10-19 16:09:03 +08:00
JianFeeeee
99914a9e9b test(plugins): 加负向断言守护 timer 不再被注册进内核 
timer 已移出内置插件（717054a），但原有 TestIntegrationAllPluginsRegister
只是正向清单 —— 它断言「该有的工具都在」，对「多出来」是瞎的：
把 internal/plugins/timer 与 all.go 的 blank import 加回去，那条测试依然全绿。
于是「已移除」这件事只能靠人记住。

补一条负向断言，在三个互相独立的注册面上各断一次（任一处漏掉都能单独复活 timer）：
  - 工具面：timer_set / timer_list / timer_cancel 不应存在
  - 输入面：inputch "timer" 不应存在（定时器注入中断的通道）
  - 注册表：插件元信息与编译期工厂都不应存在（IsBuiltinPlugin 为假）

已做变异验证：把 timer 插件与 blank import 恢复后，四条断言全部触发、测试 FAIL；
移除后 PASS。故该判据非空转。

(cherry picked from commit d5882ee44a4810fe9e5ee02fb329ad423b065d6e)
 2026-10-19 16:09:03 +08:00
JianFeeeee
6b64d69b10 refactor(timer): 从内核内置插件迁为外部插件，移除编译期注册 
老大要求「把 timer 移到外部插件，移除内核的内置 timer」。本次只做内核侧
的**摘除**，插件本体在外部工程（plugins/timer → .hmap 安装）。

timer 原先由 internal/plugins/timer 的 init() 注册进编译期工厂表。
后果是改一行定时器逻辑要重编整个 homed（87MB）并重启内核——而它恰是
最该独立演进的部件：有自己的持久化状态、触发语义、并发模型，却被绑死
在主进程的发版节奏上。

搬出来后：换实现只需重装插件 + 重启单个插件进程；插件崩了自己被拉起，
不影响 agent 主循环。

1. 删除 internal/plugins/timer（plugin.go + plugin_test.go）
2. internal/plugins/all.go 去掉该 import，并写明**不要加回去**的原因
3. internal/plugins/integration_test.go 的 expectedTools 去掉 timer_set

TestIntegrationAllPluginsRegister 的语义是「编译期内置插件是否都注册了工具」，
它走的是本地装配（setupIntegration 只加载 internal/plugins 下的内置包）。
timer 搬走后不再参与这个进程的装配，留在列表里只会造出永远绿不了的假失败。

真正不该省的是验证：外部插件的工具是否真注册成功，靠装完 .hmap 后实调
timer_set / timer_list / timer_cancel 来确认（见交付报告）。

- 配置表：外部插件同用 config_<name> ⇒ config_timer，老值 max_duration /
  pending_timers 直接读回，老大已设的定时器无需迁移
- 工具名：timer_set / timer_list / timer_cancel 不变，模型侧零感知
- 注入源与通道：source/channel 仍是 "timer"
- 注入级别：内置插件可声明 L4，外部插件被夹到 L3；本插件本就要 L3，
  故行为等价

StageHost.RegisterTool 对同名工具返回 `already registered`，而插件注册是
批量失败（新实例的工具一个都注不上）。所以必须**先装新内核**（不含内置
timer）再装外部 timer 插件，反之会撞名。

(cherry picked from commit f584776f23c3bfd8fb2892155e6018a1ec57eac0)
 2026-10-19 16:09:03 +08:00
JianFeeeee
c53d1da2a6 docs: 内核性能实测基线 + payload 透传/保留键设计 
## docs/zh/kernel-performance.md（新增）

全部是实测数据，不是估算，每条标出测量方法与复现命令。

冷启动 15.4s（5 层 17 模块 + 22 插件），耗时分布：

	第 0→1 层  3.1s  20%   内存/ONNX/文档存储初始化
	第 1→4 层  2.4s  16%   LLM/知识库/agent 装配
	第 4→完成  9.9s  64%   22 个插件子进程建链

★ 与早期记录（1538–1709ms）的差异要说明：那是**纯内核**装配时间，
不含插件。两者口径不同，混用会得出"启动变慢 10 倍"的错误结论。

其余指标：RSS 26MB / 插件进程 12 个（13 个按需加载）/ 三层工具超时
（30s ctx → max(声明,参数) → 10m 硬上限）/ 上下文预算实测值 /
`offload_busy_after` 1m。

含三个实测踩过的性能陷阱：长工具执行期间 stop 无法生效、
同阶段重复注册静默覆盖、before_output 双触发路径。

## kernel-modularization-design.md 新增 2.7 节

注入 payload 的透传机制与保留键硬约束。

保留键必须覆盖两类：注入路径自己写入的（no_memory/context_policy/…）
与内核读取的语义键（interrupt/stop/command/…）。插件写保留键会被
跳过并记日志 —— 允许覆盖等于允许伪造"这条不记记忆"或"这条立即打断"，
那是权限提升。

同时记录 output_send__* 的 stage 语义：before_output/after_output
有两条触发路径，output.go 那条才是"消息真发出去"的时刻，而它历史上
连 Extra 都没初始化（实测 extra_keys=0）。

## 设计过程中的一次返工

曾加 InjectOptions.Meta，等于把同一件事做两遍且只服务注入路径。
用户指出后改为复用 InputEvent.Payload 的扩展口，所有注入路径共用。
 2026-10-18 18:36:26 +08:00
JianFeeeee
ecffb8a7de test(plugin): InjectOptions 含 map 后不可比较，改逐字段验零值 
Payload 字段（map[string]interface{}）加进 InjectOptions 后，
结构体不再可比 ⇒ `z != sdk.InjectOptions{}` 直接编译失败
（invalid operation: struct containing map cannot be compared）。
 2026-10-18 18:30:04 +08:00
JianFeeeee
aad8ddbf1e fix(core): output_send 的 stage 补 Extra 与 after_output 
## 缺陷（2026-10-18 实测定位）

`before_output` 被两个语义共用：

	emitResponse（eventloop.go）   = 一轮的回复，turn 边界
	output.go                      = 单次 output_send__* 的工具输出

**真正把消息发出去的是后者**，而它构造 stageCtx 时连 Extra 都没初始化：

	stageCtx := &sdk.StageContext{
		FinalText: payload,
		Phase:     sdk.StageBeforeOutput,
	}

诊断日志实证：`[qq-dbg] before_output: input_source="" qq_uid=<nil> extra_keys=0`

后果：通道插件在"消息即将发出"这个最需要上下文的时点，什么都读不到。
QQ 的「对方正在输入中」因此一次都没能触发。

## 修法

Extra 补三个键：

	output_channel  目标通道（插件据此判断"是不是发给我的"）
	output_meta     本次发送的 meta 原文（user_id / group_id 在里面）
	output_type     text / image / file / voice

## 同时补上 after_output

这是"消息真的送达"的时刻，但此前只有 before_output。没有配对收尾，
插件只能等自己的超时（QQ 那边是 30 秒）—— 用户看到指示器挂很久。

阶段顺序：before_output（可改写 payload/拦截）→ Execute → after_output。

## 为什么 after_output 放在 Execute 成功之后

失败时不发 after_output：消息没送达，"发出后收尾"的语义不成立，
提前触发会让插件误以为已经发出去（进而在状态跟踪上记错）。
 2026-10-18 18:01:15 +08:00
JianFeeeee
70f7bea4b9 feat(io): InjectOptions.Payload 业务字段扩展，透传到本轮 stage 
## 为什么需要

QQ 的「对方正在输入中」必须只在**自己引起的** before_output 里发，且要
知道发给谁。但两条路都断了：

	on_input 的 stageCtx  是局部变量（stageCtxFromInput），runStage 完就丢
	before_output 的 stageCtx 是内核**新建**的（emitResponse）
	⇒ 两者**不共享 Extra**

## 第一版是错的（用户指出）

我先加了 `InjectOptions.Meta` —— 那是把同一件事做了两遍。用户直接问：
「为什么又额外定义了 injectMeta，而不是包含在 inputch 的请求体中？」

查证后的真实边界：`InputEvent.Payload` **本就是通道送入内核的请求体**，
身份信息本该在那里。但 `IOInjector` 接口全是
`(source, channel, text, opts)`，插件无法给 payload 加字段 —— 所以
payload 需要一个**扩展口**，而不是一个平行的新概念。

改名为 `Payload` 还有一个实际好处：所有注入路径（HTTP/CLI/ACP）共用
同一套机制，不是注入专属。

## 内核怎么处理

	注入点 opts.Payload
	  → 与真 payload 合并（**内核保留键不可覆盖**）
	  → emitResponse 把非保留键原样透传到 stageCtx.Extra

保留键清单 `reservedPayloadKeys` 覆盖注入路径自身写入的键
（no_memory/context_policy/recall_policy/scene_policy/cleaner_name/
priority/type/content）与内核读取的语义键。允许覆盖意味着插件能伪造
"这条不记记忆"或"这条要立即打断"——那是权限提升，不是便利。

拦截方式是**跳过**而非拒绝整次注入：插件可能只想带一个业务字段，
因顺手多写一个保留键就让整条注入失败，代价太大。

## 判据（4 条，变异 2/2 咬）

 · 插件字段原样进 payload
 · 保留键不可覆盖（逐个验证 11 个键）
 · 空 Payload 不改变旧行为
 · 保留字清单必须覆盖注入路径自己写入的键（否则新键=新提权面）

## 附带修掉的编译破坏

`internal/plugin/lua_surface_test.go` 用 `z != sdk.InjectOptions{}` 比较
零值 —— 结构体含 map 就**不可比较**，加了 Payload 后直接编译失败。
改为逐字段验证。
 2026-10-18 17:40:07 +08:00
JianFeeeee
40de84facc feat(systemd,webui,security): 数据目录一致性接线 + 内嵌主密钥注入 
## 1. 数据目录一致性（原为死代码）

`internal/systemd/sync.go` 能编译但**从未接线** —— 没有任何地方调用它。

内核有**两处**数据目录来源且不等价：

	-data <dir>            ← systemd 单元 → memory/graph.db、插件数据根
	core.daemon.data_dir   ← 数据库     → memory/text、documents、knowledge

不一致时数据**分裂**：图记忆在 A、文本/知识在 B，检索跨目录、备份会漏。
生产当前两者一致所以没暴露，但 WebUI 允许改 DB 里的值而**无任何提示**。

接线三处：

 · cmd/homed/main.go 启动时检查，不一致则打告警 + 内联修复命令
 · GET /api/v1/system/data-dir 返回诊断（只在真不一致时给 sync_command）
 · 判据 6 条（InSync/Clean/SyncCommand 内联 sed/备份/daemon-reload/drop-in）

★ 只告警**不改**：静默改 systemd 单元比不提示更危险 —— 改错了服务
起不来，而用户不知道是谁改的。命令里已内联 sed 替换，人复制执行即可。

## 2. 内嵌主密钥（方案 C）

build.sh 支持 `HA_EMBEDDED_KEY_HEX`（64 位 hex）经 -ldflags 注入。
从**环境变量**读而不是写进文件：本仓有两个公开远端，64 位 hex 一旦
写进被跟踪的文件就永久留在 git 历史里。

未设时不注入、不报错：开发机与 CI 本来就不该带生产密钥。
设了但格式不对则**中断构建**（`return 1`）—— 静默产出一个没有内嵌钥的
二进制，会让"防丢失"这个目的悄悄失效。

实测（真机）：磁盘上**没有** security.key 时，仅靠 embedded 密钥即可
Submit + 二次加载解密成功；日志确认
`密钥来源 embedded (构建期注入，指纹 0db8e9c5)`。

## 判据第一版的两个错误（记下来）

 · 没给 UnitPath 就断言"必须含 sed -i" —— 实际 sed 行只在 UnitPath
   非空时生成，判据误报。
 · 断言 `/` 必须转义 —— 但 sed 分隔符是 `|` 不是 `/`。`/` 无需转义；
   真正必须转义的是 `&`（sed 里表示整个匹配）与 `|`（分隔符）。
 2026-10-18 13:51:00 +08:00
JianFeeeee
6a15b80ee9 revert: 撤掉多余的 auto_start 门（调度器早已处理） 
## 为什么要撤

c426921 我以为"外部插件的 auto_start 完全不生效"。**判断错了。**

实机验证：13 个声明 auto_start=false 的插件在重启后确实没加载
（建链 22 → 11）。靠的是**既有机制**，不是我加的门：

	internal/kernelboot/scheduler.go:277  canLaunch: if !p.AutoStart { return false }
	internal/kernelmod/pluginhost/mod.go  buildSkipSet: catalog 里的插件全交给调度器
	internal/kernelmod/pluginhost/catalog_test.go:198  判据已覆盖

我当时只看到 `Load` 遍历目录时不查 auto_start，就断定该字段不生效 ——
那只是**没看到另一条路径**（LoadSkipping + 调度器分层）。

## 为什么必须撤而不是留作"兜底"

· 两处逻辑重叠：调度器按 catalog 决定跳过，我的门在 loadOne 里再判一次。
  两处各说各话，将来改一处漏另一处就是新的静默不一致。
· 我那条判据测的是**我自己加的门**，不是真实行为 —— 它变绿不证明任何
  产品行为正确（撤掉这道门，判据红，但产品行为不变）。
· **没验证过的防御就是噪音。**

## 撤回后行为不变

按需加载链路实测（weather）：
	plugin_start → loaded=true / alive=true / pid=838963
	plugin_stop  → loaded=false / alive=false，pid 消失
	两者都 persistent="未改动"（不动持久禁用清单）

这些都发生在**没有**我这个门的旧二进制上。
 2026-10-18 13:36:16 +08:00