ecm_sync_system/docs/enum_refactor/construction_task_detail.md

Construction Task Detail 领域重构指南

1. 范围

本文档对应 backend 的 construction_detail 明细表。

当前优先关注：

• construction_detail.status
• construction_detail.approval_status
• construction_detail.is_complete

2. 字段盘点

2.1 status

当前实现：

• 模型里是 SmallInteger
• 代码注释已经说明该字段废弃
• 同步 schema 里仍有 Optional[int] status

项目侧取值范围：

• 当前无法列出稳定正式范围
• 只能确认它仍是 int 状态字段，且与进度状态相关

集团侧差异：

• 当前没看到集团侧 enum_config 为该明细领域单独列值
• 同步 schema 仍保留该字段，说明推送侧还没有完全去掉它

结论：

• 应优先决定是否彻底下线该字段

2.2 approval_status

当前实现：

• backend 依赖 ApprovalMixin，数据库侧是审批状态数值字段
• 同步 schema construction_detail.py 用的是 ApprovalStatus enum

项目侧取值范围：

• 当前项目侧没有单独的 construction_detail 审批 enum 文件
• 实际范围跟随通用审批体系，不在 construction 模块内独立定义

集团侧差异：

• 同步 schema 已经收紧成 ApprovalStatus
• 项目侧 construction_detail 自身还没有独立、清晰的 enum 入口

结论：

• 应统一接入通用审批状态定义

2.3 is_complete

当前实现：

• 模型里是 Boolean
• backend 和 sync schema 都存在

项目侧取值范围：

• true
• false

集团侧差异：

• 当前没有明显差异

结论：

• 保持布尔字段即可

3. 重点结论

• construction_detail.status 现在的核心问题不是值域不清，而是字段本身是否还应继续存在。
• approval_status 应直接并到通用审批体系，不要在 construction 模块单独再造一套。
• is_complete 语义明确，不需要做枚举化改造。

4. 待修改项清单

1. 决定 construction_detail.status 是否正式废弃。
2. 如果不废弃，补上正式状态定义源。
3. 将 approval_status 明确统一到通用审批 enum 体系。
4. 清理明细层里“旧 status”和“审批状态”并存的混乱状态。