vrdiff — Documentation

vrdiff (pronounced ver-diff, like "version diff") is a design-to-code handoff platform that closes the gap between design and engineering. Teams publish components directly from Figma, inspect CSS and Tailwind specifications, compare versions visually, route review requests, and collaborate through threaded annotations — all without leaving the browser.

Table of Contents

1. Introduction
2. Getting Started
3. Profile & Account
4. Workspaces
5. Plans & Billing
6. Inviting Teammates
7. Roles & Permissions
8. Projects
9. Project Members
10. Publishing from Figma
11. Uploading Screens Manually
12. Version Inspector
13. Visual Diff
14. Annotations & Comments
15. Design Reviews
16. User Flows
17. Prototypes
18. Notifications & Email
19. Activity Log

Introduction

What vrdiff Is

vrdiff is a design-to-code handoff platform for product teams. It sits between the screens your team produces — wherever they come from — and the engineers, reviewers, and stakeholders who need to read them, comment on them, approve them, and turn them into shipped features.

vrdiff is source-agnostic. A screen can enter a project two ways:

• Published from Figma via the vrdiff Figma plugin, which captures the full design node tree, a preview image, and a commit message in one click.
• Uploaded manually from the web app as a PNG, JPEG, WEBP, or GIF — for designs that don't live in Figma, third-party mocks, exported screenshots, whiteboard photos, or anything else that can't be plugged in.

Both paths produce the same kind of versioned, inspectable artifact in vrdiff — the only difference is that Figma-sourced versions also carry the structured layer data needed for the CSS / Tailwind inspector, the property-level visual diff, and design-token export. Manual versions support every other vrdiff capability (preview, version history, annotations, replies, reviews, flows, activity log) without those structured-data features.

Instead of a screen being passed around as a flat PNG in a chat thread, vrdiff turns it into a versioned, inspectable, and discussable artifact:

• Versions are first-class. Every publish — from Figma or from a manual upload — creates a new version of a component with a commit message and a preview image. Figma-sourced versions additionally carry the full design node tree.
• The browser is the source of truth for handoff. Engineers don't need a Figma seat to view a screen, read its commit history, leave annotations, request reviews, or — for Figma-sourced versions — read CSS values, copy Tailwind classes, browse the layer tree, diff two versions, or export design tokens.
• Conversation lives next to the design. Threaded annotations are pinned to exact coordinates on the canvas, support @mentions, and travel with the version they were left on, regardless of how that version was published.
• Approval is structured. Design reviews assign one or more reviewers to a specific version and track each reviewer's status (Approved, Changes requested, etc.) over time.

The Problem It Solves

Most teams handle handoff through some combination of Figma comments, screenshots posted in Slack, Loom walkthroughs, and "is this the latest version?" pings. The result is a familiar set of frustrations: engineers can't tell which mock is current, designers can't tell which feedback was addressed, reviewers can't track what they signed off on, and product managers have no audit trail of when a screen changed or why. The problem is the same whether the screen came from Figma, a Sketch export, or a quick whiteboard photo — what's missing is a versioned, commentable home for it.

vrdiff replaces that ad-hoc workflow with a single source of truth that captures what changed (the design data and preview), why it changed (a commit message), who changed it, when, and what people thought of it (annotations, replies, review statuses). Every action is recorded in an activity log per project and per workspace — independent of how the screen was originally added.

What You Can Do With It

Who vrdiff Is For

• Designers working in Figma who want their frames to be inspectable and reviewable without exporting and uploading to a chat tool every time something changes.
• Designers working outside Figma — using Sketch, Penpot, screenshots, or hand-drawn mocks — who want the same versioning, commenting, and review workflow as Figma teams via manual upload.
• Engineers who want a single browser-based home for every screen the team is working on, with structured CSS / Tailwind inspection and design tokens for Figma-sourced versions and image-only previews for everything else.
• Reviewers and PMs who want a clear record of what was approved, what's outstanding, and how a screen evolved.

How vrdiff Is Organized

The product is structured as a small hierarchy of containers — knowing the names will make the rest of this document easier to follow:

