UX second pass: icon-only header, pane-toggle cue, schema columns, facet cleanup

docs/architecture/10-interaction-and-feedback.md

@@ -231,6 +231,13 @@ last-focused control on re-entry.
 - The **Datasets** control is a plain **command button** (no `aria-pressed`) in the _same_
   toolbar — APG permits mixed control types — set off from the toggles by a visual divider (and
   optionally a nested `role="group"`), but kept in the roving sequence as its last element.
+- The **pressed (pane-visible) state has its own visual cue**: an inset accent edge bar plus the
+  full-strength glyph on the filled chip (the activity-bar convention). A fill alone cannot be
+  the state cue — hover uses the same one-step fill, so a fill-only pressed state is
+  indistinguishable from hovering an off toggle (the collision class arch 09 names for hover);
+  and a bar, not a border, keeps the strip boxless per the arch 09 box-discipline rule. The
+  unlabeled glyph rail itself is the established activity-bar convention (NN/g #4) — toggles
+  carry tooltips per Carbon's icon-button rule; no visible labels.
 - **Focus**: show/hide is only ever initiated **from the strip**, so the activating toggle
   already holds focus when its pane disappears and **retains it** (the button stays, flips to
   not-pressed) — no orphaned focus, no restoration logic. The strip is **never itself hidden**,
@@ -252,7 +259,10 @@ the Draft/Published view) is a **radio group**, never a row of `aria-pressed` to
   **toggle switch** was also weighed and rejected: APG defines `role="switch"` as on/off of a
   **single** setting, but Draft/Published selects between two **named peer views** with no
   natural "on" side — a radio group is the right semantics. Reserve the switch for genuine
-  on/off settings. Consulted via /council → APG switch / radio-group / tabs.)_
+  on/off settings. Consulted via /council → APG switch / radio-group / tabs.)_ A per-option
+  `title` (tooltip for a terse label) doubles as the option's accessible name, so it must
+  **lead with the visible label** ("Original — the natural size from the spec"), or
+  speech-input users can't address the control they see (WCAG 2.5.3 label-in-name).
 
 **Resolved — selectable lists.** A row the user selects must be a real `<button>` (or a
 proper option), not a click handler on `<li>` (mouse-only, no keyboard, no role). It is
@@ -453,6 +463,14 @@ in the keyboard order, never a heading. **The boundary is set where the list is
 module that decides the option order marks the divider-carrying option (e.g.
 `chartThemeOptions` stamps the first preset); a consumer must never recompute a group
 boundary by index arithmetic, which silently misplaces when the producer's ordering changes.
+A value list may carry an **action row** (the VS Code theme-picker pattern — e.g. "Edit
+themes…" inside the chart-theme picker): permissible because options are real buttons, not
+listbox options (APG's no-interactive-children listbox constraint doesn't apply); the row's
+label ends in "…" (the opens-further-UI convention) and sets the option's `hasPopup` so AT
+hears `aria-haspopup` — no special visual styling beyond an adjacent group divider. The
+default trigger caps its value label at **16ch with ellipsis**, so a long value (a preset or
+user-named theme) can't blow out a crowded pane header; the full label remains in the open
+list and the trigger's accessible name.
 The single-open registry means **disclosures cannot nest**: a SelectControl inside a
 settings popover would close — and unmount — its own parent on open. A control that needs
 its own popover sits beside the gear in the pane header, never inside the panel.
@@ -494,6 +512,15 @@ Datasets (⌘/Ctrl+K), or check the dataset name in your spec."_ — instead of
 must match the actual cause (NN/g #9, GOV.UK error-message). The thrown
 `DatasetNotFoundError` carries `datasetName` so the surface can name it.
 
+**Resolved — no affordance for unbuilt features.** A visible placeholder promising future
+functionality (the Chart Builder's dashed "+ row facet · LATER" shelf slots, removed
+2026-06-13) is roadmap language shipped to users: it speaks our planning vocabulary, not
+theirs (NN/g #2), and competes with the working controls around it (NN/g #8). A gated or
+later-phase feature gets **no placeholder, tag, or disabled stub** until it ships — disabled
+states are for _temporarily unavailable_ actions, not unbuilt ones. Design the layout so the
+future control can land without rework (e.g. shelf slots are row-shaped), and keep the
+roadmap in `docs/`, not in the UI.
+
 **Resolved — service-worker update prompt & persistent storage (web.dev seat).** The build
 uses `registerType: 'prompt'`, so a new service worker waits and never takes over a running
 session on its own — the app **must** tell the user, or "ask before updating" silently means