# DataOps Platform 代码库完整解析与迭代升级基线

> 基线日期：2026-07-16
> 产品决策复核：2026-07-16
> 分析对象：当前 `master` 工作树中的主源码、前端、数据库脚本、部署包、测试与现有技术文档
> 目标：为下一轮迭代提供可追溯的架构、代码逻辑、页面—接口—存储映射和风险优先级基线

## 1. 结论摘要

DataOps Platform 当前是一个“单仓库、多运行时、混合存储、部分能力外置”的数据运营平台：Vue 2 前端通过 `/api` 调用 Flask 后端；PostgreSQL 保存订单、产品、审核、用户和任务记录；Neo4j 保存元数据、业务域、数据源、数据流程及其关系；MinIO 保存上传文件；n8n 承担工作流管理和执行；LLM 用于翻译、DDL 解析、订单实体提取和加工逻辑生成。

代码规模约为：

| 范围 | 规模 |
|---|---:|
| Flask 主后端 | 66 个 Python 文件，21,578 行 |
| 前端 | 289 个 Vue 文件、65 个 JS 文件，56,903 行 |
| 后端路由 | 9 个 Blueprint、107 个路由 |
| 前端 API 调用定义 | 430 个有效调用 |
| 可与本仓库 Flask 路由精确匹配 | 82 个（约 19.1%） |
| 外部服务、历史网关或本仓库未实现 | 348 个（约 80.9%） |
| PostgreSQL DDL | 20 个 SQL 文件 |

最重要的判断如下：

1. **当前不是一个完全自包含的前后端系统。** 活跃页面中既有本仓库闭环功能，也有依赖 `/authentication`、`/vanna`、`/dataFactory`、`/digitizationData` 等历史服务的功能。经产品确认，这 348 个未匹配调用基本属于后端服务已经下线后的前端遗留，后续默认按删除和瘦身处理，而不是补建同名后端。
2. **主源码与生产发布源码发生反向漂移。** `app/` 与 `deployment/app/` 有 12 个文件不同，且部署副本包含较新的 DeepSeek、运行时环境加载、日志和生产端口修复。此时执行 `deployment/sync_release.sh` 会用较旧的 `app/` 覆盖部署副本，存在生产回退风险。
3. **认证链路在契约上不闭环。** 前端登录后读取 `data.token`，后端登录接口只返回用户信息；前端之后发送 `Authorization: Bearer undefined`。同时绝大多数后端路由没有认证装饰器，所以“前端路由守卫”并没有形成后端安全边界。
4. **仓库存在必须优先处理的凭据风险。** Git 跟踪了 SSH 私钥 `cursorssh-143`，主配置中还包含 LLM、n8n、MinIO、Neo4j、PostgreSQL 等硬编码凭据或回退值。
5. **数据订单是当前最完整的端到端业务链路。** 它跨 PostgreSQL、Neo4j、LLM、任务表、生成脚本/n8n 工作流和数据产品注册，但缺少跨存储事务、幂等和补偿机制，容易产生“订单失败但图节点/产品/任务已部分创建”的状态。
6. **DataFlow 只保留定义、关系和查询能力。** 执行、状态和日志接口当前是 TODO/mock，产品已确认不再在本代码库实现，应删除对应后端路由、前端 API 和操作入口，不再规划新的调度器来补齐它们。n8n 中的 Workflow 是执行编排实体，不应重命名为 DataFlow。
7. **现有文档不能作为唯一事实来源。** `docs/CODE_DOCUMENTATION.md` 对技术栈、LLM 和部分模块的描述已落后于部署副本，且没有覆盖真实前端页面、外部 API 和源码漂移。

### 1.1 已确认的产品决策

以下内容已由产品侧于 2026-07-16 确认，可直接作为代码瘦身依据：

- 348 个前端未匹配调用基本属于已下线后端服务的遗留调用；默认动作是删除不可达页面、API 定义和关联组件，不为这些旧路径恢复后端。
- DataFlow 的执行、执行状态和执行日志不再由本代码库提供；保留 DataFlow 定义、CRUD、关系、脚本元信息和血缘用途。
- Vanna 已停止使用；`dataChart`、`modelSystem` 及 `api/dataChart.js` 等依赖 Vanna 的页面和调用进入删除范围。
- Airflow 已停止使用；主配置、部署配置、环境变量模板和文档中的 Airflow 配置进入删除范围。
- n8n 继续保留，覆盖工作流管理、执行记录、订单生成工作流和 `onboard` 回调；n8n 与 DataFlow mock 运行接口是两条不同链路，清理时不得误删 n8n 适配层。
- 统一术语：`DataFlow` 表示平台内的数据流程定义、输入输出关系、脚本元信息和血缘节点；`n8n Workflow` 表示 n8n 的执行编排对象。代码和 API 中继续使用 n8n 原生 `workflow` 命名，前端统一展示为“n8n 工作流”或“执行编排”，不将其改名为 `dataflow`。一个 DataFlow 可以关联多个有明确版本标识的 Workflow，同一环境只允许一个当前生效版本。
- 原“产品知识库”更名为“数据治理知识库”。知识来源包括数据业务域定义、数据流程定义、元数据定义以及后续纳入的数据治理资产，目标能力为统一入库、检索和问答；采用“治理对象变更后增量同步 + 每日全量一致性巡检”，不复用已下线的 Vanna/RAG 历史接口。
- 工作台继续保留，支持按用户保存布局；第一阶段提供待审核数、订单状态、数据产品统计、数据源健康和 n8n 执行状态等有限标准组件，并重建本仓库内的持久化接口。
- 暂不开放自助注册；建立管理员、编辑者、查看者三级 RBAC。部署初始化时创建首个管理员，后续用户只能由管理员创建。
- `app/` 是唯一后端源码。先将 `deployment/app/` 中仍有效的修复合并回 `app/`，再将部署目录改为单向生成产物。
- DeepSeek 是当前唯一默认生成式 LLM 和问答模型；数据治理知识库允许使用 Qwen Embedding 模型。删除 Qwen 对话/生成回退，只保留用途隔离的 Embedding 客户端与配置；Vanna 和 Airflow 配置进入清理范围。
- 数据资源、数据模型、数据指标须经可达性核验后删除；本报告第 6.2 节已完成静态核验。数据安全保留前端入口，第一阶段作为明确的待建设占位功能。
- 旧数据工厂非 n8n 模块整体移除，只保留 n8n 适配、订单生成 n8n 工作流、执行记录和回调链路。
- `mcp-servers/task-manager/` 已确认不再使用，进入整体删除范围；HOPMS 数据导入脚本、测试、源文档和 `docs/generated/*.json` 验收样例保留。
- 本轮只从代码和初始化 DDL 中清理已确认的历史表；生产数据库真实表须在只读核查、备份和依赖确认后单独下线。
- 本轮完成历史代码瘦身和 Node LTS 升级；Vue 3 迁移放到下一阶段，不与业务边界收敛同时实施。
- 问卷薪酬、图表定制、旧系统管理、名片解析和数据资产原型已确认整体移除。旧系统管理删除时保留通用 404 页面；名片解析删除时保留当前数据治理中的 `dataGovernance/dataSource` 能力。

## 2. 仓库层级与源码归属

