工程基础管理 · 概要设计文档

文档版本：1.10 ｜ 最近核对日期：2026-11-04

勘察、设计、勘察设计及监理服务标段维护合同和工点范围，不生成施工质量验收单位工程；施工类标段继续按工点与专业生成单位工程。规则见需求分析。

业主合资公司层级与类型纠正（2026-10-14）：业主公司 company 下允许合资公司 joint_venture，集团及其他父级规则保持原边界。被业务引用的业主 company/branch 可在组织 ID、上级与业主体系不变时纠正为 joint_venture，仍须通过根保护、下级兼容性、唯一性和权限校验；反向转换、调整上级及跨体系转换不适用此例外。普通编辑与 Excel 覆盖导入共用该规则。共享业主单位选择、保存校验和最近单位解析纳入合资公司；参建单位管理写入规则不变。

企业身份与业务角色分离（2026-10-13）：已有业主企业也可承担项目设计、监理或施工角色，直接复用同一 SYS_DEPT.DEPT_ID，禁止为了让选项出现而另建同名参建企业。项目三类参建字段允许 deptType=1/2 的 company/branch/joint_venture 企业节点，拒绝 group 容器和 dept 部门。候选接口与保存校验使用同一范围，名称兼容解析包含两种体系的企业；同名不能唯一匹配时必须重新按 ID 选择。该范围适用于项目参建主体及全局联合体成员/牵头企业，不扩大其他模块的共享组织校验。

项目参建主体混选现行契约（2026-10-13 修正）

设计、监理、施工字段直接选择已建档企业或全局联合体，允许同一角色同时选择一个联合体及两家独立企业。沿用 ParticipantConsortiumPicker.vue 的企业/联合体选择布局；选择身份为 type + id，企业为 UNIT，联合体为 CONSORTIUM，名称仅作显示。联合体不展开成成员企业，不根据名称逗号推断组成，不以同名企业替代联合体。建设单位仍为业主组织多选，所属公司仍单选。

独立“关联联合体”按钮、弹窗及项目关系 API 下线。全局联合体档案与成员维护继续保留；旧项目联合体表只保留历史记录，不清空、不删除，不再作为项目参建主体现行来源。企业兼任业主及施工等角色时复用同一组织 ID，候选企业允许 deptType=1/2 的 company/branch/joint_venture，排除集团容器、部门及项目部。

三类权威集合为 designParticipants/superviseParticipants/constructParticipants，每项 {type,id,name}；空数组明确解除该角色全部引用。后端按类型验证存在性、启用状态及主体类型，从档案生成名称快照，在项目保存事务中整体替换对应角色的有序引用。前端保留 Long ID 原始值，不转 Number；相同数字 ID 的企业和联合体是不同主体。

旧三类 *UnitIds 仅保留独立选择的 UNIT 项，不含联合体成员；旧名称字段是混合主体名称快照；旧单 *UnitId 仅在集合恰有一个 UNIT 且无联合体时保留，其余置空。建设 buildUnitIds 继续使用业主 CSV 集合。被现行参建集合引用的企业/联合体不得删除；联合体被引用后组成变更受保护，名称调整不得更换主体身份。

验收例：选择联合体 C + 企业 A/B 后保存，重开仍回显三项且 C 未变成成员或企业；删除 A 后仅保留 C/B；全部清空后不残留旧单 ID 或名称；企业与联合体同 ID 时能分别回显；非法 type、失效主体或伪造名称不得绕过后端校验；引用中的主体删除和联合体组成变更应被阻止。

联合体成员企业角色复用与本轮迁移边界

全局联合体正常新增、编辑的成员与牵头单位候选，以及后端成员校验，统一允许业主及参建两体系中启用、未删除的企业：deptType=1/2 且 orgType=company/branch/joint_venture；排除集团容器、部门和项目部。不能因企业当前为业主而重复建档为参建单位。联合体仍须至少两个不同成员，牵头单位须属于成员集合；被项目引用后组成冻结及删除引用保护保持有效。

验收例：微电园施工联合体选择“重庆建工第九建设有限公司”与已有业主“重庆对外建设（集团）有限公司”，应复用两企业原 ID，可正常建档和回显；仅一个成员、牵头不在成员中、停用或部门节点仍拒绝保存。

本轮仅重做设计、监理、施工主体分组，保留当前 111 处建设单位信息，不按老源建设字段数量清空。老平台附件为 100 + 26 共 126 条，三类非空角色字段分别为设计 33、监理 39、施工 39，合计 111 个角色字段。迁移按项目身份和修剪首尾空白的 CODE 核对（其中两个源 CODE 带 CRLF），不按项目名称合并，四组同名项目保持各自独立身份。数量与具体落库结果须由本轮数据库回读验证。

