@dx-do/cli 5.2.49 → 5.2.50

package/dist-node/20-nassql-from-metadata-basic.nassql.data-store-zdf1gp1v.json5

@@ -0,0 +1,42 @@
+/*
+ * The simplest NASSQL pipeline — count all metrics on the tenant.
+ * The "hello world" of NASSQL: FROM_METADATA → COUNT → KEEP.
+ *
+ * `FROM_METADATA` returns one row per registered metric definition
+ * (NOT per datapoint). COUNT collapses to a single number. The
+ * total scales with how much telemetry the tenant collects;
+ * single thousands → tens of thousands is normal.
+ */
+{
+  "query": [
+    /*
+     * FROM_METADATA loads metric DEFINITIONS as rows. The `ALL`
+     * specifier matches every metric; an alternative spec narrows.
+     * `alias` names this stage's output (referenceable downstream
+     * via `<alias>.<column>` if you do JOINs).
+     */
+    {
+      "op": "FROM_METADATA",
+      "querySpecifier": { "op": "ALL" },
+      "alias": "all_metrics"
+    },
+    /*
+     * COUNT with no `columns` field → count all rows (regardless
+     * of grouping). With a preceding GROUP, COUNT is per-group.
+     * `as: "total"` names the resulting column.
+     */
+    {
+      "op": "COUNT",
+      "as": "total"
+    },
+    /*
+     * KEEP must be the LAST op (server returns HTTP 400 if anything
+     * follows). Selects which columns appear in the response.
+     */
+    {
+      "op": "KEEP",
+      "columns": ["total"]
+    }
+  ],
+  "limit": 10
+}

package/dist-node/21-nassql-from-metadata-regex.nassql-78jnsn3e.md

@@ -0,0 +1,30 @@
+# 21-nassql-from-metadata-regex (NASSQL)
+
+## Purpose
+
+Demonstrate `FROM_METADATA` with a `SPEC` query specifier that uses REGEX patterns to filter by source name and attribute path.
+
+## Query Construction
+
+The `querySpecifier` uses the `SPEC` op with two nested specifiers:
+- `sourceNameSpecifier: { op: "REGEX", pattern: ".*Infrastructure.*" }` — matches sources containing "Infrastructure"
+- `attributeNameSpecifier: { op: "REGEX", pattern: ".*CPU.*" }` — matches metric paths containing "CPU"
+
+This finds CPU metrics reported by Infrastructure agents.
+
+## API Surface Exercised
+
+- **FROM_METADATA** with `SPEC` specifier
+- **SourceNameSpecifier**: `REGEX` op with `pattern`
+- **AttributeNameSpecifier**: `REGEX` op with `pattern`
+- **KEEP**: Column selection
+
+## Expected Output
+
+Up to 50 rows with columns `["metric.source", "metric.path"]`. Each row is a metric whose source contains "Infrastructure" and whose path contains "CPU".
+
+## What the Results Tell You
+
+The `SPEC` specifier is the most flexible metadata query mechanism. It composes independent specifiers for source name, attribute/path name, and folder name. Each sub-specifier supports its own set of ops (`ALL`, `REGEX`, `EXACT`, `PART`, `AND`, `OR`, `NOT`).
+
+Important: You cannot put `{ op: "REGEX", source: "...", path: "..." }` directly as the `querySpecifier`. The REGEX must be nested inside a `SPEC` with `sourceNameSpecifier` and/or `attributeNameSpecifier`.

package/dist-node/21-nassql-from-metadata-regex.nassql.data-store-ckzsv7h1.json5

