@camstack/addon-osd-manager 0.1.38 → 0.1.40

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 (18) hide show
  1. package/dist/{MotionZonesSettings-emdN0UNh.mjs → MotionZonesSettings-BTOqeXRd.mjs} +2 -2
  2. package/dist/{PrivacyMaskSettings-CrGo7BYZ.mjs → PrivacyMaskSettings-BgmE0tQu.mjs} +4 -4
  3. package/dist/{SceneMonitorEditor-_K9y826_.mjs → SceneMonitorEditor-D4oig7v9.mjs} +3 -3
  4. package/dist/_stub.js +11 -11
  5. package/dist/{_virtual_mf-localSharedImportMap___mfe_internal__addon_osd_manager_page-C1HPQGS9.mjs → _virtual_mf-localSharedImportMap___mfe_internal__addon_osd_manager_page-C4iHNnmw.mjs} +4 -4
  6. package/dist/_virtual_mf___mfe_internal__addon_osd_manager_page__loadShare___mf_0_camstack_mf_1_types__loadShare__.js-Blhr4EyN.mjs +26 -0
  7. package/dist/{hostInit-D49Ppk5T.mjs → hostInit-DzLQY4CO.mjs} +3 -3
  8. package/dist/index.js +417 -227
  9. package/dist/index.mjs +417 -227
  10. package/dist/{player-overlays-DURd3AGI.mjs → player-overlays-DaucHym7.mjs} +1 -1
  11. package/dist/remoteEntry.js +1 -1
  12. package/dist/{responsive-DIYWmiTV.mjs → responsive-DC2YNF2r.mjs} +1 -1
  13. package/dist/{square-pJqxPNpb.mjs → square-DuMw_5RG.mjs} +1 -1
  14. package/dist/{trash-2-DgzntFMe.mjs → trash-2-C54qifas.mjs} +1 -1
  15. package/dist/{use-device-snapshot-C-TbesfB.mjs → use-device-snapshot-BVTu9rWV.mjs} +1 -1
  16. package/dist/{virtual_mf-REMOTE_ENTRY_ID___mfe_internal__addon_osd_manager_page__remoteEntry_js-ku4Amehr.mjs → virtual_mf-REMOTE_ENTRY_ID___mfe_internal__addon_osd_manager_page__remoteEntry_js-B-XuFKdU.mjs} +1 -1
  17. package/package.json +1 -1
  18. package/dist/_virtual_mf___mfe_internal__addon_osd_manager_page__loadShare___mf_0_camstack_mf_1_types__loadShare__.js-DuDBHu79.mjs +0 -26
