@pond-ts/fit 0.53.1 → 0.55.0

package/CHANGELOG.md

@@ -4,11 +4,13 @@ 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.55.0...HEAD
+[0.55.0]: https://github.com/pond-ts/pond/compare/v0.54.0...v0.55.0
+[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 +56,1175 @@ and type-level changes; patch bumps are strictly additive.
 
 ## [Unreleased]
 
+## [0.55.0] — 2026-08-04
+
+### Added
+
+- **process:** **`@pond-ts/process` publishes for the first time —
+  experimental, pre-1.0.** Computations as data over pond-ts: a processing
+  graph authored fluently in application code (or composed as JSON by a saved
+  view or a tool-calling model) resolves against a declared op vocabulary and
+  runs over a bound `TimeSeries`, with content-addressed caching, provenance,
+  and per-node timings on every response. Two entry points: the plan layer at
+  `.` and the Node worker pool at `./pool`. The docs section
+  ([pond-ts.org/docs/process](https://pond-ts.org/docs/process/)) is listed on
+  the site with a TypeDoc API reference; the publication follows the 2026-08
+  external audit hardening (all P1 findings fixed and regression-pinned). The
+  API is expected to move as friction reports land — pin an exact version.
+
+- **charts:** **`<BarChart categories>` now works horizontally** ([PND-HCAT],
+  the 2026-08 API review's #3 item) — the funnel / ranking / comparison shape.
+  `orientation="horizontal"` puts the categories on the **y** axis as unit
+  slots with the value on x, and a `<YAxis>` with no explicit `ticks` **derives
+  one label per category by itself**, so the chart no longer needs a
+  hand-built `i + 0.5` tick list. It previously threw ("horizontal category
+  axes are not yet supported"), which forced consumers to convert their
+  categories into ordinal `bins` records _and_ hand-place the labels — the
+  workaround the gallery funnel documents.
+
+  Explicit `<YAxis ticks>` still wins, and vertical categorical charts are
+  untouched (categories stay on the container's ordinal x band scale). A new
+  internal `RowLayer.binCategories()` channel carries the names to whichever
+  axis they land on.
+
+- **charts:** **the list family's series door** — `<BarList series={splits}
+label={…}>` / `<BoxList series>` take a `TimeSeries` / `ValueSeries`
+  directly (one row per event; exactly-one-of with `rows`), closing the
+  "required adapter" gap the 2026-08 API review named: starting from a pond
+  series there is no shaping step. The `listRowsFrom*` readers remain for
+  record rows. Docs across the charts hub, cheat sheet, and type pages now
+  present the series as the whole data contract, with the exported `from*`
+  builders re-documented as **interop escape hatches for non-pond data**.
+
+- **charts:** **`<BarList>` + `<BoxList>` — standalone ranked row lists** (the
+  react-timeseries-charts `HorizontalBarChart` shape, rebuilt as what it
+  always was: a table). One DOM row per _entity_ — an interface, a split, a
+  symbol — with a label cell (any node, links included), one glyph line per
+  configured column on **one shared value scale**, optional data cells
+  before/after the glyphs, `sortBy`/`sortDirection` or a full custom
+  comparator (missing values sort last either direction), an optional per-row
+  expander (`renderExpanded`, keyed on row identity so it survives a re-sort),
+  and consumer-owned row selection with an accent edge in the marks register.
+  A vertical **baseline rule** at the scale origin anchors the rows to one
+  reference (on by default for `<BoxList>`, whose lines float at their lower
+  quantile; opt-in for `<BarList>`, whose tracks already show zero), and
+  reference **`markers`** (`{ value, label? }`) draw a labelled dotted rule
+  through every row in the annotation register — an SLA / capacity line —
+  with marker values joining the auto domain fit.
+  `<BarList>` draws proportional value bars; its sister `<BoxList>` draws a
+  five-number distribution per line — range band, `q1`→`q3` body, median line
+  — plus an optional **current-value tick** with a formatted inline label (the
+  esnet traffic-by-interface look), using the same quantile vocabulary as the
+  canvas `<BoxPlot>` (`lower`/`q1`/`median`/`q3`/`upper`, both-or-neither
+  body, quantiles computed upstream — `reduce` facts — never by the chart).
+  Styling stays on the one channel: bars resolve `theme.bar[as]`, boxes
+  `theme.box[as]`; both built-in themes gain a `box.secondary` role for the
+  paired-direction case. Readers `listRowsFromTimeSeries` /
+  `listRowsFromValueSeries` build one row per event / axis key. The in-plot
+  histogram remains `<BarChart orientation="horizontal">` — the lists are for
+  the table-shaped cases it can't be (link labels, cells, expanders, custom
+  sort).
+
+- **charts:** **`BarStyle.hover` — a distinct hover colour for bars**
+  ([#577](https://github.com/pond-ts/pond/issues/577)). A theme may now give
+  bars a three-step emphasis — `fill` at rest → `hover` under the pointer →
+  `highlight` (plus the outline) when selected. Previously one `highlight`
+  served both live states, so hover and select differed only by the presence of
+  an outline; `ScatterStyle` has carried distinct rest / selected treatments
+  (`outline` vs `selectedOutline`) all along, making bars the less expressive
+  layer for the same two-state interaction.
+
+  **Optional, with a `highlight` fallback**, so no existing theme changes
+  meaning or rendering — a theme that wants the distinction adds one colour.
+  Selection outranks hover on a bar that is both. Single-series only: a stacked
+  or per-bin-coloured bar has no separate highlight colour to replace (it pops
+  its _own_ fill, so a red/green volume bar keeps its meaning while live), and
+  that convention is unchanged.
+
+### Changed
+
+- **charts:** **a bar's capabilities now follow the mark it draws, not the
+  prop that fed it** ([PND-BARSEM], the 2026-08 API review's #2 item). A
+  **one-column vertical** histogram (`bins` + a single `column`) and a
+  one-entry `columns` draw exactly the mark a `series` + `column` chart
+  draws, but they used to route through the stacked path purely because of
+  which prop supplied them — and so silently lost whole-slot hit-testing
+  (#584), the `BarStyle.hover` colour, the cursor readout, stable per-bar
+  identity and per-bar decimation. They now take the single-series path, so
+  visually identical bars behave identically.
+
+  **What this changes in practice:** on a one-column histogram, hover and
+  click now hit the bar's **whole slot** rather than only the drawn
+  rectangle (so the space above a short bar is live, and slots tile the
+  axis); the layer gains a cursor readout; and `theme.bar.hover` applies.
+  A genuine multi-group stack, `categories`, and horizontal charts are
+  unchanged — their segments share a bin's x-range, so only y distinguishes
+  them. New reader `barsFromBins` backs the normalized path.
+
+  **Not a pure widening, in one respect:** dense-bar envelope decimation is
+  now live on a one-column histogram (it was single-series-only). It engages
+  only once bars fall under ~1px, where it is visually lossless, but at that
+  density the per-bar `gap` and highlight give way to envelope rects — pass
+  `decimate={false}` to keep every bar drawn. The `colors` map, the
+  `theme.bar[<column>]` role and `SelectInfo.label` are all preserved across
+  the reroute (each was a silent regression caught in review).
+
+  This shrinks `BarStyle.hover`'s scope warning from a list of five
+  path-accidents to the two real exclusions (a multi-group stack has no
+  hover channel on `StackStyle`; `binColors` keeps each bar's own colour by
+  design) — which was the acceptance test the task set itself.
+
+- **charts:** **column names and source modes are now checked at compile
+  time** ([PND-CHARTAPI], the 2026-08 API review's #1 item). Every draw
+  layer's column props are derived from the series' schema, so
+  `<LineChart series={cpu} column="cpuu" />` — and a numeric prop pointed at
+  a string column, where the schema has some other numeric column — fail to
+  **compile** instead of throwing at render; the
+  same holds for `readout`, the band edges, the box quantiles, and the OHLC
+  prices. `<BarChart>`'s props became a **union of its legal source modes**,
+  so mixing sources (`series` + `bins`) or column forms (`column` +
+  `columns`), or passing `categories` a `column`, are compile errors too.
+  `<BarList>` / `<BoxList>` get the same treatment for `rows` XOR `series`,
+  which additionally closes the row-type hole #590 documented (annotating a
+  callback with a custom row type while passing `series` claimed a shape the
+  series door cannot produce).
+
+  **This narrows what compiles — deliberately.** Code carrying a typo, an
+  illegal mode mix, or a lying row annotation stops building; that is the
+  point, and each case was already a runtime failure. Two compatibility
+  behaviours are preserved on purpose: a **loosely-typed** series
+  (`TimeSeries<SeriesSchema>`, e.g. from a helper that doesn't narrow) still
+  accepts any column name, because an unparameterized schema leaves the name
+  union open and nothing can be checked against it; and `bins` column names
+  stay `string`, since they name aggregate fields of a bin record rather than
+  schema columns. Note the deliberate distinction: a schema that _does_ name
+  its columns but has **no numeric one** rejects every name — there is nothing
+  numeric to plot — which is not the same as the loose case.
+
+  **One new limitation.** Because a layer's props are a union _per series
+  kind_, a value typed as _either_ kind (`TimeSeries<A> | ValueSeries<B>` — a
+  wrapper that forwards whatever it is given) matches no single member and
+  must be narrowed or cast at the boundary. `DurationAxis.stories.tsx` is the
+  worked example. The alternative design (one generic over the series type)
+  handles that case but changes every props type's public generic parameters;
+  the trade is recorded in `spikes/charts-type-seam/REPORT.md`.
+
+- **charts:** **a bar's hover / click target is now its whole slot**, not the
+  rectangle it draws. A bar _is_ the full width of its interval; the `gap` that
+  separates adjacent columns is a display affordance. Hit-testing the drawn
+  rect made that affordance interactive — the gap was a dead channel you could
+  point at and select nothing, and so was the empty plot space above a short
+  bar, even though the x-scrub cursor at that same x reported the bar quite
+  happily. `barAt` now tests the bar's full interval width and the full plot
+  height, so hover, click and the cursor readout all agree on which bar you are
+  on, and slots tile the axis.
+
+  **Widening, with one exception.** Points that previously selected _nothing_
+  now select the bar whose slot they fall in. The exception: a bar whose value
+  exceeds an explicit `<YAxis max>` used to draw — and be clickable — above the
+  plot top, in the strip a `'top'` axis title reserves; the slot stops at the
+  axis domain, so that sliver no longer hits. Everything inside the plot that
+  hit before still hits.
+
+  **It reaches across the full plot height, so it can shadow layers beneath
+  it.** The topmost hit wins, so a `<BarChart>` declared _after_ a
+  `<ScatterChart>` / `<BoxPlot>` / another `<BarChart>` in the same row now
+  claims every hit in its x-range at any y. Declare a bar layer **below** the
+  marks that should stay clickable.
+
+  **Single-series vertical only** — a stacked, `bins`, `categories` or
+  horizontal chart still hit-tests the drawn segment, because a stack's
+  segments share a bin's x-range and only y tells them apart.
+
+  Unchanged: a genuine hole between non-contiguous intervals still misses (the
+  change makes the drawing gap hittable, it doesn't invent coverage the data
+  lacks), a gap (`NaN`) bar owns no slot, and a shared edge goes to the left
+  bar — the rule `barIndexAtTime` already documented, so the two now agree by
+  construction.
+
+### Fixed
+
+- **process:** **audit hardening — five wrong-answer / silent-acceptance paths
+  in the plan layer closed** (external Codex audit, 2026-08; all reproduced,
+  all regression-pinned). Unit validation of a **picked output** read
+  `outputs[0]` instead of the selected output, so a picked `variance` was
+  refused where variance was demanded and — worse, silently — accepted where
+  price was. `Registry.define()` now rejects duplicate input roles and
+  duplicate output ids (both used to _collapse_ at run time rather than fail:
+  inputs resolved to the last role, outputs dropped the earlier column),
+  invalid param defaults, and `dependsOn` naming unknown params. An op result
+  whose length does not match the bound series is refused at the producer —
+  it used to ride out unchecked whenever `assemble: false` skipped the only
+  length check. The column-selection loop now honours `onError` (an operator
+  exception escaped `'collect'`), and a selector naming a nonexistent output
+  is a `skipped` entry instead of silently surfacing nothing. Fact provenance
+  (`id`, `name`, `op`, `unit`) now wins over a custom fold body's fields, and
+  `columnBytes` sums a chunked column's chunks instead of reporting 0 — which
+  a byte budget would read as "free".
+
+  Also: the derived fold slots in both builders now key by **params** —
+  `shape({points: 100})` after `shape({points: 20})` silently returned the
+  20-point node — and `shape` itself uses a `ceil` stride, so 200 points
+  asked of 399 rows returns ≤200 rather than all 399. The nested JSON Schema
+  projection can now express the `PickedOutput` input form, `Host` accepts
+  `budgetBytes` (the [PND-PROCCACHE] cap was unreachable from the long-lived
+  host shape) and grows `remove(id)`, and CI's package-content check covers
+  `@pond-ts/process`. Package remains **unpublished** (`private: true`).
+
+  A second audit round tightened the same seams. `columnBytes` now counts
+  what is actually retained: the **backing buffer's capacity** rather than
+  the column's logical length (core documents `_values` as possibly
+  oversized, so a one-row column viewing a 1000-slot buffer retains 8,000
+  bytes, not 8 — an undercount that defeats the budget), the chunk-offset
+  index and the bitmap's real bytes on chunked columns. The
+  **request-driven half of a `Host`'s footprint is now boundable**:
+  `runAsync` binds a graph per distinct caller-supplied `SourceRef`, so
+  `maxSources` caps registry-loaded sources LRU (author-added datasets are
+  never evicted), and a `remove()` racing an in-flight load now wins — the
+  landing load discards its result instead of resurrecting the dataset.
+  And an omitted param now unifies with its explicit default in the fluent
+  layer's derived fold slots (`shape()` ≡ `shape({points: 40})`, the same
+  rule `specId` applies), while the response labels a computation with the
+  **first** slot that named it rather than whichever was declared last.
+
+- **charts:** **a hovered or selected single-series bar now pops to full
+  opacity** ([#576](https://github.com/pond-ts/pond/issues/576)). `drawBars`
+  set `globalAlpha` once to the resting `style.opacity` and never lifted it for
+  the highlight **fill** on the single-series path — only for the selected
+  bar's outline. The per-bar-`binColors` branch in the same function and
+  `drawStacks` both already popped to 1, and `drawBars`' own docstring claimed
+  it did too. So on a theme with `opacity < 1` a **hovered** bar (which has no
+  outline) barely changed, and a **selected** one read only by its outline.
+  All three paths now treat the highlight fill identically.
+
+  **This changes pixels** on any single-series `<BarChart>` with an alpha'd
+  theme: highlighted bars are brighter. A theme that raised its base `opacity`
+  to compensate may now want it back down.
+
+  **It also flattens select against hover**, which is worth knowing before you
+  upgrade. The selected bar's outline strokes in `highlight` — previously that
+  read as a brighter ring over an alpha'd fill, and it was the main thing
+  separating a selected bar from a hovered one. Now the fill underneath is the
+  same colour at the same alpha, so only the half of the stroke falling
+  outside the rect distinguishes them. Hover is no longer nearly invisible,
+  but the two live states are closer together. A theme that needs them clearly
+  apart should set the new `BarStyle.hover`.
+
+## [0.54.0] — 2026-08-02
+
+### 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.
+
+### 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.
+
+### 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pond-ts/fit",
-  "version": "0.53.1",
+  "version": "0.55.0",
   "private": false,
   "description": "Fitness & activity domain library on pond-ts — quantities, canonical activity series, and analytics (geo, power, zones, splits)",
   "license": "MIT",
@@ -37,7 +37,7 @@
     "verify": "npm run format:check && npm run build && npm test"
   },
   "peerDependencies": {
-    "pond-ts": "^0.53.0"
+    "pond-ts": "^0.55.0"
   },
   "devDependencies": {
     "typescript": "^5.6.3",