@@ -0,0 +1,53 @@
+/*
+ * `FROM_METADATA` with a structured `SPEC` querySpecifier — narrow
+ * which metrics enter the pipeline. Two filter axes, both optional:
+ *   sourceNameSpecifier  → narrows by metric.source value
+ *   attributeNameSpecifier → narrows by metric attribute name
+ *
+ * Each can be REGEX (Java regex) or EXACT (literal). Combine them
+ * to find "all CPU metrics from Infrastructure-* sources" etc.
+ *
+ * Cheaper + cleaner than loading ALL metrics and filtering with
+ * a downstream FILTER op — the spec narrows server-side.
+ */
+{
+  "query": [
+    {
+      "op": "FROM_METADATA",
+      /*
+       * `querySpecifier` shapes WHICH metric metadata rows enter
+       * the pipeline. `op: SPEC` is the structured form; `op:
+       * ALL` (cheaper, no narrowing) is the alternative.
+       *
+       * Both specifiers are AND-combined when present. Missing
+       * means "no constraint on that axis."
+       */
+      "querySpecifier": {
+        "op": "SPEC",
+        /*
+         * Narrow by source. REGEX takes a Java pattern;
+         * `.*Infrastructure.*` matches any source name
+         * containing "Infrastructure" (case-sensitive). For
+         * EXACT match, use `op: EXACT, names: ["..."]`.
+         */
+        "sourceNameSpecifier": {
+          "op": "REGEX",
+          "pattern": ".*Infrastructure.*"
+        },
+        /*
+         * Narrow by metric attribute name. Same shape.
+         */
+        "attributeNameSpecifier": {
+          "op": "REGEX",
+          "pattern": ".*CPU.*"
+        }
+      },
+      "alias": "cpu_metrics"
+    },
+    {
+      "op": "KEEP",
+      "columns": ["metric.source", "metric.path"]
+    }
+  ],
+  "limit": 50
+}

package/dist-node/21-nassql-from-metadata-regex.nassql.data-store-tmd-zgr6r9my.json

@@ -0,0 +1,4 @@
+{
+  "description": "FROM_METADATA with REGEX specifier: find CPU-related metrics from Infrastructure agents",
+  "tags": ["nassql", "from_metadata", "regex"]
+}

package/dist-node/22-nassql-from-topology.nassql-a71qw9r0.md

@@ -0,0 +1,42 @@
+# 22-nassql-from-topology (NASSQL)
+
+## Purpose
+
+Demonstrate `FROM_TOPOLOGY`, which loads TAS topology vertices into a NASSQL tabular result for further processing with NASSQL operations.
+
+## Query Construction
+
+`FROM_TOPOLOGY` takes a `querySpecifier` that is a **full TAS query object** (with `filter`), not a metadata query specifier:
+
+```json
+{
+  "op": "FROM_TOPOLOGY",
+  "querySpecifier": {
+    "filter": {
+      "op": "ATTRIBUTE",
+      "expressions": [{ "name": "type", "values": ["HOST"], "operator": "IN" }]
+    }
+  }
+}
+```
+
+The TAS query result is flattened into tabular rows. Each vertex attribute becomes a column prefixed with `vertex.attr.`, and vertex metadata becomes `vertex.id`, `vertex.externalId`, `vertex.startTime`, `vertex.endTime`.
+
+## API Surface Exercised
+
+- **FROM_TOPOLOGY**: Cross-domain bridge from topology to tabular NASSQL
+- **TAS filter inside NASSQL**: Reuses the full TAS query model
+- **KEEP**: Select specific vertex attribute columns
+
+## Expected Output
+
+Up to 20 rows, each representing a HOST vertex with columns like:
+- `vertex.attr.name` — host name
+- `vertex.attr.type` — "HOST"
+- `vertex.externalId` — canonical external ID (e.g., `INFRASTRUCTURE:HOST:...`)
+
+## What the Results Tell You
+
+`FROM_TOPOLOGY` is the key cross-domain operation that connects topology data with metric data. After loading topology vertices as rows, you can `JOIN_METADATA` or `JOIN_DATA` to enrich them with metrics.
+
+Critical: The `querySpecifier` here is a TAS query, NOT a metric query specifier. It must include `filter` and optionally `projection`, `limit`, etc.

package/dist-node/22-nassql-from-topology.nassql.data-store-81m23nge.json5

