<!-- DSH-IDEMPOTENCY-KEY: t49-pointcodes-facility-codes -->
<!-- parentKey: 00 -->
# 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`），
  两个编码空间无交集 ⇒ 运行信息面板的定位在真实数据下**结构性不可达**。

## 待裁定（诊断，不是直接改）

1. 契约语义：`pointCodes` 本应引用「可上图的监测点」（字段名与 CONTEXT.md 的「监测点」术语都指向此），
   还是后端有意用设施编码表达「该指标挂在哪些设施上」？
2. 若语义应为监测点：根因是取数链路把 facility 编码写进了 pointCodes，还是设施本就无点位可回联？
   （对照：应急保障的 `pointCodes` 实测指向快照里存在的设备/点位编码，链路可用。）
3. 若语义就是设施编码：契约应改名（如 `facilityCodes`），且前端该面板应**撤下定位按钮**
   而不是留一排永远 MISSING 的入口——「如实报原因」是兜底，不是把不可达做成常态。

## 验收

- 给出裁定与证据（真实端点逐行业取样：`pointCodes` 值集 ∩ `map-snapshot` 编码集）。
- 若改后端：契约测试锁定「运行信息 pointCodes 必须能在 map-snapshot 里找到对象」。
- 若改前端：另立前端票撤按钮/改文案，本票只出结论。

## 关联

- 上游：[38](38-infrastructure-panel-adjustments.md)（走查发现，前端反馈链路已在该票修好）。
- 相关：票 07（坐标准入）、票 24（设施与管线几何是**另一条**图层链路，不进 map-snapshot 对象序列）。

## 进度

<!-- 做到哪一步了，在这里一行一行记 -->

Status: ready-for-agent
Type: task
Blocked by:
Labels: backend-contract, wayfinder:task

## Comments


## Answer