@camstack/types 1.2.120 → 1.2.122

package/dist/capabilities/metrics-provider.cap.d.ts

@@ -196,6 +196,45 @@ declare const NodeProcessSchema: z.ZodObject<{
     threadCount: z.ZodNullable<z.ZodNumber>;
     uptimeSec: z.ZodNumber;
 }, z.core.$strip>;
+declare const ContainerMemorySnapshotSchema: z.ZodObject<{
+    source: z.ZodEnum<{
+        "cgroup-v2": "cgroup-v2";
+        "cgroup-v1": "cgroup-v1";
+    }>;
+    currentBytes: z.ZodNumber;
+    limitBytes: z.ZodNullable<z.ZodNumber>;
+    anonBytes: z.ZodNullable<z.ZodNumber>;
+    fileBytes: z.ZodNullable<z.ZodNumber>;
+    shmemBytes: z.ZodNullable<z.ZodNumber>;
+    slabBytes: z.ZodNullable<z.ZodNumber>;
+    gpuShmemBytes: z.ZodNullable<z.ZodNumber>;
+}, z.core.$strip>;
+/**
+ * One retained container-memory reading.
+ *
+ * `atMs` is the timestamp of the PROCESS snapshot taken in the same tick, not
+ * a second clock: that is what makes "processes sum to X, container says Y"
+ * subtractable per point rather than an eyeballed comparison of two series
+ * sampled at different instants.
+ *
+ * A reduced window keeps the sample with the LARGEST `currentBytes` in each
+ * bucket, WHOLE. Taking a per-field maximum would synthesise a row whose parts
+ * never coexisted, and a mean would smear away the peak this exists to find.
+ */
+declare const ContainerMemoryPointSchema: z.ZodObject<{
+    source: z.ZodEnum<{
+        "cgroup-v2": "cgroup-v2";
+        "cgroup-v1": "cgroup-v1";
+    }>;
+    currentBytes: z.ZodNumber;
+    limitBytes: z.ZodNullable<z.ZodNumber>;
+    anonBytes: z.ZodNullable<z.ZodNumber>;
+    fileBytes: z.ZodNullable<z.ZodNumber>;
+    shmemBytes: z.ZodNullable<z.ZodNumber>;
+    slabBytes: z.ZodNullable<z.ZodNumber>;
+    gpuShmemBytes: z.ZodNullable<z.ZodNumber>;
+    atMs: z.ZodNumber;
+}, z.core.$strip>;
 declare const DumpHeapSnapshotInputSchema: z.ZodObject<{
     addonId: z.ZodString;
 }, z.core.$strip>;
@@ -280,6 +319,20 @@ declare const NodeLoadSeriesSchema: z.ZodObject<{
             processCountMin: z.ZodNumber;
         }, z.core.$strip>>>;
     }, z.core.$strip>>>;
+    containerMemory: z.ZodReadonly<z.ZodArray<z.ZodObject<{
+        source: z.ZodEnum<{
+            "cgroup-v2": "cgroup-v2";
+            "cgroup-v1": "cgroup-v1";
+        }>;
+        currentBytes: z.ZodNumber;
+        limitBytes: z.ZodNullable<z.ZodNumber>;
+        anonBytes: z.ZodNullable<z.ZodNumber>;
+        fileBytes: z.ZodNullable<z.ZodNumber>;
+        shmemBytes: z.ZodNullable<z.ZodNumber>;
+        slabBytes: z.ZodNullable<z.ZodNumber>;
+        gpuShmemBytes: z.ZodNullable<z.ZodNumber>;
+        atMs: z.ZodNumber;
+    }, z.core.$strip>>>;
     bucketMs: z.ZodNumber;
     retainedSamples: z.ZodNumber;
     oldestAtMs: z.ZodNullable<z.ZodNumber>;
@@ -641,6 +694,20 @@ export declare const metricsProviderCapability: {
                     processCountMin: z.ZodNumber;
                 }, z.core.$strip>>>;
             }, z.core.$strip>>>;
