Design preview · Waitlist + Launch (TMPL-WAITL1) · proposed · updated 2026-08-06

← Design HQ  ·  HTML on GitHub  ·  PRD — prd-as-waitlist-launch.md

Waitlist + Launch — every screen through the flow (proposed)

Waitlist + Launch — Discover, activate, go live, then the subscriber thread.

SizePortrait scrolls 375 · sideways is a slide deckNotes
Design brief — overview · scope · journey (closed)

The full proposed screen flow for the pre-sale waitlist + timed launch-broadcast assistant — a review artifact, not a signed build target (status in Scope). Structured to the 8-section shape: overview · scope · content structure · journey · desktop · mobile · components · future.

frames 1–8 · card → live → monitored · mobile + desktop grounded in the 2026-07-26 Assistant Builder + WhatsApp Agent scope passes amber = action/pending/informational-warning · emerald = live only

Widths here sample a fluid continuum — content scales continuously; structure steps only at sm 640 · md 768 · lg 1024. Kit: design-canon.md U8.

Every $ figure drawn in these frames (per-run price, wallet balance, launch-broadcast tier price) is illustrative — prices arrive from props/the DB at runtime, never authored literals (single-source pricing).

Reading order (2026-07-30, kit-locked): § Desktop screens first — every desktop frame, full flow, journey order — then § Mobile screens below it — every mobile frame, same order, laid out side by side as a wrapping grid grouped per phase (never a tall single-file column of phone screens). Two sections, never interleaved — a review-document convention only; 375 is still designed and scored FIRST in real work (U8 above still holds).

Waitlist + Launch captures pre-sale interest and fires the launch the moment the founder says go. Before doors open, subscribers join through three doors — a WhatsApp text, the hosted signup page, or a broadcast keyword reply — each deduped, written to the founder's own Sheet, and answered instantly with an honest confirmation (spots still open, or sold-out with a waitlist position). When the founder is ready, one "Launch now" action from Pulse fans a single broadcast out across channels — the Meta-approved WhatsApp template plus a Brain-voiced email — segmented by what each subscriber can actually receive, billed once per send, never per recipient. Pulse then shows delivered counts and cost by channel. This file finishes the Peyton-locked v9 setup spec (2026-06-10) that the live build stalled halfway into; every frame note calls out what's live today vs. what's proposed and why.

Status not a signed build target
  • This is a review artifact — CTO, Chief Designer, and Chief Product still need to weigh in before anything here ships. Nothing in this file is build-approved; restructuring it to the 8-section shape (2026-08-06) does not change that status.
  • Ledger check 2026-08-04 (`../parity/parity-waitlist-launch.md`) re-verified the three self-graded gaps against code — all still real. Sign-off or a re-cut is the open Peyton decision (`alignment-2026-08.md` decision 2).
In scope — drawn as the would-be build contract, once signed
  • Assistant: TMPL-WAITL1 only. Frames: Explore card (sec-1) · v9 3-question Personalize + "Make it richer" (sec-2/2b) · Connect with read-only number + compact Brain check (sec-3) · Try honest test (sec-4) · activation loader → live (sec-5) · "Launch now" modal with reach math (sec-7) · monitored Pulse card (sec-8) · guest WhatsApp confirmations + launch broadcast (sec-6).
  • Extends — never redraws — the master's existing WAITL1 worked example (`assistant-lifecycle.html` sec-2/4a/4b/6/7/8) and must never contradict it.
Explicitly out
  • WhatsApp confirmations for web-page signups — needs its own new utility-category Meta template; flagged as a real gap, not drawn (sec-6 notes).
  • Fallback frames — STOP/unsubscribe, delivery failure, schema mismatch have ACs (AC-WL-07/10/12, AC-BILL-03) but no mockup screens; flagged, not invented (journey notes).
  • Real per-channel send toggles + cross-day auto-queuing for the WhatsApp tier cap — deferred, Peyton-owned scope questions (section 8 · Future design).
  • The Signups records surface detail — inherits `RecordsTable`/`RecordRow` per `../../archetypes/records-surface.md`; not re-specified here.
