RuView v0.9.3 多厂商 RF 传感集成：Vendor Providers Beta 1 的能力契约与 fail-closed Rust 实现解读

本指南围绕 RuView 的 v0.9.3 发布（Vendor Providers Beta 1）展开，该版本基于 ADR-270 落地了一套能力安全的 Rust 多厂商 RF 传感提供方程序，覆盖十家被调研厂商。读完本文，你将理解 RuView 如何在"不许把 RSSI、云占位或网络清单冒充成 CSI"的边界下，用统一的 VendorRfProvider 契约 + 确定性模拟器 vendor-rf-sim + Sensing Server 的 REST/WebSocket/UDP 接入面，把 Origin AI、Plume/OpenSync、Mist/Juniper、NETGEAR、Electric Imp、RF Solutions、Luma、Google Nest 等厂商的异构传感面安全地并入同一套事件管线，并能独立复现构建、模拟与接入验证流程。

一、为什么需要一套"厂商提供方"程序

RuView 的核心技术路线是把普通 WiFi 信号变成空间感知（占位检测、姿态、生命体征）。但现实中不同的路由器/云服务厂商提供的是完全不同的感知表面：有的能给出逐包的校准复信道矩阵（complex CSI），有的只给出厂商自己计算的运动/占位事件，有的只暴露 RSSI 与客户端/拓扑遥测，还有的根本不存在可合法集成的开发者接口。v0.9.3 之前，仓库已经在 v0.9.0/v0.9.1/v0.9.2 三个 beta 中分别落地了 Realtek、MediaTek、Qualcomm 的 CSI 接入（对应 docs/releases 下的发布说明），而 v0.9.3 要回答的是：当厂商来源不是一块 CSI 网卡时，如何在不作伪的前提下把它们接进来。

ADR-270 给出的答案是：一套 Rust-first 的厂商提供方组合，配以显式的能力协商（capability negotiation）。核心约束是把"品牌能连通""Linux 能驱动""合成 fixture 能跑通"与"真正的 CSI 能力"严格区分开，任何流程都不得把前三种东西包装成虚假的 CSI 主张。

从代码结构看，实现被拆成了两个 crate：契约与模拟器位于 wifi-densepose-hardware，注册表与各厂商解码适配器位于 wifi-densepose-sensing-server（库模块 vendor_rf.rs、vendor_origin_plume.rs、vendor_mist_netgear.rs、vendor_remaining.rs）。

二、五种能力分类与逐厂商决策

ADR-270 定义了五级能力分类，v0.9.3 的所有 ProviderDescriptor 都落在这一模型上：

能力	含义
ComplexCsi	校准的逐包复信道矩阵（当前由真实 CSI 硬件路径提供）
DerivedSensing	厂商产出的运动、占位或位置事件
RfTelemetry	RSSI、射频、客户端与拓扑观测
NetworkOnly	仅作为流量/AP 基础设施，不是传感器
Unsupported	没有稳定、合法或可支撑的集成表面

契约模型在 vendor_rf.rs 中被 RfCapability 枚举逐一编码，并附带 ProviderAvailability（Available / CredentialsRequired / ContractRequired / Experimental / Unsupported）。逐厂商的决策矩阵如下：

厂商	分类（能力）	决策
Origin AI	商业 DerivedSensing（可能含 CSI）	通过 NDA 沙箱/API 与原始数据权推进；专有引擎隔离在 provider trait/service 边界之后
Plume/OpenSync	RfTelemetry（Plume Sense 单独门控为 DerivedSensing）	构建只读 OVSDB/控制面适配器；不得从遥测推断原始 CSI
Mist/Juniper	RfTelemetry + 位置	条件性只读 REST/webhook 适配器，承载占位、RSSI 与坐标，不作 CSI 主张
NETGEAR	伙伴门控 RfTelemetry	仅在获得 API 权限后接入 Insight；旧款 OpenWrt 机型仅作为社区实验
Luma	已停产的 OpenWrt 救援目标	仅在已持有时提供通用 OpenWrt 遥测/pcap fixture；不采购、无 Luma CSI 来源
Google Nest Wifi	NetworkOnly	作为流量/AP 基础设施；Device Access 不暴露路由器 CSI 或射频遥测
Linksys	Unsupported（传感）	Linksys Aware 已于 2024 年停止支持，仅保留能力探测记录
Electric Imp	标量 IoT/RSSI 遥测	可选 agent/impCentral 桥，用于既有设备群；拒绝作为 CSI 采集硬件
RF Solutions	非 WiFi RF/IoT 遥测	从传感后端排除；可选 RIoT 环境融合是另一未来议题
Wifigarden	商业 OEM，能力未知	在芯片组、schema、离线、标定与数据权披露前冻结实现

