@camstack/types 1.2.245 → 1.2.246

package/dist/addon.js

@@ -1,5 +1,5 @@
 Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
-const require_sleep = require("./sleep-Da9UCU5_.js");
+const require_sleep = require("./sleep-DWUJM120.js");
 const require_event_category = require("./event-category-BVfsrBYA.js");
 const require_err_msg = require("./err-msg-COpsHMw2.js");
 //#region src/generated/cap-input-defaults.ts

package/dist/addon.mjs

@@ -1,4 +1,4 @@
-import { A as DeviceType, Dt as DisposerChain, G as readNodePin, J as ReadinessTimeoutError, L as expandCapMethods, Mt as emitReadiness, Ot as BaseAddon, S as DEVICE_CHILDREN_BATCH_MAX, T as describeCustomActions, Tt as DATAPLANE_SECRET_HEADER, W as nodePin, Z as scopeKey, a as asJsonObject, b as deviceOpsCapability, d as BOOT_RECOVERY_BACKOFF_MS, f as DEVICE_SCOPED_CAPS, h as createEventBusSliceSource, j as adminUiCapability, kt as normalizeAddonInitResult, m as createDeviceProxy, p as isDeviceScopedCap, q as ReadinessRegistry, s as asString, t as sleep, u as parseJsonUnknown, x as viewerUiCapability } from "./sleep-i3eUVc-d.mjs";
+import { A as DeviceType, Dt as DisposerChain, G as readNodePin, J as ReadinessTimeoutError, L as expandCapMethods, Mt as emitReadiness, Ot as BaseAddon, S as DEVICE_CHILDREN_BATCH_MAX, T as describeCustomActions, Tt as DATAPLANE_SECRET_HEADER, W as nodePin, Z as scopeKey, a as asJsonObject, b as deviceOpsCapability, d as BOOT_RECOVERY_BACKOFF_MS, f as DEVICE_SCOPED_CAPS, h as createEventBusSliceSource, j as adminUiCapability, kt as normalizeAddonInitResult, m as createDeviceProxy, p as isDeviceScopedCap, q as ReadinessRegistry, s as asString, t as sleep, u as parseJsonUnknown, x as viewerUiCapability } from "./sleep-COWaSCAi.mjs";
 import { t as EventCategory } from "./event-category-BVDXG4tB.mjs";
 import { t as errMsg } from "./err-msg-IQTHeDzc.mjs";
 //#region src/generated/cap-input-defaults.ts

package/dist/capabilities/index.d.ts

@@ -118,8 +118,8 @@ export type { IUserPasskeysProvider, PasskeySummary } from './user-passkeys.cap.
 export { PasskeySummarySchema, userPasskeysCapability } from './user-passkeys.cap.js';
 export type { IVectorStoreProvider } from './vector-store.cap.js';
 export { VectorDeclareIndexInputSchema, VectorDeleteByFilterInputSchema, VectorDeleteInputSchema, VectorDeleteResultSchema, type VectorFilter, VectorFilterSchema, VectorGetInputSchema, VectorGetResultSchema, type VectorItem, VectorItemSchema, type VectorMatch, VectorMatchSchema, type VectorMetadata, VectorMetadataSchema, type VectorMetric, VectorMetricSchema, VectorQueryInputSchema, VectorQueryResultSchema, VectorStatsInputSchema, VectorStatsResultSchema, VectorUpsertInputSchema, VectorUpsertResultSchema, vectorStoreCapability, } from './vector-store.cap.js';
