@artooi/ag-ui-web-component 0.41.2 → 0.42.0

package/CHANGELOG.md

@@ -7,6 +7,208 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.42.0] — 2026-10-07
+
+### Fixed
+
+- **A send is in flight from the moment it is taken, not from when its run
+  starts.** A send draws its turn and dispatches `ag-ui-submit` before it asks
+  the client for a run, and only the run counted. So a `sendMessage()` from an
+  `ag-ui-submit` listener, or a second call in the same task, passed every
+  guard and went out as a second request on the same client, with the
+  listener's turn drawn between the user's turn and its answer. Both are now
+  refused, so a listener that sends hears the event once, and the built-in
+  Send queues in that time as it does during a run. A listener that stops the
+  send -- a new chat, a thread switch, a change of `user-key`, moving the
+  element -- now stops it before its request is made. It used to go out into
+  the conversation that replaced it, which after a change of `user-key` put one
+  principal's turn at the top of the next one's conversation.
+- **ArrowUp reaches a turn queued behind a run, and one sent to resume or
+  fork a run.** Arrow-key recall recorded only a turn the composer sent at
+  once. A turn typed while a run was going entered it only if Stop discarded
+  the queue, so ArrowUp skipped it while it waited and after the queue sent it.
+  A turn sent from the checkpoint panel never entered it, though it was typed
+  in the composer like any other. Both are now recorded as they leave the
+  composer, and a turn taken back from the queue stays recallable, as one Stop
+  declined to send already did. Stop no longer adds the queue again, so the
+  history holds each turn once. Queueing or continuing with a turn you walked
+  back to now starts the next walk from the newest turn, as sending one did.
+  Turns a host sends with `sendMessage` are still not recorded, and the purge a
+  change of `user-key` makes still clears them.
+- **Retry and a checkpoint pick keep the rules a send keeps.** `retryLastTurn()`
+  checked only for a run in flight. A Retry made before a send's run had
+  started, or while a picked checkpoint was in flight, started a second run in
+  the same conversation. A Retry is now refused in both cases. It also counts
+  from the call, as a send does, so a `sendMessage()` or a second Retry made
+  before its run starts is refused and the built-in Send queues. A pick made
+  before a send's or a Retry's run has started is now refused with the same hint
+  as a pick during a run. A conversation store, or an activity or tool renderer
+  the Retry redraws through, that starts a new chat or changes `user-key` now
+  stops it, and `retryLastTurn()` returns `false`. The Retry used to go ahead,
+  drawing the old conversation into the new one and asking its answer again.
+  One new refusal follows from the same rule: a Retry from an
+  `ag-ui-run-finished` listener for a picked checkpoint's run returns `false`,
+  because the continuation is still in flight when that event fires. A
+  `sendMessage()` from the same place was already refused for that reason.
+- **A recall walk ends on any write into the composer, not only on typing.**
+  Walking back to a past turn with Up and then quoting text, from the
+  transcript or from the page through `offerQuoteInPage`, or clicking a skill
+  chip that prefills the composer, left the walk running: the next Up replaced
+  what had just been written with an older turn, and Down emptied the box. The
+  walk now checks that the composer still holds the turn it put there, so any
+  other write ends it, including a host page writing the composer itself.
+- **A `user-key` changed while the element is out of the document now hands
+  over when it is inserted again.** The attribute was acted on only while the
+  element was connected, and inserting it again is a reload that keeps the
+  composer's recall on purpose. So removing the element, changing the key and
+  inserting it again left the previous principal's stored conversation in
+  `sessionStorage`, their turns one ArrowUp away, their Always allow waivers
+  live, their shared state seeded into the next principal's first run, their
+  unread count on the launcher, and their threads in a drawer left open.
+  Connecting now compares the key the element's state belongs to with the
+  attribute, and runs the handover a live change runs when they differ. The
+  first key to arrive is still an adoption rather than a purge, and a move that
+  keeps the key, a key that goes away and comes back while detached, and a
+  first connect hand nothing over.
+- **A Stop your own code makes while a turn is starting now stops it.** A
+  conversation store, a `getContext` or `getTools`, or the save that answers a
+  tool call left open, that started a new chat or changed `user-key` during a
+  send or a Retry stopped nothing: the request still went out into the
+  conversation being left, with all of its history. Nothing is sent now. On
+  `AgUiClient`, a `cancel()` from `onPersist`, `getContext` or `getTools` before
+  the request is honoured and fires `onCancelled` and `onSettled` as any Stop
+  does, and a `cancel()` with nothing in flight is still forgotten by the next
+  `send()` or `resume()`. A Retry stopped this way resolves `true`, because the
+  provider runs after the Retry has handed its turn to the client.
+- **A Retry whose save the store refuses leaves the conversation as it was.**
+  `truncateToLastUser()` shortened the history before saving it, so a store
+  that threw left the answer on screen but out of the next request, and the
+  agent was then asked a follow-up about an answer it was never told it gave.
+  It now saves first, so a refused save changes nothing, and `retryLastTurn()`
+  rejects with the store's error.
+- **A reload that resumes a run no longer lets a second run start beside it.**
+  A reload in the middle of a navigating tool's run resumes that run once the
+  conversation store answers, and with a remote store that answer is a real
+  request. A send, a Retry or a checkpoint pick made while it was out was not
+  refused: the send went out without the stored conversation and its save
+  replaced it, then the resume ran beside it on the same client, answering a
+  call the conversation no longer held. A restore that will resume now counts
+  as in flight from the moment it asks the store, so `sendMessage()` returns
+  without sending, the built-in Send queues the turn behind the resumed answer,
+  `retryLastTurn()` returns `false`, and a pick says why at the composer. New
+  chat while the store answers stands the resume down. A host calling
+  `sendMessage()` as the element connects, on a page a navigating tool
+  reloaded, now has that call refused, as it would be behind any run.
+- **A conversation restore stops where New chat, leaving the page or host
+  code stopped it.** A restore stood down only for a newer restore or, when it
+  was about to resume a run, for the Stop New chat makes; a restore with
+  nothing to resume holds nothing for a Stop to let go of. So New chat pressed
+  while a remote store was still answering drew the conversation being left
+  into the new chat, and the first turn sent there carried that whole
+  conversation. An element removed meanwhile ran the host's renderers for a
+  node no longer on the page. An activity or tool renderer that started a new
+  chat during the replay had the rest of the old conversation drawn into the
+  new one, and after a reload mid-run, a renderer, the store's save of the
+  checkpoint or `navigationResult` doing the same still let the resume go out,
+  answering the navigating call from the new chat. Once any of these happens,
+  the restore now draws nothing more and resumes nothing. The navigation
+  checkpoint such a stop leaves behind is forgotten, so coming back to that
+  conversation later answers its navigating call as not finished rather than
+  resuming it from whatever page is current then. When the element only left
+  the page, the checkpoint is kept, and the run resumes once the element is
+  put back. That holds after a `reload()` the host made while the store was
+  answering, too: a restore standing down for a newer restore of the same
+  conversation leaves the checkpoint to it, and the restore that resumes is
+  the one that clears it.
+- **A run stopped by a change of `user-key` no longer saves into the next
+  principal's storage.** The handover stopped the run, but a stopped run saves
+  what it had once its request closes, and by then the store had been purged
+  and scoped to whoever arrived. The previous principal's question and partial
+  answer were filed under their own thread id in the next principal's
+  namespace, and the history drawer listed a conversation titled with a
+  question the new user never asked. A tool result returned after the Stop, a
+  stopped checkpoint continuation, and a key changed while the element was
+  detached did the same. A state snapshot already read off the wire put the
+  previous principal's shared state back after the handover had emptied it, so
+  it went out on the next principal's first run. A client built before a
+  handover now writes nothing at all. A key's first arrival is still an
+  adoption, so a run in flight across it keeps saving into the namespace it
+  moved to, and New chat still files a stopped run's last save under the
+  conversation it left.
+- **A change of `user-key` no longer replaces a conversation store the host
+  assigned after the element connected.** Connecting remembered the element's
+  own store, and a later key change rebuilt that store under the new namespace
+  whether or not it was still the one in use. A store the host assigned to a
+  connected element was swapped for a `sessionStorage` one, and a
+  `RemoteConversationStore` built with `cacheMessages: false` to keep message
+  bodies off the client started caching every one of them in the tab. A store
+  the host assigned is now left alone whenever it was assigned, and scopes
+  itself. The one exception is unchanged: a plain `SessionStorageStore`
+  assigned before connecting is the same kind as the element's own default,
+  so the element still namespaces it as its own.
+- **A change of `user-key` clears the composer.** The transcript and recall
+  history were already cleared so the previous principal's words were not in
+  front of the next one, but a turn they had typed and not sent stayed in the
+  box, on a live change and on one made while detached. A handover now empties
+  the composer, which takes a quotation or a skill's template with it. It also
+  takes down the skill hint, closes a slash palette the text had opened, and on
+  a live change stops a voice recording in progress before it is transcribed.
+  The first arrival of a key, a move that keeps the key, and New chat leave the
+  text where it is.
+- **A tool call whose run was stopped or handed over while it waited no longer
+  acts afterwards.** Dispatch awaited the host's `confirmPredicate`, the
+  confirmation card and the handler, and checked after none of them whether
+  the run was still going. A predicate that answered after Stop opened its
+  card or ran its handler for a run the user had ended, and a Confirm clicked
+  in the same task as Stop still ran the call. Across a change of `user-key`,
+  the previous principal's handler ran on the next principal's page, a
+  navigating tool's checkpoint went into the next principal's storage, and a
+  handler failing after the handover cleared their checkpoint instead of its
+  own. Such a call now settles as not finished and posts nothing, so the next
+  request answers it as not finished, and after a handover it draws and
+  writes nothing. Both checkpoint writes go to the thread the call was
+  dispatched under. A plain Stop while a handler runs still keeps its result,
+  since that action did happen on the page.
+- **A voice clip that comes back after a change of `user-key` is dropped, not
+  written into the next principal's composer.** The mic checked whether it had
+  been taken down only before it posted the clip, so a transcript already on
+  its way when the key changed landed in the composer the change had just
+  emptied, and a failed one drew its error on the old button. The permission
+  prompt had the same gap: a mic granted after the key changed or the element
+  left the page started a recording nobody could see or stop, and its tracks
+  were never released, so the browser's recording indicator stayed lit.
+  Removing the element while a clip transcribes now drops that clip too, as
+  removing it mid-recording already did, and that holds for a move that keeps
+  the key.
+
+## [0.41.3] — 2026-10-07
+
+### Fixed
+
+- **A resumed or forked run shows the turn it was sent with.** Picking Resume
+  or Fork in the checkpoint panel sent what the composer held and streamed the
+  answer, but drew no bubble for the turn, so the answer arrived under no
+  question. The save already held the turn, so a reload showed a question the
+  live transcript never had. The continuation now draws the turn the way Send
+  does, ahead of its answer, and tests hold that the live transcript and the
+  restored one agree after both a resume and a fork.
+- **`ag-ui-submit` fires for a continued turn.** A host listens to it as "the
+  user sent something", and a turn sent with Resume or Fork is one: only the
+  endpoint differs. The event fires once the continuation is the run in flight,
+  so a `sendMessage()` from a listener is refused rather than starting a second
+  run beside it, and a listener that stops it -- a new chat, a thread switch,
+  moving the element -- stops it before its request is made. Its
+  `detail.attachments` is empty, because a continuation sends only the
+  composer's text.
+
+### Changed
+
+- **Ships DOMPurify 3.4.16 and marked 18.0.14**, from the lockfile refresh
+  since 0.41.2. Both builds carry them inlined, the npm build as well as the
+  vendored bundle: only `@ag-ui/client` and `@ag-ui/core` are left to the
+  host's resolver, so a host's own lockfile does not choose which sanitiser
+  runs.
+
 ## [0.41.2] — 2026-09-23
 
 ### Changed
