@camstack/types 1.2.126 → 1.2.128

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.
package/dist/index.js CHANGED
@@ -1,6 +1,6 @@
1
1
  Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
2
2
  const require_event_category = require("./event-category-BaEgqJNv.js");
3
- const require_sleep = require("./sleep-CWWLTM6W.js");
3
+ const require_sleep = require("./sleep-C3AniWy-.js");
4
4
  const require_canonical_hash = require("./canonical-hash-DNV8S5ET.js");
5
5
  const require_enums = require("./enums.js");
6
6
  const require_err_msg = require("./err-msg-COpsHMw2.js");
@@ -2252,6 +2252,21 @@ var RelocateJobSchema = zod.z.object({
2252
2252
  bytesMoved: zod.z.number().int(),
2253
2253
  /** Total files discovered up front; null while (or when) unknown. */
2254
2254
  filesTotal: zod.z.number().int().nullable(),
2255
+ /**
2256
+ * Rows this run CORRECTED while moving them — a durable mutation the move
2257
+ * made that nobody asked for, so it is reported where the operator reads the
2258
+ * job rather than only in a log line.
2259
+ *
2260
+ * A footage segment records its byte count in its own NAME, and the durable
2261
+ * hour row derives its aggregates from those names. A file that does not
2262
+ * match its name therefore makes the ledger's sums — and with them quota and
2263
+ * pressure eviction — wrong by the difference, and only a rename can fix it.
2264
+ * On 2026-08-30 one such row also stalled a 110 749-file drain permanently.
2265
+ *
2266
+ * Absent on lanes where the question has no meaning: a media blob's size is
2267
+ * in its row, not in its name, so `MediaRelocateEngine` never reconciles one.
2268
+ */
2269
+ rowsReconciled: zod.z.number().int().nonnegative().optional(),
2255
2270
  startedAt: zod.z.number(),
2256
2271
  finishedAt: zod.z.number().nullable(),
2257
2272
  error: zod.z.string().nullable()
@@ -2320,14 +2335,42 @@ var RelocateMediaInputSchema = zod.z.object({
2320
2335
  /** Omitted = `move`, the pre-existing behaviour. */
2321
2336
  mode: MediaRelocateModeSchema.optional()
2322
2337
  });
2323
- /** How many rows still carry NO `locationId` — the population a repoint would
2324
- * silently re-aim at a disk that does not hold their bytes. Zero is the only
2325
- * value that permits a non-blocking `eventMedia` cutover. */
2326
- var UnstampedEventMediaCountSchema = zod.z.object({
2327
- media: zod.z.number().int().nonnegative(),
2328
- retrainFrames: zod.z.number().int().nonnegative(),
2329
- total: zod.z.number().int().nonnegative()
2338
+ /**
2339
+ * The unstamped population of ONE collection split, because the gate and the
2340
+ * operator ask two different questions and only one of them has to be cheap.
2341
+ *
2342
+ * `present` is the GATE: "is there at least one row that would be orphaned by a
2343
+ * repoint". It is a single indexed seek to the first matching row, so it stays
2344
+ * answerable on a saturated disk and answers in O(log n) precisely in the state
2345
+ * that matters — after a seal, when the population is empty.
2346
+ *
2347
+ * `rows` is the NUMBER, for the refusal message and the operator's sense of
2348
+ * scale. It is a second, indexed `COUNT(*)`, and `null` means **not
2349
+ * measurable** — never zero. `{ present: true, rows: null }` is a legitimate
2350
+ * and useful answer: "there are some, and this read could not say how many"
2351
+ * still refuses the cutover, which is the whole job.
2352
+ */
2353
+ var UnstampedRowsSchema = zod.z.object({
2354
+ present: zod.z.boolean(),
2355
+ rows: zod.z.number().int().nonnegative().nullable()
2330
2356
  });
2357
+ /**
2358
+ * How many rows still carry NO `locationId` — the population a repoint would
2359
+ * silently re-aim at a disk that does not hold their bytes.
2360
+ *
2361
+ * **`null` = the count could not be taken**, and it is NOT permission to cut
2362
+ * over. The gate opens on a measured absence and on nothing else; an unread
2363
+ * collection and an empty one are different facts, and this repo has already
2364
+ * paid for conflating them (`RelocateResidueSchema`, D295).
2365
+ */
2366
+ var UnstampedEventMediaCountSchema = zod.z.object({
2367
+ media: UnstampedRowsSchema,
2368
+ retrainFrames: UnstampedRowsSchema,
2369
+ /** True when EITHER collection holds one. The refusal reads this. */
2370
+ anyPresent: zod.z.boolean(),
2371
+ /** Sum across both, or `null` when either lane could not be counted. */
2372
+ total: zod.z.number().int().nonnegative().nullable()
2373
+ }).nullable();
2331
2374
  var StorageMigrationMediaMoveInputSchema = RelocateMediaInputSchema.extend({ leaseId: zod.z.string().min(1) });
2332
2375
  /** The independently selectable logical storage classes — every class
2333
2376
  * `storage.listLocationDeclarations` reports, so an operator never meets a
@@ -2438,6 +2481,10 @@ var StorageMigrationMoveProgressSchema = zod.z.object({
2438
2481
  /** The archive census — the **M** of "N of M" (D295). `null` = unknowable. */
2439
2482
  filesTotal: zod.z.number().int().nonnegative().nullable(),
2440
2483
  bytesMoved: zod.z.number().int().nonnegative(),
2484
+ /** Rows the mover corrected while moving them — see `RelocateJob`. Absent on
2485
+ * a lane that cannot reconcile. A migration that silently rewrote durable
2486
+ * rows would be the same failure as one that silently skipped them. */
2487
+ rowsReconciled: zod.z.number().int().nonnegative().optional(),
2441
2488
  /** The MOVER's start, not the migration's: a drain restarted after an addon
2442
2489
  * crash gets a new mover, and a rate computed from the migration's start
2443
2490
  * would silently average in the time nothing was running. */
@@ -10516,6 +10563,15 @@ var deviceManagerCapability = {
10516
10563
  * calls are sync. Bindings change rarely (only on wrapper toggle or
10517
10564
  * device add/remove) — clients invalidate via the
10518
10565
  * `capability.binding-changed` event.
10566
+ *
10567
+ * "A single round-trip" describes the CLIENT's side and used not to
10568
+ * describe the server's: until 2026-08-30 the resolver read the persisted
10569
+ * wrapper activations once per device, so answering this cost one
10570
+ * settings-door RPC per device — 1 020 on the live 1 019-device hub, and
10571
+ * it did not return in 240 s against `SystemMirror.init`'s 15 s budget.
10572
+ * The server side is now two reads for the whole fleet. Anything PERIODIC
10573
+ * still belongs on `getBindings` / `getBindingsBatch` (D12); this remains
10574
+ * a warm seed.
10519
10575
  */
10520
10576
  getAllBindings: require_sleep.method(zod.z.object({}), zod.z.array(DeviceBindingsForDeviceSchema)),
10521
10577
  /**
@@ -10948,6 +11004,135 @@ var embeddingEncoderCapability = {
10948
11004
  }
10949
11005
  };
10950
11006
  //#endregion
11007
+ //#region src/capabilities/failure-contribution.cap.ts
11008
+ /**
11009
+ * `failure-contribution` — the capability an addon reports its OWN losses
11010
+ * through, per camera, with the denominator attached. It stores nothing.
11011
+ *
11012
+ * ## The twin of `load-contribution`, and why it is a twin and not a field
11013
+ *
11014
+ * `load-contribution` answers *what did this camera COST*. This answers *what
11015
+ * did this camera LOSE*. The reporting discipline is identical and deliberately
11016
+ * copied: the contributor reports what it already knows, hub-main adds only
11017
+ * `addonId`, nothing needs global knowledge, and there is no central list for
11018
+ * somebody to forget to edit.
11019
+ *
11020
+ * They are not merged, because their invariants are opposites:
11021
+ *
11022
+ * - a `load-contribution` measurement is **absent, never zero** — a zero would
11023
+ * claim a camera cost nothing, which is a measurement nobody made;
11024
+ * - a `failure-contribution` zero is the **most valuable value on the
11025
+ * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
11026
+ * and it is exactly what an absent entry cannot say.
11027
+ *
11028
+ * Putting a loss counter on a cost entry would also break the reconciliation
11029
+ * that gives `load-contribution` its point: contributions are subtracted from
11030
+ * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
11031
+ * has no process.
11032
+ *
11033
+ * ## Why not a log line, since the counters already exist
11034
+ *
11035
+ * Several of these paths already counted themselves — `CaptureScheduler`'s
11036
+ * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
11037
+ * ends in a log line, and a log line is the thing the operator asked to stop
11038
+ * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
11039
+ * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
11040
+ * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
11041
+ * media blackout were both diagnosed. The counters stay; this is where they can
11042
+ * be READ.
11043
+ *
11044
+ * ## The rate is served with its denominator or not at all
11045
+ *
11046
+ * Every entry carries `attempts` and `succeeded`. A miss count alone is
11047
+ * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
11048
+ * than yesterday" and was **flat across twelve hours** once divided by the
11049
+ * successes on the same path. A surface that publishes only the numerator
11050
+ * reproduces that mistake on every read.
11051
+ *
11052
+ * ## Shape
11053
+ *
11054
+ * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
11055
+ * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
11056
+ * generated hooks, while `addons.listCapabilityProviders` still enumerates it
11057
+ * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
11058
+ * a forked runner's entries reach hub-main over transport that already exists.
11059
+ * No new UDS message, no second registry (D3). The operator reads the assembled
11060
+ * result through `system.getFailureContributions`.
11061
+ */
11062
+ var FailureReasonCountSchema = zod.z.object({
11063
+ /**
11064
+ * Why the attempt did not land, in the contributor's own vocabulary —
11065
+ * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
11066
+ * strings that already appear in this repo's logs and, where one exists, the
11067
+ * same string the per-track `previewMissReason` records (D276): a second
11068
+ * vocabulary for the same loss would make the row and the counter
11069
+ * un-joinable.
11070
+ */
11071
+ reason: zod.z.string(),
11072
+ count: zod.z.number().int().nonnegative()
11073
+ });
11074
+ var FailureContributionSchema = zod.z.object({
11075
+ /**
11076
+ * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
11077
+ * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
11078
+ * `unit` free: the families are owned by different addons and a shared enum
11079
+ * is a central list that rots invisibly.
11080
+ */
11081
+ family: zod.z.string(),
11082
+ /**
11083
+ * The NUMERIC device id — the same value every log line carries as
11084
+ * `tags.deviceId`. Never nullable and never absent: a contributor that
11085
+ * cannot name the camera must not emit the entry, because a fleet total
11086
+ * cannot answer the only question anybody asks of this surface.
11087
+ */
11088
+ deviceId: zod.z.number().int().positive(),
11089
+ /**
11090
+ * A second dimension inside the family: the model / step id for an inference
11091
+ * timeout, so "which camera AND which model" is one read. Absent when the
11092
+ * family has a single variant.
11093
+ */
11094
+ variant: zod.z.string().optional(),
11095
+ /**
11096
+ * Epoch ms this counter started — the INCARNATION MARKER. A consumer
11097
+ * differencing two reads must drop the interval when it changes, because the
11098
+ * counter restarted from zero in a respawned runner. Same discipline as
11099
+ * `LoadContribution.startedAtMs`.
11100
+ */
11101
+ sinceMs: zod.z.number(),
11102
+ /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
11103
+ atMs: zod.z.number(),
11104
+ /**
11105
+ * THE DENOMINATOR — every attempt on this path for this camera in the
11106
+ * window. A failure count published without it is the mistake this schema
11107
+ * exists to make impossible.
11108
+ */
11109
+ attempts: zod.z.number().int().nonnegative(),
11110
+ /** Attempts that landed. `attempts - succeeded` is the loss. */
11111
+ succeeded: zod.z.number().int().nonnegative(),
11112
+ /** The loss, partitioned. Sums to `attempts - succeeded`. */
11113
+ reasons: zod.z.array(FailureReasonCountSchema).readonly()
11114
+ });
11115
+ var failureContributionCapability = {
11116
+ name: "failure-contribution",
11117
+ scope: "system",
11118
+ mode: "collection",
11119
+ internal: true,
11120
+ methods: {
11121
+ /**
11122
+ * This addon's per-camera failure counters, read live from bounded in-RAM
11123
+ * state it already keeps. Inert: no persistence, no sampling, no timer.
11124
+ *
11125
+ * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
11126
+ * consumer that wants a rate differences two reads. A draining read would
11127
+ * make two operators with the page open each destroy half of the other's
11128
+ * numbers, and `load-contribution` already settled the same question the
11129
+ * same way for `cpuSeconds`.
11130
+ */
11131
+ list: require_sleep.method(zod.z.void(), zod.z.array(FailureContributionSchema).readonly()) },
11132
+ /** In-process only — enumerated through `addons.listCapabilityProviders`. */
11133
+ mount: { kind: "skip" }
11134
+ };
11135
+ //#endregion
10951
11136
  //#region src/capabilities/filesystem-browse.cap.ts
10952
11137
  /**
10953
11138
  * filesystem-browse — per-node capability for browsing the node's local
@@ -11588,246 +11773,6 @@ var llmCapability = {
11588
11773
  }
11589
11774
  };
11590
11775
  //#endregion
11591
- //#region src/capabilities/log-channels.cap.ts
11592
- /**
11593
- * `log-channels` — the capability an addon DECLARES its diagnostic channels
11594
- * through. It stores nothing.
11595
- *
11596
- * ## Why a capability at all, and why this shape
11597
- *
11598
- * Which channels exist is knowledge only the addon has: `stream-broker` knows
11599
- * webrtc/ICE/RTP, `provider-reolink` knows baichuan/handshake. A central list
11600
- * maintained by hand rots at the first addition and rots INVISIBLY — nothing
11601
- * fails, an operator just never sees the channel somebody added. So the list
11602
- * is assembled from declarations at runtime.
11603
- *
11604
- * The shape is copied from `log-destination.cap.ts`, which already does
11605
- * exactly this job: `mode: 'collection'`, `internal: true`,
11606
- * `mount: { kind: 'skip' }` — no tRPC route, no generated hooks — while
11607
- * `addons.listCapabilityProviders` still enumerates it, and the hub's
11608
- * `CapabilityRegistry` still holds an RPC proxy per provider so a forked
11609
- * runner's declarations reach hub-main over the transport that already exists.
11610
- * No new UDS message, no second registry.
11611
- *
11612
- * ## What it deliberately does NOT own
11613
- *
11614
- * The VALUES — which channel is armed, for which cameras, until when — live in
11615
- * ONE place: the logging settings document on the `system` cap
11616
- * (`getLoggingSettings` / `setLoggingSettings`). Two authorities over the same
11617
- * value is the defect the plan behind this work exists to remove, and
11618
- * `setRequestCensus` was retired (D245) rather than allowed to be a second
11619
- * one. {@link logChannelsCapability} therefore has no getter for a level, no
11620
- * setter for a window and no persistence of any kind.
11621
- *
11622
- * ## Why `apply` is here even so
11623
- *
11624
- * The gate lives in the addon's PROCESS; the document lives in hub-main. Some
11625
- * seam has to carry the value from the authority to the mirror, and a channel
11626
- * that cannot be reached is precisely the dead knob this whole slice exists to
11627
- * make impossible (D62 — `audioThresholdDbfs`, the HA entities with no source).
11628
- * `apply` is that seam and nothing more: it writes an in-memory mirror, it
11629
- * persists nothing, it is never the source of a value, and it is called only
11630
- * with a set the hub actually read (D49 — a read that fails does not call it
11631
- * at all, so no channel is silently disarmed by a bad read).
11632
- */
11633
- /** What `apply` reports back — enough to log, not enough to be a second state. */
11634
- var LogChannelApplyResultSchema = zod.z.object({
11635
- /** How many declared channels are armed in this process after the call. */
11636
- armed: zod.z.number().int().min(0),
11637
- /**
11638
- * Names the document armed that this process does not declare. Reported
11639
- * rather than swallowed: a name here is either a typo or an addon that has
11640
- * not booted, and both deserve a line instead of silence.
11641
- */
11642
- unknown: zod.z.array(zod.z.string()).readonly()
11643
- });
11644
- var logChannelsCapability = {
11645
- name: "log-channels",
11646
- scope: "system",
11647
- mode: "collection",
11648
- internal: true,
11649
- methods: {
11650
- /** The channels this addon declares. Inert: no value, no state. */
11651
- list: require_sleep.method(zod.z.void(), zod.z.array(LogChannelDescriptorSchema).readonly()),
11652
- /**
11653
- * Refresh this process's mirror from the document's FULL set of armed
11654
- * windows.
11655
- *
11656
- * Full and not incremental on purpose: the document is the authority, so a
11657
- * channel it does not name is disarmed here. An incremental apply would
11658
- * let a disarm get lost in transit and leave a channel running that
11659
- * nobody can see is running.
11660
- */
11661
- apply: require_sleep.method(zod.z.object({ windows: zod.z.array(LogChannelWindowSchema).readonly() }), LogChannelApplyResultSchema, { kind: "mutation" })
11662
- },
11663
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
11664
- mount: { kind: "skip" }
11665
- };
11666
- //#endregion
11667
- //#region src/capabilities/log-destination.cap.ts
11668
- var LogLevelSchema = zod.z.enum([
11669
- "debug",
11670
- "info",
11671
- "warn",
11672
- "error"
11673
- ]);
11674
- var LogEntrySchema = zod.z.object({
11675
- timestamp: zod.z.date(),
11676
- level: LogLevelSchema,
11677
- scope: zod.z.array(zod.z.string()),
11678
- message: zod.z.string(),
11679
- meta: zod.z.record(zod.z.string(), zod.z.unknown()).optional(),
11680
- tags: zod.z.record(zod.z.string(), zod.z.string()).optional()
11681
- });
11682
- var logDestinationCapability = {
11683
- name: "log-destination",
11684
- scope: "system",
11685
- mode: "collection",
11686
- internal: true,
11687
- methods: {
11688
- write: require_sleep.method(LogEntrySchema, zod.z.void(), { kind: "mutation" }),
11689
- query: require_sleep.method(zod.z.object({
11690
- scope: zod.z.array(zod.z.string()).optional(),
11691
- level: LogLevelSchema.optional(),
11692
- since: zod.z.date().optional(),
11693
- until: zod.z.date().optional(),
11694
- limit: zod.z.number().optional(),
11695
- tags: zod.z.record(zod.z.string(), zod.z.string()).optional()
11696
- }), zod.z.array(LogEntrySchema).readonly())
11697
- },
11698
- /** BIG PLAN 2: declarative mount hint — read by `@camstack/system` `buildCapRouters`. */
11699
- mount: { kind: "skip" }
11700
- };
11701
- //#endregion
11702
- //#region src/capabilities/failure-contribution.cap.ts
11703
- /**
11704
- * `failure-contribution` — the capability an addon reports its OWN losses
11705
- * through, per camera, with the denominator attached. It stores nothing.
11706
- *
11707
- * ## The twin of `load-contribution`, and why it is a twin and not a field
11708
- *
11709
- * `load-contribution` answers *what did this camera COST*. This answers *what
11710
- * did this camera LOSE*. The reporting discipline is identical and deliberately
11711
- * copied: the contributor reports what it already knows, hub-main adds only
11712
- * `addonId`, nothing needs global knowledge, and there is no central list for
11713
- * somebody to forget to edit.
11714
- *
11715
- * They are not merged, because their invariants are opposites:
11716
- *
11717
- * - a `load-contribution` measurement is **absent, never zero** — a zero would
11718
- * claim a camera cost nothing, which is a measurement nobody made;
11719
- * - a `failure-contribution` zero is the **most valuable value on the
11720
- * surface** — `attempts: 400, succeeded: 400` is the proof a fix landed,
11721
- * and it is exactly what an absent entry cannot say.
11722
- *
11723
- * Putting a loss counter on a cost entry would also break the reconciliation
11724
- * that gives `load-contribution` its point: contributions are subtracted from
11725
- * `metrics.node-processes-snapshot` to find processes nobody claims. A failure
11726
- * has no process.
11727
- *
11728
- * ## Why not a log line, since the counters already exist
11729
- *
11730
- * Several of these paths already counted themselves — `CaptureScheduler`'s
11731
- * per-device window, `KeyFrameCaptureLog`, `bumpCropMetric`. Every one of them
11732
- * ends in a log line, and a log line is the thing the operator asked to stop
11733
- * needing: *"possiamo armare questi errori intanto? Così al prossimo giro
11734
- * ricontrolliamo tutti questi punti"*. Reading them meant grepping Loki and
11735
- * hand-correlating timestamps, which is how a 22% thumbnail gap and a 3-hour
11736
- * media blackout were both diagnosed. The counters stay; this is where they can
11737
- * be READ.
11738
- *
11739
- * ## The rate is served with its denominator or not at all
11740
- *
11741
- * Every entry carries `attempts` and `succeeded`. A miss count alone is
11742
- * unreadable: on 2026-08-28 the enrichment-crop miss count read as "35x worse
11743
- * than yesterday" and was **flat across twelve hours** once divided by the
11744
- * successes on the same path. A surface that publishes only the numerator
11745
- * reproduces that mistake on every read.
11746
- *
11747
- * ## Shape
11748
- *
11749
- * Copied from `load-contribution.cap.ts` (`mode: 'collection'`,
11750
- * `internal: true`, `mount: { kind: 'skip' }`): no tRPC route of its own and no
11751
- * generated hooks, while `addons.listCapabilityProviders` still enumerates it
11752
- * and the hub's `CapabilityRegistry` still holds an RPC proxy per provider — so
11753
- * a forked runner's entries reach hub-main over transport that already exists.
11754
- * No new UDS message, no second registry (D3). The operator reads the assembled
11755
- * result through `system.getFailureContributions`.
11756
- */
11757
- var FailureReasonCountSchema = zod.z.object({
11758
- /**
11759
- * Why the attempt did not land, in the contributor's own vocabulary —
11760
- * `worker-lease-gone`, `queue-overflow`, `timeout`, `empty-read`. The same
11761
- * strings that already appear in this repo's logs and, where one exists, the
11762
- * same string the per-track `previewMissReason` records (D276): a second
11763
- * vocabulary for the same loss would make the row and the counter
11764
- * un-joinable.
11765
- */
11766
- reason: zod.z.string(),
11767
- count: zod.z.number().int().nonnegative()
11768
- });
11769
- var FailureContributionSchema = zod.z.object({
11770
- /**
11771
- * The failing path — `enrichment-crop`, `inference`, `plate-ocr`,
11772
- * `person-over-vehicle`. Free text, for the reason `load-contribution` keeps
11773
- * `unit` free: the families are owned by different addons and a shared enum
11774
- * is a central list that rots invisibly.
11775
- */
11776
- family: zod.z.string(),
11777
- /**
11778
- * The NUMERIC device id — the same value every log line carries as
11779
- * `tags.deviceId`. Never nullable and never absent: a contributor that
11780
- * cannot name the camera must not emit the entry, because a fleet total
11781
- * cannot answer the only question anybody asks of this surface.
11782
- */
11783
- deviceId: zod.z.number().int().positive(),
11784
- /**
11785
- * A second dimension inside the family: the model / step id for an inference
11786
- * timeout, so "which camera AND which model" is one read. Absent when the
11787
- * family has a single variant.
11788
- */
11789
- variant: zod.z.string().optional(),
11790
- /**
11791
- * Epoch ms this counter started — the INCARNATION MARKER. A consumer
11792
- * differencing two reads must drop the interval when it changes, because the
11793
- * counter restarted from zero in a respawned runner. Same discipline as
11794
- * `LoadContribution.startedAtMs`.
11795
- */
11796
- sinceMs: zod.z.number(),
11797
- /** Epoch ms it was read. `atMs - sinceMs` is the interval this covers. */
11798
- atMs: zod.z.number(),
11799
- /**
11800
- * THE DENOMINATOR — every attempt on this path for this camera in the
11801
- * window. A failure count published without it is the mistake this schema
11802
- * exists to make impossible.
11803
- */
11804
- attempts: zod.z.number().int().nonnegative(),
11805
- /** Attempts that landed. `attempts - succeeded` is the loss. */
11806
- succeeded: zod.z.number().int().nonnegative(),
11807
- /** The loss, partitioned. Sums to `attempts - succeeded`. */
11808
- reasons: zod.z.array(FailureReasonCountSchema).readonly()
11809
- });
11810
- var failureContributionCapability = {
11811
- name: "failure-contribution",
11812
- scope: "system",
11813
- mode: "collection",
11814
- internal: true,
11815
- methods: {
11816
- /**
11817
- * This addon's per-camera failure counters, read live from bounded in-RAM
11818
- * state it already keeps. Inert: no persistence, no sampling, no timer.
11819
- *
11820
- * READING NEVER RESETS. The counters are CUMULATIVE since `sinceMs`, and a
11821
- * consumer that wants a rate differences two reads. A draining read would
11822
- * make two operators with the page open each destroy half of the other's
11823
- * numbers, and `load-contribution` already settled the same question the
11824
- * same way for `cpuSeconds`.
11825
- */
11826
- list: require_sleep.method(zod.z.void(), zod.z.array(FailureContributionSchema).readonly()) },
11827
- /** In-process only — enumerated through `addons.listCapabilityProviders`. */
11828
- mount: { kind: "skip" }
11829
- };
11830
- //#endregion
11831
11776
  //#region src/capabilities/load-contribution.cap.ts
11832
11777
  /**
11833
11778
  * `load-contribution` — the capability an addon reports its OWN cost through,
@@ -11988,6 +11933,117 @@ list: require_sleep.method(zod.z.void(), zod.z.array(LoadContributionSchema).rea
11988
11933
  mount: { kind: "skip" }
11989
11934
  };
11990
11935
  //#endregion
11936
+ //#region src/capabilities/log-channels.cap.ts
11937
+ /**
11938
+ * `log-channels` — the capability an addon DECLARES its diagnostic channels
11939
+ * through. It stores nothing.
11940
+ *
11941
+ * ## Why a capability at all, and why this shape
11942
+ *
11943
+ * Which channels exist is knowledge only the addon has: `stream-broker` knows
11944
+ * webrtc/ICE/RTP, `provider-reolink` knows baichuan/handshake. A central list
11945
+ * maintained by hand rots at the first addition and rots INVISIBLY — nothing
11946
+ * fails, an operator just never sees the channel somebody added. So the list
11947
+ * is assembled from declarations at runtime.
11948
+ *
11949
+ * The shape is copied from `log-destination.cap.ts`, which already does
11950
+ * exactly this job: `mode: 'collection'`, `internal: true`,
11951
+ * `mount: { kind: 'skip' }` — no tRPC route, no generated hooks — while
11952
+ * `addons.listCapabilityProviders` still enumerates it, and the hub's
11953
+ * `CapabilityRegistry` still holds an RPC proxy per provider so a forked
11954
+ * runner's declarations reach hub-main over the transport that already exists.
11955
+ * No new UDS message, no second registry.
11956
+ *
11957
+ * ## What it deliberately does NOT own
11958
+ *
11959
+ * The VALUES — which channel is armed, for which cameras, until when — live in
11960
+ * ONE place: the logging settings document on the `system` cap
11961
+ * (`getLoggingSettings` / `setLoggingSettings`). Two authorities over the same
11962
+ * value is the defect the plan behind this work exists to remove, and
11963
+ * `setRequestCensus` was retired (D245) rather than allowed to be a second
11964
+ * one. {@link logChannelsCapability} therefore has no getter for a level, no
11965
+ * setter for a window and no persistence of any kind.
11966
+ *
11967
+ * ## Why `apply` is here even so
11968
+ *
11969
+ * The gate lives in the addon's PROCESS; the document lives in hub-main. Some
11970
+ * seam has to carry the value from the authority to the mirror, and a channel
11971
+ * that cannot be reached is precisely the dead knob this whole slice exists to
11972
+ * make impossible (D62 — `audioThresholdDbfs`, the HA entities with no source).
11973
+ * `apply` is that seam and nothing more: it writes an in-memory mirror, it
11974
+ * persists nothing, it is never the source of a value, and it is called only
11975
+ * with a set the hub actually read (D49 — a read that fails does not call it
11976
+ * at all, so no channel is silently disarmed by a bad read).
11977
+ */
11978
+ /** What `apply` reports back — enough to log, not enough to be a second state. */
11979
+ var LogChannelApplyResultSchema = zod.z.object({
11980
+ /** How many declared channels are armed in this process after the call. */
11981
+ armed: zod.z.number().int().min(0),
11982
+ /**
11983
+ * Names the document armed that this process does not declare. Reported
11984
+ * rather than swallowed: a name here is either a typo or an addon that has
11985
+ * not booted, and both deserve a line instead of silence.
11986
+ */
11987
+ unknown: zod.z.array(zod.z.string()).readonly()
11988
+ });
11989
+ var logChannelsCapability = {
11990
+ name: "log-channels",
11991
+ scope: "system",
11992
+ mode: "collection",
11993
+ internal: true,
11994
+ methods: {
11995
+ /** The channels this addon declares. Inert: no value, no state. */
11996
+ list: require_sleep.method(zod.z.void(), zod.z.array(LogChannelDescriptorSchema).readonly()),
11997
+ /**
11998
+ * Refresh this process's mirror from the document's FULL set of armed
11999
+ * windows.
12000
+ *
12001
+ * Full and not incremental on purpose: the document is the authority, so a
12002
+ * channel it does not name is disarmed here. An incremental apply would
12003
+ * let a disarm get lost in transit and leave a channel running that
12004
+ * nobody can see is running.
12005
+ */
12006
+ apply: require_sleep.method(zod.z.object({ windows: zod.z.array(LogChannelWindowSchema).readonly() }), LogChannelApplyResultSchema, { kind: "mutation" })
12007
+ },
12008
+ /** In-process only — enumerated through `addons.listCapabilityProviders`. */
12009
+ mount: { kind: "skip" }
12010
+ };
12011
+ //#endregion
12012
+ //#region src/capabilities/log-destination.cap.ts
12013
+ var LogLevelSchema = zod.z.enum([
12014
+ "debug",
12015
+ "info",
12016
+ "warn",
12017
+ "error"
12018
+ ]);
12019
+ var LogEntrySchema = zod.z.object({
12020
+ timestamp: zod.z.date(),
12021
+ level: LogLevelSchema,
12022
+ scope: zod.z.array(zod.z.string()),
12023
+ message: zod.z.string(),
12024
+ meta: zod.z.record(zod.z.string(), zod.z.unknown()).optional(),
12025
+ tags: zod.z.record(zod.z.string(), zod.z.string()).optional()
12026
+ });
12027
+ var logDestinationCapability = {
12028
+ name: "log-destination",
12029
+ scope: "system",
12030
+ mode: "collection",
12031
+ internal: true,
12032
+ methods: {
12033
+ write: require_sleep.method(LogEntrySchema, zod.z.void(), { kind: "mutation" }),
12034
+ query: require_sleep.method(zod.z.object({
12035
+ scope: zod.z.array(zod.z.string()).optional(),
12036
+ level: LogLevelSchema.optional(),
12037
+ since: zod.z.date().optional(),
12038
+ until: zod.z.date().optional(),
12039
+ limit: zod.z.number().optional(),
12040
+ tags: zod.z.record(zod.z.string(), zod.z.string()).optional()
12041
+ }), zod.z.array(LogEntrySchema).readonly())
12042
+ },
12043
+ /** BIG PLAN 2: declarative mount hint — read by `@camstack/system` `buildCapRouters`. */
12044
+ mount: { kind: "skip" }
12045
+ };
12046
+ //#endregion
11991
12047
  //#region src/capabilities/login-method.cap.ts
11992
12048
  /**
11993
12049
  * `login-method` — collection cap through which auth addons contribute
@@ -18192,14 +18248,65 @@ var MediaFileKindEnum = zod.z.enum([
18192
18248
  "keyFrameSmall",
18193
18249
  "thumbnailSmall"
18194
18250
  ]);
18195
- var MediaFileSchema = zod.z.object({
18251
+ /**
18252
+ * One media row's IDENTITY and shape, with no representation of its bytes.
18253
+ *
18254
+ * This is the half of a media row that is cheap: it comes out of the index
18255
+ * without opening a blob, and it is everything a client needs to decide what
18256
+ * to render before it renders anything. Both wire shapes below are this plus
18257
+ * an address; the STORE's own read-back shape ({@link MediaFileBytes}) is this
18258
+ * plus the bytes.
18259
+ */
18260
+ var MediaFileRefSchema = zod.z.object({
18196
18261
  key: zod.z.string(),
18197
18262
  kind: MediaFileKindEnum,
18198
- base64: zod.z.string(),
18199
18263
  sizeBytes: zod.z.number(),
18200
18264
  timestamp: zod.z.number()
18201
18265
  });
18202
18266
  /**
18267
+ * One media row ON THE WIRE: what it is, how big it is, and WHERE ITS BYTES
18268
+ * ARE — never the bytes themselves.
18269
+ *
18270
+ * ## Why `url` and not `base64`
18271
+ *
18272
+ * Measured on the live hub 2026-08-30: `getTrackMedia {trackId, deviceId}`
18273
+ * with no `kinds` returned 6 rows / **3 597 219 B**, of which `keyFrame` alone
18274
+ * was **2 824 077 B** — one full-resolution frame, base64, so +33 % on the
18275
+ * wire. Forty events is ~144 MB. Every byte of it was read off disk,
18276
+ * base64-encoded, held whole in a unary tRPC envelope, and materialised in
18277
+ * hub-main's heap on the way past — for an `<img>` that would have cached it.
18278
+ *
18279
+ * `url` points at the `event-media` data plane
18280
+ * (`/addon/<addonId>/event-media/<storedKey>`), which serves the same blob
18281
+ * with an ETag and `Cache-Control: immutable`, honours conditional GETs, can
18282
+ * render a `?variant=thumb`, and streams. The hub gate in front of it requires
18283
+ * a bearer or the session cookie (`access: 'authenticated'`), so the bytes are
18284
+ * no less protected than they were inside a `view`-level cap response — see
18285
+ * `data-plane-access.ts` for the rule and the one gap it does not close
18286
+ * (per-device scoping).
18287
+ *
18288
+ * The URL is built from the row's **stored** key, which is not always its
18289
+ * published `kind`: a track's face/plate crop is stored as `crop` under
18290
+ * `('face'|'plate', '<prefix>-<trackId>')` and published as
18291
+ * `faceCrop`/`plateCrop`. `MediaStore.getByKey` knows only the stored key.
18292
+ *
18293
+ * ## `base64` is TRANSITIONAL and is going away
18294
+ *
18295
+ * It is still populated for one reason: the deployed viewer's track-detail
18296
+ * HERO tile reads it (`use-track-media-entry.ts` → `parseMediaFiles`, which
18297
+ * REQUIRES the field), and a row without it parses as a FAILED read — the red
18298
+ * triangle — not as absence. Removing the field before that viewer ships is an
18299
+ * outage, not a cleanup. Once the viewer takes its hero bytes from `url`,
18300
+ * delete this line and the `withBytes` pass-through in
18301
+ * `analytics-query-facade.ts`; nothing else reads it.
18302
+ */
18303
+ var MediaFileSchema = MediaFileRefSchema.extend({
18304
+ /** `/addon/<addonId>/event-media/<encoded stored key>`. Always present. */
18305
+ url: zod.z.string(),
18306
+ /** @deprecated Transitional — see the schema docblock. Use {@link url}. */
18307
+ base64: zod.z.string()
18308
+ });
18309
+ /**
18203
18310
  * One media row WITHOUT its bytes.
18204
18311
  *
18205
18312
  * A track's media is 5-8 MB of base64 (measured: 7.67 MB across 23 files for a
@@ -18209,7 +18316,9 @@ var MediaFileSchema = zod.z.object({
18209
18316
  * blocks the whole view.
18210
18317
  *
18211
18318
  * `sizeBytes` is carried because it is what lets a client decide between the
18212
- * stored blob and a `?variant=thumb` rendering without fetching either.
18319
+ * stored blob and a `?variant=thumb` rendering without fetching either, and
18320
+ * `url` because a client that had to build the plane path itself is a second
18321
+ * copy of a route — the embed, the viewer and the admin UI each grew one.
18213
18322
  */
18214
18323
  var MediaFileInfoSchema = MediaFileSchema.omit({ base64: true });
18215
18324
  /**
@@ -19008,6 +19117,17 @@ var pipelineAnalyticsCapability = {
19008
19117
  * happens to stamp it. This count is what the migration planner's
19009
19118
  * non-blocking gate reads; `relocateMedia({ mode: 'seal' })` is what drives
19010
19119
  * it to zero.
19120
+ *
19121
+ * TWO indexed statements per collection, not a walk. It used to page the
19122
+ * whole collection at 200 rows per RPC ordered by an unindexed column, so
19123
+ * on the live hub — 1 254 576 rows — it hit the 60 s RPC deadline every
19124
+ * time it was called, and the migration it gates could never start. The
19125
+ * cheap question (`present`: is there at least one) is asked first and
19126
+ * separately from the expensive one (`rows`), because only the first has
19127
+ * to be answerable for the gate to do its job.
19128
+ *
19129
+ * **`null` is "not measurable", never zero** — at either level. An
19130
+ * unreadable collection must not read as a sealed one.
19011
19131
  */
19012
19132
  countUnstampedEventMedia: require_sleep.method(zod.z.object({}), UnstampedEventMediaCountSchema, { auth: "admin" }),
19013
19133
  /**
@@ -19331,6 +19451,26 @@ var pipelineAnalyticsCapability = {
19331
19451
  deviceId: zod.z.number()
19332
19452
  }), zod.z.array(MediaFileInfoSchema).readonly()),
19333
19453
  /**
19454
+ * What media an EVENT has, without any of it — the twin `getEventMedia`
19455
+ * never had.
19456
+ *
19457
+ * `listTrackMedia` above got this treatment because a track's media is
19458
+ * 5-8 MB. An event's is worse per row, not better: an old-style event owns
19459
+ * a `crop` AND a native-resolution `fullFrameBoxed`, and the track DETAIL
19460
+ * modal — the one surface that legitimately shows the big kinds — unions
19461
+ * both listings to build its filmstrip. It then renders every tile from
19462
+ * the `event-media` plane by key and throws the bytes away. Measured on
19463
+ * the live hub: one event's `fullFrameBoxed` is 2 824 077 B, base64'd to
19464
+ * ~3.8 MB, allocated whole in hub-main's heap, for a list of keys.
19465
+ *
19466
+ * Same `deviceId` authorization subject as `getEventMedia`, and the same
19467
+ * rows — this is a projection of that method, never a different question.
19468
+ */
19469
+ listEventMedia: require_sleep.method(zod.z.object({
19470
+ eventId: zod.z.string(),
19471
+ deviceId: zod.z.number()
19472
+ }), zod.z.array(MediaFileInfoSchema).readonly()),
19473
+ /**
19334
19474
  * Search object events by text query using CLIP cosine similarity.
19335
19475
  * Encodes `text` via the `embedding-encoder` cap, queries the
19336
19476
  * `ObjectEmbeddingStore` with optional prefilters, ranks all matching
@@ -26156,10 +26296,24 @@ var FaceClusterSchema = zod.z.object({
26156
26296
  size: zod.z.number().int(),
26157
26297
  cohesion: zod.z.number()
26158
26298
  });
26299
+ /**
26300
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
26301
+ * are — never the bytes.
26302
+ *
26303
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
26304
+ * track/event contract) is still populated because a deployed viewer requires
26305
+ * the field to parse a row at all; this method has no such reader. Its ONE
26306
+ * caller is the admin UI's detail modal, which was building
26307
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
26308
+ * dialog already rendering its key FRAME from the `event-media` plane.
26309
+ *
26310
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
26311
+ * media key directly, so this needed no new plane and no new access decision.
26312
+ */
26159
26313
  var MediaFileLiteSchema$1 = zod.z.object({
26160
26314
  key: zod.z.string(),
26161
26315
  kind: zod.z.string(),
26162
- base64: zod.z.string(),
26316
+ url: zod.z.string(),
26163
26317
  sizeBytes: zod.z.number(),
26164
26318
  timestamp: zod.z.number()
26165
26319
  });
@@ -29657,10 +29811,24 @@ var PlateInfoSchema = zod.z.object({
29657
29811
  */
29658
29812
  cropUrl: zod.z.string().optional()
29659
29813
  });
29814
+ /**
29815
+ * One gallery media row: what the crop is, how big it is, and WHERE its bytes
29816
+ * are — never the bytes.
29817
+ *
29818
+ * `base64` was deleted here rather than deprecated. `MediaFile.base64` (the
29819
+ * track/event contract) is still populated because a deployed viewer requires
29820
+ * the field to parse a row at all; this method has no such reader. Its ONE
29821
+ * caller is the admin UI's detail modal, which was building
29822
+ * `data:image/jpeg;base64,…` from a row whose `key` sat right beside it, in a
29823
+ * dialog already rendering its key FRAME from the `event-media` plane.
29824
+ *
29825
+ * `url` is `/addon/<addonId>/event-media/<encoded key>`. The plane resolves a
29826
+ * media key directly, so this needed no new plane and no new access decision.
29827
+ */
29660
29828
  var MediaFileLiteSchema = zod.z.object({
29661
29829
  key: zod.z.string(),
29662
29830
  kind: zod.z.string(),
29663
- base64: zod.z.string(),
29831
+ url: zod.z.string(),
29664
29832
  sizeBytes: zod.z.number(),
29665
29833
  timestamp: zod.z.number()
29666
29834
  });
@@ -41449,6 +41617,12 @@ var METHOD_ACCESS_MAP = Object.freeze({
41449
41617
  addonId: null,
41450
41618
  access: "view"
41451
41619
  },
41620
+ "pipelineAnalytics.listEventMedia": {
41621
+ capName: "pipeline-analytics",
41622
+ capScope: "device",
41623
+ addonId: null,
41624
+ access: "view"
41625
+ },
41452
41626
  "pipelineAnalytics.listGroups": {
41453
41627
  capName: "pipeline-analytics",
41454
41628
  capScope: "device",
@@ -45335,6 +45509,11 @@ var METHOD_DEVICE_SELECTORS = Object.freeze({
45335
45509
  form: "array",
45336
45510
  optional: false
45337
45511
  }],
45512
+ "pipelineAnalytics.listEventMedia": [{
45513
+ name: "deviceId",
45514
+ form: "single",
45515
+ optional: false
45516
+ }],
45338
45517
  "pipelineAnalytics.listGroups": [{
45339
45518
  name: "deviceIds",
45340
45519
  form: "array",
@@ -51712,6 +51891,7 @@ exports.MaskRectShapeSchema = MaskRectShapeSchema;
51712
51891
  exports.MaskShapeKindSchema = MaskShapeKindSchema;
51713
51892
  exports.MaskShapeSchema = MaskShapeSchema;
51714
51893
  exports.MediaFileInfoSchema = MediaFileInfoSchema;
51894
+ exports.MediaFileRefSchema = MediaFileRefSchema;
51715
51895
  exports.MediaFileSchema = MediaFileSchema;
51716
51896
  exports.MediaPlayerRepeatSchema = MediaPlayerRepeatSchema;
51717
51897
  exports.MediaPlayerStateSchema = MediaPlayerStateSchema;
@@ -52190,6 +52370,7 @@ exports.UNIT_TABLE = UNIT_TABLE;
52190
52370
  exports.UnifiedBrokerInfoSchema = BrokerInfoSchema$1;
52191
52371
  exports.UnitConversionError = UnitConversionError;
52192
52372
  exports.UnstampedEventMediaCountSchema = UnstampedEventMediaCountSchema;
52373
+ exports.UnstampedRowsSchema = UnstampedRowsSchema;
52193
52374
  exports.UpdateIntegrationInputSchema = UpdateIntegrationInputSchema;
52194
52375
  exports.UpdateStatusSchema = UpdateStatusSchema;
52195
52376
  exports.UpdateUserInputSchema = UpdateUserInputSchema;