See the complete route index at https://crusible.dev/llms.txt before following links.

# Surfaces answer to the conversation

A surface opens because the conversation pointed at something, steps aside when you are done, and that is why the header shows chips and not tabs.

<!-- https://crusible.dev/docs/concepts/surfaces-answer-to-the-conversation/ · doctype: explanation · role: both · reviewed: 2026-09-05 -->


A <a class="docs-term" href="/docs/reference/glossary/#surface">surface</a> in Crusible is a tool view
that opens because the <a class="docs-term" href="/docs/reference/glossary/#conversation">conversation</a>
pointed at something, and it answers to that conversation rather than the other
way round. The editor, the terminal, the dashboard and the pull request are all
here, but none of them is the place you live. The conversation is, and every
surface is somewhere it sends you to look.

## The "go look at this" gesture

The way a surface opens says most of what there is to say about it. An
<a class="docs-term" href="/docs/reference/glossary/#agent">agent</a> posts an
<a class="docs-term" href="/docs/reference/glossary/#artifact-card">artifact card</a>, a diff, a test run
or a plan, and the card carries a door: **Open in Project**, **Open in Test**,
**Open plan**. Walking through it is a "go look at this" gesture. The surface
takes the centre of the screen, the conversation steps aside without going
anywhere, and when you close the surface the conversation is back where it was.

That is a different relationship from the one an IDE has with its panels, and
the difference is deliberate. In an IDE the editor is the building and everything
else is furniture inside it. In Crusible the conversation is the record of the
work, so the record has to stay primary: a surface is how you inspect one thing
the record mentions, and it is never allowed to become the place where the
record is kept. What you decide while looking at a diff goes back into the
conversation, tagged as a decision, not into a comment inside the editor that the
channel cannot see.

## Two solos

Sometimes talking is the work, and sometimes looking is. Both get the whole
width.

When the conversation goes solo it fills the window, and the header widens with
it: the channel's name, its state, its pull request badge and its one-line
description sit on one line, and rolled-up agent updates show as a single row.
This is what a planning discussion or a design call looks like in Crusible, when
nobody needs an editor open.

A surface can go solo in the same way, when inspection is all you are doing:
reading a long diff, watching a shell, sitting with a dashboard during an
incident. The conversation is still one gesture away, and nothing posted while
you were looking is lost, because it landed in the record whether you had it on
screen or not.

## Why chips, and not tabs

The channel header shows at most two surfaces as chips, **Project** and **Docs**
on a feature channel, **Terminal** and **Project** on a worktree, **Dashboards**
and **Docs** on an incident channel. A worktree channel's starter card says which
one leads: “Terminal is the default surface for this channel”.
Behind the three-dot button beside them sits **Switch surface**, a menu of the
rest, each with a one-line description: Diagrams as a brainstorm board, Design as
a live component preview, Test for runs, repros and session replay, Review for
the pull request, its checks and its comments, Flow for the agent and CI
orchestration graph.

A new reader looks at that header and expects a tab strip. It is not one, and
the reason is worth knowing, because a member who reads it as tabs misreads the
whole screen. A tab strip says "these are the places; pick one". It puts every
surface on equal footing, it makes the surface the thing you are in, and it
invites you to stay there. The chips say something narrower and more useful:
"these are the two surfaces this work is looking at right now". They are chosen
by the channel's template, so a worktree
leads with its shell and an incident channel leads with its dashboard, and the
overflow holds the rest for the moments the conversation points somewhere else.

The alternative, a strip of every surface on every channel, was considered and
it fails on two counts. Most channels need two or three surfaces, so a strip of
all of them is mostly wrong for every one of them. And a strip has no way to express
what the chips express, which is that the surfaces on show follow the work, and
are not a fixed geography you navigate on your own.

## What this means for you

The header is not a tab strip, and reading it as one is the most common
misreading of the screen. The chips are where the work is looking right now, and
the three-dot button holds the rest.

A link on a card is the front door to a surface. Opening it is not leaving the
conversation; it is looking at one thing the conversation mentioned, and closing
the surface brings the conversation back.

What you decide while looking belongs in the conversation. The surface is a
place to inspect, and the record is where the outcome goes, which is what
[The conversation is the record](/docs/concepts/the-conversation-is-the-record/)
is about.

- [Every surface has a provider](https://crusible.dev/docs/concepts/every-surface-has-a-provider/) — Behind every surface is a provider that holds its data, and connecting a tool you already use changes one surface and nothing else in your workspace.- [The conversation is the record](https://crusible.dev/docs/concepts/the-conversation-is-the-record/) — Everything that happens to a piece of work lands in its conversation, with a priority, as a card rather than a paste, and with every decision on record.- [Joining a workspace](https://crusible.dev/docs/start/joining-a-workspace/) — Someone set this workspace up before you arrived: what you are looking at, which parts are yours, and what to do first.

