oh-my-opencode 5.0.0-beta.26 → 5.0.0-beta.28

package/packages/shared-skills/skills/data-scientist/references/execution-surfaces.md

@@ -0,0 +1,91 @@
+# Execution surfaces
+
+How to run the engines on each surface, and when to escalate between them.
+
+## Persistent kernel, JavaScript (Bun)
+
+One-time setup per machine — the bundled script installs `@duckdb/node-api` into a user-level
+cache outside any repo and prints the absolute import path (its only stdout line):
+
+```bash
+bash scripts/ensure-js-deps.sh          # run from the skill directory
+```
+
+In the kernel — top-level `require` may not exist, dynamic import always works:
+
+```js
+const { DuckDBInstance } = await import("<printed path>");
+const db = await DuckDBInstance.create(":memory:");
+const conn = await db.connect();
+const reader = await conn.runAndReadAll("SELECT category, SUM(v) AS total FROM 'data.csv' GROUP BY 1");
+reader.getRowObjects();                  // array of plain row objects
+```
+
+- The connection and any tables created live across cells — connect once per session, reuse.
+- COUNT/SUM over integer columns return BigInt; convert (`Number(x)` or `String(x)`) before
+  `JSON.stringify`, which throws on BigInt.
+- Bun builtins cover ingest gaps with zero installs: `Bun.JSONL.parse`, `Bun.JSON5.parse`,
+  `Bun.XML.parse`, `Bun.TOML.parse`, `Bun.Archive` for tarballs.
+- nodejs-polars is NOT part of this skill's toolkit: its API lags the Python release by
+  major versions (option objects that work in Python throw napi type errors). Polars work
+  belongs to the Python kernel (below).
+
+## Persistent kernel, Python (the default Python surface)
+
+duckdb, numpy, and matplotlib are typically resident — import and use them directly.
+Polars and pyarrow rarely ship with a kernel, so inject them once per session (run from the
+skill directory; the script installs on first use, then just prints the path):
+
+```python
+import subprocess, sys
+site = subprocess.run(["bash", "scripts/ensure-py-deps.sh", sys.executable],
+                      capture_output=True, text=True, check=True).stdout.strip()
+sys.path.insert(0, site)
+import polars as pl
+import pyarrow
+```
+
+- The install goes to a user cache keyed to the kernel's interpreter version; the
+  interpreter itself is never mutated (it is frequently an externally-managed system
+  Python, and mutating it breaks other tools).
+- After injection the whole Python stack is resident: `duckdb.sql(...).pl()` hands off via
+  Arrow, `duckdb.register(name, df)` goes the other way, and Polars lazy pipelines run
+  in-kernel across cells.
+- `duckdb.sql("SELECT ... FROM 'data.csv'")` queries files in place; without the injection,
+  keep results in DuckDB or fetch plain Python values (`.fetchall()`).
+- matplotlib figures render natively in kernels that display rich output; also save a PNG so
+  the artifact survives the session.
+
+## uv lane (fallback and isolation)
+
+```bash
+uv run --with duckdb --with polars --with pyarrow --with numpy python -c "<code>"
+```
+
+- Reach for it when there is no kernel, or when a heavy, crash-prone one-shot should not
+  run inside (and possibly take down) the kernel.
+- Include exactly the packages the code imports, plus pyarrow whenever `.pl()` is used.
+- Each invocation pays process spawn plus imports (roughly 0.3s warm) and re-reads its inputs —
+  fine for one-shots, wasteful for exploration loops.
+- Past a few lines, a temp file beats `-c` quoting: write the script, `uv run script.py`.
+
+## No kernel at all
+
+Same engines, one process per batch of questions:
+
+```bash
+bun -e '<the JavaScript kernel pattern above>'         # DuckDB via @duckdb/node-api
+uv run --with duckdb python -c "<sql via duckdb.sql>"  # DuckDB via Python
+uv run scripts/quick-query.py data.csv "SELECT ..."    # zero-code CLI fallback
+```
+
+## Escalation rules
+
+Start on the resident kernel. Move a step down when a concrete need appears:
+
+- polars/pyarrow missing from the kernel — inject via `ensure-py-deps.sh` (above), not a
+  uv one-shot.
+- Crash-prone or memory-hungry one-shot that should not take the kernel down — uv lane.
+- No kernel on this harness — one-shot recipes above.
+- Data lives remotely or exceeds local RAM — read `placement.md` and move the query, not
+  the data.

