City-Lifeline-Cockpit/.scratch/cockpit-real-data-wayfinding/implementation/t31/status-and-verification.md

设施总数一致性：实施与验收状态

关联：后端执行票 —— 设施总数三处口径不一致（5278 / 5276 / 5273）。

诊断与业务裁定

只读 GET 直接复现 5278 / 5276 / 5273；断言探针见 三端点设施一致性探针。根因是设施表集合不同，不是共同管网的求和算法：

来源	纳入设施	现场旧总数
基础档案	管网5268、水厂3、供水泵站5、排水工程设施2	5278
总体概览	管网5268、水厂3、供水泵站5	5276
管理信息	管网5268、水源地2、窨井3	5273

用户已裁定统一为上述合法设施并集，由基础档案设施目录作为权威来源。静态数据不变时预计新总数5283：燃气537、供水1006、排水3737、窨井3。该数值尚未由新代码真实运行确认，不作为硬编码或永久断言。

实施契约

• 统一六类设施来源表读取和类型字典：管网、水厂、共用泵站、排水工程设施、水源地、窨井。逻辑删除由现有业务 service 的 ORM 查询规则处理。
• 总体概览和管理信息注入同一设施目录，只投影其记录，不再选自己的设施表集合。
• 无可信类型或无业务编码的来源行不会静默丢失：保留内部未分类哨兵，基础档案/概览计入 excluded.unknownTypeCount，管理信息计入 excluded.unknownIndustryCount。这些现有字段表示无法进入正式类型/行业的记录，缺编码也属于无法进入正式集合的行；响应不暴露内部哨兵编码。
• 设施没有权威 district，一律未分区；坐标是否可上图不影响计数。监测设备仍独立统计。
• 同码但不同类型/不同来源记录不能被关系去重合并；管理信息内部投影采用目录行身份。
• 未来建设/投运日期在未加年龄过滤时计入设施总数和片区分布，excluded.futureDateCount 是年龄异常提示，并不代表从全局总数排除；年龄筛选时仍依现有规则排除未来日期。
• 设施来源 updatedAt 取台账真实创建/更新时间最大值，不把请求时间当数据更新时间；工程设施 createTime 不冒充建设日期，未知建设日期为 UNKNOWN。
• 本票统一统计定义和来源，不新增跨 HTTP 请求缓存或数据库快照 token；跨端点实时 GET 比较要求业务数据稳定。回归测试固定同一数据和时钟。

验证事实

• 已运行只读探针，精确断言三个 totals.facilityCount 相等，旧服务以 Facility count mismatch across three endpoints 失败，输出为5278/5276/5273。
• 新契约回归贯通真实目录、真实适配器和三服务，覆盖全部合法来源、行业合计、片区合计、未来日期、未知类型、缺编码、同码不同设施和空集。
• 既有三适配器单元测试及五端点管网回归已更新到统一来源入口。
• 用户授权后，从 pipe-network-service reactor 执行 mvn test '-Dtest=Cockpit*Test' -DfailIfNoTests=false -q：469 tests, 0 failures, 0 errors, 0 skipped，包括新增跨端点契约 2/2。以 zksy-admin 子目录单独执行时命中本地旧依赖 JAR 而失败；从完整 reactor 构建通过，非代码缺陷。
• 后端开始基点为 7fb7c2c；并行提交 60a0e9a、33ca0b6 未触及本票修改文件。
• 当前服务 http://192.168.110.96:8301 仍运行旧代码；尚未重载，因此新代码的线上 GET、面板一致性未验收。未运行浏览器测试。
• 已执行双轴静态审查并处理发现：采用来源表+主键稳定身份，保留既有排水工程设施年限与概览长度精度契约，清除未用 Clock 依赖。

下一步

提交本票后，由维护者重载现有8301实例；再运行只读探针核对三端点总数、行业/片区合计并确认基础设施面板，符合后关闭票据并在 map Decisions so far 追加一行。预期5283只作为本轮当前数据的估算，实际以重新加载后的 GET 结果为准。