feat(iit): Complete V3.1 QC engine + GCP business reports + AI timeline + bug fixes

V3.1 QC Engine:
- QcExecutor unified entry + D1-D7 dimension engines + three-level aggregation
- HealthScoreEngine + CompletenessEngine + ProtocolDeviationEngine + QcAggregator
- B4 flexible cron scheduling (project-level cronExpression + pg-boss dispatcher)
- Prisma migrations for qc_field_status, event_status, project_stats

GCP Business Reports (Phase A - 4 reports):
- D1 Eligibility: record_summary full list + qc_field_status D1 overlay
- D2 Completeness: data entry rate and missing rate aggregation
- D3/D4 Query Tracking: severity distribution from qc_field_status
- D6 Protocol Deviation: D6 dimension filtering
- 4 frontend table components + ReportsPage 5-tab restructure

AI Timeline Enhancement:
- SkillRunner outputs totalRules (33 actual rules vs 1 skill)
- iitQcCockpitController severity mapping fix (critical->red, warning->yellow)
- AiStreamPage expandable issue detail table with Chinese labels
- Event label localization (eventLabel from backend)

Business-side One-click Batch QC:
- DashboardPage batch QC button with SyncOutlined icon
- Auto-refresh QcReport cache after batch execution

Bug Fixes:
- dimension_code -> rule_category in 4 SQL queries
- D1 eligibility data source: record_summary full + qc_field_status overlay
- Timezone UTC -> Asia/Shanghai (QcReportService toBeijingTime helper)
- Pass rate calculation: passed/totalEvents instead of passed/totalRecords

Docs:
- Update IIT module status with GCP reports and bug fix milestones
- Update system status doc v6.6 with IIT progress

Tested: Backend compiles, frontend linter clean, batch QC verified
Made-with: Cursor

docs/03-业务模块/IIT Manager Agent/00-模块当前状态与开发指南.md

@@ -3,8 +3,14 @@
 > **文档版本：** v3.1  
 > **创建日期：** 2026-01-01  
 > **维护者：** IIT Manager开发团队  
-> **最后更新：** 2026-03-01 **质控引擎 V3.1 架构升级计划定稿（五级数据结构 + 多维报告）**  
+> **最后更新：** 2026-03-01 **GCP 业务报表 + AI 工作流水增强 + 多项 Bug 修复完成！**  
 > **重大里程碑：**  
+> - **2026-03-01：GCP 业务端报表全量完成！** 4 张 GCP 标准报表（D1 筛选入选/D2 完整性/D3D4 质疑跟踪/D6 方案偏离）后端 API + 前端组件 + ReportsPage 五 Tab 重构
+> - **2026-03-01：AI 工作流水时间线增强！** 实际规则数显示（33 条而非 1 条）+ 中文事件名 + 可展开问题详情表格 + severity 映射修复
+> - **2026-03-01：业务端一键全量质控！** DashboardPage 新增按钮 + 自动刷新报告缓存 + 事件级通过率修复
+> - **2026-03-01：多项关键 Bug 修复！** dimension_code→rule_category / D1 仅显示 1 人→14 人 / 时区 UTC→北京时间 / 通过率 271%→正确值
+> - **2026-03-01：B4 定时质控灵活配置完成！** 项目级 cron → pg-boss dispatcher 每分钟匹配 → QcExecutor.executeBatch → DailyQcOrchestrator  
+> - **2026-03-01：V3.1 质控引擎全量完成！** 17 项任务全部实现：QcExecutor 统一入口 → D1-D7 全维度 → 三级聚合 → HealthScore → 前端驾驶舱 → 端到端测试  
 > - **2026-03-01：质控引擎 V3.1 架构设计完成！** 五级数据结构（CDISC ODM）+ D1-D7 多维报告 + 三批次落地计划  
 > - **2026-03-01：架构团队评审完成！** 采纳 InstanceID/规则分类/状态冒泡/LLM 三不原则，暂缓 SDV/自动映射/GCP 全量报表  
 > - **2026-02-26：前端架构调整完成！** 运营管理端恢复 IIT 项目管理 + 业务端精简为日常使用 + Web AI 对话页面上线  
