@camstack/addon-provider-hikvision 1.2.54 → 1.2.56

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 +350 -193
  2. package/dist/addon.mjs +350 -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
  /**
@@ -19359,6 +19402,50 @@ var EventStoreFootprintSchema = object({
19359
19402
  totalBytes: number().int(),
19360
19403
  devices: array(EventStoreDeviceFootprintSchema).readonly()
19361
19404
  });
19405
+ /** Event-media footprint for one {@link MediaFileKind}. */
19406
+ var EventMediaKindFootprintSchema = object({
19407
+ kind: MediaFileKindEnum,
19408
+ /** Media rows of this kind. */
19409
+ rows: number().int(),
19410
+ /** Bytes on disk held by those rows. */
19411
+ bytes: number().int()
19412
+ });
19413
+ /**
19414
+ * The media footprint broken down by KIND — the axis a deletion decision
19415
+ * actually turns on.
19416
+ *
19417
+ * A byte total says how much there is; it cannot say what is safe to remove.
19418
+ * The deletable set (the periodic `snapshot` filmstrip, the surplus per-edge
19419
+ * motion stills) and the keep set (`firstFrame`, rolling `lastFrame`,
19420
+ * `thumbnail`/`thumbnailSmall`, `keyFrame`/`keyFrameSmall`, the face/plate
19421
+ * buffers, gallery media, the CLIP `crop`) are distinguished by `kind` and by
19422
+ * nothing else, so sizing a deletion means summing per kind.
19423
+ *
19424
+ * ## Why `unaccounted*` exists
19425
+ *
19426
+ * `kinds` is enumerated from {@link MediaFileKindEnum} — the closed set the
19427
+ * writers use — and summed one kind at a time. `totalRows` / `totalBytes` come
19428
+ * from a SEPARATE unfiltered aggregate over the same rows, never from adding
19429
+ * `kinds` up. A row whose stored `kind` is not in the enum (written by a
19430
+ * retired code path, or by a version that knew a kind this one does not) would
19431
+ * otherwise vanish from the total silently, and an operator would delete
19432
+ * against a denominator smaller than the disk.
19433
+ *
19434
+ * `unaccountedRows` / `unaccountedBytes` are the difference. They are normally
19435
+ * zero; a non-zero value is a real finding and must be shown, not rounded away.
19436
+ */
19437
+ var EventMediaKindBreakdownSchema = object({
19438
+ /** Every media row in scope, from one unfiltered aggregate. */
19439
+ totalRows: number().int(),
19440
+ /** Every media byte in scope, from that same aggregate. */
19441
+ totalBytes: number().int(),
19442
+ /** Per-kind footprint, ordered by bytes descending. */
19443
+ kinds: array(EventMediaKindFootprintSchema).readonly(),
19444
+ /** `totalRows` minus the summed `kinds` rows — see the schema note. */
19445
+ unaccountedRows: number().int(),
19446
+ /** `totalBytes` minus the summed `kinds` bytes — see the schema note. */
19447
+ unaccountedBytes: number().int()
19448
+ });
19362
19449
  /** Per-kind counts returned by the event-prune / device-delete mutations. */
