@artooi/ag-ui-web-component 0.26.0 → 0.26.1

package/CHANGELOG.md

@@ -7,6 +7,55 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.26.1] — 2026-08-25
+
+### Fixed
+
+- **A chart the server retracted stayed on screen.** When an update replaced a
+  chart with a payload that could not be drawn, the superseded chart was left in
+  place — showing numbers the server had already withdrawn, reading as current —
+  and then vanished on the next reload, because the *stored* content was the
+  version that could not be drawn. Live and reload now agree, and both say gone.
+
+- **`enableCharts()` after the element connected silently dropped every chart in
+  restored history.** History replays on connect, and charts were off at that
+  moment, so they were skipped. That is the ordinary way to call it — you have
+  to query the element to call anything on it — so the first call now redraws
+  rather than the docs asking for an ordering nobody can satisfy. The README
+  example was that order.
+
+- **A stacked chart wrote `NaN` into the DOM** for a series carrying more points
+  than there are labels. `renderChart` is exported, so it can be handed a spec
+  the validator would have refused; a cast there claimed that could not happen.
+
+- **A sparse `labels` array was accepted**, drawing a chart with blank axis
+  labels — `Array.prototype.some` skips holes.
+
+- **A spec inside the point budget could still block the main thread.** The
+  point limit bounds the data; the DOM is bounded by labels, since each emits an
+  axis node whatever the series count. Now capped at 2,000 labels, and the
+  ceiling applies again on every reload of a stored conversation.
+
+### Documentation
+
+- **Whether a pushed chart survives a reload depends on where the conversation
+  is stored**, and the README now says which is which. A client-side store keeps
+  activities; a server storing the thread as the model's message history does
+  not, because a pushed chart is deliberately not in that history. An
+  agent-requested chart survives either way — its spec travels as the tool
+  call's arguments.
+
+### Changed
+
+- **The handler/render split is now enforced by a signature rather than a
+  comment.** The replay path is handed the `render` function alone, never the
+  tool that owns it, so the code that runs on restore cannot reach `handler`.
+  The documentation claimed this guarantee was structural while the code passed
+  the whole tool around and relied on two call sites happening not to use it.
+
+- The built-in chart tool no longer builds the chart twice per call, once only
+  to choose its reply string.
+
 ## [0.26.0] — 2026-08-25
 
 ### Added
@@ -1613,7 +1662,8 @@ hosts that both arrange the page the way it expects.
 ### Notes
 - First release — exercising the automated npm OIDC publish pipeline end-to-end.
 
-[Unreleased]: https://github.com/Artui/ag-ui-web-component/compare/v0.26.0...HEAD
+[Unreleased]: https://github.com/Artui/ag-ui-web-component/compare/v0.26.1...HEAD
+[0.26.1]: https://github.com/Artui/ag-ui-web-component/compare/v0.26.0...v0.26.1
 [0.26.0]: https://github.com/Artui/ag-ui-web-component/compare/v0.25.2...v0.26.0
 [0.25.2]: https://github.com/Artui/ag-ui-web-component/compare/v0.25.1...v0.25.2
 [0.25.1]: https://github.com/Artui/ag-ui-web-component/compare/v0.25.0...v0.25.1

package/README.md

@@ -871,6 +871,16 @@ const chat = document.querySelector("ag-ui-chat");
 chat.enableCharts(["tool", "activity"]);
 ```
 
+Order does not matter. Calling it after the element is on the page redraws any
+charts already in the restored history, so you do not have to reach the element
+before it connects — which you generally cannot.
+
+Specs are bounded, and anything outside is dropped rather than half-drawn: at
+most **20,000 points** and **2,000 labels**, and every point a finite number no
+larger than **1e15**. The first two keep a stored transcript from blocking the
+main thread on every reload; the last one keeps the value range finite, since
+scaling divides by it.
+
 **`"tool"`** registers a `render_chart` tool the agent may call. The numbers are
 in its context, so it can talk about them; it costs one model round.
 
@@ -880,6 +890,13 @@ reaches the model, there is no extra round, and this is the only route that can
 **update a chart in place** — the server repeats the same `messageId` to redraw
 it, or sends an `ACTIVITY_DELTA` to move one series as a computation advances.
 
+**Whether a pushed chart survives a reload depends on where the conversation is
+stored.** A client-side store keeps activities, so it comes back. A server that
+stores the thread as the model's message history does not — a pushed chart is
+deliberately not in that history, which is the reason to push it. A chart the
+agent asked for survives either way, because its spec travels as the tool call's
+arguments and the component redraws from those without re-running anything.
+
 Either way the payload is the same shape:
 
 ```json
@@ -917,10 +934,13 @@ chat.registerTool({
 
 **`render` is the only half a restored transcript replays.** Replaying a tool's
 *effect* is out of the question — re-running a form-filling tool on every reload
-is a bug — so the restore path holds no reference to `handler` and cannot run
-it. That makes the guarantee structural rather than a promise, and it is why
-`render` has to be a pure, deterministic function of its arguments: it runs
-again every time the conversation is restored.
+is a bug. The replay path is handed the `render` function alone, never the tool
+that owns it, so the code that runs on restore cannot reach `handler` even by
+mistake: adding a "no render? fall back to the handler" convenience there means
+changing a type signature first, which is the moment the question gets asked.
+
+That is why `render` has to be a pure, deterministic function of its arguments —
+it runs again every time the conversation is restored.
 
 ---