```text
DataOps-platform/
├── app/                         # 主后端源码；开发迭代应以此为唯一源代码入口
│   ├── api/                     # Flask Blueprint 路由层
│   ├── core/                    # 业务逻辑、图谱、LLM、n8n、数据处理
│   ├── models/                  # SQLAlchemy 模型与统一响应
│   ├── services/                # Neo4j 驱动、DB 健康检查、历史公共函数
│   ├── config/                  # 运行配置与 CORS
│   └── scripts/                 # PostgreSQL 初始化/迁移辅助脚本
├── frontend/                    # Vue 2 单页应用
│   ├── src/router/routes.js     # 静态菜单与页面路由事实来源
│   ├── src/api/                 # 前端 API 客户端
│   ├── src/views/               # 页面与业务组件
│   ├── src/store/               # Vuex 状态
│   └── src/utils/request.js     # Axios 封装与响应契约
├── database/                    # 手工 PostgreSQL DDL/迁移脚本
├── datafactory/                 # DataMeta Agent/n8n 工作流资源
├── mcp-servers/task-manager/    # 独立 Node.js MCP 服务；已确认整体删除
├── deployment/                  # 可独立上传的生产发布包；当前含有与 app/ 不一致的源码副本
├── scripts/                     # 本地/部署运维与数据导入脚本
├── tests/                       # 后端单元测试，当前无前端测试
└── docs/                        # API、部署和专题文档
```

源码归属建议：

- `app/`、`frontend/src/`、`database/` 应是唯一可编辑源。
- `deployment/app/`、`deployment/database/` 应由 CI 或单向同步脚本生成，不能继续作为另一份可人工修改源码。
- `docs/generated/` 是导入结果，不应被当作业务代码。
- `mcp-servers/task-manager/` 是独立子系统：不在 Flask Blueprint、前端路由或主部署链中注册，已确认不再使用并整体删除。

## 3. 运行架构与层级关系

```mermaid
flowchart TD
    U["浏览器用户"] --> V["Vue 2 SPA :18183"]
    V -->|"/api/*"| N["Nginx / API 网关"]
    N --> F["Gunicorn + Flask"]
    F --> A["Blueprint API 层"]
    A --> C["Core 业务层"]
    C --> P[("PostgreSQL")]
    C --> G[("Neo4j")]
    C --> M[("MinIO")]
    C --> W["n8n API / Webhook"]
    C --> L["DeepSeek / OpenAI-compatible LLM"]
    C --> FS["本地生成脚本与 workflow JSON"]
    W -->|"订单 onboard 回调"| A
```

### 3.1 后端调用层级

```text
HTTP 请求
  -> app/api/<domain>/routes.py          参数解析、响应包装、异常转译
  -> app/core/<domain>/*.py              业务规则、状态机、图查询、外部调用
  -> app/models/*.py                     PostgreSQL ORM 模型
  -> app/services/*.py                   Neo4j/数据库基础设施
  -> PostgreSQL / Neo4j / MinIO / n8n / LLM
```

实际代码没有完全遵守该分层：部分路由直接写 Cypher，`core/system/auth.py` 直接使用 psycopg2 连接池，`core/data_flow/dataflows.py` 和 `core/data_service/data_product_service.py` 直接执行 SQL，导致事务、测试和复用边界不统一。

### 3.2 前端调用层级

```text
routes.js
  -> defaultRoute.js 动态 import 页面
  -> views/**/*.vue
  -> api/*.js
  -> utils/request.js (Axios, baseURL=/api)
  -> 本仓库 Flask 或外部网关服务
```

前端当前使用静态路由。`store/modules/menu.js` 的远程菜单调用已注释，权限信息直接取自 `routes.js`；因此路由上的 `roles` 字段并未形成真正的动态授权。

## 4. 后端模块与核心代码逻辑

### 4.1 应用初始化与通用响应

- `app/__init__.py` 创建 Flask 应用、初始化 SQLAlchemy/CORS、注册 9 个 Blueprint、配置日志和全局异常处理。
- API 正常返回主要使用 `app/models/result.py` 的 `{code, message, data}` 结构。
- 多数业务错误只改变 JSON 内的 `code`，HTTP 状态仍为 200；前端依赖响应体 `code` 判断成功。这不利于网关、监控、重试和标准客户端处理。
- 全局异常处理会把原始异常文本返回给前端，可能泄露内部结构和连接信息。

### 4.2 元数据 `meta_data`

主要职责：

- `DataMeta` 节点列表、详情、图谱、创建、更新、删除和搜索。
- 新增/更新时进行冗余检测，必要时在 PostgreSQL 创建 `metadata_review_records`。
- 上传、预览、下载结构化/非结构化文件到 MinIO。
- 解析文本并创建 `DataMeta`/`Tag` 图节点。
- 审核处理支持合并、创建、忽略等动作，并写入 `metadata_version_history`。

主要存储：Neo4j `DataMeta`、`DataLabel`、`Tag`、`master_data`；PostgreSQL 审核与版本表；MinIO 文件对象。

### 4.3 业务域 `business_domain`

主要职责：

- `BusinessDomain` 列表、详情、保存、更新、删除和图谱展示。
- 通过 `INCLUDES` 连接 `DataMeta`，通过 `LABEL` 连接 `DataLabel`，通过 `COME_FROM` 连接 `DataSource`。
- 上传 DDL/Excel/Word/PDF，调用 `DDLParser` 解析表和字段。
- 组合多个元数据或业务域，复用/创建元数据并建立关系。
- 新元数据与候选元数据按名称、类型和标签匹配，生成审核记录。

该模块是最大的图谱写入入口之一，`business_domain.py` 约 1,979 行，已混合查询、规则、序列化、审核、创建与更新逻辑，建议拆分为 Repository、MatchingPolicy、ReviewService 和 DomainService。

### 4.4 数据接口 `data_interface`

主要职责：

- `data_standard` 节点的新增、详情、更新、列表、代码生成和图谱。
- `DataLabel` 节点的新增、详情、列表、动态识别、图谱和删除。
- 聚合业务域、数据流、元数据之间的全图关系。

需要注意：数据标准标签使用小写 `data_standard`，其他主要标签使用 PascalCase；图模型命名不一致会增加查询和迁移成本。

### 4.5 数据源 `data_source`

主要职责：

- 将连接配置保存为 Neo4j `DataSource` 节点。
- 列表、删除、连接串解析、LLM 校验和 SQLAlchemy 连接测试。
- `/graph` 路由仍为 TODO，当前没有实际实现。

连接测试可接受用户提供的主机、端口和凭据；在后端无认证的情况下，它相当于一个可访问内网数据库的探测入口，必须纳入 P0 安全治理。

### 4.6 数据流程 `data_flow`

主要职责：

- `DataFlow` 图节点 CRUD。
- 维护业务域/数据源与数据流程的 `INPUT`、`OUTPUT`、`LABEL`、`child` 关系。
- 根据业务域元数据生成源表和目标表 DDL。
- 创建 `public.task_list` 任务记录并关联脚本路径。
- 获取关联脚本内容。

已确认删除的运行时部分：

- `execute_dataflow` 及 `/execute-dataflow/{id}`。
- `get_dataflow_status` 及 `/get-dataflow-status/{id}`。
- `get_dataflow_logs` 及 `/get-dataflow-logs/{id}`。
- 前端 `runDataFlow/getDataFlowExecute/getDataFlowLog` 和页面“运行”操作。

删除后，DataFlow 继续作为图谱中的加工过程定义和血缘节点存在，但不再表达本系统可直接执行该流程。此处不再引入 Airflow 或新的统一调度服务。

#### DataFlow 与 n8n Workflow 的命名边界

两者不应合并为同一个术语：

| 对象 | 平台语义 | 代码/接口命名 | 用户界面名称 |
|---|---|---|---|
| `DataFlow` | 数据流程定义、输入输出关系、加工要求、脚本元信息和血缘 | `/api/dataflow/*`、Neo4j `DataFlow` | 数据流程 |
| n8n Workflow | n8n 中可启停、查看执行记录和触发的执行编排对象 | `/api/datafactory/workflows/*`、`workflow_id` | n8n 工作流 / 执行编排 |