关联需求分析：工程基础需求分析 ｜ 关联数据库设计：数据库设计

架构定位：本设计针对轨道交通全生命周期数字化建设平台，对工程基础层实施**“双核四维解耦架构”**（空间物理资产核 PBS + 商务标段合同核 CBS，通过施工质量验收 WBS 矩阵交汇，依托 OBS 统一企业主数据组织底座）。彻底终结原单棵多层折叠工程树导致的物理资产割裂、机电标段与工点重名冗余、参建单位纯文本游离无关联、权限难以维护等根本痛点。

---

1. 架构定位与解耦蓝图

1.1 总体架构蓝图（四维解耦拓扑）

1.2 四维边界定义

维度	行业属性	覆盖周期	核心业务实体	核心职责
PBS 空间物理线	物理资产资产树	规划 → 施工 → 运营（终身不变）	线路（Line）、工点（Site Master）、部位（Zone）	维护物理真实世界，提供终身不变的空间坐标与全景资产底座，直接支撑 BIM/GIS 与数字移交。
CBS 商务管理线	投资与合同界面	规划前期 → 施工建造（竣工结算后终结）	建设项目（Project）、标段（Bid Section）、合同（Contract）	承载投资批复、招投标采购、参建履约、合同总价与变更金额归集。
WBS 工程施工线	质量验收标准树	现场施工 → 竣工验收（按国标规范归档）	单位工程（Unit Project）、分部工程（Sub Project）	标段与工点交叉生成的法定验收单元；承载工程变更、现场手续、质量抽检、隐患排查、工序报验。
OBS 组织人员线	参建组织体系	动态人员进退场	参建单位（SYS_DEPT）、项目部（Dept）、参建人员（User）	维护业主法人与施工、监理、设计企业主体档案；项目通过完整 ID 集合 + 官方快照关联真实企业，档案先维护再选择，禁止项目自动建档。

1.3 参建单位与企业主数据强关联机制（严格校验建档与已建业主精准映射）

口径修订（2026-10-12）：单位主数据已改为严格校验、禁止自动建档。当业务表单中填写的单位名称在 SYS_DEPT 中不存在时，服务端 getOrCreateDeptByName 直接抛出业务异常“单位【xxx】尚未建档，请先在系统中完成单位建档后再行关联”，不再后台自动补建企业档案。以下原“缺少即建/自动建档”相关描述仅作历史来源追溯，不作为现行实现规则；现行规则为「单位必须先建档，再关联」。

针对历史架构中单位仅存纯文本名称的弊端，本模块确立平台级企业主数据协同机制：

1. 项目完整引用集合：建设/设计/监理/施工四类采用 *_UNIT_IDS 有序 CSV 集合 + *_UNIT 官方快照；旧单 ID 仅单项有值，多项/清空置 NULL。所属公司仍单 ID + 名称快照。其他实体的单项契约不随项目扩展改变；
2. 两家核心业主二级公司精准映射（系统已建，直接复用）：
   • 存量及历史文本中的“重庆市铁路(集团)有限公司”对应系统已建档的重庆交通建设管理有限公司（DEPT_ID=101, PARENT_ID=100）；
   • 存量及历史文本中的“重庆市轨道交通(集团)有限公司”与“重庆市轨道集团有限公司”对应系统已建档的重庆轨道交通运营有限公司（DEPT_ID=2083453529837531162, PARENT_ID=100）；
   • 这两家单位在系统组织树中均已预先创建完备，业务录单与存量迁移时自动精准映射绑定，严禁重复建档；
   • 其它未在组织架构建档的特殊线路运营公司遵循业务指示保留文本描述，ID 设为 NULL；
3. 项目单位选项与企业身份复用：
   • 建设、设计、监理、施工四类通过 OrgUnitSelect 搜索并多选已建档主体；所属公司单选。项目接口禁止自由文本和自动建档。
   • 建设/所属公司选业主单位；参建字段可选两体系的公司、分公司及已有项目公司，不能选集团容器或部门。
   • 同一法人兼任业主与参建角色时直接复用原 DEPT_ID，禁止重复建企业。服务端锁定集合逐项校验后生成官方快照；历史名称仅精确唯一匹配，不是新增入口。

---

2. 标段与工点的“多对多专业交汇”机制

轨道交通建设中，站前（土建）与站后（机电各专业）标段的管辖粒度存在巨大天然差异。新架构通过**“标段管辖模式 + 专业分类生成单位工程”**彻底解决这一痛点。

