Two open questions from §5 promoted to decisions in §2:
§2.1.c — Topology: one HAP bridge, N child accessories. Single pairing
flow; child accessories assignable to rooms in the Apple Home
app; matches every reference HomeKit bridge UX (Hue, Eve, ...).
The N-independent-accessories alternative was rejected for the
room-multiplication mess it creates after the second pairing.
§2.1.d — Identity-risk mapping is semantic, not probabilistic. The
raw `identity_risk_score` and Soul-Signature match probability
NEVER cross the HAP boundary. Instead we expose three thresholded
semantic events: `Unknown Presence`, `Unexpected Occupancy`,
`Unrecognized Activity Pattern`. Naming is the contract — these
read as ambient awareness, not threat detection, so RuView does
not become "RF surveillance with an Apple skin." This is the
decision that determines whether the HomeKit story ages well.
§5 trimmed to two genuinely-open items: setup-code derivation
(deterministic vs random) and ESP32-direct HAP advertisement.
Co-Authored-By: claude-flow <ruv@ruv.net>
Proposes direct HomeKit Accessory Protocol (HAP-1.1) advertisement
from the Seed runtime so HomePod / Apple Home discovers RuView with
zero Home Assistant intermediary. Two implementation tracks:
P1 (lands first): HAP-python sidecar — a tiny pyhap entrypoint in
the same Docker image, ~80 LOC; fastest to ship; pairing flow
from the Apple Home app.
P2 (follow-up): Rust-native HAP via the `hap` crate; replaces P1;
closes the ADR-116 P7 stub (`matter = []` feature flag becomes
`matter = ["dep:hap"]`); single binary.
P3 (later): Matter Controller path when matter-rs stabilizes.
Strategic framing: RuView contributes the invisible cognition layer
(passive RF presence, breathing/HR, fall, BFLD identity-risk) the
Apple ecosystem cannot natively sense; Apple Home contributes the
consumer-grade discoverability + Siri + automation graph + trust
that an open sensing stack cannot bootstrap. The structural privacy
gate from ADR-118 (only class-2 and class-3 frames cross the Matter
boundary, per ADR-122 §2.4) is what makes this safe to do at all.
Refs ADR-115, ADR-116, ADR-118, ADR-122.
Co-Authored-By: claude-flow <ruv@ruv.net>
ruv