@@ -0,0 +1,58 @@
+/*
+ * `FROM_TOPOLOGY` — load TAS query results into a NASSQL pipeline
+ * as rows (one row per matched vertex). The bridge from the graph
+ * world (TAS) to the tabular world (NASSQL).
+ *
+ * Use when the question is "tabular questions ABOUT entities":
+ *   - Group hosts by region and count
+ *   - Sort agents by name and paginate
+ *   - Compute statistics across vertex attributes
+ *
+ * For "graph questions" (neighbors, paths, traversal), stay in TAS.
+ *
+ * The vertex attributes appear as columns prefixed `vertex.attr.<n>`;
+ * the vertex's own metadata appears as `vertex.externalId`,
+ * `vertex.id`, `vertex.startTime`, etc.
+ */
+{
+  "query": [
+    /*
+     * FROM_TOPOLOGY's querySpecifier is `{ filter: <TASFilter> }`
+     * — a wrapper around a normal TAS filter. Anything you can
+     * write at the TAS top level can go here.
+     *
+     * NOTE: `querySpecifier.filter` is a TAS FILTER, not a TAS
+     * QUERY (no `limit`/`projection`/etc. fields). The parent
+     * NASSQL query's `limit` controls overall row count.
+     */
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        "filter": {
+          "op": "ATTRIBUTE",
+          "expressions": [
+            {
+              "name": "type",
+              "values": ["HOST"],
+              "operator": "IN"
+            }
+          ]
+        }
+      },
+      "alias": "hosts"
+    },
+    /*
+     * Column names from FROM_TOPOLOGY:
+     *   vertex.attr.<attrname>  — any vertex attribute
+     *   vertex.externalId       — canonical string id
+     *   vertex.id               — numeric internal id
+     *   vertex.startTime        — vertex creation timestamp
+     *   vertex.endTime          — vertex deletion timestamp
+     */
+    {
+      "op": "KEEP",
+      "columns": ["vertex.attr.name", "vertex.attr.type", "vertex.externalId"]
+    }
+  ],
+  "limit": 20
+}

package/dist-node/22-nassql-from-topology.nassql.data-store-tmd-vhpjy6c7.json

@@ -0,0 +1,4 @@
+{
+  "description": "FROM_TOPOLOGY: load HOST vertices from the topology into a NASSQL tabular result",
+  "tags": ["nassql", "from_topology"]
+}

package/dist-node/23-nassql-join-topology-metadata.nassql-hywxhcg2.md

