@camstack/addon-pipeline 1.2.286 → 1.2.288

package/dist/{dist-bAVvh6zw.js → dist-CegiJ2Pw.js}

@@ -5360,7 +5360,7 @@ var ZodIssueCode = {
 var ZodFirstPartyTypeKind;
 ZodFirstPartyTypeKind || (ZodFirstPartyTypeKind = {});
 //#endregion
-//#region ../types/dist/sleep-De1BvmWo.mjs
+//#region ../types/dist/sleep-COWaSCAi.mjs
 /**
 * The audio chunk plane's byte format, and the ONE expansion from a coded
 * window to float samples (D455).
@@ -8740,6 +8740,24 @@ object({
 		unreachable: number()
 	})
 });
+/** The wire shape of {@link PeerBytesTicket} — see the type for what it is. */
+var PeerBytesTicketSchema = object({
+	/** `http://127.0.0.1:<port>/<token>`. One `GET` takes it. */
+	url: string().min(1),
+	/**
+	* The HOST node this URL means something on — the hub or a named agent,
+	* never a runner. {@link AddonPeerBytes.open} compares it to its own and
+	* refuses `cross-node` by name when they differ, without dialling.
+	*/
+	hostNodeId: string().min(1),
+	expiresAtMs: number().int().nonnegative(),
+	/**
+	* What the producer DECLARED the body to be, when it knows — `null` when it
+	* does not. Never `0` for unknown (D393): a consumer sizing a bound off this
+	* must be able to tell "the producer did not say" from "the body is empty".
+	*/
+	declaredBytes: number().int().nonnegative().nullable()
+});
 /**
 * Adoption job — the background form of `device-adoption.adopt`.
 *
@@ -15719,6 +15737,97 @@ method(object({ integrationId: string() }), object({ filters: array(AdoptionFilt
 	auth: "admin"
 });
 /**
+* device-admin-link — "this device has a management page of its own, and here
+* is its address".
+*
+* ## Why this is not a `deviceConfig` cap
+*
+* There is nothing to edit. A `deviceConfig` cap (D14) exists so the framework
+* can DERIVE a settings form from `getOptions` + `getStatus` and route a flat
+* patch back through a setter; it costs a `builderId` reducer in
+* `device-config-contribution.ts` and a `*-config-schema.ts` beside it, and it
+* renders a form section. This cap answers ONE question with ONE read and
+* renders a button. Nothing about it is a form, so it carries no `deviceConfig`
+* block, no `settings`, no `runtimeState` and no reducer — exactly like
+* `reboot`, the other pure-RPC device-native cap.
+*
+* ## Absent, and the difference between "no page" and "we cannot say"
+*
+* The two are answered at DIFFERENT layers, on purpose:
+*
+*  - **"We cannot say"** → the provider never registers the cap for that
+*    device. A VeSync humidifier, a Petkit feeder, a Dreame vacuum and a Dreo
+*    fan are reached only through a vendor cloud; there is no address to hand
+*    out and no page to open. A Tuya plug, a Wyze camera and a Gree air
+*    conditioner DO have a LAN IP, and still have no HTTP management page
+*    behind it. None of them register, so `deviceManager.getBindings` never
+*    lists the cap and no surface asks.
+*  - **"This device has no page, and I know that"** → the provider registers
+*    and `getAdminLink` returns `null`. This is the answer for a device whose
+*    sibling DOES have a page: a Reolink battery camera reached over UDP by
+*    `uid` with a blank `host`, an Ecowitt gateway configured in `listener`
+*    transport, a Home Assistant broker authenticated by supervisor token
+*    (which carries no `baseUrl` at all).
+*
+* Both draw NOTHING. A button that opens a browser error is worse than no
+* button, and D62 is the same rule from the other side: an off switch is
+* reported off, never made to look broken. There is no third state where the
+* UI renders a disabled button "because the device might have a page".
+*
+* ## The URL never carries credentials
+*
+* Not in userinfo, not in a query string. Every provider builds through
+* `buildDeviceAdminUrl` (`device-admin-link-url.ts`), which takes host, port,
+* scheme and path as separate arguments — there is no parameter a secret could
+* arrive in — and re-checks its own output for the `scheme://user:pass@` shape
+* that `scripts/check-no-credential-urls-in-fixtures.ts` bans from recorded
+* output. `scripts/check-admin-link-builder-is-the-only-url-source.ts` is what
+* keeps providers from hand-rolling one anyway.
+*
+* This matters here more than anywhere else in the repo, because every provider
+* that knows a device's host knows its PASSWORD too: `{ host, port, username,
+* password }` sit in one object on Hikvision, Amcrest, Reolink and ONVIF alike,
+* and `http://admin:hunter2@192.168.50.139/` is a URL a browser accepts. The
+* camera's own page will ask for its own login. That is correct, and pre-
+* filling it is the operator's business, not ours.
+*
+* ## It is a LAN fact
+*
+* The URL addresses the device where the NODE can see it. It is not proxied,
+* not made reachable from outside, and not sent anywhere. A surface renders it
+* as a link the operator's own browser follows, on the operator's own network,
+* or renders nothing.
+*/
+/**
+* Whose page is it. The distinction is for the OPERATOR, who needs to know
+* before clicking whether he is about to land on a camera's own web server or
+* inside Home Assistant.
+*/
+var AdminLinkTargetEnum = _enum(["device", "integration"]);
+var DeviceAdminLinkSchema = object({
+	/**
+	* Absolute `http(s)://` URL. Built by `buildDeviceAdminUrl` and therefore
+	* free of userinfo and of any credential-shaped query key.
+	*/
+	url: string(),
+	/**
+	* What the surface calls it — "Web UI", "Home Assistant", "UniFi controller".
+	* The PROVIDER names it, because only the provider knows what the page is;
+	* a UI that invented the label from the addon id would call the Home
+	* Assistant device page "Provider Homeassistant".
+	*/
+	label: string(),
+	target: AdminLinkTargetEnum,
+	/**
+	* Host the URL points at, without scheme, port or path — for the tooltip, so
+	* an operator can see WHERE the button goes before he follows it. Redundant
+	* with `url` by construction; carried separately so no surface has to parse
+	* a URL to show it.
+	*/
+	host: string()
+});
+method(object({ deviceId: number().int().nonnegative() }), DeviceAdminLinkSchema.nullable(), { auth: "admin" });
+/**
 * `device-export` — collection cap for addons that export camstack
 * devices to external ecosystems (HomeAssistant via MQTT discovery,
 * HomeKit/HAP, Alexa Smart Home, …).
@@ -27225,6 +27334,7 @@ _enum([
 	"sleeping",
 	"camera-refused",
 	"no-keyframe",
+	"decode-failed",
 	"no-catalog-row",
 	"unsupported",
 	"unknown-device",
@@ -27481,6 +27591,27 @@ var ClipPlaybackSchema = object({
 */
 var ClipWakeSchema = _enum(["authorised"]);
 /**
+* Hard ceiling on ONE {@link videoclipsCapability.methods.offerClipBytes}
+* transfer — ten times {@link VIDEOCLIPS_MAX_READ_BYTES}, and the reasoning is
+* not "ten times more comfortable".
+*
+* The inline bound is set by what is HELD: a base64 envelope is the payload at
+* ~1.33× in the provider AND the same again in the caller, so 50 MiB of clip
+* is ~133 MiB of heap across two processes. Over `peerBytes` the consumer
+* holds one socket chunk at a time and writes straight through to the export
+* file, so its contribution is flat whatever the clip weighs. What is left is
+* the PRODUCER's own copy, and that is a property of how each provider makes a
+* clip rather than of this transport: Hikvision's fetch writes to a scratch
+* FILE and offers it (nothing is held), Reolink's cmd-5 transfer is collected
+* in memory and offered from there (one copy, the one it already had).
+*
+* So this number bounds the worst provider, not the transport, and it is named
+* separately so that lifting it is a statement about a provider rather than
+* about clips. Above it the provider REFUSES with the size in the message and
+* never truncates: half a video is worse than an honest refusal.
+*/
+var VIDEOCLIPS_MAX_OFFER_BYTES = 500 * 1024 * 1024;
+/**
 * A clip's finished bytes, inline — the twin of `recordingExport.readExportBytes`.
 *
 * `bytes` is the DECODED length, so nobody infers it from the base64 length,
@@ -27512,6 +27643,32 @@ var ClipBytesSchema = object({
 	durationMs: number().positive().optional()
 });
 /**
+* Where a clip's finished bytes can be TAKEN (D613) — the answer to
+* {@link videoclipsCapability.methods.offerClipBytes}.
+*
+* Everything {@link ClipBytesSchema} carries except the bytes themselves, plus
+* the one-shot ticket that leads to them. The metadata is answered BEFORE the
+* transfer on purpose: a consumer learns which twin it got, what to call the
+* file and how long the clip runs without having to read a byte, so a decision
+* it would make on that metadata (a wrong twin, an implausible duration) costs
+* no transfer at all.
+*/
+var ClipBytesOfferSchema = object({
+	/**
+	* One shot, seconds-long, loopback, on the PROVIDER's own host. Open it with
+	* `ctx.peerBytes.open(...)`, which refuses a ticket from another node by
+	* name rather than dialling a port that means something else here.
+	*/
+	ticket: PeerBytesTicketSchema,
+	contentType: string(),
+	/** Suggested filename, extension included. */
+	name: string(),
+	/** Which twin was actually served — see {@link ClipBytesSchema.served}. */
+	served: CamProfileSchema,
+	/** See {@link ClipBytesSchema.durationMs}. Absent when nothing measured it. */
+	durationMs: number().positive().optional()
+});
+/**
 * Where a clip's STREAM can be dialled (D597) — the answer to
 * {@link videoclipsCapability.methods.dialClipStream}.
 *
@@ -27587,6 +27744,73 @@ var ClipStreamDialSchema = object({
 	/** Why `servedAudio` is `none` although sound was asked for. */
 	audioReason: ClipStreamAudioReasonSchema.optional()
 });