package/packages/shared-skills/skills/data-scientist/references/placement.md

@@ -0,0 +1,74 @@
+# Placement: where should this computation live?
+
+Decide before touching the data. Wrong placement wastes minutes (re-scanning a file queried
+ten times) or kills the machine (loading a dataset larger than RAM and swapping).
+
+## The probe (run first, once)
+
+Three facts, one cell or script:
+
+```python
+import os, shutil, subprocess, sys
+size = os.path.getsize("data.csv")            # bytes on disk
+disk_free = shutil.disk_usage(".").free       # spill headroom
+if sys.platform == "darwin":
+    ram = int(subprocess.run(["sysctl", "-n", "hw.memsize"], capture_output=True, text=True).stdout)
+else:
+    ram = os.sysconf("SC_PAGE_SIZE") * os.sysconf("SC_PHYS_PAGES")
+# row estimate without loading (DuckDB streams the scan):
+# duckdb.sql("SELECT count(*) FROM 'data.csv'")
+```
+
+CSV typically expands 2-5x in memory (string columns dominate); Parquet expands less
+predictably — compressed columns can inflate 10x. Estimate the working set from the
+decompressed size of the columns the question actually touches, not the file size.
+
+## In memory — load once, iterate
+
+When the working set stays within roughly 25% of free RAM AND the session will run repeated
+queries: load once (`CREATE TABLE t AS SELECT ...` in DuckDB, or a collected DataFrame),
+then iterate. One scan up front converts every later query from a file re-scan into
+milliseconds. Prune at load time — select only the needed columns, filter obvious dross —
+so the resident table is the working set, not the raw file.
+
+## In place / streaming — single pass, or bigger than RAM
+
+- Single-pass questions: query the file directly (`FROM 'data.csv'`). Loading first is pure
+  waste.
+- Bigger than RAM, SQL-shaped: cap DuckDB and let it spill —
+
+  ```sql
+  SET memory_limit = '4GB';
+  SET temp_directory = '/tmp/duckdb_spill';
+  ```
+
+  Aggregations, sorts, and window functions run out-of-core: slower, but bounded.
+- Bigger than RAM, DataFrame-shaped: Polars streaming (`collect(engine="streaming")` on a
+  lazy plan) in the resident kernel — or a uv one-shot on kernel-less harnesses.
+- Manual chunked loops (read N rows, process, repeat) are the last resort — the engines'
+  own out-of-core paths are faster and simpler than hand-rolled chunking.
+
+## Remote, in place — move the query to the data
+
+- Files behind http(s)/S3: DuckDB's httpfs extension reads Parquet and CSV remotely with
+  projection and predicate pushdown —
+
+  ```sql
+  INSTALL httpfs; LOAD httpfs;   -- one-time per environment
+  SELECT region, SUM(amount) FROM 'https://example.com/sales.parquet'
+  WHERE sale_date >= '2026-01-01' GROUP BY region;
+  ```
+
+  Only matching row groups and referenced columns cross the network, not the file.
+- Data on another machine you can execute on (a remote worker with more RAM, a box closer
+  to the data): run the query there and return the aggregate. A group-by result is
+  kilobytes; the source is gigabytes.
+- Decision rule: result much smaller than data — move the query. Repeated local iteration
+  on one slice — move a pruned copy of that slice once, then work locally in memory.
+
+## Hardware notes
+
+- Both engines parallelize across all cores by default; leave that alone except on shared
+  machines (`SET threads = N` in DuckDB, `POLARS_MAX_THREADS` for Polars).
+- Sustained swapping is the failure mode to avoid on memory-tight machines: when the probe
+  says the working set is close to free RAM, choose streaming, not hope.

package/packages/shared-skills/skills/data-scientist/references/polars-lane.md

