# WebUI 布局与配置归位修复计划

## 一、背景

上一轮 SDK 接口化改造完成并部署后，用户指出三个问题：

1. **WebUI 窄屏布局损坏**：顶部 `<nav>` 为桌面式横排（标题 + 6 tab + 连接指示器 + 语言 + 主题），
   窄屏断点仅缩小字号不换行，`body { overflow-x:hidden }` 直接把溢出的 tab 裁掉不可点击。
2. **OpenClaw skills 目录被注册为核心配置**：`core.skills.path`（"OpenClaw 技能存储目录"）注册在核心
   配置表（`internal/config/registry.go`），但全仓无任何读取方（死配置）；实际生效路径是
   clawhubadapter 自己的 `skills_dir` 配置（`config_clawhubadapter` 表 + `core.daemon.data_dir`/skills 兜底）。
   技能目录是 clawhubadapter 适配加载的领域，不应属于核心配置。
3. **clawhubadapter 加载的微信插件成为独立配置项**：设置页出现 `channels.wechat.*`（核心表）、
   `plugin.wechat.*`（config_wechat 表）、`config_openclaw_weixin`（空表）等多处微信配置，
   全部为历史残留——当前代码零引用，OC 技能的配置实际在其自身 `~/.openclaw/openclaw.json`。
   设置页会把核心表全部键 + 全部插件表当作配置组展示，导致残留以"独立配置项"形态出现。

## 二、修复计划

| # | 动作 | 位置 | 风险 |
|---|------|------|------|
| A | 窄屏导航修复：<768px 下 nav 横向滚动、h1 缩写、连接指示器简化；body 溢出裁切改为 nav 内滚动 | `cmd/gui/renderer/style.css` | 无 |
| B | 删除 `core.skills.path` 核心配置注册（set + RegisterDef 两处） | `internal/config/registry.go` | 无（无读取方） |
| C | 备份后清理残留配置：`channels.wechat.*` 键、`config_wechat` / `config_openclaw_weixin` / `config_openclaw` 表（含微信 token，先备份） | 生产库 `/home/newqqagent/config.db` | 低（当前代码不读） |

## 三、实施记录

### 步骤 A：webui 窄屏导航修复（已完成）
- 修复对象为 webui HTTP 服务真正前端 `internal/plugins/webui/dashboard.html`（`go:embed` 内嵌，
  登录后 `/` 返回，104KB；cmd/gui 是独立 electron 客户端，非 webui 一部分）。
- `<768px` 断点：`nav { overflow-x:auto; scrollbar-width:none; flex-wrap:nowrap }` + `::-webkit-scrollbar { display:none }`；
  `nav a { white-space:nowrap; flex-shrink:0 }`；`nav h1 { font-size:0 }`（保留 logo 图、隐藏文字，弥补窄屏空间）；
  `nav > div { flex-shrink:0 }` 右侧语言/主题/退出按钮不压缩。
- 顺带在 cmd/gui（electron 客户端）同步了窄屏样式与消息来源徽标（`app.js`/`style.css`，客户端窗口缩放同样受益；
  客户端需另行构建 electron 应用才生效）。
- 验证：部署后 `/` 返回的 dashboard 含 `scrollbar-width:none`/`font-size:0`/`::-webkit-scrollbar` 规则。

### 步骤 B：删除 core.skills.path 核心配置（已完成）
- 删除 `internal/config/registry.go` 两处：`set("core.skills.path", ...)`（SeedDefaults）与
  `reg(ConfigDef{Key:"core.skills.path", ...})`（定义注册）。
- 理由：该键全仓无读取方（grep 仅命中注册处），实际生效路径是 clawhubadapter 的 `skills_dir`
  （config_clawhubadapter 表 + `core.daemon.data_dir`/skills 兜底）。技能目录属 clawhubadapter 适配领域。
- 验证：`grep -rn "skills.path" --include="*.go"` 零命中；部署后设置页无 `core.skills.path`。

### 步骤 C：清理生产库残留配置（已完成）
- 操作前 `sqlite3 .backup /tmp/opencode/config.db.pre-clean.bak`（含微信 token 数据）。
- 删除：`config` 表 `channels.wechat.*` 3 键 + `core.skills.path` 键；`DROP TABLE config_wechat /
  config_openclaw_weixin / config_openclaw`（三者均为历史残留：当前代码零引用，clawhubadapter 实际
  使用 config_clawhubadapter 表；OC 技能配置在其自身 `~/.openclaw/openclaw.json`）。
