@camstack/addon-provider-tuya 0.2.46 → 0.2.47

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
@@ -14021,6 +14021,114 @@ method(object({
14021
14021
  height: number()
14022
14022
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
14023
14023
  /**
14024
+ * `failure-contribution` — the capability an addon reports its OWN losses
14025
+ * through, per camera, with the denominator attached. It stores nothing.
14026
+ *
14027
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
14028
+ *
14029
+ * `load-contribution` answers *what did this camera COST*. This answers *what
14030
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
14031
+ * copied: the contributor reports what it already knows, hub-main adds only
14032
+ * `addonId`, nothing needs global knowledge, and there is no central list for
14033
+ * somebody to forget to edit.
14034
+ *
14035
+ * They are not merged, because their invariants are opposites:
14036
+ *
14037
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
14038
+ * claim a camera cost nothing, which is a measurement nobody made;
14039
+ * - a `failure-contribution` zero is the **most valuable value on the
14040
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14041
+ * and it is exactly what an absent entry cannot say.
14042
+ *
14043
+ * Putting a loss counter on a cost entry would also break the reconciliation
14044
+ * that gives `load-contribution` its point: contributions are subtracted from
14045
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14046
+ * has no process.
14047
+ *
14048
+ * ## Why not a log line, since the counters already exist
14049
+ *
14050
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
14051
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14052
+ * ends in a log line, and a log line is the thing the operator asked to stop
14053
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14054
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14055
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14056
+ * media blackout were both diagnosed. The counters stay; this is where they can
14057
+ * be READ.
14058
+ *
14059
+ * ## The rate is served with its denominator or not at all
14060
+ *
14061
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
14062
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14063
+ * than yesterday" and was **flat across twelve hours** once divided by the
14064
+ * successes on the same path. A surface that publishes only the numerator
14065
+ * reproduces that mistake on every read.
14066
+ *
14067
+ * ## Shape
14068
+ *
14069
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14070
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14071
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14072
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14073
+ * a forked runner's entries reach hub-main over transport that already exists.
14074
+ * No new UDS message, no second registry (D3). The operator reads the assembled
14075
+ * result through `system.getFailureContributions`.
14076
+ */
14077
+ var FailureReasonCountSchema = object({
14078
+ /**
14079
+ * Why the attempt did not land, in the contributor's own vocabulary —
14080
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14081
+ * strings that already appear in this repo's logs and, where one exists, the
14082
+ * same string the per-track `previewMissReason` records (D276): a second
14083
+ * vocabulary for the same loss would make the row and the counter
14084
+ * un-joinable.
14085
+ */
14086
+ reason: string(),
14087
+ count: number().int().nonnegative()
14088
+ });
14089
+ var FailureContributionSchema = object({
14090
+ /**
14091
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14092
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14093
+ * `unit` free: the families are owned by different addons and a shared enum
14094
+ * is a central list that rots invisibly.
14095
+ */
14096
+ family: string(),
14097
+ /**
14098
+ * The NUMERIC device id — the same value every log line carries as
14099
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
14100
+ * cannot name the camera must not emit the entry, because a fleet total
14101
+ * cannot answer the only question anybody asks of this surface.
14102
+ */
14103
+ deviceId: number().int().positive(),
14104
+ /**
14105
+ * A second dimension inside the family: the model / step id for an inference
14106
+ * timeout, so "which camera AND which model" is one read. Absent when the
14107
+ * family has a single variant.
14108
+ */
14109
+ variant: string().optional(),
14110
+ /**
14111
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14112
+ * differencing two reads must drop the interval when it changes, because the
14113
+ * counter restarted from zero in a respawned runner. Same discipline as
14114
+ * `LoadContribution.startedAtMs`.
14115
+ */
14116
+ sinceMs: number(),
14117
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14118
+ atMs: number(),
14119
+ /**
14120
+ * THE DENOMINATOR — every attempt on this path for this camera in the
14121
+ * window. A failure count published without it is the mistake this schema
14122
+ * exists to make impossible.
14123
+ */
14124
+ attempts: number().int().nonnegative(),
14125
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
14126
+ succeeded: number().int().nonnegative(),
14127
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
14128
+ reasons: array(FailureReasonCountSchema).readonly()
14129
+ });
14130
+ method(_void(), array(FailureContributionSchema).readonly());
14131
+ /**
14024
14132
  * filesystem-browse — per-node capability for browsing the node's local
14025
14133
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
14026
14134
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -14542,6 +14650,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
14542
14650
  kind: "mutation",
14543
14651
  auth: "admin"
14544
14652
  });
14653
+ var LoadContributionSchema = object({
14654
+ role: _enum([
14655
+ "decode",
14656
+ "transcode",
14657
+ "recording",
14658
+ "streaming",
14659
+ "detection"
14660
+ ]),
14661
+ /**
14662
+ * The NUMERIC device id — the same value every log line carries as
14663
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14664
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
14665
+ * contributor that cannot name its camera must not emit the entry at all,
14666
+ * because an unnamed per-camera entry is indistinguishable from a shared one
14667
+ * and would quietly turn one camera's cost into everybody's.
14668
+ */
14669
+ deviceId: number().int().positive().nullable(),
14670
+ attribution: _enum([
14671
+ "measured",
14672
+ "accounted",
14673
+ "unattributable"
14674
+ ]),
14675
+ /**
14676
+ * What ONE entry is, in the contributor's own words — `615/high`,
14677
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14678
+ * family and inventing a common one would lose the only information that
14679
+ * makes two entries for the same camera distinguishable.
14680
+ */
14681
+ unit: string(),
14682
+ /**
14683
+ * The OS process this cost lives in, when there is one. Present so a
14684
+ * consumer can (a) tell two generations of the same unit apart across a
14685
+ * restart, and (b) subtract claimed processes from the node's process
14686
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14687
+ * process of its own.
14688
+ */
14689
+ pid: number().int().positive().optional(),
14690
+ /**
14691
+ * When this generation started. The pid's incarnation marker: a consumer
14692
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14693
+ * window when this changes, because the counter restarted from zero in a new
14694
+ * process.
14695
+ */
14696
+ startedAtMs: number().optional(),
14697
+ /**
14698
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14699
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
14700
+ * contribution is asked for.
14701
+ *
14702
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
14703
+ * needs a sampler, and a new per-node sampler is the defect half of
14704
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14705
+ * by whoever already keeps a history; a rate cannot be un-averaged.
14706
+ *
14707
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14708
+ * an entry with no process.
14709
+ */
14710
+ cpuSeconds: number().optional(),
14711
+ /** Resident bytes of this unit's process, same source and same rules. */
14712
+ rssBytes: number().optional()
14713
+ });
14714
+ method(_void(), array(LoadContributionSchema).readonly());
14545
14715
  /**
14546
14716
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
14547
14717
  * through. It stores nothing.
@@ -14618,176 +14788,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
14618
14788
  tags: record(string(), string()).optional()
14619
14789
  }), array(LogEntrySchema).readonly());
14620
14790
  /**
14621
- * `failure-contribution` — the capability an addon reports its OWN losses
14622
- * through, per camera, with the denominator attached. It stores nothing.
14623
- *
14624
- * ## The twin of `load-contribution`, and why it is a twin and not a field
14625
- *
14626
- * `load-contribution` answers *what did this camera COST*. This answers *what
14627
- * did this camera LOSE*. The reporting discipline is identical and deliberately
14628
- * copied: the contributor reports what it already knows, hub-main adds only
14629
- * `addonId`, nothing needs global knowledge, and there is no central list for
14630
- * somebody to forget to edit.
14631
- *
14632
- * They are not merged, because their invariants are opposites:
14633
- *
14634
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
14635
- * claim a camera cost nothing, which is a measurement nobody made;
14636
- * - a `failure-contribution` zero is the **most valuable value on the
14637
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14638
- * and it is exactly what an absent entry cannot say.
14639
- *
14640
- * Putting a loss counter on a cost entry would also break the reconciliation
14641
- * that gives `load-contribution` its point: contributions are subtracted from
14642
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14643
- * has no process.
14644
- *
14645
- * ## Why not a log line, since the counters already exist
14646
- *
14647
- * Several of these paths already counted themselves — `CaptureScheduler`'s
14648
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14649
- * ends in a log line, and a log line is the thing the operator asked to stop
14650
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14651
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14652
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14653
- * media blackout were both diagnosed. The counters stay; this is where they can
14654
- * be READ.
14655
- *
14656
- * ## The rate is served with its denominator or not at all
14657
- *
14658
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
14659
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14660
- * than yesterday" and was **flat across twelve hours** once divided by the
14661
- * successes on the same path. A surface that publishes only the numerator
14662
- * reproduces that mistake on every read.
14663
- *
14664
- * ## Shape
14665
- *
14666
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14667
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14668
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14669
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14670
- * a forked runner's entries reach hub-main over transport that already exists.
14671
- * No new UDS message, no second registry (D3). The operator reads the assembled
14672
- * result through `system.getFailureContributions`.
14673
- */
14674
- var FailureReasonCountSchema = object({
14675
- /**
14676
- * Why the attempt did not land, in the contributor's own vocabulary —
14677
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14678
- * strings that already appear in this repo's logs and, where one exists, the
14679
- * same string the per-track `previewMissReason` records (D276): a second
14680
- * vocabulary for the same loss would make the row and the counter
14681
- * un-joinable.
14682
- */
14683
- reason: string(),
14684
- count: number().int().nonnegative()
14685
- });
14686
- var FailureContributionSchema = object({
14687
- /**
14688
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14689
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14690
- * `unit` free: the families are owned by different addons and a shared enum
14691
- * is a central list that rots invisibly.
14692
- */
14693
- family: string(),
14694
- /**
14695
- * The NUMERIC device id — the same value every log line carries as
14696
- * `tags.deviceId`. Never nullable and never absent: a contributor that
14697
- * cannot name the camera must not emit the entry, because a fleet total
14698
- * cannot answer the only question anybody asks of this surface.
14699
- */
14700
- deviceId: number().int().positive(),
14701
- /**
14702
- * A second dimension inside the family: the model / step id for an inference
14703
- * timeout, so "which camera AND which model" is one read. Absent when the
14704
- * family has a single variant.
14705
- */
14706
- variant: string().optional(),
14707
- /**
14708
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14709
- * differencing two reads must drop the interval when it changes, because the
14710
- * counter restarted from zero in a respawned runner. Same discipline as
14711
- * `LoadContribution.startedAtMs`.
14712
- */
14713
- sinceMs: number(),
14714
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14715
- atMs: number(),
14716
- /**
14717
- * THE DENOMINATOR — every attempt on this path for this camera in the
14718
- * window. A failure count published without it is the mistake this schema
14719
- * exists to make impossible.
14720
- */
14721
- attempts: number().int().nonnegative(),
14722
- /** Attempts that landed. `attempts - succeeded` is the loss. */
14723
- succeeded: number().int().nonnegative(),
14724
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
14725
- reasons: array(FailureReasonCountSchema).readonly()
14726
- });
14727
- method(_void(), array(FailureContributionSchema).readonly());
14728
- var LoadContributionSchema = object({
14729
- role: _enum([
14730
- "decode",
14731
- "transcode",
14732
- "recording",
14733
- "streaming",
14734
- "detection"
14735
- ]),
14736
- /**
14737
- * The NUMERIC device id — the same value every log line carries as
14738
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14739
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
14740
- * contributor that cannot name its camera must not emit the entry at all,
14741
- * because an unnamed per-camera entry is indistinguishable from a shared one
14742
- * and would quietly turn one camera's cost into everybody's.
14743
- */
14744
- deviceId: number().int().positive().nullable(),
14745
- attribution: _enum([
14746
- "measured",
14747
- "accounted",
14748
- "unattributable"
14749
- ]),
14750
- /**
14751
- * What ONE entry is, in the contributor's own words — `615/high`,
14752
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14753
- * family and inventing a common one would lose the only information that
14754
- * makes two entries for the same camera distinguishable.
14755
- */
14756
- unit: string(),
14757
- /**
14758
- * The OS process this cost lives in, when there is one. Present so a
14759
- * consumer can (a) tell two generations of the same unit apart across a
14760
- * restart, and (b) subtract claimed processes from the node's process
14761
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14762
- * process of its own.
14763
- */
14764
- pid: number().int().positive().optional(),
14765
- /**
14766
- * When this generation started. The pid's incarnation marker: a consumer
14767
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14768
- * window when this changes, because the counter restarted from zero in a new
14769
- * process.
14770
- */
14771
- startedAtMs: number().optional(),
14772
- /**
14773
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14774
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14775
- * contribution is asked for.
14776
- *
14777
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14778
- * needs a sampler, and a new per-node sampler is the defect half of
14779
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14780
- * by whoever already keeps a history; a rate cannot be un-averaged.
14781
- *
14782
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14783
- * an entry with no process.
14784
- */
14785
- cpuSeconds: number().optional(),
14786
- /** Resident bytes of this unit's process, same source and same rules. */
14787
- rssBytes: number().optional()
14788
- });
14789
- method(_void(), array(LoadContributionSchema).readonly());
14790
- /**
14791
14791
  * `login-method` — collection cap through which auth addons contribute
14792
14792
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14793
14793
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -19525,12 +19525,53 @@ var MediaFileKindEnum = _enum([
19525
19525
  "keyFrameSmall",
19526
19526
  "thumbnailSmall"
19527
19527
  ]);
19528
+ /**
19529
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
19530
+ * ARE — never the bytes themselves.
19531
+ *
19532
+ * ## Why `url` and not `base64`
19533
+ *
19534
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
19535
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
19536
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
19537
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
19538
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
19539
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
19540
+ *
19541
+ * `url` points at the `event-media` data plane
19542
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
19543
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
19544
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
19545
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
19546
+ * no less protected than they were inside a `view`-level cap response — see
19547
+ * `data-plane-access.ts` for the rule and the one gap it does not close
19548
+ * (per-device scoping).
19549
+ *
19550
+ * The URL is built from the row's **stored** key, which is not always its
19551
+ * published `kind`: a track's face/plate crop is stored as `crop` under
19552
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
19553
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
19554
+ *
19555
+ * ## `base64` is TRANSITIONAL and is going away
19556
+ *
19557
+ * It is still populated for one reason: the deployed viewer's track-detail
19558
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
19559
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
19560
+ * triangle — not as absence. Removing the field before that viewer ships is an
19561
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
19562
+ * delete this line and the `withBytes` pass-through in
19563
+ * `analytics-query-facade.ts`; nothing else reads it.
19564
+ */
19528
19565
  var MediaFileSchema = object({
19529
19566
  key: string(),
19530
19567
  kind: MediaFileKindEnum,
19531
- base64: string(),
19532
19568
  sizeBytes: number(),
19533
19569
  timestamp: number()
19570
+ }).extend({
19571
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
19572
+ url: string(),
19573
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
19574
+ base64: string()
19534
19575
  });
19535
19576
  /**
19536
19577
  * One media row WITHOUT its bytes.
@@ -19542,7 +19583,9 @@ var MediaFileSchema = object({
19542
19583
  * blocks the whole view.
19543
19584
  *
19544
19585
  * `sizeBytes` is carried because it is what lets a client decide between the
19545
- * stored blob and a `?variant=thumb` rendering without fetching either.
19586
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
19587
+ * `url` because a client that had to build the plane path itself is a second
19588
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
19546
19589
  */
19547
19590
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
19548
19591
  /**
@@ -20231,6 +20274,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
20231
20274
  }), array(MediaFileSchema).readonly()), method(object({
20232
20275
  trackId: string(),
20233
20276
  deviceId: number()
20277
+ }), array(MediaFileInfoSchema).readonly()), method(object({
20278
+ eventId: string(),
20279
+ deviceId: number()
20234
20280
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
20235
20281
  kind: "mutation",
20236
20282
  auth: "admin"
@@ -25229,10 +25275,24 @@ var FaceClusterSchema = object({
25229
25275
  size: number().int(),
25230
25276
  cohesion: number()
25231
25277
  });
25278
+ /**
25279
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
25280
+ * are — never the bytes.
25281
+ *
25282
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
25283
+ * track/event contract) is still populated because a deployed viewer requires
25284
+ * the field to parse a row at all; this method has no such reader. Its ONE
25285
+ * caller is the admin UI's detail modal, which was building
25286
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
25287
+ * dialog already rendering its key FRAME from the `event-media` plane.
25288
+ *
25289
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
25290
+ * media key directly, so this needed no new plane and no new access decision.
25291
+ */
25232
25292
  var MediaFileLiteSchema$1 = object({
25233
25293
  key: string(),
25234
25294
  kind: string(),
25235
- base64: string(),
25295
+ url: string(),
25236
25296
  sizeBytes: number(),
25237
25297
  timestamp: number()
25238
25298
  });
@@ -28254,10 +28314,24 @@ var PlateInfoSchema = object({
28254
28314
  */
28255
28315
  cropUrl: string().optional()
28256
28316
  });
28317
+ /**
28318
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
28319
+ * are — never the bytes.
28320
+ *
28321
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
28322
+ * track/event contract) is still populated because a deployed viewer requires
28323
+ * the field to parse a row at all; this method has no such reader. Its ONE
28324
+ * caller is the admin UI's detail modal, which was building
28325
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
28326
+ * dialog already rendering its key FRAME from the `event-media` plane.
28327
+ *
28328
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
28329
+ * media key directly, so this needed no new plane and no new access decision.
28330
+ */
28257
28331
  var MediaFileLiteSchema = object({
28258
28332
  key: string(),
28259
28333
  kind: string(),
28260
- base64: string(),
28334
+ url: string(),
28261
28335
  sizeBytes: number(),
28262
28336
  timestamp: number()
28263
28337
  });
@@ -36154,6 +36228,12 @@ Object.freeze({
36154
36228
  addonId: null,
36155
36229
  access: "view"
36156
36230
  },
36231
+ "pipelineAnalytics.listEventMedia": {
36232
+ capName: "pipeline-analytics",
36233
+ capScope: "device",
36234
+ addonId: null,
36235
+ access: "view"
36236
+ },
36157
36237
  "pipelineAnalytics.listGroups": {
36158
36238
  capName: "pipeline-analytics",
36159
36239
  capScope: "device",
@@ -39777,6 +39857,11 @@ Object.freeze({
39777
39857
  form: "array",
39778
39858
  optional: false
39779
39859
  }],
39860
+ "pipelineAnalytics.listEventMedia": [{
39861
+ name: "deviceId",
39862
+ form: "single",
39863
+ optional: false
39864
+ }],
39780
39865
  "pipelineAnalytics.listGroups": [{
39781
39866
  name: "deviceIds",
39782
39867
  form: "array",
package/dist/addon.mjs CHANGED
@@ -14020,6 +14020,114 @@ method(object({
14020
14020
  height: number()
14021
14021
  }), EmbeddingResultSchema, { auth: "admin" }), method(object({ text: string() }), EmbeddingResultSchema, { auth: "admin" }), method(_void(), EmbeddingInfoSchema, { auth: "admin" });
14022
14022
  /**
14023
+ * `failure-contribution` — the capability an addon reports its OWN losses
14024
+ * through, per camera, with the denominator attached. It stores nothing.
14025
+ *
14026
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
14027
+ *
14028
+ * `load-contribution` answers *what did this camera COST*. This answers *what
14029
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
14030
+ * copied: the contributor reports what it already knows, hub-main adds only
14031
+ * `addonId`, nothing needs global knowledge, and there is no central list for
14032
+ * somebody to forget to edit.
14033
+ *
14034
+ * They are not merged, because their invariants are opposites:
14035
+ *
14036
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
14037
+ * claim a camera cost nothing, which is a measurement nobody made;
14038
+ * - a `failure-contribution` zero is the **most valuable value on the
14039
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14040
+ * and it is exactly what an absent entry cannot say.
14041
+ *
14042
+ * Putting a loss counter on a cost entry would also break the reconciliation
14043
+ * that gives `load-contribution` its point: contributions are subtracted from
14044
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14045
+ * has no process.
14046
+ *
14047
+ * ## Why not a log line, since the counters already exist
14048
+ *
14049
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
14050
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14051
+ * ends in a log line, and a log line is the thing the operator asked to stop
14052
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14053
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14054
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14055
+ * media blackout were both diagnosed. The counters stay; this is where they can
14056
+ * be READ.
14057
+ *
14058
+ * ## The rate is served with its denominator or not at all
14059
+ *
14060
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
14061
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14062
+ * than yesterday" and was **flat across twelve hours** once divided by the
14063
+ * successes on the same path. A surface that publishes only the numerator
14064
+ * reproduces that mistake on every read.
14065
+ *
14066
+ * ## Shape
14067
+ *
14068
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14069
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14070
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14071
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14072
+ * a forked runner's entries reach hub-main over transport that already exists.
14073
+ * No new UDS message, no second registry (D3). The operator reads the assembled
14074
+ * result through `system.getFailureContributions`.
14075
+ */
14076
+ var FailureReasonCountSchema = object({
14077
+ /**
14078
+ * Why the attempt did not land, in the contributor's own vocabulary —
14079
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14080
+ * strings that already appear in this repo's logs and, where one exists, the
14081
+ * same string the per-track `previewMissReason` records (D276): a second
14082
+ * vocabulary for the same loss would make the row and the counter
14083
+ * un-joinable.
14084
+ */
14085
+ reason: string(),
14086
+ count: number().int().nonnegative()
14087
+ });
14088
+ var FailureContributionSchema = object({
14089
+ /**
14090
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14091
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14092
+ * `unit` free: the families are owned by different addons and a shared enum
14093
+ * is a central list that rots invisibly.
14094
+ */
14095
+ family: string(),
14096
+ /**
14097
+ * The NUMERIC device id — the same value every log line carries as
14098
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
14099
+ * cannot name the camera must not emit the entry, because a fleet total
14100
+ * cannot answer the only question anybody asks of this surface.
14101
+ */
14102
+ deviceId: number().int().positive(),
14103
+ /**
14104
+ * A second dimension inside the family: the model / step id for an inference
14105
+ * timeout, so "which camera AND which model" is one read. Absent when the
14106
+ * family has a single variant.
14107
+ */
14108
+ variant: string().optional(),
14109
+ /**
14110
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14111
+ * differencing two reads must drop the interval when it changes, because the
14112
+ * counter restarted from zero in a respawned runner. Same discipline as
14113
+ * `LoadContribution.startedAtMs`.
14114
+ */
14115
+ sinceMs: number(),
14116
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14117
+ atMs: number(),
14118
+ /**
14119
+ * THE DENOMINATOR — every attempt on this path for this camera in the
14120
+ * window. A failure count published without it is the mistake this schema
14121
+ * exists to make impossible.
14122
+ */
14123
+ attempts: number().int().nonnegative(),
14124
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
14125
+ succeeded: number().int().nonnegative(),
14126
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
14127
+ reasons: array(FailureReasonCountSchema).readonly()
14128
+ });
14129
+ method(_void(), array(FailureContributionSchema).readonly());
14130
+ /**
14023
14131
  * filesystem-browse — per-node capability for browsing the node's local
14024
14132
  * filesystem. Reads are unconfined (whole filesystem, from `/` down); WRITES
14025
14133
  * are sandboxed to operator-configured allowed roots (D115). Used by the
@@ -14541,6 +14649,68 @@ method(LlmGenerateBaseInputSchema, LlmGenerateResultSchema, { kind: "mutation" }
14541
14649
  kind: "mutation",
14542
14650
  auth: "admin"
14543
14651
  });
14652
+ var LoadContributionSchema = object({
14653
+ role: _enum([
14654
+ "decode",
14655
+ "transcode",
14656
+ "recording",
14657
+ "streaming",
14658
+ "detection"
14659
+ ]),
14660
+ /**
14661
+ * The NUMERIC device id — the same value every log line carries as
14662
+ * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14663
+ * camera (a shared pool), NOT that the contributor forgot to look it up: a
14664
+ * contributor that cannot name its camera must not emit the entry at all,
14665
+ * because an unnamed per-camera entry is indistinguishable from a shared one
14666
+ * and would quietly turn one camera's cost into everybody's.
14667
+ */
14668
+ deviceId: number().int().positive().nullable(),
14669
+ attribution: _enum([
14670
+ "measured",
14671
+ "accounted",
14672
+ "unattributable"
14673
+ ]),
14674
+ /**
14675
+ * What ONE entry is, in the contributor's own words — `615/high`,
14676
+ * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14677
+ * family and inventing a common one would lose the only information that
14678
+ * makes two entries for the same camera distinguishable.
14679
+ */
14680
+ unit: string(),
14681
+ /**
14682
+ * The OS process this cost lives in, when there is one. Present so a
14683
+ * consumer can (a) tell two generations of the same unit apart across a
14684
+ * restart, and (b) subtract claimed processes from the node's process
14685
+ * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14686
+ * process of its own.
14687
+ */
14688
+ pid: number().int().positive().optional(),
14689
+ /**
14690
+ * When this generation started. The pid's incarnation marker: a consumer
14691
+ * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14692
+ * window when this changes, because the counter restarted from zero in a new
14693
+ * process.
14694
+ */
14695
+ startedAtMs: number().optional(),
14696
+ /**
14697
+ * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14698
+ * system, read from the child's own `/proc/<pid>/stat` at the moment the
14699
+ * contribution is asked for.
14700
+ *
14701
+ * Cumulative and not a rate on purpose: a rate needs a window, a window
14702
+ * needs a sampler, and a new per-node sampler is the defect half of
14703
+ * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14704
+ * by whoever already keeps a history; a rate cannot be un-averaged.
14705
+ *
14706
+ * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14707
+ * an entry with no process.
14708
+ */
14709
+ cpuSeconds: number().optional(),
14710
+ /** Resident bytes of this unit's process, same source and same rules. */
14711
+ rssBytes: number().optional()
14712
+ });
14713
+ method(_void(), array(LoadContributionSchema).readonly());
14544
14714
  /**
14545
14715
  * `log-channels` — the capability an addon DECLARES its diagnostic channels
14546
14716
  * through. It stores nothing.
@@ -14617,176 +14787,6 @@ method(LogEntrySchema, _void(), { kind: "mutation" }), method(object({
14617
14787
  tags: record(string(), string()).optional()
14618
14788
  }), array(LogEntrySchema).readonly());
14619
14789
  /**
14620
- * `failure-contribution` — the capability an addon reports its OWN losses
14621
- * through, per camera, with the denominator attached. It stores nothing.
14622
- *
14623
- * ## The twin of `load-contribution`, and why it is a twin and not a field
14624
- *
14625
- * `load-contribution` answers *what did this camera COST*. This answers *what
14626
- * did this camera LOSE*. The reporting discipline is identical and deliberately
14627
- * copied: the contributor reports what it already knows, hub-main adds only
14628
- * `addonId`, nothing needs global knowledge, and there is no central list for
14629
- * somebody to forget to edit.
14630
- *
14631
- * They are not merged, because their invariants are opposites:
14632
- *
14633
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
14634
- * claim a camera cost nothing, which is a measurement nobody made;
14635
- * - a `failure-contribution` zero is the **most valuable value on the
14636
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
14637
- * and it is exactly what an absent entry cannot say.
14638
- *
14639
- * Putting a loss counter on a cost entry would also break the reconciliation
14640
- * that gives `load-contribution` its point: contributions are subtracted from
14641
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
14642
- * has no process.
14643
- *
14644
- * ## Why not a log line, since the counters already exist
14645
- *
14646
- * Several of these paths already counted themselves — `CaptureScheduler`'s
14647
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
14648
- * ends in a log line, and a log line is the thing the operator asked to stop
14649
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
14650
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
14651
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
14652
- * media blackout were both diagnosed. The counters stay; this is where they can
14653
- * be READ.
14654
- *
14655
- * ## The rate is served with its denominator or not at all
14656
- *
14657
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
14658
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
14659
- * than yesterday" and was **flat across twelve hours** once divided by the
14660
- * successes on the same path. A surface that publishes only the numerator
14661
- * reproduces that mistake on every read.
14662
- *
14663
- * ## Shape
14664
- *
14665
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
14666
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
14667
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
14668
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
14669
- * a forked runner's entries reach hub-main over transport that already exists.
14670
- * No new UDS message, no second registry (D3). The operator reads the assembled
14671
- * result through `system.getFailureContributions`.
14672
- */
14673
- var FailureReasonCountSchema = object({
14674
- /**
14675
- * Why the attempt did not land, in the contributor's own vocabulary —
14676
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
14677
- * strings that already appear in this repo's logs and, where one exists, the
14678
- * same string the per-track `previewMissReason` records (D276): a second
14679
- * vocabulary for the same loss would make the row and the counter
14680
- * un-joinable.
14681
- */
14682
- reason: string(),
14683
- count: number().int().nonnegative()
14684
- });
14685
- var FailureContributionSchema = object({
14686
- /**
14687
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
14688
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
14689
- * `unit` free: the families are owned by different addons and a shared enum
14690
- * is a central list that rots invisibly.
14691
- */
14692
- family: string(),
14693
- /**
14694
- * The NUMERIC device id — the same value every log line carries as
14695
- * `tags.deviceId`. Never nullable and never absent: a contributor that
14696
- * cannot name the camera must not emit the entry, because a fleet total
14697
- * cannot answer the only question anybody asks of this surface.
14698
- */
14699
- deviceId: number().int().positive(),
14700
- /**
14701
- * A second dimension inside the family: the model / step id for an inference
14702
- * timeout, so "which camera AND which model" is one read. Absent when the
14703
- * family has a single variant.
14704
- */
14705
- variant: string().optional(),
14706
- /**
14707
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
14708
- * differencing two reads must drop the interval when it changes, because the
14709
- * counter restarted from zero in a respawned runner. Same discipline as
14710
- * `LoadContribution.startedAtMs`.
14711
- */
14712
- sinceMs: number(),
14713
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
14714
- atMs: number(),
14715
- /**
14716
- * THE DENOMINATOR — every attempt on this path for this camera in the
14717
- * window. A failure count published without it is the mistake this schema
14718
- * exists to make impossible.
14719
- */
14720
- attempts: number().int().nonnegative(),
14721
- /** Attempts that landed. `attempts - succeeded` is the loss. */
14722
- succeeded: number().int().nonnegative(),
14723
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
14724
- reasons: array(FailureReasonCountSchema).readonly()
14725
- });
14726
- method(_void(), array(FailureContributionSchema).readonly());
14727
- var LoadContributionSchema = object({
14728
- role: _enum([
14729
- "decode",
14730
- "transcode",
14731
- "recording",
14732
- "streaming",
14733
- "detection"
14734
- ]),
14735
- /**
14736
- * The NUMERIC device id — the same value every log line carries as
14737
- * `tags.deviceId`. `null` means this cost genuinely belongs to no single
14738
- * camera (a shared pool), NOT that the contributor forgot to look it up: a
14739
- * contributor that cannot name its camera must not emit the entry at all,
14740
- * because an unnamed per-camera entry is indistinguishable from a shared one
14741
- * and would quietly turn one camera's cost into everybody's.
14742
- */
14743
- deviceId: number().int().positive().nullable(),
14744
- attribution: _enum([
14745
- "measured",
14746
- "accounted",
14747
- "unattributable"
14748
- ]),
14749
- /**
14750
- * What ONE entry is, in the contributor's own words — `615/high`,
14751
- * `617/native`, `cuda:0 shared pool`. Free text because the unit differs per
14752
- * family and inventing a common one would lose the only information that
14753
- * makes two entries for the same camera distinguishable.
14754
- */
14755
- unit: string(),
14756
- /**
14757
- * The OS process this cost lives in, when there is one. Present so a
14758
- * consumer can (a) tell two generations of the same unit apart across a
14759
- * restart, and (b) subtract claimed processes from the node's process
14760
- * snapshot to see what NOBODY claimed. Absent for an entry that owns no
14761
- * process of its own.
14762
- */
14763
- pid: number().int().positive().optional(),
14764
- /**
14765
- * When this generation started. The pid's incarnation marker: a consumer
14766
- * differencing {@link LoadContributionSchema.shape.cpuSeconds} must drop the
14767
- * window when this changes, because the counter restarted from zero in a new
14768
- * process.
14769
- */
14770
- startedAtMs: number().optional(),
14771
- /**
14772
- * CUMULATIVE CPU seconds this unit has consumed since it started — user +
14773
- * system, read from the child's own `/proc/<pid>/stat` at the moment the
14774
- * contribution is asked for.
14775
- *
14776
- * Cumulative and not a rate on purpose: a rate needs a window, a window
14777
- * needs a sampler, and a new per-node sampler is the defect half of
14778
- * `docs/architecture/load-ledger.md` documents. A counter can be differenced
14779
- * by whoever already keeps a history; a rate cannot be un-averaged.
14780
- *
14781
- * Absent — never zero — on a node with no `/proc`, on a read failure, and on
14782
- * an entry with no process.
14783
- */
14784
- cpuSeconds: number().optional(),
14785
- /** Resident bytes of this unit's process, same source and same rules. */
14786
- rssBytes: number().optional()
14787
- });
14788
- method(_void(), array(LoadContributionSchema).readonly());
14789
- /**
14790
14790
  * `login-method` — collection cap through which auth addons contribute
14791
14791
  * their pre-auth login surfaces to the login page. This is the SINGLE,
14792
14792
  * generic mechanism that supersedes the dead `auth.listProviders` reader:
@@ -19524,12 +19524,53 @@ var MediaFileKindEnum = _enum([
19524
19524
  "keyFrameSmall",
19525
19525
  "thumbnailSmall"
19526
19526
  ]);
19527
+ /**
19528
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
19529
+ * ARE — never the bytes themselves.
19530
+ *
19531
+ * ## Why `url` and not `base64`
19532
+ *
19533
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
19534
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
19535
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
19536
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
19537
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
19538
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
19539
+ *
19540
+ * `url` points at the `event-media` data plane
19541
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
19542
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
19543
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
19544
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
19545
+ * no less protected than they were inside a `view`-level cap response — see
19546
+ * `data-plane-access.ts` for the rule and the one gap it does not close
19547
+ * (per-device scoping).
19548
+ *
19549
+ * The URL is built from the row's **stored** key, which is not always its
19550
+ * published `kind`: a track's face/plate crop is stored as `crop` under
19551
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
19552
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
19553
+ *
19554
+ * ## `base64` is TRANSITIONAL and is going away
19555
+ *
19556
+ * It is still populated for one reason: the deployed viewer's track-detail
19557
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
19558
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
19559
+ * triangle — not as absence. Removing the field before that viewer ships is an
19560
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
19561
+ * delete this line and the `withBytes` pass-through in
19562
+ * `analytics-query-facade.ts`; nothing else reads it.
19563
+ */
19527
19564
  var MediaFileSchema = object({
19528
19565
  key: string(),
19529
19566
  kind: MediaFileKindEnum,
19530
- base64: string(),
19531
19567
  sizeBytes: number(),
19532
19568
  timestamp: number()
19569
+ }).extend({
19570
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
19571
+ url: string(),
19572
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
19573
+ base64: string()
19533
19574
  });
19534
19575
  /**
19535
19576
  * One media row WITHOUT its bytes.
@@ -19541,7 +19582,9 @@ var MediaFileSchema = object({
19541
19582
  * blocks the whole view.
19542
19583
  *
19543
19584
  * `sizeBytes` is carried because it is what lets a client decide between the
19544
- * stored blob and a `?variant=thumb` rendering without fetching either.
19585
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
19586
+ * `url` because a client that had to build the plane path itself is a second
19587
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
19545
19588
  */
19546
19589
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
19547
19590
  /**
@@ -20230,6 +20273,9 @@ DeviceType.Camera, method(object({ deviceId: number() }), array(TrackSchema).rea
20230
20273
  }), array(MediaFileSchema).readonly()), method(object({
20231
20274
  trackId: string(),
20232
20275
  deviceId: number()
20276
+ }), array(MediaFileInfoSchema).readonly()), method(object({
20277
+ eventId: string(),
20278
+ deviceId: number()
20233
20279
  }), array(MediaFileInfoSchema).readonly()), method(SearchObjectEventsInput, array(ScoredObjectEventSchema).readonly()), method(object({}), WipeObjectEmbeddingsResultSchema, {
20234
20280
  kind: "mutation",
20235
20281
  auth: "admin"
@@ -25228,10 +25274,24 @@ var FaceClusterSchema = object({
25228
25274
  size: number().int(),
25229
25275
  cohesion: number()
25230
25276
  });
25277
+ /**
25278
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
25279
+ * are — never the bytes.
25280
+ *
25281
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
25282
+ * track/event contract) is still populated because a deployed viewer requires
25283
+ * the field to parse a row at all; this method has no such reader. Its ONE
25284
+ * caller is the admin UI's detail modal, which was building
25285
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
25286
+ * dialog already rendering its key FRAME from the `event-media` plane.
25287
+ *
25288
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
25289
+ * media key directly, so this needed no new plane and no new access decision.
25290
+ */
25231
25291
  var MediaFileLiteSchema$1 = object({
25232
25292
  key: string(),
25233
25293
  kind: string(),
25234
- base64: string(),
25294
+ url: string(),
25235
25295
  sizeBytes: number(),
25236
25296
  timestamp: number()
25237
25297
  });
@@ -28253,10 +28313,24 @@ var PlateInfoSchema = object({
28253
28313
  */
28254
28314
  cropUrl: string().optional()
28255
28315
  });
28316
+ /**
28317
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
28318
+ * are — never the bytes.
28319
+ *
28320
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
28321
+ * track/event contract) is still populated because a deployed viewer requires
28322
+ * the field to parse a row at all; this method has no such reader. Its ONE
28323
+ * caller is the admin UI's detail modal, which was building
28324
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
28325
+ * dialog already rendering its key FRAME from the `event-media` plane.
28326
+ *
28327
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
28328
+ * media key directly, so this needed no new plane and no new access decision.
28329
+ */
28256
28330
  var MediaFileLiteSchema = object({
28257
28331
  key: string(),
28258
28332
  kind: string(),
28259
- base64: string(),
28333
+ url: string(),
28260
28334
  sizeBytes: number(),
28261
28335
  timestamp: number()
28262
28336
  });
@@ -36153,6 +36227,12 @@ Object.freeze({
36153
36227
  addonId: null,
36154
36228
  access: "view"
36155
36229
  },
36230
+ "pipelineAnalytics.listEventMedia": {
36231
+ capName: "pipeline-analytics",
36232
+ capScope: "device",
36233
+ addonId: null,
36234
+ access: "view"
36235
+ },
36156
36236
  "pipelineAnalytics.listGroups": {
36157
36237
  capName: "pipeline-analytics",
36158
36238
  capScope: "device",
@@ -39776,6 +39856,11 @@ Object.freeze({
39776
39856
  form: "array",
39777
39857
  optional: false
39778
39858
  }],
39859
+ "pipelineAnalytics.listEventMedia": [{
39860
+ name: "deviceId",
39861
+ form: "single",
39862
+ optional: false
39863
+ }],
39779
39864
  "pipelineAnalytics.listGroups": [{
39780
39865
  name: "deviceIds",
39781
39866
  form: "array",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@camstack/addon-provider-tuya",
3
- "version": "0.2.46",
3
+ "version": "0.2.47",
4
4
  "description": "Tuya / Smart Life device-provider addon for CamStack — account-onboarded (Tuya IoT cloud fetch of device localKeys) + LOCAL DP control via the @apocaliss92/nodetuya encrypted-LAN client, exposing switch / water-heater-family kettle entities",
5
5
  "keywords": [
6
6
  "camstack",