-export type { Clip, ClipBytes, ClipPlayback, ClipSource, ClipSourceAvailability, ClipStillDisposition, ClipStillRefusalCode, ClipStreamAudio, ClipStreamAudioReason, ClipStreamDial, ClipWake, IVideoclipsProvider, } from './videoclips.cap.js';
-export { CLIP_STILL_DISPOSITION_HEADER, CLIP_STILL_REASON_CODE_HEADER, CLIP_REASON_HEADER_MAX, CLIP_STILL_REASON_HEADER, CLIP_STREAM_TRANSPORT_HEADER, ClipBytesSchema, ClipPlaybackSchema, ClipSchema, ClipSourceAvailabilitySchema, ClipSourceSchema, ClipStillDispositionSchema, ClipStillRefusalCodeSchema, ClipStreamAudioReasonSchema, ClipStreamAudioSchema, ClipStreamDialSchema, ClipWakeSchema, MAX_CLIP_EVENT_IDS, MAX_CLIP_LABELS, VIDEOCLIPS_MAX_READ_BYTES, clipReasonHeaderValue, videoclipsCapability, } from './videoclips.cap.js';
+export type { Clip, ClipBytes, ClipBytesOffer, ClipPlayback, ClipSource, ClipSourceAvailability, ClipStillDisposition, ClipStillRefusalCode, ClipStreamAudio, ClipStreamAudioReason, ClipPlaybackOptions, ClipStreamDial, ClipWake, IVideoclipsProvider, } from './videoclips.cap.js';
+export { CLIP_BROKER_PACED_RATES, CLIP_REALTIME_SOURCE_RATES, CLIP_PLAYBACK_OPTIONS, CLIP_STILL_DISPOSITION_HEADER, CLIP_STILL_REASON_CODE_HEADER, CLIP_REASON_HEADER_MAX, CLIP_STILL_REASON_HEADER, CLIP_STREAM_TRANSPORT_HEADER, ClipBytesOfferSchema, ClipBytesSchema, ClipPlaybackOptionsSchema, ClipPlaybackSchema, ClipSchema, ClipSourceAvailabilitySchema, ClipSourceSchema, ClipStillDispositionSchema, ClipStillRefusalCodeSchema, ClipStreamAudioReasonSchema, ClipStreamAudioSchema, ClipStreamDialSchema, ClipWakeSchema, MAX_CLIP_EVENT_IDS, MAX_CLIP_LABELS, VIDEOCLIPS_MAX_OFFER_BYTES, VIDEOCLIPS_MAX_READ_BYTES, clipReasonHeaderValue, videoclipsCapability, } from './videoclips.cap.js';
 export type { IViewerUiProvider } from './viewer-ui.cap.js';
 export { viewerUiCapability } from './viewer-ui.cap.js';
 export { type IWebrtcSessionProvider, type WebrtcClientHints, type WebrtcLadderDecision, WebrtcLadderDecisionSchema, type WebrtcSessionDebug, WebrtcSessionDebugSchema, type WebrtcStreamChoice, WebrtcStreamChoiceSchema, type WebrtcStreamTarget, WebrtcStreamTargetSchema, type WebrtcTierFailure, WebrtcTierFailureSchema, webrtcClientHintsSchema, webrtcSessionCapability, } from './webrtc-session.cap.js';

package/dist/capabilities/videoclips.cap.d.ts