保留 `workflow` 命名的原因是它与 n8n 公共 API 和对象模型一致，也能避免把“治理定义”误解为“本平台直接执行的任务”。映射规则已确认：一个 DataFlow 可以关联多个有明确版本标识的 n8n Workflow；按环境区分部署状态，每个 DataFlow 在同一环境只能有一个当前生效版本。建议持久化 `dataflow_id`、`environment`、`n8n_workflow_id`、`version`、`is_active`、部署状态和最近一次执行状态，并对 `(dataflow_id, environment)` 的生效记录建立唯一约束。当前代码只生成本地 workflow JSON，没有持久化 n8n Workflow ID，链路仍不完整。

### 4.7 数据工厂 `data_factory`

这是对 n8n 公共 API 的适配层：

- `N8nClient` 负责 URL、鉴权、HTTP 请求和异常封装。
- `N8nService` 将 n8n 的 workflow/execution 结构转为前端格式。
- API 支持工作流列表、详情、状态、启停、执行记录、Webhook 触发和健康检查。

它不负责前端 `dataFactory.js` 中旧版生产线、接入、加工、集成、日志等约 98 个接口；这些非 n8n 旧数据工厂页面和调用已确认整体删除。保留范围仅包括 n8n 客户端、适配服务、`/api/datafactory/workflows*`、执行记录、健康检查、订单生成 n8n workflow JSON 和 `onboard` 回调。

### 4.8 数据产品与数据订单 `data_service`

#### 数据产品

- PostgreSQL `data_products` 保存产品元信息和目标物理表定位。
- 预览接口查询 `information_schema`，再动态读取目标表并合并 Neo4j 字段标签。
- 支持 Excel 下载、浏览标记、统计刷新、注册和删除。
- 血缘可视化沿 `DataFlow -> BusinessDomain -> DataMeta/DataSource` 追踪生产链。

风险：目标 schema/table 来自产品注册参数，随后拼接进动态 SQL。虽然使用双引号，但没有白名单校验，仍应按 SQL 标识符注入风险治理。

#### 数据订单状态机

```mermaid
stateDiagram-v2
    [*] --> pending: 创建订单
    pending --> analyzing: 开始 LLM 分析
    analyzing --> need_supplement: 提取失败
    analyzing --> manual_review: 无匹配域或不可连通
    analyzing --> pending_approval: 图谱可连通
    need_supplement --> pending: 修改订单
    manual_review --> pending: 修改订单
    pending_approval --> processing: 审批并生成资源
    manual_review --> processing: 人工审批
    processing --> onboard: n8n/数据工厂回调
    onboard --> completed: 用户确认完成
    pending_approval --> rejected: 驳回
    manual_review --> rejected: 驳回
```

审批通过后会依次：

1. 用 LLM 提取输出业务域、字段和处理逻辑。
2. 在 Neo4j 创建输出 `BusinessDomain`、`DataMeta`、`DataFlow` 以及 `INPUT/OUTPUT/INCLUDES/LABEL` 关系。
3. 在 PostgreSQL 注册 `data_products`。
4. 在 PostgreSQL 写入 `task_list`。
5. 在本地生成 n8n workflow JSON。
6. 将订单置为 `processing`，等待 `/orders/{id}/onboard` 回调。

这条链路跨越多个不可共同提交的存储，没有 Saga/Outbox、幂等键或补偿清理。任何中途失败都可能留下孤立图节点、重复产品或无效任务。

### 4.9 系统、认证和图操作

- `system` 提供健康、配置、系统信息、配置校验、注册、登录、用户查询和翻译。
- 用户密码只是 Base64 编码，不是安全密码哈希。
- `require_auth` 比较整个 Authorization 头与 `SECRET_KEY`，但当前业务路由没有普遍使用该装饰器。
- `/api/graph/query` 可执行任意 Cypher；在无认证状态下风险极高。
- Neo4j 关系普遍使用内部 `id(node)` 作为跨表引用。Neo4j 内部 ID 不适合作为稳定业务主键，应逐步迁移为 UUID/业务 ID。

### 4.10 数据清洗、校验与 LLM

- `DataCleaner` 支持空值、重复、类型转换和离群值处理。
- `DataValidator` 提供必填、类型、正则、邮箱、电话和自定义规则。
- 这两个模块目前更像工具库，未形成明确的 API 或数据流程执行闭环。
- `DDLParser` 支持 SQL/Excel/Word/PDF，优先本地 SQL 解析，再调用 LLM。
- 主源码仍有 Qwen/DashScope 生成式回退配置，部署副本已转向 DeepSeek。产品已确认 DeepSeek 为唯一默认生成式 LLM 和知识库问答模型，同时允许 Qwen Embedding 用于语义向量化。应将部署副本中的有效 DeepSeek 修复合并回 `app/`，删除 Qwen 对话/生成回退和硬编码配置；Qwen Embedding 使用独立客户端、独立模型配置和独立用途凭据，不能重新演变为通用 LLM 回退。

## 5. 后端 API 完整清单

共 107 个路由。以下路径均含 `/api` 前缀。

### 5.1 `system`：8 个

| 方法 | 路径 | 逻辑/存储 |
|---|---|---|
| GET | `/system/health` | PostgreSQL、Neo4j 和系统健康 |
| GET | `/system/config` | 脱敏配置视图 |
| GET | `/system/info` | 进程/系统信息 |
| GET | `/system/config/validate` | 配置完整性检查 |
| POST | `/system/auth/register` | PostgreSQL `users` |
| POST | `/system/auth/login` | PostgreSQL `users` |
| GET | `/system/auth/user/{username}` | PostgreSQL `users` |
| POST | `/system/translate` | LLM/本地回退翻译 |

### 5.2 `meta`：22 个

| 方法 | 路径 |
|---|---|
| POST | `/meta/node/list`、`/meta/node/graph`、`/meta/node/delete`、`/meta/node/edit`、`/meta/node/add`、`/meta/node/update` |
| GET | `/meta/check`、`/meta/search`、`/meta/config` |
| POST | `/meta/full/text/query`、`/meta/unstructure/text/query`、`/meta/text/graph`、`/meta/unstructured/process` |
| POST | `/meta/resource/upload`、`/meta/resource/display`、`/meta/resource/translate`、`/meta/resource/node` |
| GET | `/meta/resource/download` |
| POST | `/meta/review/list`、`/meta/review/create`、`/meta/review/resolve` |
| GET | `/meta/review/detail` |

### 5.3 `bd`：12 个

| 方法 | 路径 |
|---|---|
| POST | `/bd/list`、`/bd/detail`、`/bd/delete`、`/bd/save`、`/bd/update` |
| POST | `/bd/upload`、`/bd/graphall`、`/bd/ddlparse`、`/bd/search`、`/bd/compose`、`/bd/labellist` |
| GET | `/bd/download` |

### 5.4 `interface`：15 个

| 方法 | 路径 |
|---|---|
| POST | `/interface/data/standard/add`、`detail`、`code`、`update`、`list`、`graph/all` |
| POST | `/interface/data/label/add`、`detail`、`list`、`dynamic/identify`、`graph/all`、`delete` |
| POST | `/interface/labellist`、`/interface/graphall`、`/interface/metric/label/standard/delete` |

### 5.5 `datasource`：7 个

全部为 POST：`/datasource/save`、`list`、`delete`、`parse`、`valid`、`conntest`、`graph`。

### 5.6 `dataflow`：10 个

| 方法 | 路径 |
|---|---|
| GET | `/dataflow/get-dataflows-list`、`/get-dataflow/{id}`、`/get-dataflow-status/{id}`、`/get-dataflow-logs/{id}`、`/get-BD-list`、`/get-script/{id}` |
| POST | `/dataflow/add-dataflow`、`/execute-dataflow/{id}` |
| PUT | `/dataflow/update-dataflow/{id}` |
| DELETE | `/dataflow/delete-dataflow/{id}` |