- 验证：设置页总键数 138→129，无 wechat/weixin/skills.path 残留，`plugin.clawhubadapter.skills_dir /
  simulator_dir` 正常；服务 healthcheck ready、clawhubadapter "OC plugin manager started"。

---

# SDK Stop 注册接口（RegisterStopHandler）计划

## 一、背景

2026-08-01 20:00 起生产 homeagent 进入崩溃循环（`fatal error: thread exhaustion`，
systemd 重启计数 61+）。排查定位为 SDK 示例插件 `calendar`（示例源码在 SDK 仓库
`example/calendar`，生产以 plugin.so 形态加载）三个缺陷叠加：

1. **农历引擎 3 个 bug**（`daysInLunarYear` 位循环 `i > 0` 应 `i > 0x8`、缺闰月天数、
   `lunarToSolar` 内层重复加闰月）→ `lunarToSolar(2026,4,12)` 返回 **2062-11-16**（偏移 36 年），
   农历重复事件（`lunar_yearly`）的 next 被生成到遥远错误日期。
2. **`cleanupPastEvents` 保留过时重复事件** → 每 30s ticker 对已到点的重复事件再生成一份 next，
   事件从 7 个爆炸到 **45612 个**（15MB events.json）。
3. **无提醒投递保护**：15018 份同时到点的事件一次性 `go sdk.InjectInterruptText(...)` 投递
   → interrupt 风暴 → goroutine/线程耗尽。

处置：修复农历引擎 3 处 + next 去重 + 清理过时重复事件，用**新版 SDK 仓库 + 新版 plugindev 工具链**
重建 `calendar_linux_amd64.hmap`，经 **webui `POST /api/v1/plugins`**（透明代理到 pluginmgr 安装接口）
重装，重启验证收敛（事件 4 个、next 正确生成 2027-05-17、0 崩溃）。

**过程中暴露的能力缺口**：SDK 只有 `Plugin` 接口的 `Name/Start/Stop`，**没有 stop 注册接口**
（`RegisterStopHandler`/`OnStop` 均不存在，SDK v0.7.2/v0.8.0/master 一致）。插件停止时只能在自己的
`Stop()` 里写清理逻辑，SDK 层无法统一执行"停止时清理"回调；calendar 的 `Stop() { p.saveEvents() }`
还会用陈旧内存把已清理的数据写回磁盘（曾导致删除的重复事件复活）。

## 二、计划

| # | 动作 | 位置 | 风险 |
|---|------|------|------|
| 1 | 公共 SDK `PluginSDK` 加 `RegisterStopHandler(fn func())` + `RunStopHandlers()`（幂等、后注册先执行），两处同步 | `third_party/homeagent-sdk/sdk/plugin.go`、SDK 仓库 `sdk/plugin.go` | 低（纯新增，内置 SDK 内嵌透传） |
| 2 | 内核 Registry 保存每插件 SDK 引用（`sdkRefs`），`StopAll`/`ReloadOne`/`DisablePlugin` 调 `Stop()` 前执行 `RunStopHandlers` | `internal/plugin/registry.go` | 中（生命周期路径，需回归 reload/disable） |
| 3 | 工具链 plugindev：z_bridge 模板 `bridgeState` 存 SDK，`StopPlugin` 先 `RunStopHandlers()` 再 `plugin.Stop()`；init 脚手架模板加演示 | SDK 仓库 `tools/plugindev/templates.go`、`templates/main.go.tmpl` | 低 |
| 4 | 内置示例插件演示（如 timer：ticker 停止改为 stop handler） | `internal/plugins/timer/plugin.go` | 低 |
| 5 | 外部示例插件同步（`example/calendar` 的 `saveEvents` 改由 stop handler 执行，验证 z_bridge 链路；其余 example 加演示） | SDK 仓库 `example/*` | 低 |
| 6 | 文档同步：SDK README 生命周期章节 + 主仓插件开发文档 | SDK 仓库 `README.md`/`README_EN.md` 等 | 无 |

