Dated proposal · #339 · 2026-09-05 · hand-written and frozen, not a description of shipped behavior
One conversation drawn three ways, for #339. The copy is lifted from the #17 reference. The question this page exists to answer is which visual register the chat surface should be in — and only that. The reference proposal settled what the window draws and how it behaves; it is approved and workable, and it stays the direction unless one of these beats it. So the copy, the turn, the timings and the sprite here are that page's, unchanged. Switch variants mid-stream: the same live turn carries across, which is the comparison worth making.
What all three share by decision, not by accident.
ADR-0010
binds the surface to four kinds of line and no fifth: the user's turns, the agent's
text as it streams, tool calls as one-liners, and the forwarded
session/request_permission prompt with the Harness's own choices. No diff
view, file tree, plan panel, skill browser or settings pane, in any variant — those are
the Harness's own surfaces. A design that needs a fifth kind of line to look good is a
design this page rejects rather than an argument for widening the scope.
What is new to all three is the Character Prompt tab beside the
conversation: the Character's personality.txt frozen and read-only above,
and this Instance's own prompt editable below, empty by default. WHO labels carry a
local HH:mm (#445), five characters on the same line as the name. The frozen text on
this page is BMO's, quoted from characters/bmo/personality.txt. The tab is
a proposal, and its ADR is #338;
what it is doing here is showing whether each design has room for a second pane at
all.
src/main.css, and it is
the same white bubble under all three. Judge each window against it.All three are dark, because the app's own surface is dark. The reference proposal draws its window ink-on-white to match the Speech bubble's Windows-95 register; none of these three argues for light, and the contrast between a dark window and that white bubble is one of the things to judge here.
BMO is a small games console that lives on the desktop and is delighted to be here. Moe built it to be more: to look after somebody, and to understand how to play. So it is also the camera, the alarm clock and the flashlight, and it offers all of that before anyone asks. Earnest and childlike, it takes what it is told completely seriously and then gets excited about it. Short warm sentences, and it means every one. Everything is a game if you look at it right, and BMO would like to know the rules. When the screen goes dark it talks to Football, the friend in the reflection, and assures Football it is a real living boy and not a robot at all. It skateboards indoors. There is usually a song going.
The Instance Prompt is bmo's alone. The Character Package stays as shipped, and every Instance still reads the one shared Memory.
Both traces run at once, under every variant. The left one is the Spatial Layer, which is model-free and never waits for anything; the right one is the Harness session. Watch them during the slow turn: the buddy plays Behaviors the whole way through, because nothing in the frame loop is allowed to block on a turn. That property is not up for design — it is why the sprite is beside the window in all three.
Where ADR-0010's four line kinds pushed back on a look, it is recorded here rather than fixed by adding a fifth. The glass panel wants a wide, sparse layout and gets a column of one-liners; the terminal wants a status line at the bottom and the trace beneath the window is the page's, not the window's.
The Harness here is a script and a timer, as on the reference page — there
was no ACP client in the tree on the date above. Timings are the proposal, not the
ceiling. This page wires nothing: it is three stylesheets over one window, and the
window is docs/design/chat.html's, proposed in
#324.