Booking Flow

Booking Flow

v1 is a matchmaker, not escrow checkout. Payments UI was subtracted; mock payment plumbing stays dormant for a one-line future swap.

Happy path

Client discovers artist
  → Booking funnel (date, package, venue details)
  → Sends REQUEST  (status: pending_confirm)
  → Artist sees "New requests" on Home + detail CTAs
  → Accept  → confirmed (thread + push + system message fire)
     or Decline → cancel-booking Edge Function
  → Negotiate in chat

Statuses (client-facing)

Status	Meaning
pending_confirm	Request filed; waiting on artist
confirmed	Artist accepted
cancelled	Either side cancelled / decline path
completed	Gig finished (client path must reach this)
unknown	Decoder fallback for server statuses the client doesn't know yet — not actionable

Perspective is keyed on which side of the row you are, not solely account role (audit remediation).

Important guards (schema)

• Artist consent / cannot PATCH declined → confirmed (0083, tightened further in 0096)
• Event terms freeze after acceptance (0096 — pending apply)
• Participant ids immutable (0085)
• client_name server-owned (0084)
• Decline routes through cancel-booking EF (not a raw status flip that strands escrow)

Chat

• Thread created on confirm (migration lineage from 0015 / 0068 fix)
• System message rows + action_route + read receipts (0072)
• No contact redaction (scrapped); report + block still first-class

Artist-side UI (Jul 2025 E2E fixes)

First real two-account test exposed client-only UI on the artist side. Fixed role-aware:

• Accept/Decline CTAs
• No "Message artist" self-thread
• Names from mirrored columns (0080) when users RLS nulls the embed
• Dashboard uses fee, not payments-era total

UI tests: MatchmakerFlow, ArtistAcceptRequestTests, launch arg -uitest-seed-pending-request.