从 v0.9.3 的实现角度，十家厂商的 Rust 注册表把上述决策落成了一个个"诚实描述符"：每个 provider 都有 hardware_validated: false、明确的 capability 与 availability、以及一段说明原因（reason）的文本。

能力分类的"禁止越级"原则

ComplexCsi 与 Unsupported 两类状态被禁止作为标量厂商事件出现：VendorRfEvent::validate 中 InvalidEventCapability 错误的注释写得很清楚——"complex CSI and unsupported states cannot be represented as scalar vendor events"。也就是说，遥测类厂商（如 Plume）永远构造不出 ComplexCsi 事件，代码在类型层面就堵死了"用 RSSI 冒充 CSI"的可能。测试 scalar_contract_rejects_csi_masquerading 正是用 Plume 的 RfTelemetry 描述符去校验一个伪装成 ComplexCsi 的事件，断言返回 CapabilityMismatch。

三、共享契约的类型与校验边界

v0.9.3 的核心是 wifi_densepose_hardware::vendor_rf 模块提供的一组共享类型。先看几个关键的全局上限常量：

pub const MAX_VENDOR_METRICS: usize = 64;   // 单事件指标数上限
pub const MAX_VENDOR_KEY_LEN: usize = 64;   // 指标名长度上限
pub const MAX_VENDOR_TEXT_LEN: usize = 256; // source_id / reason / label 文本长度上限

三个核心数据结构：

• ProviderDescriptor { vendor, capabilities, availability, hardware_validated, reason }——声明"这个厂商是什么、能提供什么、我现在是否可用"。校验规则：capabilities 不能为空、reason 不能为空且 ≤256 字符；若 hardware_validated 为 true 则 availability 必须是 Available，从结构上阻止"还没获得访问权就先标成已验证硬件"。
• VendorRfEvent { vendor, capability, sequence, timestamp_us, source_id, synthetic, metrics, label }——统一事件载体。其中 metrics 是 BTreeMap<String, f64>，synthetic 字段标记事件是模拟（true）还是真实（false）来源，是证据可追溯性的关键。
• trait VendorRfProvider: Send + Sync——每个厂商适配器的公共接口，只暴露两件事：fn descriptor()（能力声明）与 fn decode(&self, payload: &[u8]) -> Result<Vec<VendorRfEvent>, VendorEventError>（有界解码）。

错误类型 VendorEventError 覆盖了六种失败语义：InvalidDescriptor、CapabilityMismatch、InvalidEventCapability、InvalidPayload、MalformedPayload(String)、CredentialsRequired、ContractRequired、Unsupported。这套错误映射到 HTTP 后直接决定 REST 端点的状态码（见第六节）。

事件级校验规则（VendorRfEvent::validate）是每个适配器解码出口的最后一道闸：

1. 厂商必须与描述符一致，且事件 capability 必须在描述符声明的 capability 集合内，否则 CapabilityMismatch；
2. capability 为 ComplexCsi 或 Unsupported 时直接拒绝（InvalidEventCapability）；
3. source_id 非空且 ≤256 字符；
4. metrics 非空、≤64 项、键非空且 ≤64 字符、所有值必须为有限浮点数（is_finite，天然拒绝 NaN/Inf）；
5. label 若存在则 ≤256 字符。

四、四组适配器的分层实现

sensing server 侧把十家厂商分成了三个模块文件，各自体现不同的接入复杂度。

Origin AI 与 Plume/OpenSync（vendor_origin_plume.rs）

这两个适配器代表了"必须通过契约/凭据才能访问的云端感知面"。Origin 公开文档不定义稳定路径，因此请求路径由契约化部署配置提供，而非写死在代码里。OriginAiConfig 要求三个字段：base_url（契约提供的 HTTPS 基础地址）、event_path（契约提供的相对事件 API 路径）、token_env（存放伙伴 bearer token 的环境变量名）。