setup (3 Qs + channels) ─▶ 3 signup doors ─▶ Sheet row (name·contact·channel·time)
                                                    │ dedupe, one row per subscriber
                                                    ▼
                          segments: WA+email · email-only (US) · WA-only
                                                    │ one launch send, billed once
                                                    ▼
                          locked WA template + editable Brain-voiced email
  
  • Setup fields (v9 spec, AC-WLSETUP-02 ↗): 3-question minimum — program name · one-line pitch · theme — plus the required setup-time channels choice (it drives what the signup form collects). Everything else (dates, caps, richer copy) lives behind "Make it richer" — vs. today's 16 fields across 4 phases (`waitlistPhases.ts:47-107`).
  • Subscriber record: one row per unique subscriber in the founder's own Sheet — name · contact · channel (whatsapp / web / broadcast-reply) · timestamp — deduped across the three doors (AC-WL-01 · AC-WL-02 · AC-WL-08 ↗).
  • Launch segments: derived from each row's reachable channels, never hand-picked — WhatsApp + email (218) · email-only, US numbers (142, Meta marketing-send pause) · WhatsApp-only (40). Illustrative counts, consistent across sec-7/sec-8.
  • Copy sources: session-window join confirmations are Brain-voiced (business name + tone from sec-3's compact Brain check), a PROPOSED DEVIATION from the locked AC-WLSETUP-04/05 baseline strings (sec-6 notes). The launch-day WhatsApp message is the fixed Meta template waitlist_launch_broadcast — never editable. Email subject/body are Brain-voiced defaults, editable only at launch time (sec-7), never at setup (Gap #3).

Two journeys, shown as one diagram because they connect at two exact points: the founder's Activate step is what opens the subscriber's Trigger door, and the founder's Maintain action (Launch now) is what fires the subscriber's Outcome fan-out. Standard vocabulary from the /assistant-builder Scope Council pipeline, used across the whole assistant catalog: founder Discover → Evaluate → Activate → Monitor → Maintain · subscriber Trigger → Interact → Outcome → Fallback.

FOUNDER JOURNEY ────────────────────────────────────────────────────────────
┌ DISCOVER & EVALUATE ──────────────────────────────────────────────────┐
│ Explore card, price + apps at a glance (sec-1) → tap for detail          │
└─────────────────────────────────┬──────────────────────────────────────┘
                                  ▼
┌ ACTIVATE ────────────────────────────────────────────────────────────────┐
│ Personalize — 3 questions + channels (sec-2/2b) → Connect — read-only    │
│ number/sender/Brain (sec-3) → Try — one real test signup (sec-4)         │
└─────────────────────────────────┬──────────────────────────────────────┘
                                  │ founder taps Activate
                                  ▼
┌ MONITOR (early) ──────────────────────────────────────────────────────────┐
│ Activating… → "your program is live" (sec-5) — signups already flowing   │
└─────────────────────────────────┬──────────────────────────────────────┘
                                  │
                                  ▼        ◄── subscribers join here, see below
┌ MAINTAIN — founder decides it's time ──────────────────────────────────────┐
│ "Launch now" (sec-7): sender + copy, pick lists, reach math, send          │
└─────────────────────────────────┬──────────────────────────────────────┘
                                  │ fans OUT to subscriber segments
                                  ▼
┌ MONITOR (after) ────────────────────────────────────────────────────────┐
│ Pulse card — delivered counts, cost by channel (sec-8)                   │
└──────────────────────────────────────────────────────────────────────────┘

SUBSCRIBER JOURNEY ──────────────────────────────────────────────────────────
┌ TRIGGER — three doors fork IN ────────────────────────────────────────────┐
│  WhatsApp text ──────┐                                                    │
│  Web form (sec-2b) ──┼──▶ dedupe + write, per unique subscriber            │
│  Broadcast-reply kw ─┘      (AC-WL-01 · AC-WL-02 · AC-WL-08)               │
└─────────────────────────────────┬──────────────────────────────────────┘
                                  ▼
┌ INTERACT ──────────────────────────────────────────────────────────────────┐
│ Confirmation reply — pre-sale (sec-6a) or sold-out + position (sec-6b)     │
└─────────────────────────────────┬──────────────────────────────────────┘
                                  ▼
┌ OUTCOME — one broadcast forks OUT to segments ───────────────────────────┐
│  WhatsApp + email (218) · email-only, US (142) · WhatsApp-only (40)       │
│  — one locked launch-day template, per segment (sec-6c)                   │
└─────────────────────────────────┬──────────────────────────────────────┘
                                  ▼
┌ FALLBACK ──────────────────────────────────────────────────────────────────┐
│ STOP/unsubscribe (AC-WL-07) · delivery failure (AC-WL-10/AC-BILL-03) ·     │
│ schema mismatch (AC-WL-12) — no dedicated frame drawn yet, see note ↓      │
└──────────────────────────────────────────────────────────────────────────┘
  
Sequencing principle BINDING
  • Decide the reach upfront, defer the execution — the channels choice lives in Activate (Personalize) because it drives what the signup form collects; sender identity, launch copy, and list targeting all move to the Maintain-time "Launch now" moment (prd-as-waitlist-launch.md §Setup Flow v9, T1051, locked 2026-06-10).
Where each phase lives below
  • Discover & Evaluate — “is this worth a look?” → sec-1
  • Activate — “set it up without the busywork” → sec-2 · sec-2b · sec-3 · sec-4
  • Monitor & Maintain — “watch it, then say go when I'm ready” → sec-5 (monitor, early) · sec-7 (maintain, the launch action) · sec-8 (monitor, after). Interleaved rather than strictly sequential for this assistant — the founder monitors continuously and, when ready, takes the one Maintain action that produces new things to monitor.
  • Subscriber — Trigger → Interact → Outcome — “what does joining actually feel like?” → sec-6, showing the 3-channel Trigger fork-in and the segment Outcome fork-out
  • Fallback — not yet a drawn frame in this artifact (STOP/unsubscribe, delivery failure, schema mismatch all have ACs but no mockup screen) — flagged as a real gap, not invented here.
What this mockup fixes — six gaps from the 2026-07-26 scope passes, revised after the 2026-07-26 CTO/Designer/CPO fix-pass review
  1. Personalize is 16 fields across 4 phases today (2+9+4+1, per `waitlistPhases.ts:47-107`) — v9's locked AC-WLSETUP-02 wants a 3-question minimum (program name · pitch · theme) plus the required setup-time channels choice. Section 2 draws that, with a "Make it richer" expander for everything else.
  2. Sender identity is 4 fields with no validation (`email_sender_account_id` + free-text from-name + from-email + template id) — per locked AC-WLSETUP-02 this connects at LAUNCH time, not setup. Section 3 no longer shows it at all; Section 7's Launch Now modal is its only home, as one read-only "Connected sender" row.
  3. Launch copy is collected at setup time (Phase 3), contradicting the locked model — Section 3/4 show setup with no launch-copy fields; Section 7 shows it living in the Pulse-side Launch Now moment instead.
  4. Pre-sale vs. sold-out confirmation copy is a locked baseline the live build never shipped — AC-WLSETUP-04/05 already specify verbatim strings for both; today's code has only a buried `og:description` tag. Section 6 shows a Brain-voiced PROPOSED DEVIATION from that locked baseline, flagged as a deviation, not a gap-fill.
  5. Brain classification is `not-needed` — Section 3 flips it to Brain-recommended with a compact business-name + voice check (not the full 7-category On-Brand Support module — this assistant needs less).
  6. The connected WhatsApp number is a blank editable field today (placeholder hint only, no read-only binding) — Section 3 makes it a read-only "Connected number" row, same pattern as every other connection.

The frames below are the 1:1 build contract, once signed off — the dev team matches them pixel for pixel; only current / being-built state lives here. Section 8 · Future design at the bottom marks only the two explicitly deferred, Peyton-owned scope questions, not a second gallery of drawn screens (kit canon U9). Acceptance ids cited in frame notes (AC-* ↗) live in docs/product/assistants/shared/prd-as-waitlist-launch.md — §Acceptance Criteria — Setup Flow v9 (T1051) for AC-WLSETUP-*, and §Test Plan → Acceptance Criteria for AC-WL-*/AC-BILL-*. This artifact cites ACs, never mints them; NEW (PRD debt) marks a criterion still to file.

Proposed pending CTO / Designer / Product sign-off — not yet a build contract. Where a frame matches what's already shipped (Explore card, the WAITL1 loader, the master's existing Try-tab pattern) that's called out so reviewers know what's actually new. Business/guest names are illustrative (Salt & Stone Retreats, consistent with the on-brand-support.html exemplar).
Discover
Phase 1 · Discover & Evaluate “is this worth a look?” · sec-1 the Explore card
Waitlist + Launch
A signup page and launch blast for your next cohort — built from your Brain.
$0.20 per run WhatsApp Business Email Google Sheets +1
Personalize Connect Try
tap for detailsActivate
Story
  • As a founder browsing Explore, I see the price and the apps I'll need at a glance, so I can decide whether Waitlist + Launch is worth opening without hunting for the details.