package/dist/index.mjs CHANGED
@@ -8098,6 +8098,21 @@ var RelocateJobSchema = object({
8098
8098
  bytesMoved: number().int(),
8099
8099
  /** Total files discovered up front; null while (or when) unknown. */
8100
8100
  filesTotal: number().int().nullable(),
8101
+ /**
8102
+ * Rows this run CORRECTED while moving them — a durable mutation the move
8103
+ * made that nobody asked for, so it is reported where the operator reads the
8104
+ * job rather than only in a log line.
8105
+ *
8106
+ * A footage segment records its byte count in its own NAME, and the durable
8107
+ * hour row derives its aggregates from those names. A file that does not
8108
+ * match its name therefore makes the ledger's sums — and with them quota and
8109
+ * pressure eviction — wrong by the difference, and only a rename can fix it.
8110
+ * On 2026-08-30 one such row also stalled a 110 749-file drain permanently.
8111
+ *
8112
+ * Absent on lanes where the question has no meaning: a media blob's size is
8113
+ * in its row, not in its name, so `MediaRelocateEngine` never reconciles one.
8114
+ */
8115
+ rowsReconciled: number().int().nonnegative().optional(),
8101
8116
  startedAt: number(),
8102
8117
  finishedAt: number().nullable(),
8103
8118
  error: string().nullable()
@@ -8166,14 +8181,42 @@ var RelocateMediaInputSchema = object({
8166
8181
  /** Omitted = `move`, the pre-existing behaviour. */
8167
8182
  mode: MediaRelocateModeSchema.optional()
8168
8183
  });
8169
- /** How many rows still carry NO `locationId` — the population a repoint would
8170
- * silently re-aim at a disk that does not hold their bytes. Zero is the only
8171
- * value that permits a non-blocking `eventMedia` cutover. */
8172
- var UnstampedEventMediaCountSchema = object({
8173
- media: number().int().nonnegative(),
8174
- retrainFrames: number().int().nonnegative(),
8175
- total: number().int().nonnegative()
8184
+ /**
8185
+ * The unstamped population of ONE collection split, because the gate and the
8186
+ * operator ask two different questions and only one of them has to be cheap.
8187
+ *
8188
+ * `present` is the GATE: "is there at least one row that would be orphaned by a
8189
+ * repoint". It is a single indexed seek to the first matching row, so it stays
8190
+ * answerable on a saturated disk and answers in O(log n) precisely in the state
8191
+ * that matters — after a seal, when the population is empty.
8192
+ *
8193
+ * `rows` is the NUMBER, for the refusal message and the operator's sense of
8194
+ * scale. It is a second, indexed `COUNT(*)`, and `null` means **not
8195
+ * measurable** — never zero. `{ present: true, rows: null }` is a legitimate
8196
+ * and useful answer: "there are some, and this read could not say how many"
8197
+ * still refuses the cutover, which is the whole job.
8198
+ */
8199
+ var UnstampedRowsSchema = object({
8200
+ present: boolean(),
8201
+ rows: number().int().nonnegative().nullable()
8176
8202
  });
8203
+ /**
8204
+ * How many rows still carry NO `locationId` — the population a repoint would
8205
+ * silently re-aim at a disk that does not hold their bytes.
8206
+ *
8207
+ * **`null` = the count could not be taken**, and it is NOT permission to cut
8208
+ * over. The gate opens on a measured absence and on nothing else; an unread
8209
+ * collection and an empty one are different facts, and this repo has already
8210
+ * paid for conflating them (`RelocateResidueSchema`, D295).
8211
+ */
8212
+ var UnstampedEventMediaCountSchema = object({
8213
+ media: UnstampedRowsSchema,
8214
+ retrainFrames: UnstampedRowsSchema,
8215
+ /** True when EITHER collection holds one. The refusal reads this. */
8216
+ anyPresent: boolean(),
8217
+ /** Sum across both, or `null` when either lane could not be counted. */
8218
+ total: number().int().nonnegative().nullable()
8219
+ }).nullable();
8177
8220
  var StorageMigrationMediaMoveInputSchema = RelocateMediaInputSchema.extend({ leaseId: string().min(1) });
8178
8221
  /** The independently selectable logical storage classes — every class
8179
8222
  * `storage.listLocationDeclarations` reports, so an operator never meets a
@@ -8284,6 +8327,10 @@ var StorageMigrationMoveProgressSchema = object({
8284
8327
  /** The archive census — the **M** of "N of M" (D295). `null` = unknowable. */
8285
8328
  filesTotal: number().int().nonnegative().nullable(),
8286
8329
  bytesMoved: number().int().nonnegative(),
8330
+ /** Rows the mover corrected while moving them — see `RelocateJob`. Absent on
8331
+ * a lane that cannot reconcile. A migration that silently rewrote durable
8332
+ * rows would be the same failure as one that silently skipped them. */
8333
+ rowsReconciled: number().int().nonnegative().optional(),
8287
8334
  /** The MOVER's start, not the migration's: a drain restarted after an addon
8288
8335
  * crash gets a new mover, and a rate computed from the migration's start
8289
8336
  * would silently average in the time nothing was running. */
@@ -14240,6 +14287,15 @@ var deviceManagerCapability = {
14240
14287
  * calls are sync. Bindings change rarely (only on wrapper toggle or
14241
14288
  * device add/remove) — clients invalidate via the
14242
14289
  * `capability.binding-changed` event.
14290
+ *
14291
+ * "A single round-trip" describes the CLIENT's side and used not to
14292
+ * describe the server's: until 2026-08-30 the resolver read the persisted
14293
+ * wrapper activations once per device, so answering this cost one
14294
+ * settings-door RPC per device — 1 020 on the live 1 019-device hub, and
14295
+ * it did not return in 240 s against `SystemMirror.init`'s 15 s budget.
14296
+ * The server side is now two reads for the whole fleet. Anything PERIODIC
14297
+ * still belongs on `getBindings` / `getBindingsBatch` (D12); this remains
14298
+ * a warm seed.
14243
14299
  */
14244
14300
  getAllBindings: method(object({}), array(DeviceBindingsForDeviceSchema)),
14245
14301
  /**
@@ -14668,6 +14724,133 @@ var embeddingEncoderCapability = {
14668
14724
  }
14669
14725
  };
14670
14726
  /**
14727
+ * `failure-contribution` — the capability an addon reports its OWN losses
14728
+ * through, per camera, with the denominator attached. It stores nothing.
14729
+ *
14730
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
14731
+ *
14732
+ * `load-contribution` answers *what did this camera COST*. This answers *what
14733
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
14734
+ * copied: the contributor reports what it already knows, hub-main adds only
14735
+ * `addonId`, nothing needs global knowledge, and there is no central list for
14736
+ * somebody to forget to edit.
14737
+ *
14738
+ * They are not merged, because their invariants are opposites:
14739
+ *
14740
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
14741
+ * claim a camera cost nothing, which is a measurement nobody made;
14742
+ * - a `failure-contribution` zero is the **most valuable value on the
14743
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14744
+ * and it is exactly what an absent entry cannot say.
14745
+ *
14746
+ * Putting a loss counter on a cost entry would also break the reconciliation
14747
+ * that gives `load-contribution` its point: contributions are subtracted from
14748
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14749
+ * has no process.
14750
+ *
14751
+ * ## Why not a log line, since the counters already exist
14752
+ *
14753
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
14754
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14755
+ * ends in a log line, and a log line is the thing the operator asked to stop
14756
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14757
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14758
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14759
+ * media blackout were both diagnosed. The counters stay; this is where they can
14760
+ * be READ.
14761
+ *
14762
+ * ## The rate is served with its denominator or not at all
14763
+ *
14764
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
14765
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14766
+ * than yesterday" and was **flat across twelve hours** once divided by the
14767
+ * successes on the same path. A surface that publishes only the numerator
14768
+ * reproduces that mistake on every read.
14769
+ *
14770
+ * ## Shape
14771
+ *
14772
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14773
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14774
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14775
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14776
+ * a forked runner's entries reach hub-main over transport that already exists.
14777
+ * No new UDS message, no second registry (D3). The operator reads the assembled
14778
+ * result through `system.getFailureContributions`.
14779
+ */
14780
+ var FailureReasonCountSchema = object({
14781
+ /**
14782
+ * Why the attempt did not land, in the contributor's own vocabulary —
14783
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14784
+ * strings that already appear in this repo's logs and, where one exists, the
14785
+ * same string the per-track `previewMissReason` records (D276): a second
14786
+ * vocabulary for the same loss would make the row and the counter
14787
+ * un-joinable.
14788
+ */
14789
+ reason: string(),
14790
+ count: number().int().nonnegative()
14791
+ });
14792
+ var FailureContributionSchema = object({
14793
+ /**
14794
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14795
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14796
+ * `unit` free: the families are owned by different addons and a shared enum
14797
+ * is a central list that rots invisibly.
14798
+ */
14799
+ family: string(),
14800
+ /**
14801
+ * The NUMERIC device id — the same value every log line carries as
14802
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
14803
+ * cannot name the camera must not emit the entry, because a fleet total
14804
+ * cannot answer the only question anybody asks of this surface.
14805
+ */
14806
+ deviceId: number().int().positive(),
14807
+ /**
14808
+ * A second dimension inside the family: the model / step id for an inference
14809
+ * timeout, so "which camera AND which model" is one read. Absent when the
14810
+ * family has a single variant.
14811
+ */
14812
+ variant: string().optional(),
14813
+ /**
14814
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14815
+ * differencing two reads must drop the interval when it changes, because the
14816
+ * counter restarted from zero in a respawned runner. Same discipline as
14817
+ * `LoadContribution.startedAtMs`.
14818
+ */
14819
+ sinceMs: number(),
14820
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14821
+ atMs: number(),
14822
+ /**
14823
+ * THE DENOMINATOR — every attempt on this path for this camera in the
14824
+ * window. A failure count published without it is the mistake this schema
14825
+ * exists to make impossible.
14826
+ */
14827
+ attempts: number().int().nonnegative(),
14828
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
14829
+ succeeded: number().int().nonnegative(),
14830
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
14831
+ reasons: array(FailureReasonCountSchema).readonly()
14832
+ });
14833
+ var failureContributionCapability = {
14834
+ name: "failure-contribution",
14835
+ scope: "system",
14836
+ mode: "collection",
14837
+ internal: true,
14838
+ methods: {
14839
+ /**
14840
+ * This addon's per-camera failure counters, read live from bounded in-RAM
14841
+ * state it already keeps. Inert: no persistence, no sampling, no timer.
14842
+ *
14843
+ * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
14844
+ * consumer that wants a rate differences two reads. A draining read would
14845
+ * make two operators with the page open each destroy half of the other's
14846
+ * numbers, and `load-contribution` already settled the same question the
14847
+ * same way for `cpuSeconds`.
14848
+ */
14849
+ list: method(_void(), array(FailureContributionSchema).readonly()) },
14850
+ /** In-process only — enumerated through `addons.listCapabilityProviders`. */
14851
+ mount: { kind: "skip" }
14852
+ };
14853
+ /**
14671
14854
  * filesystem-browse — per-node capability for browsing the node's local
14672
14855
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
14673
14856
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -15278,6 +15461,82 @@ var llmCapability = {
15278
15461
  })
15279
15462
  }
15280
15463
  };
15464
+ var LoadContributionSchema = object({
15465
+ role: _enum([
15466
+ "decode",
15467
+ "transcode",
15468
+ "recording",
15469
+ "streaming",
15470
+ "detection"
15471
+ ]),
15472
+ /**
15473
+ * The NUMERIC device id — the same value every log line carries as
15474
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
15475
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
15476
+ * contributor that cannot name its camera must not emit the entry at all,
15477
+ * because an unnamed per-camera entry is indistinguishable from a shared one
15478
+ * and would quietly turn one camera's cost into everybody's.
15479
+ */
15480
+ deviceId: number().int().positive().nullable(),
15481
+ attribution: _enum([
15482
+ "measured",
15483
+ "accounted",
15484
+ "unattributable"
15485
+ ]),
15486
+ /**
15487
+ * What ONE entry is, in the contributor's own words — `615/high`,
15488
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
15489
+ * family and inventing a common one would lose the only information that
15490
+ * makes two entries for the same camera distinguishable.
15491
+ */
15492
+ unit: string(),
15493
+ /**
15494
+ * The OS process this cost lives in, when there is one. Present so a
15495
+ * consumer can (a) tell two generations of the same unit apart across a
15496
+ * restart, and (b) subtract claimed processes from the node's process
15497
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
15498
+ * process of its own.
15499
+ */
15500
+ pid: number().int().positive().optional(),
15501
+ /**
15502
+ * When this generation started. The pid's incarnation marker: a consumer
15503
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
15504
+ * window when this changes, because the counter restarted from zero in a new
15505
+ * process.
15506
+ */
15507
+ startedAtMs: number().optional(),
15508
+ /**
15509
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
15510
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
15511
+ * contribution is asked for.
15512
+ *
15513
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
15514
+ * needs a sampler, and a new per-node sampler is the defect half of
15515
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
15516
+ * by whoever already keeps a history; a rate cannot be un-averaged.
15517
+ *
15518
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
15519
+ * an entry with no process.
15520
+ */
15521
+ cpuSeconds: number().optional(),
15522
+ /** Resident bytes of this unit's process, same source and same rules. */
15523
+ rssBytes: number().optional()
15524
+ });
15525
+ var loadContributionCapability = {
15526
+ name: "load-contribution",
15527
+ scope: "system",
15528
+ mode: "collection",
15529
+ internal: true,
15530
+ methods: {
15531
+ /**
15532
+ * This addon's own cost entries, computed live from state it already
15533
+ * holds. Inert: no persistence, no sampling, no timer. It is answered on
15534
+ * whatever beat the caller already has.
15535
+ */
15536
+ list: method(_void(), array(LoadContributionSchema).readonly()) },
15537
+ /** In-process only — enumerated through `addons.listCapabilityProviders`. */
15538
+ mount: { kind: "skip" }
15539
+ };
15281
15540
  /**
15282
15541
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
15283
15542
  * through. It stores nothing.
@@ -15386,209 +15645,6 @@ var logDestinationCapability = {
15386
15645
  mount: { kind: "skip" }
15387
15646
  };
15388
15647
  /**
15389
- * `failure-contribution` — the capability an addon reports its OWN losses
15390
- * through, per camera, with the denominator attached. It stores nothing.
15391
- *
15392
- * ## The twin of `load-contribution`, and why it is a twin and not a field
15393
- *
15394
- * `load-contribution` answers *what did this camera COST*. This answers *what
15395
- * did this camera LOSE*. The reporting discipline is identical and deliberately
15396
- * copied: the contributor reports what it already knows, hub-main adds only
15397
- * `addonId`, nothing needs global knowledge, and there is no central list for
15398
- * somebody to forget to edit.
15399
- *
15400
- * They are not merged, because their invariants are opposites:
15401
- *
15402
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
15403
- * claim a camera cost nothing, which is a measurement nobody made;
15404
- * - a `failure-contribution` zero is the **most valuable value on the
15405
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
15406
- * and it is exactly what an absent entry cannot say.
15407
- *
15408
- * Putting a loss counter on a cost entry would also break the reconciliation
15409
- * that gives `load-contribution` its point: contributions are subtracted from
15410
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
15411
- * has no process.
15412
- *
15413
- * ## Why not a log line, since the counters already exist
15414
- *
15415
- * Several of these paths already counted themselves — `CaptureScheduler`'s
15416
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
15417
- * ends in a log line, and a log line is the thing the operator asked to stop
15418
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
15419
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
15420
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
15421
- * media blackout were both diagnosed. The counters stay; this is where they can
15422
- * be READ.
15423
- *
15424
- * ## The rate is served with its denominator or not at all
15425
- *
15426
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
15427
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
15428
- * than yesterday" and was **flat across twelve hours** once divided by the
15429
- * successes on the same path. A surface that publishes only the numerator
15430
- * reproduces that mistake on every read.
15431
- *
15432
- * ## Shape
15433
- *
15434
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
15435
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
15436
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
15437
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
15438
- * a forked runner's entries reach hub-main over transport that already exists.
15439
- * No new UDS message, no second registry (D3). The operator reads the assembled
15440
- * result through `system.getFailureContributions`.
15441
- */
15442
- var FailureReasonCountSchema = object({
15443
- /**
15444
- * Why the attempt did not land, in the contributor's own vocabulary —
15445
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
15446
- * strings that already appear in this repo's logs and, where one exists, the
15447
- * same string the per-track `previewMissReason` records (D276): a second
15448
- * vocabulary for the same loss would make the row and the counter
15449
- * un-joinable.
15450
- */
15451
- reason: string(),
15452
- count: number().int().nonnegative()
15453
- });
15454
- var FailureContributionSchema = object({
15455
- /**
15456
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
15457
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
15458
- * `unit` free: the families are owned by different addons and a shared enum
15459
- * is a central list that rots invisibly.
15460
- */
15461
- family: string(),
15462
- /**
15463
- * The NUMERIC device id — the same value every log line carries as
15464
- * `tags.deviceId`. Never nullable and never absent: a contributor that
15465
- * cannot name the camera must not emit the entry, because a fleet total
15466
- * cannot answer the only question anybody asks of this surface.
15467
- */
15468
- deviceId: number().int().positive(),
15469
- /**
15470
- * A second dimension inside the family: the model / step id for an inference
15471
- * timeout, so "which camera AND which model" is one read. Absent when the
15472
- * family has a single variant.
15473
- */
15474
- variant: string().optional(),
15475
- /**
15476
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
15477
- * differencing two reads must drop the interval when it changes, because the
15478
- * counter restarted from zero in a respawned runner. Same discipline as
15479
- * `LoadContribution.startedAtMs`.
15480
- */
15481
- sinceMs: number(),
15482
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
15483
- atMs: number(),
15484
- /**
15485
- * THE DENOMINATOR — every attempt on this path for this camera in the
15486
- * window. A failure count published without it is the mistake this schema
15487
- * exists to make impossible.
15488
- */
15489
- attempts: number().int().nonnegative(),
15490
- /** Attempts that landed. `attempts - succeeded` is the loss. */
15491
- succeeded: number().int().nonnegative(),
15492
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
15493
- reasons: array(FailureReasonCountSchema).readonly()
15494
- });
15495
- var failureContributionCapability = {
15496
- name: "failure-contribution",
15497
- scope: "system",
15498
- mode: "collection",
15499
- internal: true,
15500
- methods: {
15501
- /**
15502
- * This addon's per-camera failure counters, read live from bounded in-RAM
15503
- * state it already keeps. Inert: no persistence, no sampling, no timer.
15504
- *
15505
- * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
15506
- * consumer that wants a rate differences two reads. A draining read would
15507
- * make two operators with the page open each destroy half of the other's
15508
- * numbers, and `load-contribution` already settled the same question the
15509
- * same way for `cpuSeconds`.
15510
- */
15511
- list: method(_void(), array(FailureContributionSchema).readonly()) },
15512
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
15513
- mount: { kind: "skip" }
15514
- };
15515
- var LoadContributionSchema = object({
15516
- role: _enum([
15517
- "decode",
15518
- "transcode",
15519
- "recording",
15520
- "streaming",
15521
- "detection"
15522
- ]),
15523
- /**
15524
- * The NUMERIC device id — the same value every log line carries as
15525
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
15526
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
15527
- * contributor that cannot name its camera must not emit the entry at all,
15528
- * because an unnamed per-camera entry is indistinguishable from a shared one
15529
- * and would quietly turn one camera's cost into everybody's.
15530
- */
15531
- deviceId: number().int().positive().nullable(),
15532
- attribution: _enum([
15533
- "measured",
15534
- "accounted",
15535
- "unattributable"
15536
- ]),
15537
- /**
15538
- * What ONE entry is, in the contributor's own words — `615/high`,
15539
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
15540
- * family and inventing a common one would lose the only information that
15541
- * makes two entries for the same camera distinguishable.
15542
- */
15543
- unit: string(),
15544
- /**
15545
- * The OS process this cost lives in, when there is one. Present so a
15546
- * consumer can (a) tell two generations of the same unit apart across a
15547
- * restart, and (b) subtract claimed processes from the node's process
15548
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
15549
- * process of its own.
15550
- */
15551
- pid: number().int().positive().optional(),
15552
- /**
15553
- * When this generation started. The pid's incarnation marker: a consumer
15554
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
15555
- * window when this changes, because the counter restarted from zero in a new
15556
- * process.
15557
- */
15558
- startedAtMs: number().optional(),
15559
- /**
15560
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
15561
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
15562
- * contribution is asked for.
15563
- *
15564
- * Cumulative and not a rate on purpose: a rate needs a window, a window
15565
- * needs a sampler, and a new per-node sampler is the defect half of
15566
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
15567
- * by whoever already keeps a history; a rate cannot be un-averaged.
15568
- *
15569
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
15570
- * an entry with no process.
15571
- */
15572
- cpuSeconds: number().optional(),
15573
- /** Resident bytes of this unit's process, same source and same rules. */
15574
- rssBytes: number().optional()
15575
- });
15576
- var loadContributionCapability = {
15577
- name: "load-contribution",
15578
- scope: "system",
15579
- mode: "collection",
15580
- internal: true,
15581
- methods: {
15582
- /**
15583
- * This addon's own cost entries, computed live from state it already
15584
- * holds. Inert: no persistence, no sampling, no timer. It is answered on
15585
- * whatever beat the caller already has.
15586
- */
15587
- list: method(_void(), array(LoadContributionSchema).readonly()) },
15588
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
15589
- mount: { kind: "skip" }
15590
- };
15591
- /**
15592
15648
  * `login-method` — collection cap through which auth addons contribute
15593
15649
  * their pre-auth login surfaces to the login page. This is the SINGLE,
15594
15650
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -21248,12 +21304,53 @@ var MediaFileKindEnum = _enum([
21248
21304
  "keyFrameSmall",
21249
21305
  "thumbnailSmall"
21250
21306
  ]);
21307
+ /**
21308
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
21309
+ * ARE — never the bytes themselves.
21310
+ *
21311
+ * ## Why `url` and not `base64`
21312
+ *
21313
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
21314
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
21315
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
21316
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
21317
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
21318
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
21319
+ *
21320
+ * `url` points at the `event-media` data plane
21321
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
21322
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
21323
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
21324
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
21325
+ * no less protected than they were inside a `view`-level cap response — see
21326
+ * `data-plane-access.ts` for the rule and the one gap it does not close
21327
+ * (per-device scoping).
21328
+ *
21329
+ * The URL is built from the row's **stored** key, which is not always its
21330
+ * published `kind`: a track's face/plate crop is stored as `crop` under
21331
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
21332
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
21333
+ *
21334
+ * ## `base64` is TRANSITIONAL and is going away
21335
+ *
21336
+ * It is still populated for one reason: the deployed viewer's track-detail
21337
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
21338
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
21339
+ * triangle — not as absence. Removing the field before that viewer ships is an
21340
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
21341
+ * delete this line and the `withBytes` pass-through in
21342
+ * `analytics-query-facade.ts`; nothing else reads it.
21343
+ */
21251
21344
  var MediaFileSchema = object({
21252
21345
  key: string(),
21253
21346
  kind: MediaFileKindEnum,
21254
- base64: string(),
21255
21347
  sizeBytes: number(),
21256
21348
  timestamp: number()
21349
+ }).extend({
21350
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
21351
+ url: string(),
21352
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
21353
+ base64: string()
21257
21354
  });
21258
21355
  /**
21259
21356
  * One media row WITHOUT its bytes.
@@ -21265,7 +21362,9 @@ var MediaFileSchema = object({
21265
21362
  * blocks the whole view.
21266
21363
  *
21267
21364
  * `sizeBytes` is carried because it is what lets a client decide between the
21268
- * stored blob and a `?variant=thumb` rendering without fetching either.
21365
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
21366
+ * `url` because a client that had to build the plane path itself is a second
21367
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
21269
21368
  */
21270
21369
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
21271
21370
  /**
@@ -22063,6 +22162,17 @@ var pipelineAnalyticsCapability = {
22063
22162
  * happens to stamp it. This count is what the migration planner's
22064
22163
  * non-blocking gate reads; `relocateMedia({ mode: 'seal' })` is what drives
22065
22164
  * it to zero.
22165
+ *
22166
+ * TWO indexed statements per collection, not a walk. It used to page the
22167
+ * whole collection at 200 rows per RPC ordered by an unindexed column, so
22168
+ * on the live hub — 1 254 576 rows — it hit the 60 s RPC deadline every
22169
+ * time it was called, and the migration it gates could never start. The
22170
+ * cheap question (`present`: is there at least one) is asked first and
22171
+ * separately from the expensive one (`rows`), because only the first has
22172
+ * to be answerable for the gate to do its job.
22173
+ *
22174
+ * **`null` is "not measurable", never zero** — at either level. An
22175
+ * unreadable collection must not read as a sealed one.
22066
22176
  */
22067
22177
  countUnstampedEventMedia: method(object({}), UnstampedEventMediaCountSchema, { auth: "admin" }),
22068
22178
  /**
@@ -22386,6 +22496,26 @@ var pipelineAnalyticsCapability = {
22386
22496
  deviceId: number()
22387
22497
  }), array(MediaFileInfoSchema).readonly()),
22388
22498
  /**
22499
+ * What media an EVENT has, without any of it — the twin `getEventMedia`
22500
+ * never had.
22501
+ *
22502
+ * `listTrackMedia` above got this treatment because a track's media is
22503
+ * 5-8 MB. An event's is worse per row, not better: an old-style event owns
22504
+ * a `crop` AND a native-resolution `fullFrameBoxed`, and the track DETAIL
22505
+ * modal — the one surface that legitimately shows the big kinds — unions
22506
+ * both listings to build its filmstrip. It then renders every tile from
22507
+ * the `event-media` plane by key and throws the bytes away. Measured on
22508
+ * the live hub: one event's `fullFrameBoxed` is 2 824 077 B, base64'd to
22509
+ * ~3.8 MB, allocated whole in hub-main's heap, for a list of keys.
22510
+ *
22511
+ * Same `deviceId` authorization subject as `getEventMedia`, and the same
22512
+ * rows — this is a projection of that method, never a different question.
22513
+ */
22514
+ listEventMedia: method(object({
22515
+ eventId: string(),
22516
+ deviceId: number()
22517
+ }), array(MediaFileInfoSchema).readonly()),
22518
+ /**
22389
22519
  * Search object events by text query using CLIP cosine similarity.
22390
22520
  * Encodes `text` via the `embedding-encoder` cap, queries the
22391
22521
  * `ObjectEmbeddingStore` with optional prefilters, ranks all matching
@@ -28732,10 +28862,24 @@ var FaceClusterSchema = object({
28732
28862
  size: number().int(),
28733
28863
  cohesion: number()
28734
28864
  });
28865
+ /**
28866
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
28867
+ * are — never the bytes.
28868
+ *
28869
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
28870
+ * track/event contract) is still populated because a deployed viewer requires
28871
+ * the field to parse a row at all; this method has no such reader. Its ONE
28872
+ * caller is the admin UI's detail modal, which was building
28873
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
28874
+ * dialog already rendering its key FRAME from the `event-media` plane.
28875
+ *
28876
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
28877
+ * media key directly, so this needed no new plane and no new access decision.
28878
+ */
28735
28879
  var MediaFileLiteSchema$1 = object({
28736
28880
  key: string(),
28737
28881
  kind: string(),
28738
- base64: string(),
28882
+ url: string(),
28739
28883
  sizeBytes: number(),
28740
28884
  timestamp: number()
28741
28885
  });
@@ -32125,10 +32269,24 @@ var PlateInfoSchema = object({
32125
32269
  */
32126
32270
  cropUrl: string().optional()
32127
32271
  });
32272
+ /**
32273
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
32274
+ * are — never the bytes.
32275
+ *
32276
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
32277
+ * track/event contract) is still populated because a deployed viewer requires
32278
+ * the field to parse a row at all; this method has no such reader. Its ONE
32279
+ * caller is the admin UI's detail modal, which was building
32280
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
32281
+ * dialog already rendering its key FRAME from the `event-media` plane.
32282
+ *
32283
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
32284
+ * media key directly, so this needed no new plane and no new access decision.
32285
+ */
32128
32286
  var MediaFileLiteSchema = object({
32129
32287
  key: string(),
32130
32288
  kind: string(),
32131
- base64: string(),
32289
+ url: string(),
32132
32290
  sizeBytes: number(),
32133
32291
  timestamp: number()
32134
32292
  });
@@ -39618,6 +39776,12 @@ Object.freeze({
39618
39776
  addonId: null,
39619
39777
  access: "view"
39620
39778
  },
39779
+ "pipelineAnalytics.listEventMedia": {
39780
+ capName: "pipeline-analytics",
39781
+ capScope: "device",
39782
+ addonId: null,
39783
+ access: "view"
39784
+ },
39621
39785
  "pipelineAnalytics.listGroups": {
39622
39786
  capName: "pipeline-analytics",
39623
39787
  capScope: "device",
@@ -43241,6 +43405,11 @@ Object.freeze({
43241
43405
  form: "array",
43242
43406
  optional: false
43243
43407
  }],
43408
+ "pipelineAnalytics.listEventMedia": [{
43409
+ name: "deviceId",
43410
+ form: "single",
43411
+ optional: false
43412
+ }],
43244
43413
  "pipelineAnalytics.listGroups": [{
43245
43414
  name: "deviceIds",
43246
43415
  form: "array",
@@ -45279,16 +45448,7 @@ var OsdManager = class {
45279
45448
  };
45280
45449
  getSourceCatalog = async ({ deviceId }) => {
45281
45450
  const devices = await this.safeListDevices();
45282
- const capsByDevice = /* @__PURE__ */ new Map();
45283
- for (const device of devices) try {
45284
- capsByDevice.set(device.id, await this.deps.listDeviceCaps(device.id));
45285
- } catch (err) {
45286
- this.logger.warn("osd-manager: cap enumeration failed — device omitted from catalog", {
45287
- tags: { deviceId: device.id },
45288
- meta: { error: String(err) }
45289
- });
45290
- }
45291
- return { sources: sourceOptionsFor(deviceId, devices, capsByDevice) };
45451
+ return { sources: sourceOptionsFor(deviceId, devices, await this.safeListDeviceCaps(deviceId, devices)) };
45292
45452
  };
45293
45453
  getConditionSupport = async () => {
45294
45454
  return {
@@ -45558,6 +45718,36 @@ var OsdManager = class {
45558
45718
  return [];
45559
45719
  }
45560
45720
  }
45721
+ /**
45722
+ * Every listed device's bound cap names, in ONE round trip.
45723
+ *
45724
+ * This used to be `listDeviceCaps(device.id)` inside the catalog loop, with a
45725
+ * per-device `catch` that omitted the device — 1 + 1 019 sequential
45726
+ * cross-process cap calls on the live hub 2026-08-30, behind an operator
45727
+ * opening a slot editor. The batch has no partial failure mode: it answers
45728
+ * for the whole set or it throws, and a throw lands where every per-device
45729
+ * read failing already landed — an empty map, hence a catalog with no
45730
+ * bindable sources. One log line instead of a thousand.
45731
+ *
45732
+ * `tags.deviceId` is the CAMERA whose editor is open, because that is the
45733
+ * question an operator asks ("why is 615's picker empty?"); the size of the
45734
+ * set that went unanswered rides in `meta`.
45735
+ */
45736
+ async safeListDeviceCaps(cameraDeviceId, devices) {
45737
+ if (devices.length === 0) return /* @__PURE__ */ new Map();
45738
+ try {
45739
+ return await this.deps.listDeviceCapsBatch(devices.map((d) => d.id));
45740
+ } catch (err) {
45741
+ this.logger.warn("osd-manager: cap enumeration failed — the source catalog has no bindable values", {
45742
+ tags: { deviceId: cameraDeviceId },
45743
+ meta: {
45744
+ devices: devices.length,
45745
+ error: String(err)
45746
+ }
45747
+ });
45748
+ return /* @__PURE__ */ new Map();
45749
+ }
45750
+ }
45561
45751
  };
45562
45752
  function cacheKey(deviceId, slotId) {
45563
45753
  return `${deviceId}:${slotId}`;
@@ -45642,9 +45832,9 @@ var OsdManagerAddon = class extends BaseAddon {
45642
45832
  name: d.name
45643
45833
  }));
45644
45834
  },
45645
- listDeviceCaps: async (deviceId) => {
45646
- const bindings = await ctx.api.deviceManager.getBindings.query({ deviceId });
45647
- return [...new Set(bindings.entries.map((e) => e.capName))];
45835
+ listDeviceCapsBatch: async (deviceIds) => {
45836
+ const rows = await ctx.api.deviceManager.getBindingsBatch.query({ deviceIds: [...deviceIds] });
45837
+ return new Map(rows.map((row) => [row.deviceId, [...new Set(row.entries.map((e) => e.capName))]]));
45648
45838
  },
45649
45839
  readLatestRecognitions: async (deviceId) => {
45650
45840
  const [faces, plates] = await Promise.all([ctx.api.faceGallery.listRecentFaces.query({