+            containerMemory: z.ZodReadonly<z.ZodArray<z.ZodObject<{
+                source: z.ZodEnum<{
+                    "cgroup-v2": "cgroup-v2";
+                    "cgroup-v1": "cgroup-v1";
+                }>;
+                currentBytes: z.ZodNumber;
+                limitBytes: z.ZodNullable<z.ZodNumber>;
+                anonBytes: z.ZodNullable<z.ZodNumber>;
+                fileBytes: z.ZodNullable<z.ZodNumber>;
+                shmemBytes: z.ZodNullable<z.ZodNumber>;
+                slabBytes: z.ZodNullable<z.ZodNumber>;
+                gpuShmemBytes: z.ZodNullable<z.ZodNumber>;
+                atMs: z.ZodNumber;
+            }, z.core.$strip>>>;
             bucketMs: z.ZodNumber;
             retainedSamples: z.ZodNumber;
             oldestAtMs: z.ZodNullable<z.ZodNumber>;
@@ -666,4 +733,4 @@ export declare const metricsProviderCapability: {
     };
 };
 export type IMetricsProvider = InferProvider<typeof metricsProviderCapability>;
-export { SystemMetricsSchema, SystemResourceSnapshotSchema, DiskSpaceInfoSchema, MetricsGpuInfoSchema, PidResourceStatsSchema, AddonInstanceSchema, NodeProcessSchema, DumpHeapSnapshotInputSchema, DumpHeapSnapshotResultSchema, LoadPointSchema, LoadFunctionSeriesSchema, NodeLoadSeriesSchema, GetLoadSeriesInputSchema, CpuBreakdownSchema, MemoryInfoSchema, DiskIoSnapshotSchema, NetworkIoSnapshotSchema, ProcessResourceInfoSchema, PressureInfoSchema, };
+export { SystemMetricsSchema, SystemResourceSnapshotSchema, DiskSpaceInfoSchema, MetricsGpuInfoSchema, PidResourceStatsSchema, AddonInstanceSchema, NodeProcessSchema, DumpHeapSnapshotInputSchema, DumpHeapSnapshotResultSchema, LoadPointSchema, LoadFunctionSeriesSchema, ContainerMemorySnapshotSchema, ContainerMemoryPointSchema, NodeLoadSeriesSchema, GetLoadSeriesInputSchema, CpuBreakdownSchema, MemoryInfoSchema, DiskIoSnapshotSchema, NetworkIoSnapshotSchema, ProcessResourceInfoSchema, PressureInfoSchema, };

package/dist/capabilities/recording.cap.d.ts

@@ -3,10 +3,10 @@
  * recording config. NOTE on events (source of truth, R5/C3): this cap carries
  * NO event surface — `getPlaybackManifest` returns playlist URLs only. Timeline
  * events (motion/object/audio) come from `pipelineAnalytics` (durable SQLite
- * rows); the recorder's internal EventMap markers are ephemeral in-RAM
- * annotations that are not exposed here and must not be treated as an event
- * feed. Event<->footage joins are by time, padded with the shared `EVENT_PAD_MS`
- * (`interfaces/recording-config.ts`).
+ * rows) and are the ONLY event surface — the recorder has none. The in-RAM
+ * playback markers it used to build were deleted on 2026-08-29 because nothing
+ * ever read them. Event<->footage joins are by time, padded with the shared
+ * `EVENT_PAD_MS` (`interfaces/recording-config.ts`).
  */
 import { z } from 'zod';
 import { type InferProvider } from './capability-definition.js';

package/dist/index.js