### 5.7 `datafactory`：10 个

| 方法 | 路径 |
|---|---|
| GET | `/datafactory/workflows`、`/workflows/{id}`、`/workflows/{id}/status`、`/workflows/{id}/executions`、`/executions`、`/executions/{id}`、`/health` |
| POST | `/datafactory/workflows/{id}/activate`、`deactivate`、`execute` |

### 5.8 `dataservice`：19 个

| 方法 | 路径 |
|---|---|
| GET | `/dataservice/products`、`/products/{id}`、`/products/{id}/preview`、`/products/{id}/download`、`/orderlist`、`/orders/{id}/detail` |
| POST | `/dataservice/products`、`/products/{id}/lineage-visualization`、`/products/{id}/viewed`、`/products/{id}/refresh` |
| DELETE | `/dataservice/products/{id}` |
| POST | `/dataservice/neworder`、`/orders/{id}/analyze`、`approve`、`reject`、`onboard`、`complete` |
| PUT | `/dataservice/orders/{id}/update`、`/orders/{id}/delete` |

### 5.9 `graph`：4 个

全部为 POST：`/graph/query`、`/graph/node/create`、`/graph/relationship/create`、`/graph/subgraph`。

## 6. 前端页面—接口—后端—存储映射

### 6.1 活跃路由映射

| 页面路由 | 页面组件 | 主要 API | 后端/存储 | 闭环状态 |
|---|---|---|---|---|
| `/home`、`/home/edit` | `views/home` | `/authentication/user/menu/*` | 历史菜单服务已下线 | **保留；重建按用户布局持久化，首期有限标准组件** |
| `/knowledge-base-product`（历史路由名） | `knowledgeBaseProduct/index` | `/text/product/list` | 历史知识库服务已下线 | **更名并重建为数据治理知识库，支持治理定义检索和问答** |
| `/data-chart` | `dataChart` | `/vanna/v0/*` | 已停用 Vanna | **已确认删除** |
| `/data-governance/metadata` | `dataGovernance/metadata` | `/meta/node/*`、`/meta/review/create`、`/interface/labellist`、`/system/translate` | Neo4j、PostgreSQL 审核表、LLM | **本仓库闭环** |
| `/data-governance/business-domain` | `dataGovernance/businessDomain` | `/bd/*`、`/meta/node/list`、`/interface/labellist`、`/datasource/list` | Neo4j、MinIO、PostgreSQL 审核表、LLM | **本仓库闭环** |
| `/data-governance/data-standard` | `dataGovernance/dataStandard` | `/interface/data/standard/*`；删除调用 `/metric/label/standard/delete` | Neo4j | 列表/新增/详情闭环；**删除路径少 `/interface` 前缀** |
| `/data-governance/data-process` | `dataGovernance/dataProcess` | `/dataflow/*`、`/interface/labellist` | Neo4j、PostgreSQL `task_list`、脚本文件 | 保留定义/CRUD；删除运行、状态、日志 |
| `/data-governance/data-Label` | `dataGovernance/dataLabel` | `/interface/data/label/*` | Neo4j `DataLabel` | **本仓库闭环** |
| `/data-governance/data-source` | `dataGovernance/dataSource` | `/datasource/list/save/delete/parse/valid/conntest` | Neo4j、外部目标数据库、LLM | 除 graph 外闭环 |
| `/data-book/data-metadata`及详情 | `dataBook/dataMetaData` | `/meta/node/list/edit/graph`、`/interface/graphall` | Neo4j | **本仓库闭环** |
| `/data-book/business-domain`及详情 | `dataBook/businessDomain` | `/bd/list/detail/search`、`/interface/graphall` | Neo4j | **本仓库闭环** |
| `/data-book/data-standard`及详情 | `dataBook/dataStandard` | `/interface/data/standard/list/detail`、`/interface/graphall` | Neo4j | **本仓库闭环** |
| `/data-book/data-process`及详情 | `dataBook/dataProcess` | `/dataflow/get-*`、`/interface/graphall` | Neo4j、脚本文件 | 查询闭环 |
| `/data-book/data-label`及详情 | `dataBook/dataLabel` | `/interface/data/label/list/detail`、`/interface/graphall` | Neo4j | **本仓库闭环** |
| 数据工厂“生产线管理” | 外部 URL `VUE_APP_N8N_URL` | 直接跳转 n8n | n8n | 外部系统 |
| `/dataFactory/workflow` | `dataFactory/workflow` | `/datafactory/workflows*`、`executions*`、`health` | n8n API | **保留；术语固定为 n8n 工作流/执行编排** |
| `/dataService/dataOrder` | `dataService/dataOrder` | `/dataservice/order*` | PostgreSQL、Neo4j、LLM、n8n/文件 | **核心链路闭环，但跨存储一致性不足** |
| `/dataService/dataProduct` | `dataService/dataProduct` | `/dataservice/products*` | PostgreSQL、目标物理表、Neo4j | **本仓库闭环** |
| `/dataReview` | `dataReview` | `/meta/review/list/detail/resolve`、`/dataflow/get-BD-list` | PostgreSQL 审核/历史表、Neo4j | **本仓库闭环** |
| `/data-asset`及详情 | `dataAsset` | 无真实 API | 页面内硬编码一条示例数据 | **已确认删除** |
| `/model-system/*` | `modelSystem/*` | `/vanna/v0/*` | 已停用 Vanna | **已确认删除** |

### 6.2 已注释但仍保留代码的页面

以下功能在 `routes.js` 中已注释或隐藏，但源码仍存在，会继续增加维护成本：数据资源、数据模型、数据指标、数据安全、RDBMS/非结构化数据来源、旧数据工厂接入/加工/集成、系统管理、问卷、图表定制等。

#### 数据资源、数据模型、数据指标静态可达性复核

| 模块 | 路由状态 | API/后端状态 | 残余引用 | 结论 |
|---|---|---|---|---|
| 数据资源 | 治理页和数据地图页全部注释 | 前端依赖 `/resource/*`；本仓库没有对应 Blueprint | 旧数据工厂 `dispatch` 页面和数据地图共享组件旧默认 API | 当前无可达业务入口；随旧数据工厂删除，并清理共享组件默认值后可删除 |
| 数据模型 | 治理页和数据地图页全部注释 | 前端依赖 `/model/*`；本仓库没有对应 Blueprint | 引用集中在 `dataGovernance/dataModules`、`dataBook/dataModel` | 当前无可达业务入口，可以删除 |
| 数据指标 | 治理页和数据地图页全部注释 | 前端依赖 `/metric/*`；本仓库没有指标 CRUD Blueprint | 引用集中在 `dataGovernance/dataIndicator`、`dataBook/indicator` | 当前无可达业务入口，可以删除；`/interface/metric/label/standard/delete` 是数据标准删除接口，不代表指标模块仍可用 |

该结论来自静态路由、动态组件路径、前端 API 引用和 Flask Blueprint 的交叉核验。当前 `store/modules/menu.js` 的远端 `getMenu2` 调用已注释，运行时直接使用 `router/routes.js`，不存在后端动态菜单重新激活这三个模块的代码路径。真正删除时仍执行三道保护：先移除共享组件中的旧默认 API，再执行前端构建，最后回归元数据、业务域、数据标准、数据标签、数据流程、数据产品和数据审核页面。本次未实时核对线上静态包，部署前仍需确认线上包与当前源码版本一致。

