docs(redcap): 重构REDCap文档体系并创建Docker部署操作手册

核心成果:
 创建REDCap模块文档体系（4个分类目录）
 完成《REDCap Docker部署操作手册》- 最核心文档
 梳理从0到1的完整部署流程
 明确Docker文件的可复用性

文档体系:
- 00-模块概览/     系统介绍、方案设计、决策报告
- 01-部署与配置/   部署手册、问题排查（核心）
- 02-系统配置与运维/ 日常管理（规划中）
- 03-API对接与开发/ API开发、二次开发
- 04-参考资料/     旧版文档存档

核心文档:
 10-REDCap_Docker部署操作手册.md（最重要）
  - 完整的从0到1部署流程
  - Docker文件复用说明和可复用性分析
  - 3种环境差异配置（本地/ECS/医院）
  - 5大常见问题与解决方案
  - 部署检查清单
  - 日常维护命令

 13-部署问题排查手册.md
  - 基于实际踩坑经验
  - ERR_CONTENT_DECODING_FAILED
  - CRLF污染问题
  - Base URL配置错误
  - MySQL连接问题

Docker文件可复用性:
 100%可复用（无需修改）:
  - Dockerfile.redcap
  - docker-entrypoint.sh
  - config/php/php.ini
  - .gitattributes

 需根据环境调整:
  - docker-compose.yml（端口、卷路径）
  - config/apache/redcap.conf（域名）
  - config/database.php（数据库连接）

文档重组:
- 移动文档到对应分类目录
- 重命名为标准格式（数字前缀）
- 旧版文档归档到参考资料
- 创建README快速入口

下一步:
- Day 2: 开发REDCap API Adapter
- 创建API使用指南
- 创建对接设计文档

docs/03-业务模块/Redcap/00-模块概览/04-生产环境部署决策报告_ECS_vs_SAE.md

@@ -0,0 +1,53 @@
+# **REDCap 生产环境部署：ECS vs SAE 深度决议报告**
+
+## **1\. 核心结论：认可 ECS 优先策略**
+
+针对 IIT Manager Agent 项目，我们决定将 REDCap 生产环境部署在 **ECS (Docker 模式)** 运行，而不是 SAE。
+
+### **为什么我们“认错”并转向 ECS？**
+
+在讨论 AI 后端时，SAE 的免运维特性很吸引人，但 REDCap 的三个“致命特性”决定了它在 SAE 上会极其痛苦：
+
+1. **Cron 依赖（心跳丢失）**：REDCap 每分钟都需要运行一次 cron.php。在 SAE 中，你得额外买 SchedulerX 服务；在 ECS，只需一行 crontab 就能搞定且 100% 可靠。  
+2. **Session 粘滞（掉线噩梦）**：REDCap 默认将会话存本地。SAE 是多实例的，如果没做 Redis 共享，用户登录后会反复掉线，2 人团队去修这个 Bug 会耗费大量时间。  
+3. **文件系统 POSIX 依赖**：REDCap 像 10 年前的软件一样极其依赖本地文件夹读写。SAE 必须挂载 NAS，网络延迟会拖慢整个系统的响应。
+
+## **2\. 深度对比：务实派的决策依据**
+
+| 维度 | ECS \+ Docker (我们的选择) | SAE (Serverless) | 结论 |
+| :---- | :---- | :---- | :---- |
+| **部署成本** | **低**。入门级 ECS (2核4G) 约 1500元/年。 | **高**。SAE \+ NAS \+ 闲置费用可能更贵。 | **ECS 胜** |
+| **配置复杂度** | **极简**。只需运行 docker-compose.yml。 | **复杂**。需解决共享存储、Session同步、定时任务。 | **ECS 胜** |
+| **系统透明度** | **透明**。直接 docker logs 查看 PHP 日志。 | **黑盒**。云原生链路长，报错时排查难度大。 | **ECS 胜** |
+| **可移植性** | **最强**。这份 Docker 配置可以原封不动挪到医院内网。 | **差**。医院内网通常没有 SAE 这种环境。 | **ECS 胜** |
+
+## **3\. 2 人团队的“生存之道”**
+
+作为一个只有 2 人的团队，我们的时间应该花在 **Agent 的 Prompt 调优** 和 **业务逻辑** 上，而不是花在“调试云产品之间的连接”上。
+
+* **ECS 方案**：你就像拥有了一台真正的电脑。文件在哪、日志在哪、数据库连没连上，你一眼就能看清。  
+* **SAE 方案**：你会陷入“为什么挂载了 NAS 还是没写权限？”、“为什么 Cron 没触发？”这种与业务无关的琐事中。
+
+## **4\. 最终定稿：混合架构蓝图**
+
+我们将采取\*\*“混合云”\*\*的思路，发挥各自的长处：
+
+### **4.1 数据平面 (Data Layer) \-\> 部署在 ECS**
+
+* **组件**：REDCap (Apache \+ PHP 8.1)。  
+* **方式**：使用 Docker-Compose 运行。  
+* **存储**：附件存储在 ECS 挂载的云盘；数据库连接 **RDS MySQL**。  
+* **优势**：保证了 EDC 系统的绝对稳定和传统运维的简便。
+
+### **4.2 控制平面 (AI Agent Layer) \-\> 部署在 SAE**
+
+* **组件**：Node.js 后端、Python 算法、AI 前端。  
+* **方式**：Serverless 部署。  
+* **优势**：利用 SAE 处理 AI 这种流量波动大、需要弹性伸缩的模块。
+
+## **5\. 对后续开发的意义**
+
+1. **本地环境即生产环境**：由于 ECS 跑的是 Docker，你在本地 03-REDCap本地部署方案.md 里写的代码，直接就能上线，没有任何“环境漂移”。  
+2. **离线交付预演**：如果未来医院要求内网部署，我们已经有了一套完整的、基于 ECS/Docker 的交付包，这比 SAE 方案更容易被医院 IT 接受。
+
+**当前状态**：Deployment Strategy Locked | **建议**：立即执行基于 ECS 的生产环境搭建。