@pond-ts/react 0.53.1 → 0.54.0

package/CHANGELOG.md

@@ -4,11 +4,12 @@ All notable changes to this project are documented here.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 The `@pond-ts` packages — `pond-ts`, `@pond-ts/react`, `@pond-ts/charts`,
-`@pond-ts/fit`, and `@pond-ts/financial` — release together under a single `v*`
-tag, so this file covers them all. Pre-1.0: minor bumps may include new features
-and type-level changes; patch bumps are strictly additive.
+`@pond-ts/fit`, `@pond-ts/financial`, and `@pond-ts/process` — release together
+under a single `v*` tag, so this file covers them all. Pre-1.0: minor bumps may
+include new features and type-level changes; patch bumps are strictly additive.
 
-[Unreleased]: https://github.com/pond-ts/pond/compare/v0.53.1...HEAD
+[Unreleased]: https://github.com/pond-ts/pond/compare/v0.54.0...HEAD
+[0.54.0]: https://github.com/pond-ts/pond/compare/v0.53.1...v0.54.0
 [0.53.1]: https://github.com/pond-ts/pond/compare/v0.53.0...v0.53.1
 [0.53.0]: https://github.com/pond-ts/pond/compare/v0.52.0...v0.53.0
 [0.52.0]: https://github.com/pond-ts/pond/compare/v0.51.0...v0.52.0
@@ -54,6 +55,865 @@ and type-level changes; patch bumps are strictly additive.
 
 ## [Unreleased]
 
