RuView 原生 HomeKit HAP 桥接：让 Seed 直通 Apple Home，免 Home Assistant 中间层

本文基于 docs/adr/ADR-125-ruview-apple-home-native-hap-bridge.md 编写，阐述 RuView 在 Cognitum Seed 运行时的 HAP（HomeKit Accessory Protocol）原生配件接入方案 —— 使刷好镜像的 Seed 直接以 RuView Sense 配件身份出现在 Apple Home 应用中，借助 HomePod / Apple TV 完成发现与自动化，全程零 Home Assistant 依赖。读完本文，你将掌握：RuView 数据流向 HomeKit 的正确架构（"广播而非推送"）、HAP-python 与 Rust 原生两条实现轨道的取舍与验收标准、单桥多子配件的拓扑设计，以及 BFLD 隐私类事件如何在 HomeKit 边界被映射为"语义事件"而非"概率监控"。

---

1. 背景：一个需要澄清的方向性误解

1.1 推送 HomePod 是行不通的

一种"天真"的集成思路是把数据推给 HomePod——开一个 socket、发一条 JSON-RPC、往 homepod.local 上写一个 MQTT topic。Apple 在设计上并不暴露这类接口。HomePod 不是终端端点，而是 Apple Home 生态在局域网内的 Home Hub + Matter Controller + HomeKit Controller + Siri 端点。它通过 Bonjour/mDNS 主动发现那些在局域网中自我广播（使用 HAP 或 Matter 协议）的配件。

因此正确的数据流向是反向的：

RuView / Seed
      ↓                  （在局域网广播 HAP / Matter 配件）
HomeKit / Matter accessory
      ↓                  （mDNS 发现）
HomePod
      ↓                  （转发给 Apple Home 自动化图）
Apple Home 生态（iPhone、Watch、Mac、Siri、automations）

RuView 负责提供 Apple 自身无法天然具备的"隐形感知层"（无摄像头像素的射频人体感知），Apple 则提供开放感知栈无法自举的"分发与 UX"。直接 HAP 集成拆掉了横亘在两者之间的唯一结构性障碍——作为强制性中间层的 Home Assistant。

1.2 现状：当前路径止步于 Home Assistant

RuView 已经具备三条向外的集成通道：

• ADR-115（HA-DISCO）：在 wifi-densepose-sensing-server 内实现的 MQTT 自动发现发布器，每节点每能力发布一条 HA 发现消息，详见 docs/adr/ADR-115-home-assistant-integration.md；
• ADR-116（cog-ha-matter）：把该发布器封装为 Seed 可安装的 cog 制品，附带 mDNS、内嵌 rumqttd broker 决策、RuVector 阈值与 Ed25519 见证链，见 docs/adr/ADR-116-cog-ha-matter-seed.md；
• ADR-122（BFLD 暴露）：在相同发布器上扩展 BFLD 的存在感 / 身份风险 / Soul-Match 话题，见 docs/adr/ADR-122-bfld-ruview-ha-matter-exposure.md。

因此当下要到达 HomePod 的路径是：

RuView sensing-server ──► cog-ha-matter (MQTT HA-DISCO + HA-MIND)
                              ↓
                       Home Assistant broker
                              ↓
                       Home Assistant HomeKit Bridge add-on
                              ↓
                              HomePod

这条链路可用且自动发现真实有效，但引入了一个硬依赖：操作者必须自行运行 Home Assistant、安装其 HomeKit Bridge 集成并在 Apple Home 应用中完成桥接配对。Seed 本身不会出现在 Apple Home 里。

值得注意，ADR-116 §P7 早已为这一缺口埋下伏笔——cog-ha-matter 的 Cargo.toml 携带一个 matter = [] feature 占位符，注释写着 "matter-rs is added in P7; intentionally absent in P1 to keep the dep surface small until the SDK choice is validated."（matter-rs 在 P7 加入；P1 中刻意缺席以在 SDK 选型验证前维持最小依赖面）。ADR-125 正是要闭合这个盒子。

1.3 为什么是现在（2026-05 的三股力量）

