Prepare states

Start from the application#

Mockspace is a renderer, not a mock server. It opens the URLs declared by the workspace and captures what the application renders. Reuse the application's existing fixture system, mock service worker, seeded development database, or route parameters instead of adding a second data mechanism just for the canvas.

First inspect the router, the data contracts, the auth gate, and every user-facing branch in each page. Build a state list from evidence in the source rather than from a generic happy-path checklist.

Build one coherent fixture world#

Keep shared entities in one place. A trip shown in a sidebar, a search result, and a confirmation must agree about its destination, dates, and price. Separate fixtures per page drift quickly and can make a technically successful capture contradict itself.

Cover the cases that change what a person sees:

• Every lifecycle or decision value the page renders differently.
• Empty, few, page-boundary, many, and partial-failure list conditions where supported.
• Independent status fields when their disagreement creates a real UI state.
• Error, redirect, and not-found branches a user can reach.
• Optional fields, locale, theme, or feature variants that materially change layout.
• Dialogs and other overlays that belong to the review.

Do not multiply every possible value. Choose conditions that exercise a different product decision or layout.

Give each state an address#

Prefer an ID in the route because it naturally reaches the page's own data requests. For example, /trips/trip-searched-none/inventory can select the coherent “empty completed search” fixture across every endpoint the page calls.

A query parameter is suitable when the application already reads and propagates it. Avoid a global fetch shim whose only job is to smuggle a query value into requests; it is easy to bypass and makes the captured state unlike normal application behavior.

For a condition held only in component state, use an act sequence on a reachable URL. See Screens and states for the declaration shape.

Keep auth and unhandled requests visible#

The capture must reach the application without an interactive sign-in round trip. Use the application's supported development gate, or declare proxy cookies in .mockspace/config.mjs when a cookie is enough. If the only path is real OAuth, resolve that application setup before promising the state.

If the fixture layer supports a catch-all, make unhandled endpoints return a safe response and log the miss. One unmocked session request can redirect every frame to sign-in. Treat the log as a backlog and replace catch-all responses with contract-correct fixtures for every endpoint that affects the screen.

Verify the rendered evidence#

Run the application with the exact environment declared in the Mockspace config. Then run:

mockspace check --project .
mockspace dev --project .

Open every declared state. Confirm that it reaches the intended screen, finishes loading, differs where it should, and does not render an auth wall or error boundary. A passing typecheck and an HTTP 200 do not prove that a client-rendered state appeared.

For a static verification, capture a build and inspect the rendered files. Duplicate frames in one row are a finding to resolve, not harmless repetition.

Work with an agent#

The agent setup guide tells a coding agent to inspect the existing application and its Mockspace instructions before editing. The full app-owned mocking procedure also ships in skills/mockspace-mocks/SKILL.md with the Mockspace package.