docs: record observability config ref boundaries

docs/reference/observability.md

@@ -18,6 +18,8 @@ UniDesk 的可观测性优先级高于静默成功。CLI、服务日志、Docker
 
 离线调查遇到 OTel 或 analyze 不好用时，先改进工具再继续业务结论。典型触发包括：OTel 查询缺少目标运行面、service path、business trace 映射、error span 摘要或 `--grep`/`--limit` drill-down；`diagnose-code-agent` 不能区分 observability gap 与业务失败；`observe collect/analyze` 解析失败、输出不可界定、不能按 run/observer/trace/sample 定位、只给 dump 或缺少 root-cause signal；sentinel report 不能把 runner API、SQLite index 和 artifact findings 对齐。工具改进应优先落在 CLI/analyzer/summary/parser 或 instrumentation 的可见性层，并用既有 trace/artifact 做回归验证；若工具改进需要实际部署或新采样，必须先把离线调查结论停在“工具缺口”，再取得明确授权后进入对应运行面流程。
 
+`platform-infra observability` 的 `serviceConnections` 是诊断覆盖图，不是全局 node/lane registry。每条连接只应引用当前 owning YAML 中稳定存在的字段；当目标节点已经不在该 YAML 中声明，或另一个 domain YAML 不暴露同构的 `node/version/runtime.namespace` 结构时，应在 observability YAML 中显式写入该连接的 `targetNode/lane/namespace`，而不是让全局配置解析被无关节点的陈旧 `configRef` 阻塞。`plan --target <node>` 必须能在查询 Tempo 前完成解析；缺 trace 应表现为受控诊断结论，例如 `otel trace not found`，不能退化为 YAML path missing 的异常栈。
+
 ## Zero Implicit Fallback
 
 运行时异常、投影写入异常、序列化异常、ReferenceError/TypeError、不可达上游、provider 不可用、trace 同步失败和状态机非法转移不得被隐式 fallback 吞掉。任何 catch 后继续返回旧值、空值、默认值、legacy 查询、二次来源仲裁或“看起来成功”的行为，都必须改成以下两类之一：