@@ -55,7 +61,26 @@ CRA Agent 是一个**替代 CRA 岗位的自主 AI Agent**，而非辅助 CRA
   - AI能力：DeepSeek/Qwen + 自研 RAG（pgvector）+ LLM Tool Use
 
 ### 当前状态
-- **开发阶段**：**V3.0 P0 + P1 已完成 → 正在规划 V3.1 质控引擎架构升级**
+- **开发阶段**：**V3.1 质控引擎 + GCP 业务报表 + AI 时间线增强 + Bug 修复 → 待部署验证**
+- **GCP 业务报表 + Bug 修复已完成**（2026-03-01）：
+  - 4 张 GCP 标准报表后端 API（iitQcCockpitService：getEligibilityReport/getCompletenessReport/getEqueryReport/getDeviationReport）
+  - 4 个前端报表组件（EligibilityTable/CompletenessTable/EqueryLogTable/DeviationLogTable）
+  - ReportsPage 五 Tab 重构（执行摘要 + 4 张报表）
+  - AI 工作流水时间线增强（SkillRunner 真实规则数 + iitQcCockpitController severity 映射 + AiStreamPage 可展开详情表格）
+  - 业务端一键全量质控按钮（DashboardPage + 报告缓存自动刷新）
+  - Bug 修复：dimension_code→rule_category / D1 数据源→record_summary 全量 + qc_field_status 叠加 / 时区 UTC→Asia/Shanghai / 通过率 passed/totalEvents
+- **B4 已完成**（2026-03-01）：
+  - 项目级 cronExpression 持久化（后端 UpdateProjectInput + Prisma update）
+  - 全局 dispatcher 调度器（pg-boss 每分钟轮询 → 匹配 cronExpression → 派发 iit_scheduled_qc）
+  - iit_scheduled_qc Worker V3.1 升级（QcExecutor.executeBatch + DailyQcOrchestrator）
+  - 前端管理端 cron 配置 UI 增强（6 个预设 + 自定义输入 + cronEnabled/cronExpression 类型修复）
+  - 动态生效：保存项目配置后 refreshProjectCronSchedule() 即时反映
+- **V3.1 已完成**（2026-03-01）：
+  - P1: 后端集成（QcExecutor 统一入口 + D2/D6 维度引擎 + HealthScore 聚合）
+  - P2: 报告升级（QcReportService 数据源切换 + dimension_summary/event_overview XML）
+  - P3: API + 服务（新增 3 端点 + CockpitService 升级 + ToolsService 升级）
+  - P4: 前端（DashboardPage 健康度+维度条 + 热力图 record×event + ReportsPage 维度/事件 Tab）
+  - P5: 端到端测试脚本 + 部署清单
 - **V3.0 已完成**：
   - P0 自驱动质控流水线 + P1 对话层 Tool Use 改造 + E2E 54/54 通过
   - QC 系统深度修复（null tolerance + baseline merge + record-level pass rate + LLM 报告修正）
@@ -82,10 +107,31 @@ CRA Agent 是一个**替代 CRA 岗位的自主 AI Agent**，而非辅助 CRA
 - ✅ **端到端测试通过**（REDCap → Node.js → 企业微信）
 - ✅ ~~AI对话集成完成（ChatService + SessionMemory）~~ → 已替换为 ChatOrchestrator
 
