A form's handler answers its own request, and a finished reply is finished

Two regressions, one of them much older than it looked.

htmx events bubble, and the composer's form declares `hx-on::after-request` so
it can clear itself after sending. Six things inside that form make requests --
the two scope switches, "ask me about these again", the agent mode select, the
effort select, and the jobs chip -- and every one of their afterRequest events
was reaching that handler. So changing the mode, or the effort, or toggling a
tool called `this.reset()` on a composer somebody was typing in and dragged the
view to the bottom. That has been true for as long as those controls have
existed. The jobs chip did not introduce it; it polls, so it made it happen
every five seconds, and that is the only reason it was ever noticed.

`event.target === this` is the whole fix, and it is what the attribute always
meant. Moving the chip out of the form would have left the other five.

The second: `steps.for_message` marked its trailing prose step as still being
written, so every finished reply ending in prose carried `msg__body--live` and
blinked a caret at the reader for ever. One flag was doing two jobs -- emit the
tail, and mark it live -- and a stored reply wants the first without the second.
They are separate arguments now.

Note what the existing test for that did: it asserted the caret was on the
*right* step, through `for_message`, and passed. It never asked whether a
finished reply should have one at all. It is driven through the live path now,
and the stored path has its own assertion.

The composer handler is driven under a DOM stub -- extract the body from the
template, fire the event from a descendant and from the form -- because a source
assertion can only say the guard is present, not what it does. Checked against
the bug before being kept: without the guard the stub reports the text wiped and
the thread scrolled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lembas/services/steps.py

@@ -63,6 +63,11 @@ def for_message(message: Any) -> list[Step]:
         thinking=(message.reasoning or "") if not message.error else "",
         events=list(message.tool_calls_json or []),
         marks=list(getattr(message, "steps_json", None) or []),
+        # A stored reply has a trailing step and it is not being written. Those
+        # are two facts and they used to be one flag: `include_open` both
+        # emitted the tail and marked it live, so every finished bubble ending
+        # in prose carried `msg__body--live` and blinked a caret for ever.
+        live=False,
     )
 
 
@@ -112,9 +117,18 @@ def _build(
     marks: list[dict],
     since: int = 0,
     include_open: bool = True,
+    live: bool = True,
 ) -> list[Step]:
     """The shared walk.
 
+    Two flags, because they are two questions and conflating them put a blinking
+    caret on every finished reply:
+
+    * `include_open` -- emit the trailing step at all. `closed_from` says no,
+      because the step still being written is carried by its own frames.
+    * `live` -- mark that trailing step as still being written. Only ever true
+      of a running generation. A stored reply has a tail and it is finished.
+
     Every offset is clamped and nothing here raises. A `steps_json` that
     disagrees with the three stores -- a row half-written when the process died,
     a hand-edited one -- has to degrade to a slightly odd order, never to a
@@ -132,7 +146,7 @@ def _build(
             steps.append(Step(index=0, kind=KIND_TOOLS, events=tuple(events)))
         if text:
             steps.append(
-                Step(index=0, kind=KIND_TEXT, open=include_open, html=render_markdown(text))
+                Step(index=0, kind=KIND_TEXT, open=live, html=render_markdown(text))
             )
         return steps
 
@@ -180,7 +194,9 @@ def _build(
         steps.append(Step(index=index, kind=KIND_THINKING, text=trailing_thought))
     if trailing_text := text[text_from:]:
         source = f"{carry}\n{trailing_text}" if carry else trailing_text
-        steps.append(Step(index=index, kind=KIND_TEXT, open=True, html=render_markdown(source)))
+        steps.append(
+            Step(index=index, kind=KIND_TEXT, open=live, html=render_markdown(source))
+        )
     if trailing_events := events[tools_from:]:
         steps.append(Step(index=index, kind=KIND_TOOLS, events=tuple(trailing_events)))
 

src/lembas/web/templates/chat/_composer.html

@@ -48,7 +48,22 @@
           {% if chat %}
           hx-post="/api/chats/{{ chat.id }}/messages"
           hx-target="#thread" hx-swap="beforeend"
-          hx-on::after-request="if (event.detail.successful) {
+          {# `event.target === this` is load-bearing, and its absence quietly
+             threw away typed messages for releases.
+
+             htmx events BUBBLE. This form contains six things that make
+             requests -- the two scope switches, "ask me about these again",
+             the agent mode select, the effort select and the jobs chip -- and
+             every one of their `htmx:afterRequest` events reached this handler.
+             So changing the mode, or the effort, or toggling a tool, called
+             `this.reset()` on a composer somebody was typing in and dragged the
+             view to the bottom. The jobs chip did not introduce that; it polls,
+             so it made it happen every five seconds, which is what finally made
+             it visible.
+
+             A form's own handler answers its own request. Anything else in here
+             that fetches is somebody else's business. There is a test. #}
+          hx-on::after-request="if (event.target === this && event.detail.successful) {
             this.reset();
             document.getElementById('attachments').replaceChildren();
             window.lembas.autosize(this.querySelector('textarea'));