1. BFLD 隐私门已发布（ADR-118 / ADR-120 / ADR-121）：按 ADR-122 §2.4，只有 class-2（Anonymous）与 class-3（Restricted）帧才有资格跨越 Matter 边界。有了这道门，每一个 Anonymous / Restricted 事件都能安全地以 HomeKit 传感器身份对外广播。
2. @ruvnet/rvagent（ADR-124）已上 npm：让 Agent 能查询 RuView 的 MCP 面已就绪。原生 Apple-Home 存在感可将 RuView 的触达从"会说 MCP 的 Agent"扩展到"任何手握 iPhone 与 HomePod 的人"。
3. Cognitum Seed Docker 镜像现已内置 cog-ha-matter：HAP 广播器的运行宿主终于变成单镜像部署。

1.4 不对称的价值组合

层级	RuView 贡献	Apple Home 贡献
感知	被动射频存在感、呼吸、心率、跌倒风险、BFLD 身份风险、穿墙占用、纵向健康	（无——Apple 没有原生射频感知面）
采用	（有限——当前为研究级硬件）	iPhone / Watch / Mac / HomePod / Apple TV 存量、消费级信任、语音、设备端智能
UX	（工具 CLI + Web UI）	Home app、Siri、自动化引擎、通知、无障碍
信任	Ed25519 见证链、隐私类门、本地优先	Apple HomeKit 本地配对、端到端加密、无需云

---

2. 决策：Seed 运行时内嵌原生 HomeKit / Matter 配件

方案核心：在 Seed 运行时中提供原生 HomeKit / Matter 配件，使刚刷好镜像的 Cognitum Seed 在 Apple Home 的 添加配件 → 更多选项 中直接出现，零 Home Assistant 依赖。具体包含三点：

1. 新增 hap-accessory workspace 组件，通过 mDNS + HAP-1.1（HomeKit Accessory Protocol）广播一组 HomeKit 特征；
2. 该组件订阅 wifi-densepose-sensing-server 的 WebSocket / BFLD MqttEvent 流，将每个隐私类 2/3 事件映射为一次 HomeKit 特征更新；
3. 与 sensing-server、cog-ha-matter 打包进同一个 Docker 镜像，作为第三个 entrypoint：

docker run --network host ruvnet/wifi-densepose:latest hap-accessory --privacy-mode

--network host（或 macvlan 桥）是必需的：HAP 配对依赖配件与控制器在同一 L2 网段看到彼此的 mDNS 广播——这与 Home Assistant 的 HomeKit Bridge 所面临的约束完全一致。

2.1 两条实现轨道（一次决策，先上 2.1.a）

2.1.a — HAP-python sidecar（最快落地、先行交付）

方案是在镜像中加入一个轻量 Python entrypoint bridges/hap-python/ruview_hap.py，使用社区维护良好的 HAP-python 库。Dockerfile 增加一个精简 Python 运行时 stage；entrypoint 脚本通过 HTTP 轮询 sensing-server，再把特征更新推进 HAP 事件循环。ADR 中给出了约 80 行的最小原型：

# bridges/hap-python/ruview_hap.py (≈80 LOC)
from pyhap.accessory import Accessory
from pyhap.accessory_driver import AccessoryDriver
from pyhap.const import CATEGORY_SENSOR
import urllib.request, json, threading, time

SENSING_URL = "http://127.0.0.1:3000/api/v1"

class RuViewSensor(Accessory):
    category = CATEGORY_SENSOR

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        s_motion = self.add_preload_service('MotionSensor')
        self.c_motion = s_motion.configure_char('MotionDetected')
        s_occ = self.add_preload_service('OccupancySensor')
        self.c_occ = s_occ.configure_char('OccupancyDetected')
        s_temp = self.add_preload_service('TemperatureSensor')
        self.c_temp = s_temp.configure_char('CurrentTemperature')
        threading.Thread(target=self._poll, daemon=True).start()

    def _poll(self):
        while True:
            try:
                v = json.loads(urllib.request.urlopen(f"{SENSING_URL}/vitals").read())
                self.c_motion.set_value(bool(v.get("motion_present")))
                self.c_occ.set_value(int(bool(v.get("occupancy"))))
                if "ambient_temp_c" in v:
                    self.c_temp.set_value(v["ambient_temp_c"])
            except Exception:
                pass
            time.sleep(1.0)

driver = AccessoryDriver(port=51826)
driver.add_accessory(accessory=RuViewSensor(driver, 'RuView Sense'))
driver.start()

原型中 _poll 每 1 秒请求一次 http://127.0.0.1:3000/api/v1/vitals，把 motion_present、occupancy、ambient_temp_c 映射到 MotionSensor / OccupancySensor / TemperatureSensor 三个服务上。真实运行环境里这些字段来自已校准的 ESP32 射频感知管线（CSI_SOURCE=esp32）。