## 三、实施记录

1. SDK 公共层（`RegisterStopHandler` + `RunStopHandlers`：后注册先执行、执行后清空幂等）已落地
   `third_party/homeagent-sdk/sdk/plugin.go`，并同步到 SDK 仓库 `/tmp/opencode/sdk-repo/sdk/plugin.go`（两处一致）。
2. 内核 Registry（`internal/plugin/registry.go`）新增 `sdkRefs map[string]*sdk.PluginSDK` + `runStopHandlers`，
   `loadOne` 注册、`StopAll`/`ReloadOne`/`DisablePlugin` 在 `Stop()` 前执行（共 4 处调用点）。
3. 工具链 plugindev（SDK 仓库）：linux `tmplLinuxBridge` 的 `go_stop_plugin` 先 `RunStopHandlers()` 再 `plg.Stop()`；
   windows `tmplBridge` 的 `bridgeState` 加 `sdk` 字段、`StopPlugin` 同链路；`tmplPluginGo` + `main.go.tmpl`
   脚手架加 `RegisterStopHandler` 演示。plugindev 重新编译通过（GOPATH=/root/go）。
4. 内置 timer 插件演示：`close(p.stopCh)` 移入 stop handler，`Stop()` 只 `wg.Wait()`。
5. 外部示例：`example/calendar` 的 `saveEvents` 改为 `s.RegisterStopHandler(p.saveEvents)`，
   `Stop()` 删除写盘调用（持久化交由 stop handler，避免陈旧内存复活已删事件）。
6. 文档：SDK 仓库 `README.md`/`README_EN.md` 生命周期章节补充 RegisterStopHandler 说明。
7. 构建测试：主仓 `go build ./...` + `go test ./internal/sdk/... ./internal/plugin/...` 全绿；
   SDK 仓库 `go build ./...` + `go test ./sdk/...` 全绿。
8. 生产部署验证：新 plugindev（--no-bundle）重建 `calendar_linux_amd64.hmap`（md5 084e97c0…，strings 确认
   `go_stop_plugin → RunStopHandlers → saveEvents` 编译进 plugin.so）；webui API 删旧装新；重装新内核
   homed（含 sdkRefs/runStopHandlers）；两次重启事件稳定 3 个不复活、events.json mtime 与 stop 时刻吻合
   （saveEvents 经 stop handler 真实执行）、0 次 thread exhaustion、服务 active。


---

# clawhubadapter OpenClaw 通道插件兼容修复计划

## 一、背景

生产 `core.llm.provider` 已是 mock LLM 源（`core.llm.sources.mocktest`，base_url
`http://127.0.0.1:18080/v1`、model mock-model、adapter openai），mock LLM 服务常驻运行。
借助 **mock 通道插件**（`/tmp/opencode/mock-skills/mock-wechat/`，完全复刻 openclaw-weixin 的
真实注册格式 `register(api) → api.registerChannel({ plugin: ChannelPlugin })`）放入生产 skills 目录
端到端复现，得出如下结论：

**已验证可用链路**：manager 加载 mock 插件 → Go 端识别 `ocplugin mock-wechat handled by manager` →
注册工具 `mock-wechat_read_mock_wechat_input`/`mock-wechat_mock_echo` → `RegisterOutputChannel("mock-wechat")`
→ mock 自推消息经 `channel_input` 通知 → `[agent] interrupt from manager/mock-wechat` →
mock LLM 正常回复（195ms）。

**复现的核心缺陷**（真实通道插件 wechat/dingding"根本不可用"的根因）：

1. **输出断链**：manager `tools/call` 通道分支只认 `channelPlugin.outbound.sendText/sendMedia`
   （旧格式），真实 ChannelPlugin（openclaw-weixin 等）无 outbound →
   `tools/call mock-wechat → error: "channel mock-wechat has no output handler"`。
2. **生命周期静止**：manager mock api 从不调用 `gateway.startAccount/stopAccount`，也无
   `api.runtime`/`channelRuntime` → 通道插件加载后永不启动（不登录、不轮询、不收消息）。
3. **输入依赖错位**：真实插件把消息经 `channelRuntime.reply.dispatchReplyWithBufferedBlockDispatcher`
   推送（manager 完全无此对象），而不是调 `api.submitInput`。