2.1 标段管辖模式（Coverage Mode）

2.2 矩阵交汇与单位工程自动生成

核心生成法则：单位工程集合 = 标段管辖工点集合 × 标段涵盖专业集合

• 单专业与多专业自适应：
  • 单专业标段（如信号标）：一个站点生成 1 个单位工程；
  • 多专业统包标段（如机电01标包含风水电、装修、支吊架 3 个专业）：在一个站点下清晰生成 3 个对应的专业单位工程；
• 防错与隔离：机电01标的项目部在重庆西站发起变更时，下拉框仅列出其承包的 3 个单位工程，精准归口、权责清晰；
• 全线标一键联动：全线标段（管辖模式为 FULL_LINE）创建时，后台自动遍历全线所有站点，为每个站点自动生成对应专业的单位工程；线路后续新增车站时，系统自动追加补齐。

---

3. 全生命周期业务流转与数据闭环

---

4. 工程数据授权与资源过滤

工程授权由整线授权与受限组合授权构成；授权方式不按组织角色拆分。整线授权动态覆盖该线路的有效工程，受限授权从线路选择有效标段与工点组合。下游按资源类型应用相应范围：标段专属资源要求精确命中同一线路、标段与工点组合；工点共享资源要求整线授权或至少一个当前有效组合覆盖该工点。

4.1 授权规则与数据范围模式

工程数据授权由 BIZ_USER_ENGINEERING_CONFIG、_LINE、_PAIR 表承载：

授权模式 (mode)	适用人员范围	配置方式	服务端过滤与判定
FULL_LINE (整线授权)	任何需负责完整线路范围的人员	“全线授权”页签勾选线路	动态覆盖该线路当前及未来全部有效工程
RESTRICTED (受限组合授权)	任何需负责部分工程范围的人员	“部分工程授权”页签按线路选择标段与工点	仅保留当前有效 (lineId, bidId, siteId) 组合；标段专属资源精确匹配，工点共享资源可投影到组合覆盖的工点

2026-10-14 实现约束：三表配置根、线路模式和标段工点组合共同构成唯一授权来源。受限组合必须由当前有效线路、标段及工点覆盖关系证明；保存时每条线路的候选清单 token 必须与服务端最新候选一致，并以配置 revision 做 CAS。专属资源要求命中同一 (lineId, bidId, siteId) 有效组合；工点共享资源要求同线整线授权或至少一条当前有效组合包含该工点。主数据改变导致组合失效时，同事务清理组合、递增受影响配置版本；查询使用同一有效性语义，不能从另一用户的授权明细借权。

4.2 统一权限码规范清单（三段式 模块:资源:动作）

严格遵循平台硬约束，后端 @SaCheckPermission、数据库 SYS_MENU.PERMS 与前端 v-hasPermi 逐字保持一致：

功能资源	权限码定义	动作与能力说明
线路管理 (Line)	business:line:list / :query	线路列表查询与详情查看
	business:line:add / :edit / :remove	线路新增、修改与删除
工点管理 (SiteMaster)	business:siteMaster:list / :query	工点列表查询、全景查看与坐标查看
	business:siteMaster:add / :edit / :remove	工点主数据新增、编辑、删除（带引用保护）
项目管理 (Project)	business:project:list / :query	建设项目主数据查询与详情
	business:project:add / :edit / :remove	建设项目新增、修改与删除
标段管理 (BidSection)	business:bidSection:list / :query	标段列表、涵盖专业与管辖工点查询
	business:bidSection:add / :edit / :remove	标段新增、修改与删除（触发单位工程联动）
单位工程 (UnitProject)	business:unitProject:list / :query	标段×工点单位工程清单查看与验收状态维护
	business:unitProject:edit / :remove	单位工程微调与删除
分部工程 (SubProject)	business:subProject:list / :query	分部工程国标目录与单位工程分部维护
	business:subProject:add / :edit / :remove	分部工程增删改
专业字典 (MajorDict)	business:majorDict:list / :edit	29 项规范专业分类字典查看与配置维护
数据权限 (DataScope)	business:dataScope:list	用户标段/空间数据权限查询与画像展示
	business:dataScope:edit	极简数据权限保存（标段/工点多选提交；动词取白名单内动作，不新增 save，见 §4.2 末注）

权限码退场与菜单迁移：business:projectNode:*（前后端 7+ 处、菜单 4 行）随工程信息配置页退场，business:projectScope:query/edit（5+ 处、菜单 2 行）替换为 business:dataScope:list 与 business:dataScope:edit；business:siteMaster:*、business:project:* 沿用。逐项处置与菜单迁移动作见详细设计 §4.1.1。

