基金量化定投选基系统

# 风险日志

---

| 编号 | 风险项 | 触发条件 | 影响 | 应对策略（规约级防御） |来源|

|------|--------|---------|------|----------------------|---|

| R-1 | 内存溢出 (OOM) | 违反 FW-3 多年份并发 Arrow 转换 | 🔴 致命 | ① DuckDB 硬限 40GB；② CI 设 cgroup 限 50GB 压测；③ 代码 Review 重点检查按年循环 ||

| R-2 | Optuna 在 CPU 下搜索不充分 | 36 核 CPU、大训练集 | 🟡 可控 | 1小时硬限截断取最优；`early_stopping_rounds=50`；单折搜索策略最大化试验次数 ||

| R-3 | T-1 未来数据泄露 | 标准化未执行 `.shift(1)` | 🔴 致命 | ① 单测强制覆盖首日输出 NULL；② CI 加专项断言；③ 代码 Review 最高优检查项 ||

| R-4 | 8 周紧凑致规约妥协 | 并行开发时省略 Type Hints / 单测 | 🟡 可控 | CI 强阻断红线，PR 触发 Error 则绝对禁止合并 ||

| R-5 | fund_basic_info 多余字段污染 | data_loader 未丢弃 4 列非规约字段 | 🟢 可防 | ① `data_loader.py` 显式指定列投影 `SELECT fund_id, fund_name, fund_type, create_date`；② M2 审计日志输出实际列名 ||

| R-6 | 白名单覆盖率异常低 | 实际数据中白名单类型基金占比过低 | 🟡 待观测 | Step 2 审计日志必须输出精确的白名单保留率；若 < 15%，PM 组织专项评审 ||

| R-7 | 当前依赖清华公共 PyPI 源，存在供应链不可控及合规隐患。|企业级合规标准化|🟡 可控|短期可接受；长期企业级治理路线图必须纳入“自建内部 PyPI 服务（如 devpi）”评估。| [[0001-Sprint1规划会议-会议纪要]] |

| R-8 | 单 Gitea Act Runner 串行策略在 S2 引入 I/O 负载（DuckDB）后，存在 CI 反馈时间显著膨胀导致阻塞研发节奏的风险。|企业级合规标准化|🟡 可控|S2 首次包含 I/O 单测的 PR 合并时重点观测。暂不进行预防性扩容（选择容忍），设定明确的量化熔断阈值（180秒），超时再启动基建调整。| [[0001-Sprint_1_回顾会议纪要：工程脚手架与架构护栏落地复盘]]  |