@camstack/addon-terminal 0.1.119 → 0.1.121

package/dist/addon.js

@@ -5392,7 +5392,7 @@ var ZodIssueCode = {
 var ZodFirstPartyTypeKind;
 ZodFirstPartyTypeKind || (ZodFirstPartyTypeKind = {});
 //#endregion
-//#region ../types/dist/sleep-Bs3xPtSh.mjs
+//#region ../types/dist/sleep-GU_us3DG.mjs
 /**
 * The audio chunk plane's byte format, and the ONE expansion from a coded
 * window to float samples (D455).
@@ -7882,13 +7882,37 @@ var CameraSwitchGroupSchema = object({
 	fetchedAt: number()
 });
 /**
-* The wrapper capability each wrapper-backed switch controls. Named constants
-* because the same strings appear in `legacy-migrations.ts`, in
-* `isCapActiveForDevice` call sites and in the fake harness — a typo in any of
-* them is a switch that silently writes a binding nobody reads.
+* Every analyser a camera CamStack BUILDS is created with switched off.
+*
+* A grid and a Terminal camera are `DeviceType.Camera`, so every wrapper that
+* declares `defaultActive: true` for a camera binds to them the instant they
+* exist — the whole analysis family included. There is nothing there to
+* analyse: a grid's subjects are already counted on the cameras it composes (a
+* person in the bottom-right cell is a person on THAT camera, not on the grid),
+* and a Terminal camera shows a shell.
+*
+* ONE list, in the package both already depend on, because there were two and
+* they had already drifted: the Terminal's and the grid's each named three caps
+* and neither named `pipeline-analytics` — which has no gate of its own except
+* this binding, so a grid that forwards its sources' motion (so the viewer can
+* light its tile) would open a motion EPISODE per forwarded event, duplicating
+* the rows those sources already write.
+*
+* `motion-detection` sits first deliberately: it is the one that holds the
+* decode session open, so its absence is the difference between a derived
+* camera costing a composition and costing a full decode pipeline.
+*
+* Applied ONLY at creation. An operator who deliberately turns analysis back on
+* for a grid must win, and a reconcile that re-asserted this every pass would
+* silently overrule them once a minute.
 */
-var DETECTION_PIPELINE_CAP_NAME = "detection-pipeline";
-var AUDIO_ANALYSIS_CAP_NAME = "audio-analysis";
+var DERIVED_CAMERA_SILENCED_CAP_NAMES = [
+	"motion-detection",
+	"detection-pipeline",
+	"audio-analysis",
+	"pipeline-analytics",
+	"scene-monitor"
+];
 /**
 * What the gate decided about a birth, from the CALLER's point of view.
 *
@@ -29070,11 +29094,15 @@ var motionTriggerCapability = {
 *
 * Adding a fifth name to that list would have been the wrong fix twice over:
 * that page is per-camera DETECTION tuning, and a grid's geometry belongs
-* beside PTZ and motion zones on the camera itself — which is exactly where the
-* framework already puts a widget, when the widget is declared on a CAPABILITY.
-* `deviceConfig.ui` is the mechanism (`motion-zones`, `ptz`, `ptz-autotrack`
-* all use it): the framework emits the structural section and the widget
-* self-persists through the cap's own mutations.
+* beside PTZ and motion zones on the camera itself. The device page is
+* BINDING-driven (D12), so the way in is a capability bound to the device —
+* and this cap carries its section the way `recording` does, by RETURNING it
+* from `getDeviceSettingsContribution`.
+*
+* Seven other widgets are still declared the other way, through a
+* `deviceConfig.ui` block the framework derives a section from. That route
+* gives the addon no say in where its own panel lands and no way to decline
+* for a device the panel does not suit, which is why this one does not use it.
 *
 * ## Why one addon may implement it
 *
@@ -31433,6 +31461,25 @@ var ptzAutotrackCapability = {
 	scope: "device",
 	deviceNative: true,
 	mode: "singleton",
+	/**
+	* Two kinds of provider behind one name, the same shape `snapshot` and
+	* `doorbell` use:
+	*
+	*  - **Native**: the camera's own firmware autotrack, registered per device by
+	*    the driver when the probe says it exists (Reolink: yes; Hikvision:
+	*    model-dependent).
+	*  - **Wrapper**: the emulated implementation (`@camstack/system`'s `autotrack` builtin),
+	*    which follows a subject with `ptz.move` pulses driven by the detection
+	*    pipeline. `defaultActive: false` — the operator binds it per camera in
+	*    the bindings UI, exactly as `virtual-doorbell` is bound.
+	*
+	* The binding chooses WHICH implementation answers; `setEnabled` stays the
+	* one switch for the function either way. A camera never has both driving its
+	* head, which is the whole reason this is not a second cap with a second
+	* toggle (D62, D520).
+	*/
+	kind: "wrapper",
+	defaultActive: false,
 	deviceTypes: [DeviceType.Camera],
 	deviceConfig: { ui: {
 		kind: "widget",
@@ -44830,17 +44877,13 @@ async function warmNodePty() {
 //#endregion
 //#region src/silence-analysis.ts
 /**
-* Every analyzer a Terminal camera is created with switched OFF.
+* Every analyser a Terminal camera is created with switched OFF.
 *
-* `motion-detection` sits first deliberately: it is the one that holds the
-* decode session open, so it is the one whose absence is the difference between
-* a terminal costing a screen scrape and costing a decode pipeline.
+* An alias, not a copy. This list and the grid's were separate and had drifted
+* — neither named `pipeline-analytics` — so both now read the one in
+* `@camstack/types`, which is the package they already share.
 */
-var TERMINAL_SILENCED_CAP_NAMES = [
-	"motion-detection",
-	DETECTION_PIPELINE_CAP_NAME,
-	AUDIO_ANALYSIS_CAP_NAME
-];
+var TERMINAL_SILENCED_CAP_NAMES = DERIVED_CAMERA_SILENCED_CAP_NAMES;
 /**
 * Resolve the addon currently providing `capName` for this device.
 *

package/dist/addon.mjs

@@ -5369,7 +5369,7 @@ var ZodIssueCode = {
 var ZodFirstPartyTypeKind;
 ZodFirstPartyTypeKind || (ZodFirstPartyTypeKind = {});
 //#endregion
-//#region ../types/dist/sleep-Bs3xPtSh.mjs
+//#region ../types/dist/sleep-GU_us3DG.mjs
 /**
 * The audio chunk plane's byte format, and the ONE expansion from a coded
 * window to float samples (D455).
@@ -7859,13 +7859,37 @@ var CameraSwitchGroupSchema = object({
 	fetchedAt: number()
 });
 /**
-* The wrapper capability each wrapper-backed switch controls. Named constants
-* because the same strings appear in `legacy-migrations.ts`, in
-* `isCapActiveForDevice` call sites and in the fake harness — a typo in any of
-* them is a switch that silently writes a binding nobody reads.
+* Every analyser a camera CamStack BUILDS is created with switched off.
+*
+* A grid and a Terminal camera are `DeviceType.Camera`, so every wrapper that
+* declares `defaultActive: true` for a camera binds to them the instant they
+* exist — the whole analysis family included. There is nothing there to
+* analyse: a grid's subjects are already counted on the cameras it composes (a
+* person in the bottom-right cell is a person on THAT camera, not on the grid),
+* and a Terminal camera shows a shell.
+*
+* ONE list, in the package both already depend on, because there were two and
+* they had already drifted: the Terminal's and the grid's each named three caps
+* and neither named `pipeline-analytics` — which has no gate of its own except
+* this binding, so a grid that forwards its sources' motion (so the viewer can
+* light its tile) would open a motion EPISODE per forwarded event, duplicating
+* the rows those sources already write.
+*
+* `motion-detection` sits first deliberately: it is the one that holds the
+* decode session open, so its absence is the difference between a derived
+* camera costing a composition and costing a full decode pipeline.
+*
+* Applied ONLY at creation. An operator who deliberately turns analysis back on
+* for a grid must win, and a reconcile that re-asserted this every pass would
+* silently overrule them once a minute.
 */
-var DETECTION_PIPELINE_CAP_NAME = "detection-pipeline";
-var AUDIO_ANALYSIS_CAP_NAME = "audio-analysis";
+var DERIVED_CAMERA_SILENCED_CAP_NAMES = [
+	"motion-detection",
+	"detection-pipeline",
+	"audio-analysis",
+	"pipeline-analytics",
+	"scene-monitor"
+];
 /**
 * What the gate decided about a birth, from the CALLER's point of view.
 *
@@ -29047,11 +29071,15 @@ var motionTriggerCapability = {
 *
 * Adding a fifth name to that list would have been the wrong fix twice over:
 * that page is per-camera DETECTION tuning, and a grid's geometry belongs
-* beside PTZ and motion zones on the camera itself — which is exactly where the
-* framework already puts a widget, when the widget is declared on a CAPABILITY.
-* `deviceConfig.ui` is the mechanism (`motion-zones`, `ptz`, `ptz-autotrack`
-* all use it): the framework emits the structural section and the widget
-* self-persists through the cap's own mutations.
+* beside PTZ and motion zones on the camera itself. The device page is
+* BINDING-driven (D12), so the way in is a capability bound to the device —
+* and this cap carries its section the way `recording` does, by RETURNING it
+* from `getDeviceSettingsContribution`.
+*
+* Seven other widgets are still declared the other way, through a
+* `deviceConfig.ui` block the framework derives a section from. That route
+* gives the addon no say in where its own panel lands and no way to decline
+* for a device the panel does not suit, which is why this one does not use it.
 *
 * ## Why one addon may implement it
 *
@@ -31410,6 +31438,25 @@ var ptzAutotrackCapability = {
 	scope: "device",
 	deviceNative: true,
 	mode: "singleton",
+	/**
+	* Two kinds of provider behind one name, the same shape `snapshot` and
+	* `doorbell` use:
+	*
+	*  - **Native**: the camera's own firmware autotrack, registered per device by
+	*    the driver when the probe says it exists (Reolink: yes; Hikvision:
+	*    model-dependent).
+	*  - **Wrapper**: the emulated implementation (`@camstack/system`'s `autotrack` builtin),
+	*    which follows a subject with `ptz.move` pulses driven by the detection
+	*    pipeline. `defaultActive: false` — the operator binds it per camera in
+	*    the bindings UI, exactly as `virtual-doorbell` is bound.
+	*
+	* The binding chooses WHICH implementation answers; `setEnabled` stays the
+	* one switch for the function either way. A camera never has both driving its
+	* head, which is the whole reason this is not a second cap with a second
+	* toggle (D62, D520).
+	*/
+	kind: "wrapper",
+	defaultActive: false,
 	deviceTypes: [DeviceType.Camera],
 	deviceConfig: { ui: {
 		kind: "widget",
@@ -44807,17 +44854,13 @@ async function warmNodePty() {
 //#endregion
 //#region src/silence-analysis.ts
 /**
-* Every analyzer a Terminal camera is created with switched OFF.
+* Every analyser a Terminal camera is created with switched OFF.
 *
-* `motion-detection` sits first deliberately: it is the one that holds the
-* decode session open, so it is the one whose absence is the difference between
-* a terminal costing a screen scrape and costing a decode pipeline.
+* An alias, not a copy. This list and the grid's were separate and had drifted
+* — neither named `pipeline-analytics` — so both now read the one in
+* `@camstack/types`, which is the package they already share.
 */
-var TERMINAL_SILENCED_CAP_NAMES = [
-	"motion-detection",
-	DETECTION_PIPELINE_CAP_NAME,
-	AUDIO_ANALYSIS_CAP_NAME
-];
+var TERMINAL_SILENCED_CAP_NAMES = DERIVED_CAMERA_SILENCED_CAP_NAMES;
 /**
 * Resolve the addon currently providing `capName` for this device.
 *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camstack/addon-terminal",
-  "version": "0.1.119",
+  "version": "0.1.121",
   "description": "Interactive terminal sessions (pty + xterm) as a CamStack addon",
   "keywords": [
     "camstack",