• Workspace — the billing and membership boundary. Every account has one personal workspace and can belong to any number of team workspaces. Plans are per-workspace.
• Project — a unit of design work inside a workspace. Projects have their own members, categories, flows, prototypes, and activity log.
• Component — a logical screen or element inside a project; identified by a stable ID so versions accumulate as a lineage.
• Version — a single publish of a component, either pushed from Figma or uploaded manually as an image. Carries a preview, a commit message, and (for Figma sources) the design data. Versions are the unit you inspect, diff, comment on, and review.
• Flow — a static, project-scoped diagram that maps how screens (and decision points) connect into a user journey.
• Prototype — a project-scoped, playable click-through. Hotspot rectangles drawn on a screen link to a target screen, and the play view renders only the screens with hotspots layered on top — so reviewers can feel the real interaction.

The rest of this document walks through these concepts in order, starting with how to sign up.

Getting Started

Signing Up

vrdiff supports three sign-up paths:

• Email + password — visit /signup, choose a name, email, and password (min. 8 characters). vrdiff sends a verification email before you can sign in. Click the link in your inbox (it expires in 24 hours), then return to /login. If the email never arrives, click Resend verification email on the post-signup screen.
• Google — click Continue with Google on the sign-up or login page. vrdiff verifies your Google identity and either links it to an existing account (matched by email) or creates a new one. Google sign-in counts as proof of email, so no separate verification step is needed.
• Workspace invitation — if a teammate invited you by email, open the invite link to land on /accept-workspace-invite. If you already have an account it joins you immediately; if not, the signup form is pre-filled with the invited email and your account is activated as soon as you set a password — no separate verification email, since clicking the invite already proved you control the inbox.

Every new user is automatically given a personal workspace on vrdiff's Free plan. You can start creating projects right away or upgrade to a team workspace.

Logging In

Navigate to /login and sign in with email + password or Google. A signed session token is stored in your browser and used for all subsequent requests. If you try to sign in before confirming your email, vrdiff tells you the account is still pending and offers to resend the verification link.

Forgot Your Password?

Click Forgot password? on the login page (or visit /forgot-password). Enter your email and vrdiff sends a one-time reset link that expires in 1 hour. The link opens /reset-password, where you choose a new password — completing the form invalidates any other reset links and signs every other device out of your account.

If your account was created via Google, the same form sends a different email explaining there is no password to reset and pointing you back to Continue with Google.

Changing Your Password

From Profile, enter your current password and a new one. The current password is required before a new one is accepted.

Profile & Account

The Profile page lets you:

• Update your display name.
• Change your password (current password required).
• See your linked sign-in methods (email, Google).
• Toggle email preferences for each non-transactional notification type (mentions, replies, new comments, version-published alerts, workspace and project membership changes). Defaults are all-on; transactional mail (verification, password reset, workspace invites) ignores these toggles.

Sign out from the user menu in the sidebar.

Workspaces

Workspaces are the unit vrdiff organizes projects, members, and billing under. Every project lives in exactly one workspace.

Personal Workspace

Every account has a single personal workspace, created automatically the first time you sign in. It is permanently on the Free plan, with a strictly enforced membership composition:

• 1 owner (you, the account holder)
• 1 editor (someone you invite who can publish and edit)
• 2 viewers (read-only collaborators who can still leave comments and reviews)
• 1 project

Trying to invite a second editor or third viewer returns a 402 with a prompt to create a team workspace on Pro. Personal workspaces cannot be upgraded directly — to unlock more, create a team workspace.

Team Workspaces

A team workspace is a billed group that supports unlimited members and projects.

1. From Workspaces, click New workspace.
2. Pick a name and a plan (Pro or Max — see Plans & Billing).
3. vrdiff opens an embedded Stripe Checkout. Enter payment details to activate.
4. Once payment succeeds, the workspace becomes active and you can invite members and create projects.

If checkout is abandoned the workspace stays in a pending_payment state for 24 hours before cleanup; you can resume the checkout from the workspace page.

Switching Workspaces

The workspace switcher in the sidebar lets you move between any workspace you belong to. The active workspace scopes the Projects, Activity, and Billing pages.

Workspace Settings

Each workspace has a settings page where any owner can:

• Rename the workspace.
• Manage members and pending invitations.
• Open Stripe Billing Portal (Pro only).
• Cancel or resume the subscription (owner only).
• Delete the workspace (owner only). Personal workspaces cannot be deleted; deleting a team workspace cancels its Stripe subscription and removes all of its projects, versions, and history.