---

5. 前后端信息架构与界面重塑

彻底移除旧页面庞大卡顿的五层工程树控件，重构为**“双工作台 + 轻量级联选择器”**：

5.1 工作台 A：施工与标段履约工作台（面向工程部、总包、监理）

• 导航架构：两级扁平列表：[建设项目] -> [标段卡片]（标明专业类型、总包单位、开工状态）；
• 工作区 Tab：
  • 【管辖工点与单位工程矩阵】：查看本标段管辖的车站与区间，显示各专业单位工程清单与验收状态；
  • 【工程变更台账】：本标段名下的所有变更单与金额累计；
  • 【现场手续与报验】：施工许可、开工报告、工序报验流转；
  • 【安全与质量问题】：本标段范围内的隐患整改闭环。

5.2 工作台 B：车站/工点全景空间工作台（面向指挥部、设计、BIM、运营移交）

• 导航架构：线路沿线站点拓扑轴（重庆西站 → 现代制造区站 → 复盛站...），清晰展示换乘与状态；
• 工作区：点击某车站（如重庆西站）：
  • 工点基础档案：车站类型、出入口数、经纬度、换乘线路、BIM 模型窗口；
  • 多专业施工协同看板：并排展示土建、风水电、信号、供电、装修各标段的单位工程状态与进度；
  • 车站质量与安全台账：该物理空间内所有专业的检查评定；
  • 三权移交与资产清单：直接导出该车站名下所有专业的验收证明与资产台账。

5.3 全局业务单据录入：统一轻量级联选择器

业务表单（工程变更、隐患录入、手续申报）采用标准化 2 步轻量级联：

• 模式 1（按标段录入）：[所属标段 ▾] -> [发生工点 ▾] -> [分部工程 ▾]（选项极少，无需在树中翻找）；
• 模式 2（按工点录入）：[发生工点 ▾] -> [涉及专业标段 ▾] -> [分部工程 ▾]。

---

6. 实施落地与纯净重构规划

实施说明：系统处于未正式上线阶段。经实测核查，下游所有业务表（工程变更、工程手续、质量安全、渣土、运营对接、投资等）当前全部为 0 行，不存在业务单据回填或割裂负担，实施风险收敛于基础主数据的安全迁移。 库内存量 931 条真实工点与 33 条线路主数据通过一次性初始化脚本直接转入新模型；无需运行期双轨并存，下游业务模块外键直接升级。

6.1 存量数据初始化迁移方案（有序执行保障）

0. 行业标准专业字典前置初始化（存量推导核心依赖）：
   • 首先执行 MERGE INTO BIZ_MAJOR_DICT 预置 29 项行业标准专业分类数据；
   • 执行顺序保障：该步骤必须在步骤 4 涵盖专业推导前完成，确保推导 SQL 中 JOIN BIZ_MAJOR_DICT 能够 100% 匹配获取专业名称，杜绝数据落空。
1. 参建单位自动建档与业主/运营单位组织映射（系统已建精准复用）：
   • 经实测核对，存量业主二级公司均已在 SYS_DEPT 中建立完备（铁路集团改制为重庆交通建设管理有限公司，ID:101；轨道交通集团改制为重庆轨道交通运营有限公司，ID:2083453529837531162，均归属集团 PARENT_ID=100）；存量迁移时直接通过映射绑定标准外键，严禁重复建档；其它未建档特殊运营公司保留原文字描述，ID 设为 NULL；
   • 从 BIZ_PROJECT_NODE_INFO 中去重提取 23 家纯乙方参建单位（施工总包/监理/设计），统一挂接至参建单位根节点 2199000000000100013。注意区分根节点自身与新建子单位的属性：根节点自身为 ORG_TYPE='group'、ANCESTORS='0'、PARENT_ID=0；新建子单位取值为 PARENT_ID=2199000000000100013、ANCESTORS='0,2199000000000100013'、ORG_TYPE='company'、DEPT_TYPE='2'；
   • 过滤脏数据（如测试字符串与孤儿节点），利用迁移序列 SEQ_SYS_DEPT_MIGRATE 生成大整数 DEPT_ID，确保后续标段与线路下沉脚本 100% 能够回填有效外键 ID。
2. 线路主数据按物理主线归并分期迁移（根除编码冲突，精确绑定业主/运营外键）：
   • 旧树中 33 个 LINE 节点包含大量同一物理线路的一期/二期/延线（如 15号线出现 4 次、9号线 3 次）。通过建立临时映射表 TMP_LINE_MAP，将存量 33 个节点归并收敛至 23 条真实物理空间线路；
   • LINE_CODE 统一标准化命名（如 L15、L09、L-LOOP 等），彻底消除 UK_BIZ_LINE_CODE 唯一索引碰撞冲突；分期属性聚合存入 LINE_STAGE，总里程累加，并自动关联回填 SYS_DEPT 交通建管(101)与轨道运营(2083453529837531162)外键 ID 与规整名称；
