feat(portal): invite participants to run their own event, and share the portal by QR

[JorimTheuns]

Two changes to the participant portal, both landing on the same screen at the end of a session.

The event card

The participant portal's thank you page ends on a card: an invitation to run an event with dembrane, and one button. A participant who has just spent ten minutes talking into their phone is the one person in the room who knows what the tool feels like, and this is the moment to ask them.

The form

The button opens the intake form the pricing configurator and the website's needs form already use, on a new portal mount.

• The opening asks for an email and nothing else, and that click alone writes the row as submitted. Somebody who leaves there has still asked us to get in touch.
• The five questions come after, offered rather than required, with a "Done, reach out to me" exit on every step.
• The calendar is cal.com's event intake call (team/dembrane/plan-event) rather than the configurator's "discuss your needs", and it is the eager path, not the only way through.
• No voice input: transcription needs a session a participant has not got.

On the phone it is a full sheet, the ask sits in the middle where a thumb can reach it, and the controls sit along the bottom.

Server

• POST /v2/pricing-configurations/portal, anonymous, gated by a project that exists and is open for participation, rate limited per client address. Rows carry mount = "portal", the project id, and a PTL- reference.
• The booking forward payload carries mount and project_id, so a portal lead reads as one wherever bookings are announced. sam prints the reference verbatim and never branches on the prefix, so this needs no change there.

Nothing announces an email-only lead yet. Those rows are submitted, with an email and no booking. A pipeline for them is Sameer's to build.

The host's switch

New project field is_dembrane_event_cta_enabled, on by default, in the portal editor under the thank you content, with a row on the project overview card. Hosts on a paid plan can switch the card off per project. The free tier cannot: the participant API forces it on and the project PATCH refuses it.

Refactor

The cal.com embed mechanics move out of PricingBookingStep into components/booking/calEmbed.ts, shared by both calendars. The configurator's own booking step behaves exactly as before.

Sharing the portal

A participant standing in a room with the portal open is the shortest path to the next participant. The header carries a share icon beside settings, and the thank you page offers "Show QR Code" ahead of "Record another conversation". Both open the same full screen QR, with copy, WhatsApp, email, and the device's own share sheet where it exists.

The link the QR encodes is built from the session the participant is already in, so a daisy chained session arrives configured the same way.

• Reusable configuration travels: skipOnboarding, tags, tag_id_list, mode, theme. Somebody who scanned a link that skips onboarding hands on a link that skips onboarding.
• Per person state does not: participant name, email, prefilled feedback, the attribution source, and any temporary route state. Every shared link starts a fresh session.

portalSharing.ts holds that split and its tests, so the rule about what carries over lives in one place rather than in the modal. The finish route now keeps its incoming query string, which is what lets the second entry point build the same link as the header; audio and text modes both forward it on their way to finish.

The event card loses its border, its bullet list and its heading. A participant who has just used dembrane does not need to be told what it does: the illustration, and one button that asks the question itself, "dembrane at your event?", pinned to the bottom of the viewport as a footer so it stays in reach however far the page scrolls. It, "Show QR Code" and "Record another conversation" are all secondary outline buttons.

The microphone check is gone

The onboarding deck no longer tests the microphone. Nearly every phone's microphone is fine, and the check cost every participant a permission prompt, a test and a tap before they had said a word. The deck runs privacy, then a name and tags if the host asks for them, then recording; the permission prompt moves to the first tap on Record. While recording, the level meter runs blue, turns yellow when the connection is unhealthy, and red when the recording itself is in trouble. Eight seconds of a flat signal (a muted, unplugged or taken-over microphone; a quiet room still returns room tone) opens the microphone test on its own. The mic_* funnel stages are retired on both sides: the dashboard drops its three mic timeline rows, the server stops accepting them from the portal and stops counting them in the funnel summary. A visitor session written by a pre-change tab that still carries one folds forward to terms.

One column, everywhere

The header keeps to the same 42rem column as the content, so on a wide screen the logo and the actions line up with the text rather than the window.

Verification

Run locally against the dev container stack: the whole flow walked on an iPhone 14 and an iPhone SE viewport, rows checked in Directus, both the free-tier lock and the paid switch exercised in the dashboard.

• 69 frontend tests, 94 server tests, plus the focused tests added along the way: share link, event card, level meter (colour, silence, fire-once), start-screen auto-start (one request across a remount), connection notice, and the funnel's retired-stage fold
• Production build, tsc --noEmit, and biome clean on every file this touches
• Share flow walked in the local portal: header icon, thank you page button, QR, and each share action
• ruff clean on the server files this touches
• i18n catalogs extracted, compiled, translated in all eight locales, and stable on a second extract

One pre-existing ruff formatting drift in free_tier.py (three functions this PR does not touch) is left alone rather than padding the diff.

🤖 Generated with Claude Code