@camstack/addon-matter-broker 0.2.45 → 0.2.46

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/dist/addon.js +259 -174
  2. package/dist/addon.mjs +259 -174
  3. package/package.json +1 -1
package/dist/addon.js CHANGED
@@ -13264,6 +13264,114 @@ method(object({
13264
13264
  height: number()
13265
13265
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string$2() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13266
13266
  /**
13267
+ * `failure-contribution` — the capability an addon reports its OWN losses
13268
+ * through, per camera, with the denominator attached. It stores nothing.
13269
+ *
13270
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
13271
+ *
13272
+ * `load-contribution` answers *what did this camera COST*. This answers *what
13273
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
13274
+ * copied: the contributor reports what it already knows, hub-main adds only
13275
+ * `addonId`, nothing needs global knowledge, and there is no central list for
13276
+ * somebody to forget to edit.
13277
+ *
13278
+ * They are not merged, because their invariants are opposites:
13279
+ *
13280
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
13281
+ * claim a camera cost nothing, which is a measurement nobody made;
13282
+ * - a `failure-contribution` zero is the **most valuable value on the
13283
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13284
+ * and it is exactly what an absent entry cannot say.
13285
+ *
13286
+ * Putting a loss counter on a cost entry would also break the reconciliation
13287
+ * that gives `load-contribution` its point: contributions are subtracted from
13288
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13289
+ * has no process.
13290
+ *
13291
+ * ## Why not a log line, since the counters already exist
13292
+ *
13293
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
13294
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13295
+ * ends in a log line, and a log line is the thing the operator asked to stop
13296
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13297
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13298
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13299
+ * media blackout were both diagnosed. The counters stay; this is where they can
13300
+ * be READ.
13301
+ *
13302
+ * ## The rate is served with its denominator or not at all
13303
+ *
13304
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
13305
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13306
+ * than yesterday" and was **flat across twelve hours** once divided by the
13307
+ * successes on the same path. A surface that publishes only the numerator
13308
+ * reproduces that mistake on every read.
13309
+ *
13310
+ * ## Shape
13311
+ *
13312
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13313
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13314
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13315
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13316
+ * a forked runner's entries reach hub-main over transport that already exists.
13317
+ * No new UDS message, no second registry (D3). The operator reads the assembled
13318
+ * result through `system.getFailureContributions`.
13319
+ */
13320
+ var FailureReasonCountSchema = object({
13321
+ /**
13322
+ * Why the attempt did not land, in the contributor's own vocabulary —
13323
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13324
+ * strings that already appear in this repo's logs and, where one exists, the
13325
+ * same string the per-track `previewMissReason` records (D276): a second
13326
+ * vocabulary for the same loss would make the row and the counter
13327
+ * un-joinable.
13328
+ */
13329
+ reason: string$2(),
13330
+ count: number().int().nonnegative()
13331
+ });
13332
+ var FailureContributionSchema = object({
13333
+ /**
13334
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13335
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13336
+ * `unit` free: the families are owned by different addons and a shared enum
13337
+ * is a central list that rots invisibly.
13338
+ */
13339
+ family: string$2(),
13340
+ /**
13341
+ * The NUMERIC device id — the same value every log line carries as
13342
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
13343
+ * cannot name the camera must not emit the entry, because a fleet total
13344
+ * cannot answer the only question anybody asks of this surface.
13345
+ */
13346
+ deviceId: number().int().positive(),
13347
+ /**
13348
+ * A second dimension inside the family: the model / step id for an inference
13349
+ * timeout, so "which camera AND which model" is one read. Absent when the
13350
+ * family has a single variant.
13351
+ */
13352
+ variant: string$2().optional(),
13353
+ /**
13354
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13355
+ * differencing two reads must drop the interval when it changes, because the
13356
+ * counter restarted from zero in a respawned runner. Same discipline as
13357
+ * `LoadContribution.startedAtMs`.
13358
+ */
13359
+ sinceMs: number(),
13360
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13361
+ atMs: number(),
13362
+ /**
13363
+ * THE DENOMINATOR — every attempt on this path for this camera in the
13364
+ * window. A failure count published without it is the mistake this schema
13365
+ * exists to make impossible.
13366
+ */
13367
+ attempts: number().int().nonnegative(),
13368
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
13369
+ succeeded: number().int().nonnegative(),
13370
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
13371
+ reasons: array(FailureReasonCountSchema).readonly()
13372
+ });
13373
+ method(_void(), array(FailureContributionSchema).readonly());
13374
+ /**
13267
13375
  * filesystem-browse — per-node capability for browsing the node's local
13268
13376
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13269
13377
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13785,6 +13893,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13785
13893
  kind: "mutation",
13786
13894
  auth: "admin"
13787
13895
  });
13896
+ var LoadContributionSchema = object({
13897
+ role: _enum([
13898
+ "decode",
13899
+ "transcode",
13900
+ "recording",
13901
+ "streaming",
13902
+ "detection"
13903
+ ]),
13904
+ /**
13905
+ * The NUMERIC device id — the same value every log line carries as
13906
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13907
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
13908
+ * contributor that cannot name its camera must not emit the entry at all,
13909
+ * because an unnamed per-camera entry is indistinguishable from a shared one
13910
+ * and would quietly turn one camera's cost into everybody's.
13911
+ */
13912
+ deviceId: number().int().positive().nullable(),
13913
+ attribution: _enum([
13914
+ "measured",
13915
+ "accounted",
13916
+ "unattributable"
13917
+ ]),
13918
+ /**
13919
+ * What ONE entry is, in the contributor's own words — `615/high`,
13920
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13921
+ * family and inventing a common one would lose the only information that
13922
+ * makes two entries for the same camera distinguishable.
13923
+ */
13924
+ unit: string$2(),
13925
+ /**
13926
+ * The OS process this cost lives in, when there is one. Present so a
13927
+ * consumer can (a) tell two generations of the same unit apart across a
13928
+ * restart, and (b) subtract claimed processes from the node's process
13929
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
13930
+ * process of its own.
13931
+ */
13932
+ pid: number().int().positive().optional(),
13933
+ /**
13934
+ * When this generation started. The pid's incarnation marker: a consumer
13935
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
13936
+ * window when this changes, because the counter restarted from zero in a new
13937
+ * process.
13938
+ */
13939
+ startedAtMs: number().optional(),
13940
+ /**
13941
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
13942
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
13943
+ * contribution is asked for.
13944
+ *
13945
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
13946
+ * needs a sampler, and a new per-node sampler is the defect half of
13947
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
13948
+ * by whoever already keeps a history; a rate cannot be un-averaged.
13949
+ *
13950
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
13951
+ * an entry with no process.
13952
+ */
13953
+ cpuSeconds: number().optional(),
13954
+ /** Resident bytes of this unit's process, same source and same rules. */
13955
+ rssBytes: number().optional()
13956
+ });
13957
+ method(_void(), array(LoadContributionSchema).readonly());
13788
13958
  /**
13789
13959
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13790
13960
  * through. It stores nothing.
@@ -13861,176 +14031,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
13861
14031
  tags: record(string$2(), string$2()).optional()
13862
14032
  }), array(LogEntrySchema).readonly());
13863
14033
  /**
13864
- * `failure-contribution` — the capability an addon reports its OWN losses
13865
- * through, per camera, with the denominator attached. It stores nothing.
13866
- *
13867
- * ## The twin of `load-contribution`, and why it is a twin and not a field
13868
- *
13869
- * `load-contribution` answers *what did this camera COST*. This answers *what
13870
- * did this camera LOSE*. The reporting discipline is identical and deliberately
13871
- * copied: the contributor reports what it already knows, hub-main adds only
13872
- * `addonId`, nothing needs global knowledge, and there is no central list for
13873
- * somebody to forget to edit.
13874
- *
13875
- * They are not merged, because their invariants are opposites:
13876
- *
13877
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
13878
- * claim a camera cost nothing, which is a measurement nobody made;
13879
- * - a `failure-contribution` zero is the **most valuable value on the
13880
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13881
- * and it is exactly what an absent entry cannot say.
13882
- *
13883
- * Putting a loss counter on a cost entry would also break the reconciliation
13884
- * that gives `load-contribution` its point: contributions are subtracted from
13885
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13886
- * has no process.
13887
- *
13888
- * ## Why not a log line, since the counters already exist
13889
- *
13890
- * Several of these paths already counted themselves — `CaptureScheduler`'s
13891
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13892
- * ends in a log line, and a log line is the thing the operator asked to stop
13893
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13894
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13895
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13896
- * media blackout were both diagnosed. The counters stay; this is where they can
13897
- * be READ.
13898
- *
13899
- * ## The rate is served with its denominator or not at all
13900
- *
13901
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
13902
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13903
- * than yesterday" and was **flat across twelve hours** once divided by the
13904
- * successes on the same path. A surface that publishes only the numerator
13905
- * reproduces that mistake on every read.
13906
- *
13907
- * ## Shape
13908
- *
13909
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13910
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13911
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13912
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13913
- * a forked runner's entries reach hub-main over transport that already exists.
13914
- * No new UDS message, no second registry (D3). The operator reads the assembled
13915
- * result through `system.getFailureContributions`.
13916
- */
13917
- var FailureReasonCountSchema = object({
13918
- /**
13919
- * Why the attempt did not land, in the contributor's own vocabulary —
13920
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13921
- * strings that already appear in this repo's logs and, where one exists, the
13922
- * same string the per-track `previewMissReason` records (D276): a second
13923
- * vocabulary for the same loss would make the row and the counter
13924
- * un-joinable.
13925
- */
13926
- reason: string$2(),
13927
- count: number().int().nonnegative()
13928
- });
13929
- var FailureContributionSchema = object({
13930
- /**
13931
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13932
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13933
- * `unit` free: the families are owned by different addons and a shared enum
13934
- * is a central list that rots invisibly.
13935
- */
13936
- family: string$2(),
13937
- /**
13938
- * The NUMERIC device id — the same value every log line carries as
13939
- * `tags.deviceId`. Never nullable and never absent: a contributor that
13940
- * cannot name the camera must not emit the entry, because a fleet total
13941
- * cannot answer the only question anybody asks of this surface.
13942
- */
13943
- deviceId: number().int().positive(),
13944
- /**
13945
- * A second dimension inside the family: the model / step id for an inference
13946
- * timeout, so "which camera AND which model" is one read. Absent when the
13947
- * family has a single variant.
13948
- */
13949
- variant: string$2().optional(),
13950
- /**
13951
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13952
- * differencing two reads must drop the interval when it changes, because the
13953
- * counter restarted from zero in a respawned runner. Same discipline as
13954
- * `LoadContribution.startedAtMs`.
13955
- */
13956
- sinceMs: number(),
13957
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13958
- atMs: number(),
13959
- /**
13960
- * THE DENOMINATOR — every attempt on this path for this camera in the
13961
- * window. A failure count published without it is the mistake this schema
13962
- * exists to make impossible.
13963
- */
13964
- attempts: number().int().nonnegative(),
13965
- /** Attempts that landed. `attempts - succeeded` is the loss. */
13966
- succeeded: number().int().nonnegative(),
13967
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
13968
- reasons: array(FailureReasonCountSchema).readonly()
13969
- });
13970
- method(_void(), array(FailureContributionSchema).readonly());
13971
- var LoadContributionSchema = object({
13972
- role: _enum([
13973
- "decode",
13974
- "transcode",
13975
- "recording",
13976
- "streaming",
13977
- "detection"
13978
- ]),
13979
- /**
13980
- * The NUMERIC device id — the same value every log line carries as
13981
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13982
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
13983
- * contributor that cannot name its camera must not emit the entry at all,
13984
- * because an unnamed per-camera entry is indistinguishable from a shared one
13985
- * and would quietly turn one camera's cost into everybody's.
13986
- */
13987
- deviceId: number().int().positive().nullable(),
13988
- attribution: _enum([
13989
- "measured",
13990
- "accounted",
13991
- "unattributable"
13992
- ]),
13993
- /**
13994
- * What ONE entry is, in the contributor's own words — `615/high`,
13995
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13996
- * family and inventing a common one would lose the only information that
13997
- * makes two entries for the same camera distinguishable.
13998
- */
13999
- unit: string$2(),
14000
- /**
14001
- * The OS process this cost lives in, when there is one. Present so a
14002
- * consumer can (a) tell two generations of the same unit apart across a
14003
- * restart, and (b) subtract claimed processes from the node's process
14004
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14005
- * process of its own.
14006
- */
14007
- pid: number().int().positive().optional(),
14008
- /**
14009
- * When this generation started. The pid's incarnation marker: a consumer
14010
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14011
- * window when this changes, because the counter restarted from zero in a new
14012
- * process.
14013
- */
14014
- startedAtMs: number().optional(),
14015
- /**
14016
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14017
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14018
- * contribution is asked for.
14019
- *
14020
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14021
- * needs a sampler, and a new per-node sampler is the defect half of
14022
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14023
- * by whoever already keeps a history; a rate cannot be un-averaged.
14024
- *
14025
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14026
- * an entry with no process.
14027
- */
14028
- cpuSeconds: number().optional(),
14029
- /** Resident bytes of this unit's process, same source and same rules. */
14030
- rssBytes: number().optional()
14031
- });
14032
- method(_void(), array(LoadContributionSchema).readonly());
14033
- /**
14034
14034
  * `login-method` — collection cap through which auth addons contribute
14035
14035
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14036
14036
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18768,12 +18768,53 @@ var MediaFileKindEnum = _enum([
18768
18768
  "keyFrameSmall",
18769
18769
  "thumbnailSmall"
18770
18770
  ]);
18771
+ /**
18772
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
18773
+ * ARE — never the bytes themselves.
18774
+ *
18775
+ * ## Why `url` and not `base64`
18776
+ *
18777
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
18778
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
18779
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
18780
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
18781
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
18782
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
18783
+ *
18784
+ * `url` points at the `event-media` data plane
18785
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
18786
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
18787
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
18788
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
18789
+ * no less protected than they were inside a `view`-level cap response — see
18790
+ * `data-plane-access.ts` for the rule and the one gap it does not close
18791
+ * (per-device scoping).
18792
+ *
18793
+ * The URL is built from the row's **stored** key, which is not always its
18794
+ * published `kind`: a track's face/plate crop is stored as `crop` under
18795
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
18796
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
18797
+ *
18798
+ * ## `base64` is TRANSITIONAL and is going away
18799
+ *
18800
+ * It is still populated for one reason: the deployed viewer's track-detail
18801
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
18802
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
18803
+ * triangle — not as absence. Removing the field before that viewer ships is an
18804
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
18805
+ * delete this line and the `withBytes` pass-through in
18806
+ * `analytics-query-facade.ts`; nothing else reads it.
18807
+ */
18771
18808
  var MediaFileSchema = object({
18772
18809
  key: string$2(),
18773
18810
  kind: MediaFileKindEnum,
18774
- base64: string$2(),
18775
18811
  sizeBytes: number(),
18776
18812
  timestamp: number()
18813
+ }).extend({
18814
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
18815
+ url: string$2(),
18816
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
18817
+ base64: string$2()
18777
18818
  });
18778
18819
  /**
18779
18820
  * One media row WITHOUT its bytes.
@@ -18785,7 +18826,9 @@ var MediaFileSchema = object({
18785
18826
  * blocks the whole view.
18786
18827
  *
18787
18828
  * `sizeBytes` is carried because it is what lets a client decide between the
18788
- * stored blob and a `?variant=thumb` rendering without fetching either.
18829
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
18830
+ * `url` because a client that had to build the plane path itself is a second
18831
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
18789
18832
  */
18790
18833
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
18791
18834
  /**
@@ -19474,6 +19517,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19474
19517
  }), array(MediaFileSchema).readonly()), method(object({
19475
19518
  trackId: string$2(),
19476
19519
  deviceId: number()
19520
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19521
+ eventId: string$2(),
19522
+ deviceId: number()
19477
19523
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19478
19524
  kind: "mutation",
19479
19525
  auth: "admin"
@@ -24481,10 +24527,24 @@ var FaceClusterSchema = object({
24481
24527
  size: number().int(),
24482
24528
  cohesion: number()
24483
24529
  });
24530
+ /**
24531
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
24532
+ * are — never the bytes.
24533
+ *
24534
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
24535
+ * track/event contract) is still populated because a deployed viewer requires
24536
+ * the field to parse a row at all; this method has no such reader. Its ONE
24537
+ * caller is the admin UI's detail modal, which was building
24538
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
24539
+ * dialog already rendering its key FRAME from the `event-media` plane.
24540
+ *
24541
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
24542
+ * media key directly, so this needed no new plane and no new access decision.
24543
+ */
24484
24544
  var MediaFileLiteSchema$1 = object({
24485
24545
  key: string$2(),
24486
24546
  kind: string$2(),
24487
- base64: string$2(),
24547
+ url: string$2(),
24488
24548
  sizeBytes: number(),
24489
24549
  timestamp: number()
24490
24550
  });
@@ -27506,10 +27566,24 @@ var PlateInfoSchema = object({
27506
27566
  */
27507
27567
  cropUrl: string$2().optional()
27508
27568
  });
27569
+ /**
27570
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
27571
+ * are — never the bytes.
27572
+ *
27573
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
27574
+ * track/event contract) is still populated because a deployed viewer requires
27575
+ * the field to parse a row at all; this method has no such reader. Its ONE
27576
+ * caller is the admin UI's detail modal, which was building
27577
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
27578
+ * dialog already rendering its key FRAME from the `event-media` plane.
27579
+ *
27580
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
27581
+ * media key directly, so this needed no new plane and no new access decision.
27582
+ */
27509
27583
  var MediaFileLiteSchema = object({
27510
27584
  key: string$2(),
27511
27585
  kind: string$2(),
27512
- base64: string$2(),
27586
+ url: string$2(),
27513
27587
  sizeBytes: number(),
27514
27588
  timestamp: number()
27515
27589
  });
@@ -35406,6 +35480,12 @@ Object.freeze({
35406
35480
  addonId: null,
35407
35481
  access: "view"
35408
35482
  },
35483
+ "pipelineAnalytics.listEventMedia": {
35484
+ capName: "pipeline-analytics",
35485
+ capScope: "device",
35486
+ addonId: null,
35487
+ access: "view"
35488
+ },
35409
35489
  "pipelineAnalytics.listGroups": {
35410
35490
  capName: "pipeline-analytics",
35411
35491
  capScope: "device",
@@ -39029,6 +39109,11 @@ Object.freeze({
39029
39109
  form: "array",
39030
39110
  optional: false
39031
39111
  }],
39112
+ "pipelineAnalytics.listEventMedia": [{
39113
+ name: "deviceId",
39114
+ form: "single",
39115
+ optional: false
39116
+ }],
39032
39117
  "pipelineAnalytics.listGroups": [{
39033
39118
  name: "deviceIds",
39034
39119
  form: "array",
package/dist/addon.mjs CHANGED
@@ -13262,6 +13262,114 @@ method(object({
13262
13262
  height: number()
13263
13263
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string$2() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13264
13264
  /**
13265
+ * `failure-contribution` — the capability an addon reports its OWN losses
13266
+ * through, per camera, with the denominator attached. It stores nothing.
13267
+ *
13268
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
13269
+ *
13270
+ * `load-contribution` answers *what did this camera COST*. This answers *what
13271
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
13272
+ * copied: the contributor reports what it already knows, hub-main adds only
13273
+ * `addonId`, nothing needs global knowledge, and there is no central list for
13274
+ * somebody to forget to edit.
13275
+ *
13276
+ * They are not merged, because their invariants are opposites:
13277
+ *
13278
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
13279
+ * claim a camera cost nothing, which is a measurement nobody made;
13280
+ * - a `failure-contribution` zero is the **most valuable value on the
13281
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13282
+ * and it is exactly what an absent entry cannot say.
13283
+ *
13284
+ * Putting a loss counter on a cost entry would also break the reconciliation
13285
+ * that gives `load-contribution` its point: contributions are subtracted from
13286
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13287
+ * has no process.
13288
+ *
13289
+ * ## Why not a log line, since the counters already exist
13290
+ *
13291
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
13292
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13293
+ * ends in a log line, and a log line is the thing the operator asked to stop
13294
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13295
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13296
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13297
+ * media blackout were both diagnosed. The counters stay; this is where they can
13298
+ * be READ.
13299
+ *
13300
+ * ## The rate is served with its denominator or not at all
13301
+ *
13302
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
13303
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13304
+ * than yesterday" and was **flat across twelve hours** once divided by the
13305
+ * successes on the same path. A surface that publishes only the numerator
13306
+ * reproduces that mistake on every read.
13307
+ *
13308
+ * ## Shape
13309
+ *
13310
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13311
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13312
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13313
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13314
+ * a forked runner's entries reach hub-main over transport that already exists.
13315
+ * No new UDS message, no second registry (D3). The operator reads the assembled
13316
+ * result through `system.getFailureContributions`.
13317
+ */
13318
+ var FailureReasonCountSchema = object({
13319
+ /**
13320
+ * Why the attempt did not land, in the contributor's own vocabulary —
13321
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13322
+ * strings that already appear in this repo's logs and, where one exists, the
13323
+ * same string the per-track `previewMissReason` records (D276): a second
13324
+ * vocabulary for the same loss would make the row and the counter
13325
+ * un-joinable.
13326
+ */
13327
+ reason: string$2(),
13328
+ count: number().int().nonnegative()
13329
+ });
13330
+ var FailureContributionSchema = object({
13331
+ /**
13332
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13333
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13334
+ * `unit` free: the families are owned by different addons and a shared enum
13335
+ * is a central list that rots invisibly.
13336
+ */
13337
+ family: string$2(),
13338
+ /**
13339
+ * The NUMERIC device id — the same value every log line carries as
13340
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
13341
+ * cannot name the camera must not emit the entry, because a fleet total
13342
+ * cannot answer the only question anybody asks of this surface.
13343
+ */
13344
+ deviceId: number().int().positive(),
13345
+ /**
13346
+ * A second dimension inside the family: the model / step id for an inference
13347
+ * timeout, so "which camera AND which model" is one read. Absent when the
13348
+ * family has a single variant.
13349
+ */
13350
+ variant: string$2().optional(),
13351
+ /**
13352
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13353
+ * differencing two reads must drop the interval when it changes, because the
13354
+ * counter restarted from zero in a respawned runner. Same discipline as
13355
+ * `LoadContribution.startedAtMs`.
13356
+ */
13357
+ sinceMs: number(),
13358
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13359
+ atMs: number(),
13360
+ /**
13361
+ * THE DENOMINATOR — every attempt on this path for this camera in the
13362
+ * window. A failure count published without it is the mistake this schema
13363
+ * exists to make impossible.
13364
+ */
13365
+ attempts: number().int().nonnegative(),
13366
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
13367
+ succeeded: number().int().nonnegative(),
13368
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
13369
+ reasons: array(FailureReasonCountSchema).readonly()
13370
+ });
13371
+ method(_void(), array(FailureContributionSchema).readonly());
13372
+ /**
13265
13373
  * filesystem-browse — per-node capability for browsing the node's local
13266
13374
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13267
13375
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13783,6 +13891,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13783
13891
  kind: "mutation",
13784
13892
  auth: "admin"
13785
13893
  });
13894
+ var LoadContributionSchema = object({
13895
+ role: _enum([
13896
+ "decode",
13897
+ "transcode",
13898
+ "recording",
13899
+ "streaming",
13900
+ "detection"
13901
+ ]),
13902
+ /**
13903
+ * The NUMERIC device id — the same value every log line carries as
13904
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13905
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
13906
+ * contributor that cannot name its camera must not emit the entry at all,
13907
+ * because an unnamed per-camera entry is indistinguishable from a shared one
13908
+ * and would quietly turn one camera's cost into everybody's.
13909
+ */
13910
+ deviceId: number().int().positive().nullable(),
13911
+ attribution: _enum([
13912
+ "measured",
13913
+ "accounted",
13914
+ "unattributable"
13915
+ ]),
13916
+ /**
13917
+ * What ONE entry is, in the contributor's own words — `615/high`,
13918
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13919
+ * family and inventing a common one would lose the only information that
13920
+ * makes two entries for the same camera distinguishable.
13921
+ */
13922
+ unit: string$2(),
13923
+ /**
13924
+ * The OS process this cost lives in, when there is one. Present so a
13925
+ * consumer can (a) tell two generations of the same unit apart across a
13926
+ * restart, and (b) subtract claimed processes from the node's process
13927
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
13928
+ * process of its own.
13929
+ */
13930
+ pid: number().int().positive().optional(),
13931
+ /**
13932
+ * When this generation started. The pid's incarnation marker: a consumer
13933
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
13934
+ * window when this changes, because the counter restarted from zero in a new
13935
+ * process.
13936
+ */
13937
+ startedAtMs: number().optional(),
13938
+ /**
13939
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
13940
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
13941
+ * contribution is asked for.
13942
+ *
13943
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
13944
+ * needs a sampler, and a new per-node sampler is the defect half of
13945
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
13946
+ * by whoever already keeps a history; a rate cannot be un-averaged.
13947
+ *
13948
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
13949
+ * an entry with no process.
13950
+ */
13951
+ cpuSeconds: number().optional(),
13952
+ /** Resident bytes of this unit's process, same source and same rules. */
13953
+ rssBytes: number().optional()
13954
+ });
13955
+ method(_void(), array(LoadContributionSchema).readonly());
13786
13956
  /**
13787
13957
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13788
13958
  * through. It stores nothing.
@@ -13859,176 +14029,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
13859
14029
  tags: record(string$2(), string$2()).optional()
13860
14030
  }), array(LogEntrySchema).readonly());
13861
14031
  /**
13862
- * `failure-contribution` — the capability an addon reports its OWN losses
13863
- * through, per camera, with the denominator attached. It stores nothing.
13864
- *
13865
- * ## The twin of `load-contribution`, and why it is a twin and not a field
13866
- *
13867
- * `load-contribution` answers *what did this camera COST*. This answers *what
13868
- * did this camera LOSE*. The reporting discipline is identical and deliberately
13869
- * copied: the contributor reports what it already knows, hub-main adds only
13870
- * `addonId`, nothing needs global knowledge, and there is no central list for
13871
- * somebody to forget to edit.
13872
- *
13873
- * They are not merged, because their invariants are opposites:
13874
- *
13875
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
13876
- * claim a camera cost nothing, which is a measurement nobody made;
13877
- * - a `failure-contribution` zero is the **most valuable value on the
13878
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13879
- * and it is exactly what an absent entry cannot say.
13880
- *
13881
- * Putting a loss counter on a cost entry would also break the reconciliation
13882
- * that gives `load-contribution` its point: contributions are subtracted from
13883
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13884
- * has no process.
13885
- *
13886
- * ## Why not a log line, since the counters already exist
13887
- *
13888
- * Several of these paths already counted themselves — `CaptureScheduler`'s
13889
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13890
- * ends in a log line, and a log line is the thing the operator asked to stop
13891
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13892
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13893
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13894
- * media blackout were both diagnosed. The counters stay; this is where they can
13895
- * be READ.
13896
- *
13897
- * ## The rate is served with its denominator or not at all
13898
- *
13899
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
13900
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13901
- * than yesterday" and was **flat across twelve hours** once divided by the
13902
- * successes on the same path. A surface that publishes only the numerator
13903
- * reproduces that mistake on every read.
13904
- *
13905
- * ## Shape
13906
- *
13907
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13908
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13909
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13910
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13911
- * a forked runner's entries reach hub-main over transport that already exists.
13912
- * No new UDS message, no second registry (D3). The operator reads the assembled
13913
- * result through `system.getFailureContributions`.
13914
- */
13915
- var FailureReasonCountSchema = object({
13916
- /**
13917
- * Why the attempt did not land, in the contributor's own vocabulary —
13918
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13919
- * strings that already appear in this repo's logs and, where one exists, the
13920
- * same string the per-track `previewMissReason` records (D276): a second
13921
- * vocabulary for the same loss would make the row and the counter
13922
- * un-joinable.
13923
- */
13924
- reason: string$2(),
13925
- count: number().int().nonnegative()
13926
- });
13927
- var FailureContributionSchema = object({
13928
- /**
13929
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13930
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13931
- * `unit` free: the families are owned by different addons and a shared enum
13932
- * is a central list that rots invisibly.
13933
- */
13934
- family: string$2(),
13935
- /**
13936
- * The NUMERIC device id — the same value every log line carries as
13937
- * `tags.deviceId`. Never nullable and never absent: a contributor that
13938
- * cannot name the camera must not emit the entry, because a fleet total
13939
- * cannot answer the only question anybody asks of this surface.
13940
- */
13941
- deviceId: number().int().positive(),
13942
- /**
13943
- * A second dimension inside the family: the model / step id for an inference
13944
- * timeout, so "which camera AND which model" is one read. Absent when the
13945
- * family has a single variant.
13946
- */
13947
- variant: string$2().optional(),
13948
- /**
13949
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13950
- * differencing two reads must drop the interval when it changes, because the
13951
- * counter restarted from zero in a respawned runner. Same discipline as
13952
- * `LoadContribution.startedAtMs`.
13953
- */
13954
- sinceMs: number(),
13955
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13956
- atMs: number(),
13957
- /**
13958
- * THE DENOMINATOR — every attempt on this path for this camera in the
13959
- * window. A failure count published without it is the mistake this schema
13960
- * exists to make impossible.
13961
- */
13962
- attempts: number().int().nonnegative(),
13963
- /** Attempts that landed. `attempts - succeeded` is the loss. */
13964
- succeeded: number().int().nonnegative(),
13965
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
13966
- reasons: array(FailureReasonCountSchema).readonly()
13967
- });
13968
- method(_void(), array(FailureContributionSchema).readonly());
13969
- var LoadContributionSchema = object({
13970
- role: _enum([
13971
- "decode",
13972
- "transcode",
13973
- "recording",
13974
- "streaming",
13975
- "detection"
13976
- ]),
13977
- /**
13978
- * The NUMERIC device id — the same value every log line carries as
13979
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13980
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
13981
- * contributor that cannot name its camera must not emit the entry at all,
13982
- * because an unnamed per-camera entry is indistinguishable from a shared one
13983
- * and would quietly turn one camera's cost into everybody's.
13984
- */
13985
- deviceId: number().int().positive().nullable(),
13986
- attribution: _enum([
13987
- "measured",
13988
- "accounted",
13989
- "unattributable"
13990
- ]),
13991
- /**
13992
- * What ONE entry is, in the contributor's own words — `615/high`,
13993
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13994
- * family and inventing a common one would lose the only information that
13995
- * makes two entries for the same camera distinguishable.
13996
- */
13997
- unit: string$2(),
13998
- /**
13999
- * The OS process this cost lives in, when there is one. Present so a
14000
- * consumer can (a) tell two generations of the same unit apart across a
14001
- * restart, and (b) subtract claimed processes from the node's process
14002
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14003
- * process of its own.
14004
- */
14005
- pid: number().int().positive().optional(),
14006
- /**
14007
- * When this generation started. The pid's incarnation marker: a consumer
14008
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14009
- * window when this changes, because the counter restarted from zero in a new
14010
- * process.
14011
- */
14012
- startedAtMs: number().optional(),
14013
- /**
14014
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14015
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14016
- * contribution is asked for.
14017
- *
14018
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14019
- * needs a sampler, and a new per-node sampler is the defect half of
14020
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14021
- * by whoever already keeps a history; a rate cannot be un-averaged.
14022
- *
14023
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14024
- * an entry with no process.
14025
- */
14026
- cpuSeconds: number().optional(),
14027
- /** Resident bytes of this unit's process, same source and same rules. */
14028
- rssBytes: number().optional()
14029
- });
14030
- method(_void(), array(LoadContributionSchema).readonly());
14031
- /**
14032
14032
  * `login-method` — collection cap through which auth addons contribute
14033
14033
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14034
14034
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18766,12 +18766,53 @@ var MediaFileKindEnum = _enum([
18766
18766
  "keyFrameSmall",
18767
18767
  "thumbnailSmall"
18768
18768
  ]);
18769
+ /**
18770
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
18771
+ * ARE — never the bytes themselves.
18772
+ *
18773
+ * ## Why `url` and not `base64`
18774
+ *
18775
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
18776
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
18777
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
18778
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
18779
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
18780
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
18781
+ *
18782
+ * `url` points at the `event-media` data plane
18783
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
18784
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
18785
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
18786
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
18787
+ * no less protected than they were inside a `view`-level cap response — see
18788
+ * `data-plane-access.ts` for the rule and the one gap it does not close
18789
+ * (per-device scoping).
18790
+ *
18791
+ * The URL is built from the row's **stored** key, which is not always its
18792
+ * published `kind`: a track's face/plate crop is stored as `crop` under
18793
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
18794
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
18795
+ *
18796
+ * ## `base64` is TRANSITIONAL and is going away
18797
+ *
18798
+ * It is still populated for one reason: the deployed viewer's track-detail
18799
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
18800
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
18801
+ * triangle — not as absence. Removing the field before that viewer ships is an
18802
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
18803
+ * delete this line and the `withBytes` pass-through in
18804
+ * `analytics-query-facade.ts`; nothing else reads it.
18805
+ */
18769
18806
  var MediaFileSchema = object({
18770
18807
  key: string$2(),
18771
18808
  kind: MediaFileKindEnum,
18772
- base64: string$2(),
18773
18809
  sizeBytes: number(),
18774
18810
  timestamp: number()
18811
+ }).extend({
18812
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
18813
+ url: string$2(),
18814
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
18815
+ base64: string$2()
18775
18816
  });
18776
18817
  /**
18777
18818
  * One media row WITHOUT its bytes.
@@ -18783,7 +18824,9 @@ var MediaFileSchema = object({
18783
18824
  * blocks the whole view.
18784
18825
  *
18785
18826
  * `sizeBytes` is carried because it is what lets a client decide between the
18786
- * stored blob and a `?variant=thumb` rendering without fetching either.
18827
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
18828
+ * `url` because a client that had to build the plane path itself is a second
18829
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
18787
18830
  */
18788
18831
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
18789
18832
  /**
@@ -19472,6 +19515,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19472
19515
  }), array(MediaFileSchema).readonly()), method(object({
19473
19516
  trackId: string$2(),
19474
19517
  deviceId: number()
19518
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19519
+ eventId: string$2(),
19520
+ deviceId: number()
19475
19521
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19476
19522
  kind: "mutation",
19477
19523
  auth: "admin"
@@ -24479,10 +24525,24 @@ var FaceClusterSchema = object({
24479
24525
  size: number().int(),
24480
24526
  cohesion: number()
24481
24527
  });
24528
+ /**
24529
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
24530
+ * are — never the bytes.
24531
+ *
24532
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
24533
+ * track/event contract) is still populated because a deployed viewer requires
24534
+ * the field to parse a row at all; this method has no such reader. Its ONE
24535
+ * caller is the admin UI's detail modal, which was building
24536
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
24537
+ * dialog already rendering its key FRAME from the `event-media` plane.
24538
+ *
24539
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
24540
+ * media key directly, so this needed no new plane and no new access decision.
24541
+ */
24482
24542
  var MediaFileLiteSchema$1 = object({
24483
24543
  key: string$2(),
24484
24544
  kind: string$2(),
24485
- base64: string$2(),
24545
+ url: string$2(),
24486
24546
  sizeBytes: number(),
24487
24547
  timestamp: number()
24488
24548
  });
@@ -27504,10 +27564,24 @@ var PlateInfoSchema = object({
27504
27564
  */
27505
27565
  cropUrl: string$2().optional()
27506
27566
  });
27567
+ /**
27568
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
27569
+ * are — never the bytes.
27570
+ *
27571
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
27572
+ * track/event contract) is still populated because a deployed viewer requires
27573
+ * the field to parse a row at all; this method has no such reader. Its ONE
27574
+ * caller is the admin UI's detail modal, which was building
27575
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
27576
+ * dialog already rendering its key FRAME from the `event-media` plane.
27577
+ *
27578
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
27579
+ * media key directly, so this needed no new plane and no new access decision.
27580
+ */
27507
27581
  var MediaFileLiteSchema = object({
27508
27582
  key: string$2(),
27509
27583
  kind: string$2(),
27510
- base64: string$2(),
27584
+ url: string$2(),
27511
27585
  sizeBytes: number(),
27512
27586
  timestamp: number()
27513
27587
  });
@@ -35404,6 +35478,12 @@ Object.freeze({
35404
35478
  addonId: null,
35405
35479
  access: "view"
35406
35480
  },
35481
+ "pipelineAnalytics.listEventMedia": {
35482
+ capName: "pipeline-analytics",
35483
+ capScope: "device",
35484
+ addonId: null,
35485
+ access: "view"
35486
+ },
35407
35487
  "pipelineAnalytics.listGroups": {
35408
35488
  capName: "pipeline-analytics",
35409
35489
  capScope: "device",
@@ -39027,6 +39107,11 @@ Object.freeze({
39027
39107
  form: "array",
39028
39108
  optional: false
39029
39109
  }],
39110
+ "pipelineAnalytics.listEventMedia": [{
39111
+ name: "deviceId",
39112
+ form: "single",
39113
+ optional: false
39114
+ }],
39030
39115
  "pipelineAnalytics.listGroups": [{
39031
39116
  name: "deviceIds",
39032
39117
  form: "array",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@camstack/addon-matter-broker",
3
- "version": "0.2.45",
3
+ "version": "0.2.46",
4
4
  "description": "Matter broker addon for CamStack — owns a Matter fabric (commissioning + the long-lived controller) via the matter.js controller and brokers commissioned Matter nodes into CamStack",
5
5
  "keywords": [
6
6
  "camstack",