3. 工点主数据保留与线路外键重定向对齐（严禁收窄现有字段）：
   • BIZ_SITE_MASTER 中的 931 条真实工点数据（区间460、车站402、停车场33、主变15、车辆段7、桥梁2、起终点1）保留全部 22 个物理业务字段，就地 ALTER 扩展字段；保留 SITUATION TEXT 等大字段实际物理类型，坚决不作收窄以防截断；
   • 通过 TMP_LINE_MAP 将原属于分期节点的工点 LINE_ID 统一重定向到归并后的主线路 ID（例如重庆西站与全线 82 个站点全部统一挂在 L15 15号线下）；
4. 标段主数据下沉提取（重定向线路 ID，PROJECT_ID 置空避免悬空外键）：
   • 提取原 BIZ_PROJECT_NODE 中 NODE_TYPE='BID' 的 35 个标段，联合 BIZ_PROJECT_NODE_INFO 下沉标段类型、专业大类、合同金额、工期等属性至 BIZ_BID_SECTION；
   • PROJECT_ID 明确置为 NULL（存量建设项目表当前 0 行，避免悬空外键，待后续在立项模块中补录后关联）；通过 TMP_LINE_MAP 精准重定向到归并后的主线路 ID；关联 SYS_DEPT 回填总包与监理单位 ID；
5. 标段专业推导与单位工程多专业展开落库（两分法分类处置，DM8 序列防溢出与国标编码）：
   • 涵盖专业推导 (BIZ_BID_MAJOR)：彻底废除 LATERAL 改用 DM8 标准 CTE 展开；主键采用序列 SEQ_BIZ_BID_MAJOR.NEXTVAL，杜绝雪花 ID 乘法算术导致的 BIGINT 溢出；弱电标按 BID_TYPE 精准映射系统专业；机电复合标默认扩展风水电+建筑装饰双专业（属于存量推断，后续支持业务方在界面上灵活核对维护）；
   • 427 个标段下节点多专业全量展开：通过 n.SITE_MASTER_ID = s.SITE_MASTER_ID 关联，不仅落库主专业，且标段涵盖的协同专业（如机电标的风水电+装饰装修）全部在工点下展开生成单位工程实体；采用独立序列 SEQ_BIZ_UNIT_PROJECT START WITH 3000000000000000001 生成唯一主键，杜绝复用旧节点 ID 导致的主键碰撞；编码采用国标规范 {线路}-{标段}-{工点}-{专业}（如 L15-CQ15TJ01-15-01-CIV-ARCH），继承工程状态；
   • 434 个规划线下节点：在 PBS 空间资产维度已由 BIZ_SITE_MASTER 完整收录，不强行作为无标段孤儿写入单位工程，待后续创建标段时正向关联。

6.2 废弃旧表清单（共 10 张表彻底退场）

以下与旧工程树、树数据权限相关的 10 张真实存在的旧表在迁移完成后安全清理：

1. BIZ_PROJECT_NODE（旧多层工程树主表）
2. BIZ_PROJECT_NODE_INFO（旧工程节点扩展信息表）
3. BIZ_USER_PROJECT_SCOPE（旧工程树数据权限表）
4. BIZ_PROJECT_SCOPE_TEMPLATE（旧范围模板表）
5. BIZ_PROJECT_SCOPE_TEMPLATE_ITEM（旧范围模板明细表）
6. BIZ_PROJECT_SCOPE_TEMPLATE_USER（旧范围模板人员关联表）
7. BIZ_PROJECT_ENGINEERING_SCOPE（旧项目-工程树范围关联表）
8. BIZ_PROJECT_USER_SCOPE（旧项目用户关联表）
9. BIZ_BID_COVERAGE_RULE（旧标段覆盖规则表）
10. BIZ_BID_COVERAGE_EXCLUSION（旧标段覆盖排除表）

6.3 下游业务模块外键对接清单

所有下游模块直接对接全新标准外键，彻底消除模糊的 project_node_id / *_node_id。逐表清单（真实表名、现存列、改造动作、不改造范围、执行顺序）以数据库设计 §7.5 为准，本节只给模块级概览。2026-10-10 按真实库列名核对后修正——原表把 8 个模块的现存字段写错 7 处、漏列约 10 张表：