Plans & Billing

vrdiff is offered in three plans. Subscriptions are per-workspace.

Per-Editor Pricing on Pro

Only owners and editors count toward the Pro seat total. Viewers are free, with no cap — invite as many reviewers and stakeholders as you want without growing the bill. vrdiff keeps Stripe in sync automatically every time membership or roles change:

• Inviting a new editor (or promoting a viewer to editor) immediately invoices the prorated cost for the rest of the cycle. The customer's saved card is charged on the spot — there's no "comes through on the next invoice" gap.
• Removing an editor or demoting one to viewer immediately issues a credit invoice for the unused portion.
• Changes that don't cross the viewer ↔ editor boundary (e.g. owner ↔ editor, or viewer ↔ viewer) don't touch billing.

Stripe Billing Portal

Pro workspace owners can open the Stripe Billing Portal from the billing page to update payment methods, download invoices, or change billing details.

Cancelling & Resuming

Owners can cancel a subscription from the billing page. By default cancellation takes effect at the end of the current period, so the workspace keeps its plan until then. A cancelled-but-still-active subscription can be resumed in one click.

After a subscription ends, the workspace becomes read-only — existing data stays intact, but new projects, members, or publishes are blocked until the workspace is upgraded again.

Grandfathered Workspaces

When vrdiff first introduced subscriptions, workspaces with more than one project at the time of upgrade were grandfathered onto Max for a 30-day grace period. A banner on the workspace shows the grace end date. After expiry the workspace falls back to Free; existing projects remain readable and editable, but creating additional projects is blocked unless you contact sales or create a new team workspace.

Pricing Page

A public summary of all plans is available at /pricing. The Max card includes a Contact Sales link for teams that want a managed contract or invoice billing.

Inviting Teammates

Workspace owners can invite people to a team workspace from Workspace → Members.

Invite by Email

Type the email address, choose a role (Member or Admin), and click Invite.

• If the email matches an existing active vrdiff user, they are added to the workspace immediately and notified by email.
• Otherwise vrdiff sends them a custom invitation email with a one-click link that expires in 7 days. They can either sign up with a password (no separate email-verification step — clicking the invite proves they own the inbox) or sign in with Google.

Pending Invitations

Pending invitations appear in the workspace members panel until they're accepted, expire, or are revoked. From there owners can:

• Copy the invite link (useful if the email was lost).
• Revoke the invitation, immediately invalidating the link.
• Re-invite the same email — the previous link is automatically superseded by the new one.

Seat Sync on Pro

On Pro workspaces, accepting an invitation as owner or editor increments the billable seat count and Stripe immediately invoices the proration. Accepting as a viewer is free — viewers don't add to the seat count at any point. Promoting a viewer to editor or demoting an editor to viewer triggers the same immediate-invoice flow (charge on promote, credit on demote). Removing or revoking a pending invitation doesn't change the count until the member has actually joined; expired invites simply vanish.

Roles & Permissions

vrdiff's permissions live entirely at the workspace and project level — there is no separate "instance" or "platform" role.

Workspace Roles

Inside any workspace you belong to, you have one of three roles:

Project Membership

Workspace owners see every project in the workspace automatically. Editors and viewers only see projects they have been explicitly added to. Adding someone to a workspace does not grant them visibility into existing projects — they have to be added per project from Project → Members.

When you create a project, you're added as a project member automatically so you don't lose access if your workspace role later changes.

Effective Project Permission

What you can do with a given project is decided in two steps:

1. Visibility — workspace owners see every project; editors and viewers need explicit project membership.
2. Capability — once visible, your workspace role decides:
   • Owner or Editor ⇒ full edit (mutate flows, prototypes, versions, categories, project settings).
   • Viewer ⇒ read-only on designs; reviews and comments still writable.

Projects

Creating a Project

From the Projects dashboard, click New project. The creator becomes the project owner, and the project is attached to the active workspace.

Required:

• Name — Human-readable project name.

Optional:

• Figma File ID — Links this project to a specific Figma file. The plugin uses this ID to target the right project when publishing.
• Description — A short summary shown on the project card.

Free workspaces are capped at 1 project. Attempting to create a second project on Free returns an upgrade prompt.

Project Dashboard

Each project page shows:

