fix(chat): prose tracks the workbench, and settings are clamped before CSS

Review on #72 found `0` documented as "follows the editor's UI font size" while the
code cleared the inline property and let a flat `--prose-size: 14px` win. Making the
description true was the better fix than making it match, because the flat value hid
a real defect: D2 argues prose should read a step ABOVE workbench chrome, and a flat
14px only satisfies that at the default 13px. Raise the editor's UI font for
accessibility and the relationship inverts — 14px prose inside 18px buttons, the
divergence pointing the wrong way, for the users who most need it not to.

`--prose-size` is now `calc(var(--vscode-font-size, 13px) + 1px)`, so the decision
holds at every workbench size. At 13px it still resolves to 14px: nothing moves for
anyone who has not changed it, and T1's ~108-character figure is unaffected.

Both settings are now clamped at the host boundary. `minimum`/`maximum` in the
contribution schema only drive the settings editor — it squiggles and saves anyway,
and a hand-edited settings.json, a synced profile or a bad merge never passes through
that UI. The values land directly in CSS, where `proseWidth: 1` is a one-pixel
transcript: a panel with nothing left on screen to open settings with, whose only way
out is finding the JSON file again. Out-of-range is pulled into range rather than
rejected — someone asking for a 200px measure wants it narrow.

`0` is now stated the same way in all four places it appears: it means "leave the
stylesheet alone", not "unconstrained" (the width's default is a 680px measure) and
not "follow the workbench" (the size's default tracks it, but by the stylesheet's
offset, not by the sentinel).

Guards, each bypass-verified by reverting the fix:
  - the size must be workbench-relative, with a px fallback, offset 1-3px, and must
    still resolve to 14px at the default — 4 separate failures
  - the clamp's ceiling must equal the schema's `maximum`, its floor must exceed the
    schema `minimum` (0, the sentinel), and the description must name both
  - 0/undefined/NaN/negative/Infinity fall back; below-floor snaps up; absurd snaps down

32 suites green.

Author: ndemianc

docs/CHAT-TYPOGRAPHY.md

@@ -78,9 +78,15 @@ This is the real trade-off in the whole document, so it gets stated rather than
 paragraphs of explanation at that size, at `line-height: 1.5`, is why the panel feels cramped next to
 the reference.
 
-**Decision:** message bodies get their own size (~14px) and leading (~1.65), expressed relative to a
-single custom property. Everything else — the composer, buttons, session cards, the status row,
-approval chips — keeps inheriting the workbench size, so the panel still belongs to the editor.
+**Decision:** message bodies get their own size and leading (~1.65), expressed through a single custom
+property. Everything else — the composer, buttons, session cards, the status row, approval chips —
+keeps inheriting the workbench size, so the panel still belongs to the editor.
+
+The size is an **offset**, `calc(var(--vscode-font-size) + 1px)`, not a flat 14px. Review caught the
+reason: a flat value silently inverts the decision for anyone who has raised the editor's UI font for
+accessibility — an 18px workbench would read 14px prose inside 18px chrome, which is the divergence
+this decision argues for, pointing the wrong way. At the default 13px it resolves to the same 14px, so
+the change is invisible to everyone who has not touched it.
 
 **The cost, honestly:** the chat will no longer match workbench chrome exactly. That is a real
 inconsistency, and it is the deliberate price of the panel being a place you *read* rather than a
@@ -117,10 +123,22 @@ for exactly this case).
 
 ### D7 — It stays hackable: two settings, no hard-coded values.
 
-`levelcode.ai.chat.proseWidth` (px, `0` = unconstrained) and `levelcode.ai.chat.fontSize`
-(`0` = follow the workbench). Both flow through CSS custom properties set on the container, so the
-defaults are a starting point rather than a verdict — consistent with the editor's whole posture, and
-the honest answer to anyone who preferred the old density.
+`levelcode.ai.chat.proseWidth` (px) and `levelcode.ai.chat.fontSize` (px). Both flow through the CSS
+custom properties above, set on the container, so the defaults are a starting point rather than a
+verdict — consistent with the editor's whole posture, and the honest answer to anyone who preferred
+the old density.
+
+**`0` means "leave the stylesheet alone" for both**, and nothing more. The first draft of this line
+claimed `0` = *unconstrained* for the width and `0` = *follow the workbench* for the size; neither was
+what the code did, and review caught both. The width's default is a 680px measure, not the absence of
+one — the way to widen it is a large number. The size's default now does track the workbench, but by
+the D2 offset, which is a property of the stylesheet rather than of the sentinel.
+
+Both are **clamped at the host boundary** (`clampSetting`, 8–24 and 320–2000). `minimum`/`maximum` in
+the contribution schema only drive the settings *editor*; a hand-edited `settings.json` reaches
+`getConfiguration()` unchecked, and these values land directly in CSS. `proseWidth: 1` is a one-pixel
+transcript — a panel with nothing left on screen to open settings with, whose only exit is finding the
+JSON file again. `webviewCss.test.js` pins the clamp to the schema so the two cannot drift.
 
 ---
 