操作者 iPhone 侧的配对流程：

1. 打开 Apple Home → 添加配件 → 更多选项；
2. 点选 RuView Sense（经 mDNS 自动出现）；
3. 输入 docker logs 打印（或由环境变量固定）的设置码；
4. 完成——此后即可说 "Hey Siri, is anyone in the living room?"。

随后应随 RuView 能力成熟度渐进替换 motion_present / occupancy 映射：BFLD class-2 presence 事件 → OccupancyDetected；BFLD class-3 identity_risk_score > threshold → SecuritySystemCurrentState（此映射在 §2.1.d 中被否决，见下文）；breathing_present → OccupancyDetected（卧室）；fall_risk → 触发 Apple Home 自动化的可编程开关。

2.1.a 的验收标准（A1–A5）：

• A1：docker run ... hap-accessory --privacy-mode 广播出 _hap._tcp 服务，HomePod 30 秒内可见（在联网 Mac 上 dns-sd -B _hap._tcp local. 能列出 RuView Sense）；
• A2：从 Apple Home 配对成功，实体出现在配置房间下；
• A3：来自已校准 ESP32 源（CSI_SOURCE=esp32）的真实射频存在检测后，2 秒内 MotionDetected 翻转；
• A4：重启容器不丢配对（HAP 状态持久化于 /var/lib/ruview-hap/）；
• A5：隐私——当 RUVIEW_BFLD_PRIVACY_CLASS 未设置时，entrypoint 拒绝在缺少 --privacy-mode 的情况下启动，匹配结构不变量 I1（原始 BFI 永不离开节点，见 ADR-118 §2.2）。

2.1.b — Rust 原生 HAP（单二进制，闭合 ADR-116 P7）

把维护良好的 Rust HAP crate 接入 cog-ha-matter，从而移除 Python sidecar。ADR 当时评估的三个候选：

• hap crate（Sebastian Schmidt）——最后发布 0.1.0-pre.16、MIT 许可、2024 年仍活跃、支持 HAP-1.1、自带 MotionSensor / LightBulb / OccupancySensor 示例，首选；
• accessory-server crate——范围更窄、服务更少；
• project-chip 的未来 matter-rs crate——待 CHIP SDK 的 Rust 绑定稳定（2026-05 仍在演进）。

cog-ha-matter/Cargo.toml 中自 ADR-116 P1 加入的 matter = [] 占位符将演进为：

[features]
default = []
mqtt = ["dep:rumqttc"]
matter = ["dep:hap"]          # ADR-125 §2.1.b

并提供一个镜像 Python 广播器配件集合的运行时子命令 cog-ha-matter --mode hap——单二进制、镜像内无 Python 解释器、符合 Cognitum Seed 的全 Rust 气质（ADR-116 §1.4）。

仓库实现提示：这条 Rust 轨道的实际形态已偏离 ADR 初稿的 crate 名单。工作区 v2/crates/homecore-hap/ 的 Cargo.toml 与 README 说明，它实现的是"无依赖被破坏的 hap 0.1 预发布 crate"的自研受限 HAP R2 配对与传输边界：Pair-Setup M1–M6（RFC 5054 3072-bit + SHA-512、HKDF-SHA512、ChaCha20-Poly1305、Ed25519 长期密钥）、Pair-Verify M1–M4（临时 X25519 + 严格 Ed25519 转写校验），配对后全部 HTTP 与 EVENT/1.0 流量走 HAP record（两字节小端认证长度、单条最多 1024 明文字节、单向密钥、单调 64 位 nonce），认证/重放/截断/超限失败即断连且不给出 oracle 响应。

2.1.c — 拓扑：一个 HAP 桥、N 个子配件（已决策）

广播器发布单个 HAP 桥（RuView Sense），由其持有 N 个子配件——每个逻辑传感器面一个（presence-bedroom、presence-office、vitals-bedroom、semantic-events……）。操作者只配对一次桥，子配件自动出现，并可在 Apple Home 应用中被重新分配到各房间。

被否决的替代方案是 N 个各自独立广播的配件。它迫使操作者按房间逐一配对（RuView Bedroom、RuView Office、RuView Wellness、RuView Presence……），第二、第三个房间后就变得杂乱，且偏离 Home 应用中所有参考级 HomeKit 配件的行为范式（Hue 桥带灯泡、Eve Energy 桥等）。单次配对也让容器重启 / 换镜像变得微不足道——只有一份持久化配对密钥，而非 N 份。

