基金量化定投选基系统

# 启动阶段

---

## 下级目录

[[0001-项目章程]] 

[[0002-基金量化定投选基系统设计规约]] 

[[0003-系统架构与工程规范基线]] 

---

## 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 不报错”**。

        *    *DoD的具体完成规范受已签署的 CR 影响*

    *   **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加专项断言”，需在启动阶段就作为任务派发给测试/研发。