@@ -4222,7 +4424,9 @@ 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.41.2...HEAD
+[Unreleased]: https://github.com/Artui/ag-ui-web-component/compare/v0.42.0...HEAD
+[0.42.0]: https://github.com/Artui/ag-ui-web-component/compare/v0.41.3...v0.42.0
+[0.41.3]: https://github.com/Artui/ag-ui-web-component/compare/v0.41.2...v0.41.3
 [0.41.2]: https://github.com/Artui/ag-ui-web-component/compare/v0.41.1...v0.41.2
 [0.41.1]: https://github.com/Artui/ag-ui-web-component/compare/v0.41.0...v0.41.1
 [0.41.0]: https://github.com/Artui/ag-ui-web-component/compare/v0.40.0...v0.41.0

package/README.md

@@ -307,11 +307,28 @@ the `copyCode` / `copied` / `copyFailed` strings.
 `ag-ui-submit` event, run started. Use it for an "Ask about this order" button, a command
 palette, or a composer of your own replacing the built-in one. It no-ops for an entirely
 empty message, and while a run — or a checkpoint continuation picked from the panel — is in
-flight; a continuation counts from the pick, not from its first event, so the gap where two
-runs could start against one conversation is closed. Unlike the built-in Send it does **not**
-queue, so your composer keeps what it tried to send, and it does **not** consult the
-attachment tray: what you pass is what is sent, so your composer stays in charge of its own
-state.
+flight. A continuation counts from the pick, and a send from the call rather than from when its
+run starts, so a `sendMessage` from an `ag-ui-submit` listener, or a second call in the same
+task, is refused rather than starting a second run. So is one made while a reload resumes a run
+a navigating tool interrupted: the resume counts from the moment the element asks its
+conversation store for the conversation, so a `sendMessage` while a remote store is still
+answering is refused, and the built-in Send queues behind the resumed answer. Your own code
+that runs on the way to the request — the conversation store's save, `getContext`, `getTools` —
+can stop a send by starting a new chat or changing `user-key`, and then nothing is sent. Unlike
+the built-in Send it does **not** queue, so your composer keeps what it tried to send, and it
+does **not** consult the attachment tray: what you pass is what is sent, so your composer stays
+in charge of its own state.
+
+`retryLastTurn()` keeps the same rules, because it starts a run on the same conversation. It
+returns `false` while a run, a send, another Retry, a continuation or a reload's resume is in
+flight, and it counts from the call as a send does: until its run starts, a `sendMessage` or a
+second Retry is refused, the built-in Send queues, and a checkpoint pick is refused. It also
+returns `false` when your own code stops it before its run starts: a conversation store, or an
+activity or tool renderer it redraws through, that starts a new chat or changes `user-key`. A
+`getContext` or `getTools` that does the same stops it too, before anything is sent, but it runs
+after the Retry has handed its turn to the client, so the call resolves `true`. A store that
+throws from the Retry's save leaves the conversation as it was, and `retryLastTurn()` rejects
+with its error.
 
 `attachFile(file)` queues a file into the tray exactly as the picker and drag-and-drop do, with
 the same validation and progress chip. It returns `false` when uploads are not configured