数据安全与上述三项不同：当前 `dataGovernance/dataSecurity/index.vue` 是未调用后端的占位页面，`created()` 中的初始化已注释。产品已确认保留并恢复“数据安全”前端入口，首期页面应明确展示“规划中/待建设”，避免用空表伪装为已实现功能，后续再补权限策略、脱敏、审计或分级分类等正式能力。

已确认整体删除：Vanna/DataChart/ModelSystem、Airflow 配置、DataFlow mock 运行时、问卷薪酬、图表定制、旧系统管理、名片解析、数据资产原型、数据资源、数据模型、数据指标、旧数据工厂非 n8n 页面和 `mcp-servers/task-manager/`。保留项是 n8n、数据治理知识库、工作台、数据安全入口、HOPMS 导入工具，以及当前已经闭环的数据治理/地图/服务/审核能力。

### 6.3 前端 API 依赖分布

| 前端 API 模块 | 调用数 | 本仓库匹配 | 外部/未实现 |
|---|---:|---:|---:|
| `dataGovernance.js` | 91 | 43 | 48 |
| `dataFactory.js` | 108 | 10 | 98 |
| `dataService.js` | 9 | 9 | 0 |
| `dataOrder.js` | 9 | 9 | 0 |
| `dataOrigin.js` | 11 | 6 | 5 |
| `dataReview.js` | 3 | 3 | 0 |
| `dataBook.js` | 52 | 0 | 52 |
| `dataChart.js` | 40 | 0 | 40 |
| `menu.js` | 29 | 0 | 29 |
| `system.js` | 39 | 0 | 39 |
| `user.js` | 9 | 1 | 8 |
| 其他 4 个模块 | 30 | 1 | 29 |

未匹配接口按一级路径聚合，主要为：`dataFactory` 141、`authentication` 57、`vanna` 43、`digitizationData` 33、`op_maintenance` 14、`resource` 12、`model` 11、`metric` 11，其余为 `dags/parse/pipeline/text/rag/graph` 等。

产品侧已确认这些未匹配调用大部分来自已下线后端。实施删除前仍需对活跃路由和仍被 import 的组件做一次可达性复核；只有产品明确要求保留的少量模块才进入重新实现或外部服务映射。

## 7. 数据库与图模型对应

### 7.1 PostgreSQL 表

| 表 | 代码模型/入口 | 页面/API | 状态 |
|---|---|---|---|
| `public.users` | `core/system/auth.py` 直接 psycopg2 | 登录、注册、用户查询 | 运行时建表；Base64 密码；无正式迁移 |
| `public.data_products` | `models/DataProduct` | 数据产品列表、预览、下载、统计、血缘 | 活跃核心表 |
| `public.data_orders` | `models/DataOrder` | 数据订单创建、分析、审批、回调、完成 | 活跃核心表；`data_source` 依赖单独迁移 |
| `public.metadata_review_records` | `MetadataReviewRecord` | `/dataReview`、元数据/业务域冗余审核 | 活跃核心表 |
| `public.metadata_version_history` | `MetadataVersionHistory` | 审核解决时记录前后快照 | 活跃核心表 |
| `public.task_list` | dataflow/order 服务直接 SQL | 订单审批生成任务、数据流程 | 活跃；无 ORM 模型 |
| `public.calendar_info` | SQL 脚本 | 当前 Flask 路由无直接使用 | 遗留/外部功能 |
| `public.calendar_records` | SQL/脚本 | 当前 Flask 路由无直接使用 | 遗留/外部功能 |
| `public.wechat_users` | SQL/迁移脚本 | 当前 Flask 路由无直接使用 | 外部微信登录能力 |
| `business_cards` / `duplicate_business_cards` | SQL 脚本 | 前端 `/parse/*`，本仓库无后端路由 | 外部/遗留能力 |
| `hotel_group_brands` | SQL 脚本 | 问卷/薪酬外部接口 | 参考数据；DDL 注释引用不存在的 `sequence_no` |
| `hotel_positions` | SQL 脚本 | 问卷/薪酬外部接口 | 参考数据 |

本轮数据库清理边界已经确认：对随历史模块下线的表，只清理代码引用和初始化 DDL，不在本轮直接执行生产 `DROP TABLE`。生产真实表下线必须独立完成只读 schema/数据量/最近写入/依赖核查、备份、审批和可恢复删除方案。

数据库治理问题：

- `requirements.txt` 包含 Alembic/Flask-Migrate，但仓库没有可追溯的 Alembic revision 链。
- DDL、增量 ALTER、回滚脚本混在同一目录，没有版本顺序和已执行状态。
- ORM、DDL 和生产库可能漂移，例如 `data_orders.data_source` 依赖额外脚本。
- `result_product_id`、`result_dataflow_id` 等跨 PostgreSQL/Neo4j 引用没有数据库外键，也没有应用级一致性审计。
- `users` 同时绕过 SQLAlchemy，自建 psycopg2 池，连接与事务管理不统一。

### 7.2 Neo4j 图模型

核心节点：

| 节点标签 | 含义 | 主要入口 |
|---|---|---|
| `DataMeta` | 字段/元数据 | 元数据、业务域、订单生成 |
| `BusinessDomain` | 业务表/业务域/输出数据产品域 | 业务域、数据订单 |
| `DataSource` | 数据库连接与来源 | 数据源、业务域 |
| `DataFlow` | 加工流程 | 数据流程、数据订单 |
| `DataLabel` | 标签 | 数据标签、元数据、业务域、流程 |
| `data_standard` | 数据标准 | 数据标准 |
| `DataResource`、`DataModel` | 旧版资源/模型 | 路由已关闭或依赖外部接口 |
| `Tag`、`master_data` | 非结构化标签/主数据 | 元数据扩展能力 |

核心关系：

```mermaid
flowchart LR
    DS["DataSource"] -->|"COME_FROM 反向语义：BD 来源于 DS"| BD["BusinessDomain"]
    BD -->|"INCLUDES"| DM["DataMeta"]
    DM -->|"LABEL"| DL["DataLabel"]
    DM -->|"ALIAS"| DM2["DataMeta"]
    BD -->|"INPUT"| DF["DataFlow"]
    DF -->|"OUTPUT"| OUT["BusinessDomain"]
    DF -->|"LABEL"| DL
```

代码中同时出现 `BusinessDomain-[:INPUT]->DataFlow` 和部分查询注释/旧逻辑中的其他方向假设，下一轮应建立唯一图模型约束、关系方向和索引定义。

### 7.3 MinIO、文件系统与外部存储

- MinIO 保存业务域上传文件和元数据资源文件。
- 数据产品实际数据不存于 `data_products`，而是由 `target_schema + target_table` 指向 PostgreSQL 物理表。
- 订单审批会在本地 `datafactory/workflows/` 生成 n8n Workflow JSON，在 `datafactory/scripts/` 约定任务脚本路径。
- Vanna、相关 Redis/PgVector 管理页面和 Airflow 配置已确认不再使用，应从当前系统架构和部署要求中移除。
- HOPMS 导入工具暂时保留，包括 `scripts/import_hopms_dataset.py`、对应测试和源 DOCX；`docs/generated/*.json` 作为验收样例一并保留，不随本轮历史模块删除。

## 8. 关键业务链路

### 8.1 DDL 到业务域

```text
前端上传文件
-> /bd/ddlparse
-> DDLParser 本地解析或 LLM
-> 前端确认表/字段
-> /bd/save 或 /bd/update
-> Neo4j BusinessDomain + DataMeta + LABEL/INCLUDES/COME_FROM
-> 命中重复规则时写 metadata_review_records
-> /dataReview 人工处理
-> metadata_version_history + Neo4j 合并/新建
```

### 8.2 数据订单到数据产品

