App Boards & the Hub

A board becomes an app board when you bind a repo as its governing Code Plugin source. One app board represents one repo.

What binding a repo changes

A board takes exactly one governing Code Plugin binding. Adding it converts the board, shows "This board is now an app board", and makes the hub its opening screen.

That adds code-backed features: aspects, analysis coverage, developer-pullable intents, and compiled skills. To go back to a normal layer, use Remove app on the hub; see Removing or deleting an app.

The six facets

An app board tracks six facets. Three come from code, two go back to the repo, and the canvas sits between them.

Expand

The tab strip does not map one-to-one onto that list. Insights live on the canvas because they're anchored to elements. Pages is a screen, but it views the ui.pages aspect rather than adding a seventh facet. Two tabs show waiting work: Intents has a count, and Hub has an attention marker.

The hub, card by card

Open an app board and the hub leads with what needs a decision: draft intents, conflicts, insights awaiting review, quiet repos, or nodes drifting behind code. Each row names the action, such as Lock & open, Review, Resolve, Inspect, or View sessions.

Below it are nine cards in three groups: what comes in from the repo, the board's own structure, and what goes back out to change the code.

Each card shows a state and opens the matching surface. Insights totals recent analyses and their insights.

Aspects shows repo detail. Intents tracks the outbound queue, and Skills shows what the repo receives. The other five need more context.

Bindings and pulse

The Bindings card graphs what feeds the board. The governing repo sits on top; reference bindings sit below it.

Each binding has a pulse that shows how fresh its data is:

• live — something arrived in the last day
• quiet — one to seven days
• dormant — over a week
• never — the source is bound but has not pushed anything yet

Expand

1. 1

   The governing repo sits on top

   One source governs the board: the repo behind the app, joined by a solid line.

2. 2

   Every binding has a pulse

   A coloured dot and a timestamp say how fresh that source is: live, quiet, dormant, or never.

3. 3

   Reference bindings fan out below

   Context you watch rather than govern — dashed, and free to sit at a different freshness.

A dormant repo may mean sync stopped, a pipeline broke, or the branch is inactive.

Analysis coverage

The pulse tells you data is arriving. Analysis coverage tells you whether the board still describes the repo.

The code plugin plans the whole board tree from the repo's structure. Each planned board is a unit. The card counts units that are built, stale (built, but changed since), incomplete (the board fails its check or leaves files unclaimed), or unbuilt (planned, but not built).

The percentage is the share of planned boards that are built; stale boards still count as built. One board out of thirteen reads as 7%, regardless of how many files it owns. A newly built top board starts low, and each drill-down raises the percentage by a visible step.

Under the bar, three chips show where the numbers come from. Hover any of them for the arithmetic, worked from the snapshot's own counts.

• Boards is the headline: built boards divided by planned boards, rounded down. Every planned board counts once, whether it owns six files or six hundred.
• Files is the true coverage: the significant files that sit under built boards, divided by every significant file in the plan. Each file belongs to exactly one planned board, the deepest one that covers it. The chip also lists what stays outside the plan: minor files, infrastructure and schema files, tests, excludePaths, coverage.ignore, and files with an extension the plugin does not count.
• Depth shows how deep the plan goes and whether analysis.plan.maxDepth capped it. A cap changes how many boards the plan has, so it moves the headline; it never changes the file total. analysis.plan.unitFloor is the number of significant files a cluster needs before it becomes a planned board.

A top board that owns a few dozen repo-level files can read 7% by boards and 2% by files at the same time. Both are right; they measure different things.

The card also shows the commit and branch used for the calculation. Only the counts leave the developer's machine; file-level detail stays local.

Architecture, Layers and Pages

Three cards show board structure rather than incoming data.

• Architecture is the canvas card: the diagram itself, and the way back to it from the hub.
• Layers lists this board's direct children, for when you want the next level down rather than the whole board tree.
• Pages counts the app's routes and feature clusters, with capture previews once /inspect has run. Before any adoption it says so and names the command that fills it.

Push sessions and footprints

Every plugin push records a push session on the binding, with the push type and counts. Open a session to see its footprint: created or touched items, grouped by facet and navigable. Binding history and session footprints have shareable URLs.

The command center

Your root board is the system map, not an app board. Repos bind to system layers, and the root watches the workspace. After app boards exist beneath it, the root opens on the command center.

This is true even with one repo. Create a system node and make that layer an app so the root stays ready for more apps later.

Fleet attention comes first. Below it, each app board gets a tile with pulse, last activity, coverage, and outstanding-work badges. A merged activity feed lists every push across apps, newest first. Select a row to open that app's hub with the footprint open.

It does not pool per-app aspects, pages, layers, or skills, because those only make sense one repo at a time.

Connecting from outside

Each hub has the access button for its scope. Both are admin-only and offer terminal sign-in or a generated key.

They provide different credentials, so they live on separate screens. MCP Access covers tokens. The Code Plugin covers repo bindings. Signing In & Credentials compares both.

One app, one repo

A board takes one governing Code Plugin binding, pinned to one branch, and an app board cannot contain another app board. Its layers describe the inside of one repo. The Board Tree explains the rule and what the bind control shows when you try.

That page also explains whether each kind of board opens on its hub, command center, or canvas.

Removing or deleting an app

The bottom of an app board's hub has two ways out. Both need board owner access, and you type the app's name to confirm. Both take effect straight away and sit outside your working copy, so Discard cannot bring anything back.

Remove app deletes every aspect permanently. That covers database tables, API endpoints, pages and their screenshots, event channels, and authorization registries on the board and its layers, including anything you edited by hand, such as column tags. Aspects are read from code, so they only exist while a repo governs the board. Make the board an app again and the plugin extracts them afresh.

Unbinding the governing repo or deleting its source from the catalog is not allowed. Remove app is the only way to do that, so aspects are never left on a board with no repo behind them. Reference bindings unbind as before.

Before either action runs, the dialog lists what it will remove, and it blocks you while there are unsaved or uncommitted changes on the app. A published board keeps showing the aspects it was published with until you republish or unpublish it.

What's next