boas.dev/ lane-a client journey/ ui bible

Production Screen Canon · Visual Layer

The Lane-A Client Journey, screen by screen.

Every interface a client meets from first invite to post-meeting summary — in journey order, each pinned to its design-of-record and judged against what production actually serves. This is the walkable visual truth behind the canon table; where a screen and its build disagree, the divergence is shown, not hidden.

Live-verified 2026-07-08 · Lane A ruled (R1)
8Journey screens
5 / 6Divergences closed
1Remaining design gap
G11OTP 410 fixed & deployed (078)
1 Invite→ 2 /p proposal→ 3 Confirm mail→ 4 /m deep-link→ 5 Room→ 6 /g home ★→ 7 Artifact→ 8 Post-meeting

Verdict: MATCHES live = design · BUILT / PENDING designed & built, awaiting merge / link · DIVERGES live ≠ design · GAP ruled, not yet built.  Lane key: each screen carries its lane-entry ref — R1–R5 rulings, G# gap register, canon # row in PRODUCTION-SCREEN-CANON.md — so it maps 1:1 onto the Live PRD lane entries.  Evidence: [live] vs prod · [code] vs landed renderer · [design] apollo design-of-record.  R6 (lane bc43baf7): after booking, the client's home is the ★ /g portal (their space — countdown, prep, artifacts, past meetings); /m is per-meeting deep-link plumbing reached from the portal / confirmation link, not the landing.

1

Invitation email

