Review and share

Open the review#

A reviewer needs only the authorized review link and a browser. Sign in if the service asks. You do not need to install the CLI to inspect flows, screens, states, diffs, or comments.

The project desk at Open app lists reviews visible to you. Direct review links can identify an immutable build or a mutable ref such as a branch or latest. An immutable build ID keeps returning the same capture; a ref follows later publishes.

Read the canvas#

Start with the flow names and purposes. Read a row from left to right for the canonical journey, then move vertically through the important states beneath each step. Labelled edges record alternate transitions that the row cannot express.

Select a frame to inspect it. In a live local canvas, a frame is the proxied application. In a static or hosted build, the captured document is deliberately inert: scripts, active links, and form actions do not run.

Compare a draft#

A comparison identifies changed, added, removed, and unchanged frames. The viewer can step through changed frames and show before and after in several visual modes. Read the named base and target before commenting so the feedback stays tied to the intended versions.

The current fingerprint compares visible text, element structure, and class names. Changes only to a stylesheet rule or inline style value, and changes only to form field values, may not be detected. Treat an “unchanged” label as a navigation aid, not proof that the pixels are identical.

Leave review context#

Comments can be pinned on a frame or in the canvas space around it. That lets feedback describe both a specific UI state and flow-level concerns such as missing steps or misleading order. The author and visibility rules determine who can read and modify a comment.

When you share, use the workbench's Share action and read the resulting link before copying it. A useful review link preserves the selected build, comparison, flow or frame, and camera context when those are part of the current view. Do not copy credentials into a URL.

Publish from a creator workflow#

Creators first capture and inspect a local static build. Publishing is an explicit next step:

mockspace login --service https://mockspace.ynext.co
mockspace publish --project . --dist dist --service https://mockspace.ynext.co

A personal login attributes the publish to the signed-in user. CI may use a machine token, but that credential should stay in the automation environment. Read Authentication and the CLI reference before choosing visibility or mutable-ref options.