# 决策记录

## 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 模式**

**理由**：
1. Wails v3 将 `application.NewService(app)` 的**所有导出方法**自动暴露给前端
2. `Context()`、`MainWindow()`、`FileSystem()`、`ConfigAPI()` 是内部实现细节，不应成为前端 API
3. 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）

**理由**：
1. 插件市场远景需要存储 source/install_path/version/installed_at 等结构化字段，KV 模式查询和索引能力不足
2. Phase 0 建表成本极低（只需在 AutoMigrate 加一个 model）
3. 后续从 KV 迁移到独立表的数据迁移成本高且易出错
4. 与 app_config 职责分离清晰：一个管全局配置，一个管插件实例状态

**后果**：
- 新增 `PluginState` GORM model
- `sqlite.go` AutoMigrate 增加一项
- Phase 3 才开始写入数据，Phase 0 只建表