Acceptance
  • No assistant-specific AC — the Explore card follows the platform-wide card contract (component taxonomy in docs/product/platform/prd-pl-platform-core.md), not a per-assistant criterion.
Design notes
  • No change — card unaffected by this rescope. Drawn only for continuity with the numbered flow. Card contract (fixed zones, price as plain text, chip readiness sort, share icon) is identical to `on-brand-support.html` sec-1 — nothing here needed a fix.
768 not yet drawn for this flow. Desktop and 375 are the contract.
This step is 1180. No 375 drawing — use the Desktop size.
Evaluate
This step is 375. No 1180 drawing — use the Mobile size.
768 not yet drawn for this flow. Desktop and 375 are the contract.
This step is 1180. No 375 drawing — use the Desktop size.
Activate
Phase 2 · Activate “set it up without the busywork” · sec-2/2b Personalize · sec-3 Connect · sec-4 Try
dimmed Explore page peeks — revealGap · app header stays visible above (C1)
Waitlist + Launch
A signup page and launch blast for your next cohort — built from your Brain.
$0.20 per run
Overview Personalize Connect Try
How people join — required, pick one or more

Each one's a link or snippet you can hand out.

Your signup page — 3 questions
1 · Program name
October cohort waitlist
2 · Pitch — what do they get for joining?
First pick of dates, 48 hours before everyone else.
3 · Theme
Mono Sand ✓ Editorial Forest
Launch broadcast — channels — required

Sent to everyone the moment you launch — also shapes what the signup form collects (phone, email, or both). Message + sender are picked at launch time (sec-7).

Make it richer — open, all optional
Event date
Oct 14–18, 2026
Spots available
24 spots
Tagline
Retreat season is almost here

✦ Reads your Brain — business name, voice. Full readiness lives on Connect →.

cover image — sample until uploaded
Join the October cohort waitlist
Retreat season is almost here
First pick of dates, 48 hours before everyone else.
Oct 14–18, 2026 · 24 spots
Join the waitlist
·· preview · Sand theme ··
Story [Activate]
  • As a founder, I watch my public signup page update live as I type, so I trust exactly what I'm about to publish before I commit to it.
Acceptance
  • AC-WLSETUP-06 ↗ — while typing, the preview is a pure state render (in-memory config + Brain profile): no fetch fires, no row writes to `assistant_waitlist`, no AI call, no URL is generated.
  • AC-WLSETUP-03 ↗ — every "Make it richer" field is optional; the preview omits each cleanly when skipped, never a broken or empty section.
Design notes
  • Build R32 preview discipline, ported. Every richer field maps to a visible change on the page: cover image → hero block, event date + spots → the meta line under the CTA, tagline → the eyebrow under the headline. Nothing collected that isn't shown.
  • Same preview default-on / live-typing discipline as `assistant-lifecycle.html` sec-4a/4b: typed fields render live (white), untouched ones fall back to a labeled sample.
  • Theme swatch only re-skins the founder's public signup page (its own light-weight page styling, independent of this dark app-chrome canon) — picking Editorial/Forest/Mono doesn't change anything else in Personalize/Connect/Try, which stay the platform's standard dark UI. This mockup shows the picker as a selector only, not a full re-themed preview render, to avoid implying the internal app chrome itself changes.
dimmed Explore page peeks — revealGap · app header stays visible above (C1)
Waitlist + Launch
A signup page and launch blast for your next cohort — built from your Brain.
$0.20 per run
Overview Personalize Connect Try
01 · Connect apps
Communication WhatsApp Business + Resend
Matches your Launch broadcast channels from Personalize — connect an app for each one you picked
Connected
WhatsApp
WhatsApp Business
+1 (628) 555-0114 — where your guests already message you
Email
Resend
Sends the launch email from your connected Resend account
Gmail coming soon
Storage Google Sheets
Signups land here — tap the badge to send them somewhere else
Connected
MystFlo Storage
Records list on Pulse
Signups stay in this assistant's own records list — nothing external to connect
· Free
Google Sheet
Create a new one
We make a new sheet in your Drive with the template
· Free
Link a sheet I already have
We add a new tab — we never touch your existing tabs
· Free
Your Supabase (spreadsheet only)
Link your project · Free
Create a new one coming soon · Free
02 · Wallet
Wallet balanceEach signup draws $0.20 from your prepaid balance $41.20
03 · Brain Check recommended, was not-needed
Business Basics
Business name
Confirmed
Edit in Brain →
Brand voice
Confirmed Jul 20
Edit in Brain →
2 of 2 ready — confirmation & launch copy can sound like you
Try reads this same check back as one line — it never re-asks.
Gap closed (2026-08-07)
  • This frame was previously drawn as a 560px .panel despite being TOC'd under § Desktop screens — no true 1180-width realization existed. Re-drawn here in the master's two-column desktop chrome (apps+wallet flex-1 left, Brain Check 400px right — same shape as `assistant-lifecycle.html` sec-5), same rows/copy as before, nothing invented. The "Continue to Try" button is omitted from this crop; content otherwise identical to the prior single-frame version.
