@camstack/addon-post-analysis 1.2.150 → 1.2.152

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.
@@ -8242,6 +8242,21 @@ var RelocateJobSchema = object({
8242
8242
  bytesMoved: number().int(),
8243
8243
  /** Total files discovered up front; null while (or when) unknown. */
8244
8244
  filesTotal: number().int().nullable(),
8245
+ /**
8246
+ * Rows this run CORRECTED while moving them — a durable mutation the move
8247
+ * made that nobody asked for, so it is reported where the operator reads the
8248
+ * job rather than only in a log line.
8249
+ *
8250
+ * A footage segment records its byte count in its own NAME, and the durable
8251
+ * hour row derives its aggregates from those names. A file that does not
8252
+ * match its name therefore makes the ledger's sums — and with them quota and
8253
+ * pressure eviction — wrong by the difference, and only a rename can fix it.
8254
+ * On 2026-08-30 one such row also stalled a 110 749-file drain permanently.
8255
+ *
8256
+ * Absent on lanes where the question has no meaning: a media blob's size is
8257
+ * in its row, not in its name, so `MediaRelocateEngine` never reconciles one.
8258
+ */
8259
+ rowsReconciled: number().int().nonnegative().optional(),
8245
8260
  startedAt: number(),
8246
8261
  finishedAt: number().nullable(),
8247
8262
  error: string().nullable()
@@ -8310,14 +8325,42 @@ var RelocateMediaInputSchema = object({
8310
8325
  /** Omitted = `move`, the pre-existing behaviour. */
8311
8326
  mode: MediaRelocateModeSchema.optional()
8312
8327
  });
8313
- /** How many rows still carry NO `locationId` — the population a repoint would
8314
- * silently re-aim at a disk that does not hold their bytes. Zero is the only
8315
- * value that permits a non-blocking `eventMedia` cutover. */
8316
- var UnstampedEventMediaCountSchema = object({
8317
- media: number().int().nonnegative(),
8318
- retrainFrames: number().int().nonnegative(),
8319
- total: number().int().nonnegative()
8328
+ /**
8329
+ * The unstamped population of ONE collection — split, because the gate and the
8330
+ * operator ask two different questions and only one of them has to be cheap.
8331
+ *
8332
+ * `present` is the GATE: "is there at least one row that would be orphaned by a
8333
+ * repoint". It is a single indexed seek to the first matching row, so it stays
8334
+ * answerable on a saturated disk and answers in O(log n) precisely in the state
8335
+ * that matters — after a seal, when the population is empty.
8336
+ *
8337
+ * `rows` is the NUMBER, for the refusal message and the operator's sense of
8338
+ * scale. It is a second, indexed `COUNT(*)`, and `null` means **not
8339
+ * measurable** — never zero. `{ present: true, rows: null }` is a legitimate
8340
+ * and useful answer: "there are some, and this read could not say how many"
8341
+ * still refuses the cutover, which is the whole job.
8342
+ */
8343
+ var UnstampedRowsSchema = object({
8344
+ present: boolean(),
8345
+ rows: number().int().nonnegative().nullable()
8320
8346
  });
8347
+ /**
8348
+ * How many rows still carry NO `locationId` — the population a repoint would
8349
+ * silently re-aim at a disk that does not hold their bytes.
8350
+ *
8351
+ * **`null` = the count could not be taken**, and it is NOT permission to cut
8352
+ * over. The gate opens on a measured absence and on nothing else; an unread
8353
+ * collection and an empty one are different facts, and this repo has already
8354
+ * paid for conflating them (`RelocateResidueSchema`, D295).
8355
+ */
8356
+ var UnstampedEventMediaCountSchema = object({
8357
+ media: UnstampedRowsSchema,
8358
+ retrainFrames: UnstampedRowsSchema,
8359
+ /** True when EITHER collection holds one. The refusal reads this. */
8360
+ anyPresent: boolean(),
8361
+ /** Sum across both, or `null` when either lane could not be counted. */
8362
+ total: number().int().nonnegative().nullable()
8363
+ }).nullable();
8321
8364
  var StorageMigrationMediaMoveInputSchema = RelocateMediaInputSchema.extend({ leaseId: string().min(1) });
8322
8365
  /** The independently selectable logical storage classes — every class
8323
8366
  * `storage.listLocationDeclarations` reports, so an operator never meets a
@@ -8428,6 +8471,10 @@ var StorageMigrationMoveProgressSchema = object({
8428
8471
  /** The archive census — the **M** of "N of M" (D295). `null` = unknowable. */
8429
8472
  filesTotal: number().int().nonnegative().nullable(),
8430
8473
  bytesMoved: number().int().nonnegative(),
8474
+ /** Rows the mover corrected while moving them — see `RelocateJob`. Absent on
8475
+ * a lane that cannot reconcile. A migration that silently rewrote durable
8476
+ * rows would be the same failure as one that silently skipped them. */
8477
+ rowsReconciled: number().int().nonnegative().optional(),
8431
8478
  /** The MOVER's start, not the migration's: a drain restarted after an addon
8432
8479
  * crash gets a new mover, and a rate computed from the migration's start
8433
8480
  * would silently average in the time nothing was running. */
@@ -13489,6 +13536,133 @@ var embeddingEncoderCapability = {
13489
13536
  }
13490
13537
  };
13491
13538
  /**
13539
+ * `failure-contribution` — the capability an addon reports its OWN losses
13540
+ * through, per camera, with the denominator attached. It stores nothing.
13541
+ *
13542
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
13543
+ *
13544
+ * `load-contribution` answers *what did this camera COST*. This answers *what
13545
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
13546
+ * copied: the contributor reports what it already knows, hub-main adds only
13547
+ * `addonId`, nothing needs global knowledge, and there is no central list for
13548
+ * somebody to forget to edit.
13549
+ *
13550
+ * They are not merged, because their invariants are opposites:
13551
+ *
13552
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
13553
+ * claim a camera cost nothing, which is a measurement nobody made;
13554
+ * - a `failure-contribution` zero is the **most valuable value on the
13555
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13556
+ * and it is exactly what an absent entry cannot say.
13557
+ *
13558
+ * Putting a loss counter on a cost entry would also break the reconciliation
13559
+ * that gives `load-contribution` its point: contributions are subtracted from
13560
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13561
+ * has no process.
13562
+ *
13563
+ * ## Why not a log line, since the counters already exist
13564
+ *
13565
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
13566
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13567
+ * ends in a log line, and a log line is the thing the operator asked to stop
13568
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13569
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13570
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13571
+ * media blackout were both diagnosed. The counters stay; this is where they can
13572
+ * be READ.
13573
+ *
13574
+ * ## The rate is served with its denominator or not at all
13575
+ *
13576
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
13577
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13578
+ * than yesterday" and was **flat across twelve hours** once divided by the
13579
+ * successes on the same path. A surface that publishes only the numerator
13580
+ * reproduces that mistake on every read.
13581
+ *
13582
+ * ## Shape
13583
+ *
13584
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13585
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13586
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13587
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13588
+ * a forked runner's entries reach hub-main over transport that already exists.
13589
+ * No new UDS message, no second registry (D3). The operator reads the assembled
13590
+ * result through `system.getFailureContributions`.
13591
+ */
13592
+ var FailureReasonCountSchema = object({
13593
+ /**
13594
+ * Why the attempt did not land, in the contributor's own vocabulary —
13595
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13596
+ * strings that already appear in this repo's logs and, where one exists, the
13597
+ * same string the per-track `previewMissReason` records (D276): a second
13598
+ * vocabulary for the same loss would make the row and the counter
13599
+ * un-joinable.
13600
+ */
13601
+ reason: string(),
13602
+ count: number().int().nonnegative()
13603
+ });
13604
+ var FailureContributionSchema = object({
13605
+ /**
13606
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13607
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13608
+ * `unit` free: the families are owned by different addons and a shared enum
13609
+ * is a central list that rots invisibly.
13610
+ */
13611
+ family: string(),
13612
+ /**
13613
+ * The NUMERIC device id — the same value every log line carries as
13614
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
13615
+ * cannot name the camera must not emit the entry, because a fleet total
13616
+ * cannot answer the only question anybody asks of this surface.
13617
+ */
13618
+ deviceId: number().int().positive(),
13619
+ /**
13620
+ * A second dimension inside the family: the model / step id for an inference
13621
+ * timeout, so "which camera AND which model" is one read. Absent when the
13622
+ * family has a single variant.
13623
+ */
13624
+ variant: string().optional(),
13625
+ /**
13626
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13627
+ * differencing two reads must drop the interval when it changes, because the
13628
+ * counter restarted from zero in a respawned runner. Same discipline as
13629
+ * `LoadContribution.startedAtMs`.
13630
+ */
13631
+ sinceMs: number(),
13632
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13633
+ atMs: number(),
13634
+ /**
13635
+ * THE DENOMINATOR — every attempt on this path for this camera in the
13636
+ * window. A failure count published without it is the mistake this schema
13637
+ * exists to make impossible.
13638
+ */
13639
+ attempts: number().int().nonnegative(),
13640
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
13641
+ succeeded: number().int().nonnegative(),
13642
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
13643
+ reasons: array(FailureReasonCountSchema).readonly()
13644
+ });
13645
+ var failureContributionCapability = {
13646
+ name: "failure-contribution",
13647
+ scope: "system",
13648
+ mode: "collection",
13649
+ internal: true,
13650
+ methods: {
13651
+ /**
13652
+ * This addon's per-camera failure counters, read live from bounded in-RAM
13653
+ * state it already keeps. Inert: no persistence, no sampling, no timer.
13654
+ *
13655
+ * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
13656
+ * consumer that wants a rate differences two reads. A draining read would
13657
+ * make two operators with the page open each destroy half of the other's
13658
+ * numbers, and `load-contribution` already settled the same question the
13659
+ * same way for `cpuSeconds`.
13660
+ */
13661
+ list: method(_void(), array(FailureContributionSchema).readonly()) },
13662
+ /** In-process only — enumerated through `addons.listCapabilityProviders`. */
13663
+ mount: { kind: "skip" }
13664
+ };
13665
+ /**
13492
13666
  * filesystem-browse — per-node capability for browsing the node's local
13493
13667
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13494
13668
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -14010,6 +14184,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
14010
14184
  kind: "mutation",
14011
14185
  auth: "admin"
14012
14186
  });
14187
+ var LoadContributionSchema = object({
14188
+ role: _enum([
14189
+ "decode",
14190
+ "transcode",
14191
+ "recording",
14192
+ "streaming",
14193
+ "detection"
14194
+ ]),
14195
+ /**
14196
+ * The NUMERIC device id — the same value every log line carries as
14197
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14198
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
14199
+ * contributor that cannot name its camera must not emit the entry at all,
14200
+ * because an unnamed per-camera entry is indistinguishable from a shared one
14201
+ * and would quietly turn one camera's cost into everybody's.
14202
+ */
14203
+ deviceId: number().int().positive().nullable(),
14204
+ attribution: _enum([
14205
+ "measured",
14206
+ "accounted",
14207
+ "unattributable"
14208
+ ]),
14209
+ /**
14210
+ * What ONE entry is, in the contributor's own words — `615/high`,
14211
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14212
+ * family and inventing a common one would lose the only information that
14213
+ * makes two entries for the same camera distinguishable.
14214
+ */
14215
+ unit: string(),
14216
+ /**
14217
+ * The OS process this cost lives in, when there is one. Present so a
14218
+ * consumer can (a) tell two generations of the same unit apart across a
14219
+ * restart, and (b) subtract claimed processes from the node's process
14220
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14221
+ * process of its own.
14222
+ */
14223
+ pid: number().int().positive().optional(),
14224
+ /**
14225
+ * When this generation started. The pid's incarnation marker: a consumer
14226
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14227
+ * window when this changes, because the counter restarted from zero in a new
14228
+ * process.
14229
+ */
14230
+ startedAtMs: number().optional(),
14231
+ /**
14232
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14233
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
14234
+ * contribution is asked for.
14235
+ *
14236
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
14237
+ * needs a sampler, and a new per-node sampler is the defect half of
14238
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14239
+ * by whoever already keeps a history; a rate cannot be un-averaged.
14240
+ *
14241
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14242
+ * an entry with no process.
14243
+ */
14244
+ cpuSeconds: number().optional(),
14245
+ /** Resident bytes of this unit's process, same source and same rules. */
14246
+ rssBytes: number().optional()
14247
+ });
14248
+ method(_void(), array(LoadContributionSchema).readonly());
14013
14249
  /**
14014
14250
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
14015
14251
  * through. It stores nothing.
@@ -14086,195 +14322,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
14086
14322
  tags: record(string(), string()).optional()
14087
14323
  }), array(LogEntrySchema).readonly());
14088
14324
  /**
14089
- * `failure-contribution` — the capability an addon reports its OWN losses
14090
- * through, per camera, with the denominator attached. It stores nothing.
14091
- *
14092
- * ## The twin of `load-contribution`, and why it is a twin and not a field
14093
- *
14094
- * `load-contribution` answers *what did this camera COST*. This answers *what
14095
- * did this camera LOSE*. The reporting discipline is identical and deliberately
14096
- * copied: the contributor reports what it already knows, hub-main adds only
14097
- * `addonId`, nothing needs global knowledge, and there is no central list for
14098
- * somebody to forget to edit.
14099
- *
14100
- * They are not merged, because their invariants are opposites:
14101
- *
14102
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
14103
- * claim a camera cost nothing, which is a measurement nobody made;
14104
- * - a `failure-contribution` zero is the **most valuable value on the
14105
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14106
- * and it is exactly what an absent entry cannot say.
14107
- *
14108
- * Putting a loss counter on a cost entry would also break the reconciliation
14109
- * that gives `load-contribution` its point: contributions are subtracted from
14110
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14111
- * has no process.
14112
- *
14113
- * ## Why not a log line, since the counters already exist
14114
- *
14115
- * Several of these paths already counted themselves — `CaptureScheduler`'s
14116
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14117
- * ends in a log line, and a log line is the thing the operator asked to stop
14118
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14119
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14120
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14121
- * media blackout were both diagnosed. The counters stay; this is where they can
14122
- * be READ.
14123
- *
14124
- * ## The rate is served with its denominator or not at all
14125
- *
14126
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
14127
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14128
- * than yesterday" and was **flat across twelve hours** once divided by the
14129
- * successes on the same path. A surface that publishes only the numerator
14130
- * reproduces that mistake on every read.
14131
- *
14132
- * ## Shape
14133
- *
14134
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14135
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14136
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14137
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14138
- * a forked runner's entries reach hub-main over transport that already exists.
14139
- * No new UDS message, no second registry (D3). The operator reads the assembled
14140
- * result through `system.getFailureContributions`.
14141
- */
14142
- var FailureReasonCountSchema = object({
14143
- /**
14144
- * Why the attempt did not land, in the contributor's own vocabulary —
14145
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14146
- * strings that already appear in this repo's logs and, where one exists, the
14147
- * same string the per-track `previewMissReason` records (D276): a second
14148
- * vocabulary for the same loss would make the row and the counter
14149
- * un-joinable.
14150
- */
14151
- reason: string(),
14152
- count: number().int().nonnegative()
14153
- });
14154
- var FailureContributionSchema = object({
14155
- /**
14156
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14157
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14158
- * `unit` free: the families are owned by different addons and a shared enum
14159
- * is a central list that rots invisibly.
14160
- */
14161
- family: string(),
14162
- /**
14163
- * The NUMERIC device id — the same value every log line carries as
14164
- * `tags.deviceId`. Never nullable and never absent: a contributor that
14165
- * cannot name the camera must not emit the entry, because a fleet total
14166
- * cannot answer the only question anybody asks of this surface.
14167
- */
14168
- deviceId: number().int().positive(),
14169
- /**
14170
- * A second dimension inside the family: the model / step id for an inference
14171
- * timeout, so "which camera AND which model" is one read. Absent when the
14172
- * family has a single variant.
14173
- */
14174
- variant: string().optional(),
14175
- /**
14176
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14177
- * differencing two reads must drop the interval when it changes, because the
14178
- * counter restarted from zero in a respawned runner. Same discipline as
14179
- * `LoadContribution.startedAtMs`.
14180
- */
14181
- sinceMs: number(),
14182
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14183
- atMs: number(),
14184
- /**
14185
- * THE DENOMINATOR — every attempt on this path for this camera in the
14186
- * window. A failure count published without it is the mistake this schema
14187
- * exists to make impossible.
14188
- */
14189
- attempts: number().int().nonnegative(),
14190
- /** Attempts that landed. `attempts - succeeded` is the loss. */
14191
- succeeded: number().int().nonnegative(),
14192
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
14193
- reasons: array(FailureReasonCountSchema).readonly()
14194
- });
14195
- var failureContributionCapability = {
14196
- name: "failure-contribution",
14197
- scope: "system",
14198
- mode: "collection",
14199
- internal: true,
14200
- methods: {
14201
- /**
14202
- * This addon's per-camera failure counters, read live from bounded in-RAM
14203
- * state it already keeps. Inert: no persistence, no sampling, no timer.
14204
- *
14205
- * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
14206
- * consumer that wants a rate differences two reads. A draining read would
14207
- * make two operators with the page open each destroy half of the other's
14208
- * numbers, and `load-contribution` already settled the same question the
14209
- * same way for `cpuSeconds`.
14210
- */
14211
- list: method(_void(), array(FailureContributionSchema).readonly()) },
14212
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
14213
- mount: { kind: "skip" }
14214
- };
14215
- var LoadContributionSchema = object({
14216
- role: _enum([
14217
- "decode",
14218
- "transcode",
14219
- "recording",
14220
- "streaming",
14221
- "detection"
14222
- ]),
14223
- /**
14224
- * The NUMERIC device id — the same value every log line carries as
14225
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14226
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
14227
- * contributor that cannot name its camera must not emit the entry at all,
14228
- * because an unnamed per-camera entry is indistinguishable from a shared one
14229
- * and would quietly turn one camera's cost into everybody's.
14230
- */
14231
- deviceId: number().int().positive().nullable(),
14232
- attribution: _enum([
14233
- "measured",
14234
- "accounted",
14235
- "unattributable"
14236
- ]),
14237
- /**
14238
- * What ONE entry is, in the contributor's own words — `615/high`,
14239
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14240
- * family and inventing a common one would lose the only information that
14241
- * makes two entries for the same camera distinguishable.
14242
- */
14243
- unit: string(),
14244
- /**
14245
- * The OS process this cost lives in, when there is one. Present so a
14246
- * consumer can (a) tell two generations of the same unit apart across a
14247
- * restart, and (b) subtract claimed processes from the node's process
14248
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14249
- * process of its own.
14250
- */
14251
- pid: number().int().positive().optional(),
14252
- /**
14253
- * When this generation started. The pid's incarnation marker: a consumer
14254
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14255
- * window when this changes, because the counter restarted from zero in a new
14256
- * process.
14257
- */
14258
- startedAtMs: number().optional(),
14259
- /**
14260
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14261
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14262
- * contribution is asked for.
14263
- *
14264
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14265
- * needs a sampler, and a new per-node sampler is the defect half of
14266
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14267
- * by whoever already keeps a history; a rate cannot be un-averaged.
14268
- *
14269
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14270
- * an entry with no process.
14271
- */
14272
- cpuSeconds: number().optional(),
14273
- /** Resident bytes of this unit's process, same source and same rules. */
14274
- rssBytes: number().optional()
14275
- });
14276
- method(_void(), array(LoadContributionSchema).readonly());
14277
- /**
14278
14325
  * `login-method` — collection cap through which auth addons contribute
14279
14326
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14280
14327
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -19640,12 +19687,53 @@ var MediaFileKindEnum = _enum([
19640
19687
  "keyFrameSmall",
19641
19688
  "thumbnailSmall"
19642
19689
  ]);
19690
+ /**
19691
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
19692
+ * ARE — never the bytes themselves.
19693
+ *
19694
+ * ## Why `url` and not `base64`
19695
+ *
19696
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
19697
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
19698
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
19699
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
19700
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
19701
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
19702
+ *
19703
+ * `url` points at the `event-media` data plane
19704
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
19705
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
19706
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
19707
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
19708
+ * no less protected than they were inside a `view`-level cap response — see
19709
+ * `data-plane-access.ts` for the rule and the one gap it does not close
19710
+ * (per-device scoping).
19711
+ *
19712
+ * The URL is built from the row's **stored** key, which is not always its
19713
+ * published `kind`: a track's face/plate crop is stored as `crop` under
19714
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
19715
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
19716
+ *
19717
+ * ## `base64` is TRANSITIONAL and is going away
19718
+ *
19719
+ * It is still populated for one reason: the deployed viewer's track-detail
19720
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
19721
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
19722
+ * triangle — not as absence. Removing the field before that viewer ships is an
19723
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
19724
+ * delete this line and the `withBytes` pass-through in
19725
+ * `analytics-query-facade.ts`; nothing else reads it.
19726
+ */
19643
19727
  var MediaFileSchema = object({
19644
19728
  key: string(),
19645
19729
  kind: MediaFileKindEnum,
19646
- base64: string(),
19647
19730
  sizeBytes: number(),
19648
19731
  timestamp: number()
19732
+ }).extend({
19733
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
19734
+ url: string(),
19735
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
19736
+ base64: string()
19649
19737
  });
19650
19738
  /**
19651
19739
  * One media row WITHOUT its bytes.
@@ -19657,7 +19745,9 @@ var MediaFileSchema = object({
19657
19745
  * blocks the whole view.
19658
19746
  *
19659
19747
  * `sizeBytes` is carried because it is what lets a client decide between the
19660
- * stored blob and a `?variant=thumb` rendering without fetching either.
19748
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
19749
+ * `url` because a client that had to build the plane path itself is a second
19750
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
19661
19751
  */
19662
19752
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
19663
19753
  /**
@@ -20455,6 +20545,17 @@ var pipelineAnalyticsCapability = {
20455
20545
  * happens to stamp it. This count is what the migration planner's
20456
20546
  * non-blocking gate reads; `relocateMedia({ mode: 'seal' })` is what drives
20457
20547
  * it to zero.
20548
+ *
20549
+ * TWO indexed statements per collection, not a walk. It used to page the
20550
+ * whole collection at 200 rows per RPC ordered by an unindexed column, so
20551
+ * on the live hub — 1 254 576 rows — it hit the 60 s RPC deadline every
20552
+ * time it was called, and the migration it gates could never start. The
20553
+ * cheap question (`present`: is there at least one) is asked first and
20554
+ * separately from the expensive one (`rows`), because only the first has
20555
+ * to be answerable for the gate to do its job.
20556
+ *
20557
+ * **`null` is "not measurable", never zero** — at either level. An
20558
+ * unreadable collection must not read as a sealed one.
20458
20559
  */
20459
20560
  countUnstampedEventMedia: method(object({}), UnstampedEventMediaCountSchema, { auth: "admin" }),
20460
20561
  /**
@@ -20778,6 +20879,26 @@ var pipelineAnalyticsCapability = {
20778
20879
  deviceId: number()
20779
20880
  }), array(MediaFileInfoSchema).readonly()),
20780
20881
  /**
20882
+ * What media an EVENT has, without any of it — the twin `getEventMedia`
20883
+ * never had.
20884
+ *
20885
+ * `listTrackMedia` above got this treatment because a track's media is
20886
+ * 5-8 MB. An event's is worse per row, not better: an old-style event owns
20887
+ * a `crop` AND a native-resolution `fullFrameBoxed`, and the track DETAIL
20888
+ * modal — the one surface that legitimately shows the big kinds — unions
20889
+ * both listings to build its filmstrip. It then renders every tile from
20890
+ * the `event-media` plane by key and throws the bytes away. Measured on
20891
+ * the live hub: one event's `fullFrameBoxed` is 2 824 077 B, base64'd to
20892
+ * ~3.8 MB, allocated whole in hub-main's heap, for a list of keys.
20893
+ *
20894
+ * Same `deviceId` authorization subject as `getEventMedia`, and the same
20895
+ * rows — this is a projection of that method, never a different question.
20896
+ */
20897
+ listEventMedia: method(object({
20898
+ eventId: string(),
20899
+ deviceId: number()
20900
+ }), array(MediaFileInfoSchema).readonly()),
20901
+ /**
20781
20902
  * Search object events by text query using CLIP cosine similarity.
20782
20903
  * Encodes `text` via the `embedding-encoder` cap, queries the
20783
20904
  * `ObjectEmbeddingStore` with optional prefilters, ranks all matching
@@ -25841,10 +25962,24 @@ var FaceClusterSchema = object({
25841
25962
  size: number().int(),
25842
25963
  cohesion: number()
25843
25964
  });
25965
+ /**
25966
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
25967
+ * are — never the bytes.
25968
+ *
25969
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
25970
+ * track/event contract) is still populated because a deployed viewer requires
25971
+ * the field to parse a row at all; this method has no such reader. Its ONE
25972
+ * caller is the admin UI's detail modal, which was building
25973
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
25974
+ * dialog already rendering its key FRAME from the `event-media` plane.
25975
+ *
25976
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
25977
+ * media key directly, so this needed no new plane and no new access decision.
25978
+ */
25844
25979
  var MediaFileLiteSchema$1 = object({
25845
25980
  key: string(),
25846
25981
  kind: string(),
25847
- base64: string(),
25982
+ url: string(),
25848
25983
  sizeBytes: number(),
25849
25984
  timestamp: number()
25850
25985
  });
@@ -28892,10 +29027,24 @@ var PlateInfoSchema = object({
28892
29027
  */
28893
29028
  cropUrl: string().optional()
28894
29029
  });
29030
+ /**
29031
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
29032
+ * are — never the bytes.
29033
+ *
29034
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
29035
+ * track/event contract) is still populated because a deployed viewer requires
29036
+ * the field to parse a row at all; this method has no such reader. Its ONE
29037
+ * caller is the admin UI's detail modal, which was building
29038
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
29039
+ * dialog already rendering its key FRAME from the `event-media` plane.
29040
+ *
29041
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
29042
+ * media key directly, so this needed no new plane and no new access decision.
29043
+ */
28895
29044
  var MediaFileLiteSchema = object({
28896
29045
  key: string(),
28897
29046
  kind: string(),
28898
- base64: string(),
29047
+ url: string(),
28899
29048
  sizeBytes: number(),
28900
29049
  timestamp: number()
28901
29050
  });
@@ -37043,6 +37192,12 @@ Object.freeze({
37043
37192
  addonId: null,
37044
37193
  access: "view"
37045
37194
  },
37195
+ "pipelineAnalytics.listEventMedia": {
37196
+ capName: "pipeline-analytics",
37197
+ capScope: "device",
37198
+ addonId: null,
37199
+ access: "view"
37200
+ },
37046
37201
  "pipelineAnalytics.listGroups": {
37047
37202
  capName: "pipeline-analytics",
37048
37203
  capScope: "device",
@@ -40666,6 +40821,11 @@ Object.freeze({
40666
40821
  form: "array",
40667
40822
  optional: false
40668
40823
  }],
40824
+ "pipelineAnalytics.listEventMedia": [{
40825
+ name: "deviceId",
40826
+ form: "single",
40827
+ optional: false
40828
+ }],
40669
40829
  "pipelineAnalytics.listGroups": [{
40670
40830
  name: "deviceIds",
40671
40831
  form: "array",
@@ -2,7 +2,7 @@ Object.defineProperties(exports, {
2
2
  __esModule: { value: true },
3
3
  [Symbol.toStringTag]: { value: "Module" }
4
4
  });
5
- const require_dist = require("../dist-BTviHGUC.js");
5
+ const require_dist = require("../dist-Bw6cidiJ.js");
6
6
  let node_fs = require("node:fs");
7
7
  node_fs = require_dist.__toESM(node_fs);
8
8
  let node_path = require("node:path");
@@ -1,4 +1,4 @@
1
- import { At as BaseAddon, F as PoolMemoryWatchdog, St as resolvePoolMemoryPolicy, at as embeddingEncoderCapability, gt as parseProcStatus, ut as hfModelUrl } from "../dist-C8cA7PX_.mjs";
1
+ import { At as BaseAddon, F as PoolMemoryWatchdog, St as resolvePoolMemoryPolicy, at as embeddingEncoderCapability, gt as parseProcStatus, ut as hfModelUrl } from "../dist-DSg_jDMt.mjs";
2
2
  import { createRequire } from "node:module";
3
3
  import * as fs from "node:fs";
4
4
  import * as path$1 from "node:path";