@pond-ts/charts 0.63.0 → 0.65.0

package/API.md

@@ -164,7 +164,7 @@ Deliberately small — the ordering-based slice of the algebra, no calendar ops
 | Operation schemas | `RollingSchema`, `RollingAlignment`, `AlignSchema`, `DiffSchema`, `SmoothSchema`, `SmoothMethod`, `FillStrategy`, `FillMapping`                    | `packages/core/src/schema/index.ts`                                |
 | Column/data kinds | `Column`, `KeyColumn`, `ColumnKind`, `ScalarKind`, `ScalarValue`, `ColumnValue`, `ArrayValue`, `ValidityBitmap`                                    | `packages/core/src/columnar/`                                      |
 | JSON wire format  | `JsonRowFormat`, `JsonRowForSchema`, `JsonObjectRowForSchema`, `JsonValueForKind`, `JsonTimestampInput`, `JsonTimeRangeInput`, `JsonIntervalInput` | `packages/core/src/schema/index.ts`                                |
-| Temporal utility  | `TemporalLike`, `DurationInput`, `CalendarUnit`, `TimeZoneOptions`, `KeyLike`, `BatchSampleStrategy`                                               | `packages/core/src/core/`, `packages/core/src/sequence/`           |
+| Temporal utility  | `TemporalLike`, `DurationInput`, `CalendarUnit`, `TimeZoneOptions`, `KeyLike`, `BatchSampleStrategy`, `SequenceSample`, `SequenceCoverage`         | `packages/core/src/core/`, `packages/core/src/sequence/`           |
 
 The `pond-ts/types` subpath re-exports the schema-as-contract types with zero
 runtime (`packages/core/src/schema/public.ts`).
@@ -432,19 +432,32 @@ Series shapes (same file): `ChartSeries`, `BandSeries`, `BoxSeries`,
 
 All are pure `(series, options) → TimeSeries` appending output columns;
 `column` defaults to `'close'`; periods are bar counts; warm-up is
-length-preserving (`undefined` head rows).
-
-| Study                       | Output column(s)                    | Options gist                                        | Source                                             |
-| --------------------------- | ----------------------------------- | --------------------------------------------------- | -------------------------------------------------- |
-| `sma`                       | `sma`                               | `{ period, column?, output? }`                      | `packages/financial/src/studies/moving-average.ts` |
-| `ema`                       | `ema`                               | `{ period, column?, output? }` (α = 2/(period+1))   | `packages/financial/src/studies/moving-average.ts` |
-| `bollinger`                 | `bbMiddle`, `bbUpper`, `bbLower`    | `{ period, stdDev?, column?, prefix? }`             | `packages/financial/src/studies/bollinger.ts`      |
-| `envelope`                  | `envMiddle`, `envUpper`, `envLower` | `{ period, percent?, maType?, column?, prefix? }`   | `packages/financial/src/studies/envelope.ts`       |
-| `rollingStdev`              | `stdev`                             | `{ period, column?, output? }` (population, ddof=0) | `packages/financial/src/studies/rolling-stat.ts`   |
-| `rollingMin` / `rollingMax` | `min` / `max`                       | `{ period, column?, output? }` (Donchian edges)     | `packages/financial/src/studies/rolling-stat.ts`   |
-| `rollingPercentile`         | `p{q}` (e.g. `p90`)                 | `{ period, q, column?, output? }`                   | `packages/financial/src/studies/rolling-stat.ts`   |
-| `zScore`                    | `zscore`                            | `{ period, column?, output? }`                      | `packages/financial/src/studies/z-score.ts`        |
-| `percentChange`             | `pctChange`                         | `{ periods?, column?, output? }`                    | `packages/financial/src/studies/percent-change.ts` |
+length-preserving (`undefined` head rows). A **multi-input** study (`atr`)
+names each input instead of taking one `column`, each defaulting to its
+`DEFAULT_OHLCV` name — the same "never hard-code a column" rule applied
+per input.
+
+| Study                       | Output column(s)                     | Options gist                                                                                   | Source                                             |
+| --------------------------- | ------------------------------------ | ---------------------------------------------------------------------------------------------- | -------------------------------------------------- |
+| `sma`                       | `sma`                                | `{ period, column?, output? }`                                                                 | `packages/financial/src/studies/moving-average.ts` |
+| `ema`                       | `ema`                                | `{ period, column?, output? }` (α = 2/(period+1))                                              | `packages/financial/src/studies/moving-average.ts` |
+| `bollinger`                 | `bbMiddle`, `bbUpper`, `bbLower`     | `{ period, stdDev?, column?, prefix? }`                                                        | `packages/financial/src/studies/bollinger.ts`      |
+| `envelope`                  | `envMiddle`, `envUpper`, `envLower`  | `{ period, percent?, maType?, column?, prefix? }`                                              | `packages/financial/src/studies/envelope.ts`       |
+| `rollingStdev`              | `stdev`                              | `{ period, column?, output? }` (population, ddof=0)                                            | `packages/financial/src/studies/rolling-stat.ts`   |
+| `rollingMin` / `rollingMax` | `min` / `max`                        | `{ period, column?, output? }` (one edge; `donchian` gives the channel)                        | `packages/financial/src/studies/rolling-stat.ts`   |
+| `rollingPercentile`         | `p{q}` (e.g. `p90`)                  | `{ period, q, column?, output? }`                                                              | `packages/financial/src/studies/rolling-stat.ts`   |
+| `zScore`                    | `zscore`                             | `{ period, column?, output? }`                                                                 | `packages/financial/src/studies/z-score.ts`        |
+| `percentChange`             | `pctChange`                          | `{ periods?, column?, output? }` (= ROC; TA-Lib-verified)                                      | `packages/financial/src/studies/percent-change.ts` |
+| `rsi`                       | `rsi`                                | `{ period?, column?, output? }` (Wilder, default 14)                                           | `packages/financial/src/studies/rsi.ts`            |
+| `macd`                      | `macdLine`, `macdSignal`, `macdHist` | `{ fastPeriod?, slowPeriod?, signalPeriod?, column?, prefix? }` (12/26/9)                      | `packages/financial/src/studies/macd.ts`           |
+| `atr`                       | `atr`                                | `{ period?, high?, low?, close?, output? }` (Wilder, default 14)                               | `packages/financial/src/studies/atr.ts`            |
+| `momentum`                  | `momentum`                           | `{ period?, column?, output? }` (`v − v[−period]`, default 10)                                 | `packages/financial/src/studies/momentum.ts`       |
+| `historicalVolatility`      | `hv`                                 | `{ period?, annualize?, column?, output? }` (σ of log returns, ×√252)                          | `packages/financial/src/studies/volatility.ts`     |
+| `stochastic`                | `stochK`, `stochD`                   | `{ kPeriod?, slowing?, dPeriod?, high?, low?, close?, prefix? }` (14/3/3; `slowing: 1` = fast) | `packages/financial/src/studies/stochastic.ts`     |
+| `williamsR`                 | `williamsR`                          | `{ period?, high?, low?, close?, output? }` (default 14, bounded −100..0)                      | `packages/financial/src/studies/williams-r.ts`     |
+| `donchian`                  | `dcUpper`, `dcLower`, `dcMiddle`     | `{ period?, high?, low?, prefix? }` (default 20)                                               | `packages/financial/src/studies/donchian.ts`       |
+| `obv`                       | `obv`                                | `{ close?, volume?, output? }` (no period; TA-Lib seed `volume[0]`)                            | `packages/financial/src/studies/obv.ts`            |
+| `vwap`                      | `vwap`                               | `{ period, high?, low?, close?, volume?, output? }` (rolling, typical px)                      | `packages/financial/src/studies/vwap.ts`           |
 
 Adding a study? Follow `packages/financial/src/studies/README.md` (uniform
 shape + pandas oracle case + fluent method are all REQUIRED).

package/CHANGELOG.md

@@ -8,7 +8,9 @@ The `@pond-ts` packages — `pond-ts`, `@pond-ts/react`, `@pond-ts/charts`,
 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.63.0...HEAD
+[Unreleased]: https://github.com/pond-ts/pond/compare/v0.65.0...HEAD
+[0.65.0]: https://github.com/pond-ts/pond/compare/v0.64.0...v0.65.0
+[0.64.0]: https://github.com/pond-ts/pond/compare/v0.63.0...v0.64.0
 [0.63.0]: https://github.com/pond-ts/pond/compare/v0.62.0...v0.63.0
 [0.62.0]: https://github.com/pond-ts/pond/compare/v0.61.0...v0.62.0
 [0.61.0]: https://github.com/pond-ts/pond/compare/v0.60.0...v0.61.0
@@ -66,6 +68,287 @@ include new features and type-level changes; patch bumps are strictly additive.
 
 ## [Unreleased]
 
