@camstack/addon-provider-hikvision 1.2.54 → 1.2.55

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 +278 -193
  2. package/dist/addon.mjs +278 -193
  3. package/package.json +1 -1
package/dist/addon.js CHANGED
@@ -13472,6 +13472,133 @@ method(object({
13472
13472
  height: number()
13473
13473
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13474
13474
  /**
13475
+ * `failure-contribution` — the capability an addon reports its OWN losses
13476
+ * through, per camera, with the denominator attached. It stores nothing.
13477
+ *
13478
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
13479
+ *
13480
+ * `load-contribution` answers *what did this camera COST*. This answers *what
13481
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
13482
+ * copied: the contributor reports what it already knows, hub-main adds only
13483
+ * `addonId`, nothing needs global knowledge, and there is no central list for
13484
+ * somebody to forget to edit.
13485
+ *
13486
+ * They are not merged, because their invariants are opposites:
13487
+ *
13488
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
13489
+ * claim a camera cost nothing, which is a measurement nobody made;
13490
+ * - a `failure-contribution` zero is the **most valuable value on the
13491
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13492
+ * and it is exactly what an absent entry cannot say.
13493
+ *
13494
+ * Putting a loss counter on a cost entry would also break the reconciliation
13495
+ * that gives `load-contribution` its point: contributions are subtracted from
13496
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13497
+ * has no process.
13498
+ *
13499
+ * ## Why not a log line, since the counters already exist
13500
+ *
13501
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
13502
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13503
+ * ends in a log line, and a log line is the thing the operator asked to stop
13504
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13505
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13506
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13507
+ * media blackout were both diagnosed. The counters stay; this is where they can
13508
+ * be READ.
13509
+ *
13510
+ * ## The rate is served with its denominator or not at all
13511
+ *
13512
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
13513
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13514
+ * than yesterday" and was **flat across twelve hours** once divided by the
13515
+ * successes on the same path. A surface that publishes only the numerator
13516
+ * reproduces that mistake on every read.
13517
+ *
13518
+ * ## Shape
13519
+ *
13520
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13521
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13522
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13523
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13524
+ * a forked runner's entries reach hub-main over transport that already exists.
13525
+ * No new UDS message, no second registry (D3). The operator reads the assembled
13526
+ * result through `system.getFailureContributions`.
13527
+ */
13528
+ var FailureReasonCountSchema = object({
13529
+ /**
13530
+ * Why the attempt did not land, in the contributor's own vocabulary —
13531
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13532
+ * strings that already appear in this repo's logs and, where one exists, the
13533
+ * same string the per-track `previewMissReason` records (D276): a second
13534
+ * vocabulary for the same loss would make the row and the counter
13535
+ * un-joinable.
13536
+ */
13537
+ reason: string(),
13538
+ count: number().int().nonnegative()
13539
+ });
13540
+ var FailureContributionSchema = object({
13541
+ /**
13542
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13543
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13544
+ * `unit` free: the families are owned by different addons and a shared enum
13545
+ * is a central list that rots invisibly.
13546
+ */
13547
+ family: string(),
13548
+ /**
13549
+ * The NUMERIC device id — the same value every log line carries as
13550
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
13551
+ * cannot name the camera must not emit the entry, because a fleet total
13552
+ * cannot answer the only question anybody asks of this surface.
13553
+ */
13554
+ deviceId: number().int().positive(),
13555
+ /**
13556
+ * A second dimension inside the family: the model / step id for an inference
13557
+ * timeout, so "which camera AND which model" is one read. Absent when the
13558
+ * family has a single variant.
13559
+ */
13560
+ variant: string().optional(),
13561
+ /**
13562
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13563
+ * differencing two reads must drop the interval when it changes, because the
13564
+ * counter restarted from zero in a respawned runner. Same discipline as
13565
+ * `LoadContribution.startedAtMs`.
13566
+ */
13567
+ sinceMs: number(),
13568
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13569
+ atMs: number(),
13570
+ /**
13571
+ * THE DENOMINATOR — every attempt on this path for this camera in the
13572
+ * window. A failure count published without it is the mistake this schema
13573
+ * exists to make impossible.
13574
+ */
13575
+ attempts: number().int().nonnegative(),
13576
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
13577
+ succeeded: number().int().nonnegative(),
13578
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
13579
+ reasons: array(FailureReasonCountSchema).readonly()
13580
+ });
13581
+ var failureContributionCapability = {
13582
+ name: "failure-contribution",
13583
+ scope: "system",
13584
+ mode: "collection",
13585
+ internal: true,
13586
+ methods: {
13587
+ /**
13588
+ * This addon's per-camera failure counters, read live from bounded in-RAM
13589
+ * state it already keeps. Inert: no persistence, no sampling, no timer.
13590
+ *
13591
+ * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
13592
+ * consumer that wants a rate differences two reads. A draining read would
13593
+ * make two operators with the page open each destroy half of the other's
13594
+ * numbers, and `load-contribution` already settled the same question the
13595
+ * same way for `cpuSeconds`.
13596
+ */
13597
+ list: method(_void(), array(FailureContributionSchema).readonly()) },
13598
+ /** In-process only — enumerated through `addons.listCapabilityProviders`. */
13599
+ mount: { kind: "skip" }
13600
+ };
13601
+ /**
13475
13602
  * filesystem-browse — per-node capability for browsing the node's local
13476
13603
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13477
13604
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13993,6 +14120,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13993
14120
  kind: "mutation",
13994
14121
  auth: "admin"
13995
14122
  });
14123
+ var LoadContributionSchema = object({
14124
+ role: _enum([
14125
+ "decode",
14126
+ "transcode",
14127
+ "recording",
14128
+ "streaming",
14129
+ "detection"
14130
+ ]),
14131
+ /**
14132
+ * The NUMERIC device id — the same value every log line carries as
14133
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14134
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
14135
+ * contributor that cannot name its camera must not emit the entry at all,
14136
+ * because an unnamed per-camera entry is indistinguishable from a shared one
14137
+ * and would quietly turn one camera's cost into everybody's.
14138
+ */
14139
+ deviceId: number().int().positive().nullable(),
14140
+ attribution: _enum([
14141
+ "measured",
14142
+ "accounted",
14143
+ "unattributable"
14144
+ ]),
14145
+ /**
14146
+ * What ONE entry is, in the contributor's own words — `615/high`,
14147
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14148
+ * family and inventing a common one would lose the only information that
14149
+ * makes two entries for the same camera distinguishable.
14150
+ */
14151
+ unit: string(),
14152
+ /**
14153
+ * The OS process this cost lives in, when there is one. Present so a
14154
+ * consumer can (a) tell two generations of the same unit apart across a
14155
+ * restart, and (b) subtract claimed processes from the node's process
14156
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14157
+ * process of its own.
14158
+ */
14159
+ pid: number().int().positive().optional(),
14160
+ /**
14161
+ * When this generation started. The pid's incarnation marker: a consumer
14162
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14163
+ * window when this changes, because the counter restarted from zero in a new
14164
+ * process.
14165
+ */
14166
+ startedAtMs: number().optional(),
14167
+ /**
14168
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14169
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
14170
+ * contribution is asked for.
14171
+ *
14172
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
14173
+ * needs a sampler, and a new per-node sampler is the defect half of
14174
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14175
+ * by whoever already keeps a history; a rate cannot be un-averaged.
14176
+ *
14177
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14178
+ * an entry with no process.
14179
+ */
14180
+ cpuSeconds: number().optional(),
14181
+ /** Resident bytes of this unit's process, same source and same rules. */
14182
+ rssBytes: number().optional()
14183
+ });
14184
+ method(_void(), array(LoadContributionSchema).readonly());
13996
14185
  /**
13997
14186
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13998
14187
  * through. It stores nothing.
@@ -14069,195 +14258,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
14069
14258
  tags: record(string(), string()).optional()
14070
14259
  }), array(LogEntrySchema).readonly());
14071
14260
  /**
14072
- * `failure-contribution` — the capability an addon reports its OWN losses
14073
- * through, per camera, with the denominator attached. It stores nothing.
14074
- *
14075
- * ## The twin of `load-contribution`, and why it is a twin and not a field
14076
- *
14077
- * `load-contribution` answers *what did this camera COST*. This answers *what
14078
- * did this camera LOSE*. The reporting discipline is identical and deliberately
14079
- * copied: the contributor reports what it already knows, hub-main adds only
14080
- * `addonId`, nothing needs global knowledge, and there is no central list for
14081
- * somebody to forget to edit.
14082
- *
14083
- * They are not merged, because their invariants are opposites:
14084
- *
14085
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
14086
- * claim a camera cost nothing, which is a measurement nobody made;
14087
- * - a `failure-contribution` zero is the **most valuable value on the
14088
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14089
- * and it is exactly what an absent entry cannot say.
14090
- *
14091
- * Putting a loss counter on a cost entry would also break the reconciliation
14092
- * that gives `load-contribution` its point: contributions are subtracted from
14093
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14094
- * has no process.
14095
- *
14096
- * ## Why not a log line, since the counters already exist
14097
- *
14098
- * Several of these paths already counted themselves — `CaptureScheduler`'s
14099
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14100
- * ends in a log line, and a log line is the thing the operator asked to stop
14101
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14102
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14103
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14104
- * media blackout were both diagnosed. The counters stay; this is where they can
14105
- * be READ.
14106
- *
14107
- * ## The rate is served with its denominator or not at all
14108
- *
14109
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
14110
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14111
- * than yesterday" and was **flat across twelve hours** once divided by the
14112
- * successes on the same path. A surface that publishes only the numerator
14113
- * reproduces that mistake on every read.
14114
- *
14115
- * ## Shape
14116
- *
14117
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14118
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14119
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14120
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14121
- * a forked runner's entries reach hub-main over transport that already exists.
14122
- * No new UDS message, no second registry (D3). The operator reads the assembled
14123
- * result through `system.getFailureContributions`.
14124
- */
14125
- var FailureReasonCountSchema = object({
14126
- /**
14127
- * Why the attempt did not land, in the contributor's own vocabulary —
14128
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14129
- * strings that already appear in this repo's logs and, where one exists, the
14130
- * same string the per-track `previewMissReason` records (D276): a second
14131
- * vocabulary for the same loss would make the row and the counter
14132
- * un-joinable.
14133
- */
14134
- reason: string(),
14135
- count: number().int().nonnegative()
14136
- });
14137
- var FailureContributionSchema = object({
14138
- /**
14139
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14140
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14141
- * `unit` free: the families are owned by different addons and a shared enum
14142
- * is a central list that rots invisibly.
14143
- */
14144
- family: string(),
14145
- /**
14146
- * The NUMERIC device id — the same value every log line carries as
14147
- * `tags.deviceId`. Never nullable and never absent: a contributor that
14148
- * cannot name the camera must not emit the entry, because a fleet total
14149
- * cannot answer the only question anybody asks of this surface.
14150
- */
14151
- deviceId: number().int().positive(),
14152
- /**
14153
- * A second dimension inside the family: the model / step id for an inference
14154
- * timeout, so "which camera AND which model" is one read. Absent when the
14155
- * family has a single variant.
14156
- */
14157
- variant: string().optional(),
14158
- /**
14159
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14160
- * differencing two reads must drop the interval when it changes, because the
14161
- * counter restarted from zero in a respawned runner. Same discipline as
14162
- * `LoadContribution.startedAtMs`.
14163
- */
14164
- sinceMs: number(),
14165
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14166
- atMs: number(),
14167
- /**
14168
- * THE DENOMINATOR — every attempt on this path for this camera in the
14169
- * window. A failure count published without it is the mistake this schema
14170
- * exists to make impossible.
14171
- */
14172
- attempts: number().int().nonnegative(),
14173
- /** Attempts that landed. `attempts - succeeded` is the loss. */
14174
- succeeded: number().int().nonnegative(),
14175
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
14176
- reasons: array(FailureReasonCountSchema).readonly()
14177
- });
14178
- var failureContributionCapability = {
14179
- name: "failure-contribution",
14180
- scope: "system",
14181
- mode: "collection",
14182
- internal: true,
14183
- methods: {
14184
- /**
14185
- * This addon's per-camera failure counters, read live from bounded in-RAM
14186
- * state it already keeps. Inert: no persistence, no sampling, no timer.
14187
- *
14188
- * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
14189
- * consumer that wants a rate differences two reads. A draining read would
14190
- * make two operators with the page open each destroy half of the other's
14191
- * numbers, and `load-contribution` already settled the same question the
14192
- * same way for `cpuSeconds`.
14193
- */
14194
- list: method(_void(), array(FailureContributionSchema).readonly()) },
14195
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
14196
- mount: { kind: "skip" }
14197
- };
14198
- var LoadContributionSchema = object({
14199
- role: _enum([
14200
- "decode",
14201
- "transcode",
14202
- "recording",
14203
- "streaming",
14204
- "detection"
14205
- ]),
14206
- /**
14207
- * The NUMERIC device id — the same value every log line carries as
14208
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14209
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
14210
- * contributor that cannot name its camera must not emit the entry at all,
14211
- * because an unnamed per-camera entry is indistinguishable from a shared one
14212
- * and would quietly turn one camera's cost into everybody's.
14213
- */
14214
- deviceId: number().int().positive().nullable(),
14215
- attribution: _enum([
14216
- "measured",
14217
- "accounted",
14218
- "unattributable"
14219
- ]),
14220
- /**
14221
- * What ONE entry is, in the contributor's own words — `615/high`,
14222
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14223
- * family and inventing a common one would lose the only information that
14224
- * makes two entries for the same camera distinguishable.
14225
- */
14226
- unit: string(),
14227
- /**
14228
- * The OS process this cost lives in, when there is one. Present so a
14229
- * consumer can (a) tell two generations of the same unit apart across a
14230
- * restart, and (b) subtract claimed processes from the node's process
14231
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14232
- * process of its own.
14233
- */
14234
- pid: number().int().positive().optional(),
14235
- /**
14236
- * When this generation started. The pid's incarnation marker: a consumer
14237
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14238
- * window when this changes, because the counter restarted from zero in a new
14239
- * process.
14240
- */
14241
- startedAtMs: number().optional(),
14242
- /**
14243
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14244
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14245
- * contribution is asked for.
14246
- *
14247
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14248
- * needs a sampler, and a new per-node sampler is the defect half of
14249
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14250
- * by whoever already keeps a history; a rate cannot be un-averaged.
14251
- *
14252
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14253
- * an entry with no process.
14254
- */
14255
- cpuSeconds: number().optional(),
14256
- /** Resident bytes of this unit's process, same source and same rules. */
14257
- rssBytes: number().optional()
14258
- });
14259
- method(_void(), array(LoadContributionSchema).readonly());
14260
- /**
14261
14261
  * `login-method` — collection cap through which auth addons contribute
14262
14262
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14263
14263
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18995,12 +18995,53 @@ var MediaFileKindEnum = _enum([
18995
18995
  "keyFrameSmall",
18996
18996
  "thumbnailSmall"
18997
18997
  ]);
18998
+ /**
18999
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
19000
+ * ARE — never the bytes themselves.
19001
+ *
19002
+ * ## Why `url` and not `base64`
19003
+ *
19004
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
19005
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
19006
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
19007
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
19008
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
19009
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
19010
+ *
19011
+ * `url` points at the `event-media` data plane
19012
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
19013
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
19014
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
19015
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
19016
+ * no less protected than they were inside a `view`-level cap response — see
19017
+ * `data-plane-access.ts` for the rule and the one gap it does not close
19018
+ * (per-device scoping).
19019
+ *
19020
+ * The URL is built from the row's **stored** key, which is not always its
19021
+ * published `kind`: a track's face/plate crop is stored as `crop` under
19022
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
19023
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
19024
+ *
19025
+ * ## `base64` is TRANSITIONAL and is going away
19026
+ *
19027
+ * It is still populated for one reason: the deployed viewer's track-detail
19028
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
19029
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
19030
+ * triangle — not as absence. Removing the field before that viewer ships is an
19031
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
19032
+ * delete this line and the `withBytes` pass-through in
19033
+ * `analytics-query-facade.ts`; nothing else reads it.
19034
+ */
18998
19035
  var MediaFileSchema = object({
18999
19036
  key: string(),
19000
19037
  kind: MediaFileKindEnum,
19001
- base64: string(),
19002
19038
  sizeBytes: number(),
19003
19039
  timestamp: number()
19040
+ }).extend({
19041
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
19042
+ url: string(),
19043
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
19044
+ base64: string()
19004
19045
  });
19005
19046
  /**
19006
19047
  * One media row WITHOUT its bytes.
@@ -19012,7 +19053,9 @@ var MediaFileSchema = object({
19012
19053
  * blocks the whole view.
19013
19054
  *
19014
19055
  * `sizeBytes` is carried because it is what lets a client decide between the
19015
- * stored blob and a `?variant=thumb` rendering without fetching either.
19056
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
19057
+ * `url` because a client that had to build the plane path itself is a second
19058
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
19016
19059
  */
19017
19060
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
19018
19061
  /**
@@ -19701,6 +19744,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19701
19744
  }), array(MediaFileSchema).readonly()), method(object({
19702
19745
  trackId: string(),
19703
19746
  deviceId: number()
19747
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19748
+ eventId: string(),
19749
+ deviceId: number()
19704
19750
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19705
19751
  kind: "mutation",
19706
19752
  auth: "admin"
@@ -24795,10 +24841,24 @@ var FaceClusterSchema = object({
24795
24841
  size: number().int(),
24796
24842
  cohesion: number()
24797
24843
  });
24844
+ /**
24845
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
24846
+ * are — never the bytes.
24847
+ *
24848
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
24849
+ * track/event contract) is still populated because a deployed viewer requires
24850
+ * the field to parse a row at all; this method has no such reader. Its ONE
24851
+ * caller is the admin UI's detail modal, which was building
24852
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
24853
+ * dialog already rendering its key FRAME from the `event-media` plane.
24854
+ *
24855
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
24856
+ * media key directly, so this needed no new plane and no new access decision.
24857
+ */
24798
24858
  var MediaFileLiteSchema$1 = object({
24799
24859
  key: string(),
24800
24860
  kind: string(),
24801
- base64: string(),
24861
+ url: string(),
24802
24862
  sizeBytes: number(),
24803
24863
  timestamp: number()
24804
24864
  });
@@ -27866,10 +27926,24 @@ var PlateInfoSchema = object({
27866
27926
  */
27867
27927
  cropUrl: string().optional()
27868
27928
  });
27929
+ /**
27930
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
27931
+ * are — never the bytes.
27932
+ *
27933
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
27934
+ * track/event contract) is still populated because a deployed viewer requires
27935
+ * the field to parse a row at all; this method has no such reader. Its ONE
27936
+ * caller is the admin UI's detail modal, which was building
27937
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
27938
+ * dialog already rendering its key FRAME from the `event-media` plane.
27939
+ *
27940
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
27941
+ * media key directly, so this needed no new plane and no new access decision.
27942
+ */
27869
27943
  var MediaFileLiteSchema = object({
27870
27944
  key: string(),
27871
27945
  kind: string(),
27872
- base64: string(),
27946
+ url: string(),
27873
27947
  sizeBytes: number(),
27874
27948
  timestamp: number()
27875
27949
  });
@@ -36284,6 +36358,12 @@ Object.freeze({
36284
36358
  addonId: null,
36285
36359
  access: "view"
36286
36360
  },
36361
+ "pipelineAnalytics.listEventMedia": {
36362
+ capName: "pipeline-analytics",
36363
+ capScope: "device",
36364
+ addonId: null,
36365
+ access: "view"
36366
+ },
36287
36367
  "pipelineAnalytics.listGroups": {
36288
36368
  capName: "pipeline-analytics",
36289
36369
  capScope: "device",
@@ -39907,6 +39987,11 @@ Object.freeze({
39907
39987
  form: "array",
39908
39988
  optional: false
39909
39989
  }],
39990
+ "pipelineAnalytics.listEventMedia": [{
39991
+ name: "deviceId",
39992
+ form: "single",
39993
+ optional: false
39994
+ }],
39910
39995
  "pipelineAnalytics.listGroups": [{
39911
39996
  name: "deviceIds",
39912
39997
  form: "array",
package/dist/addon.mjs CHANGED
@@ -13473,6 +13473,133 @@ method(object({
13473
13473
  height: number()
13474
13474
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13475
13475
  /**
13476
+ * `failure-contribution` — the capability an addon reports its OWN losses
13477
+ * through, per camera, with the denominator attached. It stores nothing.
13478
+ *
13479
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
13480
+ *
13481
+ * `load-contribution` answers *what did this camera COST*. This answers *what
13482
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
13483
+ * copied: the contributor reports what it already knows, hub-main adds only
13484
+ * `addonId`, nothing needs global knowledge, and there is no central list for
13485
+ * somebody to forget to edit.
13486
+ *
13487
+ * They are not merged, because their invariants are opposites:
13488
+ *
13489
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
13490
+ * claim a camera cost nothing, which is a measurement nobody made;
13491
+ * - a `failure-contribution` zero is the **most valuable value on the
13492
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13493
+ * and it is exactly what an absent entry cannot say.
13494
+ *
13495
+ * Putting a loss counter on a cost entry would also break the reconciliation
13496
+ * that gives `load-contribution` its point: contributions are subtracted from
13497
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13498
+ * has no process.
13499
+ *
13500
+ * ## Why not a log line, since the counters already exist
13501
+ *
13502
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
13503
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13504
+ * ends in a log line, and a log line is the thing the operator asked to stop
13505
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13506
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13507
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13508
+ * media blackout were both diagnosed. The counters stay; this is where they can
13509
+ * be READ.
13510
+ *
13511
+ * ## The rate is served with its denominator or not at all
13512
+ *
13513
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
13514
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13515
+ * than yesterday" and was **flat across twelve hours** once divided by the
13516
+ * successes on the same path. A surface that publishes only the numerator
13517
+ * reproduces that mistake on every read.
13518
+ *
13519
+ * ## Shape
13520
+ *
13521
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13522
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13523
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13524
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13525
+ * a forked runner's entries reach hub-main over transport that already exists.
13526
+ * No new UDS message, no second registry (D3). The operator reads the assembled
13527
+ * result through `system.getFailureContributions`.
13528
+ */
13529
+ var FailureReasonCountSchema = object({
13530
+ /**
13531
+ * Why the attempt did not land, in the contributor's own vocabulary —
13532
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13533
+ * strings that already appear in this repo's logs and, where one exists, the
13534
+ * same string the per-track `previewMissReason` records (D276): a second
13535
+ * vocabulary for the same loss would make the row and the counter
13536
+ * un-joinable.
13537
+ */
13538
+ reason: string(),
13539
+ count: number().int().nonnegative()
13540
+ });
13541
+ var FailureContributionSchema = object({
13542
+ /**
13543
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13544
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13545
+ * `unit` free: the families are owned by different addons and a shared enum
13546
+ * is a central list that rots invisibly.
13547
+ */
13548
+ family: string(),
13549
+ /**
13550
+ * The NUMERIC device id — the same value every log line carries as
13551
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
13552
+ * cannot name the camera must not emit the entry, because a fleet total
13553
+ * cannot answer the only question anybody asks of this surface.
13554
+ */
13555
+ deviceId: number().int().positive(),
13556
+ /**
13557
+ * A second dimension inside the family: the model / step id for an inference
13558
+ * timeout, so "which camera AND which model" is one read. Absent when the
13559
+ * family has a single variant.
13560
+ */
13561
+ variant: string().optional(),
13562
+ /**
13563
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13564
+ * differencing two reads must drop the interval when it changes, because the
13565
+ * counter restarted from zero in a respawned runner. Same discipline as
13566
+ * `LoadContribution.startedAtMs`.
13567
+ */
13568
+ sinceMs: number(),
13569
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13570
+ atMs: number(),
13571
+ /**
13572
+ * THE DENOMINATOR — every attempt on this path for this camera in the
13573
+ * window. A failure count published without it is the mistake this schema
13574
+ * exists to make impossible.
13575
+ */
13576
+ attempts: number().int().nonnegative(),
13577
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
13578
+ succeeded: number().int().nonnegative(),
13579
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
13580
+ reasons: array(FailureReasonCountSchema).readonly()
13581
+ });
13582
+ var failureContributionCapability = {
13583
+ name: "failure-contribution",
13584
+ scope: "system",
13585
+ mode: "collection",
13586
+ internal: true,
13587
+ methods: {
13588
+ /**
13589
+ * This addon's per-camera failure counters, read live from bounded in-RAM
13590
+ * state it already keeps. Inert: no persistence, no sampling, no timer.
13591
+ *
13592
+ * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
13593
+ * consumer that wants a rate differences two reads. A draining read would
13594
+ * make two operators with the page open each destroy half of the other's
13595
+ * numbers, and `load-contribution` already settled the same question the
13596
+ * same way for `cpuSeconds`.
13597
+ */
13598
+ list: method(_void(), array(FailureContributionSchema).readonly()) },
13599
+ /** In-process only — enumerated through `addons.listCapabilityProviders`. */
13600
+ mount: { kind: "skip" }
13601
+ };
13602
+ /**
13476
13603
  * filesystem-browse — per-node capability for browsing the node's local
13477
13604
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13478
13605
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13994,6 +14121,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13994
14121
  kind: "mutation",
13995
14122
  auth: "admin"
13996
14123
  });
14124
+ var LoadContributionSchema = object({
14125
+ role: _enum([
14126
+ "decode",
14127
+ "transcode",
14128
+ "recording",
14129
+ "streaming",
14130
+ "detection"
14131
+ ]),
14132
+ /**
14133
+ * The NUMERIC device id — the same value every log line carries as
14134
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14135
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
14136
+ * contributor that cannot name its camera must not emit the entry at all,
14137
+ * because an unnamed per-camera entry is indistinguishable from a shared one
14138
+ * and would quietly turn one camera's cost into everybody's.
14139
+ */
14140
+ deviceId: number().int().positive().nullable(),
14141
+ attribution: _enum([
14142
+ "measured",
14143
+ "accounted",
14144
+ "unattributable"
14145
+ ]),
14146
+ /**
14147
+ * What ONE entry is, in the contributor's own words — `615/high`,
14148
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14149
+ * family and inventing a common one would lose the only information that
14150
+ * makes two entries for the same camera distinguishable.
14151
+ */
14152
+ unit: string(),
14153
+ /**
14154
+ * The OS process this cost lives in, when there is one. Present so a
14155
+ * consumer can (a) tell two generations of the same unit apart across a
14156
+ * restart, and (b) subtract claimed processes from the node's process
14157
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14158
+ * process of its own.
14159
+ */
14160
+ pid: number().int().positive().optional(),
14161
+ /**
14162
+ * When this generation started. The pid's incarnation marker: a consumer
14163
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14164
+ * window when this changes, because the counter restarted from zero in a new
14165
+ * process.
14166
+ */
14167
+ startedAtMs: number().optional(),
14168
+ /**
14169
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14170
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
14171
+ * contribution is asked for.
14172
+ *
14173
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
14174
+ * needs a sampler, and a new per-node sampler is the defect half of
14175
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14176
+ * by whoever already keeps a history; a rate cannot be un-averaged.
14177
+ *
14178
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14179
+ * an entry with no process.
14180
+ */
14181
+ cpuSeconds: number().optional(),
14182
+ /** Resident bytes of this unit's process, same source and same rules. */
14183
+ rssBytes: number().optional()
14184
+ });
14185
+ method(_void(), array(LoadContributionSchema).readonly());
13997
14186
  /**
13998
14187
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13999
14188
  * through. It stores nothing.
@@ -14070,195 +14259,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
14070
14259
  tags: record(string(), string()).optional()
14071
14260
  }), array(LogEntrySchema).readonly());
14072
14261
  /**
14073
- * `failure-contribution` — the capability an addon reports its OWN losses
14074
- * through, per camera, with the denominator attached. It stores nothing.
14075
- *
14076
- * ## The twin of `load-contribution`, and why it is a twin and not a field
14077
- *
14078
- * `load-contribution` answers *what did this camera COST*. This answers *what
14079
- * did this camera LOSE*. The reporting discipline is identical and deliberately
14080
- * copied: the contributor reports what it already knows, hub-main adds only
14081
- * `addonId`, nothing needs global knowledge, and there is no central list for
14082
- * somebody to forget to edit.
14083
- *
14084
- * They are not merged, because their invariants are opposites:
14085
- *
14086
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
14087
- * claim a camera cost nothing, which is a measurement nobody made;
14088
- * - a `failure-contribution` zero is the **most valuable value on the
14089
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14090
- * and it is exactly what an absent entry cannot say.
14091
- *
14092
- * Putting a loss counter on a cost entry would also break the reconciliation
14093
- * that gives `load-contribution` its point: contributions are subtracted from
14094
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14095
- * has no process.
14096
- *
14097
- * ## Why not a log line, since the counters already exist
14098
- *
14099
- * Several of these paths already counted themselves — `CaptureScheduler`'s
14100
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14101
- * ends in a log line, and a log line is the thing the operator asked to stop
14102
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14103
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14104
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14105
- * media blackout were both diagnosed. The counters stay; this is where they can
14106
- * be READ.
14107
- *
14108
- * ## The rate is served with its denominator or not at all
14109
- *
14110
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
14111
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14112
- * than yesterday" and was **flat across twelve hours** once divided by the
14113
- * successes on the same path. A surface that publishes only the numerator
14114
- * reproduces that mistake on every read.
14115
- *
14116
- * ## Shape
14117
- *
14118
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14119
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14120
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14121
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14122
- * a forked runner's entries reach hub-main over transport that already exists.
14123
- * No new UDS message, no second registry (D3). The operator reads the assembled
14124
- * result through `system.getFailureContributions`.
14125
- */
14126
- var FailureReasonCountSchema = object({
14127
- /**
14128
- * Why the attempt did not land, in the contributor's own vocabulary —
14129
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14130
- * strings that already appear in this repo's logs and, where one exists, the
14131
- * same string the per-track `previewMissReason` records (D276): a second
14132
- * vocabulary for the same loss would make the row and the counter
14133
- * un-joinable.
14134
- */
14135
- reason: string(),
14136
- count: number().int().nonnegative()
14137
- });
14138
- var FailureContributionSchema = object({
14139
- /**
14140
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14141
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14142
- * `unit` free: the families are owned by different addons and a shared enum
14143
- * is a central list that rots invisibly.
14144
- */
14145
- family: string(),
14146
- /**
14147
- * The NUMERIC device id — the same value every log line carries as
14148
- * `tags.deviceId`. Never nullable and never absent: a contributor that
14149
- * cannot name the camera must not emit the entry, because a fleet total
14150
- * cannot answer the only question anybody asks of this surface.
14151
- */
14152
- deviceId: number().int().positive(),
14153
- /**
14154
- * A second dimension inside the family: the model / step id for an inference
14155
- * timeout, so "which camera AND which model" is one read. Absent when the
14156
- * family has a single variant.
14157
- */
14158
- variant: string().optional(),
14159
- /**
14160
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14161
- * differencing two reads must drop the interval when it changes, because the
14162
- * counter restarted from zero in a respawned runner. Same discipline as
14163
- * `LoadContribution.startedAtMs`.
14164
- */
14165
- sinceMs: number(),
14166
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14167
- atMs: number(),
14168
- /**
14169
- * THE DENOMINATOR — every attempt on this path for this camera in the
14170
- * window. A failure count published without it is the mistake this schema
14171
- * exists to make impossible.
14172
- */
14173
- attempts: number().int().nonnegative(),
14174
- /** Attempts that landed. `attempts - succeeded` is the loss. */
14175
- succeeded: number().int().nonnegative(),
14176
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
14177
- reasons: array(FailureReasonCountSchema).readonly()
14178
- });
14179
- var failureContributionCapability = {
14180
- name: "failure-contribution",
14181
- scope: "system",
14182
- mode: "collection",
14183
- internal: true,
14184
- methods: {
14185
- /**
14186
- * This addon's per-camera failure counters, read live from bounded in-RAM
14187
- * state it already keeps. Inert: no persistence, no sampling, no timer.
14188
- *
14189
- * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
14190
- * consumer that wants a rate differences two reads. A draining read would
14191
- * make two operators with the page open each destroy half of the other's
14192
- * numbers, and `load-contribution` already settled the same question the
14193
- * same way for `cpuSeconds`.
14194
- */
14195
- list: method(_void(), array(FailureContributionSchema).readonly()) },
14196
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
14197
- mount: { kind: "skip" }
14198
- };
14199
- var LoadContributionSchema = object({
14200
- role: _enum([
14201
- "decode",
14202
- "transcode",
14203
- "recording",
14204
- "streaming",
14205
- "detection"
14206
- ]),
14207
- /**
14208
- * The NUMERIC device id — the same value every log line carries as
14209
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14210
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
14211
- * contributor that cannot name its camera must not emit the entry at all,
14212
- * because an unnamed per-camera entry is indistinguishable from a shared one
14213
- * and would quietly turn one camera's cost into everybody's.
14214
- */
14215
- deviceId: number().int().positive().nullable(),
14216
- attribution: _enum([
14217
- "measured",
14218
- "accounted",
14219
- "unattributable"
14220
- ]),
14221
- /**
14222
- * What ONE entry is, in the contributor's own words — `615/high`,
14223
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14224
- * family and inventing a common one would lose the only information that
14225
- * makes two entries for the same camera distinguishable.
14226
- */
14227
- unit: string(),
14228
- /**
14229
- * The OS process this cost lives in, when there is one. Present so a
14230
- * consumer can (a) tell two generations of the same unit apart across a
14231
- * restart, and (b) subtract claimed processes from the node's process
14232
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14233
- * process of its own.
14234
- */
14235
- pid: number().int().positive().optional(),
14236
- /**
14237
- * When this generation started. The pid's incarnation marker: a consumer
14238
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14239
- * window when this changes, because the counter restarted from zero in a new
14240
- * process.
14241
- */
14242
- startedAtMs: number().optional(),
14243
- /**
14244
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14245
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14246
- * contribution is asked for.
14247
- *
14248
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14249
- * needs a sampler, and a new per-node sampler is the defect half of
14250
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14251
- * by whoever already keeps a history; a rate cannot be un-averaged.
14252
- *
14253
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14254
- * an entry with no process.
14255
- */
14256
- cpuSeconds: number().optional(),
14257
- /** Resident bytes of this unit's process, same source and same rules. */
14258
- rssBytes: number().optional()
14259
- });
14260
- method(_void(), array(LoadContributionSchema).readonly());
14261
- /**
14262
14262
  * `login-method` — collection cap through which auth addons contribute
14263
14263
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14264
14264
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18996,12 +18996,53 @@ var MediaFileKindEnum = _enum([
18996
18996
  "keyFrameSmall",
18997
18997
  "thumbnailSmall"
18998
18998
  ]);
18999
+ /**
19000
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
19001
+ * ARE — never the bytes themselves.
19002
+ *
19003
+ * ## Why `url` and not `base64`
19004
+ *
19005
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
19006
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
19007
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
19008
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
19009
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
19010
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
19011
+ *
19012
+ * `url` points at the `event-media` data plane
19013
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
19014
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
19015
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
19016
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
19017
+ * no less protected than they were inside a `view`-level cap response — see
19018
+ * `data-plane-access.ts` for the rule and the one gap it does not close
19019
+ * (per-device scoping).
19020
+ *
19021
+ * The URL is built from the row's **stored** key, which is not always its
19022
+ * published `kind`: a track's face/plate crop is stored as `crop` under
19023
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
19024
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
19025
+ *
19026
+ * ## `base64` is TRANSITIONAL and is going away
19027
+ *
19028
+ * It is still populated for one reason: the deployed viewer's track-detail
19029
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
19030
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
19031
+ * triangle — not as absence. Removing the field before that viewer ships is an
19032
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
19033
+ * delete this line and the `withBytes` pass-through in
19034
+ * `analytics-query-facade.ts`; nothing else reads it.
19035
+ */
18999
19036
  var MediaFileSchema = object({
19000
19037
  key: string(),
19001
19038
  kind: MediaFileKindEnum,
19002
- base64: string(),
19003
19039
  sizeBytes: number(),
19004
19040
  timestamp: number()
19041
+ }).extend({
19042
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
19043
+ url: string(),
19044
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
19045
+ base64: string()
19005
19046
  });
19006
19047
  /**
19007
19048
  * One media row WITHOUT its bytes.
@@ -19013,7 +19054,9 @@ var MediaFileSchema = object({
19013
19054
  * blocks the whole view.
19014
19055
  *
19015
19056
  * `sizeBytes` is carried because it is what lets a client decide between the
19016
- * stored blob and a `?variant=thumb` rendering without fetching either.
19057
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
19058
+ * `url` because a client that had to build the plane path itself is a second
19059
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
19017
19060
  */
19018
19061
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
19019
19062
  /**
@@ -19702,6 +19745,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19702
19745
  }), array(MediaFileSchema).readonly()), method(object({
19703
19746
  trackId: string(),
19704
19747
  deviceId: number()
19748
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19749
+ eventId: string(),
19750
+ deviceId: number()
19705
19751
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19706
19752
  kind: "mutation",
19707
19753
  auth: "admin"
@@ -24796,10 +24842,24 @@ var FaceClusterSchema = object({
24796
24842
  size: number().int(),
24797
24843
  cohesion: number()
24798
24844
  });
24845
+ /**
24846
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
24847
+ * are — never the bytes.
24848
+ *
24849
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
24850
+ * track/event contract) is still populated because a deployed viewer requires
24851
+ * the field to parse a row at all; this method has no such reader. Its ONE
24852
+ * caller is the admin UI's detail modal, which was building
24853
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
24854
+ * dialog already rendering its key FRAME from the `event-media` plane.
24855
+ *
24856
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
24857
+ * media key directly, so this needed no new plane and no new access decision.
24858
+ */
24799
24859
  var MediaFileLiteSchema$1 = object({
24800
24860
  key: string(),
24801
24861
  kind: string(),
24802
- base64: string(),
24862
+ url: string(),
24803
24863
  sizeBytes: number(),
24804
24864
  timestamp: number()
24805
24865
  });
@@ -27867,10 +27927,24 @@ var PlateInfoSchema = object({
27867
27927
  */
27868
27928
  cropUrl: string().optional()
27869
27929
  });
27930
+ /**
27931
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
27932
+ * are — never the bytes.
27933
+ *
27934
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
27935
+ * track/event contract) is still populated because a deployed viewer requires
27936
+ * the field to parse a row at all; this method has no such reader. Its ONE
27937
+ * caller is the admin UI's detail modal, which was building
27938
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
27939
+ * dialog already rendering its key FRAME from the `event-media` plane.
27940
+ *
27941
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
27942
+ * media key directly, so this needed no new plane and no new access decision.
27943
+ */
27870
27944
  var MediaFileLiteSchema = object({
27871
27945
  key: string(),
27872
27946
  kind: string(),
27873
- base64: string(),
27947
+ url: string(),
27874
27948
  sizeBytes: number(),
27875
27949
  timestamp: number()
27876
27950
  });
@@ -36285,6 +36359,12 @@ Object.freeze({
36285
36359
  addonId: null,
36286
36360
  access: "view"
36287
36361
  },
36362
+ "pipelineAnalytics.listEventMedia": {
36363
+ capName: "pipeline-analytics",
36364
+ capScope: "device",
36365
+ addonId: null,
36366
+ access: "view"
36367
+ },
36288
36368
  "pipelineAnalytics.listGroups": {
36289
36369
  capName: "pipeline-analytics",
36290
36370
  capScope: "device",
@@ -39908,6 +39988,11 @@ Object.freeze({
39908
39988
  form: "array",
39909
39989
  optional: false
39910
39990
  }],
39991
+ "pipelineAnalytics.listEventMedia": [{
39992
+ name: "deviceId",
39993
+ form: "single",
39994
+ optional: false
39995
+ }],
39911
39996
  "pipelineAnalytics.listGroups": [{
39912
39997
  name: "deviceIds",
39913
39998
  form: "array",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@camstack/addon-provider-hikvision",
3
- "version": "1.2.54",
3
+ "version": "1.2.55",
4
4
  "description": "Hikvision camera device provider addon for CamStack — ISAPI over HTTP(S) with digest auth (snapshot, alarm stream, RTSP discovery)",
5
5
  "keywords": [
6
6
  "camstack",