@mega-yfue/eufy-sdk 0.0.4 → 0.1.0-beta.0

package/dist/model/capabilities/leak.d.ts

@@ -0,0 +1,43 @@
+import { type Surface } from "./members.js";
+import type { CapabilityModule } from "./types.js";
+/**
+ * Every `leak` feature, declared once — the property schema and the evidence-gated getters derive from here.
+ *
+ * Exported but NOT published: each entry states its wire id and the evidence it was confirmed on,
+ * which the reference site does not carry.
+ * @internal
+ */
+export declare const LEAK_MEMBERS: {
+    /**
+     * The alarm flag, modelled as state even though the sensor announces a leak as a PUSH EVENT rather
+     * than by holding a param — so 1560 is a `guessed` placeholder and the evidence gate will normally
+     * leave this getter uninstalled. The push event is the reliable channel for a leak; this read is
+     * here so the flag has a home once a capture pins a real id.
+     */
+    readonly leakDetected: {
+        readonly param: 1560;
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly provenance: "guessed";
+        readonly description: string;
+    };
+    /**
+     * Unix seconds at which the sensor last checked in — param 1551, the same last-seen id the other
+     * sensor capabilities read. A `timestamp` kind takes no `unit`: the number is an instant, not a
+     * duration, and declaring `unit: "s"` beside it fails the value-kind spec.
+     */
+    readonly lastSeen: {
+        readonly param: 1551;
+        readonly type: "number";
+        readonly kind: "timestamp";
+        readonly provenance: "verified";
+        readonly description: "Last-seen unix timestamp, seconds (verified: param 1551).";
+    };
+};
+/** Bound leak-sensor reads — the object returned by `dev.leak()`. Read-only. */
+export type LeakActions = Surface<typeof LEAK_MEMBERS>;
+/**
+ * `leak` — water/leak (and freeze) sensor. Alarm flag is a placeholder — the T8920 Water & Freeze
+ * sensor reports leak via a push event, not a stable param id.
+ */
+export declare const LEAK: CapabilityModule;

package/dist/model/capabilities/light.d.ts

