49-49-operating-information-pointcodes.md 2.7 KB
49: 后端契约诊断 —— operating-information 的 pointCodes 返回设施编码，运行信息定位永远不可达
Category: backend-contract
来源
票 38（基础设施面板调整）真实浏览器走查暴露的新事实（2026-10-15，real 后端 192.168.110.96:8301）。
现象
基础设施 → 运行信息 → 点任一「定位 TCRQ…」按钮，前端如实弹出 「TCRQ202609080002 · 该点位不在已加载的一张图范围内」（票 38 的 MISSING 反馈，行为正确）。 但每一个定位按钮都是 MISSING —— 不是偶发数据缺失，而是编码空间不重叠：
/infrastructure/operating-information的metrics[].pointCodes实测返回 设施编码（TCRQ…太常燃气、CNRQ…城南燃气，即facility序列的编码）；/map-snapshot的对象序列只有监测点（GS001/WS…等）与未关联设备（deviceCode）；- 前端定位链路按编码回联已加载地图对象（
domain/mapLocate.js的planLocate）， 两个编码空间无交集 ⇒ 运行信息面板的定位在真实数据下结构性不可达。
待裁定（诊断，不是直接改）
- 契约语义：
pointCodes本应引用「可上图的监测点」（字段名与 CONTEXT.md 的「监测点」术语都指向此）， 还是后端有意用设施编码表达「该指标挂在哪些设施上」？ - 若语义应为监测点：根因是取数链路把 facility 编码写进了 pointCodes，还是设施本就无点位可回联？
（对照：应急保障的
pointCodes实测指向快照里存在的设备/点位编码，链路可用。） - 若语义就是设施编码：契约应改名（如
facilityCodes），且前端该面板应撤下定位按钮 而不是留一排永远 MISSING 的入口——「如实报原因」是兜底，不是把不可达做成常态。
验收
- 给出裁定与证据（真实端点逐行业取样：
pointCodes值集 ∩map-snapshot编码集）。 - 若改后端：契约测试锁定「运行信息 pointCodes 必须能在 map-snapshot 里找到对象」。
- 若改前端：另立前端票撤按钮/改文案，本票只出结论。
关联
- 上游：38（走查发现，前端反馈链路已在该票修好）。
- 相关：票 07（坐标准入）、票 24（设施与管线几何是另一条图层链路，不进 map-snapshot 对象序列）。
进度
Status: ready-for-agent Type: task Blocked by: Labels: backend-contract, wayfinder:task