增加重构文档

docs/enum_refactor/plan.md

@@ -344,26 +344,58 @@ async def validate_field_value(
 主计划只定义系统级方案。具体领域的梳理应拆到独立文件，例如：
 
 - [construction.md](/Users/zyl/my_projects/ecm_sync_system/docs/enum_refactor/construction.md)
+- [project.md](/Users/zyl/my_projects/ecm_sync_system/docs/enum_refactor/project.md)
 
-后续 project / contract / material 等领域也应按同样方式分别整理。
+后续 contract / material 等领域也应按同样方式分别整理。
+
+每个领域文档都不是只看“集团侧已有字段”或者“准备迁到 `field_config` 的字段”。
+
+每个领域都必须同时覆盖两部分字段：
+
+- depm 中所有已经使用以下来源之一的字段：代码 enum、代码中的初始化列表、硬编码 dict、类 enum、`config` 表、`dict` 表
+- 集团侧 `enum_config` 中该领域涉及的全部字段
+
+两部分做并集，不做交集。
+
+也就是说：
+
+- `enum_config` 中出现的字段，必须全部纳入领域文档
+- 即使某字段暂时没有出现在 `enum_config` 中，只要 depm 已经在用代码 enum / 类 enum / 初始化列表 / 硬编码 dict / `config` 表 / `dict` 表承载它，并且它影响初始化、手动创建、编辑、校验、展示，也必须纳入领域文档
+
+这里要特别避免一种错误写法：
+
+- 不能把领域范围写成“只讨论和集团侧 `enum_config` 直接对应的字段”
+- 不能因为某字段暂时只有 depm 本地 enum / 类 enum，而集团侧还没有对应项，就把它排除在领域文档之外
 
 每个领域文档都应至少覆盖以下内容：
 
-### 8.1 整理不查表的 enum 类数据
+### 8.1 先做字段总表
+
+每个领域文档开头都应先列出字段总表，至少回答：
+
+- 集团侧 `enum_config` 覆盖了哪些字段
+- depm 侧当前还额外维护了哪些相关字段
+- 每个字段当前使用的来源是什么：代码 enum、初始化列表、硬编码 dict、类 enum、`config` 表、`dict` 表，或它们的混用
+- 每个字段分别影响哪些链路：项目初始化、手动创建、手动编辑、接口展示、历史数据兼容、业务校验
+
+如果同一个字段在多个来源重复定义，也必须明确记出来，而不是只记录“最终准备保留哪个”。
+
+### 8.2 整理不查表的 enum 类数据
 
 不是只有查表型数据才需要整理。
 
-如果某领域存在不依赖字典表、也不依赖 config 表的纯 enum / 纯硬编码候选项，同样要梳理：
+如果某领域存在不依赖字典表、也不依赖 `config` 表的纯 enum / 纯硬编码候选项，同样要梳理：
 
 - 当前定义位置在哪
 - 是否重复定义
 - 是否和集团侧 `enum_config` 对应字段有关
+- 是否参与初始化、手动创建、手动编辑、展示翻译或历史校验
 - 是否需要继续保留为代码 enum
 - 是否应该迁到新的 `field_config`
 
 也就是说，纯 enum 数据如果和初始化字段、手动创建字段有关，也在本轮视野内。
 
-### 8.2 梳理哪些功能需要迁移到新的 `field_config`
+### 8.3 梳理哪些功能需要迁移到新的 `field_config`
 
 每个领域都需要明确列出：
 
@@ -371,6 +403,7 @@ async def validate_field_value(
 - 哪些手动创建 / 编辑功能依赖字段候选项
 - 哪些历史白名单校验需要迁移到 `validate_field_value()`
 - 哪些直接遍历旧 JSON 的逻辑需要迁移到 `get_field_options()` / `get_field_option_map()`
+- 哪些字段虽然目前由 `dict` 表或代码 enum 承载，但实际上已经在承担“按项目类型变化的候选项字段”职责
 
 并且必须给出示例。
 
@@ -380,17 +413,17 @@ async def validate_field_value(
 - 手动创建时从硬编码 dict 判断合法值，改为调用 `validate_field_value()`
 - 展示名称时从字段选项里直接拿 `label`
 
-### 8.3 重点关注集团侧 `enum_config` 对应字段
+### 8.4 必须完整对齐集团侧 `enum_config`
 
-领域梳理时，应优先关注集团侧 `enum_config` 中已有对应关系的字段。
+领域梳理时，不能只挑 depm 里已经处理过的字段，也不能只挑“看起来最容易改”的字段。
 
-因为这类字段本身就属于：
+每个领域都必须把集团侧 `enum_config` 中该领域涉及的字段逐一对齐到 depm，明确说明它现在处于哪一种状态：
 
-- 按项目类型变化
-- 会参与初始化
-- 通常也会参与手动创建与校验
+- depm 已有同名或同语义字段，并且来源清晰
+- depm 有近似字段，但命名、语义、来源或取值范围不完全一致
+- depm 还没有正式落点，只能先记录缺口
 
-因此，每个领域都应围绕这类字段检查两条链路：
+对齐 `enum_config` 时，每个字段都应继续检查两条链路：
 
 - 项目初始化时，取值从哪里来，如何展开
 - 手动创建 / 更新时，取值如何校验，是否和初始化使用同一来源