业务模块	真实现存关联列	改造方向
工程变更	BIZ_ENGINEERING_CHANGE.PROJECT_NODE_ID	增 BID_ID+SITE_ID+UNIT_PROJECT_ID+LINE_ID，删 PROJECT_NODE_ID
工程手续	主表 LINE_ID；明细表 BIZ_ENGINEERING_PROCEDURE_UNIT/PROGRESS/RESULT/STAGE_UNIT 的 UNIT_NODE_ID	明细增 UNIT_PROJECT_ID+SITE_ID，删 UNIT_NODE_ID
质量报验	BIZ_QUALITY_RECORD 已有 LINE_ID+BID_ID+SITE_ID	增 UNIT_PROJECT_ID；三维外键已具备，仅语义对齐
招投标	BIZ_BIDDING_TENDER_DOCUMENT/SUBORDINATE_TENDER/PROJECT_APPROVAL/EVALUATION/FILE_REVIEW/ACTIVITY_LOG 的 PROJECT_NODE_ID（6 张）	增 PROJECT_ID+BID_ID，删 PROJECT_NODE_ID
运营对接	BIZ_OPERATION_DOCK_TRANSFER/PROBLEM.LINE_ID（指向旧树）	LINE_ID 语义对齐 BIZ_LINE，增 SITE_ID
建筑垃圾	BIZ_CZW_SLAG_LEDGER.LINE_NODE_ID/BID_NODE_ID	增 LINE_ID+BID_ID+SITE_ID，删 *_NODE_ID
工程投资	BIZ_INVEST_PLAN_ITEM.LINE_ID+PROJECT_ID	语义对齐，无需加列
安质环（SQE 七张表）	实测无任何 line/bid/site/node 列	不改造；该域现行定性为“有意不过滤”，如需隔离属新建维度，另行立项
联合体（五张表）	走 SYS_DEPT 与项目关联	全局档案保留；项目独立关联退场，改为角色主体混选

模块计数口径：含工程树引用、需改造的是上表前 8 行（工程变更、手续、质量、招投标、运营对接、建渣、投资、BIM）；安质环不改造。原文档“下游 7 个模块”的表述已按此修正为“8 个需改造模块 + 安质环不改造”。

---

6.4 范围与决策说明

1. 权限码退场与菜单迁移：本方案新建 7 个页面、废弃现有 4 个页面；business:projectNode:* 随工程信息配置页退场，business:projectScope:* 替换为 business:dataScope:*，business:siteMaster:* 与 business:project:* 沿用。逐项处置与菜单迁移动作见详细设计 §4.1.1。
2. 菜单结构调整：本方案调整菜单结构（新建 6 个业务菜单 + 1 个权限抽屉），与 2026-09-29“本轮不调整菜单结构”的旧决定相反。该旧决定原记录于已废弃的易用性方案稿（2026-10-10 随方案稿删除），本方案按 2026-10-10 新架构决定执行；如需保留现有菜单结构，§5 的界面规划需重做，属方案级变更。
   • 联合体档案与成员维护保留；项目参建主体按角色直接混选企业/联合体，独立项目关联入口及 API 退场，旧项目关系表仅保留历史。
3. 安质环不接入过滤：BIZ_SQE_* 七张表实测无工程维度列，且业务地图 · 权限模型现行定性为“有意不过滤”；本方案不为其新增过滤，如需按标段/工点隔离属新建维度，另行立项。
4. 待核对项：9号线一期新桥段、15号线东延、15号线西延、国博线、江跳线二期五个分期节点在 BIZ_SITE_MASTER 中无任何工点记录（含软删，2026-10-10 实测）。归并后会生成“国博线”“江跳线”等零工点线路，需业务确认是数据本即如此，还是工点尚未录全。

7. 变更记录