@@ -1885,11 +1885,10 @@ var DetectionCatalogClassMapSchema = zod.z.object({
 * timestamp + postMs]`). Matches the admin-ui clip window (−5s/+10s).
 *
 * Every consumer derives from this ONE constant so event↔footage boundaries
-* agree everywhere (C1):
-*   - the `videoclips` default provider (addon-post-analysis) pads its clip
-*     windows with it;
-*   - the recorder's ephemeral in-RAM `EventMap` markers (addon-pipeline) pad
-*     their `startMs/endMs` with it.
+* agree everywhere (C1): today that is the `videoclips` default provider
+* (addon-post-analysis), which pads its clip windows with it. The recorder used
+* to pad in-RAM playback markers with it too; those markers had no reader
+* anywhere in the repo and were deleted on 2026-08-29.
 *
 * NOTE: this is a UI/JOIN convention, NOT the `events`-band keep/discard gate —
 * that uses the per-device `preBufferSec`/`postBufferSec` config.
@@ -11898,6 +11897,50 @@ var NodeProcessSchema = zod.z.object({
 	/** Wall-clock uptime (seconds). Parsed from `ps etime`. */
 	uptimeSec: zod.z.number()
 });
+/**
+* One retained container-memory reading.
+*
+* `atMs` is the timestamp of the PROCESS snapshot taken in the same tick, not
+* a second clock: that is what makes "processes sum to X, container says Y"
+* subtractable per point rather than an eyeballed comparison of two series
+* sampled at different instants.
+*
+* A reduced window keeps the sample with the LARGEST `currentBytes` in each
+* bucket, WHOLE. Taking a per-field maximum would synthesise a row whose parts
+* never coexisted, and a mean would smear away the peak this exists to find.
+*/
+var ContainerMemoryPointSchema = zod.z.object({
+	/** Which hierarchy answered, so a reading is never ambiguous. */
+	source: zod.z.enum(["cgroup-v2", "cgroup-v1"]),
+	/** `memory.current` (v2) / `memory.usage_in_bytes` (v1). Always known. */
+	currentBytes: zod.z.number(),
+	/** The cgroup's ceiling. `null` = NO LIMIT — never a sentinel, never zero. */
+	limitBytes: zod.z.number().nullable(),
+	/** Anonymous pages: the closest thing to "what the processes allocated". */
+	anonBytes: zod.z.number().nullable(),
+	/** Page cache. Charged to the cgroup, owned by no process. */
+	fileBytes: zod.z.number().nullable(),
+	/**
+	* Shared memory — and the field that explained the largest single surprise.
+	* The i915 driver backs GPU buffers with shmem, so an inference pool or a
+	* hardware-decode session holding DRM objects is charged HERE and appears
+	* nowhere in a `ps` scan.
+	*/
+	shmemBytes: zod.z.number().nullable(),
+	/** Kernel slab charged to this cgroup. `null` on v1, which never publishes it. */
+	slabBytes: zod.z.number().nullable(),
+	/**
+	* Shrinkable i915 GEM object bytes, from debugfs.
+	*
+	* **Host-wide across every DRM client, NOT cgroup-scoped.** It is not a
+	* component of `currentBytes` and must not be subtracted from it; it says
+	* what put the shmem there, where `shmemBytes` only says how much.
+	*
+	* `null` wherever debugfs is not mounted — which is inside every camstack
+	* container today — and on any node with no Intel GPU.
+	*/
+	gpuShmemBytes: zod.z.number().nullable()
+}).extend({ atMs: zod.z.number() });
 var DumpHeapSnapshotInputSchema = zod.z.object({ 
 /** The addon whose runner should dump a heap snapshot. */
 addonId: zod.z.string() });
@@ -11961,6 +12004,21 @@ var NodeLoadSeriesSchema = zod.z.object({
 	/** One entry per function seen in the window, heaviest-first. */
 	series: zod.z.array(LoadFunctionSeriesSchema).readonly(),
 	/**
+	* The CONTAINER's memory over the same window, oldest-first.
+	*
+	* Sits next to `series` rather than in a method of its own because the whole
+	* question is a subtraction: the per-process rows in `series` sum to one
+	* number and this one is another, and an operator who has to issue two calls
+	* to compare them will compare two different instants. Same reader, same
+	* `sinceMs`, same `bucketMs`, same timestamps.
+	*
+	* **EMPTY means ABSENT, never zero.** A node with no cgroup — a developer
+	* Mac, a bare-metal host, a container with the hierarchy hidden — reports no
+	* points at all. A zero here would be indistinguishable from a healthy
+	* container and is precisely the lie this field exists to avoid.
+	*/
+	containerMemory: zod.z.array(ContainerMemoryPointSchema).readonly(),
+	/**
 	* Width of one returned bucket, in ms. Equals the sampling cadence when no
 	* reduction was needed — so a caller can always say what one point covers
 	* without having to know whether it was reduced.
@@ -29953,10 +30011,10 @@ var rebootCapability = {
 * recording config. NOTE on events (source of truth, R5/C3): this cap carries
 * NO event surface — `getPlaybackManifest` returns playlist URLs only. Timeline
 * events (motion/object/audio) come from `pipelineAnalytics` (durable SQLite
-* rows); the recorder's internal EventMap markers are ephemeral in-RAM
-* annotations that are not exposed here and must not be treated as an event
-* feed. Event<->footage joins are by time, padded with the shared `EVENT_PAD_MS`
-* (`interfaces/recording-config.ts`).
+* rows) and are the ONLY event surface — the recorder has none. The in-RAM
+* playback markers it used to build were deleted on 2026-08-29 because nothing
+* ever read them. Event<->footage joins are by time, padded with the shared
+* `EVENT_PAD_MS` (`interfaces/recording-config.ts`).
 */
 var RecordingStatusSchema = zod.z.object({
 	deviceId: zod.z.number(),

package/dist/index.mjs

@@ -1884,11 +1884,10 @@ var DetectionCatalogClassMapSchema = z.object({
 * timestamp + postMs]`). Matches the admin-ui clip window (−5s/+10s).
 *
 * Every consumer derives from this ONE constant so event↔footage boundaries
