决策记录
ADR-001：CoreServices 使用 adapter 模式而非 App 直接实现
日期：2026-05-01 状态：已采纳 背景：插件需要访问 App 的内部服务（ctx、mainWindow、filesystem 等），需要定义 CoreServices 接口。
选项：
| 方案 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| A. App 直接实现 | App struct 添加 6 个公开方法 | 简单，无需额外类型 | Wails v3 将这 6 个方法全部暴露给前端 API（信息泄漏） |
| B. adapter 模式 | 新建独立 adapter 结构体实现接口 | 零新增公开方法；松耦合 | 多一个文件 (~40 行) |
决策：选 B. adapter 模式
理由：
- Wails v3 将
application.NewService(app)的所有导出方法自动暴露给前端 Context()、MainWindow()、FileSystem()、ConfigAPI()是内部实现细节，不应成为前端 API- adapter 仅 40 行代码，代价极小
后果：
- 新增
internal/plugin/adapter.go文件 - App 零新增公开方法
- Manager 通过
NewAdapter(a)获取 CoreServices
ADR-002：plugin_state 使用独立表而非复用 app_config KV
日期：2026-05-01 状态：已采纳 背景：插件的启用状态、版本、安装路径等数据需要持久化存储。
选项：
| 方案 | 做法 | 适用阶段 |
|---|---|---|
| A. 复用 app_config 表 | key 前缀 plugin_enabled:xxx / plugin_config:xxx |
插件数 < 20 时够用 |
| B. 独立 plugin_state 表 | 专用表，结构化字段 | 插件市场场景必需 |
决策：选 B. 独立表（Phase 0 就建好 schema）
理由：
- 插件市场远景需要存储 source/install_path/version/installed_at 等结构化字段，KV 模式查询和索引能力不足
- Phase 0 建表成本极低（只需在 AutoMigrate 加一个 model）
- 后续从 KV 迁移到独立表的数据迁移成本高且易出错
- 与 app_config 职责分离清晰：一个管全局配置，一个管插件实例状态
后果：
- 新增
PluginStateGORM model sqlite.goAutoMigrate 增加一项- Phase 3 才开始写入数据，Phase 0 只建表