Interface and layout

Document version: 1.0 (merged former WEBUI_DESIGN, responsive-breakpoints, LAYOUT_BASELINE_RULES, HOMEPAGE_LAYOUT_INTERACTION) Voice: Same as 产品规格.md — product copy follows user language. Implementation mapping: client/web/src/App.tsx, client/web/src/style.css

---

1. Visual and component spec

1.1. Visual theme and character

• Product positioning: an in-enterprise intelligent conversation tool; emphasize reliability, friendliness, readability.
• Overall style: simple, warm, low decoration; no showy animation.
• Mood keywords: professional, approachable, clear, sustainable to iterate.
• Information priority: high-frequency tasks (sign in, send a message) always own the main visual; low-frequency tasks (register, code sign-in, theme switch) are de-emphasized but reachable.
• Theme: Light, Dark, System (follow OS); the control sits in the top-bar top-right, implemented as icon + click to cycle (see §5.5).
• Optional Win12 skin: standalone file client/web/src/themes/win12.css, enabled with ?skin=win12 or VITE_SKIN=win12; see Win12风格主题规范.md §7; default remains this page’s §1.3 warm Sky theme.

1.2. Design principles (primary vs secondary)

• Sign-in dual main paths (password default): password sign-in and code sign-in are both official main paths; the default form is “phone/email + password”. The code path is reached by Tab, segmented control, or same-level switch, visible on the same layer as password — not the only hidden deep menu.
• Default state: first screen lands on password sign-in; after switching to code sign-in, show send-code and code input, with the same interaction weight as the password path.
• Secondary entries are low emphasis: register is a text link, not competing with the primary button.
• One screen highlights one primary CTA: avoid several high-saturation buttons competing at once.
• Critical paths are not hidden: low-frequency features may be de-emphasized, but not buried under many menu layers.

1.3. Color system and semantic roles

3.1 Primary and neutrals

• Primary: #0284c7 (Sky 600)
• Primary hover: #0369a1 (Sky 700)
• Secondary (gradient helper): #06b6d4 (Cyan 500)
• High-emphasis gradient (primary button): from #0284c7 to #06b6d4
• Success: #16a34a
• Warning: #d97706
• Danger: #dc2626

3.2 Light/dark theme semantics

• Light background: #f7f4ef / card #fffdf9
• Dark background: #030712 / card #111827
• Primary text (light): #111827
• Primary text (dark): #f3f4f6
• Secondary text (light): #6b7280
• Secondary text (dark): #9ca3af
• Border (light): #e5e7eb
• Border (dark): #374151

1.4. Type and typography

• Font stack: Inter, "Microsoft YaHei UI", "PingFang SC", system-ui, sans-serif
• Heading scale:

- H1: 30/36, 600 - H2: 24/32, 600 - H3: 20/28, 600

• Body: 14/22, 400
• Helper text: 12/18, 400
• Emphasis numbers/status: 14/20, 500

1.5. Component spec

5.1 Buttons