+/**
+* The playback rates a clip can be DELIVERED at, ascending, always with `1`.
+*
+* These are the BROKER's: it re-paces frames it has already demuxed — the
+* `MonotonicClock` divides source elapsed time by the factor and the pacer
+* pushes that much faster — so the domain is the recorded one, {0} ∪ [0.25, 4],
+* and this is the discrete ladder drawn from it. `1.5` is in it because a
+* re-pacer has no reason to refuse it.
+*
+* `8` and `16` are deliberately NOT here. They are the CAMERA's own
+* `<playSpeed>` (Reolink cmd-5 replay), a different mechanism, still unwired
+* (D597, D600) — a rate change there costs a new dial and a new stream, and
+* the camera's 8x would need a resample the clip audio path has no decoder
+* for. Offering them today accepts a rate and delivers 1x, which is the whole
+* defect this list exists to end (D612). When `playSpeed` IS wired its rates
+* join THIS array — a second list elsewhere is the second authority D62
+* forbids.
+*
+* Every entry must survive the broker's `clampPlaybackRate` unchanged: a set
+* that offers what the clamp then moves is the same lie one step later.
+*/
+var CLIP_BROKER_PACED_RATES = [
+	.25,
+	.5,
+	1,
+	1.5,
+	2,
+	4
+];
+/**
+* What a surface may DRAW for this provider's clips — the answer to
+* {@link videoclipsCapability.methods.getPlaybackOptions} (D612).
+*
+* The envelope is a PROVIDER fact, not a clip fact, and that is measured, not
+* assumed: the broker's `chooseClipPath` reads exactly two inputs — whether
+* `dialClipStream` and `readClipBytes` are wired — and both are constants of
+* the broker's own closure over the provider's methods. The `profile` it is
+* handed is explicitly not read. So every clip of a provider is served the
+* same way, and a per-clip channel carried a value that could not vary. The
+* per-clip `clipTransport` server message was removed for exactly that reason.
+*
+* Queried per camera, before a clip is picked, so a control is rendered or
+* DISABLED rather than offered and refused at play time (D62: a disabled
+* control reads as unavailable, one that undoes the gesture reads as broken).
+*/
+var ClipPlaybackOptionsSchema = object({
+	/**
+	* How this provider's clips reach the player. `stream` is the provider's
+	* forward-only fMP4 (D597); `file` is one bounded by-handle fetch of the
+	* whole clip, `stbl` indexed (D575).
+	*/
+	transport: _enum(["stream", "file"]),
+	/** `forward` = only ahead of the playhead. `free` = anywhere. */
+	seek: _enum(["forward", "free"]),
+	/** Frame-step BACKWARD is meaningful. Forward always is. */
+	stepBack: boolean(),
+	/** Whether the scrub gesture is served, as opposed to refused by name. */
+	scrub: boolean(),
+	/**
+	* The rates that can be delivered, ascending, always containing `1`. The
+	* viewer draws its picker from this and from nothing else — a constant it
+	* keeps instead is the second authority that produced the defect: `8` and
+	* `16` were offered, the broker clamped them to `4`, and no line anywhere
+	* said so. `0` is not a member: pause is the absence of a rate.
+	*/
+	rates: array(number().positive()).min(1).readonly()
+});
 var ClipSourceAvailabilitySchema = object({
 	state: _enum([
 		"ok",
@@ -27765,14 +27989,18 @@ var videoclipsCapability = {
 		*
 		* `getClipPlayback` is the right answer for a player: it hands back a URL
 		* on a plane the hub serves `access:'authenticated'`, which a browser and a
-		* viewer session satisfy. It is the wrong answer for another ADDON. There
-		* is no addon→addon byte transport in this framework — `AddonDataPlane`
-		* only lets an addon SERVE, on `127.0.0.1` behind a per-listener secret
-		* only the hub may present — so a recorder that wants a camera's clip
-		* cannot fetch that URL. This method is the one seam that exists for it,
-		* and it is deliberately the same shape (and the same bound) as
-		* `recordingExport.readExportBytes`, which exists for the mirror-image
-		* reason.
+		* viewer session satisfy. It is the wrong answer for another ADDON: the
+		* hub's proxy in front of that plane takes only a user credential, which
+		* an addon does not hold, so a recorder that wants a camera's clip cannot
+		* fetch that URL. This method is the shape that answer forced — the same
+		* one (and the same bound) as `recordingExport.readExportBytes`.
+		*
+		* **It is no longer the only seam.** Until D613 there was no addon→addon
+		* byte transport at all; there is now
+		* ({@link offerClipBytes}, over `ctx.peerBytes`), it holds nothing on
+		* either side, and it is what a clip EXPORT uses. This method remains for
+		* a consumer that genuinely wants the bytes in hand, and as the named
+		* fallback for a provider not yet redeployed.
 		*
 		* Routing needs no `provider` pin: the id is source-prefixed and
 		* self-contained, so `device-collection-dispatch.ts` rule 3 hands the call
@@ -27839,6 +28067,65 @@ var videoclipsCapability = {
 			auth: "protected"
 		}),
 		/**
+		* Where this clip's finished bytes can be TAKEN — the by-handle read a
+		* clip EXPORT pulls, over the addon→addon byte transport (D613).
+		*
+		* This is {@link readClipBytes} with the envelope removed. Same gates,
+		* same vocabulary, same completion rules, same `served` contract — the
+		* only difference is that the bytes travel over a one-shot loopback
+		* socket instead of inside a base64 field, so neither side holds the
+		* payload whole and the 50 MiB refusal on a long `high` twin stops
+		* existing. The bound that remains is
+		* {@link VIDEOCLIPS_MAX_OFFER_BYTES}, and it bounds the PRODUCER's own
+		* copy rather than the transport.
+		*
+		* **The ticket is loopback and same-host.** A provider on an agent mints a
+		* URL that means nothing on the hub, and `ctx.peerBytes.open` refuses it
+		* `cross-node` by name rather than dialling whatever else holds that port
+		* here. A consumer that can be on the other side of a node boundary from
+		* its provider must be able to read that refusal and say so; it must not
+		* treat it as "no bytes".
+		*
+		* **A ticket is a one-shot bearer credential with a seconds-long life.**
+		* Take it immediately, never persist it, never log its `url`. An untaken
+		* ticket costs the provider one map entry until its TTL, and outstanding
+		* tickets are bounded — which is also what makes a per-frame misuse of
+		* this method refuse by name rather than work slowly (D9/D18: this is a
+		* by-handle fetch of finished media, not a frame pipe).
+		*
+		* Optional on the provider for the same reason `readClipBytes` is: a
+		* source with no camera socket behind it has no bytes. A provider that
+		* predates this method answers `NOT_IMPLEMENTED`, and a consumer may fall
+		* back to `readClipBytes` — but it says so in the log, with the deploy
+		* hint, because that fallback re-imposes the 50 MiB refusal and an
+		* operator who sees `too-large-to-transfer` after this shipped is looking
+		* at a stale addon, not at a clip that cannot be exported.
+		*/
+		offerClipBytes: optionalMethod(object({
+			deviceId: number(),
+			clipId: string().min(1),
+			/** WHICH provider holds the bytes — see `readClipBytes.provider`. */
+			provider: string().min(1),
+			/** Which twin — `low | mid` → the sub file, `high` → the main twin. */
+			profile: CamProfileSchema.optional(),
+			/**
+			* The CALLER's byte bound, so an over-size clip is refused before the
+			* camera is touched rather than after. Capped by
+			* {@link VIDEOCLIPS_MAX_OFFER_BYTES} whatever is passed; absent means
+			* that ceiling.
+			*/
+			maxBytes: number().int().positive().optional(),
+			/**
+			* The operator's authorisation to wake a sleeping camera for this
+			* read. Absent — the default — means a sleeping standalone battery
+			* camera is REFUSED by name, before any session is opened.
+			*/
+			wake: ClipWakeSchema.optional()
+		}), ClipBytesOfferSchema, {
+			kind: "query",
+			auth: "protected"
+		}),
+		/**
 		* Where this clip's STREAM can be dialled (D597) — the forward-only
 		* fMP4 the provider writes from the first muxed byte, for the broker to
 		* play through the same WebRTC session as recorded footage, with the
@@ -27875,6 +28162,36 @@ var videoclipsCapability = {
 		}), ClipStreamDialSchema, {
 			kind: "query",
 			auth: "protected"
+		}),
+		/**
+		* What a surface may DRAW for this provider's clips: the rates it can be
+		* played at, whether scrub is served, how far a position may be moved,
+		* and whether a backward frame-step means anything (D612).
+		*
+		* **The only authority.** The per-clip `clipTransport` server message
+		* that used to carry the same answer was removed: the broker's transport
+		* choice reads nothing that varies per clip, so the clip level had no
+		* information the provider does not already have, and two channels that
+		* can disagree are worse than one (D62).
+		*
+		* Asked per camera and per provider, so it must stay CHEAP — it is a
+		* statement about wiring, answered from a constant, never a call to the
+		* camera. A provider answers with one of {@link CLIP_PLAYBACK_OPTIONS}
+		* and never composes an envelope of its own.
+		*
+		* Optional, and absence is load-bearing: a provider that has not answered
+		* has not restricted anything, and a viewer reads it as the freedom it
+		* always had. See D612 on the rollout order that absence implies.
+		*/
+		getPlaybackOptions: optionalMethod(object({
+			deviceId: number(),
+			/** WHICH provider to ask — the `addonId` a {@link ClipSourceSchema}
+			*  row carries. Required for the same reason `listClips` requires it:
+			*  a collection cap has no "the bound one" to resolve to (D554). */
+			provider: string().min(1)
+		}), ClipPlaybackOptionsSchema, {
+			kind: "query",
+			auth: "protected"
 		})
 	}
 };
@@ -29598,6 +29915,307 @@ DeviceType.Camera, method(object({ deviceId: number() }), DayNightOptionsSchema)
 	auth: "admin"
 });
 /**
+* Vendor-neutral **onboard** recording + storage cap — what the CAMERA
+* writes to the CAMERA's own card, on the camera's own schedule.
+*
+* This is NOT `recording.cap.ts`. That one is CamStack's recorder: our
+* footage ledger, our storage locations, our retention. This one has a
+* different authority — the camera's firmware — and per D62 it stores
+* nothing of its own. Every value here is read from the camera and every
+* write goes back to the camera; there is no CamStack-side mirror that
+* could disagree with the device.
+*
+* ## One shape, two firmwares
+*
+* Measured 2026-09-22 against the live fleet:
+*
+* | fact | Hikvision (ISAPI) | Reolink (Baichuan) |
+* | --- | --- | --- |
+* | storage | `ContentMgmt/Storage` `<hdd>` rows: status, capacity, freeSpace (MB) | `getHddInfoList` (cmd 102): `mount`, `format`, `capacity` GB + `capacityM` MB remainder |
+* | tracks | several (101 **and** 103 on both 1436 and 3833), each with its own schedule | one per channel |
+* | schedule | per track, 7 `ScheduleAction` blocks: DayOfWeek + TimeOfDay range + ONE `ActionRecordingMode` | per trigger type, a 168-char weekly HOUR mask |
+* | triggers | `CMR`, `MOTION` | `Normal`, `MD`, `people`, `vehicle`, `dog_cat`, `crossline`, `intrude`, `loitering` |
+* | pre-record | `PreRecordTimeSeconds` | `preRecordTime` |
+* | post-record | `PostRecordTimeSeconds` | `recordDelayTime` |
+* | overwrite | per track `LoopEnable` | `cycle`, with `cycleList` enumerating the accepted values |
+* | segment length | not exposed on V5.7.1 | `packageTime` (minutes) |
+*
+* The two schedule models look different and are the same thing in
+* different coordinates: both answer "for this trigger, during which
+* weekly windows does the camera record". {@link RecordWindow} is that
+* question in one shape — Hikvision's ranges map straight onto it,
+* Reolink's mask expands into hour-aligned windows.
+*
+* ## Union, not intersection
+*
+* **The same fields exist on every camera.** What differs per device is
+* which VALUES that device accepts, and that is what {@link
+* RecordingOnboardOptions} reports — a `{ readable, writable, reason }`
+* per field plus the schedule's own limits. A control a camera cannot
+* honour is rendered DISABLED WITH ITS REASON, never missing and never
+* dead: disabled must not look like broken.
+*
+* ## Refusal by name
+*
+* A write a camera cannot honour is refused with a sentence the operator
+* can read — never accepted and dropped. Both providers refuse through
+* {@link describeOnboardRefusal}, so the vocabulary is one function and
+* one test, not two hand-written vendor opinions.
+*
+* Follows the D14 `deviceConfig` archetype (see `stream-params.cap.ts`):
+* `getOptions` advertises per-camera availability, `getStatus` (auto-
+* injected from `status`) reports the live values, and a single
+* `setSettings` mutation applies a partial change. No hand-written
+* settings-contribution methods.
+*/
+/**
+* What makes the camera start recording during a window.
+*
+* The union of both vendors' vocabularies. `continuous` is Hikvision's
+* `CMR` and Reolink's `Normal`; `motion` is `MOTION` / `MD`. The
+* object-class triggers are Reolink-only today and the smart-event ones
+* (`lineCrossing`, `intrusion`, `loitering`) are Reolink-only on the
+* firmwares measured — a camera that cannot record on a trigger simply
+* does not list it in `options.schedule.triggers`, and a window naming
+* it is REFUSED, not dropped.
+*/
+var RecordTriggerSchema = _enum([
+	"continuous",
+	"motion",
+	"person",
+	"vehicle",
+	"animal",
+	"lineCrossing",
+	"intrusion",
+	"loitering",
+	"alarmInput"
+]);
+/**
+* One weekly recording window: "on `day`, from `startMinute` to
+* `endMinute`, record on `trigger`".
+*
+* `day` is 0 = Monday … 6 = Sunday (ISO order, which is also the order
+* both firmwares enumerate). Minutes are local camera time since
+* midnight; `endMinute` may be 1440, meaning end of day — that is
+* Hikvision's literal `24:00` and Reolink's 24th mask slot, and
+* collapsing it to 0 would turn a whole-day window into an empty one.
+*/
+var RecordWindowSchema = object({
+	trigger: RecordTriggerSchema,
+	day: number().int().min(0).max(6),
+	startMinute: number().int().min(0).max(1439),
+	endMinute: number().int().min(1).max(1440)
+});
+/** Status of one physical volume, as the camera itself describes it. */
+var OnboardStorageVolumeSchema = object({
+	/** The camera's own id for the volume (`hdd/id`, Reolink `HddInfo/number`). */
+	id: string(),
+	/** The camera's own name for it, when it gives one (`hddName`). */
+	label: string().optional(),
+	status: _enum([
+		"ok",
+		"unformatted",
+		"error",
+		"offline",
+		"unknown"
+	]),
+	/**
+	* Total size in MB, or **null when the camera did not say**.
+	*
+	* Never 0 for an unreadable value: a measurement that failed is not a
+	* measurement (D393), and a card whose size is unknown must not be
+	* rendered as a card of size zero.
+	*/
+	capacityMb: number().nullable(),
+	/**
+	* Free space in MB, or null when unknown.
+	*
+	* **Not a proxy for "has footage".** Measured 2026-09-22: 1436 and
+	* 1439 both report exactly 11776 MB free — the fixed reserve a looping
+	* card converges on once it has wrapped. At loop steady state the
+	* number is identical whether the camera recorded yesterday or stopped
+	* a month ago.
+	*/
+	freeMb: number().nullable(),
+	/** True when the camera reports the volume writable (`property` RW). */
+	writable: boolean().optional()
+});
+object({
+	storage: discriminatedUnion("kind", [
+		object({
+			kind: literal("present"),
+			volumes: array(OnboardStorageVolumeSchema)
+		}),
+		object({
+			kind: literal("absent"),
+			reason: string()
+		}),
+		object({
+			kind: literal("unknown"),
+			reason: string()
+		})
+	]),
+	tracks: array(object({
+		id: string(),
+		enabled: boolean(),
+		isVideo: boolean(),
+		/** From the camera's own track description. Null when it does not say. */
+		codec: string().nullable(),
+		resolution: string().nullable(),
+		/** Per-track overwrite flag, where the firmware keeps it per track. */
+		overwriteWhenFull: boolean().nullable()
+	})),
+	/**
+	* The track the write path targets — the enabled VIDEO one. Null when
+	* no track could be identified, which is itself a refusal reason.
+	*/
+	primaryTrackId: string().nullable(),
+	/** Master "record to the card at all" switch. */
+	enabled: boolean().nullable(),
+	overwriteWhenFull: boolean().nullable(),
+	preRecordSec: number().nullable(),
+	postRecordSec: number().nullable(),
+	/** Length of one recorded file, in minutes. */
+	segmentMinutes: number().nullable(),
+	/** The primary track's weekly windows, flattened. */
+	windows: array(RecordWindowSchema),
+	/**
+	* How many windows the camera described that CamStack could NOT read —
+	* an unrecognised trigger, an unparseable clock, a weekday it does not
+	* name.
+	*
+	* A dropped window is work the reader threw away, and a schedule that
+	* silently shows fewer rows than the camera holds is how an operator
+	* saves back a schedule shorter than the one they were looking at
+	* (D391). Non-zero means the window list is INCOMPLETE and a write
+	* that replaces it would delete what was not shown — which is why a
+	* provider reporting a non-zero count also reports the schedule as not
+	* writable.
+	*/
+	unreadableWindows: number(),
+	/**
+	* The camera is scheduled to record and has NO usable storage.
+	*
+	* A first-class fact because it is the fleet's most common silent
+	* defect: measured 2026-09-22, 1441 and 3831 are both motion-recording
+	* to a card that is not there. Neither the schedule nor the storage
+	* read says anything wrong on its own; only the pair does.
+	*/
+	recordingToNowhere: boolean(),
+	lastFetchedAt: number()
+});
+/** Numeric range descriptor — `{ min, max, step }` per the getOptions convention. */
+var RangeSchema = object({
+	min: number(),
+	max: number(),
+	step: number()
+});
+/**
+* The values a camera actually takes for a numeric field, when they are a SET
+* rather than a range.
+*
+* `{min,max,step}` cannot say what these two firmwares do. Measured on 1436
+* (I91DN) on 2026-09-22 by writing each value and reading it back:
+*
+* - pre-record: `0, 5, 10, 15, 20, 25, 30` and `2147483647` (INT32_MAX, the
+*   camera's "no limit" — `-1` and `4294967295` both land on it);
+* - post-record: `5, 10, 30, 60, 120, 300, 600`.
+*
+* Neither is expressible as a step: the first has a sentinel two billion away
+* from its neighbours, the second doubles and then jumps. A range that tried
+* would forbid values the camera takes AND permit values it silently replaces
+* with 5 — wrong in both directions at once.
+*
+* `sentinel` names the member that is not a duration, so a surface can render
+* "no limit" instead of `2147483647` seconds.
+*/
+var AllowedValuesSchema = object({
+	values: array(number()).min(1),
+	sentinel: object({
+		value: number(),
+		meaning: _enum(["no-limit", "disabled"])
+	}).optional()
+});
+/**
+* Per-field availability on ONE camera.
+*
+* The field exists on every camera — this says whether this one can be
+* read and whether it can be written, and `reason` says why not when
+* either is false. The UI renders the control DISABLED with the reason
+* rather than hiding it, so a limitation is legible instead of looking
+* like a missing feature.
+*/
+var OnboardFieldSupportSchema = object({
+	readable: boolean(),
+	writable: boolean(),
+	/** Required whenever `readable` or `writable` is false. */
+	reason: string().optional()
+});
+/** What this camera's schedule model can express. */
+var OnboardScheduleSupportSchema = object({
+	support: OnboardFieldSupportSchema,
+	/**
+	* The smallest time step the camera can express, in minutes.
+	*
+	* Hikvision takes arbitrary minutes (`00:05:00`–`23:57:00` observed on
+	* 1436's track 103). Reolink's schedule is a 7×24 HOUR mask, so 60. A
+	* window whose edges are not a multiple of this is REFUSED rather than
+	* quietly rounded — rounding is how an operator's 06:30 becomes 06:00
+	* and nothing says so.
+	*/
+	granularityMinutes: number(),
+	/** Triggers this camera can record on. A window naming another is refused. */
+	triggers: array(RecordTriggerSchema),
+	/**
+	* False when the camera stores ONE trigger per time range, so two
+	* windows overlapping on the same day cannot carry different triggers.
+	* True on Reolink, whose mask is per-trigger and independent.
+	*/
+	supportsOverlappingTriggers: boolean()
+});
+var RecordingOnboardOptionsSchema = object({
+	enabled: OnboardFieldSupportSchema,
+	overwriteWhenFull: OnboardFieldSupportSchema,
+	preRecordSec: OnboardFieldSupportSchema,
+	preRecordSecRange: RangeSchema.optional(),
+	/** Preferred over the range when the camera takes a SET, not a span. */
+	preRecordSecAllowed: AllowedValuesSchema.optional(),
+	postRecordSec: OnboardFieldSupportSchema,
+	postRecordSecRange: RangeSchema.optional(),
+	/** Preferred over the range when the camera takes a SET, not a span. */
+	postRecordSecAllowed: AllowedValuesSchema.optional(),
+	segmentMinutes: OnboardFieldSupportSchema,
+	segmentMinutesRange: RangeSchema.optional(),
+	/** Preferred over the range when the camera takes a SET, not a span. */
+	segmentMinutesAllowed: AllowedValuesSchema.optional(),
+	schedule: OnboardScheduleSupportSchema
+});
+/**
+* A partial change. Every field optional.
+*
+* Unlike the other `deviceConfig` caps, a provider here does **NOT**
+* silently ignore a field it cannot support — it refuses, by name,
+* through {@link describeOnboardRefusal}. Silence on a recording setting
+* is the failure D62 exists to prevent: the operator believes the camera
+* is recording the way the form says, and it is not.
+*/
+var RecordingOnboardPatchSchema = object({
+	enabled: boolean().optional(),
+	overwriteWhenFull: boolean().optional(),
+	preRecordSec: number().optional(),
+	postRecordSec: number().optional(),
+	segmentMinutes: number().optional(),
+	/** The complete new window set for the primary track — not a delta. */
+	windows: array(RecordWindowSchema).optional()
+});
+DeviceType.Camera, method(object({ deviceId: number() }), RecordingOnboardOptionsSchema), method(object({
+	deviceId: number(),
+	settings: RecordingOnboardPatchSchema
+}), _void(), {
+	kind: "mutation",
+	auth: "admin"
+});
+/**
 * Generic device-level status snapshot. Auto-registered by `BaseDevice`
 * for every device, regardless of provider — the kernel needs a uniform
 * cap-keyed slice for the basic device flags every consumer expects to
@@ -39159,6 +39777,12 @@ Object.freeze({
 		addonId: null,
 		access: "view"
 	},
+	"deviceAdminLink.getAdminLink": {
+		capName: "device-admin-link",
+		capScope: "device",
+		addonId: null,
+		access: "view"
+	},
 	"deviceAdoption.adopt": {
 		capName: "device-adoption",
 		capScope: "system",
@@ -43197,6 +43821,24 @@ Object.freeze({
 		addonId: null,
 		access: "view"
 	},
+	"recordingOnboard.getOptions": {
+		capName: "recording-onboard",
+		capScope: "device",
+		addonId: null,
+		access: "view"
+	},
+	"recordingOnboard.getStatus": {
+		capName: "recording-onboard",
+		capScope: "device",
+		addonId: null,
+		access: "view"
+	},
+	"recordingOnboard.setSettings": {
+		capName: "recording-onboard",
+		capScope: "device",
+		addonId: null,
+		access: "create"
+	},
 	"recordingSignal.getStatus": {
 		capName: "recording-signal",
 		capScope: "device",
@@ -44661,6 +45303,12 @@ Object.freeze({
 		addonId: null,
 		access: "view"
 	},
+	"videoclips.getPlaybackOptions": {
+		capName: "videoclips",
+		capScope: "device",
+		addonId: null,
+		access: "view"
+	},
 	"videoclips.listClips": {
 		capName: "videoclips",
 		capScope: "device",
@@ -44673,6 +45321,12 @@ Object.freeze({
 		addonId: null,
 		access: "view"
 	},
+	"videoclips.offerClipBytes": {
+		capName: "videoclips",
+		capScope: "device",
+		addonId: null,
+		access: "view"
+	},
 	"videoclips.readClipBytes": {
 		capName: "videoclips",
 		capScope: "device",
@@ -45083,6 +45737,11 @@ Object.freeze({
 		form: "single",
 		optional: true
 	}],
+	"deviceAdminLink.getAdminLink": [{
+		name: "deviceId",
+		form: "single",
+		optional: false
+	}],
 	"deviceAdoption.release": [{
 		name: "camDeviceId",
 		form: "single",
@@ -46468,6 +47127,16 @@ Object.freeze({
 		form: "single",
 		optional: true
 	}],
+	"recordingOnboard.getOptions": [{
+		name: "deviceId",
+		form: "single",
+		optional: false
+	}],
+	"recordingOnboard.setSettings": [{
+		name: "deviceId",
+		form: "single",
+		optional: false
+	}],
 	"recordingSignal.getStatus": [{
 		name: "deviceId",
 		form: "single",
@@ -46704,6 +47373,11 @@ Object.freeze({
 		form: "single",
 		optional: false
 	}],
+	"videoclips.getPlaybackOptions": [{
+		name: "deviceId",
+		form: "single",
+		optional: false
+	}],
 	"videoclips.listClips": [{
 		name: "deviceId",
 		form: "single",
@@ -46714,6 +47388,11 @@ Object.freeze({
 		form: "single",
 		optional: false
 	}],
+	"videoclips.offerClipBytes": [{
+		name: "deviceId",
+		form: "single",
+		optional: false
+	}],
 	"videoclips.readClipBytes": [{
 		name: "deviceId",
 		form: "single",
@@ -48526,6 +49205,12 @@ Object.defineProperty(exports, "CAM_PROFILE_ORDER", {
 		return CAM_PROFILE_ORDER;
 	}
 });
+Object.defineProperty(exports, "CLIP_BROKER_PACED_RATES", {
+	enumerable: true,
+	get: function() {
+		return CLIP_BROKER_PACED_RATES;
+	}
+});
 Object.defineProperty(exports, "CLIP_STILL_REASON_CODE_HEADER", {
 	enumerable: true,
 	get: function() {
@@ -48742,6 +49427,12 @@ Object.defineProperty(exports, "RingBuffer", {
 		return RingBuffer;
 	}
 });
+Object.defineProperty(exports, "VIDEOCLIPS_MAX_OFFER_BYTES", {
+	enumerable: true,
+	get: function() {
+		return VIDEOCLIPS_MAX_OFFER_BYTES;
+	}
+});
 Object.defineProperty(exports, "VISIT_MERGE_GAP_MS", {
 	enumerable: true,
 	get: function() {