@@ -0,0 +1,174 @@
+import type { CapabilityModule, CommandContext } from "./types.js";
+import { type Surface } from "./members.js";
+import type { Command } from "../../core/contracts.js";
+/**
+ * The P2P **feature-command ids** this light capability drives. Capability-owned wire vocabulary —
+ * the transport forwards `cmd.param` opaquely and never names them (full id→name catalog in the
+ * generated `transport/p2p/commands.ts`).
+ */
+export declare const LIGHT_CMD: {
+    /** Spotlight momentary on/off; `{time,type,value}` under 1700. ✅ Verified via P2P state readback (3/3). */
+    readonly FLOODLIGHT_SWITCH: 1400;
+    /**
+     * Spotlight brightness 1..100. ✅ SOLVED & verified live (T8425 + T8124): direct-binary command,
+     * 136-byte struct `[u32 ch][u32 value][account_id pad→128]` (value = raw 1..100), NOT a JSON wrapper.
+     */
+    readonly SPOTLIGHT_BRIGHTNESS: 1401;
+    /** Spotlight master enable — distinct from the on/off switch. ✅ Verified live T8124 (same 136-byte direct-binary struct as brightness). */
+    readonly SPOTLIGHT_ENABLE: 1403;
+    /** Spotlight color temperature 0=warm..100=cool. ✅ Verified live T8124 (only tunable-white spotlights respond; T8425 is white-only). */
+    readonly SPOTLIGHT_COLOR_TEMP: 1410;
+    /**
+     * Auto-spotlight = "motion-activated light" — light up when motion fires. ✅ Wire reversed from a live
+     * OUTBOUND P2P capture + replay-verified on T8425 (ch3, 2026-07-13, ON+OFF): the real command
+     * is **cmd 1422**, carried in a `1350` SET_PAYLOAD envelope on the DEVICE channel (mChannel = device
+     * channel, mValue3 0), with a COMPOSITE payload — NOT a bare bool:
+     *   `{brightness:0..100, enable:0|1, latitude:"", longtitude:"" (sic), mode:1, schedule:[], sunset2rise:0, time}`
+     * `enable` is the on/off; `time` = auto-off seconds; `mode`/`schedule`/`sunset2rise` are the scheduling
+     * knobs. See {@link AutoSpotlightOptions}.
+     * NB: the app-JS constant `APP_CMD_SET_LIGHT_CTRL_PIR_SWITCH` (1408) is a RED HERRING for this device —
+     * the T8425 never emits 1408; three 1408 wire attempts all no-op'd. (No `1408` constant is defined — it's
+     * dead; do not add one.)
+     */
+    readonly MOTION_ACTIVATE_LIGHT: 1422;
+};
+/**
+ * Tunables for the "motion-activated light" (auto-spotlight): the spotlight lights up when the camera
+ * detects motion. The device takes the WHOLE config on every write — there's no isolated on/off — so
+ * these carry the scheduling knobs alongside the enable flag. Defaults mirror the app's; the current
+ * values can't be read back, so any field left unset is written as its default rather than preserved.
+ */
+export type AutoSpotlightOptions = {
+    /** Spotlight brightness 1..100 when it triggers (default 50). */
+    brightness?: number;
+    /** Auto-off timer in seconds after the light triggers (default 30). */
+    time?: number;
+    /** Scheduling mode (default 1). */
+    mode?: number;
+};
+/**
+ * Bound spotlight / floodlight controls — the object returned by `dev.light()`.
+ *
+ * The reads and their setters are DERIVED from `LIGHT_MEMBERS`: one declaration per feature gives
+ * the getter, the setter, its argument type and its description. Only what a member table cannot state
+ * is written out below.
+ */
+export type LightActions = Surface<typeof LIGHT_MEMBERS> & {
+    /** Turn the light on. Throws if this model's switch wire is unverified. */
+    on(): Promise<void>;
+    /** Turn the light off. Throws if this model's switch wire is unverified. */
+    off(): Promise<void>;
+    /**
+     * Enable/disable the **motion-activated light** (auto-spotlight): the spotlight lights up when the
+     * camera detects motion.
+     *
+     * ⚠️ This is a COMPOSITE write, and it is WRITE-ONLY: the setting is not reported back in the device's
+     * params, so the current config cannot be read and merged. Calling it with just `on` re-sends the
+     * DEFAULT brightness/auto-off/mode ({@link AutoSpotlightOptions}), overwriting whatever the user set.
+     * To preserve their config, pass the current values in `opts`. That is why this is a method and not a
+     * member — the caller must own the composite.
+     */
+    setAutoSpotlight(on: boolean, opts?: AutoSpotlightOptions): Promise<void>;
+};
+/**
+ * Every `light` feature, declared once. The property schema, the typed getters, the derived setters,
+ * the intent routes and the descriptions all come out of this table.
+ *
+ * Auto-spotlight (1422) is deliberately absent: it is a COMPOSITE write — brightness, auto-off, mode
+ * and enable sent together — and WRITE-ONLY, so a plain toggle would re-send hardcoded defaults and
+ * clobber whatever the user set. It stays the explicit `setAutoSpotlight(on, opts)` method, where the
+ * composite is visible at the call site.
+ *
+ * Exported but NOT published: each entry states its wire id and the evidence it was confirmed on,
+ * which the reference site does not carry.
+ * @internal
+ */
+export declare const LIGHT_MEMBERS: {
+    /**
+     * Whether the lamp is lit RIGHT NOW — the momentary switch, not a setting. Measured on a T8170: 1400
+     * goes to `1` when a client lights the spotlight and back to `0` when that client stops, so the value
+     * tracks whoever is streaming rather than a preference anyone set. The vendor app lights the lamp for a
+     * live view and drops it on quitting.
+     *
+     * So it reads on whenever any client is watching. The setting a user changes and expects to persist
+     * is {@link spotlightEnabled}.
+     *
+     * The switch refuses for a reason a value check cannot give — this model's frame SHAPE is unconfirmed —
+     * so `switchFrame` throws that reason and `bindMembers` turns it into the rejection, rather than
+     * letting the generated "not a valid value" blame a boolean that was never the problem.
+     */
+    readonly isOn: {
+        readonly param: 1400;
+        readonly property: "light";
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly provenance: "verified";
+        readonly description: string;
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+        readonly writeAs: "set";
+        readonly aliases: {
+            readonly on: true;
+            readonly off: false;
+        };
+    };
+    /**
+     * Manual level for the spotlight, 1-100 — the floor is 1 rather than 0 because a 0 reads as "off" and
+     * that is `isOn`'s job. The write is pinned to the level-2 direct-binary frame (`directBinary`),
+     * the only shape captured for it, so a standalone camera that never negotiates a level-2 key cannot
+     * set it even though the getter reads fine.
+     */
+    readonly brightness: {
+        readonly param: 1401;
+        readonly type: "number";
+        readonly unit: "%";
+        readonly kind: "percent";
+        readonly provenance: "verified";
+        readonly min: 1;
+        readonly max: 100;
+        readonly description: "Manual brightness, range 1-100 (1401). Verified live (T8425 + T8124).";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * Warm-to-cool on a 0-100 scale — a `scalar`, not a percentage or a mired value, since 0 is one end
+     * of a range rather than "none". `writeOnly`, so there is a setter and no getter at all: the device
+     * accepts the setting and never reports it back.
+     * Only tunable-white spotlights respond; a white-only model accepts the frame and does nothing.
+     */
+    readonly colorTemp: {
+        readonly param: 1410;
+        readonly type: "number";
+        readonly kind: "scalar";
+        readonly provenance: "verified";
+        readonly writeOnly: true;
+        readonly min: 0;
+        readonly max: 100;
+        readonly description: "Colour temperature, 0 (warm) to 100 (cool). Not reported back, so it is write-only.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * The master enable, one level above {@link isOn}: this decides whether the spotlight may light at all,
+     * where `isOn` is the momentary switch. `writeAs` names the setter `setEnabled` rather than the
+     * `setSpotlightEnabled` the key would derive, since the capability is already the spotlight.
+     *
+     * Reported, so it is a read as well as a write. ✅ Verified live on a T8170: the cloud device list
+     * carries 1403, and its value tracks the vendor app's spotlight setting in both directions — `1` to `0`
+     * when the setting is switched off, `0` to `1` when it is switched back on, so the polarity is direct
+     * and 1 means enabled. The poll reports a param only when its PREVIOUS value differed, so the id is in
+     * the record rather than newly appearing. The param dictionary names it `floodlightTotalSwitch`
+     * (`app:FLOODLIGHT_TOTAL_SWITCH`) and lists the T8170 among its models.
+     *
+     * This is the switch a user changes and expects to STAY changed. {@link isOn} is a different fact:
+     * the lamp being lit right now, driven by whichever
+     * client is streaming — the vendor app lights it for a live view and drops it on quitting.
+     */
+    readonly spotlightEnabled: {
+        readonly param: 1403;
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly provenance: "verified";
+        readonly description: string;
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+        readonly writeAs: "setEnabled";
+    };
+};
+export declare const LIGHT: CapabilityModule;

package/dist/model/capabilities/locate.d.ts

@@ -0,0 +1,63 @@
+import { isTuyaVacuum } from "../device-family.js";
+import { type Surface } from "./members.js";
+import type { CapabilityModule } from "./types.js";
+/**
+ * Every `locate` feature, declared once.
+ *
+ * `locate()` is a `method` rather than a derived setter because its argument is OPTIONAL — the
+ * common call is a bare `locate()` meaning "start beeping" — and a derived setter always takes its
+ * value. Dispatches DP 103 (legacy Tuya) or DP 160 (AIoT) based on which DP the device has reported.
+ *
+ * Exported but NOT published: each entry states its wire id and the evidence it was confirmed on,
+ * which the reference site does not carry.
+ * @internal
+ */
+export declare const LOCATE_MEMBERS: {
+    /**
+     * The find-robot DP read back. `writtenElsewhere` rather than carrying its own `write`, because the
+     * setter is the `locate` method below — its argument is optional, which a derived setter cannot be.
+     * Expect this to read `undefined` on most robots: DP 160 is a momentary trigger, so a device that has
+     * never been asked to beep has no value to report and the evidence gate skips the getter entirely.
+     */
+    readonly locating: {
+        readonly param: 160;
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly provenance: "mega";
+        readonly writtenElsewhere: true;
+        readonly readAliases: readonly [{
+            readonly paramType: 103;
+            readonly available: typeof isTuyaVacuum;
+        }];
+        readonly description: string;
+    };
+    /**
+     * Writes DP 160 (AIoT) — `true` starts the beep, `false` cancels one already sounding. AIoT only:
+     * the legacy Tuya DP 103 is read as an alias above, but its WRITE direction is unconfirmed, so no
+     * Tuya dispatch is offered. The default
+     * argument is what makes this a `method`: a bare `locate()` is the call that matters, and a derived
+     * setter always demands its value.
+     *
+     * That default is also why the argument is named here: it is absent from the function's arity, so the
+     * description would otherwise derive as taking NO arguments and leave the cancel form undeclared.
+     */
+    readonly locate: {
+        readonly method: (deps: import("./members.js").MemberDeps) => (on?: boolean) => Promise<void>;
+        readonly description: string;
+        readonly available: ((ctx: import("./types.js").CommandContext) => boolean) & ((ctx: import("./types.js").CommandContext) => boolean);
+        readonly answers?: true;
+        readonly args: readonly [{
+            readonly name: "on";
+            readonly kind: "boolean";
+            readonly optional: true;
+            readonly description: "False cancels a beep in progress.";
+        }];
+    };
+};
+/**
+ * Bound locate reads and controls — the object returned by `dev.locate()`. The `locating` read is
+ * present only when the device has reported DP 160; `locate()` is always present on a bound device.
+ */
+export type LocateActions = Surface<typeof LOCATE_MEMBERS>;
+/** `locate` — make the robot beep to find it. */
+export declare const LOCATE: CapabilityModule;

package/dist/model/capabilities/lock.d.ts

@@ -0,0 +1,242 @@
+import { type Surface } from "./members.js";
+import type { AvailabilityContext, CapabilityModule, CommandContext } from "./types.js";
+import type { Command, AutoLockSnapshot } from "../../core/contracts.js";
+/**
+ * Setting-id selectors for the compact `ff09-setting-toggle` write — this capability's OWN wire
+ * vocabulary, named not inlined per the capability wire-id convention, so `setRainMode`
+ * below references `LOCK_SETTING_ID.RAIN_MODE` and this module's own spec can import it too, instead
+ * of a bare `7` at either call site.
+ *
+ * Unlike a normal capability id (owned by exactly one layer, crossing into `transport/` only as an
+ * opaque number), this value is a GENUINE duplicate of `transport/ff09.ts`'s `FF09_SETTING_ID.RAIN_MODE`
+ * — the capability↔transport decorrelation rule (`model/` never imports `transport/`) leaves no way to
+ * share one source of truth across the boundary, and no test can cross-check them without violating
+ * that same rule (`guard:decorrelation` forbids any `transport/` import under `src/model`, including
+ * tests). If a future capture revises this id, BOTH copies must be updated by hand.
+ */
+export declare const LOCK_SETTING_ID: {
+    /** One-touch lock toggle. Structurally confirmed via the app's own JS (2026-07-18) — see the module doc. */
+    readonly ONE_TOUCH_LOCK: 1;
+    /** Scramble-passcode toggle. Structurally confirmed via the app's own JS (2026-07-18) — see the module doc. */
+    readonly SCRAMBLE_PASSCODE: 3;
+    /** Wifi-status toggle. Structurally confirmed via the app's own JS (2026-07-18) — see the module doc. */
+    readonly WIFI_STATUS: 5;
+    /** Event-log-enable toggle. Structurally confirmed via the app's own JS (2026-07-18) — see the module doc. */
+    readonly ENABLE_LOG: 6;
+    /** Rain Mode toggle on the T8531 video lock. Verified live 2026-07-18. */
+    readonly RAIN_MODE: 7;
+    /** Privacy-mode toggle. Structurally confirmed via the app's own JS (2026-07-18) — see the module doc. */
+    readonly PRIVACY_MODE: 9;
+    /** One-touch rear-lock toggle. Structurally confirmed via the app's own JS (2026-07-18) — see the module doc. */
+    readonly ONE_TOUCH_REAR_LOCK: 11;
+};
+/**
+ * Bound lock controls — the object returned by `dev.lock()`.
+ *
+ * Everything is DERIVED from `LOCK_MEMBERS`. `lock`/`unlock` and the setting toggles drive any
+ * lock-family actuator — currently the T8531 video smart lock and the T85D0 garage door, which share one
+ * actuation frame. This module emits ONE transport-neutral intent (identity fields only, no wire bytes,
+ * no cipher, no routing key) and names no transport: the command sink routes P2P vs MQTT by the device's
+ * topology, and the chosen transport's command router builds the frame + envelope and re-resolves its own
+ * routing tail. Which pipe it is does not reach `dev.lock()` — its surface is identical either way,
+ * the same way P2P-vs-cloud is hidden for live media.
+ */
+export type LockActions = Surface<typeof LOCK_MEMBERS>;
+/**
+ * Whether the device is reachable over P2P — the topology fact that decides which lock settings exist.
+ * The compact toggles are only known on the P2P video lock; the MQTT garage door does not expose them in
+ * the app, so offering them there would guess a frame shape that likely does not exist.
+ */
+declare const overP2p: (ctx: AvailabilityContext) => boolean;
+/**
+ * Every `lock` feature, declared once.
+ *
+ * The six toggles after `setRainMode` share its confirmed frame SHAPE and are grounded in the app's own
+ * JS, but none has been captured against a real device — so each is `unverified`: DECLARED, so the
+ * capability documents what the lock has, and NOT installed, because a fire-and-forget write that is
+ * wrong looks exactly like success. A caller sees them as optional and learns at compile time that they
+ * are not settable yet; promoting one is a single edit once a capture lands.
+ *
+ * They carry no `param`: a setting id is not a param id, nothing reports these back, and declaring one
+ * would put a wire number where the schema expects a reported value.
+ *
+ * Exported but NOT published: each entry states its wire id and the evidence it was confirmed on,
+ * which the reference site does not carry.
+ * @internal
+ */
+export declare const LOCK_MEMBERS: {
+    /**
+     * The lock's own state, and the weakest thing in this table: 1200 is a `guessed` placeholder because
+     * the lock announces (un)locking as a pushed event rather than holding a param, so the evidence gate
+     * will normally leave this getter uninstalled and `lockState` is the real read. `writtenElsewhere`
+     * points at the `lock`/`unlock` methods — a single `write` cannot express two verbs that carry no
+     * value.
+     */
+    readonly locked: {
+        readonly param: 1200;
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly provenance: "guessed";
+        readonly writtenElsewhere: true;
+        readonly description: "Lock state, true=locked. UNVERIFIED: no stable state param to key off; placeholder id pending verification.";
+    };
+    /**
+     * Cell charge as a percentage, on the same param 1101 every battery device reports. Named `battery`
+     * within this capability rather than deferring to the `battery` capability: a lock resolves as a lock,
+     * so the accessor is `dev.lock().battery`.
+     */
+    readonly battery: {
+        readonly param: 1101;
+        readonly type: "number";
+        readonly unit: "%";
+        readonly kind: "percent";
+        readonly provenance: "verified";
+        readonly description: "Lock battery level 0-100 (verified: param 1101).";
+    };
+    /**
+     * Link quality in dBm as the lock measures it, on the shared param 1141. Both actuation methods here
+     * are fire-and-forget, so a weak link is silent rather than an error.
+     */
+    readonly rssi: {
+        readonly param: 1141;
+        readonly type: "number";
+        readonly unit: "dBm";
+        readonly kind: "dbm";
+        readonly provenance: "verified";
+        readonly description: "Lock signal strength (verified: param 1141 = RSSI).";
+    };
+    /** Lock the deadbolt/door. Fire-and-forget — rejects only on missing member identity, never on a device timeout. */
+    readonly lock: import("./members.js").MethodMember<() => Promise<void>>;
+    /** Unlock the deadbolt/door. Fire-and-forget — rejects only on missing member identity. */
+    readonly unlock: import("./members.js").MethodMember<() => Promise<void>>;
+    /**
+     * Read-modify-write the auto-lock setting: the transport GETs the device's current settings, changes
+     * only `enabled` (+ `delaySeconds` if given — otherwise the current delay is preserved), and writes the
+     * rest back verbatim. Works on both the T8531 video lock and the T85D0 garage/lock, which share the
+     * identical settings frame; confirmed on-device in both directions on both families.
+     *
+     * **Unlike `lock`/`unlock` this can reject on a device TIMEOUT**, not just missing identity — the GET
+     * step is a genuine precondition, so this one is not fire-and-forget.
+     */
+    readonly setAutoLock: import("./members.js").MethodMember<(enabled: boolean, delaySeconds?: number) => Promise<void>>;
+    /**
+     * Toggle Rain Mode — a pure blind write, unlike `setAutoLock`: the compact frame carries only this one
+     * field, so there is no GET pass and it is fire-and-forget. Confirmed on-device end-to-end in both
+     * directions, with the app UI reflecting the new state afterward. P2P video lock only.
+     */
+    readonly setRainMode: import("./members.js").MethodMember<(enabled: boolean) => Promise<void>> & {
+        available: (ctx: CommandContext) => boolean;
+    };
+    /**
+     * Lock the door by a single touch on the pad, with no code. First of the six compact toggles: all
+     * `unverified` (frame shape read out of the app's JS, never captured), so no setter is installed and
+     * `setOneTouchLock` lands optional on the surface — a caller learns at compile time. `writeOnly` too:
+     * nothing reports the setting back, so there is no getter either.
+     */
+    readonly oneTouchLock: {
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly writeOnly: true;
+        readonly unverified: true;
+        readonly available: typeof overP2p;
+        readonly provenance: "apk";
+        readonly description: "One-touch locking (setting-id 1). Wire shape confirmed in the app's own JS, NOT captured.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * Pad anti-shoulder-surfing: the lock asks for extra random digits around the real code so a watcher
+     * cannot read it off worn keys. Same `unverified` + `writeOnly` + P2P-only standing as its five
+     * siblings — declared so the capability documents the lock, not installed.
+     */
+    readonly scramblePasscode: {
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly writeOnly: true;
+        readonly unverified: true;
+        readonly available: typeof overP2p;
+        readonly provenance: "apk";
+        readonly description: "Scramble the passcode entry pad (setting-id 3). Wire shape confirmed in the app's own JS, NOT captured.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * Whether the lock reports its Wi-Fi status — a reporting toggle, not the radio itself, on the app's
+     * own naming. Same `unverified` + `writeOnly` + P2P-only standing as its five siblings; treat the
+     * meaning as the app's label until a capture pins the behaviour.
+     */
+    readonly wifiStatus: {
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly writeOnly: true;
+        readonly unverified: true;
+        readonly available: typeof overP2p;
+        readonly provenance: "apk";
+        readonly description: "Wi-Fi status reporting (setting-id 5). Wire shape confirmed in the app's own JS, NOT captured.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * Whether the lock records its own event history on-device. Same `unverified` + `writeOnly` +
+     * P2P-only standing as its five siblings — the frame shape comes from the app's JS and has never been
+     * driven against hardware.
+     */
+    readonly logEnabled: {
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly writeOnly: true;
+        readonly unverified: true;
+        readonly available: typeof overP2p;
+        readonly provenance: "apk";
+        readonly description: "Event-log recording (setting-id 6). Wire shape confirmed in the app's own JS, NOT captured.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * The lock's own privacy mode — unrelated to the camera capability's privacy burst, which is a
+     * different device, a different wire and a different meaning. Same `unverified` + `writeOnly` +
+     * P2P-only standing as its five siblings.
+     */
+    readonly privacyMode: {
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly writeOnly: true;
+        readonly unverified: true;
+        readonly available: typeof overP2p;
+        readonly provenance: "apk";
+        readonly description: "Lock privacy mode (setting-id 9). Wire shape confirmed in the app's own JS, NOT captured.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * The rear-deadbolt counterpart to `oneTouchLock`, on a lock that has a second bolt — so a model with
+     * one bolt has nothing for it to drive. Last of the six compact toggles and shares their standing
+     * exactly: `unverified`, `writeOnly`, P2P-only, no setter installed.
+     */
+    readonly oneTouchRearLock: {
+        readonly type: "bool";
+        readonly kind: "boolean";
+        readonly writeOnly: true;
+        readonly unverified: true;
+        readonly available: typeof overP2p;
+        readonly provenance: "apk";
+        readonly description: "One-touch rear locking (setting-id 11). Wire shape confirmed in the app's own JS, NOT captured.";
+        readonly write: (v: string | number | boolean, ctx: CommandContext) => Command;
+    };
+    /**
+     * Read the device's current auto-lock settings via a live `GET_SETTINGS` round-trip — the SAME read
+     * `setAutoLock` does internally, exposed standalone with no write attached. Works over BOTH transports.
+     * A genuine request/reply query, not a passive property, so it always talks to the device.
+     *
+     * `answers` for that reason: the returned snapshot IS the point, so it is not a control to offer even
+     * though it takes no arguments — offering it as one would run a round-trip and discard the answer.
+     */
+    readonly getAutoLockState: {
+        readonly needs: "ff09Settings";
+        readonly provided: (provider: import("../../core/contracts.js").Ff09SettingsReader, deps: import("./members.js").MemberDeps) => () => Promise<AutoLockSnapshot>;
+        readonly description: string;
+        readonly requiredCapabilities?: readonly import("../types.js").Capability[];
+        readonly answers: true;
+    };
+};
+/**
+ * `lock` — smart lock. `locked` is the reported lock state, but there's no stable state param to
+ * key off (only pushed via a CommandType-style event), so the param id here is a placeholder.
+ */
+export declare const LOCK: CapabilityModule;
+export {};

package/dist/model/capabilities/manifest.d.ts

@@ -0,0 +1,107 @@
+/**
+ * What a device exposes, as data — one JSON-safe shape per device, with no branch per capability.
+ *
+ * A bound device is fully callable but states nothing about ITSELF from outside the package: neither
+ * what is installed nor what a value means is readable off it. The member table states both, and this
+ * turns that statement into a public, JSON-safe shape: which reads a device actually installed, which
+ * of its actions are offerable, and which events it emits.
+ *
+ * **Derived from the LIVE bound objects, not recomputed from the tables.** The descriptors of the bound
+ * object are the only source that cannot disagree with what `bindMembers` installed — evidence
+ * gates, provider gates and unverified writes are all already applied there. Recomputing the same answer
+ * from the module tables would be a second implementation of the gate, and it would be wrong in exactly
+ * the cases that matter: a media method on a device bound without that provider, a read for a param
+ * the device never reported. The table is joined in only for SEMANTICS (what the value means), which the
+ * bound object does not carry.
+ *
+ * **Never spread, `Object.entries` or `JSON.stringify` a bound object here.** All three invoke its
+ * getters, and a getter with a `decode` calls into the injected codec. Property descriptors only.
+ *
+ * @module model/capabilities/manifest
+ */
+import type { Capability, Codec, PropertyValueType, ResolvedDevice, ValueKind } from "../types.js";
+import type { ActionSpec, AvailabilityContext, CapabilityModule } from "./types.js";
+/** One read installed on a bound capability object — a value the device reports, and what it means. */
+export interface ReadDescriptor {
+    /** The getter's name on the capability object (`dev.battery()?.level` → `level`). */
+    accessor: string;
+    /** The name the same value carries in the device's flat property namespace (`getProperty`). */
+    property: string;
+    /** How the value is stored. */
+    type: PropertyValueType;
+    /** What the value MEANS, as opposed to how it is stored. See {@link ValueKind}. */
+    kind?: ValueKind;
+    /** The unit the device reports the value in, when it has one (`"%"`, `"°C"`, `"dBm"`). */
+    unit?: string;
+    /** The option set, for a value out of a fixed domain. */
+    values?: readonly (string | number)[];
+    /** Labels for {@link values}, keyed by the raw value as a string. */
+    labels?: Readonly<Record<string, string>>;
+    /**
+     * Whether a setter for this value is installed BESIDE the getter on the same object.
+     *
+     * Read off the bound object rather than the schema, so it means "a caller can write this on THIS
+     * device" — a write the device gave no evidence for, or one whose wire is not confirmed, is not
+     * installed and reads `false` here. A value driven by a differently-named method (a pair of frames,
+     * a validating setter) is `false` too and appears under the capability's {@link
+     * CapabilityDescriptor.actions} instead, which is where its signature is described.
+     */
+    writable: boolean;
+    description?: string;
+}
+/**
+ * One offerable action: an {@link ActionSpec} plus the name it is installed under.
+ *
+ * The name is taken from the enumeration rather than carried in the spec, so a renamed method takes its
+ * description with it and cannot leave one behind pointing at nothing.
+ */
+export interface ActionDescriptor extends ActionSpec {
+    name: string;
+}
+/** What one capability exposes on a device — the join of its bound object and its own declaration. */
+export interface CapabilityDescriptor {
+    capability: Capability;
+    /** The fluent accessor this capability is reached under: `dev[accessor]()`. */
+    accessor: string;
+    /** The reads INSTALLED on this device, never the theoretical set. */
+    reads: readonly ReadDescriptor[];
+    /** The installed actions that carry a description. */
+    actions: readonly ActionDescriptor[];
+    /**
+     * Installed, callable actions with no description — usable, but not auto-offerable. Published rather
+     * than hidden so the gap is visible instead of looking like the action doesn't exist.
+     */
+    undescribedActions: readonly string[];
+    /** The semantic event names this capability emits. */
+    events: readonly string[];
+}
+/**
+ * A device's public shape: its identity, its capabilities, and what each of those exposes.
+ *
+ * `bound` is explicit because an unbound model object (no live client) has no bound objects to
+ * enumerate, so its `details` are empty — a caller has to be able to tell "this device exposes nothing"
+ * from "ask again once it is bound".
+ */
+export interface DeviceManifest {
+    sn: string;
+    /** What the user named the device in the app; falls back to {@link modelName} when unnamed. */
+    name: string;
+    /** Model / T-code ("T8410"), when the record states one. */
+    model?: string;
+    /** The model's own display name ("Indoor Cam Pan & Tilt") — the product, not this unit. */
+    modelName: string;
+    codec: Codec;
+    source: ResolvedDevice["source"];
+    bound: boolean;
+    capabilities: readonly Capability[];
+    details: readonly CapabilityDescriptor[];
+}
+/**
+ * Describe the capability objects a device has bound, one descriptor each.
+ *
+ * Parameterised over the module list; the barrel binds it to the real one. A capability the device did
+ * not bind — because it does not have it, or because nothing is bound yet — contributes no descriptor
+ * at all.
+ * @internal
+ */
+export declare function describeBound(modules: readonly CapabilityModule[], bound: Readonly<Record<string, unknown>>, ctx?: AvailabilityContext): CapabilityDescriptor[];