Story [Activate]
  • As a founder on Connect, I see my already-connected number, storage, and wallet as read-only facts, plus a compact Brain check — so I know I'm ready to try it without re-entering anything the platform already knows.
Acceptance
  • AC-WLSETUP-02 ↗ — the reach decision (channels) is a Personalize-only choice; launch execution fields that don't need a connected app (launch copy, wave targeting) stay absent from setup, present only in the Launch-now modal.
  • AC-WL-11 ↗ — if email capture is enabled but no ESP is connected, activation is blocked. Reflected here directly now (2026-08-07 reversal, next bullet) — Resend is a real Connect-tab row, so the blocking CTA is "Connect Resend" right where the founder can act on it, not a message pointing at a modal three steps away.
Design notes
  • Gap #6 — connected number, read-only was a blank editable field. Today `broadcast_whatsapp_number` renders as an empty text box with only a placeholder hint — nothing binds it to the actually-connected account. Proposed: a read-only row prefilled from the connection, same "Reconnect"-only verb convention as every other app row (design-canon connection-status rule) — never an editable text field for something the platform already knows.
  • Gap #2 — REVERSED (Peyton, 2026-08-07): sender identity connects in Connect, not at launch time. supersedes the 2026-08-04 "launch time entirely" call, same file Old shape: `email_sender_account_id` + free-text `broadcast_from_name` + free-text `broadcast_from_email` + `email_template_id` — four ad-hoc fields with no validation, which is what the "defer to launch" call was reacting against. New shape drops all four: Personalize's "Launch broadcast — channels" stays purely a DECISION (which channels apply, drives the signup form) — it grants no app connection by itself. Connect is where the app for each picked channel actually gets connected, same as every other role: WhatsApp through the existing number row, Email through Resend (T353 channels-mode, `providers: ['gmail','resend']` — Resend only for now, Gmail shown coming-soon). This also closes the gap AC-WL-11 already implied: today nothing in setup lets a founder FIX a missing ESP before activation blocks on it — Resend as a real Connect row does. Section 7's Launch Now modal now reads this connection back as an already-known fact, it doesn't originate it.
  • Storage — either/or routing, no dual-write. `_storage_provider` picks ONE destination — signups route to the connected Google Sheet, or to the platform store as the fallback if nothing's connected. It's never both at once (the first pass of this mockup wrongly implied a "mirror" to both); no founder-facing storage-picker decision at setup time either way.
  • The badge is the picker, and the caret is structural on every row but AI Model (kit `design-decisions.md` 2026-08-05, caret scope amended 2026-08-07, Peyton-locked): the Storage badge carries the ▾ and expands in place into the three destination groups — MystFlo Storage · Google Sheet (create-new default · link-existing) · Your Supabase (link · create-new hard-disabled). Groups ②③ copy is quoted verbatim from `DestinationPicker.tsx`, not rewritten here; group ① is drawn as NEW (build gap — see below). Communication's caret is drawn EXPANDED here, not collapsed (2026-08-07 amendment — Email/Resend is a real second channel now, not the "coming soon" placeholder the caret-amendment note originally described): two groups, WhatsApp (one provider, no picker, already connected) and Email (Resend real + connectable, Gmail `⊘ coming soon`) — same grammar as the Storage picker directly below, group-label + pick-row + radio-dot. Whether both groups render EXPANDED by default (drawn here) or the row starts collapsed to a summary badge ("WhatsApp Business + Resend ▾") and expands only on tap is a small interaction-state call for whoever builds this — not a design question, both read identically once opened. Master contract: `assistant-lifecycle.html` sec-5b/B9. No AI Model row exists on this assistant (see below) — moot here, but for the record AI Model would be the one caret-free exception if it existed.
  • Row shape — label "Storage" + badge "Google Sheets" (kit `design-decisions.md` 2026-08-04 closing amendment, Option C, ONE-row shape closed 2026-08-07): every Connect-apps role row carries its role as the LABEL and the connected app as the BADGE. **This bullet supersedes the earlier "silent fallback only" framing**: the 2026-08-07 ruling closes the open question this note used to flag — `MystFlo Storage` is now drawn as a real selectable group (①) in every Storage picker, this one included, alongside Google Sheet (②) and Your Supabase (③). Master contract: `assistant-lifecycle.html` B9/sec-5b. Contradiction flagged, not resolved here: WAITL1's shipped behavior is an automatic either/or fallback with "no founder-facing storage-picker decision at setup time" (see the design note directly above) — drawing MystFlo Storage as a tappable picker OPTION implies a founder-facing choice that the current backend doesn't offer. This mockup now matches the master contract's picker shape per the propagation directive; whether WAITL1's routing logic should become a real founder pick (making the radio functional) or the picker should show group ① as informational/disabled for this assistant specifically is an open follow-up, not decided in this pass.
  • No AI Model row here — deliberate, and code-verified. The 2026-08-04 ruling gives an AI Model row to every assistant using AI; WAITL1 uses none. Verified against the shipped build, not assumed: neither `waitlist-page/` nor `waitlist-broadcast/` calls `runLLM` or any provider SDK — signup capture, the confirmation reply, and the launch blast are all deterministic template renders. ⚠ Watch: Gap #4's proposed Brain-voiced confirmation/launch copy (sec-6/sec-7) is the one thing that would flip this — if that proposal ships as a real generation call rather than a field-substitution from the Brain profile, this assistant acquires an AI Model row and this note must be revisited in the same PR.
  • Gap #5 — compact Brain Check, not the full 7-category module. Business Basics only (name + voice) — enough to ground confirmation and launch copy in the founder's actual voice. Deliberately NOT the full category-grouped module from `on-brand-support.html` frame 4 — that module is scoped to live-chat assistants that need FAQs/policies/offerings; WAITL1 doesn't reference any of those.
