增加项目侧重构文档

2026-03-12 14:54:48 +08:00
parent 758b1c4f77
commit 84b3b7652a
16 changed files with 1485 additions and 458 deletions
@@ -183,4 +183,76 @@ construction 领域后续梳理时，至少要回答下面这些问题：
 4. 哪些逻辑仍在使用硬编码白名单。
 5. `construction_node_config` 中哪些数据只是节点补充信息，哪些其实已经在承担字段候选项职责。

-如果发现某字段既参与初始化又参与手动创建，就应优先考虑迁到字段级配置。
+如果发现某字段既参与初始化又参与手动创建，就应优先考虑迁到字段级配置。
+
+## 9. 按本轮要求的改造落点
+
+construction 领域这轮不是泛泛地“改配置”，而是明确围绕 3 条链路收口：
+
+- 初始化
+- create 校验
+- 下拉列表
+
+### 9.1 初始化
+
+当前施工初始化本来就不是 dict 驱动，而是：
+
+- `construction_section_config`
+- `ConstructionTypeTree`
+- `ConstructionTypeMapping`
+
+因此本轮初始化改造的重点不是“把 dict 搬到 config”，而是：
+
+- 把 `section_type_code` 的候选项读取统一收口到新的 config 工具
+- 保留类型树和 root node 等结构化数据，但不再让 section 候选项散落在私有 helper 里
+
+### 9.2 Create 校验
+
+当前 `ConstructionService.create()` / `create_for_scdw()` 已经在 service 开头做了较强校验：
+
+- `section_type_code` 来自 `construction_section_config`
+- `section_sub_type_code` 来自 section config 和类型树映射
+- `type_id` 来自施工类型树或 SCDW 专用配置
+
+本轮目标是：
+
+- `section_type_code` 统一改成通过 `ConfigService.validate_field_value(project_type, "construction.section_type_code", value)` 校验
+- `section_sub_type_code`、`type_id` 继续走配置/类型树校验，不做降级
+
+### 9.3 下拉列表
+
+当前施工下拉接口已经基本同源：
+
+- `/construction/section/type/list`
+- `/construction/section/sub/type/list`
+- `/construction/task/type/list`
+
+它们当前都来自 `construction_section_config + 类型树`。
+
+本轮目标不是重做接口，而是：
+
+- 让 section 级选项由新的 config 工具统一返回
+- 保证下拉、初始化、create 校验继续同源
+
+### 9.4 清理项
+
+construction 领域这轮优先清理的是“section 候选项读取分散”问题，不是一次性重写全部施工结构。
+
+完成后应清理：
+
+- 只负责 section 候选项翻译的旧 helper 直接解析逻辑
+- 不再适合作为 section 真源的旧硬编码映射
+
+但下面这些不属于本轮删除目标：
+
+- `ConstructionTypeTree`
+- `ConstructionTypeMapping`
+- 与节点树生成强绑定的结构化配置
+
+## 10. 测试关注点
+
+construction 领域 service 层集成测试至少覆盖：
+
+1. 初始化：项目初始化后生成的 section / root node / 主施工任务是否来自目标 config。
+2. 下拉：section / sub type / task type 列表是否和初始化使用同源配置。
+3. Create：合法 `section_type_code`、`section_sub_type_code`、`type_id` 可以创建，非法值明确报错。