@camstack/addon-notifiers 1.2.50 → 1.2.51

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 +259 -174
  2. package/dist/addon.mjs +259 -174
  3. package/package.json +1 -1
package/dist/addon.js CHANGED
@@ -13094,6 +13094,114 @@ method(object({
13094
13094
  height: number()
13095
13095
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13096
13096
  /**
13097
+ * `failure-contribution` — the capability an addon reports its OWN losses
13098
+ * through, per camera, with the denominator attached. It stores nothing.
13099
+ *
13100
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
13101
+ *
13102
+ * `load-contribution` answers *what did this camera COST*. This answers *what
13103
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
13104
+ * copied: the contributor reports what it already knows, hub-main adds only
13105
+ * `addonId`, nothing needs global knowledge, and there is no central list for
13106
+ * somebody to forget to edit.
13107
+ *
13108
+ * They are not merged, because their invariants are opposites:
13109
+ *
13110
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
13111
+ * claim a camera cost nothing, which is a measurement nobody made;
13112
+ * - a `failure-contribution` zero is the **most valuable value on the
13113
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13114
+ * and it is exactly what an absent entry cannot say.
13115
+ *
13116
+ * Putting a loss counter on a cost entry would also break the reconciliation
13117
+ * that gives `load-contribution` its point: contributions are subtracted from
13118
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13119
+ * has no process.
13120
+ *
13121
+ * ## Why not a log line, since the counters already exist
13122
+ *
13123
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
13124
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13125
+ * ends in a log line, and a log line is the thing the operator asked to stop
13126
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13127
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13128
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13129
+ * media blackout were both diagnosed. The counters stay; this is where they can
13130
+ * be READ.
13131
+ *
13132
+ * ## The rate is served with its denominator or not at all
13133
+ *
13134
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
13135
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13136
+ * than yesterday" and was **flat across twelve hours** once divided by the
13137
+ * successes on the same path. A surface that publishes only the numerator
13138
+ * reproduces that mistake on every read.
13139
+ *
13140
+ * ## Shape
13141
+ *
13142
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13143
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13144
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13145
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13146
+ * a forked runner's entries reach hub-main over transport that already exists.
13147
+ * No new UDS message, no second registry (D3). The operator reads the assembled
13148
+ * result through `system.getFailureContributions`.
13149
+ */
13150
+ var FailureReasonCountSchema = object({
13151
+ /**
13152
+ * Why the attempt did not land, in the contributor's own vocabulary —
13153
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13154
+ * strings that already appear in this repo's logs and, where one exists, the
13155
+ * same string the per-track `previewMissReason` records (D276): a second
13156
+ * vocabulary for the same loss would make the row and the counter
13157
+ * un-joinable.
13158
+ */
13159
+ reason: string(),
13160
+ count: number().int().nonnegative()
13161
+ });
13162
+ var FailureContributionSchema = object({
13163
+ /**
13164
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13165
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13166
+ * `unit` free: the families are owned by different addons and a shared enum
13167
+ * is a central list that rots invisibly.
13168
+ */
13169
+ family: string(),
13170
+ /**
13171
+ * The NUMERIC device id — the same value every log line carries as
13172
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
13173
+ * cannot name the camera must not emit the entry, because a fleet total
13174
+ * cannot answer the only question anybody asks of this surface.
13175
+ */
13176
+ deviceId: number().int().positive(),
13177
+ /**
13178
+ * A second dimension inside the family: the model / step id for an inference
13179
+ * timeout, so "which camera AND which model" is one read. Absent when the
13180
+ * family has a single variant.
13181
+ */
13182
+ variant: string().optional(),
13183
+ /**
13184
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13185
+ * differencing two reads must drop the interval when it changes, because the
13186
+ * counter restarted from zero in a respawned runner. Same discipline as
13187
+ * `LoadContribution.startedAtMs`.
13188
+ */
13189
+ sinceMs: number(),
13190
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13191
+ atMs: number(),
13192
+ /**
13193
+ * THE DENOMINATOR — every attempt on this path for this camera in the
13194
+ * window. A failure count published without it is the mistake this schema
13195
+ * exists to make impossible.
13196
+ */
13197
+ attempts: number().int().nonnegative(),
13198
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
13199
+ succeeded: number().int().nonnegative(),
13200
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
13201
+ reasons: array(FailureReasonCountSchema).readonly()
13202
+ });
13203
+ method(_void(), array(FailureContributionSchema).readonly());
13204
+ /**
13097
13205
  * filesystem-browse — per-node capability for browsing the node's local
13098
13206
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13099
13207
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13615,6 +13723,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13615
13723
  kind: "mutation",
13616
13724
  auth: "admin"
13617
13725
  });
13726
+ var LoadContributionSchema = object({
13727
+ role: _enum([
13728
+ "decode",
13729
+ "transcode",
13730
+ "recording",
13731
+ "streaming",
13732
+ "detection"
13733
+ ]),
13734
+ /**
13735
+ * The NUMERIC device id — the same value every log line carries as
13736
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13737
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
13738
+ * contributor that cannot name its camera must not emit the entry at all,
13739
+ * because an unnamed per-camera entry is indistinguishable from a shared one
13740
+ * and would quietly turn one camera's cost into everybody's.
13741
+ */
13742
+ deviceId: number().int().positive().nullable(),
13743
+ attribution: _enum([
13744
+ "measured",
13745
+ "accounted",
13746
+ "unattributable"
13747
+ ]),
13748
+ /**
13749
+ * What ONE entry is, in the contributor's own words — `615/high`,
13750
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13751
+ * family and inventing a common one would lose the only information that
13752
+ * makes two entries for the same camera distinguishable.
13753
+ */
13754
+ unit: string(),
13755
+ /**
13756
+ * The OS process this cost lives in, when there is one. Present so a
13757
+ * consumer can (a) tell two generations of the same unit apart across a
13758
+ * restart, and (b) subtract claimed processes from the node's process
13759
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
13760
+ * process of its own.
13761
+ */
13762
+ pid: number().int().positive().optional(),
13763
+ /**
13764
+ * When this generation started. The pid's incarnation marker: a consumer
13765
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
13766
+ * window when this changes, because the counter restarted from zero in a new
13767
+ * process.
13768
+ */
13769
+ startedAtMs: number().optional(),
13770
+ /**
13771
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
13772
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
13773
+ * contribution is asked for.
13774
+ *
13775
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
13776
+ * needs a sampler, and a new per-node sampler is the defect half of
13777
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
13778
+ * by whoever already keeps a history; a rate cannot be un-averaged.
13779
+ *
13780
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
13781
+ * an entry with no process.
13782
+ */
13783
+ cpuSeconds: number().optional(),
13784
+ /** Resident bytes of this unit's process, same source and same rules. */
13785
+ rssBytes: number().optional()
13786
+ });
13787
+ method(_void(), array(LoadContributionSchema).readonly());
13618
13788
  /**
13619
13789
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13620
13790
  * through. It stores nothing.
@@ -13691,176 +13861,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
13691
13861
  tags: record(string(), string()).optional()
13692
13862
  }), array(LogEntrySchema).readonly());
13693
13863
  /**
13694
- * `failure-contribution` — the capability an addon reports its OWN losses
13695
- * through, per camera, with the denominator attached. It stores nothing.
13696
- *
13697
- * ## The twin of `load-contribution`, and why it is a twin and not a field
13698
- *
13699
- * `load-contribution` answers *what did this camera COST*. This answers *what
13700
- * did this camera LOSE*. The reporting discipline is identical and deliberately
13701
- * copied: the contributor reports what it already knows, hub-main adds only
13702
- * `addonId`, nothing needs global knowledge, and there is no central list for
13703
- * somebody to forget to edit.
13704
- *
13705
- * They are not merged, because their invariants are opposites:
13706
- *
13707
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
13708
- * claim a camera cost nothing, which is a measurement nobody made;
13709
- * - a `failure-contribution` zero is the **most valuable value on the
13710
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13711
- * and it is exactly what an absent entry cannot say.
13712
- *
13713
- * Putting a loss counter on a cost entry would also break the reconciliation
13714
- * that gives `load-contribution` its point: contributions are subtracted from
13715
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13716
- * has no process.
13717
- *
13718
- * ## Why not a log line, since the counters already exist
13719
- *
13720
- * Several of these paths already counted themselves — `CaptureScheduler`'s
13721
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13722
- * ends in a log line, and a log line is the thing the operator asked to stop
13723
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13724
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13725
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13726
- * media blackout were both diagnosed. The counters stay; this is where they can
13727
- * be READ.
13728
- *
13729
- * ## The rate is served with its denominator or not at all
13730
- *
13731
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
13732
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13733
- * than yesterday" and was **flat across twelve hours** once divided by the
13734
- * successes on the same path. A surface that publishes only the numerator
13735
- * reproduces that mistake on every read.
13736
- *
13737
- * ## Shape
13738
- *
13739
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13740
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13741
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13742
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13743
- * a forked runner's entries reach hub-main over transport that already exists.
13744
- * No new UDS message, no second registry (D3). The operator reads the assembled
13745
- * result through `system.getFailureContributions`.
13746
- */
13747
- var FailureReasonCountSchema = object({
13748
- /**
13749
- * Why the attempt did not land, in the contributor's own vocabulary —
13750
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13751
- * strings that already appear in this repo's logs and, where one exists, the
13752
- * same string the per-track `previewMissReason` records (D276): a second
13753
- * vocabulary for the same loss would make the row and the counter
13754
- * un-joinable.
13755
- */
13756
- reason: string(),
13757
- count: number().int().nonnegative()
13758
- });
13759
- var FailureContributionSchema = object({
13760
- /**
13761
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13762
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13763
- * `unit` free: the families are owned by different addons and a shared enum
13764
- * is a central list that rots invisibly.
13765
- */
13766
- family: string(),
13767
- /**
13768
- * The NUMERIC device id — the same value every log line carries as
13769
- * `tags.deviceId`. Never nullable and never absent: a contributor that
13770
- * cannot name the camera must not emit the entry, because a fleet total
13771
- * cannot answer the only question anybody asks of this surface.
13772
- */
13773
- deviceId: number().int().positive(),
13774
- /**
13775
- * A second dimension inside the family: the model / step id for an inference
13776
- * timeout, so "which camera AND which model" is one read. Absent when the
13777
- * family has a single variant.
13778
- */
13779
- variant: string().optional(),
13780
- /**
13781
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13782
- * differencing two reads must drop the interval when it changes, because the
13783
- * counter restarted from zero in a respawned runner. Same discipline as
13784
- * `LoadContribution.startedAtMs`.
13785
- */
13786
- sinceMs: number(),
13787
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13788
- atMs: number(),
13789
- /**
13790
- * THE DENOMINATOR — every attempt on this path for this camera in the
13791
- * window. A failure count published without it is the mistake this schema
13792
- * exists to make impossible.
13793
- */
13794
- attempts: number().int().nonnegative(),
13795
- /** Attempts that landed. `attempts - succeeded` is the loss. */
13796
- succeeded: number().int().nonnegative(),
13797
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
13798
- reasons: array(FailureReasonCountSchema).readonly()
13799
- });
13800
- method(_void(), array(FailureContributionSchema).readonly());
13801
- var LoadContributionSchema = object({
13802
- role: _enum([
13803
- "decode",
13804
- "transcode",
13805
- "recording",
13806
- "streaming",
13807
- "detection"
13808
- ]),
13809
- /**
13810
- * The NUMERIC device id — the same value every log line carries as
13811
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13812
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
13813
- * contributor that cannot name its camera must not emit the entry at all,
13814
- * because an unnamed per-camera entry is indistinguishable from a shared one
13815
- * and would quietly turn one camera's cost into everybody's.
13816
- */
13817
- deviceId: number().int().positive().nullable(),
13818
- attribution: _enum([
13819
- "measured",
13820
- "accounted",
13821
- "unattributable"
13822
- ]),
13823
- /**
13824
- * What ONE entry is, in the contributor's own words — `615/high`,
13825
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13826
- * family and inventing a common one would lose the only information that
13827
- * makes two entries for the same camera distinguishable.
13828
- */
13829
- unit: string(),
13830
- /**
13831
- * The OS process this cost lives in, when there is one. Present so a
13832
- * consumer can (a) tell two generations of the same unit apart across a
13833
- * restart, and (b) subtract claimed processes from the node's process
13834
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
13835
- * process of its own.
13836
- */
13837
- pid: number().int().positive().optional(),
13838
- /**
13839
- * When this generation started. The pid's incarnation marker: a consumer
13840
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
13841
- * window when this changes, because the counter restarted from zero in a new
13842
- * process.
13843
- */
13844
- startedAtMs: number().optional(),
13845
- /**
13846
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
13847
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
13848
- * contribution is asked for.
13849
- *
13850
- * Cumulative and not a rate on purpose: a rate needs a window, a window
13851
- * needs a sampler, and a new per-node sampler is the defect half of
13852
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
13853
- * by whoever already keeps a history; a rate cannot be un-averaged.
13854
- *
13855
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
13856
- * an entry with no process.
13857
- */
13858
- cpuSeconds: number().optional(),
13859
- /** Resident bytes of this unit's process, same source and same rules. */
13860
- rssBytes: number().optional()
13861
- });
13862
- method(_void(), array(LoadContributionSchema).readonly());
13863
- /**
13864
13864
  * `login-method` — collection cap through which auth addons contribute
13865
13865
  * their pre-auth login surfaces to the login page. This is the SINGLE,
13866
13866
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18534,12 +18534,53 @@ var MediaFileKindEnum = _enum([
18534
18534
  "keyFrameSmall",
18535
18535
  "thumbnailSmall"
18536
18536
  ]);
18537
+ /**
18538
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
18539
+ * ARE — never the bytes themselves.
18540
+ *
18541
+ * ## Why `url` and not `base64`
18542
+ *
18543
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
18544
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
18545
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
18546
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
18547
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
18548
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
18549
+ *
18550
+ * `url` points at the `event-media` data plane
18551
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
18552
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
18553
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
18554
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
18555
+ * no less protected than they were inside a `view`-level cap response — see
18556
+ * `data-plane-access.ts` for the rule and the one gap it does not close
18557
+ * (per-device scoping).
18558
+ *
18559
+ * The URL is built from the row's **stored** key, which is not always its
18560
+ * published `kind`: a track's face/plate crop is stored as `crop` under
18561
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
18562
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
18563
+ *
18564
+ * ## `base64` is TRANSITIONAL and is going away
18565
+ *
18566
+ * It is still populated for one reason: the deployed viewer's track-detail
18567
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
18568
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
18569
+ * triangle — not as absence. Removing the field before that viewer ships is an
18570
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
18571
+ * delete this line and the `withBytes` pass-through in
18572
+ * `analytics-query-facade.ts`; nothing else reads it.
18573
+ */
18537
18574
  var MediaFileSchema = object({
18538
18575
  key: string(),
18539
18576
  kind: MediaFileKindEnum,
18540
- base64: string(),
18541
18577
  sizeBytes: number(),
18542
18578
  timestamp: number()
18579
+ }).extend({
18580
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
18581
+ url: string(),
18582
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
18583
+ base64: string()
18543
18584
  });
18544
18585
  /**
18545
18586
  * One media row WITHOUT its bytes.
@@ -18551,7 +18592,9 @@ var MediaFileSchema = object({
18551
18592
  * blocks the whole view.
18552
18593
  *
18553
18594
  * `sizeBytes` is carried because it is what lets a client decide between the
18554
- * stored blob and a `?variant=thumb` rendering without fetching either.
18595
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
18596
+ * `url` because a client that had to build the plane path itself is a second
18597
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
18555
18598
  */
18556
18599
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
18557
18600
  /**
@@ -19240,6 +19283,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19240
19283
  }), array(MediaFileSchema).readonly()), method(object({
19241
19284
  trackId: string(),
19242
19285
  deviceId: number()
19286
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19287
+ eventId: string(),
19288
+ deviceId: number()
19243
19289
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19244
19290
  kind: "mutation",
19245
19291
  auth: "admin"
@@ -23500,10 +23546,24 @@ var FaceClusterSchema = object({
23500
23546
  size: number().int(),
23501
23547
  cohesion: number()
23502
23548
  });
23549
+ /**
23550
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
23551
+ * are — never the bytes.
23552
+ *
23553
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
23554
+ * track/event contract) is still populated because a deployed viewer requires
23555
+ * the field to parse a row at all; this method has no such reader. Its ONE
23556
+ * caller is the admin UI's detail modal, which was building
23557
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
23558
+ * dialog already rendering its key FRAME from the `event-media` plane.
23559
+ *
23560
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
23561
+ * media key directly, so this needed no new plane and no new access decision.
23562
+ */
23503
23563
  var MediaFileLiteSchema$1 = object({
23504
23564
  key: string(),
23505
23565
  kind: string(),
23506
- base64: string(),
23566
+ url: string(),
23507
23567
  sizeBytes: number(),
23508
23568
  timestamp: number()
23509
23569
  });
@@ -25755,10 +25815,24 @@ var PlateInfoSchema = object({
25755
25815
  */
25756
25816
  cropUrl: string().optional()
25757
25817
  });
25818
+ /**
25819
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
25820
+ * are — never the bytes.
25821
+ *
25822
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
25823
+ * track/event contract) is still populated because a deployed viewer requires
25824
+ * the field to parse a row at all; this method has no such reader. Its ONE
25825
+ * caller is the admin UI's detail modal, which was building
25826
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
25827
+ * dialog already rendering its key FRAME from the `event-media` plane.
25828
+ *
25829
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
25830
+ * media key directly, so this needed no new plane and no new access decision.
25831
+ */
25758
25832
  var MediaFileLiteSchema = object({
25759
25833
  key: string(),
25760
25834
  kind: string(),
25761
- base64: string(),
25835
+ url: string(),
25762
25836
  sizeBytes: number(),
25763
25837
  timestamp: number()
25764
25838
  });
@@ -31771,6 +31845,12 @@ Object.freeze({
31771
31845
  addonId: null,
31772
31846
  access: "view"
31773
31847
  },
31848
+ "pipelineAnalytics.listEventMedia": {
31849
+ capName: "pipeline-analytics",
31850
+ capScope: "device",
31851
+ addonId: null,
31852
+ access: "view"
31853
+ },
31774
31854
  "pipelineAnalytics.listGroups": {
31775
31855
  capName: "pipeline-analytics",
31776
31856
  capScope: "device",
@@ -35394,6 +35474,11 @@ Object.freeze({
35394
35474
  form: "array",
35395
35475
  optional: false
35396
35476
  }],
35477
+ "pipelineAnalytics.listEventMedia": [{
35478
+ name: "deviceId",
35479
+ form: "single",
35480
+ optional: false
35481
+ }],
35397
35482
  "pipelineAnalytics.listGroups": [{
35398
35483
  name: "deviceIds",
35399
35484
  form: "array",
package/dist/addon.mjs CHANGED
@@ -13067,6 +13067,114 @@ method(object({
13067
13067
  height: number()
13068
13068
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
13069
13069
  /**
13070
+ * `failure-contribution` — the capability an addon reports its OWN losses
13071
+ * through, per camera, with the denominator attached. It stores nothing.
13072
+ *
13073
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
13074
+ *
13075
+ * `load-contribution` answers *what did this camera COST*. This answers *what
13076
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
13077
+ * copied: the contributor reports what it already knows, hub-main adds only
13078
+ * `addonId`, nothing needs global knowledge, and there is no central list for
13079
+ * somebody to forget to edit.
13080
+ *
13081
+ * They are not merged, because their invariants are opposites:
13082
+ *
13083
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
13084
+ * claim a camera cost nothing, which is a measurement nobody made;
13085
+ * - a `failure-contribution` zero is the **most valuable value on the
13086
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13087
+ * and it is exactly what an absent entry cannot say.
13088
+ *
13089
+ * Putting a loss counter on a cost entry would also break the reconciliation
13090
+ * that gives `load-contribution` its point: contributions are subtracted from
13091
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13092
+ * has no process.
13093
+ *
13094
+ * ## Why not a log line, since the counters already exist
13095
+ *
13096
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
13097
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13098
+ * ends in a log line, and a log line is the thing the operator asked to stop
13099
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13100
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13101
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13102
+ * media blackout were both diagnosed. The counters stay; this is where they can
13103
+ * be READ.
13104
+ *
13105
+ * ## The rate is served with its denominator or not at all
13106
+ *
13107
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
13108
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13109
+ * than yesterday" and was **flat across twelve hours** once divided by the
13110
+ * successes on the same path. A surface that publishes only the numerator
13111
+ * reproduces that mistake on every read.
13112
+ *
13113
+ * ## Shape
13114
+ *
13115
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13116
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13117
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13118
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13119
+ * a forked runner's entries reach hub-main over transport that already exists.
13120
+ * No new UDS message, no second registry (D3). The operator reads the assembled
13121
+ * result through `system.getFailureContributions`.
13122
+ */
13123
+ var FailureReasonCountSchema = object({
13124
+ /**
13125
+ * Why the attempt did not land, in the contributor's own vocabulary —
13126
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13127
+ * strings that already appear in this repo's logs and, where one exists, the
13128
+ * same string the per-track `previewMissReason` records (D276): a second
13129
+ * vocabulary for the same loss would make the row and the counter
13130
+ * un-joinable.
13131
+ */
13132
+ reason: string(),
13133
+ count: number().int().nonnegative()
13134
+ });
13135
+ var FailureContributionSchema = object({
13136
+ /**
13137
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13138
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13139
+ * `unit` free: the families are owned by different addons and a shared enum
13140
+ * is a central list that rots invisibly.
13141
+ */
13142
+ family: string(),
13143
+ /**
13144
+ * The NUMERIC device id — the same value every log line carries as
13145
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
13146
+ * cannot name the camera must not emit the entry, because a fleet total
13147
+ * cannot answer the only question anybody asks of this surface.
13148
+ */
13149
+ deviceId: number().int().positive(),
13150
+ /**
13151
+ * A second dimension inside the family: the model / step id for an inference
13152
+ * timeout, so "which camera AND which model" is one read. Absent when the
13153
+ * family has a single variant.
13154
+ */
13155
+ variant: string().optional(),
13156
+ /**
13157
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13158
+ * differencing two reads must drop the interval when it changes, because the
13159
+ * counter restarted from zero in a respawned runner. Same discipline as
13160
+ * `LoadContribution.startedAtMs`.
13161
+ */
13162
+ sinceMs: number(),
13163
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13164
+ atMs: number(),
13165
+ /**
13166
+ * THE DENOMINATOR — every attempt on this path for this camera in the
13167
+ * window. A failure count published without it is the mistake this schema
13168
+ * exists to make impossible.
13169
+ */
13170
+ attempts: number().int().nonnegative(),
13171
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
13172
+ succeeded: number().int().nonnegative(),
13173
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
13174
+ reasons: array(FailureReasonCountSchema).readonly()
13175
+ });
13176
+ method(_void(), array(FailureContributionSchema).readonly());
13177
+ /**
13070
13178
  * filesystem-browse — per-node capability for browsing the node's local
13071
13179
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
13072
13180
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -13588,6 +13696,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
13588
13696
  kind: "mutation",
13589
13697
  auth: "admin"
13590
13698
  });
13699
+ var LoadContributionSchema = object({
13700
+ role: _enum([
13701
+ "decode",
13702
+ "transcode",
13703
+ "recording",
13704
+ "streaming",
13705
+ "detection"
13706
+ ]),
13707
+ /**
13708
+ * The NUMERIC device id — the same value every log line carries as
13709
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13710
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
13711
+ * contributor that cannot name its camera must not emit the entry at all,
13712
+ * because an unnamed per-camera entry is indistinguishable from a shared one
13713
+ * and would quietly turn one camera's cost into everybody's.
13714
+ */
13715
+ deviceId: number().int().positive().nullable(),
13716
+ attribution: _enum([
13717
+ "measured",
13718
+ "accounted",
13719
+ "unattributable"
13720
+ ]),
13721
+ /**
13722
+ * What ONE entry is, in the contributor's own words — `615/high`,
13723
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13724
+ * family and inventing a common one would lose the only information that
13725
+ * makes two entries for the same camera distinguishable.
13726
+ */
13727
+ unit: string(),
13728
+ /**
13729
+ * The OS process this cost lives in, when there is one. Present so a
13730
+ * consumer can (a) tell two generations of the same unit apart across a
13731
+ * restart, and (b) subtract claimed processes from the node's process
13732
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
13733
+ * process of its own.
13734
+ */
13735
+ pid: number().int().positive().optional(),
13736
+ /**
13737
+ * When this generation started. The pid's incarnation marker: a consumer
13738
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
13739
+ * window when this changes, because the counter restarted from zero in a new
13740
+ * process.
13741
+ */
13742
+ startedAtMs: number().optional(),
13743
+ /**
13744
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
13745
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
13746
+ * contribution is asked for.
13747
+ *
13748
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
13749
+ * needs a sampler, and a new per-node sampler is the defect half of
13750
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
13751
+ * by whoever already keeps a history; a rate cannot be un-averaged.
13752
+ *
13753
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
13754
+ * an entry with no process.
13755
+ */
13756
+ cpuSeconds: number().optional(),
13757
+ /** Resident bytes of this unit's process, same source and same rules. */
13758
+ rssBytes: number().optional()
13759
+ });
13760
+ method(_void(), array(LoadContributionSchema).readonly());
13591
13761
  /**
13592
13762
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
13593
13763
  * through. It stores nothing.
@@ -13664,176 +13834,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
13664
13834
  tags: record(string(), string()).optional()
13665
13835
  }), array(LogEntrySchema).readonly());
13666
13836
  /**
13667
- * `failure-contribution` — the capability an addon reports its OWN losses
13668
- * through, per camera, with the denominator attached. It stores nothing.
13669
- *
13670
- * ## The twin of `load-contribution`, and why it is a twin and not a field
13671
- *
13672
- * `load-contribution` answers *what did this camera COST*. This answers *what
13673
- * did this camera LOSE*. The reporting discipline is identical and deliberately
13674
- * copied: the contributor reports what it already knows, hub-main adds only
13675
- * `addonId`, nothing needs global knowledge, and there is no central list for
13676
- * somebody to forget to edit.
13677
- *
13678
- * They are not merged, because their invariants are opposites:
13679
- *
13680
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
13681
- * claim a camera cost nothing, which is a measurement nobody made;
13682
- * - a `failure-contribution` zero is the **most valuable value on the
13683
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
13684
- * and it is exactly what an absent entry cannot say.
13685
- *
13686
- * Putting a loss counter on a cost entry would also break the reconciliation
13687
- * that gives `load-contribution` its point: contributions are subtracted from
13688
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
13689
- * has no process.
13690
- *
13691
- * ## Why not a log line, since the counters already exist
13692
- *
13693
- * Several of these paths already counted themselves — `CaptureScheduler`'s
13694
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
13695
- * ends in a log line, and a log line is the thing the operator asked to stop
13696
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
13697
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
13698
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
13699
- * media blackout were both diagnosed. The counters stay; this is where they can
13700
- * be READ.
13701
- *
13702
- * ## The rate is served with its denominator or not at all
13703
- *
13704
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
13705
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
13706
- * than yesterday" and was **flat across twelve hours** once divided by the
13707
- * successes on the same path. A surface that publishes only the numerator
13708
- * reproduces that mistake on every read.
13709
- *
13710
- * ## Shape
13711
- *
13712
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
13713
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
13714
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
13715
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
13716
- * a forked runner's entries reach hub-main over transport that already exists.
13717
- * No new UDS message, no second registry (D3). The operator reads the assembled
13718
- * result through `system.getFailureContributions`.
13719
- */
13720
- var FailureReasonCountSchema = object({
13721
- /**
13722
- * Why the attempt did not land, in the contributor's own vocabulary —
13723
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
13724
- * strings that already appear in this repo's logs and, where one exists, the
13725
- * same string the per-track `previewMissReason` records (D276): a second
13726
- * vocabulary for the same loss would make the row and the counter
13727
- * un-joinable.
13728
- */
13729
- reason: string(),
13730
- count: number().int().nonnegative()
13731
- });
13732
- var FailureContributionSchema = object({
13733
- /**
13734
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
13735
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
13736
- * `unit` free: the families are owned by different addons and a shared enum
13737
- * is a central list that rots invisibly.
13738
- */
13739
- family: string(),
13740
- /**
13741
- * The NUMERIC device id — the same value every log line carries as
13742
- * `tags.deviceId`. Never nullable and never absent: a contributor that
13743
- * cannot name the camera must not emit the entry, because a fleet total
13744
- * cannot answer the only question anybody asks of this surface.
13745
- */
13746
- deviceId: number().int().positive(),
13747
- /**
13748
- * A second dimension inside the family: the model / step id for an inference
13749
- * timeout, so "which camera AND which model" is one read. Absent when the
13750
- * family has a single variant.
13751
- */
13752
- variant: string().optional(),
13753
- /**
13754
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
13755
- * differencing two reads must drop the interval when it changes, because the
13756
- * counter restarted from zero in a respawned runner. Same discipline as
13757
- * `LoadContribution.startedAtMs`.
13758
- */
13759
- sinceMs: number(),
13760
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
13761
- atMs: number(),
13762
- /**
13763
- * THE DENOMINATOR — every attempt on this path for this camera in the
13764
- * window. A failure count published without it is the mistake this schema
13765
- * exists to make impossible.
13766
- */
13767
- attempts: number().int().nonnegative(),
13768
- /** Attempts that landed. `attempts - succeeded` is the loss. */
13769
- succeeded: number().int().nonnegative(),
13770
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
13771
- reasons: array(FailureReasonCountSchema).readonly()
13772
- });
13773
- method(_void(), array(FailureContributionSchema).readonly());
13774
- var LoadContributionSchema = object({
13775
- role: _enum([
13776
- "decode",
13777
- "transcode",
13778
- "recording",
13779
- "streaming",
13780
- "detection"
13781
- ]),
13782
- /**
13783
- * The NUMERIC device id — the same value every log line carries as
13784
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
13785
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
13786
- * contributor that cannot name its camera must not emit the entry at all,
13787
- * because an unnamed per-camera entry is indistinguishable from a shared one
13788
- * and would quietly turn one camera's cost into everybody's.
13789
- */
13790
- deviceId: number().int().positive().nullable(),
13791
- attribution: _enum([
13792
- "measured",
13793
- "accounted",
13794
- "unattributable"
13795
- ]),
13796
- /**
13797
- * What ONE entry is, in the contributor's own words — `615/high`,
13798
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
13799
- * family and inventing a common one would lose the only information that
13800
- * makes two entries for the same camera distinguishable.
13801
- */
13802
- unit: string(),
13803
- /**
13804
- * The OS process this cost lives in, when there is one. Present so a
13805
- * consumer can (a) tell two generations of the same unit apart across a
13806
- * restart, and (b) subtract claimed processes from the node's process
13807
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
13808
- * process of its own.
13809
- */
13810
- pid: number().int().positive().optional(),
13811
- /**
13812
- * When this generation started. The pid's incarnation marker: a consumer
13813
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
13814
- * window when this changes, because the counter restarted from zero in a new
13815
- * process.
13816
- */
13817
- startedAtMs: number().optional(),
13818
- /**
13819
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
13820
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
13821
- * contribution is asked for.
13822
- *
13823
- * Cumulative and not a rate on purpose: a rate needs a window, a window
13824
- * needs a sampler, and a new per-node sampler is the defect half of
13825
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
13826
- * by whoever already keeps a history; a rate cannot be un-averaged.
13827
- *
13828
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
13829
- * an entry with no process.
13830
- */
13831
- cpuSeconds: number().optional(),
13832
- /** Resident bytes of this unit's process, same source and same rules. */
13833
- rssBytes: number().optional()
13834
- });
13835
- method(_void(), array(LoadContributionSchema).readonly());
13836
- /**
13837
13837
  * `login-method` — collection cap through which auth addons contribute
13838
13838
  * their pre-auth login surfaces to the login page. This is the SINGLE,
13839
13839
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -18507,12 +18507,53 @@ var MediaFileKindEnum = _enum([
18507
18507
  "keyFrameSmall",
18508
18508
  "thumbnailSmall"
18509
18509
  ]);
18510
+ /**
18511
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
18512
+ * ARE — never the bytes themselves.
18513
+ *
18514
+ * ## Why `url` and not `base64`
18515
+ *
18516
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
18517
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
18518
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
18519
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
18520
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
18521
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
18522
+ *
18523
+ * `url` points at the `event-media` data plane
18524
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
18525
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
18526
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
18527
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
18528
+ * no less protected than they were inside a `view`-level cap response — see
18529
+ * `data-plane-access.ts` for the rule and the one gap it does not close
18530
+ * (per-device scoping).
18531
+ *
18532
+ * The URL is built from the row's **stored** key, which is not always its
18533
+ * published `kind`: a track's face/plate crop is stored as `crop` under
18534
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
18535
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
18536
+ *
18537
+ * ## `base64` is TRANSITIONAL and is going away
18538
+ *
18539
+ * It is still populated for one reason: the deployed viewer's track-detail
18540
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
18541
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
18542
+ * triangle — not as absence. Removing the field before that viewer ships is an
18543
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
18544
+ * delete this line and the `withBytes` pass-through in
18545
+ * `analytics-query-facade.ts`; nothing else reads it.
18546
+ */
18510
18547
  var MediaFileSchema = object({
18511
18548
  key: string(),
18512
18549
  kind: MediaFileKindEnum,
18513
- base64: string(),
18514
18550
  sizeBytes: number(),
18515
18551
  timestamp: number()
18552
+ }).extend({
18553
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
18554
+ url: string(),
18555
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
18556
+ base64: string()
18516
18557
  });
18517
18558
  /**
18518
18559
  * One media row WITHOUT its bytes.
@@ -18524,7 +18565,9 @@ var MediaFileSchema = object({
18524
18565
  * blocks the whole view.
18525
18566
  *
18526
18567
  * `sizeBytes` is carried because it is what lets a client decide between the
18527
- * stored blob and a `?variant=thumb` rendering without fetching either.
18568
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
18569
+ * `url` because a client that had to build the plane path itself is a second
18570
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
18528
18571
  */
18529
18572
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
18530
18573
  /**
@@ -19213,6 +19256,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
19213
19256
  }), array(MediaFileSchema).readonly()), method(object({
19214
19257
  trackId: string(),
19215
19258
  deviceId: number()
19259
+ }), array(MediaFileInfoSchema).readonly()), method(object({
19260
+ eventId: string(),
19261
+ deviceId: number()
19216
19262
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
19217
19263
  kind: "mutation",
19218
19264
  auth: "admin"
@@ -23473,10 +23519,24 @@ var FaceClusterSchema = object({
23473
23519
  size: number().int(),
23474
23520
  cohesion: number()
23475
23521
  });
23522
+ /**
23523
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
23524
+ * are — never the bytes.
23525
+ *
23526
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
23527
+ * track/event contract) is still populated because a deployed viewer requires
23528
+ * the field to parse a row at all; this method has no such reader. Its ONE
23529
+ * caller is the admin UI's detail modal, which was building
23530
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
23531
+ * dialog already rendering its key FRAME from the `event-media` plane.
23532
+ *
23533
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
23534
+ * media key directly, so this needed no new plane and no new access decision.
23535
+ */
23476
23536
  var MediaFileLiteSchema$1 = object({
23477
23537
  key: string(),
23478
23538
  kind: string(),
23479
- base64: string(),
23539
+ url: string(),
23480
23540
  sizeBytes: number(),
23481
23541
  timestamp: number()
23482
23542
  });
@@ -25728,10 +25788,24 @@ var PlateInfoSchema = object({
25728
25788
  */
25729
25789
  cropUrl: string().optional()
25730
25790
  });
25791
+ /**
25792
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
25793
+ * are — never the bytes.
25794
+ *
25795
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
25796
+ * track/event contract) is still populated because a deployed viewer requires
25797
+ * the field to parse a row at all; this method has no such reader. Its ONE
25798
+ * caller is the admin UI's detail modal, which was building
25799
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
25800
+ * dialog already rendering its key FRAME from the `event-media` plane.
25801
+ *
25802
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
25803
+ * media key directly, so this needed no new plane and no new access decision.
25804
+ */
25731
25805
  var MediaFileLiteSchema = object({
25732
25806
  key: string(),
25733
25807
  kind: string(),
25734
- base64: string(),
25808
+ url: string(),
25735
25809
  sizeBytes: number(),
25736
25810
  timestamp: number()
25737
25811
  });
@@ -31744,6 +31818,12 @@ Object.freeze({
31744
31818
  addonId: null,
31745
31819
  access: "view"
31746
31820
  },
31821
+ "pipelineAnalytics.listEventMedia": {
31822
+ capName: "pipeline-analytics",
31823
+ capScope: "device",
31824
+ addonId: null,
31825
+ access: "view"
31826
+ },
31747
31827
  "pipelineAnalytics.listGroups": {
31748
31828
  capName: "pipeline-analytics",
31749
31829
  capScope: "device",
@@ -35367,6 +35447,11 @@ Object.freeze({
35367
35447
  form: "array",
35368
35448
  optional: false
35369
35449
  }],
35450
+ "pipelineAnalytics.listEventMedia": [{
35451
+ name: "deviceId",
35452
+ form: "single",
35453
+ optional: false
35454
+ }],
35370
35455
  "pipelineAnalytics.listGroups": [{
35371
35456
  name: "deviceIds",
35372
35457
  form: "array",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@camstack/addon-notifiers",
3
- "version": "1.2.50",
3
+ "version": "1.2.51",
4
4
  "description": "System notifiers addon for CamStack — a `notification-output` collection provider hosting per-kind notifier adapters (ntfy, pushover, gotify, telegram, discord, webhook, zentik).",
5
5
  "keywords": [
6
6
  "camstack",