# Project Detail Data 领域重构指南

## 1. 范围

本文档对应 backend 的 `project_detail_data` 聚合明细表。

当前优先关注：

- `project_detail_data.key`

## 2. 字段盘点

### 2.1 `key`

当前实现：

- backend 模型里是 `String`
- backend schema 里也是 `str`
- 没有本地正式 enum
- 实际取值由 `ProjectDetailDataService` 和业务逻辑共同决定

项目侧取值范围：

- 当前代码里明确出现的 key 至少包括：
  - `authorized_capacity`
  - `investment_decision_capacity`
  - `plan_construction_capacity`
  - `actual_construction_capacity`
  - `key_constraints`
  - `constructing_capacity`
  - `production_capacity`
  - `ensure_production_capacity`
  - `climb_production_capacity`
  - `challenge_production_capacity`
  - `dynamic_total_investment_price`
  - `complete_investment_price`
  - `complete_investment_rate`
  - `qualified_production_score`

集团侧差异：

- 同步 schema `project_extensions/project_detail.py` 已定义了 `ProjectDetailKey` enum
- 同步 schema 当前只有 7 个 key：
  - `plan_construction`
  - `actual_construction`
  - `production`
  - `ensure_production`
  - `climb_production`
  - `challenge_production`
  - `complete_investment`
- 项目侧和同步侧当前不仅数量不一致，命名也不一致

结论：

- 这是当前差异最大的领域之一
- 不能直接把 backend `key` 当成已经对齐的枚举字段

## 3. 重点结论

- backend `project_detail_data.key` 当前是开放字符串集合。
- 同步侧已经有一套更收敛的 `ProjectDetailKey` enum。
- 两边差异不只是“少几个值”，而是命名体系都还没统一。

## 4. 待修改项清单

1. 为 `project_detail_data.key` 建立正式定义表，不再继续开放字符串。
2. 明确 backend key 与同步 `ProjectDetailKey` 的映射关系。
3. 区分哪些 key 应继续保留在 `project_detail_data`，哪些应回归 Project 主表或扩展表。
4. 先统一命名，再决定是否直接迁成代码 enum 或 `field_config`。