@camstack/addon-provider-hikvision 1.2.53 → 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 +332 -200
  2. package/dist/addon.mjs +332 -200
  3. package/package.json +1 -1
package/dist/addon.js CHANGED
@@ -7998,6 +7998,21 @@ var RelocateJobSchema = object({
7998
7998
  bytesMoved: number().int(),
7999
7999
  /** Total files discovered up front; null while (or when) unknown. */
8000
8000
  filesTotal: number().int().nullable(),
8001
+ /**
8002
+ * Rows this run CORRECTED while moving them — a durable mutation the move
8003
+ * made that nobody asked for, so it is reported where the operator reads the
8004
+ * job rather than only in a log line.
8005
+ *
8006
+ * A footage segment records its byte count in its own NAME, and the durable
8007
+ * hour row derives its aggregates from those names. A file that does not
8008
+ * match its name therefore makes the ledger's sums — and with them quota and
8009
+ * pressure eviction — wrong by the difference, and only a rename can fix it.
8010
+ * On 2026-08-30 one such row also stalled a 110 749-file drain permanently.
8011
+ *
8012
+ * Absent on lanes where the question has no meaning: a media blob's size is
8013
+ * in its row, not in its name, so `MediaRelocateEngine` never reconciles one.
8014
+ */
8015
+ rowsReconciled: number().int().nonnegative().optional(),
8001
8016
  startedAt: number(),
8002
8017
  finishedAt: number().nullable(),
8003
8018
  error: string().nullable()
@@ -8066,14 +8081,42 @@ var RelocateMediaInputSchema = object({
8066
8081
  /** Omitted = `move`, the pre-existing behaviour. */
8067
8082
  mode: MediaRelocateModeSchema.optional()
8068
8083
  });
8069
- /** How many rows still carry NO `locationId` — the population a repoint would
8070
- * silently re-aim at a disk that does not hold their bytes. Zero is the only
8071
- * value that permits a non-blocking `eventMedia` cutover. */
8072
- var UnstampedEventMediaCountSchema = object({
8073
- media: number().int().nonnegative(),
8074
- retrainFrames: number().int().nonnegative(),
8075
- total: number().int().nonnegative()
8084
+ /**
8085
+ * The unstamped population of ONE collection split, because the gate and the
8086
+ * operator ask two different questions and only one of them has to be cheap.
8087
+ *
8088
+ * `present` is the GATE: "is there at least one row that would be orphaned by a
8089
+ * repoint". It is a single indexed seek to the first matching row, so it stays
8090
+ * answerable on a saturated disk and answers in O(log n) precisely in the state
8091
+ * that matters — after a seal, when the population is empty.
8092
+ *
8093
+ * `rows` is the NUMBER, for the refusal message and the operator's sense of
8094
+ * scale. It is a second, indexed `COUNT(*)`, and `null` means **not
8095
+ * measurable** — never zero. `{ present: true, rows: null }` is a legitimate
8096
+ * and useful answer: "there are some, and this read could not say how many"
8097
+ * still refuses the cutover, which is the whole job.
8098
+ */
8099
+ var UnstampedRowsSchema = object({
8100
+ present: boolean(),
8101
+ rows: number().int().nonnegative().nullable()
8076
8102
  });
8103
+ /**
8104
+ * How many rows still carry NO `locationId` — the population a repoint would
8105
+ * silently re-aim at a disk that does not hold their bytes.
8106
+ *
8107
+ * **`null` = the count could not be taken**, and it is NOT permission to cut
8108
+ * over. The gate opens on a measured absence and on nothing else; an unread
8109
+ * collection and an empty one are different facts, and this repo has already
8110
+ * paid for conflating them (`RelocateResidueSchema`, D295).
8111
+ */
8112
+ var UnstampedEventMediaCountSchema = object({
8113
+ media: UnstampedRowsSchema,
8114
+ retrainFrames: UnstampedRowsSchema,
8115
+ /** True when EITHER collection holds one. The refusal reads this. */
8116
+ anyPresent: boolean(),
8117
+ /** Sum across both, or `null` when either lane could not be counted. */
8118
+ total: number().int().nonnegative().nullable()
8119
+ }).nullable();
8077
8120
  var StorageMigrationMediaMoveInputSchema = RelocateMediaInputSchema.extend({ leaseId: string().min(1) });
8078
8121
  /** The independently selectable logical storage classes — every class
8079
8122
  * `storage.listLocationDeclarations` reports, so an operator never meets a
@@ -8184,6 +8227,10 @@ var StorageMigrationMoveProgressSchema = object({
8184
8227
  /** The archive census — the **M** of "N of M" (D295). `null` = unknowable. */
8185
8228
  filesTotal: number().int().nonnegative().nullable(),
8186
8229
  bytesMoved: number().int().nonnegative(),
8230
+ /** Rows the mover corrected while moving them — see `RelocateJob`. Absent on
8231
+ * a lane that cannot reconcile. A migration that silently rewrote durable
8232
+ * rows would be the same failure as one that silently skipped them. */
8233
+ rowsReconciled: number().int().nonnegative().optional(),
8187
8234
  /** The MOVER's start, not the migration's: a drain restarted after an addon
8188
8235
  * crash gets a new mover, and a rate computed from the migration's start
8189
8236
  * would silently average in the time nothing was running. */
@@ -13425,6 +13472,133 @@ method(object({
13425
13472
  height: number()
13426
13473
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13427
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
+ /**
13428
13602
  * filesystem-browse — per-node capability for browsing the node's local
13429
13603
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13430
13604
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13946,6 +14120,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13946
14120
  kind: "mutation",
13947
14121
  auth: "admin"
13948
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());
13949
14185
  /**
13950
14186
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13951
14187
  * through. It stores nothing.
@@ -14022,195 +14258,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
14022
14258
  tags: record(string(), string()).optional()
14023
14259
  }), array(LogEntrySchema).readonly());
14024
14260
  /**
14025
- * `failure-contribution` — the capability an addon reports its OWN losses
14026
- * through, per camera, with the denominator attached. It stores nothing.
14027
- *
14028
- * ## The twin of `load-contribution`, and why it is a twin and not a field
14029
- *
14030
- * `load-contribution` answers *what did this camera COST*. This answers *what
14031
- * did this camera LOSE*. The reporting discipline is identical and deliberately
14032
- * copied: the contributor reports what it already knows, hub-main adds only
14033
- * `addonId`, nothing needs global knowledge, and there is no central list for
14034
- * somebody to forget to edit.
14035
- *
14036
- * They are not merged, because their invariants are opposites:
14037
- *
14038
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
14039
- * claim a camera cost nothing, which is a measurement nobody made;
14040
- * - a `failure-contribution` zero is the **most valuable value on the
14041
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14042
- * and it is exactly what an absent entry cannot say.
14043
- *
14044
- * Putting a loss counter on a cost entry would also break the reconciliation
14045
- * that gives `load-contribution` its point: contributions are subtracted from
14046
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14047
- * has no process.
14048
- *
14049
- * ## Why not a log line, since the counters already exist
14050
- *
14051
- * Several of these paths already counted themselves — `CaptureScheduler`'s
14052
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14053
- * ends in a log line, and a log line is the thing the operator asked to stop
14054
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14055
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14056
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14057
- * media blackout were both diagnosed. The counters stay; this is where they can
14058
- * be READ.
14059
- *
14060
- * ## The rate is served with its denominator or not at all
14061
- *
14062
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
14063
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14064
- * than yesterday" and was **flat across twelve hours** once divided by the
14065
- * successes on the same path. A surface that publishes only the numerator
14066
- * reproduces that mistake on every read.
14067
- *
14068
- * ## Shape
14069
- *
14070
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14071
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14072
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14073
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14074
- * a forked runner's entries reach hub-main over transport that already exists.
14075
- * No new UDS message, no second registry (D3). The operator reads the assembled
14076
- * result through `system.getFailureContributions`.
14077
- */
14078
- var FailureReasonCountSchema = object({
14079
- /**
14080
- * Why the attempt did not land, in the contributor's own vocabulary —
14081
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14082
- * strings that already appear in this repo's logs and, where one exists, the
14083
- * same string the per-track `previewMissReason` records (D276): a second
14084
- * vocabulary for the same loss would make the row and the counter
14085
- * un-joinable.
14086
- */
14087
- reason: string(),
14088
- count: number().int().nonnegative()
14089
- });
14090
- var FailureContributionSchema = object({
14091
- /**
14092
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14093
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14094
- * `unit` free: the families are owned by different addons and a shared enum
14095
- * is a central list that rots invisibly.
14096
- */
14097
- family: string(),
14098
- /**
14099
- * The NUMERIC device id — the same value every log line carries as
14100
- * `tags.deviceId`. Never nullable and never absent: a contributor that
14101
- * cannot name the camera must not emit the entry, because a fleet total
14102
- * cannot answer the only question anybody asks of this surface.
14103
- */
14104
- deviceId: number().int().positive(),
14105
- /**
14106
- * A second dimension inside the family: the model / step id for an inference
14107
- * timeout, so "which camera AND which model" is one read. Absent when the
14108
- * family has a single variant.
14109
- */
14110
- variant: string().optional(),
14111
- /**
14112
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14113
- * differencing two reads must drop the interval when it changes, because the
14114
- * counter restarted from zero in a respawned runner. Same discipline as
14115
- * `LoadContribution.startedAtMs`.
14116
- */
14117
- sinceMs: number(),
14118
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14119
- atMs: number(),
14120
- /**
14121
- * THE DENOMINATOR — every attempt on this path for this camera in the
14122
- * window. A failure count published without it is the mistake this schema
14123
- * exists to make impossible.
14124
- */
14125
- attempts: number().int().nonnegative(),
14126
- /** Attempts that landed. `attempts - succeeded` is the loss. */
14127
- succeeded: number().int().nonnegative(),
14128
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
14129
- reasons: array(FailureReasonCountSchema).readonly()
14130
- });
14131
- var failureContributionCapability = {
14132
- name: "failure-contribution",
14133
- scope: "system",
14134
- mode: "collection",
14135
- internal: true,
14136
- methods: {
14137
- /**
14138
- * This addon's per-camera failure counters, read live from bounded in-RAM
14139
- * state it already keeps. Inert: no persistence, no sampling, no timer.
14140
- *
14141
- * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
14142
- * consumer that wants a rate differences two reads. A draining read would
14143
- * make two operators with the page open each destroy half of the other's
14144
- * numbers, and `load-contribution` already settled the same question the
14145
- * same way for `cpuSeconds`.
14146
- */
14147
- list: method(_void(), array(FailureContributionSchema).readonly()) },
14148
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
14149
- mount: { kind: "skip" }
14150
- };
14151
- var LoadContributionSchema = object({
14152
- role: _enum([
14153
- "decode",
14154
- "transcode",
14155
- "recording",
14156
- "streaming",
14157
- "detection"
14158
- ]),
14159
- /**
14160
- * The NUMERIC device id — the same value every log line carries as
14161
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14162
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
14163
- * contributor that cannot name its camera must not emit the entry at all,
14164
- * because an unnamed per-camera entry is indistinguishable from a shared one
14165
- * and would quietly turn one camera's cost into everybody's.
14166
- */
14167
- deviceId: number().int().positive().nullable(),
14168
- attribution: _enum([
14169
- "measured",
14170
- "accounted",
14171
- "unattributable"
14172
- ]),
14173
- /**
14174
- * What ONE entry is, in the contributor's own words — `615/high`,
14175
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14176
- * family and inventing a common one would lose the only information that
14177
- * makes two entries for the same camera distinguishable.
14178
- */
14179
- unit: string(),
14180
- /**
14181
- * The OS process this cost lives in, when there is one. Present so a
14182
- * consumer can (a) tell two generations of the same unit apart across a
14183
- * restart, and (b) subtract claimed processes from the node's process
14184
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14185
- * process of its own.
14186
- */
14187
- pid: number().int().positive().optional(),
14188
- /**
14189
- * When this generation started. The pid's incarnation marker: a consumer
14190
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14191
- * window when this changes, because the counter restarted from zero in a new
14192
- * process.
14193
- */
14194
- startedAtMs: number().optional(),
14195
- /**
14196
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14197
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14198
- * contribution is asked for.
14199
- *
14200
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14201
- * needs a sampler, and a new per-node sampler is the defect half of
14202
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14203
- * by whoever already keeps a history; a rate cannot be un-averaged.
14204
- *
14205
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14206
- * an entry with no process.
14207
- */
14208
- cpuSeconds: number().optional(),
14209
- /** Resident bytes of this unit's process, same source and same rules. */
14210
- rssBytes: number().optional()
14211
- });
14212
- method(_void(), array(LoadContributionSchema).readonly());
14213
- /**
14214
14261
  * `login-method` — collection cap through which auth addons contribute
14215
14262
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14216
14263
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18948,12 +18995,53 @@ var MediaFileKindEnum = _enum([
18948
18995
  "keyFrameSmall",
18949
18996
  "thumbnailSmall"
18950
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
+ */
18951
19035
  var MediaFileSchema = object({
18952
19036
  key: string(),
18953
19037
  kind: MediaFileKindEnum,
18954
- base64: string(),
18955
19038
  sizeBytes: number(),
18956
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()
18957
19045
  });
18958
19046
  /**
18959
19047
  * One media row WITHOUT its bytes.
@@ -18965,7 +19053,9 @@ var MediaFileSchema = object({
18965
19053
  * blocks the whole view.
18966
19054
  *
18967
19055
  * `sizeBytes` is carried because it is what lets a client decide between the
18968
- * 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.
18969
19059
  */
18970
19060
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
18971
19061
  /**
@@ -19654,6 +19744,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19654
19744
  }), array(MediaFileSchema).readonly()), method(object({
19655
19745
  trackId: string(),
19656
19746
  deviceId: number()
19747
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19748
+ eventId: string(),
19749
+ deviceId: number()
19657
19750
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19658
19751
  kind: "mutation",
19659
19752
  auth: "admin"
@@ -24748,10 +24841,24 @@ var FaceClusterSchema = object({
24748
24841
  size: number().int(),
24749
24842
  cohesion: number()
24750
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
+ */
24751
24858
  var MediaFileLiteSchema$1 = object({
24752
24859
  key: string(),
24753
24860
  kind: string(),
24754
- base64: string(),
24861
+ url: string(),
24755
24862
  sizeBytes: number(),
24756
24863
  timestamp: number()
24757
24864
  });
@@ -27819,10 +27926,24 @@ var PlateInfoSchema = object({
27819
27926
  */
27820
27927
  cropUrl: string().optional()
27821
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
+ */
27822
27943
  var MediaFileLiteSchema = object({
27823
27944
  key: string(),
27824
27945
  kind: string(),
27825
- base64: string(),
27946
+ url: string(),
27826
27947
  sizeBytes: number(),
27827
27948
  timestamp: number()
27828
27949
  });
@@ -36237,6 +36358,12 @@ Object.freeze({
36237
36358
  addonId: null,
36238
36359
  access: "view"
36239
36360
  },
36361
+ "pipelineAnalytics.listEventMedia": {
36362
+ capName: "pipeline-analytics",
36363
+ capScope: "device",
36364
+ addonId: null,
36365
+ access: "view"
36366
+ },
36240
36367
  "pipelineAnalytics.listGroups": {
36241
36368
  capName: "pipeline-analytics",
36242
36369
  capScope: "device",
@@ -39860,6 +39987,11 @@ Object.freeze({
39860
39987
  form: "array",
39861
39988
  optional: false
39862
39989
  }],
39990
+ "pipelineAnalytics.listEventMedia": [{
39991
+ name: "deviceId",
39992
+ form: "single",
39993
+ optional: false
39994
+ }],
39863
39995
  "pipelineAnalytics.listGroups": [{
39864
39996
  name: "deviceIds",
39865
39997
  form: "array",
package/dist/addon.mjs CHANGED
@@ -7999,6 +7999,21 @@ var RelocateJobSchema = object({
7999
7999
  bytesMoved: number().int(),
8000
8000
  /** Total files discovered up front; null while (or when) unknown. */
8001
8001
  filesTotal: number().int().nullable(),
8002
+ /**
8003
+ * Rows this run CORRECTED while moving them — a durable mutation the move
8004
+ * made that nobody asked for, so it is reported where the operator reads the
8005
+ * job rather than only in a log line.
8006
+ *
8007
+ * A footage segment records its byte count in its own NAME, and the durable
8008
+ * hour row derives its aggregates from those names. A file that does not
8009
+ * match its name therefore makes the ledger's sums — and with them quota and
8010
+ * pressure eviction — wrong by the difference, and only a rename can fix it.
8011
+ * On 2026-08-30 one such row also stalled a 110 749-file drain permanently.
8012
+ *
8013
+ * Absent on lanes where the question has no meaning: a media blob's size is
8014
+ * in its row, not in its name, so `MediaRelocateEngine` never reconciles one.
8015
+ */
8016
+ rowsReconciled: number().int().nonnegative().optional(),
8002
8017
  startedAt: number(),
8003
8018
  finishedAt: number().nullable(),
8004
8019
  error: string().nullable()
@@ -8067,14 +8082,42 @@ var RelocateMediaInputSchema = object({
8067
8082
  /** Omitted = `move`, the pre-existing behaviour. */
8068
8083
  mode: MediaRelocateModeSchema.optional()
8069
8084
  });
8070
- /** How many rows still carry NO `locationId` — the population a repoint would
8071
- * silently re-aim at a disk that does not hold their bytes. Zero is the only
8072
- * value that permits a non-blocking `eventMedia` cutover. */
8073
- var UnstampedEventMediaCountSchema = object({
8074
- media: number().int().nonnegative(),
8075
- retrainFrames: number().int().nonnegative(),
8076
- total: number().int().nonnegative()
8085
+ /**
8086
+ * The unstamped population of ONE collection split, because the gate and the
8087
+ * operator ask two different questions and only one of them has to be cheap.
8088
+ *
8089
+ * `present` is the GATE: "is there at least one row that would be orphaned by a
8090
+ * repoint". It is a single indexed seek to the first matching row, so it stays
8091
+ * answerable on a saturated disk and answers in O(log n) precisely in the state
8092
+ * that matters — after a seal, when the population is empty.
8093
+ *
8094
+ * `rows` is the NUMBER, for the refusal message and the operator's sense of
8095
+ * scale. It is a second, indexed `COUNT(*)`, and `null` means **not
8096
+ * measurable** — never zero. `{ present: true, rows: null }` is a legitimate
8097
+ * and useful answer: "there are some, and this read could not say how many"
8098
+ * still refuses the cutover, which is the whole job.
8099
+ */
8100
+ var UnstampedRowsSchema = object({
8101
+ present: boolean(),
8102
+ rows: number().int().nonnegative().nullable()
8077
8103
  });
8104
+ /**
8105
+ * How many rows still carry NO `locationId` — the population a repoint would
8106
+ * silently re-aim at a disk that does not hold their bytes.
8107
+ *
8108
+ * **`null` = the count could not be taken**, and it is NOT permission to cut
8109
+ * over. The gate opens on a measured absence and on nothing else; an unread
8110
+ * collection and an empty one are different facts, and this repo has already
8111
+ * paid for conflating them (`RelocateResidueSchema`, D295).
8112
+ */
8113
+ var UnstampedEventMediaCountSchema = object({
8114
+ media: UnstampedRowsSchema,
8115
+ retrainFrames: UnstampedRowsSchema,
8116
+ /** True when EITHER collection holds one. The refusal reads this. */
8117
+ anyPresent: boolean(),
8118
+ /** Sum across both, or `null` when either lane could not be counted. */
8119
+ total: number().int().nonnegative().nullable()
8120
+ }).nullable();
8078
8121
  var StorageMigrationMediaMoveInputSchema = RelocateMediaInputSchema.extend({ leaseId: string().min(1) });
8079
8122
  /** The independently selectable logical storage classes — every class
8080
8123
  * `storage.listLocationDeclarations` reports, so an operator never meets a
@@ -8185,6 +8228,10 @@ var StorageMigrationMoveProgressSchema = object({
8185
8228
  /** The archive census — the **M** of "N of M" (D295). `null` = unknowable. */
8186
8229
  filesTotal: number().int().nonnegative().nullable(),
8187
8230
  bytesMoved: number().int().nonnegative(),
8231
+ /** Rows the mover corrected while moving them — see `RelocateJob`. Absent on
8232
+ * a lane that cannot reconcile. A migration that silently rewrote durable
8233
+ * rows would be the same failure as one that silently skipped them. */
8234
+ rowsReconciled: number().int().nonnegative().optional(),
8188
8235
  /** The MOVER's start, not the migration's: a drain restarted after an addon
8189
8236
  * crash gets a new mover, and a rate computed from the migration's start
8190
8237
  * would silently average in the time nothing was running. */
@@ -13426,6 +13473,133 @@ method(object({
13426
13473
  height: number()
13427
13474
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13428
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
+ /**
13429
13603
  * filesystem-browse — per-node capability for browsing the node's local
13430
13604
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13431
13605
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13947,6 +14121,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13947
14121
  kind: "mutation",
13948
14122
  auth: "admin"
13949
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());
13950
14186
  /**
13951
14187
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13952
14188
  * through. It stores nothing.
@@ -14023,195 +14259,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
14023
14259
  tags: record(string(), string()).optional()
14024
14260
  }), array(LogEntrySchema).readonly());
14025
14261
  /**
14026
- * `failure-contribution` — the capability an addon reports its OWN losses
14027
- * through, per camera, with the denominator attached. It stores nothing.
14028
- *
14029
- * ## The twin of `load-contribution`, and why it is a twin and not a field
14030
- *
14031
- * `load-contribution` answers *what did this camera COST*. This answers *what
14032
- * did this camera LOSE*. The reporting discipline is identical and deliberately
14033
- * copied: the contributor reports what it already knows, hub-main adds only
14034
- * `addonId`, nothing needs global knowledge, and there is no central list for
14035
- * somebody to forget to edit.
14036
- *
14037
- * They are not merged, because their invariants are opposites:
14038
- *
14039
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
14040
- * claim a camera cost nothing, which is a measurement nobody made;
14041
- * - a `failure-contribution` zero is the **most valuable value on the
14042
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14043
- * and it is exactly what an absent entry cannot say.
14044
- *
14045
- * Putting a loss counter on a cost entry would also break the reconciliation
14046
- * that gives `load-contribution` its point: contributions are subtracted from
14047
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14048
- * has no process.
14049
- *
14050
- * ## Why not a log line, since the counters already exist
14051
- *
14052
- * Several of these paths already counted themselves — `CaptureScheduler`'s
14053
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14054
- * ends in a log line, and a log line is the thing the operator asked to stop
14055
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14056
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14057
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14058
- * media blackout were both diagnosed. The counters stay; this is where they can
14059
- * be READ.
14060
- *
14061
- * ## The rate is served with its denominator or not at all
14062
- *
14063
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
14064
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14065
- * than yesterday" and was **flat across twelve hours** once divided by the
14066
- * successes on the same path. A surface that publishes only the numerator
14067
- * reproduces that mistake on every read.
14068
- *
14069
- * ## Shape
14070
- *
14071
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14072
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14073
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14074
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14075
- * a forked runner's entries reach hub-main over transport that already exists.
14076
- * No new UDS message, no second registry (D3). The operator reads the assembled
14077
- * result through `system.getFailureContributions`.
14078
- */
14079
- var FailureReasonCountSchema = object({
14080
- /**
14081
- * Why the attempt did not land, in the contributor's own vocabulary —
14082
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14083
- * strings that already appear in this repo's logs and, where one exists, the
14084
- * same string the per-track `previewMissReason` records (D276): a second
14085
- * vocabulary for the same loss would make the row and the counter
14086
- * un-joinable.
14087
- */
14088
- reason: string(),
14089
- count: number().int().nonnegative()
14090
- });
14091
- var FailureContributionSchema = object({
14092
- /**
14093
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14094
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14095
- * `unit` free: the families are owned by different addons and a shared enum
14096
- * is a central list that rots invisibly.
14097
- */
14098
- family: string(),
14099
- /**
14100
- * The NUMERIC device id — the same value every log line carries as
14101
- * `tags.deviceId`. Never nullable and never absent: a contributor that
14102
- * cannot name the camera must not emit the entry, because a fleet total
14103
- * cannot answer the only question anybody asks of this surface.
14104
- */
14105
- deviceId: number().int().positive(),
14106
- /**
14107
- * A second dimension inside the family: the model / step id for an inference
14108
- * timeout, so "which camera AND which model" is one read. Absent when the
14109
- * family has a single variant.
14110
- */
14111
- variant: string().optional(),
14112
- /**
14113
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14114
- * differencing two reads must drop the interval when it changes, because the
14115
- * counter restarted from zero in a respawned runner. Same discipline as
14116
- * `LoadContribution.startedAtMs`.
14117
- */
14118
- sinceMs: number(),
14119
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14120
- atMs: number(),
14121
- /**
14122
- * THE DENOMINATOR — every attempt on this path for this camera in the
14123
- * window. A failure count published without it is the mistake this schema
14124
- * exists to make impossible.
14125
- */
14126
- attempts: number().int().nonnegative(),
14127
- /** Attempts that landed. `attempts - succeeded` is the loss. */
14128
- succeeded: number().int().nonnegative(),
14129
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
14130
- reasons: array(FailureReasonCountSchema).readonly()
14131
- });
14132
- var failureContributionCapability = {
14133
- name: "failure-contribution",
14134
- scope: "system",
14135
- mode: "collection",
14136
- internal: true,
14137
- methods: {
14138
- /**
14139
- * This addon's per-camera failure counters, read live from bounded in-RAM
14140
- * state it already keeps. Inert: no persistence, no sampling, no timer.
14141
- *
14142
- * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
14143
- * consumer that wants a rate differences two reads. A draining read would
14144
- * make two operators with the page open each destroy half of the other's
14145
- * numbers, and `load-contribution` already settled the same question the
14146
- * same way for `cpuSeconds`.
14147
- */
14148
- list: method(_void(), array(FailureContributionSchema).readonly()) },
14149
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
14150
- mount: { kind: "skip" }
14151
- };
14152
- var LoadContributionSchema = object({
14153
- role: _enum([
14154
- "decode",
14155
- "transcode",
14156
- "recording",
14157
- "streaming",
14158
- "detection"
14159
- ]),
14160
- /**
14161
- * The NUMERIC device id — the same value every log line carries as
14162
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14163
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
14164
- * contributor that cannot name its camera must not emit the entry at all,
14165
- * because an unnamed per-camera entry is indistinguishable from a shared one
14166
- * and would quietly turn one camera's cost into everybody's.
14167
- */
14168
- deviceId: number().int().positive().nullable(),
14169
- attribution: _enum([
14170
- "measured",
14171
- "accounted",
14172
- "unattributable"
14173
- ]),
14174
- /**
14175
- * What ONE entry is, in the contributor's own words — `615/high`,
14176
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14177
- * family and inventing a common one would lose the only information that
14178
- * makes two entries for the same camera distinguishable.
14179
- */
14180
- unit: string(),
14181
- /**
14182
- * The OS process this cost lives in, when there is one. Present so a
14183
- * consumer can (a) tell two generations of the same unit apart across a
14184
- * restart, and (b) subtract claimed processes from the node's process
14185
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14186
- * process of its own.
14187
- */
14188
- pid: number().int().positive().optional(),
14189
- /**
14190
- * When this generation started. The pid's incarnation marker: a consumer
14191
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14192
- * window when this changes, because the counter restarted from zero in a new
14193
- * process.
14194
- */
14195
- startedAtMs: number().optional(),
14196
- /**
14197
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14198
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14199
- * contribution is asked for.
14200
- *
14201
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14202
- * needs a sampler, and a new per-node sampler is the defect half of
14203
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14204
- * by whoever already keeps a history; a rate cannot be un-averaged.
14205
- *
14206
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14207
- * an entry with no process.
14208
- */
14209
- cpuSeconds: number().optional(),
14210
- /** Resident bytes of this unit's process, same source and same rules. */
14211
- rssBytes: number().optional()
14212
- });
14213
- method(_void(), array(LoadContributionSchema).readonly());
14214
- /**
14215
14262
  * `login-method` — collection cap through which auth addons contribute
14216
14263
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14217
14264
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18949,12 +18996,53 @@ var MediaFileKindEnum = _enum([
18949
18996
  "keyFrameSmall",
18950
18997
  "thumbnailSmall"
18951
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
+ */
18952
19036
  var MediaFileSchema = object({
18953
19037
  key: string(),
18954
19038
  kind: MediaFileKindEnum,
18955
- base64: string(),
18956
19039
  sizeBytes: number(),
18957
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()
18958
19046
  });
18959
19047
  /**
18960
19048
  * One media row WITHOUT its bytes.
@@ -18966,7 +19054,9 @@ var MediaFileSchema = object({
18966
19054
  * blocks the whole view.
18967
19055
  *
18968
19056
  * `sizeBytes` is carried because it is what lets a client decide between the
18969
- * 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.
18970
19060
  */
18971
19061
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
18972
19062
  /**
@@ -19655,6 +19745,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19655
19745
  }), array(MediaFileSchema).readonly()), method(object({
19656
19746
  trackId: string(),
19657
19747
  deviceId: number()
19748
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19749
+ eventId: string(),
19750
+ deviceId: number()
19658
19751
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19659
19752
  kind: "mutation",
19660
19753
  auth: "admin"
@@ -24749,10 +24842,24 @@ var FaceClusterSchema = object({
24749
24842
  size: number().int(),
24750
24843
  cohesion: number()
24751
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
+ */
24752
24859
  var MediaFileLiteSchema$1 = object({
24753
24860
  key: string(),
24754
24861
  kind: string(),
24755
- base64: string(),
24862
+ url: string(),
24756
24863
  sizeBytes: number(),
24757
24864
  timestamp: number()
24758
24865
  });
@@ -27820,10 +27927,24 @@ var PlateInfoSchema = object({
27820
27927
  */
27821
27928
  cropUrl: string().optional()
27822
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
+ */
27823
27944
  var MediaFileLiteSchema = object({
27824
27945
  key: string(),
27825
27946
  kind: string(),
27826
- base64: string(),
27947
+ url: string(),
27827
27948
  sizeBytes: number(),
27828
27949
  timestamp: number()
27829
27950
  });
@@ -36238,6 +36359,12 @@ Object.freeze({
36238
36359
  addonId: null,
36239
36360
  access: "view"
36240
36361
  },
36362
+ "pipelineAnalytics.listEventMedia": {
36363
+ capName: "pipeline-analytics",
36364
+ capScope: "device",
36365
+ addonId: null,
36366
+ access: "view"
36367
+ },
36241
36368
  "pipelineAnalytics.listGroups": {
36242
36369
  capName: "pipeline-analytics",
36243
36370
  capScope: "device",
@@ -39861,6 +39988,11 @@ Object.freeze({
39861
39988
  form: "array",
39862
39989
  optional: false
39863
39990
  }],
39991
+ "pipelineAnalytics.listEventMedia": [{
39992
+ name: "deviceId",
39993
+ form: "single",
39994
+ optional: false
39995
+ }],
39864
39996
  "pipelineAnalytics.listGroups": [{
39865
39997
  name: "deviceIds",
39866
39998
  form: "array",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@camstack/addon-provider-hikvision",
3
- "version": "1.2.53",
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",