• All components that have been published, each as a card with the latest preview, version count, and last-published date.
• Quick links to Inspect, Members, Categories, Flows, Comments, and Activity.

Components can be grouped into categories (sections) — pick a category when publishing or assign one later from the project page.

Deleting a Project

Workspace owners can delete any project; the project creator can delete their own project as long as they still have edit access on the workspace (i.e. they're not a viewer). Deletion is permanent and cascades — versions, annotations, replies, reviews, flows, and activity logs for that project are removed.

Project Members

Project access is controlled at the per-project level. Anyone with edit access on the project — workspace owners (implicit), plus editors who are themselves project members — can manage membership from Project → Members.

Adding Members

1. Open the project and navigate to Members.
2. Click Add member.
3. Search by name or email — only users in the same workspace appear. Workspace owners are excluded because they already have implicit access to every project.
4. Pick the user and confirm.

How access is decided

There is no per-project access level to pick. What a member can do follows their workspace role:

To change someone's capability, change their workspace role from Workspace → Members, not from the project page.

Project Ownership

The project creator is shown with a Project owner badge and workspace owners get a Workspace owner badge. Both are protected — they can't be removed from the project through this view.

Removing Members

Click the × button next to a non-protected member to remove them. A confirmation is required. Removed members immediately lose access to the project; their workspace membership is unchanged.

Publishing from Figma

The primary way to bring components into vrdiff is the vrdiff Figma plugin, which publishes a frame's full design tree, preview image, and metadata in one step. (For screens that don't live in Figma, see Uploading Screens Manually.)

Installing the Plugin

1. Open Figma → Plugins → Development → Import plugin from manifest.
2. Select figma-plugin/manifest.json from the vrdiff repository.
3. The plugin appears in your Figma plugin list as vrdiff Handoff.

Signing in to the Plugin

The plugin uses your existing vrdiff account — no API URLs or secrets to copy.

1. Open the plugin in Figma. It detects your Figma identity automatically.
2. Click Sign in with Figma. The plugin shows a short pairing code and a button.
3. Click Open vrdiff to confirm — vrdiff opens in your browser at /plugin-link/<code>. If you’re not signed in yet, you’ll be redirected to log in first.
4. Confirm that you want to link your Figma identity to your vrdiff account by clicking Allow.
5. Switch back to Figma — the plugin finishes signing you in automatically and remembers you for future sessions.

Once paired, the plugin can publish to any project where you have edit access. Your Figma identity is stored on your vrdiff user record so future re-pairings on the same Figma account skip straight to the confirm step.

Disconnecting the Plugin

To unlink your Figma account (e.g. to pair a different Figma account, or to revoke plugin access from this browser session), open the plugin’s gear icon and click Sign out. The next sign-in starts a fresh pairing.

Publishing a Frame

1. Select the component or frame to publish.
2. Pick the destination Project and Section (or create a new section inline).
3. Write a commit message describing the changes — Markdown is supported (bold, italic, code, lists, headings, blockquotes, links). Toggle Preview to see the rendered version.
4. Click Publish to vrdiff. The plugin uploads:
   • The complete design node tree as structured JSON, including layers, properties, colors, typography, spacing, and effects.
   • A preview image (PNG snapshot captured by Figma).
   • The component ID and name, so versions accumulate as a lineage.
   • The commit message.
   • The publisher's name as recorded in Figma.

Version Naming

Versions are named automatically as ComponentName vN, where N is the next integer for that component within the project. Manual version names are not currently supported.

Uploading Screens Manually

If a screen does not live in Figma — for example a static export, a third-party mock, or a screenshot — you can add it to a project directly from the web app instead of publishing through the plugin.

Adding a Screen

1. Open the project dashboard.
2. Click Add screen in the top-right of the components grid (visible to workspace owners and editors who have edit access on the project).
3. The Add screen dialog opens. Provide:
   • Image — PNG, JPEG, WEBP, or GIF, up to 25 MB. The dialog shows an inline preview and reads the image's natural width and height for use as the canvas dimensions.
   • Screen name — required. Becomes the component name in the project (e.g. Login screen).
   • Message — required. A short commit-style description of this initial version. Markdown is supported, with Write and Preview tabs.
   • Section — optional. Pick an existing section from the dropdown or type a new name to create one inline.