2.1.d — 身份风险映射：语义事件，而非概率监控（已决策）

identity_risk_score 是 BFLD 身份特征管线输出的连续 0..1 置信度（ADR-121 §2.6）。它不得以原始值跨越 HomeKit 边界，也不得接到 SecuritySystemCurrentState 上——Apple-Home 用户会把安全系统状态读成"检测到入侵者"，把概率暴露在那里等于把 RuView 变成监视 UX，随之而来的是全部误报指责。

桥接层改为暴露经阈值化的语义事件，读感是"环境觉察"而非"威胁侦测"：

语义事件	HomeKit 原语	触发（示例性）
Unknown Presence	MotionSensor（可编程、有状态）	BFLD class-2 presence + 超过 30 s 无匹配 SoulMatch oracle 命中（ADR-121 §2.6）
Unexpected Occupancy	OccupancySensor（可编程）	房间在其操作者定义的"预期日程"窗口之外发生占用
Unrecognized Activity Pattern	可编程 Switch（有状态、瞬时）	BFLD 纵向漂移门（ADR-118 §2.3 / ADR-122 §2.7）触发 Reject 或 Recalibrate

始终留在内部、绝不发布的数据：

• 原始 identity_risk_score（0..1 数值）——永不发布；
• Soul-Signature 匹配概率——永不发布；
• rf_signature_hash——永不发布（ADR-118 §2.5 / ADR-122 §2.4 已强制——这是 HAP 边界上被重申的结构不变量）。

命名即契约。"Unknown Presence"的语义是"有人在、没事、但值得记一笔"，普通终端用户会写"9 点后检测到 Unknown Presence 就打开门廊灯"这类自动化，而不会觉得它指控谁是入侵者。这种语义框架决定了 RuView 是成为 Apple Home 需要的 calm-tech 环境基质，还是沦为又一个偏执的监视小部件——这也是决定其 HomeKit 叙事能否长久成立的关键部分。

2.2 2.1.a / 2.1.b 明确不做的事

• 不写 Matter（CHIP）Controller 代码：Matter 是长期棋局，但其 Rust SDK 尚不稳定、证书配置笨重；HAP-1.1 over Bonjour 今天用 10% 的复杂度换取 95% 的 UX；
• 不直连 HomePod：按 §1.1 的框架，RuView 永不向 HomePod 开 socket，它广播、HomePod 发现；
• 不绑定 iCloud 账号：HAP 配对天然只走局域网——RuView 在不触碰 Apple ID 的情况下获得采用，这是一个保持干净的隐私叙事；
• 不暴露任何 Class-0（Raw）BFI：结构不变量 I1（ADR-118 §2.2）成立，仅隐私类 2（Anonymous）与 3（Restricted）帧可映射到 HomeKit 特征，广播器拒绝以任何其他模式启动。

2.3 排期

1. P1（ADR-125 + 1 PR）：HAP-python sidecar（§2.1.a）作为同一 Docker 镜像中的独立 entrypoint 落地，AC A1–A5 为门禁；
2. P2（收集 5+ 次 Apple Home 配对的操作者反馈后）：Rust 原生 HAP（§2.1.b），替换 P1，P1 的 bridges/hap-python/ 降级为归档参考实现；
3. P3（matter-rs 稳定时）：Matter Controller 路径（RuView 仍作配件，但使用 Matter cluster 而非 HAP-1.1 服务），Cognitum Cog 获得 Matter QR 码，配对面扩展到"任何 Matter 控制器，不止 Apple"。

---

3. 后果分析

3.1 收益（Wins）

• Apple Home 上直接可见：厨房里的 Seed 在 docker run 后数秒内以 RuView Sense 身份出现在 Home 应用中，无需 HA、MQTT broker 或 HomeKit Bridge add-on；
• Siri 原生回答 RuView 问题："Hey Siri, is anyone in the kitchen?" 无需任何自定义 skill 或 HA 模板传感器即直达 HomeKit 特征；
• Apple-Home 自动化获得环境级触发器：RuView 已有的 presence / breathing / fall / identity-risk 全部成为 Home app UI 中的一等自动化触发条件；
• 战略上修正 RuView 的分发问题：Apple Home 存量是 HomeKit 级配件最大的消费面，RuView 的感知 IP 无需 SDK 移植即可触达该存量；
• 闭合 ADR-116 §P7：长期挂起的 matter / HAP 缺口从"无限期推迟"变为"已排期"。

