Immersive rooms

A room comes in three types. Static and Container show your demo in the room beside its tour, in a device frame. Immersive shows your app as itself: at the viewer's own window size, inside a border in your colour, under a thin banner. This page covers choosing the type, what changes for a viewer, and how people get into any room: a password, or an email they prove with a code.

Immersive rooms come with the Team and Enterprise plans. The password and the verified email work on every type of room, on every paid plan.

Choosing the type

The type comes with each deploy. pitch.json's room picks it, beside kind, which still says how the build is served:

{
  "name": "Columbus",
  "kind": "static",
  "room": "immersive",
  "output": "dist",
  "apps": [{ "id": "app", "name": "Columbus", "path": "/", "device": "laptop" }]
}

room is standard (the default, the same as leaving it out) or immersive. An immersive room is served as files or by a server, as kind says: kind: container works too.

• With Claude, ask it to deploy the project as an immersive room. deploy_static's rehearsal names the type, and a plan without it, before anything is sent.
• From the terminal, roomi init --room immersive writes the line, and roomi deploy names the type in its rehearsal.

To change the type, edit the line and deploy again. Every link stays, and the next page load shows the new type. Analytics carry on, split by build. Screen pictures belong to a build, so a new type starts its own. Rolling back to an earlier build brings its type back, and the app's confirmation says so.

The app shows the type as a badge on Builds, at the start of the project's subtitle and on its card, and read only in the project's Settings, with how to change it.

What a viewer sees

The app fills the window below a slim banner: your name and logo, the tour, the menu, and the one next step you offer. Pages, files, comments, reactions and the phone handoff move into the menu. The tour is off by default; turn on Start on the tour in Settings to open every visit on step 1. From Claude, set_tour_start does the same, rehearsing first.

The members' preview draws each build in its own type, so a preview is how you try immersive before it goes live.

On a plan without it

If a workspace moves to a plan without immersive rooms, its immersive room keeps working, drawn as a standard room. The badge says "Immersive · shown as standard on Pro". A new immersive deploy, a rollback to one or a preview of one is refused, naming Team. Moving back to Team draws it immersive again from the next page load, with no redeploy.

How people get in

Every private link is made for one person. In a project's Settings, under How people get in, a room can also ask, in this order:

1. A password, one for the room. Tell it to people another way. It is kept only as a hash: nobody can see it again, in the app or through Claude.
2. A verified email: a 6-digit code to an address you allow, from "Your name via Roomi". Allow whole domains (anyone at a firm, as themselves) or named addresses. Each link's own viewer is always allowed. The page answers the same for any address, so nobody can find out who is on your list. A free-mail domain such as gmail.com asks you to confirm first, since anyone can have an address there.
3. Say who they are: today's "Are you …?", which comes after either.

The clicks question always comes last, once.

Every change shows what it does before it is saved. Setting, changing or removing a password, or turning the verified email on, signs everyone out of the room at once. Each change is in the project's Room history, with who made it and when, never the password or the list.

From Claude, room_access reads the ways in and the failed tries per link, and set_room_access changes them, rehearsing first. Claude never repeats a password back.

Wrong tries

Five wrong passwords pause that browser for 15 minutes. A link takes at most twenty in an hour, and the room asks the viewer to wait. A code works for 10 minutes and five tries. Settings, and each viewer's journey, show how many wrong tries each link had, never what was typed. If a viewer is locked out, Roomi support can lift it for that link.

In the journey

A person's journey says how they came in, such as "Came in with a verified email", and the wrong tries on their link. Claude's viewer_activity, in_the_room and insights say the same, and so does get_link when it is given the link's projectId.