App Boards & the Hub

A board becomes something more once you connect it to a repo. Give a board a governing Code Plugin source and it becomes an app board — one board, one repo, kept in sync both ways.

That changes what you see when you open it. A plain board opens straight on the canvas, because the diagram is all there is. An app board opens on its hub instead — a front page where the diagram is just one of the things you can check — and gains a tab strip for moving between its facets.

The seven facets

An app board tracks seven things — its facets. Three flow in from your code, three flow back out to change it, and the diagram sits in the middle connecting them. The canvas was once the whole board; now it's one facet among equals — each a first-class part of the app board in its own right, not a sidebar hanging off the diagram.

Expand

There are three ways to meet a facet: its card on the hub (its current state and the one thing you're most likely to do next), its tab in the switcher (the full workbench), and — for most facets — its peek beside the diagram (a glance while you work, with ⤢ to expand it to the full view). Two facets have no tab of their own, and that's deliberate: insights live on the canvas, and sources live on the hub's bindings graph and in the canvas's Sources panel. The tab strip therefore shows six entries — Hub · Aspects · Canvas · Specs · Intents · Skills — not seven equal doors.

The tab strip also carries a Chat toggle: chat slides in beside whichever facet you're on, scoped to it automatically — ask about the intents queue from the intents screen, or about the whole tree from a command center. One conversation follows you across every screen.

The diagram doesn't lose its importance — it's still what every other facet connects to. It just stops being the only door in. If three intents are waiting on your approval, you see that the moment the board opens, not after digging through the canvas.

The hub

Open an app board and the hub answers one question first: what needs my decision now. A strip across the top gathers everything waiting on you — unreleased intents you can review and Release on the spot, intents in conflict over the same element (held back from developers until you resolve them), insight runs nobody has looked at yet, intents going stale, a push whose intent reconciliation failed (the push itself lands fine — the strip is where the failure surfaces), the governing repo gone quiet, nodes gone stale behind code changes or analysis coverage falling low. When nothing is outstanding it collapses to a single calm line, so a clear hub reads as clear at a glance.

Below that, each facet is a card showing its current state and the one thing you are most likely to do next. Every card opens that facet's own surface — Aspects opens the Aspects tab, Intents opens the Intents tab, Sources opens the canvas with its panel ready — never a generic dump onto the canvas.

The bindings, live

The sources card is a small graph of what feeds the board. The governing repo sits on top; any reference bindings — a docs space you watch, a neighbouring service you keep an eye on — fan out below it. Each binding carries a pulse: a dot and a relative time that tell you how fresh its data is.

• live — data arrived in the last day
• quiet — the last push was one to seven days ago
• dormant — nothing for over a week
• never — bound, but no push has landed yet

Expand

Analysis coverage — is the board keeping up?

Next to the bindings graph sits the analysis coverage card. The bindings pulse tells you data is arriving; this card tells you whether the board still describes the repo — the two ways an app board can quietly fall behind.

Every /sync from Cdx Code reports a fresh snapshot, and the card shows it plainly: the share of the repo's architectural files the board covers, how many files are still pending (code no node describes yet), and how many nodes have gone stale — their files changed since the board last analysed them. Alongside the numbers you see the commit and branch they were computed at, and how recently they arrived. Only the counts travel; the file-level detail stays on the developer's machine.

When drift accumulates — stale nodes piling up, or coverage dropping low — the attention strip raises it, so a board falling behind its code asks for your attention before the gap grows. The remedy is always the same and always cheap: an incremental /analyze + /sync from the repo, which re-touches exactly what drifted. A board that has never received a snapshot simply says so — coverage starts reporting with the repo's next sync.

Sessions and footprints

Every time a plugin pushes — a sync, an analysis, an insight run — it records a push session on the binding. Click a binding to see its recent sessions: what kind of push it was (nodes & edges, aspects, insights, archetype proposals), when it landed, and a compact count of what changed — +3 nodes, ~2 edges, −1 table.

Click a session to open its footprint — everything that push created or touched, grouped by facet. Every footprint row is a link into its facet: a table opens in Aspects with its detail showing, an endpoint highlights in the API surface, an intent opens in Intents, and the nodes & edges open on the canvas. A footprint traces a change both ways — back to the push that made it, and forward to everything that push affected.

A hub only ever shows its own board. If a layer deep in your tree is an app board, drilling into it takes you to that layer's own hub — with that repo's own intents, aspects, sessions, and skills.

Moving between facets

The tab strip sits above every view. One click swaps the content pane while the frame — breadcrumb and switcher — stays put, so moving between facets never reloads the board. From the keyboard, [ and ] cycle the tabs and Esc closes an open item.

While you work on the canvas, most facets are also a peek beside the diagram — glance at an intent or a node's aspects and act on it without leaving the map. The ⤢ button expands any peek to its full screen when you want the whole workbench.

Everything you reach is a shareable, Back-able link. Any row in a footprint or the attention strip opens the thing it names — across boards if needed. The URL always captures where you are: the board, the facet, and the open item. Share a table's link with a developer and it opens in their Aspects tab exactly where you left it; press Back and you retrace your steps one waypoint at a time.

Expand

The command center

Your root board usually isn't an app board itself — it's the map of how your systems fit together, and its layers are where the app boards live. Open a root board like that and you land on the command center: the fleet view.

Each app board gets a tile — but not a static one. The tile carries a pulse stack (one dot per binding, governing first), a last-activity line (insights push · 2h ago), an analysis coverage chip (82% analysed · 14 pending), and badges for anything that needs you: unreleased intents to review, stale intents, bindings gone quiet. One glance across the tiles tells you which repos are healthy, which are busy, which have stopped talking — and which boards no longer match their code.

Beneath the tiles runs a recent activity feed — every push across every app in the tree, newest first. It's the fleet's heartbeat: you watch work land in plain terms (this repo pushed aspects, that one resolved an intent), and click any row to land on that app's hub with that push's footprint already open — one step from the fleet view to exactly what changed.

The command center only shows what's cross-cutting — it doesn't try to aggregate aspects, specs, or skills, since those only make sense inside one app at a time. It answers one question: across everything I'm building, what needs me today? Click a tile and you're on that app's hub.

Where you land

Expand

Two things keep this predictable. Moving between layers from the canvas keeps you on the canvas — drilling into a node never bumps you to a hub mid-flow. And a shared link that captures a canvas moment (a viewport, a selected insight) always opens on the canvas, exactly as the sender saw it.

You can switch by hand any time: the Canvas tab (or Open canvas from a hub) takes you to the diagram, and the tab strip takes you anywhere else.

One app, one repo — and no nesting

Two rules keep app boards unambiguous:

• One repo per app board. A board takes exactly one governing Code Plugin binding, pinned to one branch — only pushes from that branch are accepted, the way a hosting product pins a release branch. The board is that repo's twin; two repos, or two branches, on one board would leave every intent and aspect pointing at the wrong place.
• No app boards inside app boards. An app board's layers model what's inside one repo, so they can't become app boards themselves. On a board inside an app board, the option to bind a governing source is replaced with a note pointing you at the app board above it. This is enforced automatically — you can't nest one by accident. The Board Tree covers where they can sit instead.

Becoming an app board

There's no setting to flip. Connect a repo through a governing Code Plugin source — usually by running /login from Cdx Code, or by binding one from the board's Sources panel — and the board becomes an app board immediately. You'll see a confirmation and land on its brand-new hub.

Disconnect the governing source and the board quietly goes back to being a plain board with just a canvas.

What's next