# 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”和“审批状态”并存的混乱状态。