4. Click Add screen. vrdiff stores the image, creates a new component, and publishes it as version 1.

Manually-added screens appear in the project alongside Figma-published components and behave identically for inspection, comments, reviews, flows, and activity logs.

Uploading a New Version

For screens you created manually, you can upload a new image as the next version:

1. On the project dashboard, hover the screen card and choose Upload new version from its menu (only shown for manual screens).
2. The dialog reopens pre-bound to that screen — only the Image and Message fields are required; the screen name and section are inherited.
3. Click Upload version. The new version is appended to the lineage as ComponentName v2, v3, and so on, exactly like Figma-published versions.

Manual vs. Figma Screens

Manual and Figma screens are intentionally kept separate:

• A screen first published from the Figma plugin can only receive new versions from the plugin. Trying to upload a manual version to it returns an error.
• A screen first added through Add screen can only receive new versions through the upload dialog.

This keeps each component's history coherent — every version of a Figma component carries the full design tree, while manual versions store only the uploaded image and a placeholder canvas. The CSS / Tailwind inspector and design tokens are therefore not populated for manual screens; the canvas, annotations, comments, reviews, version history, and flows all work as usual.

Permissions

Adding a screen requires edit access on the project — the same permission as deleting versions or publishing from the plugin. Viewers and members without project access do not see the Add screen button.

Version Inspector

The inspector is the primary view for examining a published version. Open it by clicking any version card.

Layout

A three-pane layout:

• Left pane — Layer tree or version history (toggle with the tab selector).
• Centre pane — Design canvas showing the preview image, with annotation overlays when comment mode is active.
• Right pane — CSS inspector or comments panel (toggle with the tab selector).

Press Cmd + \ (or Ctrl + \) to toggle Zen Mode, which hides both side panels and expands the canvas.

Layer Tree

The full node hierarchy of the design. Click a layer to select it; properties appear in the right pane. Layers expand and collapse like a file tree.

Version History

Switch the left pane to the Versions tab to see all previously published versions of the same component. Click a version to navigate; hover any row and click the diff icon to compare it with the current version.

CSS & Tailwind Inspection

Selecting a layer (in the tree or by clicking on the canvas) populates the right pane with that element's resolved properties:

• Dimensions — width, height, min/max constraints.
• Layout — display mode, Flexbox or Grid properties, gap, padding, alignment.
• Colours — background, border, and text colours in hex, RGB, and HSL.
• Typography — font family, size, weight, line height, letter spacing.
• Borders & Radius — border width, style, colour, and corner radii.
• Effects — box shadows, opacity.
• Tailwind equivalents — each property is mapped to its closest Tailwind utility class.

Design Tokens