值得注意的设计是请求计划 VendorRequest：它刻意只携带"凭据引用"而非秘密本身——credential_env: Option<String> 是一个环境变量名字符串，由调用方在执行时解析。配套测试 request_plans_reference_secrets_without_embedding_them 断言 Debug 输出中不会出现 Bearer 字样。配置校验函数同时拒绝非 HTTPS 的 base URL、\r\n/#/?、.. 路径穿越以及非法环境变量名（vendor_origin_plume.rs 中 validate_https_base / validate_relative_path / validate_env_name）。

Origin 解码器 OriginAiProvider 只接受 DerivedSensing，事件信封是 deny_unknown_fields 的严格 JSON，枚举 OriginKind 覆盖 Motion/Occupancy/Presence/Fall/BreathingRate 五种感知结果；confidence 必须落在 0.0..=1.0，BreathingRate 的 value 还必须落在 1.0..=120.0 BPM 之间。测试 origin_rejects_unknown_raw_csi_and_bad_values 证明：即使 payload 里夹带 raw_csi 数组字段，也会因未知字段而被 deny_unknown_fields 拒绝。

Plume/OpenSync 则被建模成只读 OVSDB 客户端。PlumeOpenSyncConfig::select_request(table) 只允许三个白名单表——Wifi_Radio_State、Wifi_VIF_State、Wifi_Associated_Clients——并且只能发出 transact 里的 select（只读）操作；对 AWLAN_Node 这类可写/运维表直接返回 InvalidPayload（测试 request_validation_rejects_injection_and_write_tables）。事件解码只产出 RfTelemetry，指标键为 rssi_dbm（-127..=0）、channel（1..=233）、可选 noise_floor_dbm/tx_rate_mbps/rx_rate_mbps/clients，并逐一做有限性与范围校验。

Mist/Juniper 与 NETGEAR Insight（vendor_mist_netgear.rs）

这两家是"带分页的云端 REST/遥测面"，适配器做了三件有意义的事：

• 区域化请求配置：MistRegion（Global/Europe/AsiaPacific/Australia）与 NetgearRegion（NorthAmerica/Europe/Australia）各自映射到官方基础 URL；请求路径形如 /api/v1/sites/{site_id}/stats/clients 与 /api/v1/locations/{location_id}/clients。
• 分页解码：decode_page 从信封中提取记录数组与游标。记录数组支持顶层数组或 results/data/clients/events/items 任一键；下一页游标兼容 next_cursor/nextPageToken/next_page_token/pagination.next/pagination.cursor 多种命名，游标必须满足 ≤512 字节且不含 &/?/#/控制字符。单 payload 上限 1 MiB、单页记录数上限 1000。
• 字段别名归一化：MistRecord/NetgearRecord 通过 serde alias 同时接受各家命名（如 NETGEAR 的 clientId/mac/macAddress/deviceId、signalStrength/rssi_dbm），时间戳既支持秒/毫秒/微秒整数、也支持 RFC3339 与小数秒，统一归一化为微秒（测试 timestamp_units_are_normalized_and_extremes_rejected）。事件 sequence 用 FNV-1a 对 source_id + timestamp_us + index 做确定性哈希，保证可重放。

秘密处理上该模块定义了 SecretToken，其 Debug 输出恒为 SecretToken([REDACTED])，且构造时拒绝控制字符（防止 header 注入）；VendorRequestConfig 的 Debug 也把所有敏感字段打码。测试 token_rejects_header_injection 验证了包含 \r\nX-Injected 的 token 会被拒绝。

标量遥测类厂商与 fail-closed（vendor_remaining.rs）

Electric Imp、RF Solutions、Luma、Google Nest 被归入"有用表面仅为标量遥测或网络元数据"的一组。它们共用一条 decode_bounded_scalar_events 有界解码路径，并对每家定义了指标白名单（MetricRule，含名称、数值范围、是否整数）：

• Electric Imp：battery_v、humidity_percent、rssi_dbm、temperature_c、voltage_v
• RF Solutions：battery_v、humidity_percent、relay_state(整数)、rssi_dbm、temperature_c
• Luma（通用 OpenWrt）：client_count、noise_dbm、rssi_dbm、rx_bytes、tx_bytes
• Google Nest（NetworkOnly）：client_count、probe_count、rx_bytes、tx_bytes