-* agree everywhere (C1):
-*   - the `videoclips` default provider (addon-post-analysis) pads its clip
-*     windows with it;
-*   - the recorder's ephemeral in-RAM `EventMap` markers (addon-pipeline) pad
-*     their `startMs/endMs` with it.
+* agree everywhere (C1): today that is the `videoclips` default provider
+* (addon-post-analysis), which pads its clip windows with it. The recorder used
+* to pad in-RAM playback markers with it too; those markers had no reader
+* anywhere in the repo and were deleted on 2026-08-29.
 *
 * NOTE: this is a UI/JOIN convention, NOT the `events`-band keep/discard gate —
 * that uses the per-device `preBufferSec`/`postBufferSec` config.
@@ -11897,6 +11896,50 @@ var NodeProcessSchema = z.object({
 	/** Wall-clock uptime (seconds). Parsed from `ps etime`. */
 	uptimeSec: z.number()
 });
+/**
+* One retained container-memory reading.
+*
+* `atMs` is the timestamp of the PROCESS snapshot taken in the same tick, not
+* a second clock: that is what makes "processes sum to X, container says Y"
+* subtractable per point rather than an eyeballed comparison of two series
+* sampled at different instants.
+*
+* A reduced window keeps the sample with the LARGEST `currentBytes` in each
+* bucket, WHOLE. Taking a per-field maximum would synthesise a row whose parts
+* never coexisted, and a mean would smear away the peak this exists to find.
+*/
+var ContainerMemoryPointSchema = z.object({
+	/** Which hierarchy answered, so a reading is never ambiguous. */
+	source: z.enum(["cgroup-v2", "cgroup-v1"]),
+	/** `memory.current` (v2) / `memory.usage_in_bytes` (v1). Always known. */
+	currentBytes: z.number(),
+	/** The cgroup's ceiling. `null` = NO LIMIT — never a sentinel, never zero. */
+	limitBytes: z.number().nullable(),
+	/** Anonymous pages: the closest thing to "what the processes allocated". */
+	anonBytes: z.number().nullable(),
+	/** Page cache. Charged to the cgroup, owned by no process. */
+	fileBytes: z.number().nullable(),
+	/**
+	* Shared memory — and the field that explained the largest single surprise.
+	* The i915 driver backs GPU buffers with shmem, so an inference pool or a
+	* hardware-decode session holding DRM objects is charged HERE and appears
+	* nowhere in a `ps` scan.
+	*/
+	shmemBytes: z.number().nullable(),
+	/** Kernel slab charged to this cgroup. `null` on v1, which never publishes it. */
+	slabBytes: z.number().nullable(),
+	/**
+	* Shrinkable i915 GEM object bytes, from debugfs.
+	*
+	* **Host-wide across every DRM client, NOT cgroup-scoped.** It is not a
+	* component of `currentBytes` and must not be subtracted from it; it says
+	* what put the shmem there, where `shmemBytes` only says how much.
+	*
+	* `null` wherever debugfs is not mounted — which is inside every camstack
+	* container today — and on any node with no Intel GPU.
+	*/
+	gpuShmemBytes: z.number().nullable()
+}).extend({ atMs: z.number() });
 var DumpHeapSnapshotInputSchema = z.object({ 
 /** The addon whose runner should dump a heap snapshot. */
 addonId: z.string() });