3.2 代价（Costs）

• 镜像中新增 Python 运行时（仅 2.1.a，到 2.1.b 落地为止）：运行层增加约 30 MB。缓解：P2 移除；P1 将 Python 依赖隔离在旁路 stage，让 sensing-server / cog-ha-matter 层保持干净；
• 网络模式约束：HAP 配对要求控制器与配件同处一个 L2 网段（mDNS 广播）。NAT/桥接容器中运行 RuView 的操作者需要 --network host 或 macvlan——这与 HA HomeKit Bridge 的约束相同，但值得写进文档；
• 配对状态持久化：HAP-python 将配对数据存于本地文件，该状态必须跨容器重启存活，需把 /var/lib/ruview-hap/ 卷挂载到持久位置。

3.3 风险（Risks）

• HAP-python 维护风险：社区维护的库若停滞，P2（Rust 原生）吸收风险——2.1.a 明确是垫脚石而非长期承诺；
• Apple 需求演进：HomeKit Accessory Certification 只针对给硬件打 HAP logo 的情形，不影响软件配件本地配对。RuView 的容器化部署正落在 Apple 明确允许的"未认证开发者配件"车道，值得在操作者 README 中重申；
• 桥接边界的隐私类执行：若某个 bug 使 class-0 BFI 帧的数据影响 HAP 特征更新，即违反 I1。缓解：桥只消费已被 ADR-120 PrivacyGate 门控的 BFLD MqttEvent 流，绝不接触原始 BFI；测试以 ADR-122 §4.3 同款风格断言此性质。

3.4 可逆性（Reversibility）

广播器是独立 entrypoint——撤掉它只需 docker run 不带 hap-accessory 首参，行为与今天完全一致，对 sensing-server 与 cog-ha-matter 的运行零影响。

---

4. P1（§2.1.a）验收测试命令

# 1. 启动 sensing server（用模拟源，测试可在任何环境跑）
docker run -d --name rs -p 3000:3000 -e CSI_SOURCE=simulated \
    ruvnet/wifi-densepose:latest

# 2. 以隐私模式启动 HAP 广播器 sidecar
docker run -d --name hap --network host \
    -v /var/lib/ruview-hap:/var/lib/ruview-hap \
    -e RUVIEW_BFLD_PRIVACY_CLASS=2 \
    ruvnet/wifi-densepose:latest hap-accessory --privacy-mode

# 3. 在处于同一局域网的 Mac 上：应看到 RuView Sense 以 HAP 身份出现
dns-sd -B _hap._tcp local.   # 期望：30 秒内出现 "RuView Sense"

# 4. iPhone Home app：添加配件 → 更多选项 → RuView Sense
#    输入 `docker logs hap` 中的设置码
#    期望：配对完成，实体出现在所选房间

# 5. 重启容器再打开 Home app：实体仍处于已配对状态
docker restart hap
# 期望：无重新配对提示；特征更新恢复

本仓库镜像内对应入口的实际容器名/镜像标识以发布产物为准；上述命令忠实取自 ADR-125 §4 的验收脚本，用于校验 mDNS 广播、配对持久化与隐私门三个关键性质。

---

5. 仍待关闭的问题（Open Questions）

评审期间已解决 §2.1.c 与 §2.1.d 两个初稿问题，其余待后续 PR 关闭：

• 设置码派生方式：从 Seed 的 Ed25519 见证密钥确定性派生（重装复用同码、操作者不再输入），还是每次启动随机（安全略优、容器重启 UX 变差）？倾向确定性 + 见证密钥派生；提交前需对照 Apple HomeKit Accessory Protocol §5.6.5 的设置码唯一性要求校验；
• ESP32 / Cognitum-Seed 级硬件直接充当 HAP 广播器（不经宿主机）。当前决策把桥停在宿主运行时；未来 ADR 可评估 8MB flash 的 ESP32-S3 是否足以直接运行 HAP-1.1，从而在单房间部署中把宿主机整个移出路径。

---

6. 仓库现状交叉印证：从设计到落地痕迹

ADR-125 头部状态标注为 Proposed（2026-05-25），其设计在该仓库中已留下多层落地痕迹，可逐条对照阅读：