@@ -67,6 +67,7 @@ export declare const ClipStillRefusalCodeSchema: z.ZodEnum<{
     "no-keyframe": "no-keyframe";
     "queue-full": "queue-full";
     "camera-backoff": "camera-backoff";
+    "decode-failed": "decode-failed";
     "no-catalog-row": "no-catalog-row";
     "unknown-device": "unknown-device";
     "uid-missing": "uid-missing";
@@ -249,11 +250,36 @@ export type ClipWake = z.infer<typeof ClipWakeSchema>;
  * the size in the message, never truncates. Half a video is worse than an
  * honest refusal.
  *
- * The clean follow-on is a CHUNKED read so a `high` twin of a long clip stops
- * being refusable at all. That is a later slice, named here so the bound is
- * not mistaken for a design ceiling.
+ * **Superseded as the way a clip export gets its bytes** (D613). The bound is
+ * a property of the ENVELOPE, not of clips, so the cure was a transport with
+ * no envelope: {@link videoclipsCapability.methods.offerClipBytes} hands back
+ * a one-shot `peerBytes` ticket and the consumer streams it straight to disk,
+ * holding nothing. This method stays for a consumer that genuinely wants the
+ * bytes in hand, and for a provider not yet redeployed — with this bound,
+ * which for an inline read is not going to move.
  */
 export declare const VIDEOCLIPS_MAX_READ_BYTES: number;
+/**
+ * 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.
+ */
+export declare const VIDEOCLIPS_MAX_OFFER_BYTES: number;
 /**
  * A clip's finished bytes, inline — the twin of `recordingExport.readExportBytes`.
  *
@@ -273,6 +299,34 @@ export declare const ClipBytesSchema: z.ZodObject<{
     durationMs: z.ZodOptional<z.ZodNumber>;
 }, z.core.$strip>;
 export type ClipBytes = z.infer<typeof ClipBytesSchema>;
+/**
+ * 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.
+ */
+export declare const ClipBytesOfferSchema: z.ZodObject<{
+    ticket: z.ZodObject<{
+        url: z.ZodString;
+        hostNodeId: z.ZodString;
+        expiresAtMs: z.ZodNumber;
+        declaredBytes: z.ZodNullable<z.ZodNumber>;
+    }, z.core.$strip>;
+    contentType: z.ZodString;
+    name: z.ZodString;
+    served: z.ZodEnum<{
+        high: "high";
+        mid: "mid";
+        low: "low";
+    }>;
+    durationMs: z.ZodOptional<z.ZodNumber>;
+}, z.core.$strip>;
+export type ClipBytesOffer = z.infer<typeof ClipBytesOfferSchema>;
 /**
  * Where a clip's STREAM can be dialled (D597) — the answer to
  * {@link videoclipsCapability.methods.dialClipStream}.
@@ -338,6 +392,86 @@ export declare const ClipStreamDialSchema: z.ZodObject<{
     }>>;
 }, z.core.$strip>;
 export type ClipStreamDial = z.infer<typeof ClipStreamDialSchema>;
+/**
+ * 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.
+ */
+export declare const CLIP_BROKER_PACED_RATES: readonly number[];
+/**
+ * The rates a REALTIME-BOUND stream can be delivered at.
+ *
+ * **Measured, and it is the whole reason this second ladder exists.** A
+ * Hikvision RTSP replay is not a fast fetch: it delivers the recording at the
+ * speed it was recorded. On 1436, 2026-09-23, one stream carried 176 access
+ * units in 14 274 ms of wall clock at a measured 12.5 fps — 14.08 s of media
+ * in 14.27 s, **1.01× realtime** — and a whole 18 s clip took 22.3 s to fetch
+ * end to end. Reolink's cmd-5 transfer, which {@link CLIP_BROKER_PACED_RATES}
+ * was written for, lands the same bytes at 49–62× and therefore has the entire
+ * clip in hand within the first second.
+ *
+ * The broker's pacer consumes `rate` seconds of media per second of wall
+ * clock while the socket supplies one. So at any rate above 1 the buffer
+ * drains at `(rate − 1)×` and a stream that is only seconds old runs dry
+ * almost at once — the viewer stops, the queue empties, and the provider's
+ * own drain gate eventually reports `peer-stalled`. Nothing about that is a
+ * bug to be fixed with a bigger buffer: there is no buffer, because the bytes
+ * do not exist yet.
+ *
+ * So the honest answer is the DECLARATION (D612's own rule, applied to the
+ * case it did not yet have): a rate this transport cannot deliver is never
+ * offered. Below 1 is free — a slower pacer only lets the buffer grow.
+ *
+ * When a clip is served from a FILE the constraint is gone with the transport,
+ * which is why `file` keeps the full ladder.
+ */
+export declare const CLIP_REALTIME_SOURCE_RATES: readonly number[];
+/**
+ * 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).
+ */
+export declare const ClipPlaybackOptionsSchema: z.ZodObject<{
+    transport: z.ZodEnum<{
+        file: "file";
+        stream: "stream";
+    }>;
+    seek: z.ZodEnum<{
+        forward: "forward";
+        free: "free";
+    }>;
+    stepBack: z.ZodBoolean;
+    scrub: z.ZodBoolean;
+    rates: z.ZodReadonly<z.ZodArray<z.ZodNumber>>;
+}, z.core.$strip>;
+export type ClipPlaybackOptions = z.infer<typeof ClipPlaybackOptionsSchema>;
 export declare const ClipSourceAvailabilitySchema: z.ZodObject<{
     state: z.ZodEnum<{
         ok: "ok";
@@ -533,14 +667,18 @@ export declare const 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
@@ -588,6 +726,72 @@ export declare const videoclipsCapability: {
         }, z.core.$strip>, "query"> & {
             readonly providerOptional: true;
         };
+        /**
+         * 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.
+         */
+        readonly offerClipBytes: import("./capability-definition.js").CapabilityMethodSchema<z.ZodObject<{
+            deviceId: z.ZodNumber;
+            clipId: z.ZodString;
+            provider: z.ZodString;
+            profile: z.ZodOptional<z.ZodEnum<{
+                high: "high";
+                mid: "mid";
+                low: "low";
+            }>>;
+            maxBytes: z.ZodOptional<z.ZodNumber>;
+            wake: z.ZodOptional<z.ZodEnum<{
+                authorised: "authorised";
+            }>>;
+        }, z.core.$strip>, z.ZodObject<{
+            ticket: z.ZodObject<{
+                url: z.ZodString;
+                hostNodeId: z.ZodString;
+                expiresAtMs: z.ZodNumber;
+                declaredBytes: z.ZodNullable<z.ZodNumber>;
+            }, z.core.$strip>;
+            contentType: z.ZodString;
+            name: z.ZodString;
+            served: z.ZodEnum<{
+                high: "high";
+                mid: "mid";
+                low: "low";
+            }>;
+            durationMs: z.ZodOptional<z.ZodNumber>;
+        }, z.core.$strip>, "query"> & {
+            readonly providerOptional: true;
+        };
         /**
          * 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
@@ -639,6 +843,92 @@ export declare const videoclipsCapability: {
         }, z.core.$strip>, "query"> & {
             readonly providerOptional: true;
         };
+        /**
+         * 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.
+         */
+        readonly getPlaybackOptions: import("./capability-definition.js").CapabilityMethodSchema<z.ZodObject<{
+            deviceId: z.ZodNumber;
+            provider: z.ZodString;
+        }, z.core.$strip>, z.ZodObject<{
+            transport: z.ZodEnum<{
+                file: "file";
+                stream: "stream";
+            }>;
+            seek: z.ZodEnum<{
+                forward: "forward";
+                free: "free";
+            }>;
+            stepBack: z.ZodBoolean;
+            scrub: z.ZodBoolean;
+            rates: z.ZodReadonly<z.ZodArray<z.ZodNumber>>;
+        }, z.core.$strip>, "query"> & {
+            readonly providerOptional: true;
+        };
     };
 };
 export type IVideoclipsProvider = InferProvider<typeof videoclipsCapability>;
+/**
+ * NOTE ON PLACEMENT: this block lives AFTER the capability definition on
+ * purpose. `scripts/lib/parse-cap.ts` finds a cap by the FIRST
+ * `export const <X> = {` in the file, so an object literal declared above
+ * `videoclipsCapability` is silently taken for the capability itself and
+ * codegen emits a `DeviceProxy` entry that does not type-check. Found the
+ * hard way, 2026-09-23.
+ */
+/**
+ * The two envelopes, spelled ONCE.
+ *
+ * A provider answers with the entry for the transport its own wiring buys —
+ * `stream` if it implements `dialClipStream`, `file` if it implements only
+ * `readClipBytes` — and never composes one of its own. One table is what
+ * makes "the provider may not promise what no clip can be given" structural
+ * instead of a discipline: there is nothing else to promise.
+ */
+export declare const CLIP_PLAYBACK_OPTIONS: {
+    readonly stream: {
+        readonly transport: "stream";
+        readonly seek: "forward";
+        readonly stepBack: false;
+        readonly scrub: false;
+        readonly rates: readonly number[];
+    };
+    /**
+     * A `stream` whose SOURCE runs at realtime — a Hikvision RTSP replay.
+     *
+     * Same verbs as `stream`, a shorter rate ladder, and the difference is a
+     * measurement rather than a preference: see
+     * {@link CLIP_REALTIME_SOURCE_RATES}. A third entry rather than a parameter,
+     * because a provider must still be able to do nothing but NAME one of these.
+     */
+    readonly realtimeStream: {
+        readonly transport: "stream";
+        readonly seek: "forward";
+        readonly stepBack: false;
+        readonly scrub: false;
+        readonly rates: readonly number[];
+    };
+    readonly file: {
+        readonly transport: "file";
+        readonly seek: "free";
+        readonly stepBack: true;
+        readonly scrub: true;
+        readonly rates: readonly number[];
+    };
+};

package/dist/generated/addon-api.d.ts

@@ -9131,6 +9131,13 @@ export type AppRouter = TrpcCoreRouter<{
             output: z.infer<typeof videoclipsCapability.methods.readClipBytes.output>;
             meta: object;
         }>;
+        offerClipBytes: TRPCQueryProcedure<{
+            input: {
+                [x: string]: unknown;
+            } & z.input<typeof videoclipsCapability.methods.offerClipBytes.input>;
+            output: z.infer<typeof videoclipsCapability.methods.offerClipBytes.output>;
+            meta: object;
+        }>;
         dialClipStream: TRPCQueryProcedure<{
             input: {
                 [x: string]: unknown;
@@ -9138,6 +9145,13 @@ export type AppRouter = TrpcCoreRouter<{
             output: z.infer<typeof videoclipsCapability.methods.dialClipStream.output>;
             meta: object;
         }>;
+        getPlaybackOptions: TRPCQueryProcedure<{
+            input: {
+                [x: string]: unknown;
+            } & z.input<typeof videoclipsCapability.methods.getPlaybackOptions.input>;
+            output: z.infer<typeof videoclipsCapability.methods.getPlaybackOptions.output>;
+            meta: object;
+        }>;
     }>>;
     viewerUi: TRPCBuiltRouter<{
         ctx: TrpcContext;

package/dist/generated/method-access-map.d.ts

@@ -6,7 +6,7 @@
  * scope+access check inside `protectedProcedure` (see
  * `server/backend/src/api/trpc/trpc.middleware.ts`).
  *
- * Coverage: 1169 method paths across 160 capabilities.
+ * Coverage: 1171 method paths across 160 capabilities.
  */
 import type { CapabilityMethodAccess } from '../capabilities/capability-definition.js';
 export interface MethodAccessRecord {

package/dist/generated/method-device-selectors.d.ts

@@ -6,7 +6,7 @@
  * system-scope cap that takes a deviceId was previously never device-filtered
  * — see the generator header).
  *
- * Coverage: 395 methods carry a device reference, of which
+ * Coverage: 397 methods carry a device reference, of which
  * 141 are on SYSTEM-scope caps.
  *
  * Top-level fields, number arrays, and one-level arrays of objects carrying

package/dist/index.d.ts

@@ -22,6 +22,8 @@ export type * from './interfaces/addon.js';
 export { DEFAULT_ADDON_PLACEMENT, isAgentOnlyPlacement, isDeployableToAgent, isIsolatedBuiltin, resolveAddonExecution, resolveAddonGroup, resolveAddonPlacement, resolveRunnerId, } from './interfaces/addon.js';
 export type * from './interfaces/addon-data-plane.js';
 export { DATAPLANE_SECRET_HEADER, SHARE_VIEW_KINDS } from './interfaces/addon-data-plane.js';
+export type * from './interfaces/addon-peer-bytes.js';
+export { PeerBytesTicketSchema, PEER_BYTES_CHUNK_BYTES, PEER_BYTES_MAX_OUTSTANDING, PEER_BYTES_STALL_MS, PEER_BYTES_TICKET_TTL_MS, } from './interfaces/addon-peer-bytes.js';
 export type * from './interfaces/addon-routes.js';
 export * from './interfaces/adoption-job.js';
 export type * from './interfaces/agent.js';