@@ -0,0 +1,35 @@
+# 23-nassql-join-topology-metadata (NASSQL)
+
+## Purpose
+
+Demonstrate the full cross-domain pipeline: load topology vertices, join with metric metadata, then aggregate — answering "how many metrics does each agent report?"
+
+## Query Construction
+
+Six-step pipeline:
+1. **FROM_TOPOLOGY**: Load AGENT vertices from TAS
+2. **JOIN_METADATA**: Join each agent vertex with its metric metadata (ALL specifier)
+3. **GROUP**: Group by agent name and type
+4. **COUNT**: Count metrics per agent
+5. **ORDER**: Sort by metric count descending
+6. **KEEP**: Select output columns
+
+## API Surface Exercised
+
+- **FROM_TOPOLOGY** + **JOIN_METADATA**: The fundamental cross-domain join pattern
+- **GROUP + COUNT + ORDER**: Standard aggregation pipeline
+- **KEEP**: Column selection
+
+## Expected Output
+
+Up to 20 rows showing each agent name with its metric count, sorted from most to fewest:
+
+| vertex.attr.name | vertex.attr.type | metric_count |
+|---|---|---|
+| Kubernetes Agent (node-1) | AGENT | 3000+ |
+| Infrastructure Agent | AGENT | 1500+ |
+| ... | ... | ... |
+
+## What the Results Tell You
+
+This pipeline demonstrates the most common real-world pattern: start with topology entities, enrich with metrics, then aggregate for a dashboard view. The `JOIN_METADATA` operation correlates each topology vertex with the metric sources that belong to it (based on the vertex's external ID mapping to metric source paths).

package/dist-node/23-nassql-join-topology-metadata.nassql.data-store-da7q90n2.json5

@@ -0,0 +1,76 @@
+/*
+ * Cross-domain pipeline — load topology rows (FROM_TOPOLOGY), then
+ * JOIN with metric metadata (JOIN_METADATA) to count metrics per
+ * entity. Demonstrates the FROM_<source> + JOIN_<other-source>
+ * pattern that's the workhorse of "things × their metrics" queries.
+ *
+ * Result: one row per agent with the count of metrics that agent
+ * publishes. Use this shape to find noisy agents, coverage gaps,
+ * or to build dashboards that pair topology + metric counts.
+ *
+ * NOTE: this counts METADATA rows (metric definitions per agent),
+ * not DATAPOINTS. For "what value did this metric have last hour"
+ * questions, switch JOIN_METADATA → JOIN_DATA (separate cookbook).
+ */
+{
+  "query": [
+    /*
+     * Source 1: agent vertices.
+     */
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        "filter": {
+          "op": "ATTRIBUTE",
+          "expressions": [
+            {
+              "name": "type",
+              "values": ["AGENT"],
+              "operator": "IN"
+            }
+          ]
+        }
+      },
+      "alias": "agents"
+    },
+    /*
+     * JOIN_METADATA enriches each row with metric metadata for
+     * the corresponding entity. The join key is implicit
+     * (DataStore knows how to match topology vertices to their
+     * metrics). After JOIN_METADATA, columns include both
+     * vertex.attr.* (from FROM_TOPOLOGY) AND metric.* (from
+     * JOIN_METADATA).
+     *
+     * `querySpecifier: { op: ALL }` includes all metrics the
+     * entity publishes; for a narrower join use `op: SPEC` (see
+     * #21 for the regex pattern).
+     */
+    {
+      "op": "JOIN_METADATA",
+      "querySpecifier": { "op": "ALL" },
+      "alias": "agent_metrics"
+    },
+    /*
+     * GROUP by agent — collapses the joined rows back to one
+     * row per agent. This is the "metric count per agent"
+     * shape: one row out per group in.
+     */
+    {
+      "op": "GROUP",
+      "columns": ["vertex.attr.name", "vertex.attr.type"]
+    },
+    {
+      "op": "COUNT",
+      "as": "metric_count"
+    },
+    {
+      "op": "ORDER",
+      "columns": [{ "column": "metric_count", "sortDescending": true }]
+    },
+    {
+      "op": "KEEP",
+      "columns": ["vertex.attr.name", "vertex.attr.type", "metric_count"]
+    }
+  ],
+  "limit": 20
+}

package/dist-node/23-nassql-join-topology-metadata.nassql.data-store-tmd-rr8wt9qa.json

@@ -0,0 +1,4 @@
+{
+  "description": "FROM_TOPOLOGY + JOIN_METADATA: join agent topology with all metrics metadata, group by agent, count metrics per agent",
+  "tags": ["nassql", "from_topology", "join_metadata", "group", "count"]
+}

package/dist-node/24-nassql-from-data-window-mean.nassql-q6qsgdxw.md

@@ -0,0 +1,33 @@
+# 24-nassql-from-data-window-mean (NASSQL)
+
+## Purpose
+
+Demonstrate the `FROM` (data) source operation combined with `WINDOW` and `MEAN` to compute time-windowed averages — the fundamental time-series aggregation pattern.
+
+## Query Construction
+
+Five-step pipeline:
+1. **FROM**: Load actual metric data values (not just metadata) for CPU Utilization metrics from Infrastructure agents
+2. **GROUP**: Group by `metric.source` (one group per agent)
+3. **WINDOW**: Window into 1-hour intervals (`every: 3600000` ms)
+4. **MEAN**: Compute average of `data.value` within each window
+5. **KEEP**: Select source and average
+
+## API Surface Exercised
+
+- **FROM**: Source operation that loads time-series data values (unlike FROM_METADATA which loads only metric registration info)
+- **WINDOW**: Time-based windowing with `every` (milliseconds)
+- **MEAN**: Aggregation operation with `column` and `as`
+- **GROUP**: Must precede WINDOW to define the grouping dimension
+
+The `FROM` columns are: `data.time`, `data.value`, `metric.source`, `metric.path`.
+
+## Expected Output
+
+Rows with `metric.source` and `avg_cpu` for each hour. May return 0 rows if the default query time range has no data for these metrics.
+
+## What the Results Tell You
+
+The `FROM` operation loads actual metric data values (time-series points), not just metadata. Combined with `WINDOW` + aggregation, this enables time-series analytics. The `GROUP` must come before `WINDOW` to establish the grouping key. The pipeline order matters: GROUP → WINDOW → aggregation → KEEP.
+
+Note: `WINDOW` uses `every` (milliseconds), not `windowSizeMs`. For calendar-aligned windows, use `WINDOW_CALENDAR` with `calendarInterval` instead.

