feat(admin): Add user management and upgrade to module permission system

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

docs/03-业务模块/IIT Manager Agent/00-系统设计/IIT Manager Agent 项目实施战略与 MVP 路线图.md

@@ -1,62 +1,72 @@
-# **IIT Manager Agent 椤圭洰瀹炴柦鎴樼暐涓?MVP 璺<>嚎鍥?*
+# **IIT Manager Agent 项目实施战略与 MVP 路线图**
 
-## **1\. 鏍稿績鎴樼暐锛氫互鈥滄劅鐭モ€濋┍鍔ㄢ€滀俊浠烩€?*
+## **1\. 核心战略：以“感知”驱动“信任”**
+
+在 Phase 1，我们不急于实现“全自动数据搬运”，因为“写”的合规风险和技术门槛最高。我们应优先实现\*\*“智能感知与主动预警”\*\*。
 
-鍦?Phase 1锛屾垜浠<E59E9C>笉鎬ヤ簬瀹炵幇鈥滃叏鑷<E58F8F>姩鏁版嵁鎼<E5B581>繍鈥濓紝鍥犱负鈥滃啓鈥濈殑鍚堣<E98D9A>椋庨櫓鍜屾妧鏈<E5A6A7>棬妲涙渶楂樸€傛垜浠<E59E9C>簲浼樺厛瀹炵幇\*\*鈥滄櫤鑳芥劅鐭ヤ笌涓诲姩棰勮<E6A3B0>鈥漒*\*銆?
 **MVP 的定义：**
 
-鑳藉<EFBFBD>瀹炴椂鐩戝惉 REDCap 褰曞叆锛屽埄鐢?Dify RAG 鍙戠幇閫昏緫鍋忓樊锛屽苟鎺ㄩ€佸埌 PI 鐨勫井淇＄<E6B787>杩涜<E69DA9>棰勮<E6A3B0>銆?
-## **2\. 涓夊ぇ閲岀▼纰?(Milestones)**
+能够实时监听 REDCap 录入，利用 Dify RAG 发现逻辑偏差，并推送到 PI 的微信端进行预警。
 
-### **閲岀▼纰?1锛氶€氳矾鎼<E79FBE>缓锛堚€滆矾瑕侀€氣€濓級**
+## **2\. 三大里程碑 (Milestones)**
 
-* **鐩<>爣**锛氬缓绔?REDCap \-\> Node.js \-\> 寰<>俊鐨勯棴鐜<E6A3B4>€? 
-* **鍏抽敭浠诲姟**锛? 
-  * **鐜<><E9909C>鍒濆<E98D92>鍖?*锛歋AE 閮ㄧ讲鍚庣<E98D9A>锛孯DS 鍒濆<E98D92>鍖?iit\_schema銆? 
-  * **EDC 閫傞厤鍣?*锛氬畬鎴?REDCap External Module (EM) 鍩虹<E98DA9>寮€鍙戯紝瀹炵幇淇濆瓨璁板綍鏃剁殑 Webhook 瑙﹀彂銆? 
-  * **寰<>俊鑱旈€?*锛氬畬鎴愪紒涓氬井淇″簲鐢ㄥ垱寤轰笌娑堟伅鎺ㄩ€佹帴鍙ｅ<E98D99>鎺ャ€?
-### **閲岀▼纰?2锛氭櫤鑳芥敞鍏ワ紙鈥滆剳瑕佺伒鈥濓級**
+### **里程碑 1：通路搭建（“路要通”）**
 
-* **鐩<EFBFBD>爣**锛氬疄鐜?AI 瀵逛复搴婃柟妗堢殑娣卞害鐞嗚В銆? 
-* **鍏抽敭浠诲姟**锛? 
-  * **Dify 鐭ヨ瘑搴?*锛氫笂浼?1-2 浠芥爣鍑嗕复搴婂崗璁<E5B497>紝璋冭瘯 RAG 妫€绱㈠弬鏁般€? 
-  * **Prompt 璋冧紭**锛氱紪鍐欏苟娴嬭瘯鈥滄暟鎹<E69A9F>川鎺?Agent鈥濇彁绀鸿瘝锛岀‘淇濆叾杈撳嚭绗﹀悎鎴戜滑鐨?JSON 鍗忚<E98D97>銆? 
-  * **褰卞瓙鐢熸垚**锛氬疄鐜板悗绔<E68297>嚜鍔ㄧ敓鎴?PendingAction 璁板綍銆?
-### **閲岀▼纰?3锛氶棴鐜<E6A3B4>崗鍚岋紙鈥滄椿瑕佺粏鈥濓級**
+* **目标**：建立 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 自动回写。
 