```text
创建 data_orders
-> LLM 提取业务域/字段/用途/标签
-> Neo4j 匹配和连通性分析
-> 人工审批
-> 创建输出 BusinessDomain/DataMeta/DataFlow
-> 注册 data_products
-> 创建 task_list
-> 生成 n8n workflow JSON
-> n8n 执行脚本
-> onboard 回调
-> 用户确认 completed
```

### 8.3 数据产品预览与血缘

```text
data_products 定位 schema/table
-> information_schema 读取列
-> 动态 SELECT 读取样例/统计
-> Neo4j 根据 source_dataflow_id 查目标业务域和字段标签
-> 前端表格/血缘图展示
```

### 8.4 数据治理知识库（下一轮目标链路）

现有 `/knowledge-base-product` 页面仍使用产品资料字段和已下线的 `/text/product/list`、历史 RAG 对比组件，不能直接作为新功能后端契约。建议保留页面入口但重构名称、数据模型和交互：

```text
业务域 / DataFlow / DataMeta / 数据标准 / 数据标签等治理定义
-> 按实体类型、业务域、版本、责任人和权限抽取标准知识文档
-> 治理对象变更后增量同步，并每日执行一次全量一致性巡检
-> 保存来源实体 ID、版本、内容哈希和更新时间
-> 使用 Qwen Embedding 建立语义索引，同时保留关键词检索
-> 检索结果携带来源、实体类型和版本引用
-> DeepSeek 基于检索上下文回答
-> 用户可回跳原始治理对象核验答案
```

首期至少需要：变更增量同步、每日一致性巡检、统一搜索、问答、来源引用、权限过滤和索引状态；不得直接复用 Vanna、旧 `/rag/*` 或 `/text/product/*` 契约。知识库应以现有治理实体为事实源，不维护另一套无法追溯的手工副本。DeepSeek 负责生成式问答，Qwen Embedding 只负责向量化，两类模型配置和调用适配必须解耦。

### 8.5 工作台（下一轮目标链路）

现有 `/home/edit` 调用已下线的 `/authentication/user/menu/*`，且标准组件清单基本被注释。首期标准组件确认为：待审核数、订单状态、数据产品统计、数据源健康和 n8n 执行状态。后端按用户保存组件 ID、布局、尺寸和必要配置；组件能力由三级 RBAC 过滤，不开放任意前端组件路径或脚本配置。

## 9. 风险与技术债优先级

### P0：迭代开始前必须处理

1. **撤销并轮换仓库中的真实凭据。** 删除 Git 跟踪的 SSH 私钥，轮换 SSH、LLM、n8n、MinIO、Neo4j、PostgreSQL 凭据；必要时清理 Git 历史。
2. **落实唯一源码。** `app/` 已确认为唯一后端源码；将 `deployment/` 改为生成产物，先逐项审查并把部署副本中仍有效的修复合并回 `app/`，再执行单向同步，禁止当前脚本直接覆盖。
3. **修复认证闭环。** 使用 Argon2/bcrypt 密码哈希、签发有时效的 JWT/session、后端统一鉴权和管理员/编辑者/查看者三级 RBAC；首期不提供自助注册，禁止只依赖前端路由守卫。
4. **关闭危险匿名能力。** 优先保护任意 Cypher、数据源连接测试、文件上传下载、订单审批和系统配置接口。
5. **建立前端删除清单。** 以路由可达性、组件 import 和 API 引用为依据清理 348 个历史调用；默认删除，只有产品明确保留的模块才重新设计后端契约。
6. **对生产数据库做只读 schema 快照。** 对比 SQLAlchemy 模型、SQL 文件和实际表结构，再生成正式迁移基线。

### P1：架构稳定化

1. 统一 HTTP 状态码和响应结构，建立 OpenAPI 契约。
2. 引入 Alembic 正式 revision，停止手工无序 SQL 发布。
3. 将 Neo4j 查询、PostgreSQL ORM/SQL、MinIO 和 n8n 抽为 Repository/Adapter。
4. 为订单审批引入 Saga/Outbox、幂等键、补偿清理和可恢复步骤状态。
5. 用业务 UUID 替代 Neo4j 内部 `id()`。
6. 校验动态 schema/table 标识符；限制数据源连接测试的协议、网段和账号权限。
7. 删除 DataFlow 的 mock 执行、状态和日志接口，同时保留 DataFlow 作为定义和血缘节点的语义。

### P2：前端与功能收敛

1. 为活跃路由建立明确 API ownership；优先保证数据研发、数据地图、数据服务和审核闭环。
2. 修复数据标准删除路径缺少 `/interface` 前缀的问题。
3. 删除硬编码的数据资产原型页面和路由。
4. 删除 Vanna/DataChart/ModelSystem、Airflow 配置、DataFlow 运行时操作、问卷薪酬、图表定制、旧系统管理、名片解析、数据资源、数据模型、数据指标、旧数据工厂非 n8n 页面和 task-manager MCP 服务；保留数据安全入口。
5. 前端升级到受支持 Node LTS；本轮保持 Vue 2，Vue 3 渐进迁移明确放到下一阶段。
6. 移除生产环境全局禁用 `console.error`，接入统一前端错误上报。
7. 将原产品知识库重构为数据治理知识库，围绕业务域、数据流程、元数据等治理定义设计采集、索引、检索和问答契约；工作台重建按用户保存布局的后端契约，首期仅提供有限标准组件。两者均不复用已经下线的历史接口。

### P3：工程化与可观测性

1. 后端单元、API 契约、PostgreSQL/Neo4j 集成、订单 Saga 和前端 E2E 测试。
2. CI 中执行 lint、type check、test、依赖/密钥扫描和部署包一致性检查。
3. 统一结构化日志、request ID、审计日志、指标和告警。
4. 前后端构建产物版本化，部署后自动进行健康、登录和关键页面烟测。

## 10. 建议的下一轮开发计划

### Sprint 0：基线与安全收口（1–2 周）

- 凭据轮换和 Git 安全清理。
- 合并 `app/` 与 `deployment/app/`，建立一致性 CI。
- 导出生产 API 路由、网关配置、PostgreSQL schema 和 Neo4j schema。
- 定义核心域负责人：元数据、业务域、DataFlow 定义/血缘、n8n 执行编排、订单/产品、数据治理知识库。
- 产出 OpenAPI v1 和历史代码删除清单。

**退出条件：** 可以明确回答每个活跃页面调用哪个服务、部署哪份代码、读写哪些数据。

### Sprint 1：认证、契约与迁移（2–3 周）

- 新认证机制和管理员/编辑者/查看者三级 RBAC；部署初始化创建首个管理员，关闭自助注册，后续用户由管理员创建，并为危险接口加权限。
- 统一错误码、HTTP 状态和请求校验。
- 建立 Alembic 基线与生产 schema 差异报告。
- 修复活跃页面已知接口错配和登录 token 契约。

**退出条件：** 未登录无法访问业务 API；数据库变更可版本化、可回滚。

### Sprint 2：订单可靠性与 DataFlow 语义收口（3–4 周）

- 将订单审批拆为可恢复步骤，加入幂等、Outbox 和补偿。
- 删除 DataFlow 运行、状态和日志的 mock 链路，统一其“定义与血缘节点”定位。
- 保留 n8n 订单工作流链路及 `workflow` 原生命名，前端统一显示“n8n 工作流/执行编排”；实现一个 DataFlow 对多个有版本标识的 Workflow，并保证同一环境只有一个当前生效版本，同时升级部署、执行追踪、失败重试和 `onboard` 回调可靠性。
- 建立订单—任务—流程—产品一致性巡检。

**退出条件：** 任一步骤失败可重试或补偿，不留下不可解释的半成品。

### Sprint 3：前端与外部能力收敛（3–5 周）