extensions/levelcode-ai/extension.js

@@ -2083,6 +2083,24 @@ async function browseProviderModels(cfg, providerId) {
 	sendConfigToWebview();
 }
 
+// A settings number on its way into a CSS custom property.
+//
+// `minimum`/`maximum` in the contribution schema only drive the settings *editor*: it draws a squiggle
+// and saves the value anyway, and a hand-edited settings.json, a synced profile or a bad merge never
+// passes through that UI at all. Whatever is in the file is what `getConfiguration()` returns, and here
+// it lands directly in CSS — where `chat.proseWidth: 1` is a one-pixel transcript and
+// `chat.fontSize: 0.5` is a blank panel. Neither leaves anything on screen to open settings with, so
+// the way out is to find the JSON file again; clamping at the boundary is cheaper than that.
+//
+// Out-of-range is pulled INTO the range rather than rejected — someone who asks for a 200px measure
+// wants it narrow, so give them the narrowest readable one instead of silently ignoring them. Only 0,
+// a negative, or a non-number means "leave the stylesheet's own value alone".
+function clampSetting(raw, lo, hi) {
+	const n = Number(raw);
+	if (!Number.isFinite(n) || n <= 0) { return 0; }
+	return Math.min(Math.max(n, lo), hi);
+}
+
 function sendConfigToWebview() {
 	const cfg = aiConfig();
 	// Gateway mode (signed in — the gateway only routes when authenticated): the footer reflects the
@@ -2092,10 +2110,14 @@ function sendConfigToWebview() {
 	const groupActivity = cfg.get('chat.groupActivity', true) !== false;
 	// T2/T5 (docs/CHAT-TYPOGRAPHY.md D2, D7). Prose gets its own size because `--vscode-font-size` is the
 	// size of menu labels and tree rows — right for chrome, wrong for reading three paragraphs. Both are
-	// escape hatches by design: 0 means "follow the workbench" / "do not constrain", so anyone who
-	// preferred the old density has a one-setting way back rather than an argument.
-	const proseSize = Number(cfg.get('chat.fontSize', 0)) || 0;
-	const proseWidth = Number(cfg.get('chat.proseWidth', 0)) || 0;
+	// escape hatches by design, so anyone who preferred the old density has a one-setting way back
+	// rather than an argument.
+	//
+	// 0 means "leave the stylesheet alone" for both — the size then tracks the workbench
+	// (`--vscode-font-size` + 1px) and the measure stays at its 680px default. It does NOT mean
+	// "unconstrained": the way to widen the measure is a large number, not 0.
+	const proseSize = clampSetting(cfg.get('chat.fontSize', 0), 8, 24);
+	const proseWidth = clampSetting(cfg.get('chat.proseWidth', 0), 320, 2000);
 	if (providerMode() === 'gateway' && cloudSignedIn) {
 		const model = gatewayModel();
 		post({

extensions/levelcode-ai/media/chat.html

@@ -32,8 +32,13 @@
     /* T2 (D2) — the READING type. `--vscode-font-size` is the size of menu labels and tree rows: right
        for chrome, wrong for three paragraphs of explanation. Message bodies alone get their own size
        and leading; every control around them keeps inheriting the workbench, so the panel still
-       belongs to the editor. Both are overridable at runtime by the settings (D7). */
-    --prose-size: 14px;
+       belongs to the editor. Both are overridable at runtime by the settings (D7).
+       An OFFSET, not a flat 14px, so prose TRACKS the workbench instead of pinning against it. A flat
+       value quietly inverts for anyone who raises the editor's UI font for accessibility: at a 18px
+       workbench they would read 14px prose inside 18px chrome — the divergence D2 argues for, pointing
+       the wrong way. At the default 13px this still resolves to 14px, so nothing moves for anyone who
+       has not changed it. */
+    --prose-size: calc(var(--vscode-font-size, 13px) + 1px);
     --prose-leading: 1.65; }
   /* Log is a flex column → children default to flex-shrink:1. Any child with overflow:hidden (e.g. the
      approval/edit cards) then gets an auto min-size of 0 and the flex algorithm crushes it to an invisible

extensions/levelcode-ai/package.json

@@ -369,14 +369,14 @@
           "default": 0,
           "minimum": 0,
           "maximum": 24,
-          "markdownDescription": "Font size for chat **prose** (message bodies), in pixels. `0` follows the editor's UI font size.\n\nThe workbench size is tuned for menu labels and tree rows; message bodies default to a slightly larger size so a long answer reads comfortably. Controls, cards and the composer always follow the workbench."
+          "markdownDescription": "Font size for chat **prose** (message bodies), in pixels. `0` tracks the editor's UI font size, one step larger for reading — a 13px workbench gives 14px prose.\n\nThe workbench size is tuned for menu labels and tree rows; message bodies read a step above it so a long answer is comfortable. Controls, cards and the composer always match the workbench exactly. Values are clamped to 8–24."
         },
         "levelcode.ai.chat.proseWidth": {
           "type": "number",
           "default": 0,
           "minimum": 0,
           "maximum": 2000,
-          "markdownDescription": "Maximum width of the chat transcript, in pixels. `0` uses the default reading measure (680px).\n\nOnly has an effect when the panel is wider than the measure — in a narrow sidebar the container already bounds the line length. Set a large value to let the transcript fill the full width."
+          "markdownDescription": "Maximum width of the chat transcript, in pixels. `0` uses the default reading measure (680px) — it does **not** mean unconstrained.\n\nOnly has an effect when the panel is wider than the measure: in a narrow sidebar the container already bounds the line length. Raise it to let the transcript spread across a wide editor tab. Values are clamped to 320–2000."
         },
         "levelcode.ai.chat.groupActivity": {
           "type": "boolean",

extensions/levelcode-ai/test/webviewCss.test.js

@@ -302,7 +302,8 @@ test('TRANSCRIPT: prose has its own type, and chrome does not follow it', () =>
 	// size is tuned for menu labels; message bodies get their own. The scoping is the entire safety
 	// property: applied to `.msg` instead of `.msg .body` it would drag the role label, the copy
 	// button and the checkpoint control up with it, and the panel would stop matching the editor.
-	assert.match(css, /#log\s*\{[^}]*--prose-size:\s*\d+px/, 'the prose size is no longer a custom property');
+	assert.match(css, /#log\s*\{[^}]*--prose-size:\s*calc\(var\(--vscode-font-size[^)]*\)\s*\+\s*\d+px\)/,
+		'the prose size must be an OFFSET from the workbench, not a flat value — see below');
 	assert.match(css, /#log\s*\{[^}]*--prose-leading:\s*[\d.]+/, 'the prose leading is no longer a custom property');
 	assert.match(css, /\.msg \.body \{[^}]*font-size:\s*var\(--prose-size\)[^}]*line-height:\s*var\(--prose-leading\)/,
 		'prose type must be set on .msg .body');
@@ -314,6 +315,75 @@ test('TRANSCRIPT: prose has its own type, and chrome does not follow it', () =>
 		'the turn label must keep an absolute size, or it grows with the prose it is labelling');
 });
 
+test('TRANSCRIPT: the prose size TRACKS the workbench rather than pinning against it', () => {
+	// The bug a flat `--prose-size: 14px` hides, and the reason review's "0 doesn't do what the
+	// description says" comment was worth more than a wording fix.
+	//
+	// D2 argues prose should read a step ABOVE workbench chrome. A flat value only satisfies that at
+	// the default 13px: raise the editor's UI font for accessibility and the relationship inverts —
+	// 14px prose inside 18px buttons, the divergence pointing the wrong way, for exactly the users who
+	// most need it not to. An offset holds the decision at every workbench size.
+	const decl = /--prose-size:\s*([^;]+);/.exec(css);
+	assert.ok(decl, 'the stylesheet no longer declares --prose-size');
+	const m = /calc\(\s*var\(--vscode-font-size(?:\s*,\s*(\d+)px)?\)\s*\+\s*(\d+)px\s*\)/.exec(decl[1]);
+	assert.ok(m, '--prose-size must be workbench-relative, got: ' + decl[1].trim());
+
+	// The offset stays small: this is "a step above for reading", not a second font scale. Past ~3px
+	// the panel stops looking like part of the editor and D2's cost is no longer the one we accepted.
+	assert.ok(Number(m[2]) >= 1 && Number(m[2]) <= 3,
+		'the reading offset is ' + m[2] + 'px; beyond ~3px the chat stops belonging to the workbench');
+	// A fallback is required: `--vscode-font-size` is injected by the host, and the file opens in a
+	// plain browser during development, where an unresolved var() would void the whole declaration.
+	assert.ok(m[1], '--vscode-font-size needs a px fallback, or the rule is void outside the webview');
+
+	// And the default must still land on the 14px the doc and T1's character count were measured at.
+	assert.strictEqual(Number(m[1]) + Number(m[2]), 14,
+		'at the default 13px workbench this must still resolve to 14px, or T1\'s ~108-character figure moves');
+});
+
+test('TRANSCRIPT: settings are clamped at the host boundary, to the schema\'s own bounds', () => {
+	// `minimum`/`maximum` in the contribution schema are advice for the settings EDITOR — it squiggles
+	// and saves anyway, and a hand-edited settings.json, a synced profile or a bad merge never passes
+	// through that UI at all. These two land straight in CSS, where `proseWidth: 1` is a one-pixel
+	// transcript: a panel with nothing left on screen to open settings with, whose only way out is
+	// finding the JSON file again.
+	const ext = fs.readFileSync(path.join(__dirname, '..', 'extension.js'), 'utf8');
+	const src = /function clampSetting\(raw, lo, hi\) \{[\s\S]*?\n\}/.exec(ext);
+	assert.ok(src, 'clampSetting is gone — the settings reach CSS unchecked again');
+	const clampSetting = new Function(src[0] + '\nreturn clampSetting;')(); // eslint-disable-line no-new-func
+
+	const props = require('../package.json').contributes.configuration.properties;
+	for (const key of ['fontSize', 'proseWidth']) {
+		const call = new RegExp('clampSetting\\(cfg\\.get\\(\'chat\\.' + key + '\', 0\\),\\s*(\\d+),\\s*(\\d+)\\)').exec(ext);
+		assert.ok(call, 'chat.' + key + ' is read without clampSetting — the bound is decorative again');
+		const lo = Number(call[1]), hi = Number(call[2]);
+		const schema = props['levelcode.ai.chat.' + key];
+
+		// The pin: the number the host enforces IS the number the settings UI advertises. Raising one
+		// without the other is the drift this test exists to catch.
+		assert.strictEqual(hi, schema.maximum,
+			'chat.' + key + ' clamps at ' + hi + ' but the schema advertises ' + schema.maximum);
+		assert.ok(lo > schema.minimum,
+			'the floor must be a real readability bound, not the schema minimum (which is 0, the sentinel)');
+		assert.ok(new RegExp('clamped to ' + lo + '.' + hi).test(schema.markdownDescription),
+			'chat.' + key + ' does not tell the user it is clamped to ' + lo + '-' + hi);
+
+		// 0 is the sentinel, and it must survive the clamp — clamping it up to `lo` would make the
+		// default un-expressible and permanently override the stylesheet.
+		assert.strictEqual(clampSetting(0, lo, hi), 0, '0 must stay 0 — it means "leave the stylesheet alone"');
+		assert.strictEqual(clampSetting(undefined, lo, hi), 0, 'an unset value falls back to the stylesheet');
+		assert.strictEqual(clampSetting('nonsense', lo, hi), 0, 'a non-number falls back rather than emitting NaNpx');
+		assert.strictEqual(clampSetting(-5, lo, hi), 0, 'a negative falls back — CSS would drop it and behave unpredictably');
+		assert.strictEqual(clampSetting(Infinity, lo, hi), 0, 'Infinity falls back rather than emitting "Infinitypx"');
+
+		// In range, untouched. Out of range, pulled in — someone asking for a 200px measure wants it
+		// narrow, so give them the narrowest readable one instead of ignoring them.
+		assert.strictEqual(clampSetting(lo + 1, lo, hi), lo + 1, 'an in-range value must pass through unchanged');
+		assert.strictEqual(clampSetting(1, lo, hi), lo, 'a below-floor value snaps to the floor');
+		assert.strictEqual(clampSetting(1e9, lo, hi), hi, 'an absurd value snaps to the ceiling');
+	}
+});
+
 test('TRANSCRIPT: the heading scale has steps you can actually see', () => {
 	// The old 1.3/1.18/1.07 put 0.11em between h2 and h3 — 1.4px at 13px, i.e. three levels of
 	// hierarchy that were indistinguishable without selecting the text.