iven/hms

Files

iven df1d85bfde docs: T40 UI 审计报告 + wiki 更新 + Docker 配置

- T40 UI 审计计划和结果文档（docs/qa/）
- wiki 更新：miniprogram 设计系统合规审计记录 + index 关键数字更新
- 审计 V2 完整报告（docs/audits/v2/）
- 讨论记录文档（docs/discussions/）
- 设计规格和实施计划（docs/superpowers/）
- 角色测试计划和结果（docs/qa/role-test-*）
- Docker 生产部署配置

2026-05-13 23:29:42 +08:00

3.8 KiB

Raw Blame History

插件系统定位讨论

日期: 2026-05-06 | 参与者: 产品负责人 + AI 协作上下文: 夯实基础讨论中引申出的架构问题

背景

在讨论"冻结推迟模块"策略时，发现一个根本性问题：如果插件系统足够成熟，冻结功能 = 卸载插件，无需代码改动。当前 7 个模块需要通过菜单迁移和路由守卫来"冻结"，这本质上是架构不够灵活的症状。

战略方向

通用基座 + 行业插件。 一套底座代码维护，不同行业通过不同插件覆盖。医疗只是第一个行业，未来会有其他行业。

核心结论

交付质量第一，插件化是理想状态。

插件化是长期战略方向，但不是当前优先级
当插件开发能提供与原生同等的性能和体验时，才选择插件
当前阶段：用原生开发保证医疗功能的交付质量，同时积累"插件系统还缺什么"的实际数据

当初选择原生开发的原因及现状

原始限制	现在还是硬墙？	判断
JSONB 动态存储，不够强类型	Generated Column 有类型约束，但 CHECK/FK/NOT NULL 仍缺失	半解决，医疗数据仍有风险
无自定义 API	仍无，模板 API 覆盖不了趋势分析等	❌ 硬墙
无文件上传	仍无	❌ 硬墙
沙箱限制（加密、AI、外部调用）	仍无	❌ 硬墙
实体上限 20 个	软限制，可调	✅ 已解决

结论：医疗核心功能继续用原生开发是正确的选择。 插件系统尚未准备好承载复杂医疗业务。

插件系统当前能力

11 个 Host API（全部实现）：CRUD + 事件 + 权限 + 多租户 + 配置 + 编号 + 日志

前端 7 种页面类型：crud, tree, tabs, graph, dashboard, kanban, detail

5 个已有插件：assessment, CRM, inventory, freelance, itops

插件系统 4 面硬墙及拆除评估

硬墙	工期	拆除方案	解锁能力
无自定义 API	1-2 周	`register-route` Host API，插件声明路由+handler，宿主注册到 Axum router	趋势分析、报表、非 CRUD 端点
无文件上传	1 周	`file-upload/download` Host API，宿主负责存储（本地/S3），返回文件 ID	化验单、体检报告、头像
沙箱限制	2-3 周	`encrypt-field` / `ai-analyze` / `http-request` 三个 Host API	加密、AI 集成、外部系统对接
类型约束不足	1 周	plugin.toml 增加 `required` / `constraints` / `ref_entity`，建表时生成 CHECK/NOT NULL/FK	医疗级数据完整性

合计：5-7 周

各硬墙关键难点

自定义 API — WASM 入参出参通过线性内存传递有开销；SSE 流式需宿主代理；路由冲突检测
文件上传 — 大文件需分块传输（WASM 线性内存有限）；文件与实体关联；权限控制
沙箱扩展 — http-request 需域名白名单防 SSRF；ai-analyze 需抽象多 provider；加密密钥插件不应接触 KEK
类型约束 — Generated Column 加 NOT NULL 后历史数据需补值；跨插件 FK 需特殊处理；约束变更迁移策略

投资时机

当前决策：等医疗行业功能稳定后再投入。

触发条件（满足任一即可启动）：

第二个行业确定要对接
医疗功能已稳定交付，团队有余力投入基础设施建设
特定能力（如文件上传）成为多个客户的共同痛点

行动路径

现在 — 核心医疗功能继续原生开发，保证交付质量
同时 — 在原生开发中记录"哪些需求插件系统无法满足"
医疗功能稳定后 — 按触发条件评估是否启动硬墙拆除
最终 — 插件能力足够时，新行业直接用插件开发，无需维护多套系统

3.8 KiB Raw Blame History Unescape Escape