- 按页面清理 348 个未匹配调用，删除 Vanna、Airflow、问卷薪酬、图表定制、旧系统管理、名片解析、数据资产原型、数据资源、数据模型、数据指标、旧数据工厂非 n8n 页面、task-manager MCP 服务和其他不可达历史页面；恢复并保留数据安全占位入口。
- 外部服务客户端分域，环境配置显式化。
- 建立数据治理知识库的增量同步、每日全量一致性巡检、Qwen Embedding 检索和 DeepSeek 问答能力；建立工作台按用户保存布局能力，首期组件为待审核数、订单状态、数据产品统计、数据源健康和 n8n 执行状态。
- 升级 Node LTS 和前端依赖，保持 Vue 2，补齐关键页面 E2E；Vue 3 迁移进入下一阶段计划。

**退出条件：** 活跃菜单中不再出现静态演示页或无所有者接口。

### Sprint 4：可观测性与发布（2–3 周）

- 全链路 request/trace ID、结构化日志、审计日志和告警。
- CI/CD、数据库迁移门禁、部署包校验和回滚演练。
- 性能基线：大图查询、DDL 解析、产品预览、订单分析。

## 11. 验收指标建议

| 领域 | 指标 |
|---|---|
| API 闭环 | 活跃页面 API 100% 有明确服务 owner；无 owner 调用为 0 |
| 安全 | 仓库密钥扫描为 0；危险接口认证覆盖 100% |
| 数据库 | ORM/DDL/生产 schema 差异为 0；所有变更有 migration revision |
| 可靠性 | 订单跨存储步骤可重试、可补偿；重复审批不产生重复资源 |
| 测试 | 核心后端服务、API 契约和活跃页面 E2E 纳入 CI |
| 发布 | `app/` 与发布包一致性自动校验；部署可回滚 |
| 可观测性 | 订单、任务、流程、n8n 执行可用同一关联 ID 查询 |

## 12. 本次验证边界

已完成：

- 全仓库文件、路由、前端 API、页面导入、ORM、SQL、Cypher、部署脚本和配置的静态解析。
- 147 个 Python 文件语法解析，语法错误为 0。
- 主源码与部署副本差异检查。
- 当前工作树检查；仅保留用户已有的 `frontend/src/router/routes.js` 菜单隐藏修改，未覆盖该改动。

未完成且需要后续环境支持：

- 当前本机 Python 环境没有 Flask、SQLAlchemy、Neo4j、MinIO、OpenAI、psycopg2、pandas、numpy 和 pytest，现有 18 个后端测试函数无法执行。
- `frontend/node_modules` 不存在，未执行前端构建或浏览器 E2E。
- 本次没有连接生产 PostgreSQL、Neo4j、MinIO、n8n 或线上网关，因此“外部/未实现”表示本仓库未找到对应实现，不等于线上一定不可用。
- 未对线上静态包和服务器当前部署副本做实时校验。

## 13. 建议立即补充的架构产物

1. `OPENAPI.yaml`：本仓库 107 个路由的正式契约。
2. `FRONTEND_REMOVAL_INVENTORY.md`：348 个历史调用对应的页面、组件、API 定义、删除批次和少量保留例外。
3. `DATA_MODEL.md`：PostgreSQL ER 图、Neo4j 标签/关系约束、跨存储 ID 规则。
4. `DEPLOYMENT_SOURCE_OF_TRUTH.md`：源码到发布包、前端静态包、Nginx/Gunicorn 的唯一发布链。
5. `ADR-001-authentication.md`、`ADR-002-workflow-engine.md`、`ADR-003-cross-store-consistency.md`。

完成以上基线后，再排具体功能需求，能显著降低下一轮迭代在认证、接口归属、数据库迁移和部署回退上的返工。

## 14. 详细设计决策补充

以下边界已由产品侧确认，后续设计和开发计划直接以此为准：

1. 数据治理知识库采用“治理对象变更后增量同步 + 每日全量一致性巡检”。增量同步负责时效性，每日巡检负责发现漏同步、版本漂移和孤立索引。
2. DeepSeek 负责知识库最终问答；语义检索允许使用 Qwen Embedding 模型。Qwen Embedding 是专用向量化依赖，不恢复 Qwen 作为生成式 LLM 的回退路径。具体 Embedding 型号、向量维度和索引存储属于技术选型，不再构成产品边界问题。
3. 一个 DataFlow 可以对应多个有明确版本标识的 n8n Workflow；不同环境分别管理生效状态，同一个 DataFlow 在同一环境只允许一个当前生效版本。
4. 工作台首期标准组件包括待审核数、订单状态、数据产品统计、数据源健康和 n8n 执行状态，支持按用户保存布局。
5. 部署初始化时创建第一个管理员；系统不开放自助注册，后续新用户由管理员创建，并赋予管理员、编辑者或查看者角色。
6. HOPMS 的 `docs/generated/*.json` 作为验收样例保留，同时保留源 DOCX、导入脚本和自动化测试。

## 附录 A：107 个后端路由逐项索引

本附录记录瘦身实施前的当前代码基线，由 `app/api/*/routes.py` 的 Blueprint 前缀和路由装饰器逐项核对。已确认删除的 DataFlow 运行时路由仍列在这里，便于后续通过路由数量变化验证清理结果。

### A.1 business_domain

```text
POST   /api/bd/list
POST   /api/bd/detail
POST   /api/bd/delete
POST   /api/bd/save
POST   /api/bd/update
POST   /api/bd/upload
GET    /api/bd/download
POST   /api/bd/graphall
POST   /api/bd/ddlparse
POST   /api/bd/search
POST   /api/bd/compose
POST   /api/bd/labellist
```

### A.2 data_factory

```text
GET    /api/datafactory/workflows
GET    /api/datafactory/workflows/{workflow_id}
GET    /api/datafactory/workflows/{workflow_id}/status
POST   /api/datafactory/workflows/{workflow_id}/activate
POST   /api/datafactory/workflows/{workflow_id}/deactivate
GET    /api/datafactory/workflows/{workflow_id}/executions
GET    /api/datafactory/executions
GET    /api/datafactory/executions/{execution_id}
POST   /api/datafactory/workflows/{workflow_id}/execute
GET    /api/datafactory/health
```

### A.3 data_flow

```text
GET    /api/dataflow/get-dataflows-list
GET    /api/dataflow/get-dataflow/{dataflow_id}
POST   /api/dataflow/add-dataflow
PUT    /api/dataflow/update-dataflow/{dataflow_id}
DELETE /api/dataflow/delete-dataflow/{dataflow_id}
POST   /api/dataflow/execute-dataflow/{dataflow_id}
GET    /api/dataflow/get-dataflow-status/{dataflow_id}
GET    /api/dataflow/get-dataflow-logs/{dataflow_id}
GET    /api/dataflow/get-BD-list
GET    /api/dataflow/get-script/{dataflow_id}
```

### A.4 data_interface

```text
POST   /api/interface/data/standard/add
POST   /api/interface/data/standard/detail
POST   /api/interface/data/standard/code
POST   /api/interface/data/standard/update
POST   /api/interface/data/standard/list
POST   /api/interface/data/standard/graph/all
POST   /api/interface/data/label/add
POST   /api/interface/data/label/detail
POST   /api/interface/data/label/list
POST   /api/interface/labellist
POST   /api/interface/graphall
POST   /api/interface/data/label/dynamic/identify
POST   /api/interface/data/label/graph/all
POST   /api/interface/metric/label/standard/delete
POST   /api/interface/data/label/delete
```

### A.5 data_service

