---
name: camstack-probe-gated-cap-registration
description: In camstack's addon-provider-reolink, probe-gated native caps must be re-registered retroactively after the feature probe; constructor registration runs too early.
metadata:
  type: project
---

# Reolink probe-gated native-cap registration (camstack)

In `packages/addon-provider-reolink/src/reolink-camera.ts`, the constructor calls
`registerNativeCapabilities()` **synchronously**, but the `feature-probe`
runtime-state slice (`hasPtz` / `hasIntercom` / `hasDoorbell` / `hasAutotrack`)
is populated **later**, in the kernel-driven `onProbe()` lifecycle hook →
`probeAndPersistFeatures()`.

**Consequence:** any `registerXIfSupported()` helper that gates on
`getProbeFlags<ReolinkProbeFlags>().hasX === true` is a NO-OP during the
constructor pass on a fresh boot (empty slice). It MUST be re-invoked
retroactively at the end of `probeAndPersistFeatures()`, alongside its siblings:
`registerPtzIfSupported()`, `registerPtzAutotrackIfSupported()`,
`registerDoorbellIfSupported()`, `registerIntercomIfSupported()`.

Each helper is idempotent (guards on its own `private xRegistered` flag), so a
warm-rehydrate boot that registered in the constructor just no-ops on the
retroactive call.

**Why this matters:** if a probe-gated cap is never registered, the cap router
finds no provider for the device and the call fails at the **routing layer**
before any provider code runs — producing ZERO provider-side logs. This is how
the "Reolink intercom closes immediately" bug hid: the diagnostic was the
ABSENCE of the `intercom cap registered (...)` log line for Reolink devices,
while Hikvision logged it. Compare provider registration log lines across
vendors when a cap silently does nothing.

**Detection tip:** `grep -c "intercom cap registered"` per provider in the log.
Hikvision logged it 87×; Reolink logged it 0× → cap never registered.

Related: [[baichuan-talk-sequence]].