4. **stdout 污染**：插件 `console.log` 直接进 JSON-RPC 流，Go 端 readLoop 跳过非 JSON 行，有丢通知风险。

**wechat 通道的心跳机制**（`openclaw-weixin/dist/index.js` `pollLoop`，448 行起）：每账号一个常驻
`pollLoop`，循环 `POST ilink/bot/getupdates`（body `{get_updates_buf}`，超时 35s）——**长轮询即心跳**：
服务器收到 poll 请求即知通道在线，新消息随 poll 响应 push 回来；超时视为空响应继续轮询，真错误延时
5s 重试。**与 gateway 生命周期强绑定**：

- `pollLoop` 只由 `gateway.startAccount(ctx)` 启动；不被调用 → 心跳/收消息全断（服务器侧认为通道离线）。
- `startAccount` 末尾 `await new Promise(()=>{})` **永久挂起**——OC gateway 靠它配合 health-monitor
  （startAccount 退出 → 判定账号崩溃 → 重启账号）。manager 调 `startAccount` 必须 **fire-and-forget**。
- 停靠 `gateway.stopAccount(ctx)`（`ctx.account.accountId` 定位），停止时经 `statusSinks` 调
  `ctx.setStatus({running:false, connected:false, lastStopAt})`；启动即上报
  `ctx.getStatus()/ctx.setStatus({...running:true, connected:true, lastStartAt})`——`connected` 是
  gateway 判断账号存活的依据。
- `sendTyping`（ilink/bot/sendtyping + typing_ticket）是打字指示，非心跳，无需支持。

## 二、修复计划

| # | 动作 | 位置 | 风险 |
|---|------|------|------|
| A | manager 提供 **gateway 生命周期桥**：channel 插件注册后自动 `gateway.startAccount(ctx)`（fire-and-forget，不等待挂起的 Promise），构造完整 ctx `{account, cfg, channelRuntime, getStatus, setStatus}`；Go 端 `channel_stop` 通知 → `stopAccount` | `internal/plugins/clawhubadapter/manager/main.js` | 中 |
| B | 实现 **channelRuntime mock**：`reply.dispatchReplyWithBufferedBlockDispatcher`（deliver 回调 → `channel_output` 通知送 Go 端）、`getPolls`（OC 通用通道轮询输入）、`call` 透传 | 同上 | 中 |
| C | `tools/call` 通道分支改造：无 `outbound` 的 ChannelPlugin 改走 channelRuntime 事件式发送（agent 输出 → deliver），不再报 "no output handler" | 同上 | 低 |
| D | 状态上报透传：`setStatus` 经 `channel_status` 通知 → Go 端可查；health-monitor 语义（startAccount 保持挂起） | 同上 | 低 |
| E | stdout 卫生：插件 `console.log` 重定向 stderr（或 JSON-RPC 流感知封装），杜绝污染 | 同上 | 低 |
| F | Go 端：`channel_output`/`channel_status` 通知接入（事件分发），通道输出 handler 保持 `sp.CallTool` | `internal/plugins/clawhubadapter/registry.go`、`plugin.go` | 中 |
| G | 端到端验证：mock 通道插件 + mock LLM（生产环境，临时放入/移出 skills 目录）复跑全链路（登录启动→收消息→回复→出站→停止） | 生产 | 低 |

## 三、实施记录

（逐步填写）

