55 lines
2.1 KiB
Markdown
55 lines
2.1 KiB
Markdown
# 决策记录
|
||
|
||
## 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 只建表
|