Overview Personalize Connect Try
What you're activating
Program name"October cohort waitlist"
Signups go toyour connected Google Sheet
Connected number+1 (628) 555-0114
Email senderpicked at launch — Section 7
Launch blastWhatsApp + email, when you say go
Brain 2 of 2 ready
Wallet$41.20 · $0.20 per run
Try it for real
Run one real signup

We'll add a test row to your store and send the confirmation to your own WhatsApp — so you see exactly what a guest sees. Free.

Run the test
Row added — October cohort waitlist
You (test) · joined today · position 1
Confirmation sent to your WhatsApp
You're on the list for October — we'll message you the moment dates open. — Salt & Stone
Name this one
October cohort waitlist
Activate — $0.20 per run
Story [Activate]
  • As a founder on Try, I run one real signup and see the exact confirmation a guest would get, before I spend a cent activating for real.
Acceptance
  • AC-WL-15 ↗ — NEW, added this pass — the Try tab's real test signup writes a row and sends a real confirmation, clearly marked as a test, and bills $0. No existing AC covered this: AC-WL-04 only covers a test *broadcast*, not a test *signup*.
  • Flagged, not fixed here: AC-WL-09 in the PRD reads "Given the founder previews their page in the Try tab / … Then no row writes … no run bills" — that zero-side-effect description matches the Personalize step-1 preview (AC-WLSETUP-06), not this frame's real write-and-send test action. Looks like PRD drift from before the v9 restructuring split "preview" (Personalize) from "real test" (Try); left for the PRD owner to reconcile, not silently patched in this mockup pass.
Design notes
  • Carried forward, largely unchanged see assistant-lifecycle.html sec-6. The master already models WAITL1's Try tab correctly — real test row + real WhatsApp confirmation, launch-blast row already reads "WhatsApp, when you say go" (not a launch-copy field). This frame adapts it to reflect the Connect fixes above: a "Connected number" line instead of a blank text box, and no sender line at all here — sender identity connects at launch time only (Section 7), so Try's read-back just points there rather than showing a value that isn't decided yet.
  • Desktop 1180 tier: unchanged from `assistant-lifecycle.html` sec-6 desktop WAITL1 frame — not re-drawn here since nothing in this rescope touches its layout, only its read-back content (same fix as above).
768 not yet drawn for this flow. Desktop and 375 are the contract.
2Closed — 3 questions only, collapsed by default
dimmed Explore peeks — tap to return
Overview Personalize Connect Try
How people join — required, pick one or more

Each one's a link or snippet you can hand out.

Your signup page — 3 questions
1 · Program name
October cohort waitlist
2 · Pitch — what do they get for joining?
First pick of dates, 48 hours before everyone else.
3 · Theme
Mono Sand ✓ Editorial Forest
Launch broadcast — channels — required

Sent to everyone the moment you launch — also shapes what the signup form collects (phone, email, or both).

+ Make it richer — cover image, event date, format, spots, tagline (optional)

✦ Reads your Brain — business name, voice. Full readiness lives on Connect →.

·· preview ··
2"Make it richer" open — 5 more fields, none collectible today
dimmed Explore peeks — tap to return
Overview Personalize Connect Try
Make it richer — all optional
Cover image
+ upload a photo
Event date
Oct 14–18, 2026 — sample
Format
In-personVirtualHybrid
Spots available
24 — sample
Tagline
Retreat season is almost here — sample
Story [Activate]
  • As a founder personalizing my assistant, I fill only 3 required questions — program name, pitch, theme — plus my reach channels, and everything else is optional, so I reach Connect without wading through 16 fields.
Acceptance
  • AC-WLSETUP-01 ↗ — filling only program name, pitch, and theme (mono default) enables Continue → Connect; no other field is required.
  • AC-WLSETUP-02 ↗ — the reach decision (channels) is present in Personalize and live-drives the previewed form fields; launch execution fields (sender identity, launch copy, wave targeting) are absent here.
  • AC-WLSETUP-03 ↗ — every "Make it richer" field is optional; skipping all of them still renders the hosted page gracefully, no broken or empty section.
Design notes
  • Gap #1 — 16 fields / 4 phases today v9 target, 2026-06-10. Today's live build asks 16 fields across a 4-phase wizard shell (2+9+4+1, per `waitlistPhases.ts:47-107`) before the founder sees a preview. The locked v9 spec calls for a 3-question minimum path (program name · pitch · theme) plus the required channels choice — this frame is that path. Everything else moves behind an optional disclosure.
  • "Make it richer" fields (cover image, event date, format, spots, tagline) aren't collectible anywhere in the live build — they're proposed net-new, matched to the live-preview page so a founder can see exactly what each one changes before committing to it.
  • Restored — channels decision + theme picker correction, not a new call. Both were dropped from the first pass of this mockup by mistake — AC-WLSETUP-02 already locks the setup-time WhatsApp/Email channels choice (it live-drives what the signup form collects: phone, email, or both) and the 4-theme signup-page picker (Mono/Sand/Editorial/Forest) as the third of the 3 locked questions, replacing the free-text "button label" this mockup had substituted in its place.
  • Corrected — two questions, not one Peyton review, 2026-08-04. An earlier pass labeled the WhatsApp/Email channels toggle "Where can they sign up?" — conflating two different decisions. How people JOIN is the three mechanisms from `waitlistPhases.ts` Phase 2 "How people join" (`enable_hosted_page` / `enable_embed` / `enable_whatsapp_text`: hosted page, embed, WhatsApp text-to-join). WhatsApp/Email is the launch-broadcast REACH decision (`channels`, the "Launch broadcast" phase) — it shapes which contact fields the signup form collects (per AC-WLSETUP-02), but it is not where people sign up. Both frames now show the two blocks separately labeled.
  • Gap #5 — Brain classification flips to recommended. WAITL1's classification is `not-needed` in code today. Proposed: Brain-recommended, reading business name + voice only (not the full On-Brand Support 7-category gate — this assistant's confirmation/launch copy needs less grounding than a live chat assistant does). Shown as a one-line pointer here, full compact check lives on Connect (sec-3).