The Tokens tab (accessible via the version's tokens page) exports the design data as a Style Dictionary-compatible JSON file, including:

• Color palette extracted from the version.
• Text styles (font families, sizes, weights).
• Spacing values.

The JSON follows the W3C / Style Dictionary token format and can be used directly with style-dictionary to generate CSS variables, SCSS maps, or platform-specific token files.

Visual Diff

The diff view compares any two versions of the same component side by side.

Opening a Diff

From the version history panel in the inspector, hover a version and click the diff icon. Or navigate directly to:

/projects/:projectId/diff?before=<versionId>&after=<versionId>

Diff Modes

Reading Property Changes

The diff panel lists every property that changed between the two versions, grouped by layer path. Each changed property shows:

• The old value (strikethrough, red tint).
• The new value (green tint).
• Layers that were added or removed are shown in full.

A summary header counts how many layers were added, removed, modified, and unchanged.

Annotations & Comments

Canvas Annotations

In the inspector, click the Comments tab in the right panel to enter comment mode. The cursor turns into a crosshair. Click anywhere on the canvas to drop a numbered annotation pin.

A text bubble appears at the pin location. Type your comment and press Post (Cmd/Ctrl + Enter works too). Pins are stored at the exact coordinates you clicked and are preserved across zoom levels.

You can @mention project members to notify them.

Annotation Pins

Each annotation appears as a numbered circle on the canvas. Click a pin to open its popover, which shows:

• The author's name and timestamp.
• The comment text.
• Any replies in the thread.
• A Resolve / Unresolve button.
• A Reply input.

Resolved annotations turn green and move to the resolved section in the sidebar.

Annotation Sidebar

The Comments tab in the right panel lists all annotations for the current version:

• Open annotations on top, numbered to match their canvas pins.
• Resolved annotations grouped below in a collapsed section.
• Each row shows author, timestamp, content, and replies.
• Actions: Resolve / Unresolve, Edit (author / admin), Delete (author / admin), Reply.

Project Comments Drawer

From the project dashboard, click Comments to open a drawer showing every annotation across all versions in the project. Each card shows the component + version, a View link to that version with the annotation highlighted, the full thread, and a resolve toggle.

Replies & @mentions

Click Reply under any annotation to open an inline reply input. Replies support @mention autocomplete:

1. Type @ followed by any characters.
2. A dropdown appears showing matching project members.
3. Use Arrow keys to navigate, Enter to select, or click a suggestion.
4. The mention is inserted as @username and triggers a notification.

Enter sends the reply, Shift + Enter inserts a newline, Escape dismisses the input.

Resolving Annotations

Any project member can resolve or unresolve an annotation using the ✓ button. Resolved annotations are hidden from the open list but stay accessible in the resolved section and in the project comments drawer.

Design Reviews

Reviews let you formally request feedback on a specific component version and track its outcome.

Requesting a Review

From the version inspector, click Request review:

1. Pick one or more reviewers from the project members.
2. Add an optional message.
3. Submit.

Each reviewer receives a notification linking them directly to the version.

Review Statuses

Reviewers update their assignment with one of the configured statuses (the default set is Pending, Approved, Changes requested, Reviewed). Reviewers can also leave a short note alongside their status.

Review History

Each component remembers its full review history. From the project page you can:

• See the latest review per component at a glance.
• Open the history view for a component to see every past review and the per-reviewer status timeline.

Notifications

Review-related notifications include Review requested (sent to assigned reviewers) and Review status changed (sent to the requester whenever a reviewer updates their status).

User Flows

Flows let you stitch screens together to communicate end-to-end product journeys.

Creating a Flow

1. Open a project and go to Flows.
2. Click New flow, give it a name and optional description.
3. The flow editor opens.

Flow Nodes

The editor supports several node shapes:

Drag nodes onto the canvas and reposition or resize them; pick a colour for shapes and notes.

Flow Edges

Connect any two nodes to form an edge. Edges optionally carry a label ("on submit", "if invalid") and a condition. Edges are first-class objects — you can edit or delete them later.

Annotating Flows

Just like versions, flows can be annotated. Open a flow, switch to the Comments tab, and click on the canvas to drop a pin. Replies and mentions work the same as version annotations.

Prototypes

Prototypes turn a set of screens into a clickable, playable experience — the way Figma's Prototype mode does. Where Flows describe a journey as a diagram, a Prototype lets you feel the journey by clicking through it. Both Figma-published and manually uploaded screens work identically.

What a Prototype Is

A prototype is a project-scoped, named entity (just like a flow) that owns:

• An entry screen — the version that the play view starts on.
• A set of hotspots — rectangles drawn directly on a screen that link to a target screen on click.

A single screen can appear in several prototypes with different wiring — the hotspots belong to the prototype, not the screen.

Creating a Prototype

1. Open a project and switch to the Prototypes tab.
2. Click New Prototype, give it a name and optional description.
3. The prototype editor opens with three panels: a screen list on the left, the active screen canvas in the centre, and an inspector on the right.

Adding Screens

The left rail lists every screen included in this prototype. Click + Add from the left rail to open a picker that shows every screen in the project; pick one and the canvas switches to it.

Screens you add are persisted to the prototype immediately — they survive page navigation and reload. The membership is stored on the server in a dedicated prototype_screens table, separate from the entry pointer and any hotspots.

Drawing Hotspots

On the active screen, drag a rectangle anywhere with the left mouse button. As long as the rectangle is bigger than a few pixels, the editor saves it as an unwired hotspot — drawn in amber. Linked hotspots are blue; the selected hotspot is highlighted in solid violet.

Hotspot coordinates are stored in the screen's natural pixel space, so they stay aligned regardless of the size you draw the screen at.

Linking a Hotspot

Click a hotspot to select it. The right inspector shows a Navigate to dropdown — pick any screen in the project (the source screen is excluded so a hotspot can't link to itself). The dropdown lists every uploaded screen, not just the ones already in this prototype; picking a screen that isn't yet a member auto-adds it (a small "+ add" tag in the option label flags this). If you'd rather pre-stage a screen first, the inspector also has an Add another screen button that opens the same picker as the left rail — without leaving your current canvas, since the right-rail flow keeps the active screen pinned.

The trigger is on click and the transition is instant for now — more options will follow.

Setting the Entry Screen

Click any screen in the list, then in the right inspector hit Set as start. A START badge appears on the screen's thumbnail and the Play button at the top of the editor becomes active. Use Unset start to clear it.

Playing the Prototype

Click Play in the editor header (or open the prototype's play URL directly). The play view:

• Renders the entry screen full-bleed on a dark stage with no editor chrome.
• Layers hotspots as invisible click targets over the image.
• Clicking a hotspot navigates to its target screen instantly.
• Clicking the background flashes all hotspots so testers can find them.
• The header has Restart (jump back to entry), Edit (open the editor), and × (exit). Esc also exits.

You can deep-link into a specific screen with ?from=<versionId> — useful for sharing a particular point in the flow.

Editing & Deleting Hotspots

Selecting a hotspot reveals a trash icon in the inspector header — click it to delete just that hotspot. To delete a whole prototype, hit the trash icon in the editor header (or use the menu on the prototype card on the project dashboard); deletion cascades to all of its hotspots.

Notifications & Email

vrdiff keeps you informed two ways: an in-app notifications feed (always on) and email (configurable per template). Both surfaces are driven by the same underlying events.

Notification Types

If you are @mentioned in a comment you receive a mention notification rather than a generic new-comment notification (no duplicates).

Realtime Updates

vrdiff keeps a WebSocket connection open while you're using the app. New notifications and read-state changes appear without needing to refresh the page. As a belt-and-suspenders, the unread count also re-polls every 30 seconds and on tab focus, so the badge stays current even if the WebSocket dropped silently. Editing a comment to add a new @mention re-fires a mention notification only for newly-tagged users — typo-fix edits don't re-spam the room.

Notification Badge

The Bell icon in the sidebar shows a red badge with the count of unread notifications. Marking a notification read from anywhere (notifications page, dashboard panel, or Mark all as read) updates the badge immediately across every dashboard surface — the layout, the dashboard stats card, and any open notifications page all mutate in step.

Notifications Page

Click the bell to open the notifications page. Each row shows the actor, what happened, a preview of the related content, a relative timestamp, and a Mark read button. Clicking the row jumps to the relevant version, flow, or workspace page — and crucially, when the notification was about a comment or reply, the destination page auto-opens that comment's popover so you don't have to hunt for the new thread.

Dashboard Notifications Panel

The dashboard's Recent notifications card mirrors the same click-to-open behaviour as the notifications page. Clicking a row marks it read (badge counter updates everywhere) and deep-links to the comment popover on the destination page. The dashboard activity card works the same way for activity events that reference an annotation.

Mark as Read

Click Mark read on a single row, or Mark all as read at the top of the page. Both actions update the badge counter immediately.

Email Notifications

vrdiff can also send each of the events above as email — the same templates that power sign-up verification, password reset, and workspace invitations. By default, every notification email is on.

To opt out of an individual category, open Profile → Email preferences and untick anything you'd rather not receive. Transactional emails (verification, password reset, workspace invitations) are required for the product to function and cannot be disabled.

In-app notifications always work, regardless of how your account's email preferences are configured.

Activity Log

vrdiff maintains a full audit trail of actions taken across your workspaces.

Where to Find It

• Per-version — Click Activity in the version inspector toolbar to open a panel of events for that version.
• Per-project — From the project dashboard, click Activity to see all events across all versions in the project.
• Workspace-wide — Click Activity in the main sidebar for everything across all projects in the active workspace.
• Dashboard summary — The home dashboard renders the most recent six events in a side card, all clickable and deep-linked to the source.

Every activity surface auto-refreshes every 30 seconds and on tab focus, so you don't need to reload to see new entries. Clicking any row that references an annotation opens the destination page with the comment popover already expanded — same behaviour as clicking the notification.

Logged Events

Each entry shows the actor, the action, the target entity, and a timestamp.