-* **鐩<>爣**锛氫笂绾?PC Workbench 鍜?PI 灏忕▼搴忥紝瀹炵幇浜烘満纭<E6BA80><E7BAAD>銆? 
-* **鍏抽敭浠诲姟**锛? 
-  * **Workbench 楠ㄦ灦**锛氬熀浜?Ant Design X 瀹炵幇浠诲姟鍒楄〃涓庤瘉鎹<E79889><E98EB9>姣斿尯銆? 
-  * **PI 灏忕▼搴?*锛氬疄鐜板搧鐗屽寲鎶ヨ〃灞曠ず涓庣Щ鍔ㄧ<E98D94>涓€閿<E282AC><E996BF>鎵广€? 
-  * **鍥炲啓闂<E59593>幆**锛氬疄鐜?APPROVED 鐘舵€佸悗鐨?REDCap API 鑷<>姩鍥炲啓銆?
 ## **3\. 当前最重要的技术攻坚点 (Technical Hard Rocks)**
 
-### **3.1 REDCap EM 鐨勯潪渚靛叆寮忊€滀晶鎸傗€?(P0)**
+### **3.1 REDCap EM 的非侵入式“侧挂” (P0)**
 
-* **鎸戞垬**锛氬<E9949B>浣曞湪涓嶇牬鍧忓尰闄㈡棦鏈?REDCap 鐜<><E9909C>鐨勫墠鎻愪笅锛岀ǔ瀹氬湴鎶婃暟鎹<E69A9F>€滈挬鈥濆嚭鏉ャ€? 
-* **瀵圭瓥**锛氬埄鐢?REDCap 瀹樻柟鐨?External Module 妗嗘灦锛屽彧鍋氭暟鎹<EFBFBD>浆鍙戯紝涓嶅仛涓氬姟澶勭悊銆?
-### **3.2 璇佹嵁閾剧殑鈥滅簿鍑嗗畾浣嶁€?(P0)**
+* **挑战**：如何在不破坏医院既有 REDCap 环境的前提下，稳定地把数据“钩”出来。  
+* **对策**：利用 REDCap 官方的 External Module 框架，只做数据转发，不做业务处理。
 
-* **鎸戞垬**锛欴ify 杩斿洖鐨勬枃瀛楃墖娈靛<E5A888>浣曡浆鍖栨垚鍓嶇<E98D93> PDF 棰勮<E6A3B0>鐨勯珮浜<E78FAE>潗鏍囥€? 
-* **瀵圭瓥**锛氬湪 Dify 渚ч厤缃<E58EA4>敮鎸佽繑鍥?metadata锛堝惈椤电爜锛夛紝鍓嶇<E98D93>瀹炵幇涓€涓<E282AC>交閲忕骇鐨?PDF.js 楂樹寒灞傘€?
-### **3.3 浠诲姟寮曟搸鐨勨€滈暱鍛ㄦ湡璋冨害鈥?(P1)**
+### **3.2 证据链的“精准定位” (P0)**
+
+* **挑战**：Dify 返回的文字片段如何转化成前端 PDF 预览的高亮坐标。  
+* **对策**：在 Dify 侧配置支持返回 metadata（含页码），前端实现一个轻量级的 PDF.js 高亮层。
+
+### **3.3 任务引擎的“长周期调度” (P1)**
+
+* **挑战**：临床研究持续数月甚至数年，如何保证任务不丢失、不重复。  
+* **对策**：利用 pg-boss 的持久化队列，结合 Postgres 事务保证状态一致性。
 