19363
19450
  var EventPruneCountsSchema = object({
19364
19451
  motion: number().int(),
@@ -19562,6 +19649,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19562
19649
  }), TrackFlagsSchema, { kind: "mutation" }), method(object({}), EventStoreFootprintSchema, {
19563
19650
  kind: "query",
19564
19651
  auth: "admin"
19652
+ }), method(object({ deviceId: number().int().optional() }), EventMediaKindBreakdownSchema, {
19653
+ kind: "query",
19654
+ auth: "admin"
19565
19655
  }), method(object({
19566
19656
  olderThanMs: number(),
19567
19657
  reason: OpsLogReasonSchema.optional()
@@ -19701,6 +19791,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19701
19791
  }), array(MediaFileSchema).readonly()), method(object({
19702
19792
  trackId: string(),
19703
19793
  deviceId: number()
19794
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19795
+ eventId: string(),
19796
+ deviceId: number()
19704
19797
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19705
19798
  kind: "mutation",
19706
19799
  auth: "admin"
@@ -21614,6 +21707,20 @@ method(object({
21614
21707
  error: string().optional()
21615
21708
  }), { auth: "admin" }), method(_void(), array(ProviderListEntrySchema).readonly()), method(object({
21616
21709
  providerId: string(),
21710
+ /**
21711
+ * The location this config is an UNSAVED edit of, when there is one.
21712
+ *
21713
+ * `listLocations` replaces every declared secret with the redaction
21714
+ * sentinel, so the edit modal's form state holds the sentinel for any
21715
+ * credential the operator did not retype — and posting that here
21716
+ * without a way to resolve it makes the provider try to authenticate
21717
+ * as `__camstack_redacted__` and report the operator's own working
21718
+ * password as wrong. Given this id, the orchestrator restores each
21719
+ * sentinel from the stored config (same rule as `upsertLocation`)
21720
+ * before dispatching. Omitted by the "Add location" wizard, where
21721
+ * every value was typed just now and nothing is stored yet.
21722
+ */
21723
+ locationId: string().optional(),
21617
21724
  config: record(string(), unknown())
21618
21725
  }), object({
21619
21726
  ok: boolean(),
@@ -24795,10 +24902,24 @@ var FaceClusterSchema = object({
24795
24902
  size: number().int(),
24796
24903
  cohesion: number()
24797
24904
  });
24905
+ /**
24906
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
24907
+ * are — never the bytes.
24908
+ *
24909
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
24910
+ * track/event contract) is still populated because a deployed viewer requires
24911
+ * the field to parse a row at all; this method has no such reader. Its ONE
24912
+ * caller is the admin UI's detail modal, which was building
24913
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
24914
+ * dialog already rendering its key FRAME from the `event-media` plane.
24915
+ *
24916
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
24917
+ * media key directly, so this needed no new plane and no new access decision.
24918
+ */
24798
24919
  var MediaFileLiteSchema$1 = object({
24799
24920
  key: string(),
24800
24921
  kind: string(),
24801
- base64: string(),
24922
+ url: string(),
24802
24923
  sizeBytes: number(),
24803
24924
  timestamp: number()
24804
24925
  });
@@ -27866,10 +27987,24 @@ var PlateInfoSchema = object({
27866
27987
  */
27867
27988
  cropUrl: string().optional()
27868
27989
  });
27990
+ /**
27991
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
27992
+ * are — never the bytes.
27993
+ *
27994
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
27995
+ * track/event contract) is still populated because a deployed viewer requires
27996
+ * the field to parse a row at all; this method has no such reader. Its ONE
27997
+ * caller is the admin UI's detail modal, which was building
27998
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
27999
+ * dialog already rendering its key FRAME from the `event-media` plane.
28000
+ *
28001
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
28002
+ * media key directly, so this needed no new plane and no new access decision.
28003
+ */
27869
28004
  var MediaFileLiteSchema = object({
27870
28005
  key: string(),
27871
28006
  kind: string(),
27872
- base64: string(),
28007
+ url: string(),
27873
28008
  sizeBytes: number(),
27874
28009
  timestamp: number()
27875
28010
  });
@@ -36188,6 +36323,12 @@ Object.freeze({
36188
36323
  addonId: null,
36189
36324
  access: "view"
36190
36325
  },
36326
+ "pipelineAnalytics.getEventMediaFootprintByKind": {
36327
+ capName: "pipeline-analytics",
36328
+ capScope: "device",
36329
+ addonId: null,
36330
+ access: "view"
36331
+ },
36191
36332
  "pipelineAnalytics.getEventStoreFootprint": {
36192
36333
  capName: "pipeline-analytics",
36193
36334
  capScope: "device",
@@ -36284,6 +36425,12 @@ Object.freeze({
36284
36425
  addonId: null,
36285
36426
  access: "view"
36286
36427
  },
36428
+ "pipelineAnalytics.listEventMedia": {
36429
+ capName: "pipeline-analytics",
36430
+ capScope: "device",
36431
+ addonId: null,
36432
+ access: "view"
36433
+ },
36287
36434
  "pipelineAnalytics.listGroups": {
36288
36435
  capName: "pipeline-analytics",
36289
36436
  capScope: "device",
@@ -39847,6 +39994,11 @@ Object.freeze({
39847
39994
  form: "single",
39848
39995
  optional: false
39849
39996
  }],
39997
+ "pipelineAnalytics.getEventMediaFootprintByKind": [{
39998
+ name: "deviceId",
39999
+ form: "single",
40000
+ optional: true
40001
+ }],
39850
40002
  "pipelineAnalytics.getGroup": [{
39851
40003
  name: "deviceId",
39852
40004
  form: "single",
@@ -39907,6 +40059,11 @@ Object.freeze({
39907
40059
  form: "array",
39908
40060
  optional: false
39909
40061
  }],
40062
+ "pipelineAnalytics.listEventMedia": [{
40063
+ name: "deviceId",
40064
+ form: "single",
40065
+ optional: false
40066
+ }],
39910
40067
  "pipelineAnalytics.listGroups": [{
39911
40068
  name: "deviceIds",
39912
40069
  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
  /**
@@ -19360,6 +19403,50 @@ var EventStoreFootprintSchema = object({
19360
19403
  totalBytes: number().int(),
19361
19404
  devices: array(EventStoreDeviceFootprintSchema).readonly()
19362
19405
  });
19406
+ /** Event-media footprint for one {@link MediaFileKind}. */
19407
+ var EventMediaKindFootprintSchema = object({
19408
+ kind: MediaFileKindEnum,
19409
+ /** Media rows of this kind. */
19410
+ rows: number().int(),
19411
+ /** Bytes on disk held by those rows. */
19412
+ bytes: number().int()
19413
+ });
19414
+ /**
19415
+ * The media footprint broken down by KIND — the axis a deletion decision
19416
+ * actually turns on.
19417
+ *
19418
+ * A byte total says how much there is; it cannot say what is safe to remove.
19419
+ * The deletable set (the periodic `snapshot` filmstrip, the surplus per-edge
19420
+ * motion stills) and the keep set (`firstFrame`, rolling `lastFrame`,
19421
+ * `thumbnail`/`thumbnailSmall`, `keyFrame`/`keyFrameSmall`, the face/plate
19422
+ * buffers, gallery media, the CLIP `crop`) are distinguished by `kind` and by
19423
+ * nothing else, so sizing a deletion means summing per kind.
19424
+ *
19425
+ * ## Why `unaccounted*` exists
19426
+ *
19427
+ * `kinds` is enumerated from {@link MediaFileKindEnum} — the closed set the
19428
+ * writers use — and summed one kind at a time. `totalRows` / `totalBytes` come
19429
+ * from a SEPARATE unfiltered aggregate over the same rows, never from adding
19430
+ * `kinds` up. A row whose stored `kind` is not in the enum (written by a
19431
+ * retired code path, or by a version that knew a kind this one does not) would
19432
+ * otherwise vanish from the total silently, and an operator would delete
19433
+ * against a denominator smaller than the disk.
19434
+ *
19435
+ * `unaccountedRows` / `unaccountedBytes` are the difference. They are normally
19436
+ * zero; a non-zero value is a real finding and must be shown, not rounded away.
19437
+ */
19438
+ var EventMediaKindBreakdownSchema = object({
19439
+ /** Every media row in scope, from one unfiltered aggregate. */
19440
+ totalRows: number().int(),
19441
+ /** Every media byte in scope, from that same aggregate. */
19442
+ totalBytes: number().int(),
19443
+ /** Per-kind footprint, ordered by bytes descending. */
19444
+ kinds: array(EventMediaKindFootprintSchema).readonly(),
19445
+ /** `totalRows` minus the summed `kinds` rows — see the schema note. */
19446
+ unaccountedRows: number().int(),
19447
+ /** `totalBytes` minus the summed `kinds` bytes — see the schema note. */
19448
+ unaccountedBytes: number().int()
19449
+ });
19363
19450
  /** Per-kind counts returned by the event-prune / device-delete mutations. */
19364
19451
  var EventPruneCountsSchema = object({
19365
19452
  motion: number().int(),
@@ -19563,6 +19650,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19563
19650
  }), TrackFlagsSchema, { kind: "mutation" }), method(object({}), EventStoreFootprintSchema, {
19564
19651
  kind: "query",
19565
19652
  auth: "admin"
19653
+ }), method(object({ deviceId: number().int().optional() }), EventMediaKindBreakdownSchema, {
19654
+ kind: "query",
19655
+ auth: "admin"
19566
19656
  }), method(object({
19567
19657
  olderThanMs: number(),
19568
19658
  reason: OpsLogReasonSchema.optional()
@@ -19702,6 +19792,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19702
19792
  }), array(MediaFileSchema).readonly()), method(object({
19703
19793
  trackId: string(),
19704
19794
  deviceId: number()
19795
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19796
+ eventId: string(),
19797
+ deviceId: number()
19705
19798
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19706
19799
  kind: "mutation",
19707
19800
  auth: "admin"
@@ -21615,6 +21708,20 @@ method(object({
21615
21708
  error: string().optional()
21616
21709
  }), { auth: "admin" }), method(_void(), array(ProviderListEntrySchema).readonly()), method(object({
21617
21710
  providerId: string(),
21711
+ /**
21712
+ * The location this config is an UNSAVED edit of, when there is one.
21713
+ *
21714
+ * `listLocations` replaces every declared secret with the redaction
21715
+ * sentinel, so the edit modal's form state holds the sentinel for any
21716
+ * credential the operator did not retype — and posting that here
21717
+ * without a way to resolve it makes the provider try to authenticate
21718
+ * as `__camstack_redacted__` and report the operator's own working
21719
+ * password as wrong. Given this id, the orchestrator restores each
21720
+ * sentinel from the stored config (same rule as `upsertLocation`)
21721
+ * before dispatching. Omitted by the "Add location" wizard, where
21722
+ * every value was typed just now and nothing is stored yet.
21723
+ */
21724
+ locationId: string().optional(),
21618
21725
  config: record(string(), unknown())
21619
21726
  }), object({
21620
21727
  ok: boolean(),
@@ -24796,10 +24903,24 @@ var FaceClusterSchema = object({
24796
24903
  size: number().int(),
24797
24904
  cohesion: number()
24798
24905
  });
24906
+ /**
24907
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
24908
+ * are — never the bytes.
24909
+ *
24910
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
24911
+ * track/event contract) is still populated because a deployed viewer requires
24912
+ * the field to parse a row at all; this method has no such reader. Its ONE
24913
+ * caller is the admin UI's detail modal, which was building
24914
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
24915
+ * dialog already rendering its key FRAME from the `event-media` plane.
24916
+ *
24917
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
24918
+ * media key directly, so this needed no new plane and no new access decision.
24919
+ */
24799
24920
  var MediaFileLiteSchema$1 = object({
24800
24921
  key: string(),
24801
24922
  kind: string(),
24802
- base64: string(),
24923
+ url: string(),
24803
24924
  sizeBytes: number(),
24804
24925
  timestamp: number()
24805
24926
  });
@@ -27867,10 +27988,24 @@ var PlateInfoSchema = object({
27867
27988
  */
27868
27989
  cropUrl: string().optional()
27869
27990
  });
27991
+ /**
27992
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
27993
+ * are — never the bytes.
27994
+ *
27995
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
27996
+ * track/event contract) is still populated because a deployed viewer requires
27997
+ * the field to parse a row at all; this method has no such reader. Its ONE
27998
+ * caller is the admin UI's detail modal, which was building
27999
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
28000
+ * dialog already rendering its key FRAME from the `event-media` plane.
28001
+ *
28002
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
28003
+ * media key directly, so this needed no new plane and no new access decision.
28004
+ */
27870
28005
  var MediaFileLiteSchema = object({
27871
28006
  key: string(),
27872
28007
  kind: string(),
27873
- base64: string(),
28008
+ url: string(),
27874
28009
  sizeBytes: number(),
27875
28010
  timestamp: number()
27876
28011
  });
@@ -36189,6 +36324,12 @@ Object.freeze({
36189
36324
  addonId: null,
36190
36325
  access: "view"
36191
36326
  },
36327
+ "pipelineAnalytics.getEventMediaFootprintByKind": {
36328
+ capName: "pipeline-analytics",
36329
+ capScope: "device",
36330
+ addonId: null,
36331
+ access: "view"
36332
+ },
36192
36333
  "pipelineAnalytics.getEventStoreFootprint": {
36193
36334
  capName: "pipeline-analytics",
36194
36335
  capScope: "device",
@@ -36285,6 +36426,12 @@ Object.freeze({
36285
36426
  addonId: null,
36286
36427
  access: "view"
36287
36428
  },
36429
+ "pipelineAnalytics.listEventMedia": {
36430
+ capName: "pipeline-analytics",
36431
+ capScope: "device",
36432
+ addonId: null,
36433
+ access: "view"
36434
+ },
36288
36435
  "pipelineAnalytics.listGroups": {
36289
36436
  capName: "pipeline-analytics",
36290
36437
  capScope: "device",
@@ -39848,6 +39995,11 @@ Object.freeze({
39848
39995
  form: "single",
39849
39996
  optional: false
39850
39997
  }],
39998
+ "pipelineAnalytics.getEventMediaFootprintByKind": [{
39999
+ name: "deviceId",
40000
+ form: "single",
40001
+ optional: true
40002
+ }],
39851
40003
  "pipelineAnalytics.getGroup": [{
39852
40004
  name: "deviceId",
39853
40005
  form: "single",
@@ -39908,6 +40060,11 @@ Object.freeze({
39908
40060
  form: "array",
39909
40061
  optional: false
39910
40062
  }],
40063
+ "pipelineAnalytics.listEventMedia": [{
40064
+ name: "deviceId",
40065
+ form: "single",
40066
+ optional: false
40067
+ }],
39911
40068
  "pipelineAnalytics.listGroups": [{
39912
40069
  name: "deviceIds",
39913
40070
  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.56",
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",