1. **manager/main.js — 通道运行时与生命周期桥（已完成，独立运行验证）**
   - `makeChannelRuntime(chName, ch)`：`reply.dispatchReplyWithBufferedBlockDispatcher(opts)` 提取
     `dispatcherOptions.deliver`/`typingCallbacks` 按 `ctx.AccountId` 挂到 `ch.deliverers`，随后
     `notify('channel_input', {channel, payload:{content: BodyForAgent||Body, from, sessionKey, accountId,
     messageSid, chatType, raw}})` 入站；返回 dispatcher（sendNow/addToBuffer/sendBuffer/closeBuffer）。
     `chatPolls`/`getPolls` 空转（防断连误判）、`call` 转发 `channel_output` 通知。
   - `startChannels(name)`：channel 插件注册后自动枚举账号（`config.listAccountIds`→`resolveAccount`，
     缺省 `['default']`），构造完整 ctx `{account, cfg, channelRuntime, getStatus, setStatus}`，
     **fire-and-forget** 调 `gateway.startAccount`（真实插件会永久挂起，绝不等待）；崩溃/状态变更经
     `channel_status` 通知透传（health-monitor 语义：startAccount 不退出=账号存活）。
   - `stopChannels(name)`：逐个账号 `gateway.stopAccount`；进程 SIGTERM/SIGINT 时统一执行优雅停靠。
   - `tools/call` 通道分支：保留 outbound（旧格式）→ 新增 **deliver 事件式发送**
     （`deliverItem` 按 accountId 取 deliver + typingCallbacks.onReplyStart/onCleanup 包裹）→
     无 deliver 时降级 `channel_output` 通知 → 兜底报错。不再出现 "has no output handler"。
   - **stdout 卫生**：全局 `console.log` 重定向 stderr，JSON-RPC 流仅承载协议帧。
2. **mock 插件升级（/tmp/opencode/mock-skills/mock-wechat/index.js）**：完全复刻真实 weixin 行为——
   `gateway.startAccount` 永久挂起 + `setStatus` 上报 + `setInterval` 心跳轮询 + 800ms 后经
   `dispatchReplyWithBufferedBlockDispatcher` 推送入站（deliver 本地记录发送）；`stopAccount` 停轮询+状态置否。
3. **manager 独立运行验证（通过）**：`channel_status` 启动上报（running=true connected=true）；
   `tools/call mock-wechat` → `{"status":"sent","via":"channelRuntime.deliver"}`，插件 deliver 收到
   `text="hello from agent"` 且 typing onReplyStart/onCleanup 正确包裹；心跳 poll #1-4 常驻；
   SIGTERM → `stopAccount called` 退出码 0；插件 console 输出全部走 stderr（协议流零污染）。
4. **Go 端通知接入（plugin.go translateAndRegister + registry.go 状态缓存）**：`channel_status` 存
   `channelStatus` map（可查）+ 日志；`channel_output` 降级事件日志。`go build ./...` 通过。
5. **回复闭环修复（同步注入）**：`channel_input → InjectInterruptText` 的 InputEvent 不带 ResponseCh
   （internal/agent/io/channel.go:276），agent 回复在 emitResponse（eventloop.go:384）被静默丢弃。
   改为 `s.InjectInputSync(pluginName, channel, "text", payload)`（内部 SDK 已有 4 参版本，返回
   `*OutputEvent`）同步等待回复 → 提取 `Payload["content"]` → `sp.CallTool(channel, {payload, meta})`
   → manager `tools/call` → deliver → 插件发送 → 微信送达。公共 SDK IOInjector 同步补
   `InjectInputSync(source, channel, text) string`（ioAdapter 实现，供外部插件一致使用）。
6. **mock LLM 恒定文本化**：/opt/llm-mock/mock_server.py `decide()` 删除工具调用分支，一律回文本
   （"无论收到什么消息都通过微信插件发送"），保证每条入站消息回复必然走通道输出。
7. **生产微信闭环验证（通过）**：用户微信发"你好..." → pollLoop 收到 → dispatchReply →
   InjectInputSync → mock LLM 回文本 → CallTool(wechat) → deliver → `POST ilink/bot/sendmessage`
   → **status=200 message_id=7489545365740590088**，微信收到"（mock）已收到消息，长度 324 字符。"
8. **通用性审查（无硬编码）**：manager/plugin.go/registry.go 均无 weixin/wechat 特判，全部按 OC 规范
   字段实现（gateway/config/capabilities/channelRuntime/deliver/typingCallbacks）。修正规范签名参数
   约定：`listAccountIds(cfg)`、`resolveAccount(cfg, accountId)` 正确传 cfg。
9. **已知边界**（非硬编码，架构性）：a) `channelRuntime.getPolls/chatPolls` 返回空 msgs——依赖
   runtime 轮询输入的通用通道型插件收不到消息（weixin/dingding 类自带 pollLoop 的通道不受影响）；
   b) `gatewayMethods` 登录流程（web.login.start/QR 扫码）未实现（CLI 有 stub），通道凭 token
   配置直连；c) startAccount ctx 提供 account/channelRuntime/cfg/getStatus/setStatus 核心字段。
