# CRM 插件深度分析 & 多专家组头脑风暴

## Context

CRM 插件 (`erp-plugin-crm`) 是 ERP 平台的第一个行业业务插件，也是 WASM 插件系统的标杆验证案例。它已完成了设计规格中的全部 3 个阶段（共 24 个任务），包含 5 个实体、9 个权限、7 种页面类型。现在需要从深度和广度两个维度进行全方位审视，发现改进空间、架构风险和演进方向。

---

## 一、CRM 插件全景画像

### 1.1 架构定位

```
┌─────────────────────────────────────────────────┐
│                   前端 SPA                       │
│  PluginCRUDPage / Tree / Graph / Dashboard /     │
│  Tabs / Detail / Admin — 全部 schema 驱动渲染    │
└────────────────────┬────────────────────────────┘
                     │ REST API (pluginData + plugins)
┌────────────────────▼────────────────────────────┐
│              Plugin Host (erp-plugin)             │
│  service.rs → engine.rs → host.rs → dynamic_table│
│  data_service.rs → handler → module              │
└────────────────────┬────────────────────────────┘
                     │ WIT 接口 (Host API 9 个函数)
┌────────────────────▼────────────────────────────┐
│          CRM WASM Guest (erp-plugin-crm)          │
│  lib.rs (30行) — init/on_tenant_created/          │
│  handle_event 全部 no-op                         │
└──────────────────────────────────────────────────┘
```

### 1.2 数据模型 (5 实体)

| 实体 | 表名 | 字段数 | 用途 |
|------|------|--------|------|
| customer | plugin_erp_crm_customer | 15 | 客户主数据 (企业/个人) |
| contact | plugin_erp_crm_contact | 8 | 联系人 |
| communication | plugin_erp_crm_communication | 7 | 沟通记录 |
| customer_tag | plugin_erp_crm_customer_tag | 3 | 客户标签 |
| customer_relationship | plugin_erp_crm_customer_relationship | 4 | 客户关系 |

### 1.3 页面矩阵 (7 页面类型)

| 页面类型 | CRM 用途 | 复杂度 |
|----------|---------|--------|
| CRUD | 客户/联系人/沟通/标签/关系列表 | 中 (搜索/筛选/排序/视图切换) |
| Detail (Drawer) | 客户360度视图 | 高 (字段+嵌套CRUD+时间线) |
| Tree | 客户层级树 | 低 |
| Tabs | 客户管理入口 | 中 |
| Graph | 关系图谱 (Canvas手绘) | 高 |
| Dashboard | 统计概览 | 中 |
| Admin | 插件生命周期管理 | 中 |

### 1.4 权限模型 (9 权限)

两级权限体系：平台级 (`plugin.admin/list`) + 插件级 (`erp-crm.customer.list/manage` 等)

---

## 二、深度分析 — 六维度体检

### 2.1 架构健壮性 ⚠️

**优势：**
- Host-Guest 沙箱隔离，Fuel 资源限制，WASM panic 不影响主服务
- 延迟写入模式 (PendingOp) 保证事务原子性
- 乐观锁 + 软删除 + 多租户隔离

**风险：**
- **JSONB 外键完整性为零** — `contact.customer_id` 指向已删除客户不会被拦截
- **WASM Guest 价值极低** — CRM 插件 lib.rs 仅 30 行，3 个生命周期钩子全是 no-op，所有业务逻辑实际在 Host 侧的 data_service.rs
- **动态表 SQL 拼接风险** — 虽有 `sanitize_identifier()`，但 JSONB 查询构建器复杂度高
- **插件热升级策略缺失** — 版本升级时如何处理已有数据的 schema 变更？

### 2.2 数据完整性 ⚠️

**当前状态：**
- 无 DB 级外键约束（JSONB 字段无法使用 PostgreSQL FK）
- 无应用层 FK 校验（data_service.rs 的 create/update 不检查关联实体是否存在）
- 删除客户时不级联处理关联的联系人/沟通记录/标签
- `customer.parent_id` 的循环引用无检测

### 2.3 查询性能 🟡

**已做优化：**
- GIN 索引覆盖 searchable 字段
- tenant_id 索引
- Redis 连接缓存 (响应 2.26s → 2ms)