+#### ✅ 已完成功能（GCP 业务报表 + AI 时间线 + Bug 修复 - 2026-03-01）
+- ✅ **GCP 标准报表（阶段 A 4 张）**：
+  - D1 筛选入选表（getEligibilityReport：record_summary 全量 + qc_field_status D1 叠加）
+  - D2 数据录入率与缺失率（getCompletenessReport：record_summary 聚合统计）
+  - D3/D4 数据质疑跟踪表（getEqueryReport：qc_field_status severity 分布）
+  - D6 方案偏离表（getDeviationReport：qc_field_status D6 维度）
+- ✅ **前端 4 个报表组件**（EligibilityTable / CompletenessTable / EqueryLogTable / DeviationLogTable）
+- ✅ **ReportsPage 五 Tab 重构**（执行摘要 LLM + 4 张报表独立 Tab）
+- ✅ **AI 工作流水时间线增强**：
+  - SkillRunner 输出 totalRules（33 条真实规则数替代 1 条 skill 数）
+  - iitQcCockpitController severity 映射修复（critical→red / warning→yellow）
+  - AiStreamPage 可展开 Collapse 详情表格（规则名/字段/描述/严重性/实际值）
+  - 中文事件名显示（eventLabel）+ 状态标签中文化（通过/严重/警告）
+- ✅ **业务端一键全量质控**（DashboardPage SyncOutlined 按钮 + batchQualityCheck API 调用）
+- ✅ **报告缓存自动刷新**（iitBatchController 批量 QC 后调用 QcReportService.refreshReport）
+- ✅ **Bug 修复**：
+  - dimension_code→rule_category（iitQcCockpitService 4 处 SQL）
+  - D1 筛选入选仅 1 人→14 人（数据源从 qc_field_status 改为 record_summary 全量）
+  - 时区 UTC→北京时间（QcReportService toBeijingTime + buildLlmXmlReport Asia/Shanghai）
+  - 通过率 271%→正确值（iitBatchController passed/totalEvents 替代 passed/totalRecords）
+
 #### ✅ 已完成功能（P0 自驱动质控流水线 - 2026-02-26）
 - ✅ **变量清单导入**（REDCap Data Dictionary → iit_field_metadata）
 - ✅ **规则配置增强**（4 类规则 + AI 辅助建议 + 变量关联）
-- ✅ **定时质控调度**（pg-boss cron + DailyQcOrchestrator）
+- ✅ **定时质控调度**（pg-boss cron dispatcher + 项目级 cronExpression + DailyQcOrchestrator）
 - ✅ **eQuery 闭环**（open → responded → ai_reviewing → resolved/reopened）
 - ✅ **重大事件归档**（SAE + 方案偏离自动归档 iit_critical_events）
 - ✅ **统一驾驶舱**（健康分 + 趋势图 + 风险热力图 + 核心指标卡片）
@@ -908,8 +954,8 @@ npx ts-node src/modules/iit-manager/test-wechat-push.ts
 ---
 
 > **提示**：本文档反映IIT Manager Agent模块的最新真实状态，每个里程碑完成后必须更新！  
-> **最后更新**：2026-02-25  
-> **当前进度**：V3.0 开发计划已定稿 | 下一步：P0-1 ChatOrchestrator + ToolsService 重构  
+> **最后更新**：2026-03-01  
+> **当前进度**：V3.1 QC Engine 完成 | GCP 业务报表 4 张全量完成 | AI Timeline 增强 | 一键全量质控 | 多项 Bug 修复 | Phase 2: LLM 执行摘要待开发  
 > **核心文档**：
 > - [CRA Agent V3.0 开发计划](./04-开发计划/V3.0全新开发计划/V3.0全新开发计划.md) ⭐⭐⭐⭐⭐
 > - [统一数字 CRA 质控平台 PRD](./04-开发计划/V3.0全新开发计划/统一数字%20CRA%20质控平台产品需求文档(PRD).md) ⭐⭐⭐⭐⭐

docs/03-业务模块/IIT Manager Agent/09-技术评审报告/GCP 质控报表开发计划专家审查报告.md

