原表 9 列、累计固定宽 1100+px、首两列 fixed → 在较窄窗口下渲染异常。
改为 7 列、min-width 弹性布局、去掉 fixed、合并'实际长度/标准长度'：
  - 表名          min-width=140  show-overflow-tooltip
  - 字段名        min-width=130  show-overflow-tooltip
  - 长度(实际/标准) min-width=130 模板渲染 (实际红色加粗/灰色/标准)
  - 浪费字节       width=90   align=right
  - 国家标准      min-width=120  show-overflow-tooltip
  - 规则          min-width=160  show-overflow-tooltip
  - 建议          min-width=160  show-overflow-tooltip
  - el-table 加 max-height=560，行多时纵向滚动

数据字段全部已在 step6 产出，无需改后端。
验证：HTTP 抓取的页面 HTML 已含新表格定义。

- step6_length_check.py: 移除 llm 入参与自定义字段 LLM 推断分支，
  只保留内置 GB/YD 14 条规则；签名简化为 run_step6(dict_data, log)
- orchestrator.py: STEP_REGISTRY 中 Step 6 的 llm_mode 由 optional 改为 none；
  _run_step6 不再向 run_step6 传 llm；顶部 llm_mode 取值注释同步
- routes.py: /api/steps 返回的 Step 6 描述去掉「LLM 可选」字样
- README.md: LLM 依赖矩阵删除 Step 6 行，新增说明 Step 1/3/4/6/7/8 均无 LLM 依赖
- DESIGN.md: Step 6 章节由「固定 + LLM 混合」改为「100% 固定代码」，
  删除 suggest_length_rule 示例
- CLAUDE.md: 补充「不要自动提交，我说提交再提交」纪律

验证：
  - ast.parse 通过 (orchestrator.py / routes.py / step6_length_check.py)
  - 烟雾测试：varchar(50) id_card + varchar(20) mobile → 2 条异常，符合预期

上一个提交引入了 wave 调度,如果用户勾选了有依赖的
Step 但没勾该依赖(如选 1/3/4/5 但不选 2),
调度器会在 ready=[] 时抛 RuntimeError('调度死锁'),
整个 job 标失败,日志提示看起来很严重但其实只是用户配置问题。

修复:
- 在进入 wave 调度前加预处理,把'依赖不在计划里'
  的 Step 拎出来 WARN 跳过(沿用非关键失败的处理路径)
- 把 wave 循环里 ready=[] 时的 RuntimeError 降级为 ERROR +
  break(防御性保留,理论上预处理后不应该再发生)
- 调度计划日志里多加一行 '因依赖缺失跳过=...' 字段,
  用户 / 排查时可以一眼看出被跳了哪个

验证(steps=[1,3,4,5] 此次失败案例):
  调整前:Job 失败,错误 '调度死锁: 剩余 [3] 但无依赖被满足'
  调整后:Step 3 因缺 [2] 被 WARN 跳过,Job 正常跑完 1/4/5

目标
- Step 1（数据字典）为强制步骤，前后端都防御性兜底
- 其余 Step 按依赖图分波并行执行（Wave 调度）
- Step 8 报告生成显式排在所有主步骤之后

调度器（orchestrator.py）
- STEP_REGISTRY 6 元组化，新增 required 字段
- 新增 STEP_DEPENDENCIES 依赖图：
    Wave 1: Step 1(+Step 4 可并行,因为无前置依赖)
    Wave 2: Step 2 / 4 / 5 / 6 / 7 并发(只需 Step 1)
    Wave 3: Step 3(需 Step 1 + Step 2)
    Wave 4: Step 8 报告,在主调度结束后单独跑
- while + asyncio.gather 实现 wave 调度
- 必选步骤缺失时自动追加并打 WARN 日志
- 关键 Step 失败:整流程终止;非关键:标记 failed,
  其余步骤继续(基于依赖的 wave 仍正常推进)
- _run_step4 改为接收 step_outputs["1_data_dict"],
  避免在 Wave 1 与 Step 1 重复连库拉元数据