@@ -0,0 +1,95 @@
+# Polars lane (resident Python kernel)
+
+When the work is DataFrame-shaped, Polars is the right engine — and it runs in the resident
+Python kernel by default. Kernels rarely ship polars/pyarrow preinstalled, so inject them
+once per session; the install lands in a user cache keyed to the kernel's interpreter, and
+the interpreter itself is never mutated (run with the skill directory as cwd, or spell out
+the script's absolute path):
+
+```python
+import subprocess, sys
+site = subprocess.run(["bash", "scripts/ensure-py-deps.sh", sys.executable],
+                      capture_output=True, text=True, check=True).stdout.strip()
+sys.path.insert(0, site)
+import polars as pl
+```
+
+After this, Polars lives across cells like every other resident engine: lazy frames,
+intermediate results, and the DuckDB handoff all persist with no per-call process cost.
+
+## When Polars wins over DuckDB SQL
+
+- Expression-chain transforms: many derived columns, per-column conditional logic, string
+  pipelines — `with_columns` chains read and optimize better than nested SQL SELECTs.
+- Reshapes: `unpivot`/`pivot` beat SQL gymnastics.
+- Larger-than-RAM pipelines: the streaming engine executes lazy plans in chunks.
+- Window-heavy feature engineering with `over()`.
+
+SQL-shaped work (joins, aggregation, ad-hoc questions) stays in DuckDB; mixed pipelines hand
+off zero-copy (below) instead of forcing one engine to do everything.
+
+## Current API (1.x) — older spellings fail or warn
+
+Training data is full of the pre-1.0 API. Current names:
+
+| Use | Not |
+| --- | --- |
+| `pl.scan_csv` / `pl.scan_parquet` + `.collect()` | eager `read_*` on big files |
+| `.group_by(...)` | `.groupby(...)` |
+| `pl.len()` | `pl.count()` |
+| `.collect(engine="streaming")` | `.collect(streaming=True)` |
+| `.unpivot(...)` | `.melt(...)` |
+
+Lazy first: `scan_*` builds a plan, pushes filters and projections down to the file read, and
+executes once at `.collect()`. Eager `read_*` is for small files mutated interactively.
+
+```python
+out = (pl.scan_csv("data.csv")
+       .filter(pl.col("value") > 100)
+       .group_by("category")
+       .agg(pl.col("value").sum().alias("total"), pl.len().alias("n"))
+       .sort("total", descending=True)
+       .collect())
+```
+
+## Zero-copy handoff with DuckDB
+
+Both engines speak Arrow, so mixed pipelines pay no serialization cost — all in-kernel:
+
+```python
+import duckdb
+df = duckdb.sql("SELECT * FROM 'orders.csv' o JOIN 'items.csv' i USING (id)").pl()
+shaped = df.with_columns((pl.col("qty") * pl.col("price")).alias("rev"))
+duckdb.register("shaped", shaped)
+out = duckdb.sql("SELECT category, SUM(rev) AS total FROM shaped GROUP BY 1").pl()
+```
+
+- `.pl()` requires pyarrow — the injection above provides it; without it, it raises
+  `ModuleNotFoundError`.
+- Never `.df()`: it requires pandas (raising without it), and pandas is banned and absent.
+
+## Streaming past RAM
+
+```python
+out = (pl.scan_parquet("huge.parquet")
+       .filter(pl.col("status") == "active")
+       .group_by("region").agg(pl.len())
+       .collect(engine="streaming"))
+```
+
+Streaming executes lazy plans only — keep the plan lazy end-to-end, with no intermediate
+`.collect()` breaking it into eager pieces.
+
+## Kernel-less fallback (uv one-shot)
+
+On a harness with no persistent kernel, the same code runs as one-shots — batch several
+questions per process, since each invocation pays spawn plus imports:
+
+```bash
+uv run --with duckdb --with polars --with pyarrow python -c "
+import duckdb
+import polars as pl
+df = duckdb.sql(\"SELECT * FROM 'data.csv'\").pl()
+print(df.group_by('category').agg(pl.len()).sort('category'))
+"
+```

package/packages/shared-skills/skills/data-scientist/references/uv-setup.md

@@ -1,6 +1,6 @@
 # uv Setup — Per-Platform
 
-This skill runs every data operation through `uv run --with ...`. If `uv --version` fails, set uv up with the automated scripts or the manual commands below, then verify.
+This skill's uv lane (kernel-less harnesses, isolated one-shots) runs through `uv run --with ...`, and `scripts/ensure-py-deps.sh` uses uv as its installer. If `uv --version` fails, set uv up with the automated scripts or the manual commands below, then verify.
 
 ## Automated (recommended)
 

package/packages/shared-skills/skills/data-scientist/references/visualization.md

@@ -0,0 +1,64 @@
+# Visualization
+
+A chart exists to answer a question at a glance. Render it with matplotlib (resident in most
+Python kernels; `uv run --with matplotlib` otherwise), then look at it before delivering —
+a chart nobody inspected is not evidence.
+
+## When to chart
+
+Chart when the user asked for one, and default to charting when the answer is a shape prose
+cannot carry: a trend over time, a distribution, a comparison across many categories, a
+relationship between variables. Skip the chart when a number or a five-row table answers the
+question — decoration dilutes the answer.
+
+## Chart type follows the question
+
+| Question shape | Chart |
+| --- | --- |
+| How did X change over time? | line, datetime x-axis |
+| Which categories are biggest? | horizontal bar, sorted by value |
+| How is X distributed? | histogram (tune bin count) or box plot per group |
+| Is X related to Y? | scatter; add a trend line only when it aids the eye |
+| Composition of a whole? | stacked or 100% bar — pie only for four or fewer slices |
+| Many series over time? | small multiples over one spaghetti chart |
+
+## Quality bar — every chart
+
+- Title states the finding ("Seoul overtook Busan in March"), not the dataset name.
+- Axis labels carry units. Tick density stays readable: `fig.autofmt_xdate()` for dates,
+  rotate or abbreviate long category names.
+- Size for the medium: inline chat reads well around `figsize=(10, 6)` at default dpi;
+  documents want `dpi=150` or more at export.
+- `tight_layout()` (or `constrained_layout=True`) before saving — clipped labels are the
+  most common chart defect.
+- Few series: label lines directly, or keep the legend inside empty plot space. Many
+  series: gray the context, color only the series that answers the question.
+- The default color cycle is fine; avoid rainbow palettes and 3D. Sort categorical bars by
+  value, never alphabetically.
+
+## CJK and other non-Latin text
+
+Matplotlib's default font renders CJK as empty boxes (tofu). Set a fallback before plotting
+whenever any label or title contains CJK:
+
+```python
+import platform
+import matplotlib
+cjk = {"Darwin": "AppleGothic", "Windows": "Malgun Gothic"}.get(platform.system(), "Noto Sans CJK KR")
+matplotlib.rcParams["font.family"] = [cjk, "DejaVu Sans"]
+matplotlib.rcParams["axes.unicode_minus"] = False   # keeps the minus sign rendering
+```
+
+## Output contract
+
+1. Save a PNG next to the work: `plt.savefig(path, dpi=150, bbox_inches="tight")`.
+2. Also render inline when the surface displays rich output (kernels usually do).
+3. Report the file path together with the answer.
+
+## Visual QA — mandatory
+
+Open the produced image — kernel display, or the harness's image-reading surface — and
+check four things: labels readable and unclipped, no tofu or mojibake, nothing overlapping,
+and the chart actually shows the finding the title claims. A failed check means fix and
+re-render, not ship with a caveat. This one pass catches nearly every chart defect;
+skipping it is how tofu titles reach users.

package/packages/shared-skills/skills/data-scientist/scripts/ensure-js-deps.sh

@@ -0,0 +1,28 @@
+#!/usr/bin/env bash
+# Install @duckdb/node-api into a user-level cache (outside any repo) and print the
+# absolute import path as the ONLY stdout line. Idempotent: re-runs reuse the install.
+set -euo pipefail
+
+log() { printf '[ensure-js-deps] %s\n' "$*" >&2; }
+
+CACHE_DIR="${OMO_DATA_SCIENTIST_CACHE:-$HOME/.cache/omo-data-scientist}"
+IMPORT_PATH="$CACHE_DIR/node_modules/@duckdb/node-api/lib/index.js"
+
+if ! command -v bun >/dev/null 2>&1; then
+  log "bun is required (https://bun.sh); install it, or use the uv lane instead."
+  exit 1
+fi
+
+if [ ! -f "$IMPORT_PATH" ]; then
+  log "installing @duckdb/node-api into $CACHE_DIR"
+  mkdir -p "$CACHE_DIR"
+  [ -f "$CACHE_DIR/package.json" ] || printf '{"name":"omo-data-scientist-cache","private":true}\n' > "$CACHE_DIR/package.json"
+  (cd "$CACHE_DIR" && bun add @duckdb/node-api 1>&2)
+fi
+
+if [ ! -f "$IMPORT_PATH" ]; then
+  log "install finished but $IMPORT_PATH is missing; inspect $CACHE_DIR"
+  exit 1
+fi
+
+printf '%s\n' "$IMPORT_PATH"

package/packages/shared-skills/skills/data-scientist/scripts/ensure-py-deps.sh

@@ -0,0 +1,37 @@
+#!/usr/bin/env bash
+# Install polars + pyarrow for a given Python interpreter into a user-level cache
+# (never mutating the interpreter itself) and print the site directory as the ONLY
+# stdout line. Idempotent: re-runs reuse the install. arg1 = python executable
+# (default: python3); pass the kernel's sys.executable for kernel use.
+set -euo pipefail
+
+log() { printf '[ensure-py-deps] %s\n' "$*" >&2; }
+
+PYTHON_BIN="${1:-python3}"
+
+if ! command -v uv >/dev/null 2>&1; then
+  log "uv is required (see references/uv-setup.md); install it first."
+  exit 1
+fi
+if ! command -v "$PYTHON_BIN" >/dev/null 2>&1 && [ ! -x "$PYTHON_BIN" ]; then
+  log "python executable not found: $PYTHON_BIN"
+  exit 1
+fi
+
+TAG="$("$PYTHON_BIN" -c 'import sys; print(f"cp{sys.version_info[0]}{sys.version_info[1]}")')" \
+  || { log "not a working python interpreter: $PYTHON_BIN"; exit 1; }
+CACHE_DIR="${OMO_DATA_SCIENTIST_CACHE:-$HOME/.cache/omo-data-scientist}"
+SITE_DIR="$CACHE_DIR/py-$TAG"
+
+if [ ! -d "$SITE_DIR/polars" ] || [ ! -d "$SITE_DIR/pyarrow" ]; then
+  log "installing polars + pyarrow for $TAG into $SITE_DIR"
+  mkdir -p "$SITE_DIR"
+  uv pip install --python "$PYTHON_BIN" --target "$SITE_DIR" polars pyarrow 1>&2
+fi
+
+if [ ! -d "$SITE_DIR/polars" ]; then
+  log "install finished but $SITE_DIR/polars is missing; inspect $SITE_DIR"
+  exit 1
+fi
+
+printf '%s\n' "$SITE_DIR"

package/packages/shared-skills/skills/ulw-research/SKILL.md

@@ -161,7 +161,9 @@ Record the answer in the journal; Phase 5 opens by turning it into `design-spec.
 
 ## Phase 1 — Saturation wave
 
-Launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
+**When the user asked for MASS research, the wave is sized by the topic's angles, not by the roster ceiling.** "mass ulw research", "mulw research", "ulw mass research" — in any language — order over-collection that a team of 8 cannot produce. Where the harness has a dependency-graph surface (the `mass-ulw` skill and its `references/planning.md`), run collection through it instead: a 60+ node opening wave covering every angle the topic has, routed across the whole difficulty ladder in one graph — mechanical sweeps and per-item harvest batches on the cheapest tier, judgment-shaped angles a step up, cross-territory angles a step above that, and the deepest tier reserved for genuinely hairy contradictions. Each wave's EXPAND leads define the next wave's nodes, and the synthesis reduces through several parallel architect-tier nodes into ONE architect-tier reducer (the strongest reasoning tier substitutes wherever no architect tier exists). Absent that surface, hold the same shape with background workers in batched waves. Everything else in this skill still binds: the format gate, the journal, the claim graph, the convergence rules, and the delivery gates.
+
+Otherwise launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
 
 Scaling floor — more angles always justify more workers:
 

package/dist/skills/data-scientist/references/common-scenarios.md

@@ -1,176 +0,0 @@
-# Common Scenarios with Tool Selection
-
-## Scenario 1: Simple Calculation
-
-**Decision: Python (always)**
-
-```python
-uv run --with numpy python -c "
-import numpy as np
-result = np.sum([1, 2, 3, 4, 5])
-print(f'Result: {result}')
-"
-```
-
-## Scenario 2: CSV Quick Analysis
-
-**Decision: DuckDB (direct query, no memory load)**
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-result = duckdb.sql('''
-    SELECT * FROM 'data.csv'
-    LIMIT 10
-''').pl()
-print(result)
-"
-```
-
-## Scenario 3: Filter + Sort on Large Dataset
-
-**Decision: Polars (128x faster filtering, 12x faster sorting)**
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-result = (
-    pl.scan_csv('large.csv')
-    .filter(pl.col('value') > 1000)
-    .sort('value', descending=True)
-    .head(100)
-    .collect()
-)
-print(result)
-"
-```
-
-## Scenario 4: Multi-Table Join + Aggregation
-
-**Decision: DuckDB (best for joins and aggregations)**
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-result = duckdb.sql('''
-    SELECT
-        a.category,
-        COUNT(*) as count,
-        SUM(b.amount) as total
-    FROM 'table1.csv' a
-    JOIN 'table2.csv' b ON a.id = b.id
-    GROUP BY a.category
-    ORDER BY total DESC
-''').pl()
-print(result)
-"
-```
-
-## Scenario 5: Data Exploration
-
-**Decision: DuckDB for quick exploration**
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-
-# Show first few rows
-print('**Sample Data**')
-print(duckdb.sql('SELECT * FROM \"data.csv\" LIMIT 5').pl())
-
-# Show summary statistics
-print('\\n**Summary Statistics**')
-print(duckdb.sql('DESCRIBE SELECT * FROM \"data.csv\"').pl())
-
-# Show row count
-print('\\n**Row Count**')
-print(duckdb.sql('SELECT COUNT(*) as total_rows FROM \"data.csv\"').pl())
-"
-```
-
-## Scenario 6: Time-Series Analysis
-
-**Decision: DuckDB for aggregation + matplotlib for visualization**
-
-```python
-uv run --with numpy --with duckdb --with pyarrow --with matplotlib python -c "
-import duckdb
-import matplotlib.pyplot as plt
-
-# Aggregate by date
-result = duckdb.sql('''
-    SELECT
-        DATE_TRUNC('day', timestamp) as date,
-        COUNT(*) as count,
-        AVG(value) as avg_value
-    FROM 'timeseries.csv'
-    GROUP BY date
-    ORDER BY date
-''').pl()
-
-# Plot
-plt.figure(figsize=(12, 6))
-plt.subplot(2, 1, 1)
-plt.plot(result['date'], result['count'])
-plt.title('Daily Count')
-
-plt.subplot(2, 1, 2)
-plt.plot(result['date'], result['avg_value'])
-plt.title('Daily Average Value')
-
-plt.tight_layout()
-plt.savefig('timeseries.png')
-print('Saved to timeseries.png')
-"
-```
-
-## Scenario 7: Complex Transformation
-
-**Decision: Polars for efficient transformations**
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-result = (
-    pl.scan_csv('data.csv')
-    .with_columns([
-        # Create new calculated columns
-        (pl.col('price') * pl.col('quantity')).alias('total'),
-        pl.col('date').str.strptime(pl.Date, '%Y-%m-%d').alias('parsed_date'),
-        pl.col('name').str.to_uppercase().alias('upper_name'),
-    ])
-    .filter(pl.col('total') > 100)
-    .select(['parsed_date', 'upper_name', 'total'])
-    .collect()
-)
-
-print(result)
-"
-```
-
-## Scenario 8: Large File Processing
-
-**Decision: Polars streaming mode**
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-# Process file larger than RAM
-result = (
-    pl.scan_csv('huge_file.csv')
-    .filter(pl.col('active') == True)
-    .groupby('category')
-    .agg([
-        pl.count().alias('count'),
-        pl.sum('amount').alias('total'),
-        pl.mean('amount').alias('average'),
-    ])
-    .collect(streaming=True)  # Streaming mode
-)
-
-print(result)
-print(f'\\nProcessed {result[\"count\"].sum():,} rows')
-"
-```