The Board Tree

A nested set of boards can model a whole system. That structure is the board tree.

The tree

Every tree starts at a root board. From there, any node can open into a layer: a full board nested inside that node. Layers can nest again when needed.

Three kinds of board live in the tree:

Expand

Most trees use three levels: L0 for the landscape, L1 for one board per system, and L2 for subsystems. App boards usually live at L1. Use L3 only when a subsystem needs its own map.

Where you land

Opening a board does not always take you to its canvas. What you get depends on what the board is:

Only the workspace's root board can become a command center. A context board, decision record, or board created from the listing stands outside the tree. It opens on its canvas without a hub, aspects, or intents.

On a context board, the Map button becomes Context maps. The dock lists the workspace's context boards so you can move between answers. A board outside the tree has no hierarchy for a board map to show.

The tab strip

Above every board is a strip of the screens that board has:

An app board has the full set because a repo stands behind it: aspects, pages, intents, and compiled skills. A root board watching several apps gets a narrower strip because those details only make sense one repo at a time.

Moving around

The shell shows where you are in three places: the breadcrumb, tab strip, and board map.

You can navigate without the mouse. [ and ] cycle the screens of the current board. The back and forward arrows follow your in-app history board by board. ⌘K jumps straight to a board, screen, node, aspect, intent, or insight by name.

Two behaviors keep navigation predictable. Opening a layer from the canvas keeps you on the canvas. A shared canvas link opens the viewport or selected insight exactly as the sender saw it.

The board map

Select Map in the board bar to open a left panel with the whole tree: every board, which ones are apps, and one-click access to each. Layers do not appear in the workspace sidebar. That list stays short so large trees do not hide the boards people start from.

Expand

1. 1

   Each row says what the board is

   An app board shows a type badge and a pulse dot; a plain layer shows the icon of the node that owns it.

2. 2

   Hover a row for its screens

   Screen icons appear at the right edge; click one to open that screen of that board.

3. 3

   The current row stays quiet

   Your own board shows no icons, because the tab strip is already visible.

At rest, each row shows what the board is. An app board shows a type badge and pulse dot; a plain layer shows the icon of the node that owns it.

Hover another board and its screen icons appear at the right edge. Click the row to open the board, or click an icon to open a specific screen. The current row does not show icons because the tab strip is already visible.

One app, one repo — and no nesting

An app board is bound to one repo, pinned to one branch. Everything beneath it describes that repo. A second repo should be a sibling app board, not a child layer.

Two repos become sibling app boards under the root, and the root becomes the command center. A monorepo is still one repo and one app board; model web and server as layers inside it.

The root board's place in the tree

The root board sits at the top of the tree. Every other board in the workspace is a layer below it, directly or through another layer.

Boards covers what a Root Board is, where it comes from, and what you can change about it.

What's next