Begin with one job
Start in the application repository and choose one job a person completes from beginning to end. “Recover a failed payment” is a reviewable flow. “Account pages” is a category, so it does not give reviewers an order or a finish line.
List the screens in the order the person reaches them. Give the flow a purpose that explains what the review should protect. If a screen appears in another journey, reuse the same screen identity instead of creating a duplicate definition.
Start with a user flow introduces the four terms used on the canvas. The full declaration shape is in Flows.
Keep the description beside the application
Mockspace reads JavaScript configuration from the application repository. The config records the app URL, its start command and environment, and the flow module. A screen definition records its route, purpose, source files, and reachable states.
Keeping this context with the app makes it possible to update a screen and its review description together. It also gives mockspace check enough information to report missing source paths and invalid declarations before anyone opens the canvas.
The configuration reference documents the supported files and fields. Reuse an existing .mockspace/config.mjs when the repository already has one.
Make every state reachable
Each frame ultimately opens a URL in the application. Prefer a route or fixture identifier the app already understands. For a dialog, menu, or another condition held only in component state, declare an interaction after loading a stable URL.
Do not add a second data system inside Mockspace. The application owns the fixture, seeded data, mock service worker, or route parameter that produces the screen. Open each state directly and confirm it shows the intended condition rather than a sign-in wall, loading shell, or fallback.
Validate before opening the canvas
Run the structural check from the application root:
mockspace check --project .The command reports the configured app URL and start command along with the flows, screens, states, and missing declared sources. Fix a nonzero result before capture.
Mockspace does not start the application. Run the command printed by check in one terminal and confirm the configured URL serves the expected local data. Then open the live canvas from another terminal:
mockspace dev --project .The command prints the viewer URL. The default is http://localhost:4310, and --port selects a different local port when needed. Run Mockspace locally covers port conflicts and recovery.
Read the result as a reviewer
Walk the row from left to right, then move through the states beneath each step. Check visible content, not only HTTP status: a client-rendered app can return a successful loading shell for every URL.
When the live result is truthful, create an inert local build:
mockspace build --project . --out distInspect that build before deciding whether it should be shared. A first local review is already useful; publishing is a separate, explicit action.