Live
Phase 3 · Monitor & Maintain “watch it, then say go when I'm ready” · sec-5 activating→live · sec-7 the launch action · sec-8 monitored after launch
Activating "October cohort waitlist"

About 20 seconds. Stay on this screen.

Checking your setup
Confirming billing & terms
Setting up your assistant
Running a live test~15s
Going live
"October cohort waitlist" is live

Your signup page is open and taking names right now.

Working nowsignup page · confirmations · your store
Waiting for youthe launch blast — you send it when ready (Section 7)
Open the signup page
See it in Pulse
Story [Monitor, early]
  • As a founder, I watch a short, honest loading sequence turn into "your program is live," so I know signups are already flowing before I do anything else.
Acceptance
  • No assistant-specific AC — the activation loader/success shell is the platform-wide activation pipeline (`docs/architecture/activation/activation-wizard-architecture.md`), not a per-assistant criterion.
Design notes
  • Carried forward from the master assistant-lifecycle.html sec-7. Loader = same C2 5-step grouping every assistant type uses. Success state is the master's outcome (c) with one difference: "waiting" no longer names WhatsApp template approval, because launch copy no longer submits at activation (Gap #3) — the founder triggers the launch blast themselves from Pulse, so "waiting" now points there instead of to Meta's queue.
Desktop 1180 / seated-sheet width — the primary surface
Launch now
October cohort waitlist ASST-4B8
01 · Sender & copy at launch time
Email sender
hello@saltandstone.com · via Resend
Connected
Email subject (editable now, Brain-voiced default)
The October cohort is officially open
Email body (this slot only — footer is fixed)
Doors are open! You were on the list, so you get first pick before we open this up publicly. Grab your spot →

Unsubscribe link + business mailing address are a fixed CAN-SPAM compliance footer, not part of this editable slot.

locked template WhatsApp — submitted to Meta at activation, this exact wording ships "Hi {{1}}! Great news — the October cohort is now live! Grab your spot before it fills up."
02 · Which lists to include — uncheck to leave a list out
Joined before it sold out
Pre-sale signups, never notified
344
Joined after it sold out
Waitlisted, never notified
56
See who's on these lists →

Nobody on an unchecked list is contacted or charged. Sending needs at least one list checked — with both off, "Send" disables and shows "No recipients, no charge," same as every other staged assistant.

03 · Reach & limits before you send
Your number can start ~250 new WhatsApp conversations per 24h (unverified tier) 258 of your 400 subscribers are WhatsApp-eligible — just over that cap. We'll send WhatsApp to the first ~250 now and pause; you can send again tomorrow to reach the rest. Email has no such cap and reaches everyone today. Nothing else for you to do right now.
142 of 400 subscribers are US numbers Meta paused marketing-template WhatsApp sends to US numbers (2025-04-01) — these subscribers get the email only, not WhatsApp. This is a Meta policy, not a MystFlo limit.
WhatsApp + email218 subscribers
Email only (US numbers)142 subscribers
WhatsApp only (no email)40 subscribers
04 · This send
Going to400 people
Price101–500 band, billed once for the whole send — not a per-run figure$0.50
Your wallet$38.40 available
Send launch to 400 people

This can't be undone once you send.

Story [Maintain]
  • As a founder ready to launch, I review who's on my lists, see exactly what it'll cost and who it'll reach, and send one broadcast that fans out to every channel at once.
Acceptance
  • AC-WL-03 ↗ — when the founder triggers the live Broadcast, WhatsApp subscribers get the approved template, email subscribers get the ESP email, per-recipient outcomes log to `broadcast_log`, and exactly 1 run bills at trigger.
  • AC-BILL-01 ↗ — `waitlist-broadcast` records exactly one Stripe meter event at trigger and sets `billing_status='charged'`, regardless of recipient count or per-leg delivery — this is the exact path that silently broadcast-without-metering in the 2026-06-05 incident; the flat $0.50 shown here (not $0.20 × 400) is that guarantee made visible.
  • NEW (PRD debt) — the wallet-insufficient "Add $0.15 to send now" edge state drawn in the third variant isn't yet a numbered AC in this PRD; it's governed by the platform's prepaid-wallet gate (`docs/product/platform/billing/prd-pl-prepaid-credit-funding.md`), not an assistant-specific criterion.