@@ -0,0 +1,103 @@
+# **业务端 GCP 质控报表开发计划专家审查报告**
+
+**审查对象**：《GCP Business Reports 开发计划》 (5aeb159b.plan)
+
+**审查定位**：针对 D1、D2、D3/D4、D6 报表开发的逻辑闭环、性能瓶颈及 LLM 协同性进行深度排雷。
+
+**审查结论**：总体架构极佳，完美贯彻了“硬计算归系统，软推理归 LLM”的原则。但在 D2 缺失数据写入、D6 字段解析及前端加载性能上存在 4 个隐藏坑点，需在编码前修正。
+
+## **一、 值得高度肯定的亮点（What's Good）**
+
+1. **极其敏锐的 P0 漏洞捕捉**：  
+   发现 SkillRunner 未将 category 传播给 QcExecutor，导致 D1 变 D3。这个 Bug 如果在测试期才发现，会导致所有报表数据串位。修复方案非常精准。  
+2. **对 LLM 极其友好的底层设计**：  
+   你没有选择“把几十万条数据直接扔给 LLM 让它画表格”，而是**老老实实写了 4 个结构化的 API**。这是最顶级的 LLM 友好型架构！  
+   *未来 LLM 只需要调用这 4 个 API 获取 JSON（极低 Token），就能在 Tab 0（执行摘要）里写出极其精准且绝对不会幻觉的全局分析报告。*  
+3. **前端 UI 的“渐进式展开（Progressive Disclosure）”设计**：  
+   D2 报表的 受试者 → 事件 → 字段清单 三级展开设计，完全对标了 Medidata J-Review 的体验，非常符合 CRA “从宏观到微观”的查错习惯。
+
+## **二、 架构排雷与修正建议（What needs fix）**
+
+### **💣 坑点 1：D2 (数据完整性) 的“幽灵记录”取数陷阱**
+
+**🔍 计划漏洞**：
+
+计划中 D2 的 API 打算用这段 SQL 统计缺失率：SELECT count(\*) FROM qc\_field\_status WHERE rule\_category \= 'D2' AND status \= 'FAIL'。
+
+**临床逻辑断层**：如果是“缺失数据”，意味着 CRC **根本没有填这个字段**。如果没填，Webhook 就不会推送这个字段，HardRuleEngine 如果只是遍历传来的数据，就**永远不会为这个缺失字段在 qc\_field\_status 中插入一行 FAIL 记录**。没有记录，你的 SQL 就什么都 count 不到！
+
+**🛠️ 修正建议 (后端)**：
+
+必须明确界定 CompletenessEngine (D2 引擎) 的特殊职责：**它必须是主动轮询（Proactive Polling）**。
+
+D2 引擎在运行时，必须拿患者当前的 Event 去对比 REDCap 的 Data Dictionary。对于字典里有但数据库里没有的必填项，引擎必须**主动强行向 qc\_field\_status 插入一条具有五层坐标的“幽灵记录”**（实际值为空，状态为 FAIL，类别为 D2）。
+
+*只有这样，你计划里的 SQL 才能真正生效。请将此要求补充进 D2 的开发任务中。*
+
+### **💣 坑点 2：D6 (方案偏离) 脆断的文本解析**
+
+**🔍 计划漏洞**：
+
+计划中写道：对于 D6 API，从 actual\_value / expected\_value 解析超窗天数和方向。
+
+**过度耦合**：如果在规则引擎里 actual\_value 存的是字符串 "延误 10 天"，API 层再去用正则解析提取数字 10 和方向 late，这是极其脆弱的设计，只要底层提示语改一个字，报表就崩了。
+
+**🛠️ 修正建议 (后端数据结构)**：
+
+不要在 API 层解析字符串。在底层执行超窗规则（D6）时，规则引擎应该把结构化的偏离数据写入到一个元数据字段。
+
+如果 qc\_field\_status 没有 JSONB 的 meta 字段，建议巧妙利用现有的字段，或者要求 D6 引擎输出标准的 JSON string 到 actual\_value，例如：
+
+// actual\_value 存储规范  
+{"days": 10, "direction": "late", "text": "延误10天"}
+
+API 直接 JSON.parse(actual\_value) 即可安全获取 deviationDays。
+
+### **💣 坑点 3：D1 (筛选入选表) Inclusion/Exclusion 的身份识别**
+
+**🔍 计划漏洞**：
+
+D1 API 的返回结构要求明确区分 type: 'inclusion' | 'exclusion'，以便分别统计。但在我们现有的 qc\_field\_status 五层表中，并没有字段标识一条规则到底是纳入还是排除。
+
+**🛠️ 修正建议 (后端映射)**：
+
+在执行 P0 Bugfix 时，连同将规则的子分类也传递下去。或者在项目的 IitSkill 配置中，规定 D1 规则的命名必须带有前缀（例如：INC-年龄校验，EXC-妊娠状态）。D1 的 API 通过解析 ruleName 的前缀来区分 inclusion 和 exclusion，从而正确归类到前端表格中。
+
+### **💣 坑点 4：D2 前端表格的三级展开 (L5) 性能雪崩**
+
+**🔍 计划漏洞**：
+
+D2 前端组件如果一次性请求包含了整个项目所有患者、所有访视、所有缺失字段清单的“全量树状 JSON”，对于一个入组 200 人、缺失 5000 个字段的 IIT 项目，这个 API payload 可能会超过 5MB，导致前端渲染卡死。
+
+**🛠️ 修正建议 (前端与 API)**：
+
+采用**过度设计审查**：L5（具体字段清单）不能随总览 API 一起返回。
+
+* **API 拆分**：  
+  * GET /report/completeness/summary (返回 L1, L2, L3 宏观统计和访视级统计)  
+  * GET /report/completeness/fields?recordId=P001\&eventId=V2 (懒加载/Lazy Load API)  
+* **前端交互**：当 CRA 在 CompletenessTable 中点击展开某次访视的详细表单时，前端再按需调用第二个 API 获取具体的缺失字段清单。
+
+## **三、 对 LLM 友好的延伸设计 (架构红利)**
+
+当前的计划主要聚焦在“传统业务报表（表格）”的渲染。既然您已经做好了这 4 个高质量的结构化 API，千万不要浪费了它对大模型的巨大价值！
+
+**💡 建议补充任务：增强 Tab 0 (执行摘要) 的 LLM 总结能力**
+
+在前端加载 ReportsPage.tsx 的 Tab 0 时：
+
+1. 前端并行请求 D1, D2, D3, D6 的 4 个 API 的 **summary 部分**（不包含 entries 明细）。  
+2. 将这 4 个 JSON summary 拼成一个 Context 对象：  
+   const llmContext \= { D1: d1.summary, D2: d2.summary, D3: d3.summary, D6: d6.summary };
+
+3. 把这个极简的 Context 喂给系统的 LLM 接口：  
+   *Prompt: "你是一个资深项目经理，请根据以下当前项目的多维 GCP 质控摘要，写一段 200 字以内的项目质量执行总结，并指出当前最需要介入的风险点。"*  
+4. 将 LLM 生成的这段话展示在 Tab 0 的最顶端。
+
+**这就是真正的 AI 原生 SaaS**：不仅能提供冷冰冰的报表，还能直接基于结构化报表进行像人一样的洞察和汇报。
+
+## **四、 审查最终结论**
+
+这个开发计划的**粒度非常合适**，属于“刚刚好能落地且能商用”的级别。它没有去强求一次性做完所有的 AI 关联，而是优先把 GCP 需要的“表单底子”搭了出来。
+
+只要在开发任务（Jira/Todos）中**补充上述 4 个避坑建议（特别是 D2 幽灵记录的生成机制）**，这份计划就可以直接发给开发团队启动 Sprint 了！