**潜在瓶颈：**
- JSONB 内字段排序 (`ORDER BY data->>'field'`) 无法使用 B-tree 索引
- 聚合查询 (`aggregate`) 对大数据量可能慢
- 关系图谱需要全量加载 customer + customer_relationship，前端 Canvas 渲染
- 无分页的树结构查询（前端全量加载后客户端构建）

### 2.4 安全合规 🔴

- **数据权限缺失** — 只有操作权限 (能否操作)，无数据权限 (能看到谁的数据)
- **搜索注入** — search 参数直接拼入 SQL ILIKE，需确认转义逻辑
- **权限 fallback 过宽** — `plugin.admin` 权限自动获得所有插件的所有操作权限

### 2.5 前端体验 🟡

**亮点：**
- 全 schema 驱动，零 CRM 专用前端代码
- visible_when 条件表单字段
- 时间线/表格视图切换
- Canvas 手绘关系图谱（无第三方库依赖）
- 嵌套 CRUD (Detail Drawer)

**不足：**
- 无看板视图（销售漏斗/客户跟进阶段）
- 无数据导入/导出功能
- 无批量操作
- 标签系统过于简单（无标签分组管理、无标签云）
- Dashboard 统计维度有限（只有计数+分组聚合）
- 树页面不支持拖拽排序

### 2.6 可扩展性 🟡

**平台能力沉淀：**
- 7 种通用页面类型可供未来插件复用
- 插件 manifest (TOML) schema 定义了完整的元数据规范
- 插件生命周期管理 (上传→安装→启用→禁用→卸载→清除)

**限制：**
- 页面类型有限 — 无日历、看板、甘特图、地图等业务常见页面
- WASM WIT 接口固定 — Host API 9 个函数，扩展需要修改 WIT + 双端重编译
- 插件间通信未实现 — 当前只能通过 EventBus 订阅系统事件，插件间无法直接交互

---

## 三、专家组头脑风暴议题

基于以上分析，建议从以下 6 个专家组视角展开头脑风暴：

### 专家组 1: 后端架构师
**焦点：** WASM 插件架构的真正价值在哪里？如何让 Guest 代码从 no-op 变成有意义的业务逻辑？
- Host API 的 db_query 为何不可用？如何修复？
- JSONB 动态表 vs 独立 schema 表的取舍
- 插件版本升级的数据迁移策略
- 延迟写入模式的局限性和改进

### 专家组 2: CRM 产品专家
**焦点：** 这个 CRM 能用吗？缺什么核心能力？
- 销售漏斗/商机管理缺失的影响
- 客户跟进提醒机制
- 数据导入/导出 (Excel)
- 客户画像/360度视图的完整性
- 与 ERP 其他模块 (进销存/财务) 的联动

### 专家组 3: 安全工程师
**焦点：** 数据权限、隔离性、合规风险
- 行级数据权限 (谁能看到哪些客户)
- JSONB 查询注入风险
- 插件 WASM 沙箱逃逸可能性
- 审计日志的完整性
- GDPR/数据隐私合规

### 专家组 4: 前端架构师
**焦点：** Schema 驱动 UI 的天花板和突破路径
- 复杂交互场景 (拖拽、批量操作、右键菜单) 的 schema 描述能力
- 看板/日历/甘特图等新页面类型的设计
- 大数据量下的性能优化 (虚拟滚动、懒加载)
- 插件自定义 UI 组件的可行性

### 专家组 5: 平台架构师
**焦点：** 插件平台的通用性和未来演进
- 插件间通信和协作机制
- 插件市场/分发的技术架构
- 插件依赖管理和版本兼容
- 多租户插件隔离的成本和安全性

### 专家组 6: 性能工程师
**焦点：** JSONB 动态表的性能天花板
- 百万级数据的查询优化策略
- 聚合查询的预计算/缓存
- 关系图谱大数据量下的前端渲染
- PostgreSQL JSONB 索引策略优化

---

## 四、实施计划

1. 退出计划模式后，立即调用 `/brainstorm` 技能，以本分析报告为基础材料
2. 对 6 个专家组视角逐一展开头脑风暴
3. 汇总所有专家建议，形成优先级排序的改进路线图
4. 输出最终的 CRM 插件改进计划