10. **补充边界 a) getPolls/chatPolls 消息源（已完成）**：manager `makeChannelRuntime` 的
    `chatPolls/getPolls` 改为读 `ch.pollQueues`（按 accountId 队列，poll 取走即消费）；新增
    `channel/send` RPC（Go 端注入 → 队列 → 插件轮询取走）；Go 端 `SendToChannel(channel, payload)`
    + `ChannelSender()` 单例（Start 时置位）。验证：mock-poll 插件（纯 chatPolls 轮询型）——
    `channel/send` → `{"status":"queued"}` → `[mock-poll] poll got msg` → dispatchReply →
    `channel_input` 入站完整（content/from/sessionKey/accountId/messageSid/chatType）。
    微信链路回归正常（Polling started + channel_status running=true）。
11. **边界 b) 登录流程核实（已解决，无需实现）**：真实登录机制是 **SKILL 脚本旁路**——
    `weixin-openclaw-login` SKILL 的 `scripts/get-login-url.js`（ilink 二维码 URL）+ 
    `poll-login-status.py`（轮询扫码状态）→ agent 经 exec 执行 → 拿 bot_token 写入
    `~/.openclaw-weixin/account.json`（2026-07-28 17:31 创建，token 有效）→ 插件启动
    `resolveAccountData` 直读。不依赖 manager gatewayMethods（web.login.start 等 OC gateway
    协议 stub 不影响真实使用）。
12. **clawhubadapter 全量管理接口（已完成并验证）**：向 agent 暴露完整插件/通道管理面——
    - 新工具：`clawhubadapter_plugin_info`（类型/工具/关联通道详情）、`plugin_reload`（reloadPlugin）、
      `channel_list`（全部注册通道 + 实时状态）、`channel_send`（SendToChannel 投递）、
      `channel_start`/`channel_stop`（manager `channel/start`、`channel/stop` RPC）。
    - manager 新增 RPC：`plugins/channels`（registeredChannels 摘要含 status/accounts）、
      `channel/start`（fire-and-forget startChannels 恢复账号）、`channel/stop`（stopAccount，
      按 channel 全停或按 accountId 单停，省略 channel 则全部停止）。
    - Go 侧 `channelSummary(mgr)` 合并 manager 注册信息与 `channel_status` 实时缓存（缓存优先）。
    - 端到端验证（生产实例，LLM 为本地 mock 源）：微信发"你好通道..." → agent 执行
      `channel_list` → `- wechat | plugin=openclaw-weixin type=text running=true connected=true
      accounts=[default]` → 回复送达；发"注入..." → 执行 `channel_send` → "消息已投递到通道
      wechat" → 回复送达。standalone manager 另验证 `channel/start`（mock-wechat startAccount
      重新执行、心跳恢复）与 `channel/stop`（stopAccount called）。
13. **插件删除回调 onRemove 全套（已完成并验证）**：`RegisterOnRemoveHandler`（仅卸载触发、
    重载/禁用不触发，与 stop handler 互补——stop 每次停止都执行）。registry.RemovePlugin 流程：
    stop handlers → Stop → runOnRemoveHandlers → 移除 plugins/sdkRefs/instances →
    UnregisterPluginTools → **配置清理**。配置清理含两层：`ConfigRegistry.RemovePlugin`
    删除 defs 中 `plugin.<name>.*` 配置项定义 + DROP `config_<name>` 插件配置表
    （含用户设置值，ListPlugins 基于 config_% 表枚举故配置区完全消失）；已用临时程序验证
    （before: defs=1/plugins=[timer] → after: defs=0/plugins=[]）。示例盘点（SDK 仓库 15 个）：
    calendar（events.json）、memo（memos.json）、rss（订阅数据目录）、weather（缓存目录）已加；
    files（filesDir 为用户配置的访问根目录，默认 /）、bili/qq（用户下载资产）、
    ocr（函数内 defer RemoveAll 自清理）按语义不加；plugindev 模板 main.go.tmpl + README.tmpl
    含 onRemove 演示；SDK README/README_EN 生命周期文档补"删除清理（onRemove）"小节。

