# Construction Task 领域重构指南

## 1. 范围

本文档对应 backend 的 `construction` 主表，也就是施工任务本体。

当前优先关注：

- `construction.section_type_code`
- `construction.task_type`
- `construction.status`

## 2. 字段盘点

### 2.1 `section_type_code`

当前实现：

- 本地有硬编码 `section_type_id_dict`
- 也有 `construction_section_config` 作为配置来源
- 模型里是 `String`
- 创建 schema 里是 `str`
- 同步 schema 对应字段名是 `construction_section`，类型是 `str`

当前使用：

- 是施工初始化和施工任务分区的关键字段
- construction 服务和 config helper 都直接依赖它

项目侧取值范围：

- 本地明确值：`GF`、`SY`、`SC`、`SCDW`

集团侧差异：

- 当前没看到集团侧 `enum_config` 有独立的 Construction 顶层段
- 同步 schema 里有对应字段，但仍是普通字符串

结论：

- 应迁到 `field_config`
- 继续沿用 `construction.section_type_code`

### 2.2 `task_type`

当前实现：

- 模型里是 `String`
- 创建 schema 里是 `str`
- 本地只有一个层级 enum `ConstructionCategory`，值是 `01`、`02`、`0201`、`03`、`0301`、`04`、`05`

当前使用：

- 施工树和类型树逻辑会使用它
- 但业务任务实际取值往往来自施工树节点，而不只是 `ConstructionCategory`

项目侧取值范围：

- 如果按层级 category 看，明确值是：`01`、`02`、`0201`、`03`、`0301`、`04`、`05`
- 如果按真实任务类型看，当前无法从单一代码 enum 列出完整集合，因为还受施工树/`construction_node_config` 影响

集团侧差异：

- 同步 schema 里 `task_type` 仍是 `str`
- 当前没有看到集团侧 `enum_config` 对这个字段给出统一候选项表

结论：

- 不能简单做成单一代码 enum
- 更适合拆成“层级 category”与“真实任务类型”两层定义

### 2.3 `status`

当前实现：

- 模型里是 `SmallInteger`
- 同步 schema 里是 `Optional[int]`
- 本地有 `progress_status_dict`

项目侧取值范围：

- `-1`
- `0`
- `1`

集团侧差异：

- 当前没看到集团侧 `enum_config` 独立列出 Construction.status
- 同步 schema 仍是 `int`

结论：

- 保留数值状态字段
- 需要统一是走代码常量、dict 映射还是后续字段配置

## 3. 重点结论

- `section_type_code` 是典型的字段级配置候选。
- `task_type` 当前最复杂，不能直接当成一个静态 enum 处理。
- `status` 目前是简单数值状态，但也需要统一正式定义源。

## 4. 待修改项清单

1. 将 `section_type_code` 正式迁到 `field_config`。
2. 清理 `section_type_code` 的硬编码 dict 与 config helper 双来源。
3. 拆分 `task_type` 的“层级 category”与“真实任务类型”语义。
4. 明确哪些 `task_type` 值来自施工树，哪些来自配置表。
5. 为 `status` 建立统一常量定义，避免散落数值字面量。