```text
GET    /api/dataservice/products
GET    /api/dataservice/products/{product_id}
GET    /api/dataservice/products/{product_id}/preview
POST   /api/dataservice/products/{product_id}/lineage-visualization
GET    /api/dataservice/products/{product_id}/download
POST   /api/dataservice/products/{product_id}/viewed
POST   /api/dataservice/products/{product_id}/refresh
DELETE /api/dataservice/products/{product_id}
POST   /api/dataservice/products
GET    /api/dataservice/orderlist
GET    /api/dataservice/orders/{order_id}/detail
POST   /api/dataservice/neworder
PUT    /api/dataservice/orders/{order_id}/update
POST   /api/dataservice/orders/{order_id}/analyze
POST   /api/dataservice/orders/{order_id}/approve
POST   /api/dataservice/orders/{order_id}/reject
POST   /api/dataservice/orders/{order_id}/onboard
POST   /api/dataservice/orders/{order_id}/complete
PUT    /api/dataservice/orders/{order_id}/delete
```

### A.6 data_source

```text
POST   /api/datasource/save
POST   /api/datasource/list
POST   /api/datasource/delete
POST   /api/datasource/parse
POST   /api/datasource/valid
POST   /api/datasource/conntest
POST   /api/datasource/graph
```

### A.7 graph

```text
POST   /api/graph/query
POST   /api/graph/node/create
POST   /api/graph/relationship/create
POST   /api/graph/subgraph
```

### A.8 meta_data

```text
POST   /api/meta/node/list
POST   /api/meta/node/graph
POST   /api/meta/node/delete
POST   /api/meta/node/edit
GET    /api/meta/check
POST   /api/meta/node/add
GET    /api/meta/search
POST   /api/meta/full/text/query
POST   /api/meta/unstructure/text/query
POST   /api/meta/resource/upload
POST   /api/meta/resource/display
GET    /api/meta/resource/download
POST   /api/meta/resource/translate
POST   /api/meta/resource/node
POST   /api/meta/unstructured/process
POST   /api/meta/text/graph
GET    /api/meta/config
POST   /api/meta/node/update
POST   /api/meta/review/list
POST   /api/meta/review/create
GET    /api/meta/review/detail
POST   /api/meta/review/resolve
```

### A.9 system

```text
GET    /api/system/health
GET    /api/system/config
GET    /api/system/info
GET    /api/system/config/validate
POST   /api/system/auth/register
POST   /api/system/auth/login
GET    /api/system/auth/user/{username}
POST   /api/system/translate
```

## 附录 B：2026-07-16 历史代码清理实施回填

> 本附录记录依据本报告和产品确认结论完成的第一轮代码瘦身。附录 A 仍保留清理前的 107 路由基线，便于追溯对比。

### B.1 恢复点

- 清理前完整归档：`/Users/maxiaolong/Documents/Codex/2026-07-06/g-i/DataOps-platform-backup-before-cleanup-20260716-170321.tar.gz`
- 归档大小：11 MB。
- SHA-256：`866c6c4aff127f88497a5ddf39ac8d8da93008cc784ae6f276f80a7cd17d4ef0`。
- 归档包含 `.git/`、`app/`、`frontend/`、`database/`、`deployment/`、分析报告及清理前未提交工作树，可直接用于逐文件恢复。

### B.2 已完成清理

- 删除 216 个已跟踪历史文件，净删除约 3.5 万行；包含 Vanna/DataChart、ModelSystem、数据资产原型、问卷薪酬、图表定制、数据资源/模型/指标、旧数据来源、旧系统管理、旧数据工厂非 n8n 页面、不可达工作台动态图表组件和 `mcp-servers/task-manager/`。
- 前端 API 定义由清理前 430 个调用收敛为 79 个实际 HTTP 调用，删除 351 个（81.6%）；`dataFactory.js` 仅保留 10 个 n8n 适配调用。
- DataFlow 后端删除执行、状态、日志 3 条 mock 路由和对应服务方法；后端路由由 107 条降为 103 条，额外删除了与产品权限边界冲突的公开自助注册路由。
- 数据安全保留可见占位入口；数据治理知识库入口改正名称并明确增量同步、每日一致性巡检、Qwen Embedding 与 DeepSeek 问答的后续边界。
- 工作台收敛为待处理审核、数据订单状态、数据产品统计、数据源健康度、n8n 执行状态 5 个标准组件，支持按当前用户名保存显示和排序。
- 删除日历、微信用户、名片、酒店品牌和酒店职位相关 Python 迁移代码及 14 个初始化/迁移 SQL；保留订单、产品、审核、版本和任务 6 个核心 SQL。本轮未执行任何生产表删除。
- 将 `deployment/app/` 中 12 处有效的 DeepSeek、DDL 解析、环境加载、日志、时区和健康检查修复回并到 `app/`，删除 Airflow 与 Qwen 生成式配置，再通过 `deployment/sync_release.sh` 单向刷新部署副本；`app/`、`database/` 与部署副本当前无差异。
- 前端运行时从固定 Node 14.7.0 升级为 Node 24 LTS 范围 `>=24 <25`，增加 `.nvmrc` 并更新锁文件；Vue 2 保持不变。

### B.3 验证结果

- 清理契约：8 项通过，覆盖保留入口、删除目录、API 收敛、DataFlow/n8n 边界、HOPMS 样例、Node LTS 和历史 SQL。
- Python：`compileall` 通过；最终隔离环境执行 `pytest` 共 38 项通过。
- 前端：Node `v24.14.0`、npm `10.9.8` 下依赖安装成功，生产构建成功，无缺失模块或 ESLint 错误。
- 部署一致性：`diff -qr app deployment/app` 和 `diff -qr database deployment/database` 均为空。
- 仍需后续处理的已知技术债：Vue 2 及部分前端依赖已停止维护，安装审计报告 72 个依赖漏洞，构建仍有 console、CSS 顺序和大包体警告；这些应与 Vue 3 迁移和依赖治理一并规划，不在本轮业务边界清理中升级。

### B.4 下一轮明确待实现项

- 正式的管理员、编辑者、查看者三级 RBAC；初始化首个管理员，并仅允许管理员创建用户。本轮已经关闭前后端自助注册入口，但未新增用户管理功能。
- DataFlow 与 n8n Workflow 多版本映射：一个 DataFlow 可关联多个 Workflow 版本，同一环境仅一个当前生效版本。
- 数据治理知识库的数据模型、增量同步、每日全量一致性巡检、Qwen Embedding 检索和 DeepSeek 问答。
- 工作台 5 个标准组件的真实业务数据接口与服务端用户布局持久化。目前布局按用户保存在浏览器本地，适合作为第一阶段交互基线。

### B.5 本地隔离环境与架构产物回填

- 已在 `deploy/docker/` 建立全本地隔离测试栈，包含 PostgreSQL 16、Neo4j 5、MinIO、n8n、Flask 后端和 Vue/Nginx 前端，使用独立网络、命名卷与本地端口。
- 后端配置已移除提交在代码中的生产 n8n 回退地址和 Token；前端 n8n、助手、MinIO 预览和 DataFlow 默认数据源也改为显式环境配置或本地安全默认值。缺少配置时失败关闭，不再静默连接线上环境。
- 2026-07-16 冒烟验证结果：6 个常驻服务均 healthy，MinIO 初始化容器退出码 0；前端、后端健康和 n8n 健康接口均返回 200；PostgreSQL、Neo4j 和 MinIO 数据初始化验证通过。
- 架构产物已补充到 `docs/architecture/`：总览、103 路由 OpenAPI、前端删除清单、数据模型、部署源真相、认证 ADR、工作流引擎 ADR、跨存储一致性 ADR 和下一轮路线图。
- 下一轮待实现项已拆为 5 份逐任务计划：平台契约/一致性基线、RBAC、DataFlow–n8n Workflow 版本、工作台持久化、数据治理知识库。