package/dist-node/24-nassql-from-data-window-mean.nassql.data-store-j7xmg7fc.json5

@@ -0,0 +1,81 @@
+/*
+ * `FROM` (datapoints) + WINDOW + MEAN — the time-series workhorse.
+ * Where FROM_METADATA returns metric DEFINITIONS (one row per
+ * metric), `FROM` returns DATAPOINTS (one row per metric per
+ * timestamp). Use FROM whenever the question involves values
+ * over time (CPU last hour, latency now, error rate trend).
+ *
+ * `WINDOW + MEAN` is the canonical "average over time bucket"
+ * pattern. Bucket size set by `WINDOW.every` (epoch ms);
+ * 3600000 = 1h. After WINDOW each row has a `time.bucket` column
+ * representing the bucket start.
+ *
+ * NEVER author a FROM-without-time-window for "right now" questions
+ * — the response includes EVERY datapoint in the default range and
+ * scales with metric volume × time. Bound it with a window.
+ */
+{
+  "query": [
+    /*
+     * `FROM` is the datapoints source op. Same querySpecifier
+     * shapes as FROM_METADATA (ALL or SPEC with regex/exact);
+     * here narrowed to Infrastructure-source CPU utilization.
+     *
+     * Default time range is implementation-defined (recent past);
+     * for a custom range, set `time` on the parent envelope.
+     */
+    {
+      "op": "FROM",
+      "querySpecifier": {
+        "op": "SPEC",
+        "sourceNameSpecifier": {
+          "op": "REGEX",
+          "pattern": ".*Infrastructure.*"
+        },
+        "attributeNameSpecifier": {
+          "op": "REGEX",
+          "pattern": ".*CPU.*Utilization.*"
+        }
+      },
+      "alias": "cpu_data"
+    },
+    /*
+     * GROUP by source — collapses to one logical series per
+     * metric source. Required before WINDOW + MEAN if you want
+     * per-source averages (vs a single global average).
+     */
+    {
+      "op": "GROUP",
+      "columns": ["metric.source"]
+    },
+    /*
+     * WINDOW.every is the bucket width in milliseconds:
+     *   60000      = 1 minute
+     *   300000     = 5 minutes
+     *   3600000    = 1 hour
+     *   86400000   = 1 day
+     *
+     * After WINDOW, downstream aggregations (MEAN, SUM, MIN, MAX,
+     * PERCENTILE) operate per bucket per group.
+     */
+    {
+      "op": "WINDOW",
+      "every": 3600000
+    },
+    /*
+     * MEAN per bucket per group. `column: data.value` references
+     * the datapoint value. `as: avg_cpu` names the result column.
+     * Alternatives: SUM, MIN, MAX, MEDIAN, PERCENTILE, STDDEV.
+     */
+    {
+      "op": "MEAN",
+      "column": "data.value",
+      "as": "avg_cpu"
+    },
+    {
+      "op": "KEEP",
+      "columns": ["metric.source", "avg_cpu"]
+    }
+  ],
+  "limit": 50
+}

package/dist-node/24-nassql-from-data-window-mean.nassql.data-store-tmd-qgzz2f7v.json