• Primary: high-contrast gradient fill (from #0284c7 to #06b6d4), white type, radius 12.
• Secondary: neutral background, text-color emphasis.
• Text buttons: secondary actions only (e.g. “Go register”, “Sign in with a code”).
• Forbidden: more than two primary buttons competing in the same view.
• Unified: site-wide primary buttons keep the same gradient direction and same-level shadow; do not mix solid primary buttons.

5.2 Inputs

• Height: 44 (desktop), minimum touch target 44×44.
• Unified states: default / hover / focus / error / disabled.
• Error hints sit nearby, and copy is actionable (tell the user what to fill).

5.3 Cards and containers

• Radius: 12 (cards), 10 (inputs), 8 (small controls).
• Shadow: light single layer; prefer border for hierarchy, not stacked heavy shadows.
• Vertical spacing inside a panel: from 16, stepping the 4/8 grid.

5.4 Combobox (dropdown pick)

• Site-wide: user-visible dropdown picks (form fields, filters, toolbar enums, and similar) must not use the browser native <select>.
• Components: static option lists use OptionListCombobox; special first-item semantics such as help conversations use HelpSessionCombobox (both in client/web/src/).
• Look and interaction: reuse .help-session-combobox-* styles (outlined trigger, animated dropdown, keyboard and a11y, collapse after pick); implementation and maintenance mapping: doc/skills/combobox-pattern.md.
• Field layout: title uses an ordinary container + copy span; do not wrap the whole combobox in <label>; align with existing action-assistant conversation rows, My agents status filters, and similar.
• Compact type size: in workspace A-tier forms (.capability-pack-field, data-connection forms, and similar) the combobox trigger is 12px, matching inputs on the same form.

5.5 Drawers vs dialogs

A side drawer (slides from one side, narrow, full height) is only for content that fits one screen without scrolling. When content would scroll inside a drawer, use a centered dialog: wider, related blocks can sit side by side, so reading does not bounce in a narrow strip.

• Drawer OK: two or three read-only summaries, three or four fields, a few buttons.
• Must use a dialog: multi-section notes (e.g. job duties + qualifications + people in post), long forms, comparison tables.
• When a list is long, give the list itself a thin scrollbar; do not treat the whole narrow drawer as a reading area.
• Blocks that can sit side by side (definition vs list) use two columns, so you do not scroll one side only to discover the other.

Implementation mapping: HR job/grade detail uses a centered wide dialog (.job-detail-dialog); coding convention: .cursor/rules/mindlink-drawer-vs-dialog.mdc.

5.6 Theme-switch control

• Three modes: Light, Dark, System (follow OS light/dark appearance).
• Placement: top-right of the app main-frame top bar (same place if the signed-in main UI and unsigned shell share a top bar; on a sign-in-only page it may also sit top-right of that page’s bar), not occupying the main content center, not competing with the primary CTA.
• Shape and interaction:

- Presented as an icon button (one control is enough; need not span three cells). - Click cycles in order: light → dark → system → light → … - The icon reflects the current effective mode (suggestion: light = sun/bright screen, dark = moon, system = “display + OS” or half-light half-dark; graphics can unify as a linear outline set).

• Assist: hover or long-press may show a Tooltip naming the current mode (e.g. “Light theme”, “Dark theme”, “Follow system”); optional repeat of the current value on a settings page, consistent with the top-bar control.
• Persistence: the user’s choice must persist (e.g. localStorage or sync with account preference, backend policy wins); in System mode, listen to prefers-color-scheme (or equivalent) and update the UI immediately.
• Visual: icons unify as linear outline, size aligned with other top-bar icon buttons; theme switch is never a primary action, only an environment preference.

5.7 Interface language

• Chinese by default. English is a second language, not a replacement.
• Follows the account. After sign-in, stored in account preference (“My account → Preferences → Interface language”); admin console on About and the sidebar; phone in “Me”. When unsigned, follow the browser (or device) language first. If none is recognized, Chinese.
• The product SPA does not use /en/... paths. Changing the setting switches immediately. The marketing site may still use a URL prefix for search engines.
• Translate product copy only. Names the user wrote, conversations, knowledge-base originals, workspace titles are not translated.
• English still uses user language. Buttons, empty states, help bodies use wording English users understand (workspace / help assistant / knowledge base).
• Plugins follow the host. Opening an app carries the current language; switching language changes in-app menus and hints together.
• Combobox. Language options use the console combobox; native <select> is forbidden.

1.7. Interaction and states

• Feedback timing:

- Visual feedback within 100ms of a click. - While submitting, forbid double-click and show an in-progress state (copy + inline spinner, see below).

• Button loading (in progress):

- Components: BtnBusyLabel, btnBusyInlineClass (client/web/src/BtnBusyLabel.tsx). - Usage: button adds btnBusyInlineClass(busy), aria-busy={busy}, disabled={busy}; content is <BtnBusyLabel busy={busy} label="保存" busyLabel="保存中…" />. - Styles: .btn--busy-inline, .data-sources-inline-spinner (spinner on primary buttons is a white stroke). - Pure icon buttons replace the icon with a spinner when busy; maintenance detail: .cursor/rules/web-ui-component-scale.mdc §9.

• Error handling:

- Form errors prefer field-level hints. - Request failures add a global hint.

• Empty states:

- Must include a suggested next action.

• Secondary-action placement:

- In-form secondary switches (e.g. “Use email instead”, “Sign in with a code”) prefer the right of the matching field label or the top-right of the input. - Avoid giving a secondary entry a whole row of primary-viewport height.

1.8. Sign-in / register special rules (aligned with current implementation)

• Default mode: phone-number sign-in.
• Default sign-in method: password.
• After switching to “Sign in with a code”:

- Show code input and send-code button. - Hide the password input.

• After switching back to password:

- Hide the code area. - Clear the code field so state does not linger.

• Register flow:

- Keep phone/email register available. - At register, password and code required/optional follow the API.

1.9. Do / Don’t

Do

• Show primary vs secondary with hierarchy and defaults, not “often used / rarely used” copy.
• Use consistent semantic color for status (success / warning / error).
• Keep readable contrast in both light and dark.
• Leave a visible entry for low-frequency features, but lower visual competition.

Don’t

• Do not make sign-in and register equal primary buttons.
• Do not show password sign-in and code sign-in as two primary forms at once.
• Do not write frequency labels such as “used by a few users” on the page.
• Do not let theme switch steal attention from the main flow.

1.10. Agent usage notes (for coding agents)

• Prefer guaranteeing the high-frequency path: sign in -> enter chat -> send a message.
• When changing UI, check whether primary/secondary is broken first, then visual consistency.
• New features default to a secondary entry unless a clear product decision promotes them to the main flow.
• When touching the sign-in page, must verify:

- Phone + password sign-in is reachable in one step - Code sign-in can switch and switch back - Register is reachable but does not steal the primary button

1.11. Notes on integrating awesome-design-md

• Borrow its structured writing (theme, color, type, components, layout, depth, Do/Don’t, responsive, Agent hints).
• Do not copy third-party brand visual assets (brand color, type, component style).
• Later, as the product evolves, gradually add:

- Component state tables - Page-level templates - Accessibility checklists (contrast, focus, keyboard)

---

2. Responsive breakpoints

Name mapping

In conversation you can say “large screen”, “medium screen”, “small screen”; use “medium-small” / “medium-large” only when the medium range needs splitting.

---

Small screen

• Width: < 600px
• CSS media query: @media (max-width: 599px)

---

Medium screen

Medium splits into two bands, cut by viewport width (CSS pixels) only, not device model. Medium screen = the whole tablet range; internally medium-small / medium-large.

How to tell medium-small vs medium-large

Medium-small

• Width: 600px - 780px
• CSS media query: @media (min-width: 600px) and (max-width: 780px)

Medium-large (wider / often includes common medium portrait and some landscape)

• Width: 781px - 960px
• CSS media query: @media (min-width: 781px) and (max-width: 960px)

---

Large screen

• Width: > 960px
• CSS media query: @media (min-width: 961px)

---

Console · Messages area (Cadau implementation mapping)

In client/web/src/App.tsx, the conversation list and main conversation area (product name C1-history) is still a three-tier UI (narrow / medium / wide), with splits nested in this file’s ranges:

Note: 781px is this page’s medium-small | medium-large split; the Messages area uses it to switch from “center rail” to “persistent conversation column”, without waiting for 961px. Constants: MESSAGES_SMALL_MIN_PX = 600, MESSAGES_DOCK_MIN_PX = 781. Style tokens: --bp-small-min, --bp-medium-large-split (781), --bp-large-min (961, for site-wide and large-screen semantics) in style.css. See this page §4 “C1-history”.

Console · Area B (agent sidebar console-nav)

Shares the 781px split with C1-history; “medium-small and below” matches the Messages-area center-rail strategy.

---

3. Layout baseline (A / B / C)

This file records confirmed layout rules for later pages to reuse, to avoid style regression or inconsistent language. Sub-numbers (A1, A2…) help reviews pinpoint location; they do not replace user-visible copy. Viewport width (small / medium / large and bands inside medium) follows docs/responsive-breakpoints.md; Messages-area C1 three-tier implementation aligns with it.

3.1 Region definitions

Top level (macro layout)

Area A substructure (console-topbar inside topbar-slot, signed-in main console)

Note: layout order is A1 → (right-aligned group) A3, A2, A3-cs (optional), Apps, A3-pre. A3-pre is Messages, in the same console-topbar-trailing as A3 (feature menu), A2 (account), A3-cs (local seat or support-group member), and Apps; Messages sticks to the right of that group. The Shell outside the slot often also has a brand link, theme switch, and similar; discussion may call that the top-bar outer area; it does not take this section’s A sub-numbers.

Area B substructure (console-nav mounted when a workspace is selected and the current module is Messages)

The agent-sidebar toggle (sidebar-toggle) in top-bar A1 appears only on this kind of screen, to expand/collapse B (on wide screens, collapsed B takes no space; on narrow screens it is still an overlay).

Area C

• Usually not numbered further; if you need the in-chat two columns, see C1-L / C1-R in this page §4.

---

3.2. Fixed-position rules

Area A (including A1, A3-pre, A3, A2 on the same row)

• Must stay fixed at the top (does not scroll with the page)
• Reference implementation:

- position: fixed - top: 0; left: 0; right: 0 - Total height is reflected by --header-h (single-row top bar matches the global baseline; see style.css :root)

Area B (including B1, B2)

• Must stay fixed on the left (does not scroll with C)
• Left flush (left = 0), no gap
• Corner radius cancelled (right angle where it meets the top bar)
• Reference implementation:

- position: fixed - left: 0 - top: var(--header-h) (flush with the bottom of A) - height: calc(100vh - var(--header-h))

Area C (Content)

• Main scroll area (content scroll does not affect A/B fixed)
• Must reserve width for B (margin-left or equivalent)

---

3.3. Spacing rules (core)

• Unified spacing variable: --panel-gap
• Current confirmed value: 12px

Hard constraints

1. C-A gap = --panel-gap
2. C-B gap = --panel-gap
3. Gap between C’s inner children = --panel-gap
4. Forbidden: stacking “container gap + child margin-bottom” into double spacing

Current implementation mapping

• main top padding: calc(var(--header-h) + var(--panel-gap))
• console-content left offset: calc(240px + var(--panel-gap)) (keep in sync if sidebar width changes)
• app-shell / app-sidebar: gap: var(--panel-gap)
• .card: margin-bottom: 0 (avoid stacking with gap)

---

3.4. Theme-consistency rules

• Layout variables must be defined on global :root, not only inside the light theme
• At least these variables must be available in all themes:

- --header-h - --panel-gap

---

3.5. Reuse suggestions for later pages

When a new page joins A/B/C layout, prefer the same variables and structure:

1. Header height always reads --header-h
2. All main-layout spacing always reads --panel-gap
3. Card spacing is preferably controlled by parent gap, not extra bottom margin inside the card component
4. In conversation, prefer this file’s sub-numbers (A1, A3-pre, A3, A2, B1, B2) to align position, not only “top” / “left”

---

3.6. Change-process suggestion

If spacing needs adjustment (e.g. 12 → 8 or 16):

1. Change only --panel-gap
2. Check whether the A–B–C trio still satisfies:

- C-A = C-B = child spacing

1. Verify light/dark themes stay consistent

If --header-h needs adjustment (e.g. top-bar line height or multi-row controls in the Shell), also check that B top / height still flush with A’s bottom edge.

---

4. Signed-in home regions and interaction

This section unifies discussion of signed-in home layout and interaction so product, design, and front/back end share one vocabulary.

Also see baseline rules: this page §3 (A/B/C fixed position and unified spacing).

4.1. Page overview

The current signed-in home has three layers (with fixed layout constraints):

1. Top header (Header, fixed at the top, does not scroll with the page)
2. Left console sidebar B (appears only on the Messages workbench: agent list; desktop fixed left, mobile overlay expand)
3. Right content C (main scroll area)

Code locations:

• client/web/src/App.tsx AppHome()
• client/web/src/style.css console-*, messages-*, app-*, and similar style blocks

---

4.2. Regions and duties

A. Top-bar slot (topbar-slot in Header, console-topbar)

Position: injected mid top-bar via the Shell topbar-slot, same row as brand and theme button.

Main duties: current workspace and entry controls; Messages is the last independent button of the right group (A3-pre, may include an unread-badge placeholder); support seats may see A3-cs; nine-grid feature menu (A3) and account (A2) sit to its left. Fine sub-areas A1 / A3-pre / A3-cs / A3 / A2 follow this page §3.

• Discussion tags: Header-Workspace, independent Messages entry, feature dropdown called Header-FeatureNav (aligned with baseline A3-pre / A3)

---

B. Fixed left column (console sidebar, console-nav, Fixed Left)

When it appears: a workspace is selected and the current first-level module is Messages; other modules (Skills, Workspace collaboration, Me…) do not mount B, and the top bar does not show the agent-sidebar collapse button.

Position: desktop left fixed column (left=0); on narrow screens, when this condition holds, the button in A1 overlay-expands/collapses.

Main duties: show the agent list related to this account (the selected item is who Messages sends to). Switching to other modules uses the top-bar independent Messages button (A3-pre) and feature menu (A3); substructure: this page §3 (B1 · B2).

Discussion tag: Sidebar-Agents-Rail

---

C. Right content (Content)

Position: main area on the right; only when B appears the left yields width to B (see .console-layout--has-agent-rail).

#### C1. Messages module (activeModule=chat, product-facing name “Messages”)

After entering a workspace, area C under Messages has two parts: conversations and history (C1-history) and current conversation main UI (C1-thread); if the user chose “view on the right” and this round already has files and similar results, work-results (C1-results) also appears. Implementation class names root at messages-workspace.

C1-history is for agent conversations only (help assistant, self-created agents): the same agent may have several historical conversations. When a colleague / friend / workspace group / group chat contact is selected, C1-history does not appear; the main area is one continuous IM timeline with that person (switch contacts in B, not by picking a “history conversation” in C).

##### C1-history (agent conversation list, adaptive three tiers)

Viewport width is watched on the front end; global width still follows this page §2 (small / inside medium medium-small | medium-large / large). Messages C1-history borrows the medium-small | medium-large split at 781px: 600–780 is “center rail + drawer”, ≥781 is “left conversation column stays” (including medium-large and large; no need to wait for 961px).

The same conversation data structure is shared across three tiers; only layout and entries differ.

##### C1-thread (current conversation main area)

• Work assistant: beside or under the agent name, the current topic (the user’s main goal, Markdown; default one-line summary; the left topic icon opens to edit the original; tapping the summary or the right button only expands/collapses). By default do not nag for review; after agent settings turn on “Prompt for review”, when the assistant judges it is done or sends an idle invite, Review appears in the composer or conversation menu (reading mode may hide it). After confirm it becomes “View review”. List and collapsed summaries skip small headings such as “main goal” and show the first sentence of the real thing to get done.
• With no messages, a centered empty state may hint; after messages, a bubble timeline; older messages can load upward (when pagination exists).
• Bottom: large-radius composer card, supporting text, attachments, Enter to send (Shift+Enter newline), sending and error hints.
• Streaming replies preview in the assistant bubble (aligned with implementation).
• Reply annotation improve: assistant-bubble “Mark up” → show original by paragraph, write notes under each → “Improve from notes” sends as a new user message; the agent outputs a rewritten full text.

- Reading mode (Web, html[data-reader-mode=on]): - Entry: conversation “More” menu, medium-rail/narrow toolbar, agent context bar; “Me → Preferences” can set default on (remembered on this machine). - Layout: bubbles become full-width continuous prose; “You / agent name” as small headings; high-contrast colors following light/dark theme; animations off. - Less noise: hide agent sidebar, conversation-history column, composer, bubble secondary actions, ratings, next-step suggestions, tool traces; reading toolbar collapsed by default, open from left/right edge handles. - Paging: tap left/right half, wheel, or arrow keys page by screen (not vertical scroll). - Nav: when the toolbar is expanded, a right-side question directory is available; jumps use instant scroll. - Reading bar: exit, five type sizes, Export as ebook (EPUB), Export as PDF (backend assembles the full set; PDF needs a Chinese font, set via MINDLINK_CHAT_EXPORT_FONT to a .ttf), Export conversation pack (can import into another agent).

##### C1-results (work-results area, optional)

• Entry: Me → Preferences → “In-conversation file preview” pick View on the right; when this round already has files, the composer shows a preview position icon; one tap switches between bubble and right, synced with preference. The bubble still keeps filename, download, and full screen; full preview moves to the right of the conversation. Bubble buttons toggle between show on the right and collapse.
• When it appears: the current agent conversation already has files and similar results (including an in-progress reply). With no results it takes no space; the feature menu and conversation history stay as they were.
• Auto yield: when the results area opens, feature menu (A3) and conversation history (C1-history) collapse automatically, giving width to conversation and results. The user can still open conversation history or the feature menu (hover or click); they can also collapse results and reopen when needed. Conversation history can be pinned: when pinned, appearing or collapsing work results no longer auto-collapses or expands that list; only the user’s own open/close remains.
• Several results: the results area lists this conversation’s files; previous / next pages continuously (loops at the ends), or tap a filename to jump; default shows the latest. When a new result appears, switch to the latest.
• Resize: the conversation-bubble area and work-results area can be dragged to resize; remembered on this machine.
• Narrow screen: the results area overlays the conversation from the right, without squeezing the composer away; still draggable to resize.

Discussion tags: Content-Chat, Content-Chat-History, Content-Chat-Thread, Content-Chat-Results

When no workspace is selected (localStorage has no workspace_id):

• Area B (agent sidebar) is not shown; C takes the full horizontal width (see this page §3 and .console-layout.no-workspace).
• When activeModule=chat, C does not show the Messages workbench (C1-history + C1-thread) above; it becomes the help assistant: centered layout, with composer and quick topics; empty state offers Create a workspace (default “My workspace”), Join a workspace (apply-to-join dialog), and Workspace collaboration / Me entries. On send, the front end assembles the repo-root help/ system knowledge tree (backend helpdocs retrieval) as context and calls the existing conversation API (placeholder strategy when there is no key).
• After selecting or creating a workspace (usually a full-page reload or local-state restore), B and the C1 Messages workbench return; on first enter with no work assistant of their own yet, Start appears automatically and a conversation with it opens.
• If the user jumps from the help-page top bar to another module (e.g. “Workspace collaboration”), the top of C shows a back to help assistant entry; sidebar B stays hidden while no workspace is selected.

Discussion tag: Content-Chat-NoWorkspace-Help

#### C2. Agents marketplace module (activeModule=agents)

• Currently a structured entry page (module cards)
• Later: template marketplace, My agents, and similar

Discussion tag: Content-Agents

#### C3. Skills center module (activeModule=skills)

• Shows the current skill list
• Later: install/start-stop/run entries

Discussion tag: Content-Skills

#### C4. Workspace collaboration module (activeModule=workspace)

• Workspace list
• Create a workspace
• Rename/delete a workspace
• Switch workspace

Discussion tag: Content-Workspace

#### C4b. Agent teams module (activeModule=teams, /agent-teams)

• Pick a team template or create roles from scratch
• Assign agents to roles, publish a task to meet, register coding crews
• A workspace must be selected; legacy /workspace?section=teams redirects here

Discussion tag: Content-AgentTeams

#### C5. Me module (activeModule=me)

• Current signed-in identity notes
• Account-related capability placeholders

Discussion tag: Content-Me

---

4.3. Recommended interaction discussion template

Later reviews should use this shape to reduce ambiguity:

• Region: Header-Workspace / Sidebar-Agents-Rail / Content-Chat / Content-Chat-History …
• Change type: add / adjust / delete
• Goal: in what scene the user should complete what action
• Acceptance: user-visible result (copy, buttons, flow, empty state)

Example:

• Region: Content-Chat
• Change type: adjust
• Goal: add a “common prompts” shortcut in the send area
• Acceptance: tap fills the composer automatically, does not send

---

4.4. Current implementation vs requirements (short)

• Aligned:

- The top includes workspace and account entries and stays fixed at the top; Messages is a single top-bar button; local seats or support-group members have a separate Support button (A3-cs); other first-level modules (including Support workbench for admins who are neither seats nor group members) live in the feature menu (A3) - Area B (agent list) appears only when a workspace is selected and the current module is Messages; the top-bar agent collapse button matches. Under other modules, C takes the full available horizontal width (no B) - Messages module (C1) with a workspace selected is conversation area (three-tier adaptive) + main thread, see C1-history / C1-thread above - With no workspace selected, the Messages entry opens the help assistant (document source: help/ system knowledge tree, backend helpdocs retrieval), not the C1 workbench

• Still to complete:

- Agents marketplace module wired to backend APIs - “Me” module refined into profile/security/preferences pages - Conversation-area three tiers: <600 / 600–780 / ≥781 (781 is the spec’s medium-small|medium-large split), consistent with this page §2 console subsection

---

4.5. Layout behavior constraints (for acceptance)

1. Header stays fixed at the top and does not leave the viewport because of page scroll.
2. When B’s appear condition holds, left console-nav (B) stays fixed left; the agent list can scroll independently.
3. When right Content scrolls, in common desktop layout it does not affect Header; if B exists, it also does not affect B staying fixed.
4. Narrow screen and on the Messages workbench: if B exists, overlay expand/collapse via the top-bar button (not the same layer as the C1-history conversation drawer).