• 操作者指南与迭代记录：docs/user-guide-apple-homepod.md 记录了 feat/adr-125-apple-fabric 分支上的 8 轮迭代（PR #797）：从多特征 HomeKit 配件（Motion + Occupancy + StatelessProgrammableSwitch），到 sensing-server 的 /api/v1/vitals、/api/v1/bfld、/api/v1/semantic-events 三个供桥轮询的 HTTP 端点，再到 §2.1.c 的"N 个子配件桥 + 按房间 Siri"（RuView Sensing）、§2.1.d 的语义事件端点（I1 强制执行），以及 PyO3 BFLD PrivacyClass 绑定与 Shortcuts-as-glue（launchd + 经由 iCloud Home graph 的 Speak Text）。这也说明文档中的 SENSING_URL 端点与验收脚本描述的 HTTP 轮询模式已实际运行；
• 仓库内的 HAP-python 侧car 参考实现：
  • scripts/hap-test-sensor.py —— ADR-125 §2.1.a 冒烟测试：单 HAP 桥 + 一个 RuView Test Motion 子配件，AccessoryDriver(port=51826)，配对状态持久化在 ~/.ruview-hap/，同时支持旧版布尔触摸文件（/tmp/ruview-motion）与新版 JSON IPC（/tmp/ruview-state.json，schema 含 motion / occupancy / anomaly / ts）；
  • scripts/ruview-hap-bridge.py —— §2.1.c 的生产级桥：桥名 RuView Sensing（端口 51827、独立持久化目录 ~/.ruview-hap-prod），自动按 --rooms 或扫描 /tmp/ruview-state.<room>.json 挂载每个房间子配件，每个子配件带 MotionSensor + OccupancySensor + StatelessProgrammableSwitch 三服务；文件内还预留了 BFLD PrivacyClass 自定义特征 UUID（8B0E1C00-0001-4B0E-9C00-1234567890AB），用于 Eve.app 渲染，注明"经 HAP-python JSON-loader 路径落地，属后续迭代"；
• Rust 原生轨道的工作区起点：v2/crates/homecore-hap/（含 Cargo.toml 与 src/mapping.rs）。注意其 README 自我标注：实现的是协议级 HAP R2 覆盖，含真实 TCP 生命周期（Pair-Verify → 加密 /accessories）的确定性测试套件，但未经当前 Apple Home 控制器实测、不代表 Apple 认证；可写特征调用、定时写、资源端点、持久 AID/IID 分配尚未实现，当前特征面仅读与事件订阅。构建验证命令为 cargo test -p homecore-hap --no-default-features 与 cargo test -p homecore-hap --features hap-server；
• Matter feature 占位符的源头：见 ADR-116 实现阶段表中的 P7 行——"Matter Bridge mode（depends on matter-rs / esp-matter readiness）| pending"，其配套研究档案在 docs/research/ADR-116-ha-matter-cog-research.md（Matter 1.4 OccupancySensor (0x0107) + RFSensing feature flag 结论）。ADR-125 是这一行被正式排期的节点。

7. 关联 ADR 阅读地图

• ADR-115——Home-Assistant 集成（HA-DISCO MQTT 发布器，ADR-125 上游的数据来源）；
• ADR-116——cog-ha-matter Seed cog（matter feature 占位符所在地）；
• ADR-118——BFLD 波束赋形反馈层（隐私门 + 类不变量 I1）；
• ADR-120、ADR-121——隐私类与身份风险评分的上游定义；
• ADR-122——BFLD 的 RuView HA/Matter 暴露（本 ADR 的 HAP 原生路径所互补的现行 MQTT 桥）。

关于外部规范：HAP-python 库与 hap Rust crate 的具体版本与可用性请以各自发布渠道为准；HomeKit Accessory Protocol 规范（非商业版）由 Apple 提供。本文不提供外部跳转链接，仅作库名与选型判断的记录。

---

小结：ADR-125 的核心洞察是——HomePod 是"发现者"而非"接收器"，正确的集成姿势是让 RuView 作为 HAP 配件自我广播。以"单桥多子配件 + 语义事件 + 隐私类门控"三支柱，它把 BFLD 之后成熟的感知能力安全地送进 Apple Home 这一最大的消费级自动化表面，同时把 Home Assistant 从"必经之路"降级为"可选之一"。无论是选择先行的 HAP-python sidecar、随后接棒的 Rust 原生实现，还是远期 Matter 路径，本文所述的验收标准（mDNS 30 秒可见、2 秒特征翻转、重启不丢配对、无 --privacy-mode 拒启）都是可逐条验证的落地清单。