0a6e2b7dc4
为插件作者建一个文档站，重点是**能按描述搜到 API**，以及**明确能力边界**。
## 为什么 API 参考要生成而不是手写
公开 API 面有 115 个符号、11 个接口。手抄必然与代码漂移——这是文档站最常见的
死法（本仓 README 里已经有过几处「文档说一套、代码是另一套」）。
所以 `tools/apidoc` 直接从 `sdk/*.go` 提取签名、文档注释与代码块示例，渲染成
`docs/api/*.md`。发现文档不对时改的是**源码注释**，不是生成物。生成页首行带
「勿手改」标记，防止有人改了下次构建白改。
- `extract.go`：go/ast + go/doc 提取（只用标准库，离线可跑，不引入依赖）
- `gensite/`：渲染 Markdown + 检索索引
- `gensite/usages.go`：从 `example/` 21 个示例插件里反查**真实调用点**，
贴在每个 API 下（源码注释里几乎没有可运行示例，但示例插件都是能编译跑的真代码）
## 能力边界：写这个站时查出的三处文档错误
这是本次最有价值的部分。原以为「公开 SDK 里有的 API 外部插件都能用」，
实测对照桥接模板后发现三处不符，站内已更正：
1. **`PluginMgr()` 被写成「仅内置可用」——错的。** 桥接模板第 692 行显式
`base.SetPluginMgrAPI(procPluginMgr{})`，公开 `PluginMgrAPI` 注释也写「外部插件可调用」。
真正的区别是**方法数**：公开面 3 个（ReloadOne/ListLoadedPlugins/IsPluginDisabled），
内部面 9 个。容易混淆是因为两个包里有同名但不同的接口。
2. **`Events()` 外部插件恒为 nil。** `SetEventSubscriber` 全仓只有定义、无调用点，
故 subscriber 从未被注入。外部插件的事件订阅实际由生成的运行时走
`events.subscribe` RPC 完成——旧文档把它当成可用入口，会让人写出必然失效的代码。
3. **`UnregisterOutputChannel` 是静默无效，不是报错。** 桥接只注入 registrar、
不注入 unregistrar，于是 `regOutputUnreg == nil`，函数命中 else 分支**直接返回 nil**
（sdk/plugin.go:539-549）——不报错、通道也没注销。
每条裁定的依据写进 `tools/apidoc/tiers.json`（文件:行号 或 grep 结论），
站上以告警框呈现，读者可自行核对。判断依据三源：桥接模板的 `base.Set*` 注入点、
`internal/sdk` 完整面、`internal/plugin/proc/protocol.go` 的 RPC 表。
## 检索（用户的核心诉求）
两套互补：
- **MkDocs 内置搜索**：全文，中文走 jieba 分词。
- **自建 API 检索**（`docs/javascripts/api-search.js` + `assets/api-index.json`）：
支持四类查询——按名称、**按功能描述**（「注册工具」→ RegisterTool、
「崩溃」→ SetAutoRestart）、按 `限定符.方法`（`memory.recall` → MemoryAPI.Recall）、
按签名片段（`(string) error`）。并标出「仅内置」，避免外部插件作者踩空。
自建的理由：Material 内置搜索按整页文本索引，搜 `InjectText` 会列出所有提到它的
页面，但分不清哪条是它的定义；而且它要等 mkdocs build 才更新。
## 文档结构
- `docs/guide/`：快速开始、Go/Lua 首个插件、能力边界、打包发布、多平台、受限 SDK 与安全
- `docs/api/`：10 个按「你想做什么」划分的章节（工具/阶段/记忆/通道/配置/生命周期/
事件/LLM/常量/桥接）+ 仅内置汇总页
- `docs/versions.md`：SDK 版本语义（跟随内核中版本、patch 恒为 .0）、
1.0.0 是唯一破坏性变更、RPC 协议版本
## 验证
- `mkdocs build --strict` 零告警
- 23 个页面的全部站内链接与锚点可达（自动校验）
- 1440 / 768 / 390px 三视口：无横向溢出、无控制台错误
- 四种检索模式实测有结果且跳转锚点正确
- 构建产物 `site_build/` 已 gitignore
用法：`tools/apidoc/build.sh`（生成+构建）、`tools/apidoc/build.sh serve`（预览）。
4.6 KiB
能力边界：哪些 API 外部插件能用
HomeAgent 有两类插件：
| 类型 | 说明 | 分发 |
|---|---|---|
| 外部插件 | 第三方开发，编译成 .hmap 后安装 |
独立分发，可闭源 |
| 内置插件 | 编译进内核，init() 自注册 |
随内核发行，需合入主仓 |
SDK 包是同一个 gitcode.com/JianFeeeee/homeagent-sdk/sdk，但两类插件拿到的
能力不同：外部插件跑在独立进程里，由内核通过桥接注入能力（IPC，不是共享内存里的直接调用）。
本页说明边界在哪、为什么，以及怎么在写代码前就知道某个 API 是否可用。
一句话规则
公开 SDK 包里声明的符号，不等于外部插件拿得到。
原因是：有些能力只有进程内的内置插件才可能拥有（比如直接读事件发布通道、 直接注入到内核 IO 层）。外部插件通过桥接运行时拿到的是一份受注入的能力集合。
外部插件不可用的 API
这些 API 在公开包里存在，但在外部插件路径上拿不到。文档里每条都带 仅内置 标记， 完整清单见 仅内置插件可用。
| API | 外部插件的实际情况 | 该用什么 |
|---|---|---|
sdk.PluginSDK.Events() |
恒为 nil。桥接运行时不注入 event subscriber（SetEventSubscriber 全仓无调用点） |
桥接运行时已按你的声明完成 events.subscribe；Lua 插件用 sdk.events.subscribe |
sdk.PluginSDK.SetEventSubscriber |
无人调用 | 同上 |
UnregisterOutputChannel |
桥接只注入 registrar、不注入 unregistrar，调用是静默无效（返回 nil，不报错也不注销） | RegisterOutputChannel 可用；注销需重载插件 |
SocialAPI 的写操作 |
公开接口只有 6 个只读方法 | 读用 s.GetPerson 等；写需内置插件 |
EventSubscriber.Publish |
公开接口刻意只有 Subscribe，没有 Publish | 只订阅 |
PriorityL4 |
声明会被内核夹到 L3 | 用 L1–L3 |
RegisterChannel / ListChannels / OutputChan / InjectInput / InjectInterrupt |
只存在于内核内部 SDK | RegisterInputChannel / RegisterOutputChannel / InjectText 等公开方法 |
PluginMgr() 的完整能力 |
公开 PluginMgrAPI 只有 3 个方法（ReloadOne / ListLoadedPlugins / IsPluginDisabled） |
就这 3 个；ReloadPlugins/Disable/Remove 属内部接口 |
!!! warning "两处常见的文档错误（本站已更正）"
1. PluginMgr() 不是「仅内置可用」。桥接模板显式注入了它
（base.SetPluginMgrAPI(procPluginMgr{})），公开 PluginMgrAPI 也注明
「外部插件可调用」。真正的区别是方法数量：公开面 3 个，内部面 9 个。
容易混淆是因为两个包里有同名但不同的接口：
sdk.PluginMgrAPI（3 方法）与 internal/sdk.PluginManager（9 方法）。
2. Events() 恒为 nil 这件事以前没写清。旧文档把 Events() 当作
可用的订阅入口，但桥接运行时不注入 subscriber。外部插件的事件订阅
实际由生成的运行时通过 events.subscribe 完成。
判定依据来自哪里
本站的「仅内置」标记不是猜的，逐条来自：
tools/hmapdev/templates/proc_main.go.tmpl—— 外部插件运行时实际注入 哪些能力，看buildPluginSDK()里的base.Set*调用。internal/sdk—— 内置插件用的完整接口，与公开包对照。- 内核 RPC 协议表（
internal/plugin/proc/protocol.go）—— 外部插件能发哪些请求。
每条裁定的具体依据写在该 API 的告警框里，可以直接核对。
怎么快速确认
- 用 API 搜索 搜 API 名或功能描述，带 仅内置 的就是外部不可用
- 直接看 仅内置插件可用 汇总页
- 拿不准时，读
example/下的示例插件 —— 它们全是外部插件， 能被它们编译通过的写法，外部就一定可用
为什么这样设计
不是为了限制，而是IPC 边界决定了能力边界：外部插件跑在独立进程里， 内核只能通过显式的注入点把能力交过去。凡是需要「持有内核内部数据结构」 的能力（事件发布通道、IO 通道、插件注册表全量操作），进程外都无法安全暴露。
这套边界同时带来好处：插件崩溃不会带崩内核（进程隔离）， 以及插件可以闭源（SDK 是 MIT，见首页）。