ecm_sync_system/docs/enum_refactor/construction_task.md

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 建立统一常量定义，避免散落数值字面量。