白名单的意义在注释里写得很直白："防止任意标量字段悄悄改变 provider 契约的语义（也拒绝 CSI 形态的数据）"。测试 rejects_csi_or_cross_provider_metric_masquerading 验证了在 Electric Imp 事件里塞 csi_real 键会返回 CapabilityMismatch，在 Nest 的 NetworkOnly 事件里塞 rssi_dbm 同样被拒。

关键的两个 fail-closed 提供方也在这个模块：

• LinksysProvider：描述符为 Unsupported/Unsupported，decode 无条件返回 Err(Unsupported)——即使喂给它非 JSON 内容也先于解析失败（测试 unavailable_providers_fail_before_interpreting_payloads）。
• WifigardenProvider：描述符为 Unsupported/ContractRequired，decode 无条件返回 Err(ContractRequired)。

模块顶部还导出了四个确定性合成 fixture 常量（ELECTRIC_IMP_CONTRACT_FIXTURE 等），每个 fixture 都带 "synthetic":true，为 sidecar/离线重放提供稳定输入。

五、vendor-rf-sim：面向确定契约的确定性模拟器

vendor-rf-sim 是 wifi-densepose-hardware crate 的一个 bin，位于 src/bin/vendor-rf-sim.rs，作用是为"已定义事件契约的八家厂商"生成带 provenance 标记的确定性 JSONL/UDP 事件，并拒绝为 Linksys 与 Wifigarden 编造事件。

CLI 参数如下：

参数	默认值	说明
--vendor <name>	必填	厂商，值域见下
--frames <N>	100	发射的事件帧数
--seed <u64>	0x525556454e444f52	xorshift 随机种子，保证确定性
--interval_ms <N>	100	帧间隔（毫秒），用于时间戳与实时模式
--udp <addr>	无	目标 UDP 地址（如 127.0.0.1:5005）
--output <path>	无	输出 JSONL 文件路径
--realtime	关	按 interval 实际 sleep 逐帧发射

--udp 与 --output 至少选择其一，否则直接报错。厂商取值必须使用规范 snake_case 标识符：origin_ai、plume、mist、netgear、electric_imp、rf_solutions、luma、google_nest、linksys、wifigarden。

启动前的门控逻辑（main 中的检查）：当厂商描述符 availability 属于 Unsupported 或 ContractRequired 且 capability 含 Unsupported 时，直接以 "{vendor} has no simulatable event contract: {reason}" 退出。因此 --vendor linksys、--vendor wifigarden 不会产出任何事件。

事件指标按 capability 生成：

• DerivedSensing（Origin AI）：motion_score（正弦+噪声后夹到 0..1）、occupancy_count（1/2）、confidence（0.92）；
• RfTelemetry（Plume 等）：rssi_dbm（约 -52±5）、client_count（3/4）、channel_utilization（约 0.31）；
• NetworkOnly（Google Nest）：reachable、device_count。

每条事件 source_id 形如 plume-sim-01，synthetic: true，label 固定为 deterministic_contract_fixture，并在发射前逐条调用 validate。单帧 canonical JSON 形如：

{
  "vendor": "plume",
  "capability": "rf_telemetry",
  "sequence": 0,
  "timestamp_us": 0,
  "source_id": "plume-sim-01",
  "synthetic": true,
  "metrics": {
    "channel_utilization": 0.31,
    "client_count": 3.0,
    "rssi_dbm": -52.0
  },
  "label": "deterministic_contract_fixture"
}

典型用法（在 v2 工作区目录内构建并运行）：

# 构建硬件 crate（含 vendor-rf-sim bin）与 sensing server
cargo build -p wifi-densepose-hardware -p wifi-densepose-sensing-server

# 查看帮助
cargo run -p wifi-densepose-hardware --bin vendor-rf-sim -- --help

# 向文件输出 200 帧 Plume JSONL fixture（固定种子保证可复现）
cargo run -p wifi-densepose-hardware --bin vendor-rf-sim -- \
    --vendor plume --frames 200 --output plume-fixture.jsonl

# 实时把 100 帧 Mist 事件发往本机 sensing server 的 UDP 端口（默认 5005）
cargo run -p wifi-densepose-hardware --bin vendor-rf-sim -- \
    --vendor mist --udp 127.0.0.1:5005 --realtime

运行结束会在 stderr 打印摘要：emitted N synthetic {vendor} events (M bytes, seed=0x...)。

