@@ -425,14 +425,29 @@ every Enter, because the reader erases exactly one line (hold Enter, get a colum
 leaves one rule per turn behind, travelling up the scrollback. One rule, below the input, is the shape
 that has neither problem.
 
-**Wiping the screen.** `/cls` clears the window and leaves the input and the block at the bottom —
-Ctrl-L does the same, bound by the line reader itself rather than by this project (a test pins that, so
-a keymap change cannot quietly take it away). `/clear` wipes the screen *and* drops the history: what is
-still on screen after a `/clear` is a conversation the model no longer has, which reads as if it were
-still in play. Neither touches the terminal emulator's own scrollback — what was written stays where
-the scrollbar can reach it. The block at the bottom is redrawn from a kept copy afterwards: JLine draws
-the pinned region only when its *content* changes, and a wipe does not change the content, it only takes
-it off the screen — so asking it to redraw does nothing and the bottom of the window stays empty.
+**Wiping the screen.** `/cls` clears the window and leaves the input and the block at the bottom, and
+Ctrl-L does exactly the same — the key is bound to this command rather than to the line reader's own
+clear, because the reader's own leaves the input somewhere else. `/clear` wipes the screen *and* drops the
+history: what is still on screen after a `/clear` is a conversation the model no longer has, which reads
+as if it were still in play. Neither touches the terminal emulator's own scrollback — what was written
+stays where the scrollbar can reach it.
+
+**It clears by scrolling, not by erasing**, and that is the whole implementation: a window's worth of
+blank lines, printed above the prompt. Erasing was tried in three shapes and each was reported as a
+defect. Erase then print blank rows to push the input back down: erasing clears the *visible* area and
+leaves those lines in the scrollback, so scrolling pulls them straight back into view — text above the
+prompt. Erase then move the cursor: the reader owns the cursor while it prints above the prompt, so a
+cursor move smuggled in there leaves its bookkeeping wrong and stranded a character above the prompt.
+Erase and stop: the input then sat at the top left, and worse — the reader redraws its prompt as a
+*difference* against what it believes is on screen, an erase invalidates that belief, and the measured
+result was no prompt on screen at all. Scrolling has none of those problems, because it is nothing but
+output: the screen goes blank, the scrollback keeps everything, the pinned block is never touched, and
+the cursor ends on its row because printing is what puts it there.
+
+**A useful side effect**: a screen that has lost rows on its own (see the resize note below) is repaired
+by `/cls` or Ctrl-L, because printing walks the cursor back down one row per line. That is the same
+recovery as pressing Enter a dozen times, in one keystroke.
+
 
 **Why the screen is scrolled once at startup.** The line reader draws its prompt where the cursor is,
 which is directly after the last thing printed; only the block below it is pinned to the window. On a
@@ -448,15 +463,94 @@ network. Each is an icon, a space, its value. Rows are cut by **screen columns**
 because an icon is one character and two columns — counting characters lets a row come out wider than
 the window, wrap, and push the pinned block out of place.
 
-**Resizing the window** is left to JLine, which resizes the pinned region and re-cuts its rows itself.
-A handler of our own was tried for a reported row of `> > > > >` after dragging the window smaller and
-made it worse: the line reader installs its own handler for as long as it is reading, so ours only
-added a second writer on the terminal while the reader was redrawing. A test drives the real path — a
-size change plus the resize signal, with the reader reading as it does all session — across shrinking,
-growing and a changed row count, and every one draws exactly one prompt. The leftover `> ` row that is
-still reported is therefore not produced there; the remaining suspect is the console reflowing its own
-screen buffer on a resize, which moves lines the program never wrote again and which nothing on this
-side can reproduce. `/cls` or Ctrl-L cleans it up.
+**Output is folded by the agent, not by the console**, to one column less than the window. That is what
+makes dragging the window survivable, and the reason is worth knowing: a line the console wrapped is *one*
+logical line over two screen rows, and Windows joins such lines again when the window is widened. The text
+above then needs fewer rows and everything below moves **up** — including the pinned block's last-drawn rows,
+which end up above the block where nothing writes again. One leftover per drag, which is where the rules
+climbing up the screen came from; narrowing does it in reverse and walks the input upwards. A line that was
+never soft-wrapped has nothing to join. The price: text keeps the line breaks it was printed with, so widening
+the window does not re-flow the conversation — the same trade an append-only console already makes.
+
+**Making the window narrower no longer erases the conversation.** The status bar's own housekeeping used to
+clear a band of rows on a geometry change and pulled the start of that band upwards "to account for wrapped
+status lines" — six rows above a three-row bar in a halved window, straight through the answers on screen.
+Measured: three answers, halve the width, two gone. Since a bar row is padded one column short it cannot wrap at
+all, so there was nothing to account for. That was the report "after making it narrower I cannot see it any
+more": the output was never scrolled away, it was erased.
+
+**The pinned block never writes the last column of a row**, which is what stopped the stacks of bars. A row
+padded to the full reported width wraps when that width is not the screen's real one — a dragged window reports
+a width before it has applied it — and a wrapped row takes two screen rows where the bar reserves one, so the
+bar's last row wraps past the bottom and scrolls it: the bar moves up and leaves a copy above, one per bad
+render. Leaving the last column alone costs nothing, because each row is addressed rather than reached by
+wrapping, and it also stops the terminal from marking the row as wrapped at all.
+
+**Changing the window's WIDTH clears the screen once you let go**, in either direction, and that is deliberate. A console reflows when
+the width changes: lines it had wrapped are joined again, the text above needs fewer rows, and everything below
+moves up — measured on a real console, a 32-row window widened from 86 to 111 columns left the cursor three rows
+higher, exactly the rows that joining freed. The pinned block's rows move up with everything else, the next
+redraw puts a fresh block at the bottom, and the carried-up copy stays above it: one leftover rule per size
+event, and a drag reports one every ~125 ms. It cannot be prevented — the console reflows before the program is
+told the size — and nothing can find the copy afterwards, because a program cannot read the screen back.
+Scrolling removes it, which is what `/cls` does and why that was always the repair. So the agent does it itself
+once the size settles. Narrowing needs the same treatment for the mirror-image reason: there the lines are split
+instead of joined, and the block's own rows — built for the old width — no longer fit and are re-wrapped across
+several screen rows. And then the conversation is **printed again**, folded for the width the window now has: the console remembers
+the lines it printed (the last few hundred, before folding), so after the wipe the recent ones come back and a
+paragraph that needed two rows in a narrow window takes one in a wide one. Dragging only the height changes
+nothing here, because without a width change nothing re-wraps.
+
+**After a height change the prompt is printed back down to its row.** JLine draws the prompt wherever the
+cursor happens to be, and a window whose height changes moves the screen's content by however many rows the
+console's buffer gives it — measured: growing a 20-row window to 26 left the input three rows too high, and
+shrinking it to 14 left it three rows too *low*, which means inside the pinned block, where it is drawn over
+and vanishes. The amount cannot be computed, but it is bounded by the height change, and printing moves the
+cursor down one row per line until it reaches its row and then simply scrolls — so the agent prints that many
+blank lines once the size settles. A width change costs nothing, because folding means a width change moves no
+rows at all. Shrinking is not repaired this way (the prompt would have to move *up*, which nothing can do
+without breaking the reader's cursor bookkeeping); `/cls` puts it back.
+
+**Resizing the window.** The pinned region is JLine's, but the rows in it are this project's: a rule built
+for a 113-column window stays 113 columns wide until somebody re-makes it, so the block is rebuilt whenever
+the window changes size, from a poll. A resize handler of our own was tried and made things worse — the line
+reader installs its own for as long as it is reading, so ours only added a second writer while the reader was
+redrawing.
+
+**And the redraw after the size settles is a repaint rather than a redraw**, which is what fixed "smaller was
+fine, bigger still breaks". The mechanism is worth knowing because it explains a report that survived every
+earlier fix. JLine pads each region row to the width the terminal *reports* and writes the rows one after
+another, relying on the terminal wrapping at the right margin to start the next one — so a screen that is
+**wider** than the reported width never wraps and the next row continues on the same screen line: a rule with
+the activity row cut short beside it, and the last row still looking perfectly correct. Windows gets there by
+a second route that does not correct itself: it **reflows** its screen buffer when the window is widened,
+joining rows it had marked as wrapped, which is every region row. JLine is never told, so its model still
+matches what it wrote, every later update computes an empty difference and writes **nothing**, and the joined
+rows stay for the rest of the session — which is exactly why holding Enter repaired it and no redraw did.
+Once the size stops changing, the block is therefore repainted unconditionally instead of compared.
+
+**The deeper half of that was in the library.** One measurement: a status update sends a single cursor
+address and then writes its rows back to back, each padded to the reported width — the second row begins on
+a new screen row only because writing the last column of the first one made the terminal *wrap*. So a screen
+wider than the reported width does not merely truncate: **every row of the block lands on one screen row,
+side by side**. And since the block is reserved from the bottom, what that pushes past the window ends up in
+the output area *above* it, where nothing writes again — one fragment per drag, which is why a dozen drags
+left a screen full of rule fragments and why `/cls` was the only thing that cleared them. The pinned region
+now addresses each of its rows instead of trusting the wrap.
+That needs a way to ask for a repaint, which the library did not have — `redraw()` is the same diff under another name, and `reset()` forgets the scroll region as well, so the next update grows the region by scrolling and leaves the old rows *above* the block. So a fifth fix is carried against JLine: a `Status.repaint()` that clears the model and nothing else. It is the only one of the five that adds a method, so it is called reflectively and skipped when absent: the agent must stay buildable with whatever JLine a copy of it finds, and the pom names the released version on purpose.
+
+What that cannot reach: the prompt is drawn by a display of its own with the same difference logic and no way
+in from outside, so a reflow that damages the prompt's row is still beyond repair from here. `/cls` or Ctrl-L
+cleans that up, because they only print.
+
+
+**A known JLine defect on Windows.** With a pinned block, typing without pressing Enter and then
+widening the window shows the prompt and the typed text once per keystroke, side by side. The repeats
+are written *while typing* — clipped past the right edge, so widening merely reveals them. It is
+reproducible with plain JLine and a three-row status block and **no** code from this project, is not
+fixed in JLine 4.4.6, and is not caused by resize signals; the write-up is in
+[`../docs/upstream-investigation-jline-status-windows-redraw.md`](../docs/upstream-investigation-jline-status-windows-redraw.md).
+Nothing on this side can honestly fix it. `--plain` pins nothing and is unaffected.
 
 **Three threads write to this console** and all of them had to be brought into line, because a write that
 goes around the line reader scrolls the screen without JLine noticing and the pinned block ends up
 
@@ -71,6 +71,19 @@ public interface AgentTerminal extends AutoCloseable {
      */
     boolean pinsStatus();
 
+    /**
+     * What kind of terminal this is, for the startup line.
+     *
+     * <p>The terminfo entry name on a real terminal — {@code windows-vtp}, {@code xterm} — because the entry
+     * decides how the pinned block is drawn and two of the fixes carried against JLine are about exactly
+     * that. A report from a console is much easier to read when it says which one it came from.
+     *
+     * @return the type, or a word describing this implementation when there is no terminal
+     */
+    default String terminalType() {
+        return "plain stream";
+    }
+
     /**
      * Wipe the window, leaving the input line and the block at the bottom.
      *
 
@@ -54,10 +54,20 @@ public String symbol() {
     /**
      * Symbol and name together, as the status line and {@code /mode} print them.
      *
-     * @return e.g. {@code "⏸ manual"}
+     * <p><b>Two spaces, and it is not a typo.</b> Reported as "beim auto mode hat immer ein Leerzeichen
+     * gefehlt": the transport symbols are drawn two columns wide by Windows Terminal while the column
+     * arithmetic counts them as one, so the glyph covers the single space that follows it and the name
+     * ends up touching it. The space is genuinely in the string — the screen-backed tests in
+     * {@link ScreenUseCasesTest} assert the badge survives to the rendered row, and they pass — so the
+     * disagreement is between the terminal's font and the width table, not in this code. A second space
+     * is the fix that works on both: where the glyph really is two columns wide the result looks like one
+     * space, and where it is one there is a wider gap, which is harmless. The same disagreement in a less
+     * harmless form is why {@link StatusLine}'s icons are basic-plane rather than emoji.
+     *
+     * @return e.g. {@code "⏸  manual"}
      */
     public String badge() {
-        return symbol + " " + label();
+        return symbol + "  " + label();
     }
 
     /**