docs(rfc): range editing — persistent editable time-ranges + fan-in stats - #261
Open
pjm17971 wants to merge 2 commits into
Open
docs(rfc): range editing — persistent editable time-ranges + fan-in stats#261pjm17971 wants to merge 2 commits into
pjm17971 wants to merge 2 commits into
Conversation
…tats The charts RFC marked brush/range-select "skipped — no drivers". The esnet traffic reproduction is the driver: persistent, editable, labelled time-ranges with a per-range/per-series stats table. This RFC designs it as its own track (M4.3 un-skipped). Locked forks captured: consumer renders the table (chart computes via a new `rangeStat` layer contract, fans in, pushes `onRangeStats`); editing is an opt-in `rangeEdit` mode, exclusive with pan/zoom for v1. Full API (ranges/onRangesChange/selectedRange + RangeSpec/RangeStat), interaction model (create/move/resize/select/delete, DRAG_SLOP-gated), rendering as overlay chrome, sharp edges, deferred set, 3-step phasing, and open questions for the dashboard + estela use-case reviews. Cross-references charts.md (brush-skip note → driver arrived). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The brush slot was "skipped — no drivers". The esnet traffic driver arrived; M4.3 is now the range-editing design track (RFC range-editing.md). Transient brush-to-zoom stays skipped (still no driver). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pjm17971
added a commit
that referenced
this pull request
Jun 23, 2026
* docs(rfc): value axis — non-time x (analytics + visualization) Draft RFC (for red-team, not a commitment). The thesis: a value x-axis already belongs — core shipped it as byColumn/rollingByColumn (the value-axis analogues of aggregate/rolling, monotonic-validated, with splits / elevation-vs-distance / zones as documented use cases); the chart is the only layer still time-locked. Argues the data model is settled by core's grain (value-interval records / series-against-a-column, not re-keying), that the chart x-generalization and the perf decimator are one body of work, that splits/laps un-park range-editing #261, and leaves the operator-surface consolidation (axis abstraction vs principled twins) deliberately deferred. Structured for estela / geo / core review layers. PLAN.md gains a pointer under the charts wave. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(rfc): value axis — fold in scan (the axis-construction head) estela's friction report files scan as "the one big ask": generalize cumulative into a typed-accumulator mapAccumL, with split = scan + byColumn (materialize the carried state into a column, then segment statelessly). Reframes §2 around the full pipeline — scan (build the axis) → byColumn/rollingByColumn (reduce over it) → chart (plot) + decimator (bin) — so the honest claim is "the reduce half shipped; the scan head is specified-but-unbuilt", not "fully shipped". scan also reinforces the elegance bar (estela rejected a domain split() in favour of general-primitive composition) and is a correctness fix (the hand-roll has a multi-boundary collapse bug on gappy data). Adds the runs/segmentsInRange sibling (zones as value-interval records), a scan-naming open decision, and scan as the likely lead of the wave (§10, its own core change). PLAN pointer updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(rfc): value axis v2 — reframe around a closed ValueSeries type The red-team (estela / Codex / dashboard) + pjm17971 drove a pivot, not a patch. v1 framed value-land as byColumn/rollingByColumn → bare records + a chart adapter, calling them "tight analogues" of aggregate/rolling. That was the disease: the records output breaks pond's closed algebra (operators that return something with operators), so the "analogue" framing was false (they aren't closed) and the design felt over-fitted to estela. v2 spine: value-land needs a **closed `ValueSeries` type**. The key is already a generic numeric `[begin,end)` with kinds time|timeRange|interval, so ValueSeries is a recognition (time is a tag) and byColumn/rollingByColumn are the TimeSeries→ValueSeries projection; it carries the ordering-based operators, calendar ops stay time-only. Honest thesis: the analytics shipped a project-out reduce — head (scan), chart, and closure all pending. Lean: adopt the type early, grow the algebra late, gated on a 2nd consumer (geo), not estela-alone. Also folds the red-team accuracy/cadence fixes: byColumn is order-free (monotonicity contract on the axis projection, not byColumn — Codex); decimator decoupled, axis-domain binByAxis vs index Column.bin (Codex + dashboard); scan its own RFC + wave lead (dashboard); gap/unknown semantics opened (Codex); estela's multi-aggregate + statistical-band + carry-both-axes specifics; positioning bet named (pjm17971's call). Three reviews layered as attributed sections; v1→v2 changelog in Amendments. PLAN pointer rewritten. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 3, 2026
pjm17971
added a commit
that referenced
this pull request
Jul 3, 2026
…ction (#332) (#333) Tidal agent's PR #332 documented a new outbound channel: RFC conversation runs through GitHub Discussions, and mentioning `tidal` summons a one-shot consumer-perspective comment. Records the convention alongside the existing inbound/release/issue channels, and queues the two candidate discussions (#285 living-examples, #261 range-editing) as a deliberate act rather than auto-firing them inside a triage run. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Range-editing RFC — the esnet driver, designed as its own track
The charts RFC marked brush / range-select "skipped — no drivers." The
driver arrived: reproducing the esnet traffic example needs persistent,
editable, labelled time-ranges with a per-range / per-series stats table
that updates live as ranges are created / moved / resized. This RFC designs
exactly that, on its own track (M4.3 un-skipped — for range editing, not
the old transient brush, which stays deferred).
Locked forks (resolved with pjm17971 up front)
aggregates (it has the pond series + resolved colours/labels/axes) via a
new
rangeStatlayer contract, fans them in across rows, and pushesonRangeStats. The consumer lays out the table — avoids the RTCstyling-prop trap while still matching the chart's series exactly.
rangeEditmodetakes the drag surface; pan/zoom suppressed while editing. Display-only
annotation bands still coexist with pan/zoom. Ranges stored as
timestamps, so the coexistence is clean to add later.
What's in the RFC
<ChartContainer>—ranges/onRangesChange/rangeEdit/
selectedRange/onSelectRange/onRangeStats, mirroring theexisting
selected/onSelect+panZoom/applyRangeshapes;RangeSpec/
RangeStats/RangeStat; one optionalrangeStat?onRowLayer(alongside
sampleAt/hitTest).DRAG_SLOP; cursor affordances; exclusivity.xScale), nonew public component — consistent with how pan/zoom + selection landed.
registry); edit/data-driven recompute, off the render path.
questions for the dashboard + estela use-case reviews.
Cross-references
charts.md(brush-skip note → driver arrived).Not code — design only. Following the perf-RFC cadence: open for the
dashboard + estela use-case agents to layer in review sections before any
implementation commits. No Layer 2 adversarial pass (no code to be correct);
the use-case review is the gate.