版本	日期	变更内容	变更原因	确认人
v1.0	2026-10-10	完成全新双核四维架构下的概要设计初稿	彻底替代旧折叠工程树设计	AI Pair Designer
v1.1	2026-10-10	规范统一权限码为 business:<资源>:<动作>；明确双轨数据权限模型与三段式权限控制；补充国标 GB 50299 WBS 矩阵交汇定义	对齐平台权限设计硬约束	AI Pair Designer / 用户审核中
v1.2	2026-10-10	架构引入 OBS 企业组织底座强关联；确定参建与业主单位缺少即自动建档策略；规划 UnitSelect 统一组件与时序	解决参建单位与业主单位纯文本游离无主数据问题	AI Pair Designer / 用户审核中
v1.3	2026-10-10	明确下游 7 个业务模块数据表全部为 0 行的前提事实；规划物理主线归并迁移方案（33线路收敛为23主线）；明确 427 标段节点落库与 434 规划节点空间保留分类处理机制	规避线路编码唯一索引冲突，确保平滑重构	AI Pair Designer / 用户审核中
v1.4	2026-10-10	细化 OBS 组织架构规范挂接（参建单位统一挂 2199000000000100013，业主挂 100）；落实标段涵盖的多专业在工点下全量展开生成单位工程规范；主键采用独立序列 SEQ_BIZ_UNIT_PROJECT 生成，杜绝 ID 碰撞	响应多专业标段法定验收实体展开需求与组织树统一挂接规范	AI Pair Designer / 用户审核中
v1.5	2026-10-10	明确专业分类字典前置初始化保障机制（在存量涵盖专业推导前完成）；修正轨道交通/铁路集团 3 家企业为业主分类（挂接100）；确立既有大字段（SITUATION TEXT）严禁反向收窄原则	响应最后把关审核意见，确保脚本执行顺序与数据完整性	AI Pair Designer / 用户审核中
v1.6	2026-10-10	补充业主建设单位与运营单位组织架构已建事实与改制映射规则（重庆市铁路集团对应已建的重庆交通建管 ID:101；轨道交通集团对应已建的重庆轨道运营 ID:2083453529837531162）；线路清洗脚本实现精准映射绑定	响应业务方关于改制更名与已建单位直接复用的明确指示	AI Pair Designer / 用户审核中
v1.7	2026-10-10	按真实库列名修正 §6.3 下游外键清单（原表 8 个模块写错 7 处、漏列约 10 张表；安质环改列为不改造、联合体列明保留）；§6.1 澄清参建单位根节点自身与新建子单位的属性区别；§4.2 补权限码退场与菜单迁移说明；新增 §6.4“范围与决策说明”（菜单结构调整、联合体保留、安质环不接入过滤、零工点线路待核对）；专业字典口径统一为 25 项	承接 2026-10-10 开发库回读与代码核对结论，修正方案与真实结构的不一致，使方案可直接实施	待用户确认
v1.8	2026-10-11	扩充 §4.1 与 §6.1 专业分类字典项数为 29 项，支持土建综合（CIV-INTE）、大机电系统综合（MEP-TOTAL）、弱电系统集成综合（SYS-INTE）、供电系统综合（POW-INTE）4 项综合专业，从源头收敛工点多专业笛卡尔积展开导致的单位工程膨胀	响应用户业务指示，支撑土建总包、站后大机电系统总包等统包标段模式	已确认

项目候选权限与存量分组计划补充

项目角色只凭项目 query/add/edit 任一权限读取项目专用企业/联合体候选，不要求单位或联合体管理菜单权限；项目查询直接返回联合体牵头/成员名称的只读投影，详情不另外请求联合体档案。此投影仅服务项目选择和详情，不能借项目权限修改联合体档案。

2026-10-14 开发库已按源数据分组完成迁移：126 个项目 × 3 角色 = 378 个角色范围，其中 111 个非空角色字段，实际保存 175 项混合主体（127 UNIT + 48 CONSORTIUM），新增 22 个联合体及 70 条成员关系；回读共 49 个有效联合体、145 条成员关系。用户已确认其中 19 种原资料未明确牵头的组合暂按原首成员登记，备注保留牵头待核对，不解释为已确认实际牵头。实际写入、页面回归与组织身份纠正见最新测试报告。

企业现名、组织层级与项目角色核对（2026-10-14）

• 原“重庆城市综合交通枢纽（集团）有限公司”复用现“重庆交通资源开发有限公司”既存企业档案及 ID，不另建同一主体。资源公司官网说明其以原枢纽集团为主体改组，于 2025 年 4 月 29 日揭牌；官方公司简介为现名来源。

• “重庆通远城市建设发展有限公司”按资源公司体系下级企业维护为 company，不挂集团根作为一级直属公司。资源公司官网 2024 年新闻将其称为原枢纽集团通远公司，支持该组织层级判断；尚未取得足以核实全资/控股比例的资料，不能仅因一级组织图未列而标为合资。此归属依据 2024 年官网历史枢纽/资源体系维护，2026 年当前股权及存续沿革仍待核对；官网所属企业页未列通远，也不能据此推断其更名或注销。官方项目新闻、集团调研新闻。

• “重庆市渝西快线建设运营有限公司”维护为 joint_venture 参股项目企业，组织归属挂交通建设管理公司原铁路体系，不作为集团一级直属公司。2023 年招股说明书披露城建设计 30.60%、铜梁金龙 24.50%、重庆绿发 24.50%、原铁路集团 15.30%、北京城建集团 5.10%；上述比例仅为 2023 年披露时点，不能当作当前股权百分比。铜梁区交通局 2025 年答复明确其是璧铜线 PPP 项目业主。