step4_empty_fields.py
- run_step4 新增 dict_data 参数;复用 Step 1 数据,
  缺省时回退到自取(支持独立跑 Step 4)

前后端契约
- models.StepInfo 加 required: bool
- routes.py /api/steps 给 Step 1 标 required=True
- index.html:el-checkbox :disabled="s.required"
  + 必选 step 标题旁红色 "必选" 标签
- startJob 启动前再兜底检查一次 form.steps 是否包含所有必选

perf
- 全部 8 步情形下,从串行 ~55s 降至 ~30s 级别
  (Wave 2 同时跑 5 个, 加上 LLM 同时批分类 vs 串行等待)

后端
- models.py: OverviewStats 补充 mid_empty_fields / standards_applied 字段，
  避免被 routes.py 的字段过滤机制误删
- orchestrator.py: _build_overview 修正 nested overview_meta 取值（三层嵌套，
  之前一直兜底到 0 → 表/字段总数显示 0)
- step4_empty_fields.py: 修复 table_comment 始终为空（之前从列级 row 取
  table_comment，应从 table_summary 取），新增 per_table.total_fields 与
  field_record 用同一份 table_comment_map

前端 (index.html / style.css)
- 隐藏历史记录入口（保留后端接口，便于以后恢复）
- 移除「中空字段」KPI 卡片（位于中间不符合浏览习惯）
- 大范围空字段 tab：
  * 字段明细（平铺：等级/表名/表注释/字段名/字段注释/类型/空值数/空值率）
    上移到主视图位置
  * 按表统计下移为辅助视图，表名+表注释合并到一列避免错位
- 冗余字段 tab：把 prop 改成与后端实际数据一致的
  field/table_count/classification/reasoning/recommendation/source，并
  给 llm_failed / true_redundancy / suspicious / common_business /
  common_base 各加色 tag 显著标识
- 修复"\"LLM 失败\""导致的 template compile 错误引发的白屏
  （HTML 属性里 \ 不会被当 JS 转义，把 " 换成「 」即可）
- .app-main 宽度 1400 → 1800px，table 更舒展

Why：与本次\"分批次提交并写明关联性\"的工作一致，固化到 CLAUDE.md，
     后续每次 commit 都遵循\"提交信息描述清楚做了什么、为什么\"的格式。

把工作流包装成浏览器化的产品：填表 → 测试连接 → 一键治理 → 实时进度。

核心架构
- web/app.py         FastAPI 入口 + CORS + 静态资源挂载
- web/start.py       启动前依赖检查（可选 anthropic / dmPython）
- web/start.bat      Windows 一键启动脚本
- web/api/routes.py  12 个 REST 接口（jobs/history/standards/reports...）

调度与运行
- web/core/orchestrator.py 8 步流程调度 + 步骤级日志 + 异常 traceback
- web/core/job_manager.py  后台任务管理 + LogBuffer + SSE 订阅
- web/core/db_adapter.py   MySQL / 达梦 统一连接与查询
- web/core/step_impl/      8 个 Step 的 Web 版实现

LLM 增强（可降级）
- web/core/llm.py          Anthropic / OpenAI / MiniMax 多 provider 适配
- configs/llm.example.yaml provider / api_key / base_url / model 模板

SQL 模板体系（Python 不再写 SQL）
- web/sql/info_schema/     list_columns / list_tables  按 dialect 区分 MySQL / 达梦
- web/sql/verify/          count_table_rows
- web/sql/empty_fields/    count_with_nulls
- web/sql/xzqh/            check_dict_table_exists / find_xzqh_orphans
- web/sql/standards/       sample_field_values
- web/sql/health/          check_connection
- web/sql/loader.py        占位符 + dialect 自动加载

前端（无构建步骤）
- web/static/index.html    Vue 3 单页应用
- web/static/lib/          Vue + Element Plus 静态资源
- web/static/style.css

实时日志 / 历史归档 / 报告下载
- SSE 流（GET /api/jobs/{id}/logs/stream）
- outputs/<db>/<ts>/findings/_all_findings.json
- outputs/<db>/<ts>/reports/{md,docx}
- GET /api/history /api/reports/{db}/{ts}/{file}