R2 · canon #1metis · WIRED 🟢 CLOSED
proposal-invite · multipart/alternative
Branded proposal invite email
Design of recordemail-suite/v3/proposal-invite.html — "You're invited", accept / reschedule.
Verdict — live vs design🟢 CLOSED (070 R2). The designed HTML invite is now sent as branded multipart/alternative via mercury-send (d809807, athena live-verified). Was plain-text (divergence #2) — closed. [code][live]
2

/p proposal — the booking surface, all states

R1 (THE journey) · canon #2/3/Ametis 🟢 MATCHES (page)🟢 counter LIVE (#231) 🟢 G11 fixed (078)
/p/<slug> · v3.4.0
Fresh / pending
/p fresh proposal
Accept → email→OTP
/p accepted
Decline
/p declined
OTP entry
/p OTP code entry
Expired · branded 410/404 shell
renderProposalError — branded shell, reuses the .term vocab (PR metis#214 merged). v3.4.0 render capture pending (Playwright backend down); prior stray shot was pre-#214 unbranded and was removed rather than shown.
Counter — desktop calendar (design-of-record)
Design of recordreports/2026-06-30_p-page-v3/ (page) + reports/2026-07-08_p-counter-calendar-desktop-v3/ (desktop counter, 8-wk horizon) + proposal-page.ts.
Verdict — page🟢 MATCHES. The branded booking lane is fully built, v3.4.0. Lane A /p is THE client journey (R1) — cal.com is backend-only; any client-visible cal.com surface is a bug. [code][live]
Verdict — counter picker🟢 LIVE IN PROD. Desktop-first two-pane calendar shipped into the live renderers (shared availability-picker.ts), retiring the cramped slot-list. PR metis#231 merged→main (45bed53 cherry-picked clean, tsc + 332 tests green), CF-deployed; /p?step=counter serves the two-pane calendar (calgrid / month / week markers live). 8-wk horizon is a non-blocking follow-up (data-driven — auto-extends when metis adds getRangeSlots + MAX_DAYS→56). [live: metis-verified][code: #231]
Verdict — OTP leg (G11)🟢 FIXED + DEPLOYED. The E2E run-2 post-OTP 410 (gap G11) is fixed — idempotent terminal on booked proposals (task 078, 6fd99e4), merged to main and carried live by the #231 deploy. The E2E run itself is the live proof of the leg. [code+deploy]
3

Booking confirmation email

R3 · canon #5metis · WIRED 🟢 CLOSED
confirmation · single branded · ics · email-suite/v3
Design of recordemail-suite/v3/confirmation.html — one branded email, ics + /m link.
Verdict — live vs design🟢 CLOSED (070 R3). cal.com native attendee email suppressed (live-verified zero cal email post-flip, f798c1c); the single branded confirmation is the sole send. Was a double-send (divergence #5) — closed. [code][live]
G12 — delivery fixed🟢 Mail now actually lands. The confirmation queue-drainer had never loaded (all mail unsent since 06-27) — now inline JMAP, landed-mail proven. [live]
R6 — where it points (lane bc43baf7)Post-confirmation, the client's destination is their /g portal (screen 6). The confirmation's meeting link is a deep-link into the specific /m per-meeting view — the portal, not the bare card, is home.
4

/m per-meeting page (deep-link plumbing)

R6 · canon #6metis · DEPLOYED 🟢 MATCHES
/m/<uid> · v3.4.0 · m-page-v3 design-of-record
Design of recordreports/2026-06-30_m-page-v3/ + m-invitee-design.patch; renderer confirms dual-tz + live countdown + JOIN + JaaS embed.
Verdict — live vs design🟢 MATCHES. Countdown, joining-as, JOIN, add-to-calendar, choose-new-time, cancel — v3.4.0 deployed, matches design. [live]
R6 — role reframed (lane bc43baf7)/m is deep-link plumbing, not the post-confirmation landing. The client's home after booking is their /g portal (screen 6). /m/<uid> is the per-meeting deep-link reached FROM the portal or the confirmation email's join link — the single-meeting join/prep view, not the destination the client is dropped on.
5

Branded meeting room (pre-join + in-meeting chrome)

R4 · canon #7metis · DEPLOYED 🟢 BUILT + DEPLOYED
meet.boas.dev/ · our shell · 8x8 media backend only
Design of recordThe room index.html pre-join shell itself; v3.4.0 blue reskin 72aa670. 8x8 (JitsiMeetExternalAPI("8x8.vc")) is the media backend only — vendor watermark off (SHOW_BRAND_WATERMARK:false). preview: shell only — external 8x8 media not loaded in-frame
Verdict — live vs design🟢 BUILT + DEPLOYED (v3.4.0). Our own branded pre-join shell wraps 8x8 as media backend; PR metis#217 merged (883c41f) + deployed — live-verified all-blue, Bricolage, #edgeLive, watermark off. The prior "vendor chrome" verdict was wrong (read a running media session as the whole surface). Operator ruling: full branded room, no JaaS tune. [live][code]
6

/g guest / partnership portal — the client's home

R5 · R6 · canon #9metis · LIVE ★ post-confirmation destination 🟢 MATCHES + PINNED🟢 G10 CTA fixed
/g/<slug> · guest variant of the /me portal system
Design of recordreports/2026-07-01_me-portal-full-v3/ + me-portal-design-analysis.md. /g inherits the /me portal pattern — greeting, tabs, meetings w/ decisions/actions, graph, book-CTA. (Preview shows the populated /me composition-of-record; live /g is the guest variant, ratified matching.)
Verdict — live vs design🟢 MATCHES + PINNED (072). Live render (HTTP 200) ratified as the guest-variant canon of the /me portal system. A dedicated /g design report is an optional follow-up, not a gap. [live][design]
R6 — the post-confirmation destination (lane bc43baf7)This is where the client lands after booking — their space. Countdown to the next meeting, prep, artifacts (screen 7), and past meetings all live here; the portal deep-links out to the specific /m per-meeting view (screen 4) and the room (screen 5). The journey's client home is the portal, not a bare meeting card.
G10 — resolved🟢 CTA retargeted off cal.boas.dev. The guest /g book-CTA no longer leaks a cal.com surface — retargeted to the Lane-A pipeline (task G10, 09252ae), merged to main + deployed with #231. R1 restored on the portal. [code+deploy]
7

Meeting-prep artifact (standalone client page)

decision:artifact-vs-portal · T077apollo · BUILT 🟡 PENDING PORTAL LINK
standalone page — surfaced IN a portal, never woven into tabs
Design of recordprojects/coral/reports/2026-07-08_coral-juergen-meeting-prep-portal/ — curated EN meeting-prep in the portal design language (Coral instance): hero, shared story, 3-stage machine, what-you'll-see, agenda, edge CTA.
Verdict — build state🟡 BUILT → pending portal link. Self-contained, curation-clean (internal analysis excluded; EN; R1-compliant mailto CTA). Per decision:artifact-vs-portal-semantics this is a standalone page the client opens — the portal links to it via a card, it is not a portal tab. Wiring = metis portal card → this page. [design]
8

Guest post-meeting summary (on /m)

G2 · canon #8apollo design · metis data-contract ⬜ RULED → DESIGN OPEN — the one remaining journey gap
/m post-meeting state · dual-consent-gated · design-of-record (not yet built)
Design of recordreports/2026-07-08_m-postmeeting-summary-v3/ — the /m post-meeting state, 3 dual-gate variants (consent-pending · release-pending · summary-ready), brand-guardian-clean.
Verdict — the remaining gap⬜ RULED → DESIGN OPEN (operator P0). Expose the transcript summary (not the raw transcript) to the guest on /m, dual-gated: renders only when recording_consent=true AND summary_released_at != null. Design-of-record exists; build waits on the metis meetings data contract (both fields). This is the sole open client-journey gap — every other divergence is closed. [design]
Source of truth: projects/meet-boas-dev/PRODUCTION-SCREEN-CANON.md (per-screen pin + verdict ledger) · lane epic:client-journey · Live PRD 2026-07-08-lane-a-client-journey-live-prd.md.
This document is the visual layer of that canon — assembled from existing design-of-record renders (collected, not rebuilt). Each screen is lane-addressable; it mounts as a prd_section on /project/scheduling-meet-crm. Where a screen and its build disagree, the divergence is shown.
Design: apollo · meet.boas.dev portal v3.4.0 · generated 2026-07-08 · EN.