启动阶段¶

简介¶

项目启动阶段信息记录。

1. 制定项目章程¶

2. 召开《最终设计规约》签字封板会¶

• 动作：拉齐算法工程师、数据资产管理员、基础架构，逐条过审规约核心参数（20%止盈、150周、DuckDB/Polars防火墙、严禁Pandas等）。
• 目的：确立“规约为唯一真相源”的绝对权威。任何人不得在后续开发中以“我觉得这样更好”为由篡改公式或逻辑。
• 交付物：所有核心干系人在《最终设计规约 (v1.0)》上的签字确认记录（存入 Redmine 项目文档区）。

3. 工程与工具链基线就绪检查¶

• 动作：不要等 Step 1 才搭环境，必须在启动阶段把“基础设施”跑通。
  • Redmine：创建项目空间，配置好核心自定义字段（特别是“验收标准”字段），建立 Step 1 到 Step 6 的史诗级任务及严格的依赖关系树（Step 5 强依赖于 3 和 4 闭合）。
  • Gitea：初始化仓库，强制建好 /docs 目录结构，配置好分支保护规则（主干保护）。
  • Docker + CI：搭建基础运行镜像（Ubuntu 24 + Python + DuckDB + Polars + LightGBM），必须在启动阶段跑通一次 CI 空跑流水线，确保 .gitea-ci.yml 能被正确触发。
• 目的：确保 M1（脚手架）一旦提交，立刻能被机器级卡控接管。

4. 确立 DoD 与 DoR 铁律¶

• 动作：向全员宣贯并锁定本项目的“完成标准”与“就绪标准”。
  • DoD (Definition of Done)：硬性规定 Sprint 的 Done 不是“代码写完”，而是**“数据产物正确 + 单测全过（如标签7场景） + CI 不报错”**。
  • DoR (Definition of Ready)：例如 Step 5 的 DoR 就是 Redmine 中 Step 3 和 4 状态必须为“已关闭”。
• 目的：锁死微步交付的边界，杜绝“带病流转”。

5. 数据资产物理探查与准入¶

• 动作：要求“数据资产管理员”提供小批量物理样本（如 100MB 净值表 + 完整 fund_basic_info 表），研发团队在启动阶段执行一次“Schema 碰撞”。
• 目的：
  • 验证章程中提到的“fund_basic_info 实际比规约多 4 列”是否属实，确认 data_loader 的列投影策略可行（防 R-5）。
  • 验证净值日期是否存在跨周分布，确认周频聚合逻辑的前置假设成立。
  • 输出初步的《数据探查确认单》，作为 Step 2 启动的正式准入凭证。

6. Redmine 风险登记册初始化¶

• 动作：将项目章程中的 6 大风险（R-1 到 R-6，特别是 OOM 和 T-1 未来数据泄露）正式录入 Redmine 的风险跟踪模块，并指定 Owner。
• 目的：从第一天起就让风险可视化。例如 R-3（T-1泄露）的应对策略“单测强制覆盖首日输出NULL + CI加专项断言”，需在启动阶段就作为任务派发给测试/研发。