@@ -0,0 +1,4 @@
+{
+  "description": "FROM (data) + WINDOW + MEAN: get hourly average CPU utilization from Infrastructure agents",
+  "tags": ["nassql", "from", "window", "mean", "aggregation"]
+}

package/dist-node/25-nassql-group-order-top.nassql-awgnwn3r.md

@@ -0,0 +1,30 @@
+# 25-nassql-group-order-top (NASSQL)
+
+## Purpose
+
+Demonstrate the `TOP` shaping operation, which efficiently selects the top N rows by a column value.
+
+## Query Construction
+
+Pipeline: FROM_METADATA → GROUP → COUNT → TOP → KEEP
+
+The `TOP` operation takes:
+- `column`: The column to rank by
+- `n`: How many rows to keep (schema field is `n`, not `count`)
+
+## API Surface Exercised
+
+- **TOP**: Selects the top N rows by a numeric column
+- **GROUP + COUNT**: Standard aggregation producing the ranking column
+
+## Expected Output
+
+Exactly 10 rows: the 10 metric sources with the most metrics, each with `metric.source` and `metric_count`.
+
+Typical top metric sources are things like OpenTelemetry-fed app traffic, Kubernetes agents per cluster, and Infrastructure agents per host — exact ranking and counts depend on what's reporting on the tenant.
+
+## What the Results Tell You
+
+`TOP` is more efficient than `ORDER + LIMIT` for selecting the highest-ranked rows, as it can use partial sorting. The companion operation `BOTTOM` selects the lowest-ranked rows (see query 32).
+
+Schema note: The field is `n` (number), not `count`. This matches the Java source `QueryTopSpec.n`.

package/dist-node/25-nassql-group-order-top.nassql.data-store-cmrn300b.json5

@@ -0,0 +1,48 @@
+/*
+ * `TOP` — efficient "top N rows by column" selection. Compared to
+ * ORDER + LIMIT, TOP can use partial sorting and is the right op
+ * when you specifically want the N highest-ranked rows.
+ *
+ * Pipeline shape: FROM_METADATA → GROUP → COUNT → TOP → KEEP.
+ * Same shape works for any "top N <X> by <metric>" question.
+ *
+ * Schema gotcha: the field is `n` (number of rows), NOT `count`.
+ * Easy to mis-author from intuition. Companion op `BOTTOM` (#32)
+ * works the same way for the lowest-ranked rows.
+ */
+{
+  "query": [
+    {
+      "op": "FROM_METADATA",
+      "querySpecifier": { "op": "ALL" },
+      "alias": "all_metadata"
+    },
+    {
+      "op": "GROUP",
+      "columns": ["metric.source"]
+    },
+    {
+      "op": "COUNT",
+      "as": "metric_count"
+    },
+    /*
+     * TOP keeps the N rows with the HIGHEST values in `column`.
+     * `n` (singular int) — NOT `count`, NOT `top`. The schema
+     * field is exactly `n`. (Java source: QueryTopSpec.n)
+     *
+     * If multiple rows tie for the boundary value, behavior is
+     * implementation-defined; don't depend on which tie-broken
+     * rows make the cut.
+     */
+    {
+      "op": "TOP",
+      "column": "metric_count",
+      "n": 10
+    },
+    {
+      "op": "KEEP",
+      "columns": ["metric.source", "metric_count"]
+    }
+  ],
+  "limit": 10
+}

package/dist-node/25-nassql-group-order-top.nassql.data-store-tmd-7xpqeh7c.json

@@ -0,0 +1,4 @@
+{
+  "description": "GROUP + COUNT + TOP: find the top 10 metric sources by metric count",
+  "tags": ["nassql", "group", "count", "top", "shaping"]
+}

package/dist-node/26-nassql-filter-predicate.nassql-2t27h5ev.md