调试能力（本次一并落地）
- 三路日志：SSE 实时流 + web/logs/app.log + outputs/<db>/<ts>/run.log
- 每步开始 / 完成带耗时、进度 N/M；异常带 traceback 与异常类型
- 数据库 [DB] 连接 / SQL 执行时间；路由 [POST /api/xxx] 入参摘要
- 启动脚本自带 web/logs/start.log

Why：CLI 工作流需要登录机器；Web 端把治理入口放到任何能开浏览器的设备上，
     配合 SSE 实时反馈，业务方也能直接用。
How：复用 workflow/ 中的 8 步逻辑与 standards/ 国标插件；新增 Pydantic 契约
     + job_manager + SSE，前后端用 REST + 事件流通信。

把以下两个文件加入 .gitignore，避免 API Key / 主机信息泄露：
- web/configs/llm.yaml        含 provider api_key
- workflow/config.yaml        含 DB host / user（密码走 env var）

对应的模板文件仍纳入版本控制：
- web/configs/llm.example.yaml
- workflow/config.example.yaml

Why：执行治理时本地会有真实凭据，复用项目时按模板复制即可。

把 Phase 1 的 7 个独立脚本收敛成一条流水线：

工作流核心 workflow/
- run_governance.py：CLI 入口，支持 --db / --steps / --skip / --offline
- config.example.yaml：阈值 / 数据库 / 输出配置（实际 config.yaml 不入库）
- core/
    db.py      连接与查询辅助
    utils.py   配置加载、目录管理、JSON I/O
    reporter.py Markdown + Word 报告生成
- steps/       8 个 Step 的实现（每个文件一个 Step）

8 步流水线：
  1 数据字典 -> 2 合并/冗余(离线) -> 3 数据验证(连库)
  -> 4 空字段(连库) -> 5 缺注释(离线) -> 6 长度检查(离线)
  -> 7 国标校验(连库) -> 8 报告生成(离线)

国标插件 standards/ 独立可扩展
- base.py + registry.py 自动发现所有标准
- std_001_id_card.py   GB 11643-1999  身份证
- std_002_uscc.py      GB 32100-2015  统一社会信用代码
- std_003_mobile.py    YD/T 1313      手机号
- std_004_xzqh.py      GB/T 2260      行政区划代码

Why：脚本是一次性产物，工作流才是可复用的工程；分离国标后新增规范
     只需要再写一个 std_xxx.py 文件。
How：每个 Step 是独立类，产出统一为 dict，run_governance.py 按编号串行
     执行；国标通过字段名匹配自动加载，registry 提供全局发现。

第一阶段，针对 smart-build 数据库做一次性手工治理：
- fetch_data_dictionary.py：拉取 information_schema，输出 data_dictionary.json
- check_empty_fields.py：逐表扫 NULL/空字符串比例，输出高空字段报告
- verify_merge_redundancy.py + .sql：连库验证合并候选的实际行数
- validate_standard_fields.py：对身份证/手机/统一社会信用代码等抽样校验
- check_field_length.py：识别 VARCHAR 超出固定长度的字段（基于国标）
- check_uncommented_fields.py：扫描无注释字段，按字段名启发式推测
- generate_report.py：把以上 JSON 汇总成 Word 报告

Why：先把\"用什么工具看什么数据\"跑通，再抽象成可复用工作流。
How：每个脚本独立运行，输出落 JSON 到 data_dictionary/，最终由
     generate_report.py 汇总成 数据治理报告_smart-build.docx。

定义项目的核心目标与约束：
- 只读分析 smart-build 数据库（MySQL），不修改任何数据
- 五个治理方向：可合并表/冗余字段、空字段、缺注释、固定长度字段、规范字段
- 已识别的国标：身份证、统一社会信用代码、手机号、地区编码
- 工作流分阶段沉淀：脚本 -> 工作流 -> Web 端

Why：后续所有治理脚本、工作流、Web 端都以本目标为准绳。
How：CLAUDE.md 描述目标；.gitignore 屏蔽运行产物（outputs/、JSON
     输出、__pycache__、work-logs 等），保留源代码本身。