@@ -655,7 +672,10 @@ AG-UI has no server-side cancel route: cancelling **aborts the streaming request
 `cancel()` with no run in flight is a safe no-op. `newChat()` cancels any in-flight run before
 discarding the client, and so do switching conversations, `reload()` and removing the element. A
 [checkpoint continuation](#resuming-a-run) is the run in flight while it lasts, so Stop and all of
-these end it too.
+these end it too. So does a turn that has not made its request yet: called from host code a send
+or a resume runs on the way — the conversation store's save, `getContext`, `getTools` —
+`cancel()` stops it before anything is sent, and `onCancelled()` and `onSettled()` fire as for any
+other Stop.
 
 A cancelled run ends a moment later, once its request has closed or a running tool handler has
 returned. What it does then stays with the conversation it belonged to: its truncated exchange is
@@ -717,7 +737,8 @@ Whether a call is gated is decided in this order:
    for others, which a static flag can't express). **A predicate that throws or rejects refuses
    the call**: no card, the handler does not run, the tool card settles as declined, and the agent
    gets the `confirmCheckFailed` string as the result and carries on, as after a decline. The
-   error goes to the console, never to the endpoint.
+   error goes to the console, never to the endpoint. A predicate still pending when the run is
+   stopped decides nothing: the call does not run, and its card settles as not finished.
 3. Else if the user has waived this tool name for the session, the call runs.
 4. Else the element falls back to [`isDestructive(parameters)`](src/tools/is_destructive.ts),
    which reads the `x-destructive` JSON-Schema flag.
@@ -1078,7 +1099,10 @@ matching JS API:
   server-backed store it stays on the server. Deleting one is the drawer row's own action. A chat
   nothing was ever sent in is the exception — it was never listed, so it is dropped rather than
   left behind. Focus moves to the composer, whichever control started the new chat, unless the
-  widget is collapsed, and the page is not scrolled to it.
+  widget is collapsed, and the page is not scrolled to it. A restore still loading or replaying
+  the conversation being left stops there, so nothing of it is drawn into the new chat, and a
+  run it was about to resume after a reload is not resumed: coming back to that conversation
+  later answers the interrupted call as not finished.
 - `describeSurface()` — where the panel is and what can be done to it: placement, collapsed,
   whether it can be moved, whether it fills the screen, its box and the viewport. `movable` folds
   the two reasons a move can fail into the one answer a caller needs.
@@ -1110,17 +1134,24 @@ that gap is parked too rather than racing it. What
 is waiting shows above the composer as chips, each of which takes its message
 back when pressed, and the next one is sent when the run settles. Stopping the
 run discards them: sending into a conversation someone has just stopped is the
-opposite of what stopping meant. It is not thrown away, though — a queued
-message has already left the composer, so it goes to the front of the recall
-history below rather than nowhere.
+opposite of what stopping meant. Nothing is lost, though — a queued message
+entered the recall history below when it left the composer, so **Up** gets it
+back after a Stop, and after its chip is taken back.
 
 The composer also walks back through what you have already sent, on **Up** and
-**Down** — the shape every shell and every coding agent uses. Only from an empty
-composer and only with the skills palette closed: an arrow inside text is how you
-move the caret, and taking it unconditionally would break editing to add a
-shortcut. Arrowing forward past the newest turn empties the box again, so the way
-out is the key that got you in. The history is this conversation's: starting a
-new chat, switching threads or changing `user-key` clears it with the transcript.
+**Down** — the shape every shell and every coding agent uses. It holds every turn
+that left the composer: one sent at once, one queued behind a run (from the
+moment it is queued), and one sent to resume or fork a run from the checkpoint
+panel. A message sent with `sendMessage` is not in it, because it was never
+typed there. Only from an empty composer and only with the skills palette closed:
+an arrow inside text is how you move the caret, and taking it unconditionally
+would break editing to add a shortcut. Arrowing forward past the newest turn
+empties the box again, so the way out is the key that got you in. A walk lasts
+only while the composer holds the turn it put there: anything else that writes
+the box — typing, a quotation, a skill, dictation, or the host page itself — ends
+it, so the next arrow moves the caret in what was written rather than replacing
+it. The history is this conversation's: starting a new chat, switching threads
+or changing `user-key` clears it with the transcript.
 
 ### Collapsing to the launcher
 
@@ -1858,7 +1889,7 @@ chat.addEventListener("ag-ui-feedback", (e) => {
   analytics.track("assistant_rating", e.detail); // { content, rating }
 });
 
-await chat.retryLastTurn(); // false when there is nothing to ask again
+await chat.retryLastTurn(); // false when there is nothing to ask again, or a run is in flight
 ```
 
 ## Quoting a selection
@@ -2091,6 +2122,16 @@ waived with *Always allow* are forgotten with it, so the next principal is asked
 sent on the next principal's first run, so a host that seeds shared state assigns it again for the
 principal who arrived.
 
+A handover also ends what the previous principal had in flight. Their run is stopped, and nothing
+it does afterwards is written into the next principal's storage or shared state: not the save a
+stopped run makes once its request closes, not a tool result that comes back after the Stop, not
+state already on its way. A tool call still waiting on `confirmPredicate` or its confirmation card
+does not run, one whose handler is still running draws nothing when it returns, and a navigating
+tool's checkpoint is never written into the next principal's thread. What they had typed into the
+composer and not sent is cleared with the transcript, quotations and skill templates included. A
+voice recording in progress is stopped before it is transcribed, and a clip already sent for
+transcription is dropped when its transcript comes back.
+
 Set it live, from script, as part of signing out or in:
 
 ```js
@@ -2102,10 +2143,17 @@ out through its own router without remounting anything, so the host naming the n
 dropping the attribute — is the only signal the element will ever get. Removing the attribute
 purges too, so a sign-out that simply clears it is safe.
 
+It holds for an element that is out of the document too, such as a view a router keeps alive.
+Nothing is purged while it is detached: the handover runs when it is inserted again, against the
+key it has by then, so a key that changes and changes back while detached hands nothing over. An
+element that is never inserted again leaves the previous principal's conversation in
+`sessionStorage` under their key, where only an element naming that principal again can reach it.
+
 The **first** value to arrive is treated as a host naming the user who was already there, not as a
 handover: the conversation in progress moves into the principal's namespace instead of being
 destroyed. So an element configured by an async auth handshake — the shape described in
-[Framework hosts](#framework-hosts-configure-before-you-insert) — keeps what is on screen.
+[Framework hosts](#framework-hosts-configure-before-you-insert) — keeps what is on screen,
+including a run still streaming and whatever is in the composer.
 
 Two things it deliberately does not do. It does not scope the panel's own collapsed / dragged-size
 / theme preferences, which are this element's UI state and carry no conversation content. And it
@@ -2141,6 +2189,15 @@ chat.conversationStore = new RemoteConversationStore(
 );
 ```
 
+A conversation store you assign yourself is never replaced by a change of `user-key`, whether you
+assign it before the element connects or after. The one exception is a plain `SessionStorageStore`
+assigned before the element connects: that is the same kind as the element's own default, which is
+all connecting can see, so the element namespaces it as its own and moves it on every key change.
+Assign it after connecting, or wrap it, to keep it yours. A store that keeps its data somewhere
+the element cannot see has to scope itself; the element purges only its own `sessionStorage`
+namespace and clears what is on screen. If your store wraps a `SessionStorageStore`, build a new
+one per principal.
+
 `SessionStorageStore.purge(namespace)` is the same primitive the element uses, for a host driving
 its own store from its own sign-out path.
 
@@ -2409,7 +2466,10 @@ Type the next turn in the composer, then pick a row:
 - **Resume** — continue that run.
 - **Fork** — branch it, leaving the original untouched.
 
-Both send to the matching server endpoint and stream into the same transcript.
+Both send to the matching server endpoint and stream into the same transcript. The
+turn you typed is drawn there ahead of the answer and announced with `ag-ui-submit`,
+exactly as a send is, so a host that keeps its own record of what the user said sees
+continued turns too.
 
 Picking a row with an empty composer says so above the input and puts the caret
 there, rather than closing the panel over nothing: a continuation sends **only**