HaHafeng
66255368b7
Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
3.6 KiB
3.6 KiB
IIT Manager Agent 项目实施战略与 MVP 路线图
1. 核心战略：以“感知”驱动“信任”
在 Phase 1，我们不急于实现“全自动数据搬运”，因为“写”的合规风险和技术门槛最高。我们应优先实现**“智能感知与主动预警”**。
MVP 的定义：
能够实时监听 REDCap 录入，利用 Dify RAG 发现逻辑偏差，并推送到 PI 的微信端进行预警。
2. 三大里程碑 (Milestones)
里程碑 1：通路搭建（“路要通”）
- 目标：建立 REDCap -> Node.js -> 微信的闭环。
- 关键任务：
- 环境初始化：SAE 部署后端，RDS 初始化 iit_schema。
- EDC 适配器：完成 REDCap External Module (EM) 基础开发，实现保存记录时的 Webhook 触发。
- 微信联通：完成企业微信应用创建与消息推送接口对接。
里程碑 2：智能注入（“脑要灵”）
- 目标：实现 AI 对临床方案的深度理解。
- 关键任务：
- Dify 知识库：上传 1-2 份标准临床协议，调试 RAG 检索参数。
- Prompt 调优：编写并测试“数据质控 Agent”提示词，确保其输出符合我们的 JSON 协议。
- 影子生成：实现后端自动生成 PendingAction 记录。
里程碑 3：闭环协同（“活要细”）
- 目标：上线 PC Workbench 和 PI 小程序，实现人机确认。
- 关键任务：
- Workbench 骨架：基于 Ant Design X 实现任务列表与证据对比区。
- PI 小程序：实现品牌化报表展示与移动端一键审批。
- 回写闭环：实现 APPROVED 状态后的 REDCap API 自动回写。
3. 当前最重要的技术攻坚点 (Technical Hard Rocks)
3.1 REDCap EM 的非侵入式“侧挂” (P0)
- 挑战：如何在不破坏医院既有 REDCap 环境的前提下，稳定地把数据“钩”出来。
- 对策：利用 REDCap 官方的 External Module 框架，只做数据转发，不做业务处理。
3.2 证据链的“精准定位” (P0)
- 挑战：Dify 返回的文字片段如何转化成前端 PDF 预览的高亮坐标。
- 对策：在 Dify 侧配置支持返回 metadata（含页码），前端实现一个轻量级的 PDF.js 高亮层。
3.3 任务引擎的“长周期调度” (P1)
- 挑战：临床研究持续数月甚至数年，如何保证任务不丢失、不重复。
- 对策：利用 pg-boss 的持久化队列，结合 Postgres 事务保证状态一致性。
4. MVP 版本功能清单 (Scope for MVP)
为了让用户快速见到东西，MVP 建议仅包含以下功能：
- 项目初始化：手动输入 5 个关键变量映射（暂不做全量自动映射）。
- 实时质控预警：针对“年龄、性别、核心入排标准”进行 AI 检查。
- 微信消息推送：当录入违背方案时，PI 收到企微卡片。
- PC 简易工作站：查看违背详情和 AI 给出的证据片段。
5. 建议的行动顺序 (Next Steps)
- 立刻执行 (Day 1-3)：
- 注册并认证企业微信开发者主体。
- 在阿里云 SAE 搭建第一个 Node.js Hello World，并调通企业微信推送 API。
- 同步推进 (Day 1-7)：
- 由一位前端工程师基于我们的 HTML 原生开始搭建 React 版本的 Workbench 骨架。
- 由一位后端工程师开始编写 REDCap EM 插件的 PHP 代码。
当前阶段：Ready to Code | 目标日期：2 周内完成 MVP 演示闭环