+## [0.54.0] — 2026-08-02
+
+### Added
+
+- **`ctx.out` — prepared output buffers for a ranged recompute**
+  ([PND-PROCRANGE]), plus `prepareRange` / `sealRange` / `RangeOutput` on the
+  package surface. An op writes only `[from, to)` and returns nothing; the
+  rows it keeps arrive already copied, **values and validity both**.
+
+  500k rows × 5 studies: **209 → 6.5 ms/tick, 32×**, bit-identical to a
+  from-scratch pass every tick. The mechanism shipped at 4× because the
+  example op rebuilt its whole output, carrying the prefix with a `.at(i)`
+  per cell into a boxed `Array`.
+
+  **The contract exists because the obvious shortcut is silently wrong.**
+  Copying the prefix as a typed-array block gets 13× — and 1,875 wrong
+  cells, because packed storage holds `0` at a missing cell rather than
+  `NaN`, so every warm-up gap becomes a defined zero. Nothing in the type
+  system objects. Validity has to move with the values, and doing that per
+  cell is the `O(n)` walk the ticket exists to remove — so the graph
+  prepares both as blocks and an op cannot get it wrong by omission.
+  `previousView` is also exposed for ops that want to read the prior
+  output directly.
+
+- **Ranged recompute** ([PND-PROCRANGE]): `graph.setSourceFrom(series,
+changedFrom)` declares which row first changed, and an op opts in with
+  `OpDef.runRange(ctx)` — which receives `{ from, to, previous }` and rebuilds
+  only that slice. `graph.recomputes` reports `{ ranged, full }`.
+
+  **The previous output is an argument, not state.** Letting a node reach for
+  its own last output would make `compute` a function of history: two callers
+  with the same data but different edit sequences could disagree, and
+  `explain` would stop describing what a value depends on. Passing it in keeps
+  the op a pure function of declared inputs; the mutable part stays in the
+  graph, which is a cache and was already stateful.
+
+  **It is opt-in because it is only safe for some ops.** An incremental result
+  must be _bit-identical_ to a from-scratch one, or answers start depending on
+  the sequence of edits that produced them — invisible to any test that only
+  computes from scratch. That holds for [PND-PROCKERN]'s range-exact kernel
+  and does **not** hold for `median`, percentiles, `min` or `max`, which still
+  sweep whole-series. An op that declares nothing gets full recomputes: always
+  correct, merely slower.
+
+  Measured 500k rows, 5 studies, 20 ticks: **209 → 55 ms/tick (4×)**, verified
+  bit-identical against a from-scratch pass every tick. That is short of the
+  plan's 26×, and the gap is in the _op_, not the graph — a `runRange` that
+  copies the whole prefix out of `previous` before patching is `O(n)` per
+  tick. Reaching the projected ceiling needs a capacity-buffer contract
+  letting an op _extend_ the previous column instead of rebuilding it.
+
+  For scale: [PND-PROCHIST] answers the same hot-edge workload at ~1.3 ms/tick
+  by slicing, with no incremental machinery. Ranging earns its keep where the
+  whole column must stay materialized — a chart drawing every point while one
+  row arrives.
+
+- **An engine-wide byte budget over retained node values** ([PND-PROCCACHE]):
+  `bind(series, { registry, budgetBytes })`, plus `graph.retainedBytes`,
+  `graph.evictions` and `graph.enforceBudget()`. Unbounded when omitted, so
+  no existing caller changes behaviour.
+
+  Every distinct spec ever compiled was retained forever, so memory scaled
+  with _questions asked_. A session walking a slider from period 20 to 200
+  left 180 nodes holding 180 result columns and dropped none. 60 distinct
+  params × 200k rows, each configuration in its own process:
+  **arrayBuffers 104 → 42 MB** (2.5×), retained 93 → 11 MB, 60 nodes → 7 —
+  while a repeat-heavy sweep still hits, with no eviction churn and no
+  measurable penalty. Both halves matter: a budget that bounds memory by
+  discarding what the caller asks for next is not a cache.
+
+  **No `rss` figure is quoted, deliberately.** An earlier draft claimed
+  5.6× on rss; that was a measurement-order artifact — two configurations
+  timed in one process, the second starting from the first's heap, and
+  reversing them inverted the result. Forking a process per configuration
+  fixed the ordering, but the replacement 1.2× did not survive either:
+  across five forked pairs, bounded rss exceeded unbounded in two. Freed
+  buffers are not promptly returned to the OS and the bound series is the
+  floor, so rss cannot support a direction here at this scale.
+  `arrayBuffers` and `retainedBytes` can, and are what the benchmark
+  reports.
+
+  The ticket framed this as an op-level cache where an op declares which
+  inputs key its result. **Half of that is already true and was not
+  rebuilt** — `specId` is content-addressed over op, params and inputs, so
+  asking the same question twice hits the same node by construction, and a
+  per-op key would be a second key beside a correct one. What was missing is
+  the capacity, and the ticket is right that it cannot belong to the op: a
+  per-op cap is a per-op promise, and nothing supervises the total.
+
+  Bounded in **bytes**, resolving the ticket's open question. Entries are not
+  the unit anyone has a limit in — one node over 1M rows outweighs fifty over
+  5,000 — and bytes only became knowable once [PND-PROCCOL] made node values
+  columns with a reportable `columnBytes`. Eviction is LRU with one
+  constraint: a node whose consumer still holds its outlet is skipped,
+  because dropping it frees nothing and forces a recompile.
+
+- **`requiredHistory(registry, plan)` in `@pond-ts/process`** ([PND-PROCHIST]),
+  with a per-op `OpDef.lookback`. The hot leading edge is the design's worst
+  cliff — an 8-study stack over 500k rows costs ~100 ms/tick — and the fix is
+  to slice a tail, which until now was the consumer's guess. The registry
+  already knows every op's lookback, so the minimum safe tail is derivable.
+
+  Measured on that stack: **97 → 1.3 ms/tick, 75×** (10 → 773 ticks/sec), with
+  **zero truncated cells** at the derived tail and **exactly one** at a tail
+  one row shorter. The bound is tight, not merely safe.
+
+  Two things it is careful about. Lookbacks **sum along a nested chain** —
+  `sma(20)` over `sma(50)` needs 69 rows, not 50, and taking the max
+  under-provisions in the way that produces defined, plausible, truncated
+  answers. And an op that declares no lookback yields `known: false` naming
+  it, rather than a number: a missing declaration and a genuinely
+  element-wise op are the same value with opposite meanings, so an
+  element-wise op should say `() => 0`.
+
+  Slicing a tail gives answers that agree to **≤5.8e-13**, not bit-for-bit.
+  An `ema` lookback (`4 × period`) is an approximation by construction, and
+  slicing builds a new shorter series, which re-indexes every row — the
+  rolling kernel pins its rebuilds to absolute row index, so
+  [PND-PROCKERN]'s bit-identity covers a range of the _same_ column, not a
+  re-indexed copy.
+
+- **`columnView(column)` in `@pond-ts/process` — a zero-copy read view over a
+  packed numeric column** ([PND-PROCCOL]), and `FoldContext.numeric(role)`,
+  which hands one to a fold. `values` and `bits` are `subarray`s of the
+  column's own storage: read, never retain.
+
+  `FoldContext.values` — the boxed `(number | undefined)[]` — is now a **lazy
+  getter** rather than eagerly densified, so a fold that never touches it
+  never allocates. It was the graph's largest heap cost, and `last` reads a
+  single cell while paying to densify 500,000 of them.
+
+  20 folds × 500k rows, `scripts/perf-proccol.mjs`:
+
+  |              | boxed  | columnar   |
+  | ------------ | ------ | ---------- |
+  | warm run     | 606 ms | **383 ms** |
+  | heap at peak | 35 MB  | **25 MB**  |
+  | rss          | 204 MB | **173 MB** |
+
+  Read that as a fold-shape result, not a representation result. **Columnar
+  is not faster to read** — a buffer walk reaches parity with a boxed array,
+  and `Column.scan()` is 4.7× slower than either because it takes a callback
+  per cell. The 1.58× is the densify disappearing for folds that read a few
+  cells. A fold that walks the whole column should expect parity, and gets
+  the memory win only.
+
+- **charts:** **`<LineChart readout>` / `<AreaChart readout>` — the tracked
+  value, decoupled from the plotted one** ([PND-READOUT]). Name a **second
+  column** and its value rides each tracker sample as the new
+  `TrackerSample.readout`, while the layer keeps plotting `column`. Plotting a
+  _derived_ series but reading the _source_ number is common — a log,
+  normalized, unit-transformed or smoothed line whose readout should show the
+  raw sample — and until now a consumer had to reconstruct that off-chart from
+  its own data. (Motivating case: estela's DATA chart plots pace-space,
+  Gaussian-smoothed, but the scrub readout wants the native m/s formatted as
+  pace.)
+
+  `value` is unchanged, so **the in-chart cursor dot still sits on the plotted
+  value** — as it must, or the dot would leave the line. In-chart flag / inline
+  chips likewise keep showing the plotted number; `readout` is for the
+  off-chart consumer, which shows `readout ?? value`. **Additive**: omit
+  `readout` and every sample is identical to before.
+
+  A mistyped `readout` throws the readers' `RangeError` / `TypeError` on
+  **both** axis kinds, rather than throwing on a value axis and silently
+  producing no readout on a time axis.
+
+- **charts:** **single-series bars gained the stable per-bar `mark` identity**
+  the categorical stack already had. `<BarChart series column>`'s `hitTest` now
+  echoes a `SelectInfo.mark` — the bar's **own axis key**, stringified — and a
+  controlled `selected` / `hovered` carrying a `mark` matches on that name
+  instead of the bar's `key`. This closes a gap on **point-keyed** series,
+  where the bar span is synthesized from neighbour spacing so its `key` is a
+  _derived_ edge (`t - halfGap`), not the sample's time: pinning a selection
+  previously meant re-deriving that geometry, and now a caller matches on the
+  centre it already owns. The readers (`barsFromTimeSeries` /
+  `barsFromValueSeries`) supply the identity, exposed as the new optional
+  `BarSeries.marks`.
+
+  **The match rule is strictly additive.** A selection with no `mark` — every
+  one that exists today — still matches on the `key`, so key-pinned controlled
+  selections are untouched. (A deliberate divergence from `drawStacks`, which
+  switches on the _series_ carrying marks rather than the _selection_; bars have
+  shipped key-pinning, category stacks never did.) The **payload** does change,
+  additively: an interactive single-series bar's `SelectInfo` now carries a
+  `mark` where it previously carried none, so a consumer that round-trips a hit
+  back as a controlled `selected` pins by mark rather than key. Both resolve to
+  the same bar.
+
+  `marks` build lazily and memoize (~9 ms per 100k bars, on a ~0.8 ms reader).
+  A **non-interactive** layer never reads them; an **interactive** one echoes
+  the hovered bar's mark from `hitTest` on every pointer move, so its first
+  hover over a bar materializes the array — once per data identity, on the input
+  path (11.1 ms cold vs 1.7 ms warm, at 100k). Bounded and paid once, where an
+  eager array would charge every chart on every data update.
+  `scripts/perf-barmarks.mjs` pins both halves.
+
+- **`parallelDispatches()`** in `@pond-ts/financial/parallel` — how many rolling
+  passes have actually run on worker threads. `withWorkers` is a silent no-op
+  when the pool declines a series, and a declined pass returns the same answer,
+  just slower than the caller expected; this is how you check. It also replaces
+  a test canary that had proved the parallel path ran _by it being wrong_ —
+  which stopped working the moment the wrongness was fixed.
+
+- **financial:** **`withWorkers` (`@pond-ts/financial/parallel`) — rolling
+  studies partitioned across worker threads** ([PND-SCANKERN], Node-only,
+  opt-in). A rolling window is not a recurrence: output cell `i` reads only
+  rows `[i-period+1, i]`, so the output splits into ranges with a `period-1`
+  overlap and no communication between workers.
+
+  **Opt in once, at ingest** — `withWorkers(bars, { workers: 8 })` returns the
+  series unchanged, and every rolling study over it (or over anything derived
+  from it) is partitioned from then on. The studies keep their signatures and
+  stay **synchronous**: `Atomics.wait` lets the main thread dispatch and join
+  without yielding, which is also why this is Node-only and simply absent in a
+  browser. **Single-threaded is unchanged and remains the default**; the main
+  package never imports this entry point.
+
+  Measured over 500k bars, 8 workers: `sma` **1.83×**, `bollinger` **1.86×**,
+  `zScore` **2.45×**, a three-study stack **1.98×**.
+
+  **It changes the answer, and how much depends on the study.** Chunk 0
+  reproduces the sequential sweep exactly; later chunks start their Welford
+  state fresh. `sma`, `envelope` and `bollinger` shift by rounding error
+  (3.9e-14, 3.9e-14, 5.1e-13 observed; no cell beyond 1e-9).
+
+  **`zScore` is different in kind, not degree** — though not for the reason
+  first published here. The divergence is **catastrophic cancellation in the
+  numerator**, not the division by σ: at the worst row, σ differs by 0.97%
+  while `v − mean` differs by 60%, because `ulp(1e15)` is `0.125` and a window
+  spanning ±3 covers ~48 ulps. The sequential study computes the same
+  subtraction and carries the same exposure; partitioning only perturbs it.
+  A shifted-frame formulation removes it (650% → 8.8e-15, prototyped in
+  `spikes/shifted-frame/`, tracked as [PND-SHIFTFRAME]).
+  On a benign random walk the difference is ~2.6e-6 across ~0.8% of cells; on
+  a legal near-flat series at large magnitude it is **38%** (counterexample
+  from a Codex review, now a regression test). Do not opt in if you threshold
+  z-scores, reproduce the pandas oracle, or work with near-constant series.
+  Related: core rejects a non-finite rolling result, where this kernel can
+  emit `Infinity` or clamp a `NaN` variance to zero.
+
+  Below `MIN_ROWS` (100k) a registered series still runs sequentially and is
+  bit-identical.
+
+- **process:** **`HostPool` (`@pond-ts/process/pool`) — whole requests across
+  resident worker threads** ([PND-PROCPAR], Node-only). N workers, each holding
+  a long-lived `Host`, with the pool as a router: a plan is already JSON, a
+  registry is a module both isolates import (functions cannot be structured-
+  cloned, so the caller names a `setup` module rather than passing a value),
+  and a result's columns cross as transferable buffers. No engine change.
+
+  Measured (`packages/process/scripts/perf-pool.mjs`, 32 requests/batch,
+  8 workers, median of 3 distinct batches): **3.1–4.0× on distinct requests**
+  at every size from 0.5 ms to 10 ms each, and **~0.01× on repeated ones**.
+  What decides it is the cache-hit rate, not request size — in-process, a
+  re-asked question is a memo hit returning the same column for nothing, while
+  a pool copies and ships every answer however cheap it was, and each worker
+  warms its own graph. Pooling and caching compete rather than compose.
+
+  Worth checking before reaching for it: the same rolling mean writing a
+  `Float64Array` instead of `new Array(n)` runs **482 ms single-threaded where
+  the boxed version needs 632 ms across eight workers**. Fixing the op beat
+  adding eight cores, and boxing parallelises worse besides.
+
+  Supporting: `columnBuffers` / `columnFromBuffers` — a packed numeric column
+  as the buffer pair it already is, for crossing an isolate boundary. The
+  buffers are **copies**, deliberately: transferring a column's own buffer
+  detaches it in the sending isolate, which would silently empty the cache the
+  worker exists to keep warm.
+
+- **core:** **the flattened key convention — two-edged keys now survive a
+  columnar round trip.** `toArrow` has always flattened a `timeRange` /
+  `interval` key into `<key>` + `<key>End` (+ `<key>Label`), because Arrow has
+  no interval-of-time type — but no ingest door read that shape back, so
+  anything aggregated was columnar-export-only. Now `fromColumns` reads it,
+  `toColumns` emits it (where it previously threw), and `fromArrow` gains
+  `{ keyKind: 'timeRange' | 'interval' }` to read it out of Arrow. One spelling
+  across all four doors, so `TimeSeries.fromColumns(daily.toColumns())`
+  round-trips an aggregated series, key and all.
+
+  The names are fully determined — a key column's name equals its kind — so
+  there is nothing to configure. The envelope's `schema` keeps declaring the
+  **logical** key; the edge columns are derived from it. Two rules follow: a
+  value column may not take a derived name (it throws on ingest, naming the
+  collision), and ordering for a two-edged key is by `(begin, end)`, matching
+  the row door — as does `sort: true`. Interval labels must be present in every
+  row and all of one type, again matching the row door (and throwing the same
+  `RangeError` when they aren't). Types: `FlatKeyColumns`, plus `keyKind` on
+  `FromArrowOptions`.
+
+  Two incidental improvements fell out: `TimeSeries.fromColumns` no longer
+  rejects non-`time` keys at all (it accepted only `'time'` since it shipped),
+  and the ingest engine's `makeKey` callback is gone — the schema's key kind
+  fully determines the column class, so every door stopped passing one.
+
+- **core:** **`TimeSeries.toColumns()`** — the columnar-JSON export door, and
+  the inverse `fromColumns` never had. Returns the same
+  `{ name, schema, columns }` envelope `fromColumns` accepts (one plain array
+  per column, gaps as `null`), typed per column, so
+  `TimeSeries.fromColumns(series.toColumns())` round-trips **with no cast**.
+  It reads the columnar store directly where `toJSON` materialises a row per
+  event: measured **~2.5–3 ms vs ~26 ms** at 100k rows × 6 columns — an
+  8–10× gap across runs, widening with row count
+  (`scripts/perf-to-columns.mjs`). Two deliberate
+  limits, both reported rather than hidden — a `timeRange` / `interval` key
+  spans two edges and no columnar ingest door reads it back, so it throws
+  naming the two ways out (`asTime({ at: 'begin' })` or `toJSON()`); and
+  `boolean` / array columns export fine but aren't ingestable, which the
+  return type encodes as a compile error rather than a runtime one. Types:
+  `TimeSeriesJsonColumns`, `TimeSeriesColumnarInput`,
+  `TimeSeriesColumnarOutput`.
+
+- **core:** **`ValueSeries` gets the full ingest / export surface** — the
+  value-keyed series is no longer a one-way street with a single columnar door.
+  In: **`ValueSeries.fromJSON`** (row tuples _or_ objects; strict per-cell kind
+  checking, `required` enforced, and — unlike the time door — no timestamp
+  parsing, because a value axis has no calendar to read `'2026-01-01'`
+  against), and **`ValueSeries.fromArrow(table, { axis })`** (`axis` is
+  required: there is no `'time'` field convention to fall back on, and the axis
+  is read unscaled since it carries no `TimeUnit`). Out:
+  **`toRows()` / `toObjects()` / `toJSON({ rowFormat })`** (rows, gaps as
+  `undefined` / `null` respectively), **`toColumns()`** (columnar JSON — one
+  plain array per column, gaps as `null`, the exact envelope `fromColumns`
+  takes back), and **`toArrow()`** (Arrow's memory layout, no copy — the
+  exporter `TimeSeries.toArrow` already used; a `'value'` axis exports as a
+  plain `float64` field). Every door pairs with its inverse and the round trips
+  are **typed**: `ValueSeries.fromColumns(vs.toColumns())` and
+  `ValueSeries.fromJSON(vs.toJSON())` compile without a cast. All four ingest
+  doors share one engine, so the monotonic-axis contract, `sort: true`, and the
+  packing rules are identical whichever you use. Types:
+  `ValueSeriesJsonInput`, `ValueSeriesJsonRow`, `ValueSeriesJsonObjectRow`,
+  `ValueSeriesJsonOutputArray`, `ValueSeriesJsonOutputObject`,
+  `ValueSeriesJsonCell`, `ValueSeriesRow`, `ValueSeriesObjectRow`,
+  `ValueSeriesJsonColumns`, `ValueSeriesColumnarInput`,
+  `ValueSeriesColumnarOutput`, `FromArrowValueOptions`, `JsonColumn`.
+
+- **core:** **`TimeSeries.toArrow(options?)` — zero-copy export to the Apache
+  Arrow memory layout**, the counterpart of `fromArrow`. Every other export
+  door is row-shaped, so reaching another columnar engine meant a full
+  re-materialisation; it never had to — pond's validity bitmap is LSB-first
+  one-bit-per-value (Arrow's layout exactly), numeric columns are a contiguous
+  `Float64Array`, booleans a packed bitmap, and dict-encoded strings
+  `Int32Array` indices plus a dictionary. `toArrow` hands those buffers over
+  as they stand and returns `{ length, fields }` rather than an Arrow `Table`
+  — pond does not depend on `apache-arrow`; the caller assembles with
+  `makeData` / `makeVector` in a few lines (shown on the method doc). The
+  buffers are **live storage, not copies** — the same read-only contract
+  `column()` / `keyColumn()` already carry. Two named non-zero-copy cases:
+  chunked columns materialize first, and a non-dict-encoded string column is
+  a plain JS array (Arrow `Utf8` wants offsets + bytes). A `timeRange` /
+  `interval` key exports as `<key>` + `<key>End` (+ `<key>Label` for interval
+  labels), and a value column already using one of those names throws rather
+  than producing duplicate field names. Types: `ArrowExport`,
+  `ArrowExportField`, `ArrowExportType`, `ToArrowOptions`.
+
+- **process:** registry-bound fluent graph authoring via
+  `process(registry, from)`. Operation methods, params, named secondary inputs,
+  and multi-output suffixes are inferred from the registry while the result
+  remains the same plain slot request accepted over a wire. Added opaque async
+  sources (`defineSource`, `SourceRegistry`, `Host.runAsync`): requests carry
+  only `{ source, params }`, loaders and credentials stay host-side, and equal
+  remote revisions reuse the existing bound graph and all node caches.
+  Concurrent calls for one source identity share a single in-flight load and
+  revision update.
+- **charts:** **`<BarChart binColors>` now works on the single-series
+  time-axis path** — per-bar colours for a plain `series={…} column="…"` bar
+  layer, the shape a **direction-coloured financial volume row** needs (derive
+  the array from open vs close and volume reads green / red under the
+  candles; the `Charts/Candlestick` price+volume scenario shows the recipe).
+  Previously `binColors` only applied to `bins` / horizontal (stacked-path)
+  charts. A per-bar-coloured bar keeps its own colour under hover / selection
+  (the highlight pops opacity instead of swapping the fill), the hover / click
+  readout reports the bar's own colour, and the dense-bar envelope decimation
+  is skipped (an envelope rect can't carry more than one colour), so every
+  visible bar draws.
+- **process:** new **`@pond-ts/process`** package — **work in progress, not
+  published.** Marked `private: true`, so the release workflow skips it; it is
+  on `main` to be iterated on in the open against
+  [RFC #543](https://github.com/pond-ts/pond/pull/543), not to be consumed.
+  A typed dataflow engine over pond values: nodes with typed `in` / `out` port
+  fields (wiring a `string` output into a `number` input is a compile error),
+  pull-based memoized evaluation, connect-time cycle rejection, per-node error
+  caching, and a read-only `Graph` view. `fromLive()` binds a live source where
+  events only mark dirty, so a burst of N events costs one snapshot at the next
+  pull rather than N.
+
+  **The public shape is expected to change.** The RFC concludes that the
+  declarative plan layer is the consumer surface and this engine belongs
+  underneath it as an internal module — see **[PND-PROCSUB]** in
+  [PLAN.md](PLAN.md), and [PND_PROCESS_PLAN.md](docs/plans/PND_PROCESS_PLAN.md)
+  for the measured follow-ups (node identity/lifetime is blocking for
+  interactive use; column-valued nodes and dirty-per-range are the large wins).
+
+- **process:** **`registry.toJsonSchema({ defs })`** replaces the `base` option
+  added earlier in this cycle — the recursive `$ref` now lives in `$defs` and
+  points at `#/$defs/<name>`, which a caller lifts to its own document root.
+  `base` produced a pointer _into_ the host schema; that passes local
+  validators and is rejected by a real tool API (_"reference can only point to
+  definitions defined at the top level of the schema"_). The projection also
+  now emits `anyOf` rather than `oneOf` (equivalent here — both branch sets are
+  disjoint — and the one tool APIs accept), and every `const` carries its
+  `type`. All three were 400s from live calls that a client-side strict
+  validator had passed. See **[PND-PROCSCHEMA]**.
+- **process:** a **selector resolves its own inline spec**, whether or not the
+  plan also lists it at top level. Requiring both was bookkeeping no schema
+  could express, so it lived in prose — and a caller composing from the schema
+  alone duly selected a spec it had not listed and got a skip instead of an
+  answer.
+- **process:** `columns` and `reduce` on one selector are **no longer
+  exclusive** — asking for both now returns both, which is the legend-chip case
+  [PND-PROCTERM] exists for. Previously the reduction was silently dropped.
+- **process:** **`NodeTiming.inputs` and `NodeTiming.pulled`** — `nodes` now
+  describes the **graph** the plan resolved, not just the subset a selector
+  reached. `inputs` carries each node's upstream ids (a raw source column is
+  named by column), which a consumer cannot derive without reimplementing
+  `specId`'s canonicalization; `pulled` is false for a resolved node this
+  request never read, whose `ms` is therefore zero and says nothing. Reporting
+  the unpulled ones is free — no value is produced for them. Found by drawing
+  the pipeline for M4, which rendered a plan with whole branches missing.
+- **process:** **`run({ assemble: false })` and `RunResult.columns`** — columns
+  are the wire shape; the assembled `TimeSeries` is the in-process convenience
+  over the top of them. A `columns` selector now always hands back the resolved
+  columns by name, and `assemble: false` skips building a widened series for a
+  consumer that could never receive one. The receiving side rebuilds with
+  `TimeSeries.fromColumns`, which adopts a `Float64Array` **zero-copy** and
+  reads NaN as a gap, so reassembly across a boundary is free. Measured at 1M
+  rows, the skipped `appendColumn` is 7.6 ms for a gapless column and 22.4 ms
+  for a gapped one — and every rolling study is gapped. See **[PND-PROCCOL]**.
+- **process:** `registry.toJsonSchema({ base })` — the projection can now be
+  **embedded** in a larger schema. Its recursive `$ref` (the line that lets a
+  caller express _EMA of SMA of px_ without being taught a nesting concept)
+  resolves against the **document root**, so a projection emitted at `#` and
+  then dropped inside a tool's `input_schema` had a dangling pointer — silently,
+  since a `$ref` is not required to resolve. `base` names the pointer the
+  subschema will live at, and `$schema` is now emitted only at the root. Found
+  by putting a model-shaped caller in front of it; see **[PND-PROCSCHEMA]**.
+
+- **process:** **slots** — a plan may now be written as `nodes` keyed by
+  caller-assigned names, with `outputs` keyed by the caller's name for each
+  surfaced result ([PND-PROCSLOT]). A node's `specId` is derived from its op,
+  params and inputs, so it keys the cache correctly and **changes the moment a
+  param does — even though the topology has not**. A slot is the missing
+  identity: `avg` survives a `period` edit that moves every derived id.
+
+  Slots are an alias layer, not a replacement. `specId` remains the cache key,
+  because it is what finds a node again across requests, sessions and callers;
+  one caller's `avg` means nothing to another's. Expansion produces exactly the
+  nested plan the equivalent would have been written as, so **a slot plan hits
+  the cache a nested plan built** — verified at 150k bars, where the slot form
+  of an already-resolved graph comes back `cached` at 0.002 ms per node — and
+  neither `compile` nor `specId` knows slots exist.
+
+  `NodeTiming` gains `slot`, and `Fact` / `OutputInfo` gain `name`. Naming does
+  not require slots: a `Select` in the original form can carry a `name` too.
+
+- **process:** **`registry.toJsonSchema({ shape: 'slots' })`** — the projection
+  for the slot format, and notably **flat**. The nested projection's single most
+  load-bearing line is a recursive `$ref`, because an input may be another spec;
+  making that portable took three rounds against a live API (`oneOf` refused,
+  every node needing an explicit `type`, a body pointer rejected in favour of a
+  top-level `$defs`). With slots an input is a plain string, so the recursion is
+  gone and every one of those problems with it — no `$defs`, no `$ref`, nothing
+  to rebase when embedded.
+- **process:** **`plan(from)`** — a builder that emits a plan
+  ([PND-PROCBUILD]). `add` returns a handle you pass as another node's input,
+  so a mistyped reference is a compile error rather than a resolution failure,
+  and `toJSON()` produces the same envelope a model would compose. It holds no
+  resolution logic and knows nothing about the registry, so there is one
+  resolution path, one cache, and the existing plan tests cover it.
+
+- **process:** **`OpDescriptor.inputs` is the declared `InputDef[]`**, not a
+  count. A count checks arity and says nothing else — a consumer labelling a
+  two-input op could not tell which side was which, and one explaining a
+  rejection could not name the unit an input demands, both of which the
+  registry holds and `describe()` was dropping. **Breaking** for anything
+  reading `inputs` as a number; `inputs.length` is the same value.
+
+- **process:** **`suggest` on a numeric param** — the range worth offering,
+  as distinct from `min`/`max`, the range that rejects. Sliders drawn on the
+  legal range spent 96% of their travel where nobody goes, and a param with
+  no `max` had no drawable range at all: `annualise.barsPerYear` defaults to
+  105,120 against a fallback ceiling of 100, so its control sat pinned at the
+  edge and any drag silently destroyed the annualisation. Advisory — nothing
+  rejects a value outside it — but checked at `define()` time so an inverted
+  or escaping range fails in front of the op's author. It also reaches a
+  composing model, as `description` prose in the JSON Schema projection
+  rather than a custom keyword.
+
+- **process:** **Reductions are nodes.** `last`, `extremes`,
+  `percentileRank` and `shape` were a fixed `reduce` enum on the selector,
+  computed after the graph finished — so the one thing every caller reads
+  sat outside the memo, at 10.85 ms of an 11.6 ms fully-cached run
+  (`percentileRank` alone 6.57 ms, densifying 150,000 values and filtering
+  them twice, every request). They are ordinary registry entries now, with
+  content-addressed ids, cache entries and badges like anything else:
+  **0.09 ms**, a 120× improvement on the warm path. **Breaking** — a
+  selector is `{on, output?}`; `reduce`, `points` and `columns: true` are
+  gone, and what a selector yields is decided by the node it points at.
+- **process:** **`Input` admits `{from, output}`** — `slot#Output` in the
+  flat slot form — so a node can read one named output of a multi-output
+  upstream. A nested input had always read output 0, which nobody hit
+  while `select.output` could pick one at the end.
+- **process:** **Slot-expansion failures are collectable.** They ran
+  before the error policy, so a mistyped input was the only class of bad
+  plan that threw instead of coming back as a `skipped` reason an agent
+  could retry against.
+
+### Changed
+
+- **A fold no longer builds a `TimeSeries`** ([PND-PROCTERM]). Every node's
+  `compute` widened the source with `appendColumn` for each nested input, so
+  an op could call the corpus normally — the studies take
+  `(series, { column })`. For a fold that was waste twice over: the column it
+  reads is already in its inputs, and it was being packed into a series only
+  to be read straight back out.
+
+  The cost was not incidental. `appendColumn` **boxes a gapped column** on
+  the way in, because core's `withColumn` takes values rather than a column —
+  22.4 ms per column at 1M rows. Every rolling study is gapped, so the
+  expensive path was the ordinary one.
+
+  20 folds × 500k rows, on top of the columnar fold context below:
+  **383 → 129 ms** (2.96×), rss 173 → 113 MB. Against the boxed, assembling
+  baseline the two changes together are **606 → 129 ms**.
+
+  A facts-only request now returns no `series` at all, and the upstream
+  column still resolves through the node graph rather than the terminal's
+  `needed` set — so the failure the plan warned about, a fact silently
+  coming back with no value because its column was never selected, cannot
+  happen.
+
+- **The rolling mean/σ kernel is now _range-exact_, and every rolling study
+  is faster and more accurate for it** ([PND-PROCKERN]). `sma`, `bollinger`
+  and `envelope` move off core's general sweep onto a dedicated
+  `rollingMeanSdInto`, which fills any `[lo, hi)` with **exactly the bits a
+  full pass would have written there** — not "within rounding", the same
+  doubles.
+
+  That property is the point. An ordinary sliding accumulator carries
+  rounding history from row 0, so restarting it mid-column lands a few ulps
+  off on _every_ cell of the range. Harmless-sounding, until you notice it
+  means the value depends on which ranges happened to be recomputed — on a
+  caller's edit history rather than their data. Two mechanisms get it: the
+  accumulators are rebuilt from the window every `period` rows so history
+  cannot accumulate, and those rebuilds are pinned to **absolute** row index
+  so a ranged sweep reconstructs the state a full sweep held. They also work
+  in a shifted frame, for the reason [PND-SHIFTFRAME] established — aligning
+  _without_ shifting made large-magnitude σ **worse** (3.6e-3 → 1.7e-2),
+  which is why the two ship together.
+
+  Worst relative error against an exact reference, 200k rows, period 20:
+
+  | input                  | before | after   |
+  | ---------------------- | ------ | ------- |
+  | random walk ≈100       | 5.3e-9 | 3.9e-14 |
+  | `1e9 + sin`            | 1.4e-3 | 6.3e-14 |
+  | `1e15 + ((i % 7) − 3)` | 3.6e-3 | 4.4e-16 |
+
+  **Values change** in the last ulps on ordinary data, and materially where
+  they were previously wrong — the `1e9` row is an ordinary notional, not a
+  contrived extreme. Faster too, on 500k bars: `bollinger(20)` **46.5 → 18.4
+  ms** (avg and σ now fuse into one sweep instead of core running two
+  reducers), `envelope(20)` 13.1 → 10.6, `sma(20)` 6.7 → 6.2, a five-study
+  stack 58.3 → 49.9. `scripts/perf-ranged-kernel.mjs`.
+
+- **`withWorkers` no longer changes the answer at all.** The per-study
+  accuracy table is gone, replaced by one word: identical. Partitioned and
+  sequential results are bit-identical for every accelerated study, at
+  ordinary and large magnitudes, because a chunk starting anywhere now
+  reconstructs the state a whole-column pass held there. The previous
+  figures — `sma` 3.9e-14, `bollinger` 5.1e-13 — were observations on one
+  benign random walk presented as bounds, and a Codex pass had already
+  broken the `zScore` one with a legal input.
+
+- **core:** **`fromArrow` now adopts a null-bearing numeric column's buffers
+  zero-copy** — 19.3 ms → 1.5 ms (**12.7×**) on 500k rows with 4% nulls.
+  Arrow's validity bitmap is byte-identical to pond's, so both the values
+  buffer and the bitmap become the column's storage as they stand; the old
+  per-element `vector.get(i)` walk remains only as the fallback. Adoption
+  declines — falling back with the same answer — for a sliced vector
+  (non-zero chunk offset), a multi-chunk vector, a non-`Float64Array` values
+  buffer, a `nullCount` disagreeing with the bitmap's popcount, or a defined
+  cell holding a non-finite value (which keeps pond's NaN-as-gap intake
+  semantics: adopting would have made the same table ingest differently
+  depending on whether adoption was possible). Aliasing note: like the dense
+  path's existing adopt, the resulting column shares memory with the Arrow
+  table — mutating the table's buffers afterwards corrupts the series.
+
+- **core:** **`fromColumns` / `fromArrow` numeric columns with gaps now carry
+  `allFinite: true`.** The ingest predicate ("a cell is defined iff its value
+  is finite") _is_ the finiteness proof, but the flag was previously set only
+  for gap-free columns — so a single missing cell cost the column the
+  unguarded reduction fast path for the life of the series. Same answers,
+  faster reductions on gapped columns; observable as the column's `allFinite`
+  field now being `true` where it was `false`.
+
+- **core:** **`sum` and `mean` are ~2.5× faster on long runs**, and their
+  results may differ from previous versions in the last ulp. Runs of **32 or
+  more** cells (range positions — a gapped range counts its gaps) now
+  accumulate into eight independent partial sums rather than one running
+  total, which breaks the loop's dependency chain — 2.51× on a dense column,
+  2.22× through a validity bitmap, and `close.mean()` over 500k bars goes
+  from 0.47 ms to **0.19 ms**.
+
+  Floating-point addition is not associative, so this **can change the
+  answer** — worth being precise about the direction, though: the blocked
+  result is _generally more accurate_, not less. Sequential summation
+  accumulates rounding error as O(n·ε); eight partial sums accumulate it as
+  O((n/8)·ε + 8·ε). Summing 10⁶ copies of `0.1` lands strictly closer to the
+  true answer than before, and `1e16` followed by 8191 `1`s no longer absorbs
+  every `1` into the exponent gap.
+
+  What is guaranteed: runs of **fewer than 32** cells are unchanged bit for
+  bit; which cells contribute is unchanged (the validity bitmap and the
+  non-finite policy behave exactly as before — only the order of the
+  additions moved); `stdev`, the rolling-window kernel that backs
+  `@pond-ts/financial`'s studies, and the row-API path are all untouched.
+  pond-ts does not guarantee that a columnar sum and a row sum of the same
+  values agree bit for bit. Full rationale, measurements, and the threshold
+  reasoning in [`docs/notes/blocked-summation.md`](docs/notes/blocked-summation.md).
+
+- **core:** **`aggregate()` is up to 2.5× faster**, from two changes to how it
+  produces its result. Neither changes the answer: same values, same interval
+  keys and labels, same `undefined` (not `NaN`) for an empty bucket, and the
+  same `ValidationError` if a reducer overflows to a non-finite result.
+  - It **builds the result columnar** instead of routing it back through row
+    intake. The columnar fast path already computed every bucket in typed
+    arrays, then boxed each one into a frozen `[Interval, …]` row so
+    `new TimeSeries({ rows })` could walk all of them back into columns; the
+    store is now assembled directly.
+  - It **reduces each bucket in place** rather than materialising a
+    `Float64Column` slice for it. Reducers gained a range-scoped kernel
+    (`reduceColumnRange`), so a bucket costs two integers instead of a column
+    instance — plus, on a column with a validity bitmap, a `Uint8Array`
+    allocation, an O(bucket) bit copy and an O(bucket/8) popcount that the
+    slice's constructor performed and then threw away.
+
+  Measured on 1M events, 1-second grid: **2.10× at 1-minute buckets**
+  (6.65 ms → 3.16 ms, one column) and **2.55× at 10-second buckets**
+  (55.52 ms → 21.81 ms, four columns). The win is per output bucket, so it
+  tapers to no change on hourly and daily rollups, where the reduction
+  dominates and there was nothing to save. Whole-column reductions
+  (`series.reduce`, `column.sum()`, …) are unaffected.
+
+- **core:** **`median` / `percentile` are ~13× faster on the columnar path.**
+  `reducePercentileColumn` densified the defined+finite cells and then sorted
+  them; a percentile needs one or two order statistics, not a total order, so
+  it now runs quickselect — O(n) expected instead of O(n log n). Measured at
+  1M rows: `median` 76.18 ms → 5.90 ms, `p95` 75.80 ms → 5.88 ms (**12.9×**).
+  Applies to `series.reduce(col, 'median' | 'pNN')`, `column.median()`,
+  `column.percentile(q)`, and the `aggregate` / `bin` / `binBy` percentile
+  families. Other reducers are unchanged.
+
+  **One behaviour change, and it removes an inconsistency.** The old path used
+  `Float64Array.prototype.sort()`, which places `-0` strictly before `+0`,
+  while the row path sorts with `(a, b) => a - b` — a comparator that reads
+  the pair as equal. On signed-zero input the two paths disagreed: `p0` of
+  `[0, -0, 0, -0, 0]` was `-0` columnar and `+0` row-wise. Quickselect
+  compares with `<` / `>`, under which they are equal, so the columnar path
+  now returns `+0` and matches the row path.
+
+- **core:** **`cumulative`, `diff`, `rate` and `pctChange` are 4–7× faster.**
+  All four were column-native only in the sense of not materialising `Event`s:
+  each still read every cell through the polymorphic `col.read(i)` into a boxed
+  `Array<number | undefined>`, then handed that to `float64ColumnFromArray`,
+  which walked the boxed array twice more — once for the values and once for
+  the validity bitmap. They now walk the source's `Float64Array` and validity
+  bits directly and write into typed output buffers.
+
+  Measured at 200k rows × 4 columns (`scripts/perf-operators-unboxed.mjs`):
+
+  | operation           | dense                  | 4% missing             |
+  | ------------------- | ---------------------- | ---------------------- |
+  | `cumulative('sum')` | 10.22 → 2.56 ms (4.0×) | 22.94 → 3.44 ms (6.7×) |
+  | `cumulative('max')` | 11.84 → 2.54 ms (4.7×) | 22.12 → 3.43 ms (6.4×) |
+  | `diff`              | 19.18 → 2.71 ms (7.1×) | 20.29 → 3.87 ms (5.2×) |
+  | `rate`              | 21.18 → 3.96 ms (5.4×) | 21.92 → 5.14 ms (4.3×) |
+  | `pctChange`         | 19.87 → 2.85 ms (7.0×) | 21.85 → 3.95 ms (5.5×) |
+
+  Output is unchanged: same values, same missing cells, and `allFinite` still
+  derived from the produced values rather than inherited from the source.
+  Chunked and non-numeric sources keep the previous path.
+
+- **core:** **`rolling()`'s per-row contributor test is inlined.** The
+  per-column sweep evaluated it through a small helper — twice per row, once
+  entering the window and once leaving — which is a call per row per column,
+  the exact cost the sweep was restructured to remove. Both its operands are
+  loop-invariant, so on a dense provably-finite column (an OHLCV bar series)
+  the whole predicate now folds away. `sma(20)` over 500k bars: **10.41 →
+  6.48 ms**, and the five-study strategy pass 70.58 → 65.25 ms.
+
+- **core:** **`rolling(count, 'stdev')` runs Welford inline.** `stdev` was the
+  one reducer deliberately left on the reducer-state path when the kernel was
+  restructured, because its order-independent delete has exact `n <= 1` and
+  `n === 1` cases whose value is entirely numerical. The recurrence is now
+  transcribed verbatim into the sweep, removing three virtual calls per row
+  while keeping results **bit-identical** — asserted with `Object.is` against
+  the real state object across 18 shapes (large offsets, gross-outlier
+  eviction, denormals, gaps) plus 150 randomised trials, not with a closeness
+  tolerance that a dropped special case could pass.
+
+  `bollinger(20)` 31.51 → 25.18 ms, `zScore(20)` 26.49 → 19.88 ms, and the
+  five-study strategy pass 84.15 → 70.58 ms.
+
+- **core:** **`rolling()`'s count-window kernel sweeps one column at a time**,
+  making every reducer-state call monomorphic instead of megamorphic, and
+  specialises `avg` inline. The window bounds never depended on the column, so
+  the columns were only sharing a sweep — and sharing it meant a single
+  `states[c].add(...)` site saw every reducer's state shape in turn, costing
+  three uninlinable virtual calls per row per column for what is usually O(1)
+  arithmetic.
+
+  Measured on 500k 1-minute bars through `@pond-ts/financial`
+  (`packages/financial/scripts/perf-agent-queries.mjs`): `sma(20)` 21.48 →
+  15.20 ms, `bollinger(20)` 105.26 → 73.66 ms, `zScore(20)` 98.77 → 61.88 ms,
+  `envelope(20)` 69.33 → 45.03 ms, and a five-study strategy pass **318.30 →
+  212.18 ms (1.50×)**.
+
+  Results are bit-identical: the same reducer states are fed the same values in
+  the same order, and `avg`'s specialisation is a running sum with no accuracy
+  argument to preserve (unlike `stdev`, whose order-independent Welford delete
+  keeps its state path).
+
+- **core:** **`withColumn` accepts a `Float64Array` where `NaN` means missing.**
+  A typed buffer has no `undefined` slot, so `NaN` is the only way to express a
+  gap in one — and requiring gaps to be spelled `undefined` forced every
+  producer holding a typed buffer to box a whole column to say "no value here".
+  A boxed `Array<number | undefined>` keeps the strict reading: it already has
+  `undefined`, so a `NaN` in one is still rejected. `±Infinity` is rejected on
+  both doors. The buffer is copied, not adopted (`fromColumns` remains the
+  documented zero-copy door).
+
+- **financial:** **studies are 2.0–5.6× faster.** The study kernel handed every
+  study an `Array<number | undefined>` built by walking the column with the
+  polymorphic `col.at(i)`, and each study then checked every input for
+  `undefined` per cell — `bollinger` allocated four 500k boxed arrays before
+  three `withColumn` re-ingests. The kernel now returns a `Float64Array` with
+  `NaN` marking a gap, which propagates through arithmetic on its own, so only
+  the genuinely study-specific guards survive (σ = 0 has no band; a zero base
+  has no percent change).
+
+  Measured on 500k 1-minute bars, combined with the `rolling` change above:
+
+  | study                 | before    | after        | ×         |
+  | --------------------- | --------- | ------------ | --------- |
+  | 5-study strategy pass | 318.30 ms | **84.15 ms** | **3.78×** |
+  | `envelope(20)`        | 69.33 ms  | 12.47 ms     | 5.56×     |
+  | `percentChange()`     | 23.66 ms  | 4.51 ms      | 5.24×     |
+  | `zScore(20)`          | 98.77 ms  | 26.49 ms     | 3.73×     |
+  | `bollinger(20)`       | 105.26 ms | 31.51 ms     | 3.34×     |
+  | `sma(20)`             | 21.48 ms  | 10.54 ms     | 2.04×     |
+
+  Output is unchanged — verified against the committed pandas oracle fixtures
+  and, for the gap placement the oracle doesn't cover, byte-identical to the
+  pre-change build.
+
+- **process:** `RunResult.explain` now covers **every id in `nodes`**, not only
+  the plan's top-level entries — a nested spec is a node in the timing badges
+  (and will be a node in the pipeline view) and had no lineage string to render.
+  `Skipped.spec` also now carries `inputs`, because a plan may hold two specs of
+  the same op and `{op, params}` alone does not say which one to fix. Both are
+  additive to the response.
+- **charts (Storybook):** the `Charts/Histogram` story group moved to
+  **`Charts/BarChart/Histogram`** — the histogram is `BarChart` in its `bins`
+  mode, not a separate component, and the sidebar now says so. Story IDs under
+  the group changed accordingly (`charts-histogram--*` →
+  `charts-barchart-histogram--*`).
+
+### Fixed
+
+- **core:** **`fromArrow` now reads a field's declared Arrow type instead of
+  guessing from the runtime shape of `toArray()`** — closing a
+  silent-corruption class. The reader worked out what a column held from what
+  `toArray()` handed back, which is correct for the types it supports and
+  quietly wrong outside them, because Arrow's physical layouts do not all store
+  one machine word per logical value. Measured, before the fix: **`Float16`
+  ingested `1.5` as `15872`** (its half-float bit pattern — the length matched,
+  so nothing caught it), and a **`Decimal128` column with a single null
+  ingested `123.45` as `12345`** (the per-element path produced exactly `rows`
+  values, so the length check never fired). A dense `Decimal` merely threw the
+  wrong error, blaming a length mismatch.
+
+  The readable set is now an explicit allowlist — `Int` (any width),
+  `Float32`/`Float64`, `Date32`/`Date64`, `Time32`/`Time64`, `Timestamp`,
+  `Utf8`/`LargeUtf8`/`Utf8View`, `Null` (an all-missing value column), and a
+  `Dictionary` of any of those (the encoding is transparent; readability
+  follows the value type) — checked per field, on the key and value columns of every
+  Arrow door (`TimeSeries.fromArrow`, `ValueSeries.fromArrow`, and the
+  flattened key edges). Anything else is refused **by name**, with the cast
+  that would fix it: `Decimal` names the float64 precision trade-off, `Float16`
+  says to cast, `Bool` names the real reason (the columnar ingest engine
+  carries `number` and `string` value columns only). A duck-typed stand-in
+  carrying no `typeId` keeps working — the `ArrowTableLike` contract is
+  deliberately structural — and gains a width check that catches the Decimal
+  shape anyway.
+
+  Behavioural change worth noting: a `Utf8` **key** now throws on its declared
+  type rather than on its shape, so the message names the type and points at
+  passing it as a value column instead.
+
+- **Charts' affine fast path evaluates in a rebased frame, and survives deep
+  zoom for the first time.** The canvas draw loops reconstructed each affine
+  scale as `px = k·t + b` on absolute epoch-ms values — on a deeply zoomed
+  window, `k·t` and `b` are huge near-cancelling terms whose rounding residue
+  reaches ~0.16 px at a 1 ms window and ~24 px at 1 µs. The interior affinity
+  probe detected the drift and rejected the scale, so every deep-zoomed frame
+  (sub-second visible windows on an epoch-ms axis — the rejection crossover
+  measures around a few hundred ms at typical plot widths) silently fell back
+  to the slow per-point d3-scale path. The map is now recovered, verified, and evaluated
+  in the rebased form `px = (t − t0)·k + px0` (the association d3 itself
+  uses), which matches the exact scale to ≲1e-9 px at every zoom depth — the
+  fast path stays engaged at the `minDuration` floor and below (line/area
+  deep-zoom draws ~3.1–3.4× faster; wide-domain draws pay ~1–2%, one extra
+  subtraction per point per axis).
+
+- **`zScore` computes its deviation in a shifted frame, and is accurate at
+  large magnitudes for the first time** ([PND-SHIFTFRAME]). The study derived
+  its numerator as `value − rollingMean`, which is catastrophic cancellation
+  whenever the values are large next to the window's spread: `ulp(1e15)` is
+  `0.125`, so a window spanning ±3 leaves the deviation about three bits. The
+  new `rollingDeviationSd` kernel accumulates `value − anchor` and emits the
+  deviation directly — both operands small, nothing cancels — re-anchoring
+  periodically, and on magnitude, so a trending series stays in frame.
+
+  Measured against an exact reference over 200k rows, worst relative error:
+
+  | input                     | before | after   |
+  | ------------------------- | ------ | ------- |
+  | `1e15 + ((i % 7) − 3)`    | 1.0e+0 | 4.1e-15 |
+  | `1e9 + sin` (mid)         | 4.1e+0 | 4.9e-12 |
+  | random walk ≈100 (benign) | 3.9e-6 | 4.4e-11 |
+  | `1e12·(1+i/N)` (trending) | 9.0e-6 | 4.9e-15 |
+
+  **This was never a parallelism bug**, though it was found through one and
+  first documented as one. The sequential study computed the same subtraction
+  and carried the same exposure; partitioning only made two equally-wrong
+  answers visibly disagree. Anyone thresholding z-scores on large-magnitude
+  data was affected on the default path.
+
+  Two consequences worth reading before upgrading. **`zScore` values change**
+  — by rounding error on ordinary data, and by a lot on the cases above, where
+  they were wrong. And **`zScore` is no longer accelerated by `withWorkers`**:
+  the stable kernel is not the shape the worker pool hooks, so opting in no
+  longer speeds it up (it was 2.44×, the fastest study there) and no longer
+  changes its answer by a bit. The remaining accelerated studies — `sma`,
+  `envelope`, `bollinger` — are exactly those whose error is bounded.
+
+  **One behaviour change at overflow scale**, verified by a Codex pass and
+  left unguarded: the shifted frame computes `x - anchor`, which can
+  overflow when both operands are near `Number.MAX_VALUE` even though each
+  is finite. `[MAX_VALUE, -MAX_VALUE]` at period 2 gives a mean of
+  `-Infinity` where the previous raw-sum kernel gave the true `0`. Not
+  guarded, because the check is per row on a ~20 ns/row kernel to correct
+  an input no price, size or rate series can produce.
+
+  `zScore` costs ~2.3× its previous formulation as an upper bound (~26 ns/row
+  at 500k), and is flat in `period` — 22.8 to 26.1 ns/row from `period 2` to
+  `period 100_000`. `scripts/perf-shifted-frame.mjs`.
+
 ## [0.53.1] — 2026-07-25
 
 ### Fixed

package/README.md

@@ -152,27 +152,31 @@ const points = series.sample({ reservoir: { size: 500 } }).toRows();
 
 ## Performance
 
-pond-ts is faster on **every** comparable operation, with no regressions —
-a **~17x** geometric-mean speedup across the measurable ops, plus a handful
-of transforms (`select` / `rename`) that are **effectively instant** (O(1)
-column rebinds, below the timer's resolution). The advantage grows with data
-size.
-
-| Category          | Speedup (N=16k)                                      | Notes                                         |
-| ----------------- | ---------------------------------------------------- | --------------------------------------------- |
-| **Rate**          | ~120x                                                | Single columnar walk vs Pipeline              |
-| **Fill**          | 77–87x                                               | Single columnar pass vs Pipeline per strategy |
-| **Aggregation**   | 57–82x                                               | O(N+B) bucketing vs O(N×B) Pipeline           |
-| **Statistics**    | 18–80x                                               | Typed-array reduce vs ImmutableJS iteration   |
-| **Alignment**     | 42x                                                  | Forward cursor vs repeated binary search      |
-| **Construction**  | 13x                                                  | Columnar intake vs ImmutableJS wrapping       |
-| **Chained**       | 8x                                                   | Derived constructors vs per-step Pipeline     |
-| **Transforms**    | `select`/`rename` instant; `collapse` 30x; `map` ~4x | Column reshapes vs Pipeline                   |
-| **Event access**  | 6x                                                   | Array indexing vs ImmutableJS `get()`         |
-| **Serialization** | 4x                                                   | Lightweight columnar representation           |
-
-See the [full benchmark results](website/docs/reference/benchmarks.mdx)
-for detailed numbers. Run locally:
+Measured against three reference points (snapshot 2026-07-30; full tables,
+methodology, and every losing number in the
+[benchmark reference](website/docs/reference/benchmarks.mdx)):
+
+- **vs pondjs** (the predecessor): faster on all 54 measurable shared
+  operations — geometric mean **20.7×**, `aggregate` up to 453×,
+  `median` 157×, and `select` / `rename` effectively instant (O(1)
+  column rebinds).
+- **vs pandas** (500k-bar workload): roughly **even** — ahead on `ema`,
+  `mean`, `median` / `percentile`; behind ~1.1–1.9× on the rolling
+  studies. A five-study strategy pass runs 1.28× slower than pandas'
+  Cython kernels.
+- **vs polars, single-threaded**: **ahead on composite studies**
+  (`bollinger` 0.53×, strategy stack 0.85×, `ema` 0.32× — lower is
+  pond-ts faster), behind 4–9× on whole-column reductions (the SIMD gap;
+  half-closed already by blocked summation) and on raw ingest, where
+  pond-ts front-loads validation the dataframe engines defer.
+- **vs polars on all 10 cores**: behind ~3.5× on the strategy stack —
+  pond-ts has no parallelism today; a measured 2.42× worker-thread path
+  is on the roadmap (`[PND-PROCPAR]`).
+
+The honest one-line version: the rewrite beat its predecessor by an order
+of magnitude, holds its own per-core against the native engines on the
+composite queries that dominate real workloads, and knows exactly where
+it is behind. Run locally:
 
 ```sh
 npm run build && node packages/core/bench/vs-pondjs.cjs

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pond-ts/react",
-  "version": "0.53.1",
+  "version": "0.54.0",
   "description": "React hooks for pond-ts live time series",
   "license": "MIT",
   "repository": {
@@ -33,7 +33,7 @@
     "test:runtime": "vitest run"
   },
   "peerDependencies": {
-    "pond-ts": "^0.53.0",
+    "pond-ts": "^0.54.0",
     "react": "^18.0.0 || ^19.0.0"
   },
   "devDependencies": {