feat(ssa): Complete QPER architecture - Query, Planner, Execute, Reflection layers

Implement the full QPER intelligent analysis pipeline:

- Phase E+: Block-based standardization for all 7 R tools, DynamicReport renderer, Word export enhancement

- Phase Q: LLM intent parsing with dynamic Zod validation against real column names, ClarificationCard component, DataProfile is_id_like tagging

- Phase P: ConfigLoader with Zod schema validation and hot-reload API, DecisionTableService (4-dimension matching), FlowTemplateService with EPV protection, PlannedTrace audit output

- Phase R: ReflectionService with statistical slot injection, sensitivity analysis conflict rules, ConclusionReport with section reveal animation, conclusion caching API, graceful R error classification

End-to-end test: 40/40 passed across two complete analysis scenarios.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/03-业务模块/SSA-智能统计分析/06-开发记录/J技术报告审核评估与建议/SSA-Pro 方案深度审查与风险评估报告 V2.0.md

@@ -0,0 +1,124 @@
+# **SSA-Pro 方案深度审查与风险评估报告**
+
+**审查对象：** SSA-Pro MVP 开发计划套件 (v1.1)
+
+**包含文档：** MVP计划总览、任务清单、R服务指南、后端指南、前端指南
+
+**审查时间：** 2026-02-18
+
+**总体评级：** **A- (优秀，但存在关键一致性漏洞)**
+
+## **1\. 🚨 关键一致性漏洞 (Critical Inconsistency)**
+
+**这是当前计划中最大的风险点，必须在开工前修复。**
+
+### **漏洞：混合数据传输协议在 R 指南中缺失**
+
+* **架构定义 (V4.1)**：明确定义了“混合数据传输协议”，即 \<1MB 走 Inline JSON，1-20MB 走 OSS 引用。  
+* **后端指南 (Doc 03\)**：正确实现了 data\_source 逻辑，会发送 OSS Key。  
+* **R 服务指南 (Doc 02\)**：❌ **严重缺失**。  
+  * 在 5.2 Wrapper 实现 示例代码中，依然假设 input$data 直接就是数据对象：  
+    \# 错误代码 (Doc 02\)  
+    df \<- tryCatch(as.data.frame(input$data), ...)
+
+  * **后果**：如果后端发来的是 OSS Key，R 服务会直接报错或崩溃，导致 1MB 以上文件无法处理。
+
+### **🛠️ 修正建议**
+
+在 R 服务开发指南中，必须增加一个标准化的 **Data Loader** 工具函数，并在所有 Wrapper 入口处调用：
+
+\# utils/data\_loader.R  
+load\_input\_data \<- function(input\_json) {  
+  \# 兼容旧协议（纯数据）和新协议（data\_source 对象）  
+  if (\!is.null(input\_json$data\_source)) {  
+    source \<- input\_json$data\_source  
+    if (source$type \== "inline") {  
+      return(as.data.frame(source$content))  
+    } else if (source$type \== "oss") {  
+      \# ⬇️ 必须实现 OSS 下载逻辑  
+      return(download\_and\_read\_oss(source$key))  
+    }  
+  }  
+  \# Fallback  
+  return(as.data.frame(input\_json$data))  
+}
+
+## **2\. 架构层面的潜在风险 (Architecture Risks)**
+
+### **2.1 R 服务的“单线程阻塞”风险**
+
+* **现状**：R 语言是单线程的。Plumber 默认也是同步处理。  
+* **场景**：假设 SAE 分配了 1 个实例。用户 A 提交了一个需要跑 10 秒的 Bootstrap 任务。此时用户 B 提交了一个简单的 T 检验。  
+* **后果**：用户 B 的请求会被阻塞 10 秒，甚至超时。HTTP 接口没有排队机制，体验极差。  
+* **建议**：  
+  1. **SAE 层面**：设置较激进的扩容策略（并发数 \> 2 即扩容）。  
+  2. **应用层面**：考虑在 Plumber 中使用 future 包将长任务丢到后台 Promise 中运行（虽然这会增加复杂度），或者简单粗暴地在 Docker 容器中启动多个 R 进程（利用 PM2 管理 Rscript）。**MVP 阶段建议至少部署 2 个 SAE 实例做负载均衡。**
+
+### **2.2 OSS 内网穿透的配置陷阱**
+
+* **现状**：文档强调了使用“VPC 内网 Endpoint”。  
+* **风险**：  
+  * 开发环境（本地 Docker）通常不在 VPC 内，无法访问内网 Endpoint。  
+  * 生产环境（SAE）在 VPC 内，必须访问内网 Endpoint。  
+* **建议**：  
+  * R 代码中的 OSS Endpoint **必须通过环境变量注入**，绝不能硬编码。  
+  * docker-compose.yml (开发) 注入公网 Endpoint。  
+  * SAE 环境变量 (生产) 注入内网 Endpoint。
+
+## **3\. 工程细节的优化建议 (Engineering Improvements)**
+
+### **3.1 代码生成的“可维护性”问题**
+
+* **现状**：在 R 代码中使用 glue 拼接字符串。  
+* **问题**：将大量的 R 代码（如下载逻辑、绘图逻辑）以字符串形式写在 Wrapper 里，不仅难写，而且**没有语法高亮，容易拼错**。  
+* **建议**：  
+  * 采用 **"模板文件分离"** 策略。  
+  * 在 templates/ 目录下存放完整的 .R 文件（如 t\_test\_template.R），在其中用 {{variable}} 占位。  
+  * Wrapper 只负责读取文件并替换变量，不要在代码里写大段字符串。
+
+### **3.2 统计结果的“精度陷阱”**
+
+* **现状**：R 返回的 p\_value 是浮点数。  
+* **问题**：JSON 序列化时，极小的 P 值（如 1.23e-16）在前端 JavaScript 中可能会显示不友好，或者精度丢失。  
+* **建议**：  
+  * R 服务在返回 JSON 前，建议增加一个格式化后的字段，如 p\_value\_fmt: "\< 0.001"，由 R 来决定如何科学计数显示，而不是让前端去猜。
+
+### **3.3 护栏（Guardrails）的“一刀切”风险**
+
+* **现状**：正态性检验失败 \-\> 自动降级。  
+* **问题**：对于大样本（N \> 5000），Shapiro-Wilk 检验过于敏感，哪怕极微小的偏态也会 P \< 0.05。但实际上大样本下 T 检验是鲁棒的（中心极限定理）。  
+* **建议**：  
+  * 优化 guardrails.R 逻辑：当 N \> 500 时，放宽正态性检验的阈值，或者直接跳过 Shapiro 检验，改用 Q-Q 图的峰度/偏度判断（虽然这很难自动化）。  
+  * **MVP 修正**：至少加上 if (N \> 5000\) return PASS 的逻辑，避免大样本被错误降级。
+
+## **4\. 测试数据的缺失 (Missing Test Data)**
+
+文档中提到了“端到端测试”，但缺少\*\*“标准测试数据集 (Golden Datasets)”\*\*。
+
+* **问题**：怎么证明你的 T 检验算得是对的？  
+* **建议**：  
+  * 建立一个 tests/fixtures 目录。  
+  * 准备几组 **“标准答案”**：  
+    1. normal\_data.csv (R 算出来应该是 P=0.042)  
+    2. skewed\_data.csv (应该触发护栏降级)  
+    3. missing\_data.csv (应该报错或自动剔除)  
+  * 在 CI/CD 流程中，自动跑这几组数据，比对结果是否与标准答案一致。
+
+## **5\. 结论与修正计划**
+
+### **✅ 总体评价**
+
+方案架构设计合理，技术栈选型（Node+R+Plumber）成熟。只要修复数据协议的不一致，MVP 成功率极高。
+
+### **📝 需立即执行的修正 (Must-Do)**
+
+1. **修正 Doc 02 (R 开发指南)**：  
+   * \[ \] 增加 utils/data\_loader.R 模块，实现混合协议解析。  
+   * \[ \] 修改 Dockerfile 和 Env 配置，支持 OSS\_ENDPOINT 动态注入。  
+   * \[ \] 修改 Wrapper 模板，使用 load\_input\_data() 替代直接读取。  
+2. **修正 Doc 03 (后端指南)**：  
+   * \[ \] 确认 RClientService 发送给 R 的 Payload 结构与 R 端的解析逻辑完全匹配。  
+3. **补充测试资源**：  
+   * \[ \] 准备 3-5 个涵盖边缘情况（空值、单行、非正态）的标准 CSV 文件。
+
+**建议项目经理（PM）将上述 3 点加入 "Phase 1: 骨架搭建" 的首要任务。**