Workspace overview

The workspace is organized as a sequence of connected editing contexts rather than a collection of isolated forms. Information entered in one tab becomes context or structure in another: roles named while describing the product become access-matrix columns and route guards; features become traceability rows; the data model becomes CRUD endpoints and typed store fields. That connectedness is the point — the plan stays one document, not eight.

A recommended working order

The tab bar reads left to right in roughly the order a plan comes together:

1. Describe the product, roles, features, and constraints in Domain — the requirements everything else traces back to.
2. Model entities, relationships, and shared types on the Data ER diagram.
3. Plan routes, components, state, and navigation in Structure — one canvas with four views (Routes, Components, State, Nav), so linking two routes never means switching context.
4. Sketch what each page looks like in Wireframe — placing a page on Structure places a linked screen here, so working left to right never leaves a screen unaccounted for.
5. Define or generate the API surface in Backend. On Desktop, Terminal, and Extension targets this tab grows a second rail for the platform's own outside-world contract — Tauri capabilities, CLI flags, or extension surfaces.
6. Plan AI agents in Agents: MCP servers, Claude, OpenAI, Google ADK, Deep, and Eve agents, each with its tools and prompts, sitting between Backend and Security because an agent calls the routes on its left and is constrained by the policy on its right.
7. Review access in Security and requirement coverage in Traceability.
8. Set the visual system in Theme and project-wide concerns — shortcuts, SEO, accessibility — in Misc.
9. Use Export to inspect the generated file tree, generate starter code, and take the plan out as a report, a download, or a GitHub push.

You do not have to finish a tab before moving on. The workspace autosaves, and downstream tabs read the current state — returning to Domain to add a role immediately updates the role choices Structure and Security offer. Planning iteratively like this is cheaper than discovering the same decisions in code.

Tabs, panels, and targets

Top-level tabs switch the whole editing context, Blender-style. Some tabs carry a secondary panel list — Domain separates Roles from Features, Data separates the ER diagram from reusable Types — while canvas tabs use the full width and keep their own inspectors and tools.

The workspace adapts to the project's target platform. All five targets — Web, Desktop, Mobile, Terminal, and Browser extension — share the same planning surfaces, but the component catalogue, the Backend rails, and the exported project structure follow the platform, and concerns that do not exist on a target (SEO for a packaged desktop app, say) simply disappear.

Saving and collaborating

The save indicator in the workspace header reports whether the project is saved, saving, or in conflict. A solo project autosaves straight to your account. A shared project goes live: everyone with edit access sees each other's changes in real time, viewers get a read-only lock, and the owner's session is the one that persists the merged state — so two windows can never silently overwrite each other.