主题
前期管理 · 概要设计文档
文档版本：1.00 ｜ 最近核对日期：2026-11-10
本版落实用户确认的四类台账、具体单位工程归属、施工维护/监理审核、逐关计划实际、卡点互通和空间复核。业务规则唯一正文见需求分析，已关闭D01–D09，不再沿用旧建议。以下均为待实施设计，本轮不代表代码、数据库及环境已交付。
1. 模块边界
| 能力 | 前期管理 | 其他模块 |
|---|---|---|
| 四类台账 | 施工填写、初始及关键变更送审、生效版与历史 | 工程基础提供真实单位工程和组织关系 |
| 逐关进度 | 四/五关计划和实际、严格前置、单条滞后 | Warm-Flow提供任务及审核历史，不将每个业务关口复制为固定审批节点 |
| 手续 | 多份辅助附件、各自有效截止日、缺证/临期/过期红提示 | 文件服务管理实体；本期不依赖工程手续证照接口 |
| 卡点 | 施工原报、监理修订、已审来源内容 | 进度问题库接收及保留关联，建设单位在那里督办上报，不被前期覆盖 |
| 空间 | 施工采集面/点、送审预览、监理复核 | GIS正式要素、绑定、业务图层及显隐 |
| 指标 | 保留可追溯正式事实、面积交地率定义 | 独立总览、统计分析和指标看板后续专项 |
四类为征地/管线/交通/绿化，空间依次面/点/点/点；涉军涉铁本期不做。卡点不再仅从进度只读；手续不扩成证照系统；GIS不再止于绑定ID。这些是用户明确回复导致的范围修正。
2. 架构与数据流
前端目标位于digital-construction-ui的src/views/business/preliminary/及src/api/business/preliminary/；后端在digital-construction-business的com.bokun.business.preliminary下分层，不新造动态表单或万能台账引擎。
四类身份共用稳定对象ID，所有影响审核的业务内容用强类型关系快照保存。初始对象没有正式版时仍可在授权台账查草稿/待审，但不输出虚构已完成事实。修改阶段计划、工程量或手续/空间资料都走同一类目申请体系，不开直写正式表的捷径。
3. 十四表与版本语义
数据库设计定义OBJECT、REVISION、CHANGE，四个分类扩展，阶段、植物、附件、手续、卡点、空间候选、疑似重复明细共十四表。
- OBJECT保存稳定业务身份、unitProjectId及currentRevisionId。
- CHANGE关联原正式版、施工提交版和当前审核工作版，保存真实平台流程状态及实例。
- REVISION及强类型子表保存一套可审核内容。施工提交冻结；监理只在工作版修订明确授权的卡点；同意后工作版冻结成为正式版，旧版保留；退回前冻结本轮审核稿为REVIEWED，关联该轮施工提交，再给施工新工作副本，监理修订不被覆盖。
- 每个版本包含完整关口计划/实际，未完成实际可空，禁止累计目标或IMPLIED日期补齐。正式完成步数从当前版阶段事实派生，不作为任意可写状态。
- 手续只登记文件说明及期限；卡点只保留来源申报快照，不维护第二套督办状态；空间候选只承担审核证据，正式地图事实由GIS管理。
采用关系快照是新增/关键资料都要审核及保留原报的直接需要，不是并发版本控制。字段不塞JSON/EAV，除空间WKT等专门几何表达外不以文本存整份业务对象；不新增锁或通用重试队列。
4. 单位工程与资格
用户已确认沿用现有授权。unitProjectId必填，后端读取UnitProject反取lineId/bidId/siteId/majorCode，复用assertPairVisible和同源查询过滤。同一组合下多个专业单位工程沿同范围可见，不增加独立unitID授权表或major授权维度。
施工/监理候选从UnitProject→BidSection.constructUnitId/superviseUnitId→有效所属用户解析，并检查工程范围及相应角色/岗位。字段已存在不等于实际配置正确，实施时核对环境。提交人选择合格监理，不能任意选人；监理卡点修改和审核同时受本人任务、节点和范围控制。其他已提交字段默认只读，错误退回施工改。
5. 流程设计
建议四类各一条固定表单流程，申请人→监理审核→结束；初始与后续同类申请复用定义，编码为preliminary_land_change、preliminary_utility_change、preliminary_traffic_change、preliminary_greening_change。流程业务ID使用changeId，不能用objectId混淆多次申请。四关/五关在业务表单逐项管理，不写成只能走一遍的引擎节点链。
平台状态沿draft/waiting/back/finish等实际枚举。back返回原申请人，同change/instance重提并保留历史；finish才切正式版。监理同意前校验疑似重复确认、逐关前置及应有实际时间，缺手续仅警告不阻断。
| 操作 | 必须保证 |
|---|---|
| 保存草稿 | 真实单位工程和对象名称必填；其余资料可未齐，已填值及引用须合法；父子归属完整，不改正式版、不启动流程 |
| 提交/重提 | 资格、范围、顺序、日期及查重重新校验，施工提交版冻结 |
| 监理保存卡点 | 保留原报、保存修订记录，不直接发布或修改其他字段 |
| 同意 | 业务版切换、必要GIS发布/绑定、卡点接收及流程结果一致 |
| 退回/失败 | 原正式版本和原图形/问题办理不被错误覆盖 |
参考工程手续同步事件和当前任务内可编辑机制，不能照搬其全部阶段完成或返工重置逻辑。必须用故障测试证明事务边界；同源同步接入可优先一事务，异源不能承诺注解自动回滚外部系统，应先确定已存在的可靠发布接入，不先搭新补偿平台。
6. 页面与复用
四类入口与隐藏办理页使用以下完整路径，不省略共同前缀：
| 类别 | 台账路由 | 固定办理路由 |
|---|---|---|
| 征地拆迁 | /preliminary/landAcquisition | /preliminary/landAcquisition/flowForm |
| 管线迁改 | /preliminary/utilityRelocation | /preliminary/utilityRelocation/flowForm |
| 交通导改 | /preliminary/trafficDiversion | /preliminary/trafficDiversion/flowForm |
| 绿化移植 | /preliminary/greeningTransplant | /preliminary/greeningTransplant/flowForm |
普通菜单父级核对现平台，办理名称、分类、隐藏菜单和固定注册遵循平台规范，流程FORM_PATH与对应完整办理路由逐字一致。
首期以台账、详情和审核为主，关口矩阵在详情/表单展示，不建批次、行政区、五关等独立聚合图表页签。页面内含手续、卡点、植物及空间分区，警告在本功能展示；地图可切四类业务图层显示，显隐不改变权限和审核。
复用ProjectBidSiteCascader的unit模式/完整path、UserSelect、OrgUnitSelect、FileUpload及流程头卡/动作/时间线；以实际组件支持核实为准。监理卡点可编辑参考工程手续工作台，不能把勘察只读详情直接当可编辑样本。文件移除只改业务引用，取消不能删原实体。
7. 必要集成与当前缺口
| 集成 | 现有事实 | 本次目标 |
|---|---|---|
| 单位工程/组织 | UnitProject有归属，BidSection有施工/监理单位字段 | 实际配置核验，统一资格和工程范围 |
| 进度问题库 | 未发现可直接使用的通用服务 | 明确已审来源字段接收/更新及关联查询，保留建设单位督办上报字段，不扩整个进度模块 |
| 手续 | 无需依赖当前未有的有效期API | 在前期维护辅助附件及期限，审核后生效 |
| GIS | 已有要素属性/绑定和图层显隐；几何编辑未开放，白名单仅PROJECT/SITE/BID | 补点/面采集预览、审核发布、PRELIMINARY_OBJECT目标和受权图层，保留既有语义 |
卡点问题库及GIS几何接入是必须实施验证的能力，不是已完成前提。独立主链可先做，但不得以mock、假零或“填了ID”宣布整体完成。
8. 交付顺序与证据
先核实真实单位工程/组织/流程/表结构，以管线“初始计划→监理→下一关→监理”纵向贯通，随后征地、交通、绿化；然后导入、卡点问题接收及空间复核发布。非阻塞细节按既有规则自主补齐，不重问已答12项。
必要验证覆盖待审隔离、施工原报/监理修订留痕、逐关计划实际、完全/部分重复、缺证可推进、期限边界、unit授权、GIS点面和显隐及问题库不覆盖督办。本轮实际仅文档，测试证据见测试与验收，目标操作见操作手册，接口见详细设计。