Design notes
  • Gap #3 — launch copy + sender move here, out of setup. Today `launch_email_subject`/`launch_email_body` are collected in setup Phase 3, contradicting the locked model where launch-time decisions belong in this Pulse-side moment. This modal is where email subject/body become editable — prefilled from the Brain-voiced default, changeable right before send. The WhatsApp side is never editable here (it's the locked template from Section 6c).
  • This editability is NET-NEW send-path wiring, not a re-surfacing of a working feature: the `launch_email_subject`/`launch_email_body` fields already exist in the DB today, but nothing in the current send path actually consumes them at send time. Moving them here is a real build item, not a copy/paste of existing behavior.
  • Which lists to include — restored per-list checkboxes matches shipped `BroadcastConfirmationModal.tsx` R7 pattern. The master's own worked example (`assistant-lifecycle.html` sec-12, R31) already draws this correctly: `bc-rows` with a checked/unchecked state per list, a "review the list" link, and the send button disabling to "No recipients, no charge" when nothing's selected. The first pass of this mockup wrongly reduced these to read-only rows — restored here. Row labels are the plain segment description with no "Wave 1/Wave 2" numbering, since founders think in "who these people are," not wave sequence numbers.
  • Pricing — tiered by recipient count, not a flat per-subscriber charge. Per the shipped `resolveTierPrice` bands (also documented in `assistant-lifecycle.html` sec-12): 1–100 → $0.20 · 101–500 → $0.50 · 501–2,000 → $1 · 2,001–10,000 → $3 · 10,001+ → $7, billed ONCE for the whole send. The 258 WhatsApp recipients here land in the 101–500 band → $0.50 flat. This replaced a flat "$0.20 × subscriber count" model in the first pass of this mockup, which is not how the real billing works and produced an inflated, wrong cost.
  • Wallet reconciliation. The $38.40 shown here is the wallet's OWN current balance at launch time — weeks after the $41.20 shown at setup (Sections 3/4), during which ordinary per-signup debits and top-ups happened off-screen. It is not a running total computed from that $41.20, and it does not need to be — reviewers flagged that the first pass implied a $100+ launch cost against the setup-time balance, which was really a symptom of the wrong flat-pricing model above, not a real affordability problem once tiered pricing is used correctly. The low-wallet edge-case frame is a separate illustrative variant (same modal, a different, lower balance) demonstrating the disabled-send + top-up path — not a continuation of the $38.40 scenario.
  • Reach breakdown is informational text, not toggle controls. Today's channel checkboxes exist in the UI but don't wire to the backend — every send goes out on every eligible channel regardless of what's checked. Rather than ship broken controls, this frame drops the toggles and shows the same information as read-only reach math: who gets what, and why, before the founder commits. If real per-channel selection becomes a real capability later, it replaces this block — it doesn't coexist with it. Whether MystFlo ever builds real cross-day auto-queuing for the WhatsApp cap (vs. today's manual pause-and-resume-tomorrow, ~3–5 days of backend work either way) is a separate, open product-scope question Peyton is deciding — the softer "we pause, you resume tomorrow" copy above is deliberate and should not be read as implying queuing machinery that doesn't exist yet.
  • Numbers. 344 (before sold out) + 56 (after sold out) = 400 total subscribers = 218 (both channels) + 142 (email-only, US) + 40 (WhatsApp-only). WA-eligible = 218 + 40 = 258, checked against the ~250/24h cap above.
Active Details →
October cohort waitlist ASST-4B8
Waitlist + Launch
Launch sent · 400 notified
Runs · launch
418 signups · $83.60 + 1 launch send · $0.50
October cohort waitlistASST-4B8
Waitlist + Launch · launched 9:02 AM today
Launch broadcast
WhatsApp — 258 sent218 both-channel + 40 WhatsApp-only 251 delivered
Email — 360 sent218 both-channel + 142 US-only 358 delivered
Launch broadcast fee101–500 band, billed once for the send $0.50
Signups since launchgrounded in the same waitlist 18 new · $3.60
Story [Monitor, after]
  • As a founder checking Pulse after launch, I see delivery counts and cost broken down by channel, so I can trust the send actually reached who I meant it to.
Acceptance
  • AC-WL-03 ↗ — per-recipient outcomes logged to `broadcast_log` at trigger surface here as the delivered/sent counts per channel.
  • AC-BILL-01 ↗ — exactly one meter event at trigger, regardless of recipient count — reflected as the single flat $0.50 launch-broadcast fee, never a per-recipient charge.
Design notes
  • Channel split, honestly labeled. 258 WhatsApp sends = 218 both-channel + 40 WhatsApp-only; 360 email sends = 218 both-channel + 142 US-only — same 400-subscriber base as the Launch Now reach math (Section 7), so the founder sees the same numbers resolve into real delivery counts, not a new unexplained total.
  • Cost reconciles with Section 7: 400 pre-launch signups + 18 post-launch signups = 418 signup runs at $0.20 each ($83.60), plus the ONE tiered launch-broadcast fee ($0.50, 101–500 band) — never a per-subscriber launch charge.
  • Post-launch card metrics keep the shared Pulse card geometry (`assistant-lifecycle.html` sec-8, R13/R24) — no bespoke card shape for this assistant.
768 not yet drawn for this flow. Desktop and 375 are the contract.
7375 — same modal, mobile tier
Launch now
October cohort waitlist ASST-4B8
Sender & copy
Email sender
hello@saltandstone.com
Connected
locked template WhatsApp — ships as submitted "Hi {{1}}! Great news — the October cohort is now live! Grab your spot before it fills up."
Which lists
Before sold out344
After sold out56
142 are US numbersEmail only, not WhatsApp — Meta policy.
Going to400 people
Price · wallet$0.50 · $38.40
Send launch to 400 people
7Edge case — wallet doesn't cover this send (illustrative low-wallet variant, same modal)
Launch now
October cohort waitlist ASST-4B8
04 · This send
Going to400 people
Price101–500 band$0.50
Your wallet$0.35 available
Not enough in your wallet for this send You need $0.50, you have $0.35. Add $0.15 to send now, or wait for your next top-up.
Send launch to 400 people
Top up →

Nothing sends until the wallet covers it. No partial send, no retry-on-top-up.

Story, acceptance, and design notes for this modal live with its primary desktop frame — sec-7 above.

Guest
This step is 375. No 1180 drawing — use the Mobile size.
768 not yet drawn for this flow. Desktop and 375 are the contract.
Phase 4 · Subscriber journey “what does joining actually feel like?” · Trigger → Interact → Outcome · sec-6 all three states
6(a) Pre-sale — spots still open (WhatsApp-channel join only)
6(b) Sold-out / overflow — waitlist position given (WhatsApp-channel join only)
6(c) Launch day — Meta-approved template locked, not editable
Story [Trigger → Interact → Outcome]
  • As a subscriber who just texted the waitlist number, I get an honest confirmation immediately — whether I made it into the current cohort or I'm on the list for next time — so I always know exactly where I stand.
  • As a subscriber who joined earlier, I get one clear WhatsApp message the moment the cohort opens, so I don't miss my chance because I forgot to check back.
Acceptance
  • AC-WLSETUP-04 ↗ — a pre-sale (not fully booked) join gets the confirmation "You're on the list — we'll tell you the moment doors open." — (a) above.
  • AC-WLSETUP-05 ↗ — the sold-out branch reads the offering's fully-booked state at send time, never a mixed or stale message — (b) above.
  • AC-WL-01 ↗ — a WhatsApp signup writes to the Sheet (name, timestamp, `channel=whatsapp`) and sends a confirmation within ~5s.
  • AC-WL-03 ↗ — the launch Broadcast delivers the approved template to WhatsApp subscribers — (c) above.
Design notes
  • Gap #4 — a PROPOSED DEVIATION from a locked baseline, not a gap-fill. AC-WLSETUP-04/05 already specify verbatim baseline copy for both the pre-sale and sold-out confirmations — this isn't empty ground the mockup is filling for the first time (the first pass of this file wrongly framed it that way). Today's code has neither the locked baseline strings nor anything else beyond a buried `og:description` meta tag ("first in line"). The two bubbles above are a Brain-voiced PROPOSED DEVIATION from the locked baseline (reads business name + tone from the compact Brain Check in Section 3), founder-editable/prefillable, unlike (c) — CTO/Product should confirm whether the Brain-voiced version replaces the locked baseline or the baseline ships as-is and Brain-voicing is a later opt-in.
  • Both ride the open WhatsApp session window (free-form messaging), same mechanism as the confirmation shown in the master's Try-tab test block — not a template submission.
  • Both are WhatsApp-channel join confirmations only. A founder who signs up via the hosted web page today gets a different, narrower path — a sheet write + a founder-facing notification, with no open WhatsApp session to send a free-form confirmation into. Giving web-signups a WhatsApp confirmation too would need its own new utility-category Meta template (distinct from the marketing-category launch broadcast) — flagged here as a real gap, explicitly OUT of scope for this pass. This is the same gap the journey diagram's Fallback box points to.
  • (c) — fixed Meta template, ships verbatim. `waitlist_launch_broadcast` is auto-submitted to Meta at activation (approval window 24–48h, confirmed by webhook — no shorter SLA implied). Body is fixed: "Hi {{1}}! Great news — {{2}} is now live! Grab your spot before it fills up." — founders cannot edit this wording; the locked-template chip plus the bubble's neutral dashed border (not amber — nothing here needs the founder's action, it's just informationally locked) make that visually obvious wherever it's previewed, matching the `.contract-chip` treatment used across the design system for non-negotiable, system-owned copy.
  • Explore / Team card: `AssistantSummaryCardPre` (sec-1); post-activation Pulse card `AssistantSummaryCardPost` (sec-8).
  • Wizard: `ConfigureStep` fields driven by `waitlistPhases.ts` (sec-2/2b — the 3-question collapse is PROPOSED, see currency note below); Connect read-only rows + compact Brain Check (sec-3); Try readback (sec-4).
  • Signup page: the public waitlist page rendered by the `waitlist-page` EF (sec-2b preview; known append-path debt — not the `storage-providers.write()` pattern).
  • Launch Now modal: `ModalWrapper presentation="sheet"` with tier-cap + US-pause reach math (sec-7).
  • Guest thread frames: the shared WhatsApp chat vocabulary (`.bub`, locked-template dashed bubbles) — sec-6.
  • Records component (future): Signups inherits `RecordsTable`/`RecordRow` per `../../archetypes/records-surface.md` — one component, noun is a prop.
Content currency — ledger check 2026-08-04 open gaps, NOT resolved here
  • This file remains a PROPOSED rescope, never signed. `../parity/parity-waitlist-launch.md` (2026-08-04) re-verified its three self-graded gaps against code and found all three still real: (1) Personalize is still the full 16-field / 4-phase flow — the 3-question minimum (AC-WLSETUP-02 ↗) and "Make it richer" expander do not exist; (2) sender identity (4 fields) + the WhatsApp number are still setup-time editable fields, not launch-time read-only rows; (3) launch copy is still collected at setup time. They stay drawn as PROPOSED frames; sign-off or a re-cut is the open Peyton decision (`alignment-2026-08.md` decision 2).
Master contract + sources
  • assistant-flows/assistant-lifecycle.html is the PRIMARY structural contract — this file extends its existing WAITL1 worked example (Personalize live-preview, Try honest-test, activation loader, Pulse cards) rather than re-deriving it, and must never contradict it. assistant-flows/workshop-booking.html is the canonical structural reference (design-canon.md § Assistant-flow mockup structure); token block from on-brand-support.html verbatim.
  • Sources: prod row TMPL-WAITL1 · prd-as-waitlist-launch.md §Setup Flow v9 (AC-WLSETUP-*, the 2026-06-10 Peyton-locked spec) + §Test Plan (AC-WL-*/AC-BILL-*) · waitlistPhases.ts · templateConfigurationFields.ts · ledger ../parity/parity-waitlist-launch.md · 2026-07-26 Assistant Builder scope pass (Personalize/Connect/Brain findings) · 2026-07-26 WhatsApp Agent scope pass (send-path, template, tier-cap, US-policy findings).
8 · Future design deferred, never a build target — real per-channel send selection (replacing Section 7's informational-only reach breakdown with actual working toggles) and real cross-day auto-queuing for the WhatsApp tier cap (vs. today's manual pause-and-resume-tomorrow) are both open, Peyton-owned scope questions, not decided here. Everything else above is the current proposed scope.