14. [2026-08-03] SDK 工具链/打包/重装 + dlclose 修复：
    - 工具链源码位置澄清：SDK 仓完整内容位于 third_party/homeagent-sdk（主仓 .gitignore 仅跟踪
      sdk/meta/go.mod，"两个远程仓库各取所需"；/tmp/opencode/sdk-repo 为工作克隆，远程=gitcode）。
    - 工具链支持公共 IOInjector.InjectInputSync：CORE_INJECT_INPUT_SYNC=47（C 桥 dispatchIO
      callString 回传回复文本）；主仓 cabi loader case 47 用内部 4 参版 InjectInputSync 取
      OutputEvent.Payload["content"] setResult（meta.go ID 47 + loader.go，主仓 3f252ed）。
    - plugindev 构建环境：GOMODCACHE=/root/go/pkg/mod（yaegi 缓存所在）、GOPROXY=off。
    - 工具链打包 memo：plg.json BOM 去除、name_en "Memo/Notes"→"Memo"（toSnake 不处理斜杠，
      name_en 带 / 会使 hmap 名含子路径报错）；bundle=true 时走全平台交叉编译（本机无 darwin
      工具链），打包用 `build --no-bundle --target linux/amd64`；产物 dist/memo_linux_amd64.hmap。
    - 重装：pluginmgr HTTP API（127.0.0.1:9876）DELETE /plugins/memo 卸载（走内核 RemovePlugin
      + onRemove）→ POST /plugins binary body 传 hmap（返回 installed+checksum）；生效用
      webui `POST /api/v1/plugins/reload`（X-API-Key，生产 admin123）。
    - 关键 bug：Linux dlopen 同路径复用旧句柄——RemovePlugin/ReloadOne 只 Stop 不 dlclose，
      插件二进制更新后重载仍执行旧代码（生产 memo 装新版仍注册旧 3 工具）。修复：
      cabiPlugin.Close()（handle.Close）+ Registry.closeDynamic 在卸载/重载时调用（主仓 649e312）。
      生产 homed-new7 验证：memo 6 工具（memo_todo_add/complete/list + memo_memo_create/list/delete）
      注册正常，wechat 通道 running。
    - SDK 仓推送 b6e30f9（工具链 47 + 重建 bin 二进制 + memo plg.json + sdk/plugin.go 注释精简）。
15. [2026-08-03] 嵌套 git 恢复 + 工作区清理 + codegraph 索引修正：
    - 嵌套 git 恢复：third_party/homeagent-sdk 原本是"单仓库双提交"（目录内嵌套 .git 推 gitcode
      homeagent-sdk 仓，主仓 git 跟踪 sdk/meta/go.mod 推 HomeAgent 仓），嵌套 .git 此前被误删；
      已从 /tmp/opencode/sdk-repo 复制 .git 恢复（remote=homeagent-sdk.git，HEAD=b6e30f9，工作区干净），
      主仓 git 不受影响。以后 SDK 改动直接在 third_party 内 git commit+push（SDK 仓推送仍用带凭据
      URL https://JianFeeeee:BCkb32xBuLxWD9P4MmU8ydZ5@gitcode.com/JianFeeeee/homeagent-sdk.git），
      不再经 /tmp 中转。
    - /tmp 清理：删除 /tmp/opencode/sdk-repo、hasdk-fresh、plugindev-new、plugindev_new、mock-run、
      lunartest（SDK 中转/临时目录）；保留 homed-new*（生产二进制备份）、mock-skills 等非 SDK 内容。
    - replace 修正：go.mod 第 17 行已是 `./third_party/homeagent-sdk`（正确）；package-linux.sh
      prepare_gomod 优先用 $PROJECT_ROOT/third_party/homeagent-sdk，仅缺失时才 clone /tmp/homeagent-sdk
      兜底（主仓 108faac）。
    - codegraph 索引修正：根目录 codegraph.json（PROJECT_CONFIG_FILENAME）配
      includeIgnored+include: ["third_party/homeagent-sdk"]，codegraph index 后 Files 179→233，
      third_party 文件 7→61，tools/plugindev 与 sdk/plugin.go（InjectInputSync 等）均可查询
      （此前嵌套 SDK 仓被主仓 .gitignore 挡在索引外）；codegraph sync 不感知配置变更，需 index 全量重建。