+## [0.65.0] — 2026-09-06
+
+### Added
+
+- `@pond-ts/financial`: **`stochastic(...)`**, **`williamsR(...)`** and
+  **`donchian(...)`** — the three range-position studies, built on one new
+  kernel (`highestLowestValues`: the trailing highest high / lowest low in a
+  single `rolling` scan) plus fluent `.stochastic()` / `.williamsR()` /
+  `.donchian()`. All name their bar inputs per column (`high` / `low` /
+  `close`, defaulting to `DEFAULT_OHLCV`), the `atr` shape.
+
+  **`stochastic`** — `{ kPeriod = 14, slowing = 3, dPeriod = 3, prefix =
+'stoch' }` appending `stochK` / `stochD`: the slow stochastic, with
+  `slowing: 1` giving the fast one (TA-Lib's `STOCHF`) from the same
+  function. Values match TA-Lib's `STOCH`/`STOCHF` to `5.7e-14` on every bar
+  TA-Lib emits, `%D` with an identical warm-up. Two deliberate deltas,
+  both documented on the study: **`%K` starts when it can** (bar 15 at the
+  defaults) where TA-Lib masks it back to `%D`'s first bar (17), discarding
+  `dPeriod − 1` real values — the `macd` precedent; and **a flat window
+  (`HH === LL`) is `undefined`** where TA-Lib reports `0`, which is also its
+  value for "close at the very bottom of a real range" — the `rsi` precedent.
+  The smoothing uses a new raw-array kernel, `rollingMeanValues`, that waits
+  for `slowing` _values_ rather than rows: a scratch-column SMA would have
+  put a "3-bar" `%K` on bar 13 with one value in it.
+
+  **`williamsR`** — `{ period = 14, output = 'williamsR' }`, bounded
+  `−100..0`. Matches TA-Lib's `WILLR` bar-for-bar to `1.4e-14` with an
+  identical warm-up; the only delta is the same flat-window `undefined`.
+  It is fast `%K − 100`, computed on the same kernel, and a test pins that
+  identity against `stochastic({ slowing: 1 })`.
+
+  **`donchian`** — `{ period = 20, prefix = 'dc' }` appending `dcUpper` /
+  `dcLower` / `dcMiddle`. `upper` is exactly `rollingMax(high)` and `lower`
+  exactly `rollingMin(low)` (pinned), in one scan plus the midpoint; pandas
+  oracle only (TA-Lib has no Donchian). Scales linearly with price, like
+  `atr`; a missing `high`/`low` is skipped (core's reducer policy), not
+  propagated.
+
+- `@pond-ts/financial`: **`obv(...)`** and **`vwap(...)`** — the first two
+  **volume** studies, plus fluent `.obv()` / `.vwap()`. Both name their inputs
+  per column (`close` / `volume`, and `high` / `low` for VWAP), each
+  defaulting to its `DEFAULT_OHLCV` name, the rule `atr` established.
+
+  **`obv`** is Granville's On-Balance Volume — the running total of each bar's
+  volume signed by its close change — and is the first study with **no
+  `period`**: it is read for its shape, not its level, so there is nothing to
+  size a window over. It is **TA-Lib's OBV exactly**, including the seed
+  (`OBV[0] = volume[0]`) and an unchanged close adding nothing; the oracle
+  asserts equality, with an identical (empty) warm-up mask. On **interior
+  gaps** it deliberately departs from TA-Lib: a running sum has no local
+  answer for a missing term, so a missing close or volume leaves the level
+  `undefined` from that bar on (the same asymmetry the Wilder recursion has —
+  a leading gap shifts the seed, an interior one propagates). TA-Lib has no
+  gap semantics; measured on a seven-bar series it is 400 out of level at
+  the gap bar and 100 out from then on, presented as a value.
+
+  **`vwap`** is a **rolling** Volume-Weighted Average Price:
+  `Σ typicalPrice · volume / Σ volume` over `period` bars, typical price
+  `(high + low + close) / 3`. There is no TA-Lib VWAP and no single
+  definition, so this is a documented design choice: the rolling form fits
+  the package's count-window shape, and the intraday desk's _anchored_ VWAP
+  is not a special case of it (a count window emits only once it spans
+  `period` rows) — that one needs a session reset and is deferred to the
+  session-anchored phase. `period` is **required** (no conventional length to
+  default to). A window with no volume is `undefined`; a bar missing any
+  input is dropped from **both** sums so the ratio is never biased. Verified
+  against a pandas replication on a fixture whose volume spikes make a
+  dropped weighting visible (≥ 1.24 price units from the plain mean).
+
+  The oracle fixture gains a `volumes` input, and four kernels land under
+  them for the studies that follow: `cumulativeValues` (A/D line, PVT),
+  `signedVolumeValues`, `typicalPriceValues` (CCI, MFI, Keltner) and
+  `rollingWeightedMeanValues` (VWMA).
+
+- `@pond-ts/financial`: **`atr(...)`** — Wilder's Average True Range, the third
+  [PND-STUDY] named indicator, plus a fluent `.atr()`. `{ period = 14,
+high = 'high', low = 'low', close = 'close', output = 'atr' }`. Verified
+  against **TA-Lib** bar-for-bar in the oracle — exact agreement at both
+  periods tested, with identical warm-up.
+
+  **The first multi-input study.** Where every study so far took a single
+  `column`, ATR names each of its three inputs, each defaulting to its
+  `DEFAULT_OHLCV` name — the same "never hard-code a column" rule applied per
+  input rather than a new mechanism. Because the inputs are columns of one
+  series they are aligned by construction, so the mismatched-length error
+  array-based libraries must check for at every call is unrepresentable here.
+
+  Warm-up is `period` rows, not `period − 1`: true range needs a previous
+  close, so bar 0 has none.
+
+- `@pond-ts/financial`: **`macd(...)`** — Moving Average Convergence/Divergence,
+  the second [PND-STUDY] named indicator. `{ fastPeriod = 12, slowPeriod = 26,
+signalPeriod = 9, column = 'close', prefix = 'macd' }`, appending
+  `macdLine` / `macdSignal` / `macdHist`, plus a fluent `.macd()`.
+
+  Two deliberate deltas from TA-Lib, both documented on the study:
+  **each column warms up when it can** (the line at bar 25, signal and
+  histogram at 33) where TA-Lib masks all three back to 33, keeping eight real
+  values it discards; and the EMAs are **pond's own** (`α = 2/(span+1)` seeded
+  on the first sample — what `ema()` already ships) rather than TA-Lib's
+  SMA-seeded ones. The second is a _seed_ difference, so it decays: measured
+  at 3.8% of the line's magnitude at the first shared bar, 0.089% by bar 79.
+  Seeding TA-Lib's way would make `macd()` disagree with
+  `ema(fast) − ema(slow)` inside this package, which is the worse surprise —
+  and is pinned by a test.
+
+- `@pond-ts/financial`: **`rsi(...)`** — Wilder's Relative Strength Index, the
+  first of the [PND-STUDY] named indicators. `{ period = 14, column = 'close',
+output = 'rsi' }`, length-preserving warm-up (`period` rows, not `period − 1`
+  — RSI averages _differences_, so it needs one extra bar), and a fluent
+  `.rsi()`. Verified against **TA-Lib** bar-for-bar in the oracle fixture,
+  agreeing to `1.4e-14`.
+
+  Worth knowing which RSI this is: the gain/loss averages are seeded on the
+  arithmetic mean of the first `period` differences, then carried by Wilder's
+  recursion — TA-Lib's definition and Wilder's original. Implementations that
+  instead smooth with a plain first-sample-seeded EMA of the same `α = 1/period`
+  produce a **materially different** series: on this package's own oracle input
+  the two sit up to **7.03 RSI points** apart, and are still `0.15` apart 65
+  bars later. That is enough to move a reading across the conventional 70/30
+  thresholds, so it is a definition choice rather than a rounding detail.
+
+- `@pond-ts/financial`: **`momentum(...)`** — the absolute `period`-bar
+  difference, `value − value[i − period]`. `{ period = 10, column = 'close',
+output = 'momentum' }`, warm-up `period` rows, plus a fluent `.momentum()`.
+  Verified against **TA-Lib's `MOM`** bar-for-bar in the oracle: exact
+  agreement with identical warm-up masks. The additive companion to
+  `percentChange`'s ratio; it is in the price's units and scales with them
+  (pinned by a property test).
+
+- `@pond-ts/financial`: **`historicalVolatility(...)`** — the standard
+  deviation of log returns over `period` bars, annualised.
+  `{ period = 20, annualize = 252, column = 'close', output = 'hv' }`, plus a
+  fluent `.historicalVolatility()`. Warm-up is `period` rows, not
+  `period − 1` — `period` returns need `period + 1` prices, the same
+  off-by-one RSI and ATR have.
+
+  TA-Lib has no HV to arbitrate the conventions, so they are pinned on the
+  study and in the pandas oracle (`np.log(s).diff().rolling(n).std(ddof=0)
+· √annualize`): **population σ** (`ddof = 0`, the package convention shared
+  with Bollinger / `rollingStdev` / `zScore`; a sample σ is
+  `√(n/(n−1))` larger — 2.6% at 20); **log returns**, not simple; annualised
+  by `√annualize` with `252` the default for daily bars and an **option**
+  rather than a hidden constant (`1` for per-bar σ, `252·390` for one-minute
+  bars); and a **decimal** (`0.18` = 18%), the form volatility is consumed
+  in. Scale-invariant, pinned by a property test. A non-positive price has
+  no log return: both returns touching it are missing (explicitly, since
+  `ln(−4/−5)` is a finite non-answer). A leading gap shifts the start so the
+  first window still covers `period` real returns, matching pandas'
+  `min_periods` and the Wilder-family studies — the σ is computed by calling
+  the range-exact kernel on the returns array directly, because a scratch
+  column through `rollingValues` counts rows and would emit one bar early
+  over one return too few.
+
+- `@pond-ts/financial`: **`percentChange` is ROC** — TA-Lib's `ROC` is the same
+  `(price / prevPrice − 1) × 100`, and the oracle now cross-checks the study
+  against it: exact agreement (`0.0`) with identical warm-up masks at both
+  periods. Documented on the study and in API.md; there is deliberately no
+  separate `roc` study.
+
+## [0.64.0] — 2026-08-28
+
+### Added
+
+- `pond-ts`: **`Sequence.bounded(range, { coverage })`** — chooses whether a
+  range selects buckets by their sample point (`'sample'`, the default and the
+  existing behaviour) or by their extent (`'overlap'`, every bucket the range
+  touches, including the one containing `range.begin()`). `aggregate` realizes
+  its grid with `'overlap'`; alignment keeps `'sample'`. As a side benefit
+  `bounded({ start: t, end: t }, { coverage: 'overlap' })` is a flooring
+  primitive — it returns exactly the bucket containing `t` — so consumers no
+  longer have to re-derive pond's calendar anchoring by hand to floor a
+  timestamp. New exported type `SequenceCoverage`.
+
+- `@pond-ts/charts`: **`<YAxis zeroAnchored>`** — pins a y-axis's zoom to the
+  value-`0` gridline instead of the pointer, and drops drag-to-pan entirely.
+  For a bar chart, whose baseline must never move: a bar rests on `0` (at the
+  plot floor for all-positive data, or somewhere mid-plot for data that
+  straddles positive and negative), and an ordinary pointer-pivoted gesture
+  would slide that baseline around the plot as you scroll. With
+  `zeroAnchored`, every wheel notch scales the axis around wherever `0`
+  currently renders, so the baseline holds however far in or out you zoom.
+  One qualification: the pivot is clamped into the axis's pixel range, so once
+  `0` has been scrolled off the plot the zoom pivots about the nearer edge and
+  the baseline does creep — benign for bars, where that clamp coincides with
+  the declared floor, but not an unconditional guarantee. Still gated by the
+  container's own `axisPanZoom` opt-in — this changes what the gesture does,
+  not whether it's on.
+
+### Changed
+
+- `pond-ts`: **`aggregate` now emits the bucket containing the first event**,
+  where before it started at the first grid boundary _at or after_ it — so
+  every event between the two aggregated into nothing, silently. 60 daily bars
+  rolled to a calendar month came back holding 38 of them: no error, no
+  warning, no `undefined`, just a well-formed series with a third of the input
+  gone. It contradicted `aggregate`'s own documented membership rule ("point
+  events contribute to the bucket containing their timestamp") and was
+  asymmetric — the trailing partial bucket _was_ emitted. **This changes
+  results for any caller whose first event did not land exactly on a grid
+  boundary**: expect an extra leading bucket, and sums/counts that now account
+  for the previously-dropped events. Callers who worked around it by passing a
+  pre-floored explicit `range` are unaffected — the floor is now what the
+  default does. **Note what `range` does and does not bound:** it selects the
+  grid, not the event scan, so the leading bucket is filled from every event it
+  contains — including events _before_ `range.begin()` when the series has
+  them. On a window narrower than the series (a chart viewport, say) the edge
+  bucket is therefore a complete bucket rather than a clipped one, which is
+  what keeps bar heights stable under a pan; if you need the window to bound
+  the events too, narrow the series rather than the grid. `align(...)` and
+  `materialize(...)` are deliberately unchanged: their grids are _sampled_,
+  and the sample point becomes the output key. A pre-realized
+  `BoundedSequence` argument is an explicit bucket list, used as given and
+  unaffected by any of this. Reported by Tidal (#672).
+
+- `@pond-ts/charts`: **y gutter drag now pans instead of zooming** — matching
+  the x strip's own gesture (drag pans, wheel zooms) instead of the
+  drag-to-zoom behavior it shipped with in `axisPanZoom="y"`/`"xy"`. Wheel
+  still zooms the grabbed axis about the pointer, and double-click still
+  releases it back to its fit; only the drag's own effect changed.
+
+### Fixed
+
+- `@pond-ts/charts`: **a trading-time date band clamped onto a labelled tick
+  keeps its segment boundary.** The F-charts-21 collision fix dropped the whole
+  `{ start, label, shaded }` entry, but `<XAxis>` spans each band
+  `[its start, the next band's start)` and takes its zebra parity from
+  `shaded` — so removing an entry deleted the _period_, not a duplicate label,
+  and the preceding band ran on to the next surviving boundary under its own
+  name and shading. (Aug 1 2026 is a Saturday, so the August band clamps onto
+  Mon Aug 3, already a day tick — August vanished and July painted across it.)
+  `bands()` entries now carry **`showLabel`**, and only the text is suppressed.
+  Found by Codex reviewing the v0.64.0 range.
+- `@pond-ts/charts`: **a controlled y-gutter wheel zoom no longer pivots about
+  the wrong point under a plot-level y zoom.** The `zeroAnchored` pivot was
+  corrected above, but the ordinary (non-anchored) controlled wheel still fed
+  the pointer's _screen_ pixel into the pre-transform scale's pixel space, so
+  the value under the pointer slid out from under it — ~0.14 units per notch at
+  `k = 1.198`. Third and last face of one root cause: a screen-space pixel used
+  where `base`'s pixel space is meant.
+- `@pond-ts/charts`: **a controlled y-gutter pan no longer overshoots the
+  cursor under a plot-level y zoom.** With `onBoundsChange` set, the drag
+  translated the axis's pre-transform scale by a _screen_ pixel delta. Those
+  two pixel spaces differ by the container's `yTransform`, so with the plot's
+  own y pan/zoom engaged (`panZoom="panZoomY"` / `"panZoomXY"`) the axis
+  panned `k`× too far and the grabbed value outran the pointer. Both
+  transforms are applied in pixel space, so the base↔screen relation is
+  exactly affine and the correction is a division, on `log` and `symlog` as
+  well. (The division is exact on all three; end-to-end tracking on `symlog`
+  still drifts, because its knee is re-derived from the panned domain — a
+  pre-existing property the sibling zoom test already documents.) Invisible at
+  `k === 1`.
+- `@pond-ts/charts`: **`<YAxis zeroAnchored>` no longer lets the baseline drift
+  in the controlled path.** With `onBoundsChange` set, the zoom read `0`'s
+  pixel off the axis's _live_ scale but inverted it through `baseYScales`.
+  Those two pixel spaces differ by the container's own `yTransform`, so with
+  the plot's y pan/zoom active (`panZoom="panZoomY"` / `"panZoomXY"`) the
+  baseline crept a few pixels per wheel notch — monotonically, in exactly the
+  gesture whose purpose is to hold it still. It was invisible without a
+  plot-level y zoom, where the two spaces coincide. Found by a post-merge
+  adversarial review of #676.
+- `@pond-ts/charts`: **a `BarChart`'s baseline no longer relocates under a y
+  gutter pan/zoom.** `resolveBarBaseline` decided whether bars rest on zero or
+  on the axis floor by reading the axis's _live, transformed_ domain — the
+  same read a pan/zoom keeps moving — so once a gesture scrolled zero out of
+  view, every bar's rendered top silently snapped to the moving floor instead
+  of its actual value. It now reads the axis's declared (pre-transform)
+  domain for that decision, so a pan/zoom can move the viewport without ever
+  relocating a bar's own baseline.
+- `@pond-ts/charts`: **[F-charts-21] a trading-time axis's stacked date-band
+  row no longer draws a second, colliding label over a collapsed-gap seam.**
+  `scale.bands()` picked its anchors from the raw calendar (a month or day
+  start) without checking whether that instant was live, so a period
+  beginning on a collapsed weekend or holiday clamped its label onto the same
+  seam a tick (or another band) already occupied — rendering as two
+  overlapping labels (`"Aug"` over `"Aug 3"`, or worse at tight zoom, fully
+  interleaved). Bands whose raw start needed clamping now dedupe against a
+  run of other clamped starts landing on the same live instant (picking the
+  genuinely-live member as the representative when one exists) and against
+  an already-labelled tick, so a seam carries exactly one label.
+
 ## [0.63.0] — 2026-08-18
 
 ### Added

package/dist/BarChart.js

@@ -448,8 +448,8 @@ export function BarChart({ series, bins, categories, column, columns, as: semant
                     ...(id === undefined
                         ? {}
                         : {
-                            hitTest: (px, py, xScale, yScale, mode) => {
-                                const baseline = resolveBarBaseline(yScale);
+                            hitTest: (px, py, xScale, yScale, mode, baseYScale) => {
+                                const baseline = resolveBarBaseline(yScale, baseYScale);
                                 // No `gapPx` — the hit region is the bar's whole slot (its
                                 // interval width, full plot height), not the inset rect the
                                 // gap draws. See barSlotRect.
@@ -525,7 +525,7 @@ export function BarChart({ series, bins, categories, column, columns, as: semant
                                     },
                                 }),
                         }),
-                    draw: (ctx, xScale, yScale) => drawBars(ctx, bs, xScale, yScale, singleDrawStyle, resolveBarBaseline(yScale), gapPx, id, selection, hover, decimate, binColors, bandLadder, layerSpans),
+                    draw: (ctx, xScale, yScale, baseYScale) => drawBars(ctx, bs, xScale, yScale, singleDrawStyle, resolveBarBaseline(yScale, baseYScale), gapPx, id, selection, hover, decimate, binColors, bandLadder, layerSpans),
                 },
                 axisId: axis,
                 index,
@@ -562,7 +562,7 @@ export function BarChart({ series, bins, categories, column, columns, as: semant
                 ...(id === undefined
                     ? {}
                     : {
-                        hitTest: (px, py, xScale, yScale) => {
+                        hitTest: (px, py, xScale, yScale, _mode, baseYScale) => {
                             // The cap reaches the hit rect ONLY for a real stack, where the
                             // rect is what resolves *which segment* was hit and so must be
                             // the drawn one. A single-series chart has one segment per slot
@@ -576,7 +576,7 @@ export function BarChart({ series, bins, categories, column, columns, as: semant
                             // the fix is to make the guarantee orientation-independent rather
                             // than to narrow the claim, since the reason for the split is
                             // segment disambiguation and that is a property of the *stack*.
-                            const hit = stackAt(ss, px, py, orientation, xScale, yScale, gapPx, stackMinWidth, ss.groups.length > 1 ? maxWidthPx : undefined);
+                            const hit = stackAt(ss, px, py, orientation, xScale, yScale, gapPx, stackMinWidth, ss.groups.length > 1 ? maxWidthPx : undefined, baseYScale);
                             if (hit === null)
                                 return null;
                             const [bi, g, begin, name, value] = hit;
@@ -657,7 +657,7 @@ export function BarChart({ series, bins, categories, column, columns, as: semant
                             });
                         },
                     }),
-                draw: (ctx, xScale, yScale) => drawStacks(ctx, ss, orientation, xScale, yScale, stackStyle, gapPx, stackMinWidth, id, selection, hover, bandLadder, layerSpans),
+                draw: (ctx, xScale, yScale, baseYScale) => drawStacks(ctx, ss, orientation, xScale, yScale, stackStyle, gapPx, stackMinWidth, id, selection, hover, bandLadder, layerSpans, baseYScale),
             },
             axisId: axis,
             index,

package/dist/Layers.js

@@ -207,7 +207,7 @@ export function Layers({ children }) {
     }), [row.registerLayer, row.unregisterLayer]);
     const background = container.theme.background;
     const { grid: gridColor, gridDash } = container.theme.axis;
-    const { layers, yScales, formats, defaultAxisId, tickValues, tickCounts, axisSides, axisOffsets, axisColors, } = row;
+    const { layers, yScales, baseYScales, formats, defaultAxisId, tickValues, tickCounts, axisSides, axisOffsets, axisColors, } = row;
     // x geometry is shared and lives on the container (uniform across rows), and
     // so is the x tick count — vertical gridlines must sit under the `<XAxis>`
     // labels, which pass the same `xTickCount` to the same scale.
@@ -346,21 +346,23 @@ export function Layers({ children }) {
         const report = container.reportDrawStats;
         if (report === undefined) {
             for (const entry of layers) {
-                const yScale = yScales.get(entry.axisId ?? defaultAxisId);
+                const axisId = entry.axisId ?? defaultAxisId;
+                const yScale = yScales.get(axisId);
                 if (yScale === undefined)
                     continue;
-                entry.layer.draw(ctx, xScale, yScale);
+                entry.layer.draw(ctx, xScale, yScale, baseYScales.get(axisId));
             }
         }
         else {
             const infos = [];
             let totalDrawMs = 0;
             for (const entry of layers) {
-                const yScale = yScales.get(entry.axisId ?? defaultAxisId);
+                const axisId = entry.axisId ?? defaultAxisId;
+                const yScale = yScales.get(axisId);
                 if (yScale === undefined)
                     continue;
                 const t0 = performance.now();
-                const stats = entry.layer.draw(ctx, xScale, yScale);
+                const stats = entry.layer.draw(ctx, xScale, yScale, baseYScales.get(axisId));
                 const drawMs = performance.now() - t0;
                 totalDrawMs += drawMs;
                 infos.push({
@@ -377,6 +379,7 @@ export function Layers({ children }) {
     }, [
         layers,
         yScales,
+        baseYScales,
         xScale,
         xTickCount,
         defaultAxisId,
@@ -1132,7 +1135,7 @@ export function Layers({ children }) {
         // canvas repaints only on a mark transition — not every move (the move just
         // slides the SVG cursor). A row with no selectable layer (line/area/band)
         // resolves to null → a no-op. Uses the raw pointer, not the snapped x.
-        const hit = resolveSelection(r.layers, rawX, py, c.xScale, (axisId) => r.yScales.get(axisId ?? r.defaultAxisId));
+        const hit = resolveSelection(r.layers, rawX, py, c.xScale, (axisId) => r.yScales.get(axisId ?? r.defaultAxisId), 'hover', (axisId) => r.baseYScales.get(axisId ?? r.defaultAxisId));
         // The resting BLOCK preview (a mounted <MultiSelector>): hover lights
         // every mark in the snap block under the pointer — exactly the set a
         // drag begun and released here would select, from exactly the sweep's
@@ -1392,7 +1395,7 @@ export function Layers({ children }) {
         // 'select', not 'hover': a click must be able to resolve to NO mark —
         // that null is the deselect signal (the empty commit) — so layers whose
         // hover target is generous (a bar's full-height slot) narrow it here.
-        const hit = resolveSelection(r.layers, e.clientX - rect.left, e.clientY - rect.top, c.xScale, (axisId) => r.yScales.get(axisId ?? r.defaultAxisId), 'select');
+        const hit = resolveSelection(r.layers, e.clientX - rect.left, e.clientY - rect.top, c.xScale, (axisId) => r.yScales.get(axisId ?? r.defaultAxisId), 'select', (axisId) => r.baseYScales.get(axisId ?? r.defaultAxisId));
         const modifiers = {
             additive: e.metaKey || e.ctrlKey,
             ctrlKey: e.ctrlKey,

package/dist/XAxis.js

@@ -592,7 +592,7 @@ export function XAxis({ format, label, side = 'bottom', height, ticks: customTic
                             fontWeight: 600,
                             whiteSpace: 'nowrap',
                             overflow: 'hidden',
-                        }, children: b.label }, b.start));
+                        }, children: b.showLabel ? b.label : '' }, b.start));
                 }) })), label !== undefined && (_jsx("div", { style: {
                     position: 'absolute',
                     left: 0,

package/dist/YAxis.d.ts

@@ -267,6 +267,32 @@ export interface YAxisProps {
      * space), so it is always a domain the axis can actually draw.
      */
     onBoundsChange?: (bounds: readonly [number, number] | null) => void;
+    /**
+     * Pin the zoom to the value-**0** gridline instead of the pointer, and drop
+     * drag-to-pan entirely — for a bar chart, whose baseline must never move.
+     * A bar rests on `0` (or, straddling positive and negative, has `0`
+     * *somewhere inside* the visible range) — panning or zooming about an
+     * arbitrary pointer position would slide that baseline around the plot,
+     * which reads as the data moving under gestures that never touched it (see
+     * `resolveBarBaseline`, and [PND-XBASE] for the still-open x-axis
+     * counterpart of this exact failure mode). `zeroAnchored` sidesteps it:
+     * every wheel notch scales the axis around wherever `0` currently renders,
+     * so the baseline holds however far in or out you scroll — whether it sits
+     * at the plot floor (all-positive bars) or in the middle (bars that
+     * straddle zero).
+     *
+     * One qualification: the pivot is clamped into the axis's own pixel range,
+     * so if `0` has been scrolled off the plot entirely the zoom pivots about
+     * the nearer edge instead and the baseline does creep. For a bar chart that
+     * is benign — the clamp lands on the same floor `resolveBarBaseline`
+     * already resolves against — but it is a creep, not a guarantee.
+     *
+     * Still gated by the container's own `axisPanZoom` opt-in (`'y'` / `'xy'`)
+     * — this only changes *what* the gesture does once enabled, not whether
+     * it's enabled. Double-click still resets to the declared/auto-fit view.
+     * Default `false`.
+     */
+    zeroAnchored?: boolean;
     /**
      * @internal Declaration position among the row's children, injected by
      * `ChartRow` so the first-declared axis stays the default. Do not set.
@@ -289,5 +315,5 @@ export interface YAxisProps {
  * {@link RowFrame.axisTransforms}. Report it to a scale UI with
  * {@link YAxisProps.onBoundsChange}.
  */
-export declare function YAxis({ id, side, label, scale, linearWindow, min, max, format, ticks, tickCount, pad, boundaryLabels, width, hide, labelPlacement, color, onMouseEvent, onBoundsChange, index, }: YAxisProps): import("react/jsx-runtime").JSX.Element | null;
+export declare function YAxis({ id, side, label, scale, linearWindow, min, max, format, ticks, tickCount, pad, boundaryLabels, width, hide, labelPlacement, color, onMouseEvent, onBoundsChange, zeroAnchored, index, }: YAxisProps): import("react/jsx-runtime").JSX.Element | null;
 //# sourceMappingURL=YAxis.d.ts.map

package/dist/YAxis.js

@@ -1,6 +1,6 @@
 import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
-import { useContext, useEffect, useMemo } from 'react';
-import { ContainerContext, RowContext } from './context.js';
+import { useContext, useEffect, useMemo, useRef } from 'react';
+import { ContainerContext, RowContext, } from './context.js';
 import { resolveAxisFormat } from './format.js';
 import { unpadDomain } from './domain.js';
 import { useSlotKey } from './use-slot-key.js';
@@ -40,7 +40,7 @@ const DEFAULT_TICK_COUNT = 5;
  * {@link RowFrame.axisTransforms}. Report it to a scale UI with
  * {@link YAxisProps.onBoundsChange}.
  */
-export function YAxis({ id, side = 'left', label, scale = 'linear', linearWindow, min, max, format, ticks, tickCount, pad = 0, boundaryLabels = true, width = DEFAULT_WIDTH, hide = false, labelPlacement = 'rotated', color, onMouseEvent, onBoundsChange, index = 0, }) {
+export function YAxis({ id, side = 'left', label, scale = 'linear', linearWindow, min, max, format, ticks, tickCount, pad = 0, boundaryLabels = true, width = DEFAULT_WIDTH, hide = false, labelPlacement = 'rotated', color, onMouseEvent, onBoundsChange, zeroAnchored = false, index = 0, }) {
     const container = useContext(ContainerContext);
     if (container === null) {
         throw new Error('<YAxis> must be rendered inside a <ChartContainer>');
@@ -103,11 +103,23 @@ export function YAxis({ id, side = 'left', label, scale = 'linear', linearWindow
     useEffect(() => {
         registerAxis(slot, spec);
     }, [registerAxis, slot, spec]);
-    // Drag / wheel to zoom **this** axis, double-click to release it back to the
-    // row's own fit. Enabled by the container's `panZoom` zoom-y degree of freedom.
-    // The gesture writes this axis's entry in `row.axisTransforms`, so only the
-    // gutter you grabbed rescales — the sibling axis, and every other row, hold
-    // still (see `RowFrame.axisTransforms` for why that needs its own transform).
+    // The transform this axis held at the last press — an UNCONTROLLED pan is
+    // anchored on it (see `onPan`), the same way the x strip anchors on
+    // `container.timeRange`.
+    const panStartRef = useRef(null);
+    // The base scale at the last press, for a CONTROLLED pan. Snapshotted for the
+    // same reason: a controlled consumer writes `min`/`max` back after every
+    // move, so `row.baseYScales` on the *next* move already reflects this drag's
+    // own effect — reading it fresh would compose the total delta onto a base
+    // that has already moved, doubling every step's shift.
+    const panBaseRef = useRef(null);
+    // Drag pans, wheel zooms **this** axis, double-click releases it back to the
+    // row's own fit — the same gesture vocabulary the x strip uses, so a gutter
+    // and the canvas agree on what a drag does. Enabled by the container's
+    // `panZoom` zoom-y degree of freedom. The gesture writes this axis's entry in
+    // `row.axisTransforms`, so only the gutter you grabbed moves — the sibling
+    // axis, and every other row, hold still (see `RowFrame.axisTransforms` for
+    // why that needs its own transform).
     const gestures = useAxisGestures({
         axis: 'y',
         // Gated on `<ChartContainer axisPanZoom>` (its `'y'` / `'xy'` values) — the
@@ -116,9 +128,95 @@ export function YAxis({ id, side = 'left', label, scale = 'linear', linearWindow
         // panned and zoomed — without either inheriting gestures silently or opting
         // the plot into vertical drags (a different feature: the uniform 2-D
         // transform a scatter or heat map wants).
-        drag: container.axisPanZoomY ? 'zoom' : 'none',
+        //
+        // `zeroAnchored` drops the drag entirely: a pan slides the whole pixel
+        // window, which is exactly the baseline movement it exists to forbid.
+        // Wheel stays live — `onZoom` below overrides the pivot to `0`'s own
+        // pixel, so a notch narrows the axis around the baseline instead.
+        drag: !zeroAnchored && container.axisPanZoomY ? 'pan' : 'none',
         wheel: container.axisPanZoomY,
-        onZoom: (factor, pivotPx) => {
+        // Snapshot the transform (uncontrolled) or the base scale (controlled) at
+        // press: the pan is re-derived from one of these on every move (the x
+        // strip's own approach), so a long drag can't accumulate rounding — and,
+        // for the controlled path, can't compose the total delta onto a base that
+        // this same drag's own previous move already shifted.
+        onDragStart: () => {
+            panStartRef.current = row.axisTransforms.get(id) ?? IDENTITY_TRANSFORM;
+            panBaseRef.current = row.baseYScales.get(id) ?? null;
+        },
+        onPan: (totalDeltaPx) => {
+            if (onBoundsChange !== undefined) {
+                // **Controlled**: shift the pixel window by the drag, same pixel-space
+                // inversion `onZoom` uses so the maths stays correct on `log` and
+                // `symlog` — a pan is just a zoom with every pixel shifted by the same
+                // amount rather than scaled about a pivot. Read from the *press-time*
+                // base, not the live one: `min`/`max` come back through this axis's own
+                // props after every move, so the live base already carries however far
+                // this drag has gone so far, and re-deriving the total delta against it
+                // would double-apply everything already reported.
+                const base = panBaseRef.current;
+                if (base === null)
+                    return;
+                const [r0, r1] = base.range();
+                // `totalDeltaPx` is a SCREEN delta, but `base` is the pre-transform
+                // scale, and the two pixel spaces differ by the container's `k` (and
+                // this axis's own, if it carries one). Translating `base` by a screen
+                // delta therefore pans by `k`× too much whenever the plot's own y zoom
+                // is engaged — the grabbed value outruns the cursor. Both transforms
+                // are applied in *pixel* space (`narrow` inverts `(px - ty) / k`), so
+                // the base↔screen relation is exactly affine for every scale kind and
+                // the correction is a plain division — no per-scale special-casing.
+                // The division is exact on `log` and `symlog` too; end-to-end
+                // tracking on `symlog` still drifts, because `symlogConstant` is
+                // derived from the domain and so the knee moves as the domain pans.
+                // That is pre-existing and independent of this correction — the
+                // sibling zoom test already documents it as "knee drift".
+                //
+                // `ownK` is 1 in the ordinary controlled path: `applyAxisTransform`
+                // is only ever called from the UNCONTROLLED branches, so a controlled
+                // axis carries no transform of its own. It is composed here for the
+                // one window where that is false — a consumer that pans uncontrolled
+                // and then supplies `onBoundsChange`, leaving a stale axis transform
+                // until the next reset. No test covers that window.
+                //
+                // Sibling of the pivot-space bugs in `onZoom`; invisible at
+                // `k === 1`, which is every test that does not first zoom the plot.
+                const ownK = panStartRef.current?.k ?? 1;
+                const pixelK = container.yTransform.k * ownK;
+                const deltaBasePx = Number.isFinite(pixelK) && pixelK !== 0
+                    ? totalDeltaPx / pixelK
+                    : totalDeltaPx;
+                const at = (px) => +base.invert(px - deltaBasePx);
+                const next = [at(r0), at(r1)];
+                if (!Number.isFinite(next[0]) || !Number.isFinite(next[1]))
+                    return;
+                if (next[0] === next[1])
+                    return;
+                onBoundsChange(unpadDomain(next, pad, scale));
+                return;
+            }
+            // **Uncontrolled**: shift this axis's own pixel transform. Anchored on
+            // the press's `panStartRef`, not the live `row.axisTransforms` value —
+            // reading that fresh on every move would double-apply everything moved
+            // so far this drag.
+            const start = panStartRef.current ?? IDENTITY_TRANSFORM;
+            applyAxisTransform(id, { k: start.k, ty: start.ty + totalDeltaPx });
+        },
+        onZoom: (factor, wheelPivotPx) => {
+            // `zeroAnchored` substitutes the wheel's own pointer pixel for wherever
+            // `0` currently renders — read off the LIVE scale (post pan/zoom, both
+            // the container's and this axis's own), which is the pixel a viewer
+            // actually sees the baseline sitting at right now. Falls back to the
+            // pointer if `0` has no position at all (a log axis, which never
+            // admits it — `scaleLog()(0)` is `NaN`) rather than silently doing
+            // nothing.
+            // Used by the UNCONTROLLED branch below, which composes its transform in
+            // live pixel space. The controlled branch re-reads `0` off `baseYScales`
+            // instead — see there.
+            const zeroPx = row.yScales.get(id)?.(0);
+            const pivotPx = zeroAnchored && zeroPx !== undefined && Number.isFinite(zeroPx)
+                ? zeroPx
+                : wheelPivotPx;
             // Read the scale at gesture time, not from the render that built this
             // closure — a wheel notch mid-stream must compose onto what is drawn now.
             if (onBoundsChange !== undefined) {
@@ -139,13 +237,40 @@ export function YAxis({ id, side = 'left', label, scale = 'linear', linearWindow
                 const base = row.baseYScales.get(id);
                 if (base === undefined)
                     return;
+                // `pivotPx` above was read off the LIVE scale — the pixel a viewer
+                // sees, which is right for the uncontrolled branch because it composes
+                // a transform in that same space. Here the inversion happens in
+                // `base`'s pixel space, and the two differ by the container's own
+                // `yTransform`, so `0` has to be re-read there. Mixing them lets the
+                // baseline drift a few px per notch whenever the plot's y pan/zoom is
+                // active (`panZoom="panZoomY"` / `"panZoomXY"`) — precisely the motion
+                // `zeroAnchored` exists to forbid, and invisible without a plot-level
+                // y zoom, where the two spaces coincide.
+                const baseZeroPx = zeroAnchored ? base(0) : undefined;
+                // The fallback — and the ordinary, non-`zeroAnchored` case — is the
+                // pointer's own pixel, which is a SCREEN pixel and needs the same
+                // change of space. (#678 corrected only the `zeroAnchored` pivot,
+                // leaving the plain controlled wheel pivoting about the wrong point
+                // under a plot y zoom; the pan in this same file had the mirror
+                // defect on its delta. Three faces of one root cause: a screen-space
+                // pixel used where `base`'s pixel space is meant.) `ty` matters here
+                // because a pivot is an absolute position, not a delta.
+                const ownK = panStartRef.current?.k ?? 1;
+                const pixelK = container.yTransform.k * ownK;
+                const pixelTy = container.yTransform.ty;
+                const toBasePx = (screenPx) => Number.isFinite(pixelK) && pixelK !== 0
+                    ? (screenPx - pixelTy) / pixelK
+                    : screenPx;
+                const controlledPivotPx = baseZeroPx !== undefined && Number.isFinite(baseZeroPx)
+                    ? baseZeroPx
+                    : toBasePx(wheelPivotPx);
                 const [r0, r1] = base.range();
                 const lo = Math.min(r0, r1);
                 const hi = Math.max(r0, r1);
                 // Clamp into the scale's own range, not the gutter box: a
                 // `labelPlacement="top"` row reserves a header, so a press up there would
                 // otherwise pivot about a value the axis never draws.
-                const pivot = Math.max(lo, Math.min(hi, pivotPx));
+                const pivot = Math.max(lo, Math.min(hi, controlledPivotPx));
                 // `factor` scales the visible span, so the pixel window scales by its
                 // reciprocal about the pivot.
                 const at = (px) => +base.invert(pivot + (px - pivot) * factor);

package/dist/bars.d.ts

@@ -38,12 +38,25 @@ export declare function barExtent(cs: BarSeries): [number, number] | null;
  * - When the domain sits entirely below `0`: the bars hang from the **axis top**
  *   (`0` clamped down into the domain) — the symmetric case.
  *
- * I.e. `0` clamped into `[floor, top]`. The domain bounds come from the plain
- * `(value) => pixel` scale the row hands `draw`/`hitTest`; the runtime object is
- * a d3 `ScaleLinear` carrying `.domain()`, read through a localized shape rather
- * than widening the contract to d3-scale (same approach as `AreaChart`).
+ * I.e. `0` clamped into `[floor, top]`. The domain bounds come from `baseScale`
+ * when the caller has one — the axis's *declared* domain, resolved from
+ * `min`/`max`/auto-fit before any pan/zoom pixel transform narrows it — else
+ * from `yScale` itself. The runtime object is a d3 `ScaleLinear` carrying
+ * `.domain()`, read through a localized shape rather than widening the
+ * contract to d3-scale (same approach as `AreaChart`).
+ *
+ * **Reading `yScale` alone is the bug this parameter exists to avoid.** `yScale`
+ * is the *viewport* onto the axis — a gutter drag or wheel notch slides it
+ * without moving any bar's actual value. But a bare `yScale.domain()` read
+ * can't tell "the axis was deliberately configured to exclude zero" apart
+ * from "the current pan happens to have scrolled zero out of view" — so once
+ * a pan pushed the floor above zero, every bar's rendered top silently became
+ * `yScale(baseline)` instead of `yScale(value)`, reading as a bar's value
+ * changing under a gesture that never touched the data. `baseScale` is the
+ * declared domain, immune to that transform, so a transient pan can never
+ * relocate the baseline — only an author's own `<YAxis min>` can.
  */
-export declare function resolveBarBaseline(yScale: Scale): number;
+export declare function resolveBarBaseline(yScale: Scale, baseScale?: Scale): number;
 /**
  * The pixel rect of bar `i` — `[x0, x1, yTop, yBottom]`, with `x0 <= x1` and
  * `yTop <= yBottom` — or `null` for a gap (non-finite value). The x-span comes
@@ -442,7 +455,7 @@ export declare function stackBinExtent(ss: StackedBarSeries): [number, number] |
  * `0` into the domain, so this returns exactly `0` and the geometry is
  * unchanged.
  */
-export declare function stackBase(orientation: Orientation, xScale: Scale, yScale: Scale): number;
+export declare function stackBase(orientation: Orientation, xScale: Scale, yScale: Scale, baseYScale?: Scale): number;
 /**
  * The pixel rect `[x0, x1, yTop, yBottom]` (ascending on both axes) of bin `b`'s
  * segment `g`, stacked so it sits atop `cumBefore` (the summed value of the
@@ -475,7 +488,7 @@ export declare function segmentRect(ss: StackedBarSeries, b: number, g: number,
  *
  * O(N·G) over bins × groups, one fill (+ optional stroke) per drawn segment.
  */
-export declare function drawStacks(ctx: CanvasRenderingContext2D, ss: StackedBarSeries, orientation: Orientation, xScale: Scale, yScale: Scale, style: StackStyle, gapPx: number, minSpanPx: number, seriesId: string | undefined, selection: readonly StackMark[], hover: readonly StackMark[], banding?: BandLadder, spans?: readonly SpanSelection[]): void;
+export declare function drawStacks(ctx: CanvasRenderingContext2D, ss: StackedBarSeries, orientation: Orientation, xScale: Scale, yScale: Scale, style: StackStyle, gapPx: number, minSpanPx: number, seriesId: string | undefined, selection: readonly StackMark[], hover: readonly StackMark[], banding?: BandLadder, spans?: readonly SpanSelection[], baseYScale?: Scale): void;
 /**
  * Hit-test plot-pixel `(px, py)` against `ss`'s stacked segments — the **first**
  * segment whose rect contains the point, or `null`. The geometry is
@@ -491,5 +504,5 @@ export declare function stackAt(ss: StackedBarSeries, px: number, py: number, or
 /** Must match the draw's cap ([PND-BARWIDTH]) — this function's whole
  *  contract is that its rect is the drawn rect, so a cap applied to one and
  *  not the other silently drifts the hit target off the ink. */
-maxSpanPx?: number): [bin: number, group: number, begin: number, name: string, value: number] | null;
+maxSpanPx?: number, baseYScale?: Scale): [bin: number, group: number, begin: number, name: string, value: number] | null;
 //# sourceMappingURL=bars.d.ts.map

package/dist/bars.js

@@ -49,13 +49,26 @@ export function barExtent(cs) {
  * - When the domain sits entirely below `0`: the bars hang from the **axis top**
  *   (`0` clamped down into the domain) — the symmetric case.
  *
- * I.e. `0` clamped into `[floor, top]`. The domain bounds come from the plain
- * `(value) => pixel` scale the row hands `draw`/`hitTest`; the runtime object is
- * a d3 `ScaleLinear` carrying `.domain()`, read through a localized shape rather
- * than widening the contract to d3-scale (same approach as `AreaChart`).
+ * I.e. `0` clamped into `[floor, top]`. The domain bounds come from `baseScale`
+ * when the caller has one — the axis's *declared* domain, resolved from
+ * `min`/`max`/auto-fit before any pan/zoom pixel transform narrows it — else
+ * from `yScale` itself. The runtime object is a d3 `ScaleLinear` carrying
+ * `.domain()`, read through a localized shape rather than widening the
+ * contract to d3-scale (same approach as `AreaChart`).
+ *
+ * **Reading `yScale` alone is the bug this parameter exists to avoid.** `yScale`
+ * is the *viewport* onto the axis — a gutter drag or wheel notch slides it
+ * without moving any bar's actual value. But a bare `yScale.domain()` read
+ * can't tell "the axis was deliberately configured to exclude zero" apart
+ * from "the current pan happens to have scrolled zero out of view" — so once
+ * a pan pushed the floor above zero, every bar's rendered top silently became
+ * `yScale(baseline)` instead of `yScale(value)`, reading as a bar's value
+ * changing under a gesture that never touched the data. `baseScale` is the
+ * declared domain, immune to that transform, so a transient pan can never
+ * relocate the baseline — only an author's own `<YAxis min>` can.
  */
-export function resolveBarBaseline(yScale) {
-    const d = yScale.domain?.();
+export function resolveBarBaseline(yScale, baseScale) {
+    const d = (baseScale ?? yScale).domain?.();
     if (!d || d.length === 0)
         return 0;
     const floor = Math.min(d[0], d[d.length - 1]);
@@ -759,8 +772,14 @@ export function stackBinExtent(ss) {
  * `0` into the domain, so this returns exactly `0` and the geometry is
  * unchanged.
  */
-export function stackBase(orientation, xScale, yScale) {
-    return resolveBarBaseline(orientation === 'vertical' ? yScale : xScale);
+export function stackBase(orientation, xScale, yScale, 
+// The y axis's declared (pre-pan/zoom) scale — see `resolveBarBaseline`.
+// Vertical only: a horizontal stack's baseline lives on `xScale`, and x has
+// no equivalent "declared, pre-transform" scale to read yet ([PND-XBASE]).
+baseYScale) {
+    return orientation === 'vertical'
+        ? resolveBarBaseline(yScale, baseYScale)
+        : resolveBarBaseline(xScale);
 }
 /**
  * The pixel rect `[x0, x1, yTop, yBottom]` (ascending on both axes) of bin `b`'s
@@ -833,9 +852,12 @@ export function drawStacks(ctx, ss, orientation, xScale, yScale, style, gapPx, m
 // value against `y` when present, and its group against `rows` when present
 // (the group is this layer's label channel, so `rows` stays testable per
 // segment where `drawBars`' constant label lets the component resolve it).
-spans = NO_SPANS) {
+spans = NO_SPANS, 
+// The y axis's declared (pre-pan/zoom) scale — see `resolveBarBaseline` /
+// `stackBase`.
+baseYScale) {
     const G = ss.groups.length;
-    const base = stackBase(orientation, xScale, yScale);
+    const base = stackBase(orientation, xScale, yScale, baseYScale);
     // Threshold banding applies to a **plain** bar only. `G === 1` is exactly the
     // categorical / horizontal single-value bar (`categoryStack` builds a
     // one-group series); a genuine multi-group stack has no defined banding —
@@ -1015,9 +1037,13 @@ export function stackAt(ss, px, py, orientation, xScale, yScale, gapPx, minSpanP
 /** Must match the draw's cap ([PND-BARWIDTH]) — this function's whole
  *  contract is that its rect is the drawn rect, so a cap applied to one and
  *  not the other silently drifts the hit target off the ink. */
-maxSpanPx) {
+maxSpanPx, 
+// The y axis's declared (pre-pan/zoom) scale — see `resolveBarBaseline` /
+// `stackBase`. Kept in sync with `drawStacks`' own so a hit rect never
+// drifts from the drawn one under a live gutter pan.
+baseYScale) {
     const G = ss.groups.length;
-    const base = stackBase(orientation, xScale, yScale);
+    const base = stackBase(orientation, xScale, yScale, baseYScale);
     for (let b = 0; b < ss.length; b += 1) {
         // The same two accumulators `drawStacks` keeps — they must agree exactly or
         // the hit rect drifts from the drawn one.

package/dist/context.d.ts

@@ -822,7 +822,7 @@ export interface RowLayer {
      * chart. Layers whose hit target is already the drawn mark (stacks,
      * scatter, boxes, heat cells) ignore `mode`.
      */
-    hitTest?(px: number, py: number, xScale: (value: number) => number, yScale: (value: number) => number, mode?: 'hover' | 'select'): SelectInfo | null;
+    hitTest?(px: number, py: number, xScale: (value: number) => number, yScale: (value: number) => number, mode?: 'hover' | 'select', baseYScale?: (value: number) => number): SelectInfo | null;
     /**
      * Begin a **sweep session** over this layer's marks — `<MultiSelector>`'s
      * range query (interaction RFC A7.6/A7.7), the range analog of
@@ -896,8 +896,18 @@ export interface RowLayer {
      * {@link LayerDrawStats} (source/drawn counts + whether decimation engaged) so
      * the container can surface them via {@link ContainerProps.onDrawStats}; a
      * layer that returns `void` still contributes its measured `drawMs`.
-     */
-    draw(ctx: CanvasRenderingContext2D, xScale: (value: number) => number, yScale: (value: number) => number): LayerDrawStats | void;
+     *
+     * `baseYScale` is this axis's *declared* scale — resolved from `min`/`max`/
+     * auto-fit, before either the container's or this axis's own pan/zoom pixel
+     * transform narrows it (the same scale `row.baseYScales` exposes). A layer
+     * whose geometry depends on where the domain sits relative to a fixed value
+     * (a bar or stack resting on zero — see `resolveBarBaseline`) reads *that*
+     * domain for the decision, not `yScale`'s: the live scale is a *viewport*
+     * onto the axis, and a pan sliding that viewport away from zero must not
+     * relocate the bars' own baseline out from under them. Only bars currently
+     * use it; every other layer type ignores the extra argument.
+     */
+    draw(ctx: CanvasRenderingContext2D, xScale: (value: number) => number, yScale: (value: number) => number, baseYScale?: (value: number) => number): LayerDrawStats | void;
 }
 /**
  * A layer's per-drag **sweep session** ({@link RowLayer.beginSweep} — RFC

package/dist/select.d.ts

@@ -17,5 +17,5 @@ import type { LayerEntry, SelectInfo } from './context.js';
  * dispatch in `Layers` unit-tests without a DOM. (Layers passes its sorted
  * z-stack, the shared `xScale`, and its `axisId → yScale` resolver.)
  */
-export declare function resolveSelection(entries: readonly LayerEntry[], px: number, py: number, xScale: (value: number) => number, yScaleFor: (axisId: string | undefined) => ((value: number) => number) | undefined, mode?: 'hover' | 'select'): SelectInfo | null;
+export declare function resolveSelection(entries: readonly LayerEntry[], px: number, py: number, xScale: (value: number) => number, yScaleFor: (axisId: string | undefined) => ((value: number) => number) | undefined, mode?: 'hover' | 'select', baseYScaleFor?: (axisId: string | undefined) => ((value: number) => number) | undefined): SelectInfo | null;
 //# sourceMappingURL=select.d.ts.map

package/dist/select.js

@@ -16,13 +16,18 @@
  * dispatch in `Layers` unit-tests without a DOM. (Layers passes its sorted
  * z-stack, the shared `xScale`, and its `axisId → yScale` resolver.)
  */
-export function resolveSelection(entries, px, py, xScale, yScaleFor, mode = 'hover') {
+export function resolveSelection(entries, px, py, xScale, yScaleFor, mode = 'hover', 
+// The axis's declared (pre-pan/zoom) scale — see `RowLayer.hitTest`. Kept
+// alongside `yScaleFor` rather than folded into it: most callers have no
+// base-scale lookup at hand (a bar-free row, a test harness), and every
+// layer but bars ignores the extra argument regardless.
+baseYScaleFor) {
     for (let i = entries.length - 1; i >= 0; i -= 1) {
         const entry = entries[i];
         const yScale = yScaleFor(entry.axisId);
         if (yScale === undefined)
             continue;
-        const hit = entry.layer.hitTest?.(px, py, xScale, yScale, mode);
+        const hit = entry.layer.hitTest?.(px, py, xScale, yScale, mode, baseYScaleFor?.(entry.axisId));
         if (hit)
             return hit;
     }

package/dist/tradingTimeScale.d.ts

@@ -170,7 +170,7 @@ export interface TradingTimeScale {
      * The **date bands** — the segmented second row of the stacked style. One
      * entry per next-coarser calendar period touching the domain (day bands
      * under intraday ticks, month bands under day ticks, year bands under
-     * month/quarter ticks), each `{ start, label, shaded }`: the period's start
+     * month/quarter ticks), each `{ start, label, showLabel, shaded }`: the period's start
      * instant (the first band's `start` may precede the domain — its label pins
      * at the left edge), the left-aligned label, and a stable zebra `shaded`
      * flag keyed to the band's calendar identity (pan/zoom-invariant). The
@@ -181,6 +181,16 @@ export interface TradingTimeScale {
     bands(count?: number): Array<{
         start: number;
         label: string;
+        /**
+         * Whether the renderer should DRAW `label`. `false` when this band's start
+         * was clamped onto a live instant a tick already labels — the text would
+         * collide, but the band itself must still be emitted, because each entry
+         * is a segment boundary (the next entry's `start` closes it) and carries
+         * that segment's `shaded` parity. Dropping the entry instead deletes the
+         * period from the row, letting the previous band stretch across it under
+         * the wrong identity and shading.
+         */
+        showLabel: boolean;
         shaded: boolean;
     }>;
     domain(): [number, number];

package/dist/tradingTimeScale.js

@@ -192,22 +192,68 @@ export function scaleTradingTime(provider) {
     scale.bands = (count = 10) => {
         if (!hasCalendar())
             return [];
-        const bg = bandGrainFor(resolved(count).granularity);
+        const { ticks, granularity } = resolved(count);
+        const bg = bandGrainFor(granularity);
         if (bg === undefined)
             return []; // year grain — nothing coarser to band
         const fmt = base.tickFormat(count, bandFormatFor(bg));
-        const out = [];
+        const tickSet = new Set(ticks);
+        // A band's raw calendar start is a date, not necessarily a LIVE instant —
+        // a month or day beginning on a collapsed weekend/holiday clamps onto the
+        // next live moment. `bandNext`/`clampUp` are both monotonic, so every raw
+        // start that clamps to the SAME live instant is a contiguous run (a
+        // holiday week's Sat/Sun/Mon all land on the same Tuesday) — collected
+        // here as `{ s, live }` candidates before any label is built, so a run
+        // can be resolved as one group rather than emitting (and then trying to
+        // retract) a label per member.
+        const candidates = [];
+        let s = bandStartOf(domain[0], bg);
         // First band starts at (or before) the domain start — the partial left
         // band whose label the renderer pins at x=0; step to each next period
         // start still inside the domain. Bounded loop as a runaway guard.
-        let s = bandStartOf(domain[0], bg);
         for (let i = 0; i < 100_000 && s < domain[1]; i++) {
+            candidates.push({ s, live: provider.clampUp(s) });
+            s = bandNext(s, bg);
+        }
+        const out = [];
+        for (let i = 0; i < candidates.length;) {
+            const live = candidates[i].live;
+            let j = i;
+            while (j < candidates.length && candidates[j].live === live)
+                j += 1;
+            // One label per run: prefer the member that is ITSELF live (so a
+            // Tuesday reopening after a collapsed weekend reads "Tue", not the
+            // Saturday whose raw start merely happened to clamp onto it) — a run
+            // with no live member (the whole period is inside the gap) falls back
+            // to the first, since there is no better candidate. (Every member of
+            // the group shares `live` by construction — the test is `c.s ===
+            // c.live`, i.e. THIS candidate needed no clamping at all.)
+            const rep = candidates.slice(i, j).find((c) => c.s === c.live) ?? candidates[i];
+            // The band's raw start routinely coincides with a tick that is ALSO
+            // legitimately live (a month band and a day tick both anchored on the
+            // 1st is the ordinary stacked-axis look) — that is not the bug. Only a
+            // representative that itself needed clamping, and whose landing spot a
+            // tick already labels, duplicates one; skip it rather than draw a
+            // second, colliding label over the tick's own.
+            const collides = rep.s !== live && tickSet.has(live);
+            // Emit the band either way. A collision suppresses only its TEXT — the
+            // entry is also this period's segment boundary (the next entry's
+            // `start` closes it) and owns its zebra parity, so skipping it deletes
+            // the period from the row rather than de-duplicating a label: the
+            // preceding band then runs on to the next surviving start under its own
+            // shading and name. (Aug 1 2026 is a Saturday, so the August band
+            // clamps onto Mon Aug 3, which is already a day tick — dropping it left
+            // July painted across the whole of August.)
             out.push({
-                start: s,
-                label: fmt(new Date(s)),
-                shaded: bandShaded(s, bg),
+                start: live,
+                // Formatted from the representative's own RAW start, not the
+                // clamped one — a genuinely-live rep reads its own date; a
+                // gap-only run's rep reads whichever raw date it fell back to.
+                label: fmt(new Date(rep.s)),
+                showLabel: !collides,
+                shaded: bandShaded(rep.s, bg),
             });
-            s = bandNext(s, bg);
+            i = j;
         }
         return out;
     };

package/dist/use-axis-gestures.d.ts

@@ -14,8 +14,10 @@ export interface AxisGestureSpec {
      * - `'zoom'` — scales the axis about the grabbed pixel, reporting incremental
      *   span multipliers.
      *
-     * The x strip pans (the canvas gesture, one mental model for both surfaces);
-     * a y gutter zooms, which is the gesture the plot cannot offer per axis.
+     * Both the x strip and the y gutter pan on drag — the canvas gesture, one
+     * mental model for every surface. `'zoom'` remains available for a strip
+     * that wants drag-to-zoom instead, but nothing in this repo currently wires
+     * it up: wheel is the zoom gesture everywhere now.
      */
     drag: 'none' | 'pan' | 'zoom';
     /** Whether the **wheel** zooms this axis — again as it does over the plot. */
@@ -61,19 +63,17 @@ export interface AxisGestures {
 /**
  * Drag, wheel and double-click gestures for an axis strip.
  *
- * **The x strip behaves exactly as the canvas does** — drag pans, wheel zooms
+ * **Every strip behaves exactly as the canvas does** — drag pans, wheel zooms
  * about the pointer — so a chart has one gesture vocabulary rather than one per
- * surface, and the strip is simply a second place to reach the same view.
+ * surface, and a strip is simply a second place to reach the same view. A y
+ * gutter's pan moves only *that* axis (the plot's own vertical drag, where it
+ * exists, scales every axis in the row by one factor — the aspect lock; a
+ * gutter names a single axis instead).
  *
- * **A y gutter zooms on drag**, because that is the gesture the plot cannot
- * offer: the plot's vertical drag scales every axis in the row by one factor
- * (the aspect lock), while grabbing a gutter names a single axis. Up expands it,
- * down compresses it, about the grabbed pixel.
- *
- * The two shapes are why the drag reports differently per mode: a pan is
- * **anchored** (total delta from the press, re-derived from a snapshot — how the
- * plot's own pan avoids accumulating rounding), a zoom is **incremental** (a
- * span multiplier per step, composed onto the current view).
+ * The two `drag` shapes report differently: a pan is **anchored** (total delta
+ * from the press, re-derived from a snapshot — how the plot's own pan avoids
+ * accumulating rounding), a zoom is **incremental** (a span multiplier per
+ * step, composed onto the current view).
  */
 export declare function useAxisGestures(spec: AxisGestureSpec): AxisGestures;
 //# sourceMappingURL=use-axis-gestures.d.ts.map

package/dist/use-axis-gestures.js

@@ -26,19 +26,17 @@ const WHEEL_CURSOR_MS = 400;
 /**
  * Drag, wheel and double-click gestures for an axis strip.
  *
- * **The x strip behaves exactly as the canvas does** — drag pans, wheel zooms
+ * **Every strip behaves exactly as the canvas does** — drag pans, wheel zooms
  * about the pointer — so a chart has one gesture vocabulary rather than one per
- * surface, and the strip is simply a second place to reach the same view.
+ * surface, and a strip is simply a second place to reach the same view. A y
+ * gutter's pan moves only *that* axis (the plot's own vertical drag, where it
+ * exists, scales every axis in the row by one factor — the aspect lock; a
+ * gutter names a single axis instead).
  *
- * **A y gutter zooms on drag**, because that is the gesture the plot cannot
- * offer: the plot's vertical drag scales every axis in the row by one factor
- * (the aspect lock), while grabbing a gutter names a single axis. Up expands it,
- * down compresses it, about the grabbed pixel.
- *
- * The two shapes are why the drag reports differently per mode: a pan is
- * **anchored** (total delta from the press, re-derived from a snapshot — how the
- * plot's own pan avoids accumulating rounding), a zoom is **incremental** (a
- * span multiplier per step, composed onto the current view).
+ * The two `drag` shapes report differently: a pan is **anchored** (total delta
+ * from the press, re-derived from a snapshot — how the plot's own pan avoids
+ * accumulating rounding), a zoom is **incremental** (a span multiplier per
+ * step, composed onto the current view).
  */
 export function useAxisGestures(spec) {
     // The live spec, read by the handlers — so a listener attached once still sees

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pond-ts/charts",
-  "version": "0.63.0",
+  "version": "0.65.0",
   "private": false,
   "description": "Canvas-rendered, streaming-first time-series charts for pond-ts",
   "license": "MIT",
@@ -39,8 +39,8 @@
     "perf": "PERF_BENCH=1 playwright test perf.spec.ts --workers=1"
   },
   "peerDependencies": {
-    "@pond-ts/react": "^0.63.0",
-    "pond-ts": "^0.63.0",
+    "@pond-ts/react": "^0.65.0",
+    "pond-ts": "^0.65.0",
     "react": "^18.0.0 || ^19.0.0"
   },
   "devDependencies": {