@@ -0,0 +1,41 @@
+# 26-nassql-filter-predicate (NASSQL)
+
+## Purpose
+
+Demonstrate the `FILTER` operation with a `NUMERIC` predicate spec to filter rows based on computed values.
+
+## Query Construction
+
+Pipeline: FROM_METADATA → GROUP → COUNT → FILTER → ORDER → KEEP
+
+The `FILTER` operation uses a `spec` object:
+```json
+{
+  "op": "NUMERIC",
+  "column": "metric_count",
+  "operator": "GT",
+  "value": 2000
+}
+```
+
+This keeps only sources where `metric_count > 2000`.
+
+## API Surface Exercised
+
+- **FILTER**: Row filtering with predicate specs
+- **NUMERIC predicate**: `{ op: "NUMERIC", column, operator, value }`
+- **NumericOperator**: `GT` (also: `GE`, `LT`, `LE`, `EQ`, `NE`)
+
+Other predicate types available:
+- `IN`: `{ op: "IN", column, values: [...] }`
+- `REGEX`: `{ op: "REGEX", column, pattern, ignoreCase }`
+- `EXPR`: `{ op: "EXPR", spec: "expression_string" }`
+- Boolean: `AND`, `OR`, `NOT` composing other predicates
+
+## Expected Output
+
+Only metric sources with more than 2000 metrics. On a busy tenant a handful of sources usually qualify (OpenTelemetry, Kubernetes agents, etc.); a quiet lab tenant may have none.
+
+## What the Results Tell You
+
+`FILTER` is applied after aggregation, making it equivalent to SQL's `HAVING` clause. It operates on computed columns (like `metric_count` from COUNT), not just source data columns. The predicate spec system supports arbitrary nesting via AND/OR/NOT.

package/dist-node/26-nassql-filter-predicate.nassql.data-store-k2rgp609.json5

@@ -0,0 +1,59 @@
+/*
+ * `FILTER` — row-level filtering with predicate specs. Equivalent
+ * to SQL's `HAVING` when applied after aggregation, or `WHERE`
+ * when applied before. Operates on COMPUTED columns (like
+ * metric_count from COUNT), not just source columns.
+ *
+ * The `spec` field shape is a discriminated union:
+ *   { op: NUMERIC, column, operator: GT|GE|LT|LE|EQ|NE, value }
+ *   { op: IN, column, values: [...] }
+ *   { op: REGEX, column, pattern, ignoreCase }
+ *   { op: EXPR, spec: "<expression string>" }
+ *   { op: AND|OR|NOT, ... }   — compose other predicates
+ *
+ * Default to FILTER for "more than N" / "matches X" / "within
+ * range" questions. Default to TOP/BOTTOM for "highest/lowest N".
+ */
+{
+  "query": [
+    {
+      "op": "FROM_METADATA",
+      "querySpecifier": { "op": "ALL" },
+      "alias": "all_metrics"
+    },
+    {
+      "op": "GROUP",
+      "columns": ["metric.source"]
+    },
+    {
+      "op": "COUNT",
+      "as": "metric_count"
+    },
+    /*
+     * FILTER applied AFTER aggregation = SQL HAVING semantics.
+     * Per-row predicate; rows where the spec evaluates true
+     * pass through.
+     *
+     * NUMERIC operators: GT (>), GE (>=), LT (<), LE (<=),
+     * EQ (=), NE (!=). For string predicates use REGEX.
+     */
+    {
+      "op": "FILTER",
+      "spec": {
+        "op": "NUMERIC",
+        "column": "metric_count",
+        "operator": "GT",
+        "value": 2000
+      }
+    },
+    {
+      "op": "ORDER",
+      "columns": [{ "column": "metric_count", "sortDescending": true }]
+    },
+    {
+      "op": "KEEP",
+      "columns": ["metric.source", "metric_count"]
+    }
+  ],
+  "limit": 50
+}

package/dist-node/26-nassql-filter-predicate.nassql.data-store-tmd-m4dddgwm.json

@@ -0,0 +1,4 @@
+{
+  "description": "FILTER with GT predicate: find metric sources with more than 2000 metrics (heavy data producers)",
+  "tags": ["nassql", "filter", "predicate", "group"]
+}