• “重庆江跳线轨道交通运营管理有限公司”复用既存企业 ID 2109011604266926081，类型修正为 joint_venture 合营/参股企业，不新建、不与“重庆轨道江跳线建设运营有限公司”或江跳二期主体合并。原铁路官网披露设立时原铁路集团 50%、中铁建重庆投资 30%、中铁十六局 20%；市国资委 2024 年招聘公告明确其为原铁路集团参股公司，集团 2025 年度财务附注仍按合营企业列示。该性质不表示集团实际控股；2025 年重组后直接归属尚待核对，本轮暂保留集团下参股节点父级 100，不将其解释为集团一级直属公司，也不推定挂交通建设或轨道运营公司。历史设立比例不代替最新股权确认。

组织归属表达企业主数据的真实层级，建设单位表达项目参与角色，两者独立；不能因为项目建设字段引用某企业就将它放入集团直属公司，也不能因组织分类调整清空合法建设引用。同一主体更名复用稳定 ID，按真实层级和节点类型维护，不重复建档。

实施核对：2026-10-14 已将原枢纽重复档案的 13 个项目建设引用精确迁移到资源公司既存 ID，保留多选中的其他企业及项目所属公司；通远挂资源公司下级、渝西归交通建设管理公司参股项目企业。126 个有效项目及 111 个有建设单位项目保持不变，分类纠正不清空建设角色。验收例子：公共运输职业学院扩建项目（二期）的建设单位仍为学院与资源公司两项；渝西快线项目继续引用同一渝西企业 ID。通远当前股权、存续沿革待核对，不依据组织归属推断持股比例。

合同标段跨项目关联（2026-10-14 当前业务规则）

一个合同标段可关联多个建设项目，始终保持同一 BID_ID、合同金额、管辖工点及单位工程，不复制标段，不强制指定主项目。标段所属项目选择多项；以任一关联项目筛选均能查到同一标段。关联集合为空表示归属待核对，不能编造所属项目。合同编码在共同所属项目内唯一；同编码且关联集合相交时拒绝保存，无项目关联时，同一线路内未关联项目的标段编码唯一，锁线路行防止并发重号。

项目关联与物理分期是两个维度：工点属于哪条分期线路由空间主数据决定，合同标段覆盖哪些项目由合同项目关系决定，不能为匹配单项目而改写工点分期。合同金额只记一次，跨项目汇总按 BID_ID 去重，不能在各项目重复累计全额；没有分摊基线时不自造项目分摊金额。本次不引入新金额分摊字段。429 项单位工程仍各自引用唯一 BID_ID，原标段/工点/线路授权机制不因多项目关系扩权。

项目删除须检查标段项目关系，仍被标段引用时禁止删除。更新关联在同一事务内校验全部项目并整体替换；重复 ID 拒绝保存；并发编码校验锁定当前及提交项目的并集，按 ID 升序锁定。关联变更不能更换合同身份或重建单位工程。

验收例：同一系统合同关联 15 号线一期与二期，两边筛选均返回同一标段；编辑后重新打开显示两项目；清空后显示待核对且旧单项目不残留；共同项目内相同编码拒绝；合计合同金额按标段计一次；项目删除引用保护有效；429 单位工程的 BID_ID 及原授权不变。

15号线公开资料补证与迁移结果（2026-10-14）

两份老平台 JSON 直接给出部分土建合同期别，公开建设和审批资料补齐其余范围。本轮31个现存标段均已建立真实项目关系：一期单项目12个、二期单项目11个、两期共同8个，共39条关系；不再采用前述13+8+10待核对的初步计划。合同明确期别优先于单个工点物理位置，现管辖范围为单一期别的机电子标按所服务范围归集。未给工点主数据另写推断项目ID，也未因车站改名修改历史工点名称。原资料有一期土建11标、现台账无此标，本轮不凭图描述新建合同。具体标段和官方来源见数据库设计本轮迁移章节。

保存标段项目关系时沿用项目只能解析到一条物理线路的既有约束：所选项目已有关联其他线路的有效标段时拒绝保存；项目改选不会自动扩大原BID/SITE/LINE授权。并发锁为标段行（编辑时）、全部当前及提交项目按ID升序；未关联项目的编码按同线路校验并锁线路行。项目选项接口 /business/project/options 真实返回 projectId/projectName，前端显式映射为下拉组件 value/label，不把空白选项当作无项目。