-* **鎸戞垬**锛氫复搴婄爺绌舵寔缁<E5AF94>暟鏈堢敋鑷虫暟骞达紝濡備綍淇濊瘉浠诲姟涓嶄涪澶便€佷笉閲嶅<E996B2>銆? 
-* **瀵圭瓥**锛氬埄鐢?pg-boss 鐨勬寔涔呭寲闃熷垪锛岀粨鍚?Postgres 浜嬪姟淇濊瘉鐘舵€佷竴鑷存€с€?
 ## **4\. MVP 版本功能清单 (Scope for MVP)**
 
 为了让用户快速见到东西，MVP 建议仅包含以下功能：
 
-1. **椤圭洰鍒濆<EFBFBD>鍖?*锛氭墜鍔ㄨ緭鍏?5 涓<>叧閿<E58FA7>彉閲忔槧灏勶紙鏆備笉鍋氬叏閲忚嚜鍔ㄦ槧灏勶級銆? 
-2. **瀹炴椂璐ㄦ帶棰勮<EFBFBD>**锛氶拡瀵光€滃勾榫勩€佹€у埆銆佹牳蹇冨叆鎺掓爣鍑嗏€濊繘琛?AI 妫€鏌ャ€? 
-3. **寰<EFBFBD>俊娑堟伅鎺ㄩ€?*锛氬綋褰曞叆杩濊儗鏂规<E98F82>鏃讹紝PI 鏀跺埌浼佸井鍗＄墖銆? 
-4. **PC 绠€鏄撳伐浣滅珯**锛氭煡鐪嬭繚鑳岃<E991B3>鎯呭拰 AI 缁欏嚭鐨勮瘉鎹<E79889>墖娈点€?
-## **5\. 寤鸿<E5AFA4>鐨勮<E990A8>鍔ㄩ『搴?(Next Steps)**
+1. **项目初始化**：手动输入 5 个关键变量映射（暂不做全量自动映射）。  
+2. **实时质控预警**：针对“年龄、性别、核心入排标准”进行 AI 检查。  
+3. **微信消息推送**：当录入违背方案时，PI 收到企微卡片。  
+4. **PC 简易工作站**：查看违背详情和 AI 给出的证据片段。
 
-1. **绔嬪埢鎵ц<E98EB5> (Day 1-3)**锛? 
-   * 娉ㄥ唽骞惰<E9AA9E>璇佷紒涓氬井淇″紑鍙戣€呬富浣撱€? 
-   * 鍦ㄩ樋閲屼簯 SAE 鎼<>缓绗<E7BC93>竴涓?Node.js Hello World锛屽苟璋冮€氫紒涓氬井淇℃帹閫?API銆? 
-2. **鍚屾<E98D9A>鎺ㄨ繘 (Day 1-7)**锛? 
-   * 鐢变竴浣嶅墠绔<EFBFBD>伐绋嬪笀鍩轰簬鎴戜滑鐨?HTML 鍘熺敓寮€濮嬫惌寤?React 鐗堟湰鐨?Workbench 楠ㄦ灦銆? 
-   * 鐢变竴浣嶅悗绔<E68297>伐绋嬪笀寮€濮嬬紪鍐?REDCap EM 鎻掍欢鐨?PHP 浠ｇ爜銆?
-**褰撳墠闃舵<E99783>**锛歊eady to Code | **鐩<>爣鏃ユ湡**锛? 鍛ㄥ唴瀹屾垚 MVP 婕旂ず闂<E3819A>幆
+## **5\. 建议的行动顺序 (Next Steps)**
+
+1. **立刻执行 (Day 1-3)**：  
+   * 注册并认证企业微信开发者主体。  
+   * 在阿里云 SAE 搭建第一个 Node.js Hello World，并调通企业微信推送 API。  
+2. **同步推进 (Day 1-7)**：  
+   * 由一位前端工程师基于我们的 HTML 原生开始搭建 React 版本的 Workbench 骨架。  
+   * 由一位后端工程师开始编写 REDCap EM 插件的 PHP 代码。
+
+**当前阶段**：Ready to Code | **目标日期**：2 周内完成 MVP 演示闭环