Last updated August 3, 2026
Pages
Every architecture board tells you what a system is made of. Pages tells you what people actually see — the routes your app really serves, arranged so you can look at the whole surface at once.
What Pages shows
Pages is the app's front-end route surface, on a per-app-board screen of its own. Nothing on it is drawn by hand: the routes come from the code plugin's ui.pages aspect, and the screenshots come from /inspect running against your app in a real browser.
That makes it an app-board feature specifically. A command center doesn't have a Pages screen — pages are per-app detail, not something worth aggregating across a fleet — and neither does a published board.
Two arrangements
The same rows render two ways, and you flip between them with the Canvas / Tree toggle.
Canvas is a Figma-style map. Pages cluster into derived groups — by Feature or by Owning layer, your choice — and land on a deterministic grid. There's no dragging and no saved positions, and that's deliberate: a page sits where its route and its cluster put it, so the map looks the same every time you open it. Stability across loads is the layout.
Tree mirrors the app's real route segments instead. It's the arrangement to reach for when you're asking a structural question — where a route lives, what sits under it, whether a segment has grown a tail you didn't expect. Canvas is for taking in the whole surface; Tree is for finding one thing in it.
Tiles and captures
A page tile changes with how close you are. Zoomed out, it shows its route pattern and fetches nothing — a hundred tiles cost you a hundred strings, not a hundred screenshots. Zoom past the threshold and each tile loads its newest ready capture.
A tile with nothing to show says so: "No capture — run /inspect". That's an honest empty state rather than a placeholder image, and it names the command that fixes it.
The links between pages
Canvas draws navigation edges between pages, derived from the link targets in your routes — this screen leads to that one.
When a target can't be resolved to a real page, you get a stub badge instead of an edge. We'd rather show you a dead end we couldn't follow than invent a connection that isn't there, because a fabricated edge on a map you trust is worse than a gap you can see.
Opening one page
Selecting a page opens a detail sheet beside the map, with what's known about that route and its captures.
A page also has its own address: ?item=page:<id> lands directly on it, in whichever arrangement you're in. That's what makes a page shareable — paste the link into a review, or anchor an intent to the screen it's about, and whoever opens it arrives looking at the same thing you were.
Getting pages onto the board
Two commands, in order, in the repo bound to this board:
/adopt --aspect ui.pagesextracts the route surface from the code and reconciles it onto the board. This is what fills the screen at all./inspectopens your running app and stores a page capture — a clean screenshot plus an element map — on each correlated page.
Both live in the code plugin, and the empty states tell you which one you're missing. Before any adoption, the hub's Pages card reads "No pages extracted yet — run the code plugin's pages adoption to map this app's surface." After it, a tile with no screenshot yet reads "No capture — run /inspect". Once both have run, the card carries the page and feature counts and opens the screen.
Where Pages fits
Pages is a screen, not a seventh facet. An app board tracks six facets — canvas, insights, intents, aspects, skills, sources — and Pages is a view onto one of them, the ui.pages aspect, given its own home because a route surface deserves a map rather than a table. It sits between Canvas and Intents in the tab strip; the board tree covers the strip in full.
The captures it collects have a second life. When an architect annotates one while authoring an intent, those marks become that intent's visual context — so a request to change a screen arrives with the screen attached.