-
Data Governance Dev authored
移除 Step 3「数据验证」后,Step 号出现断层:1,2,4,5,6,7。重新编号让 Step 号 连续 1-6,对用户更直观。 改动: orchestrator.py: - STEP_REGISTRY:4→3 (空字段扫描), 5→4 (缺注释), 6→5 (字段长度), 7→6 (国标校验) - STEP_DEPENDENCIES 同步重新编号 - step_name() 同步重新编号('3_empty_fields' / '4_missing_comments' / 等) - _run_step4/5/6/7 重命名为 _run_step3/4/5/6(调用方 STEP_REGISTRY 已对,自动匹配) - 顶部 docstring 重写:6 步流程 + 重新编号说明 step_impl/*.py:每个文件里的 step="X" 日志标签同步重新编号 (4→3, 5→4, 6→5, 7→6),同时把 docstring 和 message 文本里的 Step X 字样也改了。 文件本身保留旧文件名(如 step4_empty_fields.py)—— 内部实现细节, 不影响外部行为;如果未来想重命名可单独一次提交。 routes.py:list_steps() 的 StepInfo 也重新编号(4→3, 5→4, 6→5, 7→6) frontend index.html: - form.steps 默认 [1,2,4,5,6,7] → [1,2,3,4,5,6] - 兜底过滤改成 n >= 1 && n <= 6(兼容旧缓存残留的 8/7/3) - TAB_STEP_MAP: - redundancy tab:step 3 → 2(与 merge 同一来源) - empty: 4 → 3 - missing: 5 → 4 - length: 6 → 5 - standards: 7 → 6 注:未触及 workflow/ 旧 CLI 目录、docs/DESIGN.md / README.md 文档, 那些是历史描述,单独一次文档 PR 一起改。 行为:UI 显示 Step 1-6 连续 6 个分析 Step,进度计算 / 报告生成 / section 关联都不变。文件 / 函数命名差异仅是内部实现细节。
472a0c4a