六、Sensing Server 的接入面：REST、UDP 与 WebSocket

v0.9.3 在 sensing server 上提供了 provider 注册表、描述符、最新事件 REST 端点以及 WebSocket 摘要推送。路由注册集中在 main.rs：

方法与路径	处理器	说明
GET /api/v1/rf/vendors	vendor_descriptors	返回全部 10 个 provider 描述符
GET /api/v1/rf/vendors/latest	latest_vendor_events	返回各厂商最新事件的映射
GET /api/v1/rf/vendors/{vendor}/latest	latest_vendor_event	查询指定厂商最新事件（未知厂商返回 404）
POST /api/v1/rf/vendors/{vendor}/events	ingest_vendor_events	以该厂商的 provider 解码器解析并摄取 payload（适用于真实/实时数据）

服务器默认端口为 HTTP :8080、UDP :5005、WS :8765（见 sensing server README）。用 curl 快速验证：

# 1. 列出 provider 注册表（能力/可用性/硬件验证状态）
curl -s http://127.0.0.1:8080/api/v1/rf/vendors

# 2. 查询 Origin AI 最新事件
curl -s http://127.0.0.1:8080/api/v1/rf/vendors/origin_ai/latest

# 3. 以 Plume 解码器摄取真实(非合成)遥测 payload
curl -s -X POST http://127.0.0.1:8080/api/v1/rf/vendors/plume/events \
  -H 'Content-Type: application/json' \
  --data-binary @plume_live.json

ingest_vendor_events 的错误语义是 fail-closed 的（HTTP 状态码映射）：

• 未知厂商路径 → 404；
• 解码返回 Unsupported → 501 NOT_IMPLEMENTED（Linksys）；
• 解码返回 ContractRequired 或 CredentialsRequired → 403 FORBIDDEN（Wifigarden、无凭据时）；
• 其余载荷错误 → 400 BAD_REQUEST；
• 成功 → 202 ACCEPTED，响应 {"vendor": ..., "accepted": N}。

每条被接受的事件都会转成 VendorEventSnapshot（event_type: "vendor_rf"，source 形如 vendor:plume:simulated/vendor:plume:live），写入 latest_vendor_rf 状态，并通过 WebSocket 通道 tx 向已连接客户端广播（浏览器端对应 ws://localhost:8765/ws/sensing）。