@@ -11960,6 +12003,21 @@ var NodeLoadSeriesSchema = z.object({
 	/** One entry per function seen in the window, heaviest-first. */
 	series: z.array(LoadFunctionSeriesSchema).readonly(),
 	/**
+	* The CONTAINER's memory over the same window, oldest-first.
+	*
+	* Sits next to `series` rather than in a method of its own because the whole
+	* question is a subtraction: the per-process rows in `series` sum to one
+	* number and this one is another, and an operator who has to issue two calls
+	* to compare them will compare two different instants. Same reader, same
+	* `sinceMs`, same `bucketMs`, same timestamps.
+	*
+	* **EMPTY means ABSENT, never zero.** A node with no cgroup — a developer
+	* Mac, a bare-metal host, a container with the hierarchy hidden — reports no
+	* points at all. A zero here would be indistinguishable from a healthy
+	* container and is precisely the lie this field exists to avoid.
+	*/
+	containerMemory: z.array(ContainerMemoryPointSchema).readonly(),
+	/**
 	* Width of one returned bucket, in ms. Equals the sampling cadence when no
 	* reduction was needed — so a caller can always say what one point covers
 	* without having to know whether it was reduced.
@@ -29952,10 +30010,10 @@ var rebootCapability = {
 * recording config. NOTE on events (source of truth, R5/C3): this cap carries
 * NO event surface — `getPlaybackManifest` returns playlist URLs only. Timeline
 * events (motion/object/audio) come from `pipelineAnalytics` (durable SQLite
-* rows); the recorder's internal EventMap markers are ephemeral in-RAM
-* annotations that are not exposed here and must not be treated as an event
-* feed. Event<->footage joins are by time, padded with the shared `EVENT_PAD_MS`
-* (`interfaces/recording-config.ts`).
+* rows) and are the ONLY event surface — the recorder has none. The in-RAM
+* playback markers it used to build were deleted on 2026-08-29 because nothing
+* ever read them. Event<->footage joins are by time, padded with the shared
+* `EVENT_PAD_MS` (`interfaces/recording-config.ts`).
 */
 var RecordingStatusSchema = z.object({
 	deviceId: z.number(),

package/dist/interfaces/event-bus.d.ts

@@ -7,7 +7,7 @@ import type { PipelineEngineChoice } from '../types/pipeline.js';
 import type { PipelineExecutionTrace, StepCadence } from '../types/pipeline-step.js';
 import type { CameraMetrics } from './api-shared.js';
 import type { FrameHandle } from './frame-handle.js';
-import type { NodeProcess, SystemResourceSnapshot } from './metrics-provider.js';
+import type { ContainerMemorySnapshot, NodeProcess, SystemResourceSnapshot } from './metrics-provider.js';
 import type { RunnerLocalLoad } from './pipeline-runner-capability.js';
 import type { BrokerStats } from './stream-broker.js';
 export interface EventSource {
@@ -1198,6 +1198,16 @@ export interface EventCatalog {
         readonly nodeId: string;
         readonly processes: ReadonlyArray<NodeProcess>;
         readonly timestamp: number;
+        /**
+         * The CONTAINER's memory at the SAME instant as `processes`, or `null`
+         * when this node has no cgroup.
+         *
+         * It rides this event rather than one of its own for a single reason: the
+         * question is a subtraction. The processes above sum to one number and
+         * this is another, and two events would carry two timestamps that never
+         * quite line up. `null` is ABSENT — never a zeroed reading.
+         */
+        readonly containerMemory: ContainerMemorySnapshot | null;
     };
     /**
      * Per-agent hwaccel override changed (set / cleared / re-probed). Payload

package/dist/interfaces/metrics-provider.d.ts

@@ -1,5 +1,5 @@
 import type { z } from 'zod';
-import type { CpuBreakdownSchema, MemoryInfoSchema, DiskIoSnapshotSchema, NetworkIoSnapshotSchema, MetricsGpuInfoSchema, ProcessResourceInfoSchema, PressureInfoSchema, SystemResourceSnapshotSchema, DiskSpaceInfoSchema, PidResourceStatsSchema, AddonInstanceSchema, NodeProcessSchema, DumpHeapSnapshotInputSchema, DumpHeapSnapshotResultSchema, LoadPointSchema, LoadFunctionSeriesSchema, NodeLoadSeriesSchema, GetLoadSeriesInputSchema } from '../capabilities/metrics-provider.cap.js';
+import type { CpuBreakdownSchema, MemoryInfoSchema, DiskIoSnapshotSchema, NetworkIoSnapshotSchema, MetricsGpuInfoSchema, ProcessResourceInfoSchema, PressureInfoSchema, SystemResourceSnapshotSchema, DiskSpaceInfoSchema, PidResourceStatsSchema, AddonInstanceSchema, NodeProcessSchema, DumpHeapSnapshotInputSchema, DumpHeapSnapshotResultSchema, LoadPointSchema, LoadFunctionSeriesSchema, ContainerMemorySnapshotSchema, ContainerMemoryPointSchema, NodeLoadSeriesSchema, GetLoadSeriesInputSchema } from '../capabilities/metrics-provider.cap.js';
 export type CpuBreakdown = z.infer<typeof CpuBreakdownSchema>;
 export type MemoryInfo = z.infer<typeof MemoryInfoSchema>;
 export type DiskIoSnapshot = z.infer<typeof DiskIoSnapshotSchema>;
@@ -16,5 +16,7 @@ export type DumpHeapSnapshotInput = z.infer<typeof DumpHeapSnapshotInputSchema>;
 export type DumpHeapSnapshotResult = z.infer<typeof DumpHeapSnapshotResultSchema>;
 export type LoadSeriesPoint = z.infer<typeof LoadPointSchema>;
 export type LoadFunctionSeries = z.infer<typeof LoadFunctionSeriesSchema>;
+export type ContainerMemorySnapshot = z.infer<typeof ContainerMemorySnapshotSchema>;
+export type ContainerMemoryPoint = z.infer<typeof ContainerMemoryPointSchema>;
 export type NodeLoadSeries = z.infer<typeof NodeLoadSeriesSchema>;
 export type GetLoadSeriesInput = z.infer<typeof GetLoadSeriesInputSchema>;

package/dist/interfaces/recording-config.d.ts

@@ -6,11 +6,10 @@ import { type CamProfile } from '../capabilities/schemas/streaming-shared.js';
  * timestamp + postMs]`). Matches the admin-ui clip window (−5s/+10s).
  *
  * Every consumer derives from this ONE constant so event↔footage boundaries
- * agree everywhere (C1):
- *   - the `videoclips` default provider (addon-post-analysis) pads its clip
- *     windows with it;
- *   - the recorder's ephemeral in-RAM `EventMap` markers (addon-pipeline) pad
- *     their `startMs/endMs` with it.
+ * agree everywhere (C1): today that is the `videoclips` default provider
+ * (addon-post-analysis), which pads its clip windows with it. The recorder used
+ * to pad in-RAM playback markers with it too; those markers had no reader
+ * anywhere in the repo and were deleted on 2026-08-29.
  *
  * NOTE: this is a UI/JOIN convention, NOT the `events`-band keep/discard gate —
  * that uses the per-device `preBufferSec`/`postBufferSec` config.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camstack/types",
-  "version": "1.2.120",
+  "version": "1.2.122",
   "description": "Shared types, interfaces, and model catalogs for the CamStack detection ecosystem",
   "keywords": [
     "camstack",