0.34.0

• An icon on the rail, and the word when it is wanted (0.34.0)

The rail carried SESSIONS set vertically, and the word was the whole objection:
it is the only thing on this page a person has to tilt their head for, and it
names a category where everything else on screen names an action - Clear, Live,
Frozen, jump to latest.

It draws a panel icon now, at the top where a rail's first control goes, and the
word appears beside it the moment a pointer or the keyboard arrives. Drawn
rather than left to title, which waits about a second, takes the operating
system's colours, and never appears for a keyboard at all. 44px instead of 54,
so ten pixels go back to the conversation, and the target is still the full
height of the window. The accent on the edge stays: a line that is always there
is the edge of the room rather than a state indicator competing with the
background.

This was chosen by drawing four variants side by side at real proportions, with
the product's own tokens and the same panel behind each one, so the only
difference on screen was the way in. Two guesses had already been wrong - a bar
in the header, and then leaving it alone - and neither was going to be settled
in prose.

Taking the word off the rail left the column it opens with no title at all: the
panel's own heading had been deliberately empty because the rail beside it
carried the word, and nothing said so where the word was removed. It is back,
and the landmark now takes its name FROM the visible word rather than carrying a
second one of its own, so there is exactly one name and it is the one on screen.

That is also what the gate asks now. It used to forbid an aria-label outright,
which was right while the word was on the button and wrong the moment the button
became an icon. It asks the question that survives both shapes: is there a name,
and does everything that says a name say the same one.

And a row in the session list was 24 pixels tall minus one. Measured, not
guessed.

Five known-bad mutations, all killed.

• Dragging the pane wider now widens something

Reported as "the chat does not get wider", and measured doing exactly that: the
separator dragged from 530px to 1440 and the conversation stopped growing at
534. The rest of the pane turned into margin. A control that offers a range in
which nothing happens is a control that lies.

The measure cap was on the whole transcript. It belongs to the prose, which is
unreadable at 200 characters a line whatever the window is, and it does not
belong to the step rows - those are monospace data, they were already cut off
at 48 characters with the rest behind a disclosure, and every pixel the drag
hands them is a pixel of address somebody can read without opening anything.
Measured after: the step track goes from 416px at the default width to 1326px
dragged wide, and an address that was truncated fits whole. The prose stays at
68 characters either way.

The cap also had to be recomputed rather than carried over. It used to sit
outside the indent an answer carries, so the indent came off the text; it sits
inside that indent now, and the same 66ch would have bought 82 characters where
it used to buy 75. It is 58ch. That arithmetic is exactly what this page has
already got wrong twice, so the gate recomputes it from the file rather than
trusting a number in a comment.

Written as .answer > * rather than a list of element selectors, because a
compound beginning h3.md-h sits earlier in the file than the heading's own
rule, and two gates that read this stylesheet as text then found the wrong
declarations.

And the accent line down the rail is half the weight it was: a hairline that
says where the room ends rather than a rule that draws attention to itself.

Three known-bad mutations on the new gate, all killed. A fourth, putting the
line back to a full pixel, survives on purpose: nothing gates its thickness,
because that is a preference and not an invariant with a measured consequence.

• The pane is the measure, and both bars are on the grid

Two things, and the first is a correction to the commit before it.

Moving the measure cap off the transcript widened the step rows and left the
ANSWER exactly where it was, which is the text a person actually reads: dragged
wide, the sentences still wrapped in the same place. Reported a second time,
with a screenshot. So the cap came off the prose as well. The measure is not a
number this file picks any more, it is the width of the pane, and the separator
is the control that sets it - which is a better answer than a cap in either
place, because the person reading decides how wide their own reading is.
Measured: 67 characters over three lines at the default width, 120 over two at
900px, 198 on one line at 1440.

The default still has to land somewhere sane for anybody who never drags, so
the gate stopped reading a cap that no longer exists and computes the default
from the pane's own declared ceiling instead: 65 to 80 characters, the range
chat design guidance, Baymard and WCAG 2.1 AAA all sit inside.

Second, both bars grew, and one of them was off the grid. This file declares a
4px base and spends it everywhere else, and the header sat at 50 - twelve and a
half steps, which is not a step. A spacing system with one number off it is the
clearest sign there is no system, and it is the kind of number nobody questions
because it looks round in decimal. The rail is 48, a step wider and the figure
Material puts on a touch target. The headers are 56, six pixels taller and the
height an app bar has almost everywhere, which by Jakob's law is the height an
eye is already expecting. The control height stays 28, which is now exactly half
the bar rather than a number that happened to leave enough room.

• Every dimension is a published number, and the bar is the top of the room

Two changes, both asked for, and the second is a rule about all the others.

The horizontal band now runs the whole width, unbroken from edge to edge, and
the rail hangs under it. It could not do that while the rail was a column in the
same row as the panes: it cut the band in two at the left and the header started
48px in. So the rail leaves the flow, and the conversation carries those pixels
as padding on the two things the rail actually stands beside - the transcript
and the composer, not the header. Not a padding on the pane with a negative
margin on the header to undo it: that is the structural hack the guidance names
by name.

The drawer opens under the band for the same reason, and it PUSHES rather than
covering. An overlay drawer is the phone pattern; on a desktop the standard one
moves the content over. Covering was slicing every line of the conversation down
the middle, readable text with a panel sitting on its first 224 pixels.

And then the rule: every size here is a published figure rather than something
chosen. A scale somebody invents is a scale nobody can check.

16px body the default body size for the web and for Material, and
the first number every source names
12px labels a step above the 11px floor for captions
20px answer heading 1.25 from the body, inside the 1.2 to 1.333 band all of
them give for a type scale
13px monospace what those sources put on code, and off the prose scale
by decision: a mono face reads larger at the same pixel
and the step track is measured against it
48px rail, icon button the touch target
56px top bar the app bar height, which by Jakob's law is the height an
eye already expects
40px bar controls the standard button height, taken at the top of the 36
to 40 range
24px icons the standard icon size
256px drawer the standard drawer width

The ones that moved: the body from 15, which was mine; the controls from 28,
which was mine; Clear from a 24px floor of its own; the new-session button from
32; the icons from 16 and 14. The header had been 50 - twelve and a half steps
of a 4px base, and the kind of number nobody questions because it looks round in
decimal.

One defect found while resizing: an icon drawn at 12px from a 16-unit viewBox
scales its stroke to 1.2 while declaring 1.6, so the one-stroke rule was true in
the attribute and false on the screen. There is a gate now: the viewBox has to
match the drawn size, and then the number in the file is the number on the glass.

• The rail is the full height of the window again

Tried the other way round for one commit - the band across the whole width and
the rail hanging below it, from a drawing - and it goes back: the strip runs the
full height from the very top, so the icon sits in the corner ABOVE the header's
line rather than under it. It belongs to the room, not to the pane beside it.

What stays from the pass in between: the drawer pushes the conversation rather
than covering it, at the standard 256px, and every dimension is still a
published figure. The push is now the width the drawer takes BEYOND the rail it
replaces, since the rail is back in the row and pays for its own 48px again.