UDP 数据面则承接了 vendor-rf-sim 的确定性输出：UDP receiver 发现首字节为 { 的报文时按 canonical VendorRfEvent 解析（main.rs 的 udp_receiver_task），再经服务端描述符校验。只有 synthetic: true 的事件会被接受；非合成事件会收到 warn! 日志"live payloads must use the provider decoder HTTP route"，并被拒绝——这保证了"真实事件只能走厂商解码器"的纪律。此外 UDP 数据面受 ADR-296 源地址 allowlist 约束，非白名单来源（loopback 除外）的报文直接被丢弃。

鉴权范围

路由鉴权由 bearer_auth.rs 的 required_scope_for 决定：所有非变更方法（GET/HEAD/OPTIONS）要求 sensing:read；POST /api/v1/rf/vendors/{vendor}/events 因前缀命中 READ_SAFE_MUTATIONS 的 allowlist 也只需 sensing:read（路径带 :vendor 段，无法精确匹配，故用前缀规则）；而 /api/v1/rf/vendors/netgear/delete-all 这类其余变更路由一律按默认 fail-closed 规则落到 sensing:admin（测试 vendor_event_ingest_is_read_scoped_by_prefix 明确验证了这一边界）。也就是说："摄取厂商事件"被刻意视为只读安全操作，而任何影响系统状态的其他厂商路由默认都需要管理员权限。

七、确定性重放与 fail-closed 测试矩阵

v0.9.3 的可靠性主张由大量单元测试支撑，覆盖 ADR-270 要求的重放、损坏、丢失、重连、背压、schema 演进与秘密处理等测试维度。按模块归纳：

测试类别	代表性测试	位置
标识稳定性	every_vendor_has_a_stable_identifier	vendor_rf.rs
CSI 伪装拦截	scalar_contract_rejects_csi_masquerading	同上
注册表完整性	registry_has_exactly_one_valid_descriptor_per_vendor	sensing-server/vendor_rf.rs
fail-closed	unsupported_providers_fail_closed（Linksys→Unsupported、Wifigarden→ContractRequired）	同上
诚实能力声明	descriptors_are_honest_about_capabilities_and_access、no_remaining_provider_claims_complex_csi_or_hardware_validation	vendor_origin_plume.rs / vendor_remaining.rs
确定性重放	mist_rest_and_webhook_fixture_is_deterministic、fixtures_are_deterministic_bounded_and_marked_synthetic	vendor_mist_netgear.rs / vendor_origin_plume.rs
载荷边界	malformed_empty_oversized_and_unbounded_arrays_fail_closed、payload_and_page_bounds_are_enforced	各适配器模块
秘密处理	request_plans_reference_secrets_without_embedding_them、token_rejects_header_injection	vendor_origin_plume.rs / vendor_mist_netgear.rs
时间戳归一化	timestamp_units_are_normalized_and_extremes_rejected	vendor_mist_netgear.rs

关键的工程约束是：每家的 fixture 解码两次必须逐字节等价（assert_eq!(first, second)），且每条 fixture 事件都以 synthetic: true 标记，保证"确定性合成输入"与"真实数据"在证据链上永远可分。

八、Boundary：本版本声明了什么、没声明什么

v0.9.3 发布说明用独立的 Boundary 小节划清了边界，这是整套设计最重要的部分：

本版本实现并验证的是软件契约。它不声称拥有厂商云凭据、商业 SDK 权利、物理硬件验证，也不为仅遥测的厂商提供复杂 CSI 支持。

对应地，代码里每一项证据都服从这一纪律：

• 所有 10 家厂商描述符的 hardware_validated 一律为 false——物理/厂商云验证与实现完备性是两回事，未完成前不允许翻转为 true；
• ADR-270 定义了六步门控循环（核实权威 API/SDK→先写 ADR→实现有界 Rust 类型→做确定性/损坏/丢失/重连/背压/schema 演进/秘密测试→仅在合法物理采集 + 精确机型固件 + 标定与可重复性测试 + fixture 发布权齐备后才提升为硬件支持→发布并声明 measured-versus-simulated 边界），v0.9.3 停留在前四步；
• 模拟器成功永远不能替代上述硬件门禁——这正是"vendor-rf-sim 可以产 Plume 事件，但 Plume 的描述符依然是 RfTelemetry + CredentialsRequired"的原因。

从仓库上下文还能看到这一发布与整体路线的衔接：v0.9.3 是四连 beta 的最新一环（docs/releases 中 v0.9.0 Realtek、v0.9.1 MediaTek、v0.9.2 Qualcomm、v0.9.3 Vendor Providers），其前向关联 ADR 是 ADR-268（Qualcomm 平台），Qualcomm 仍作为 ComplexCsi 的第一物理基线独立推进，而 v0.9.3 的云/遥测类厂商在能力上被明确隔离开。

九、快速上手路径小结

想在本地复现 v0.9.3 的能力边界，建议按以下顺序验证（前提：已检出仓库，Rust 工具链满足 v2/rust-toolchain.toml 要求）：

1. 阅读架构依据：ADR-270 → 本发布说明 v0.9.3-vendor-providers-beta.1.md；
2. 阅读契约源码 vendor_rf.rs，理解五能力分类与边界常量；
3. 构建并在 v2 工作区跑单测：cargo test -p wifi-densepose-hardware -p wifi-densepose-sensing-server（覆盖上节全部测试矩阵）；
4. 启动 server：cargo run -p wifi-densepose-sensing-server（默认 HTTP 8080 / UDP 5005 / WS 8765）；
5. 运行 vendor-rf-sim --vendor plume --udp 127.0.0.1:5005，再 curl http://127.0.0.1:8080/api/v1/rf/vendors/plume/latest 观察 canonical 事件落库与广播；
6. 尝试 --vendor linksys 观察"no simulatable event contract"的 fail-closed 拒绝。

整套实现的可验证结论是：v0.9.3 用一份 Rust 类型契约 + 逐厂商有界解码器 + 确定性模拟器 + 服务端注册表/接入面，把异构的十家厂商整合进了 RuView 的实时传感管线，同时用 hardware_validated: false 和只允许 synthetic 走 UDP 的纪律，让"模拟的置信度"与"硬件的置信度"在每一次发布中都泾渭分明。