Summit Editing — User Journeys

Four people touch the system. Three are DB roles (app_role: customer · editor · admin); the "premium editor" is an operational label, not a separate role.

2.1 — Customer Journey

Discover → Waitlist → Sign up (invite-only beta)

1. Discover. Public marketing pages — /, /pricing, /how-it-works, /ai-examples, /faq. During the invite-only beta the primary CTA points to /waitlist.
2. Join the waitlist. /waitlist embeds a Fillout form (WAITLIST_URL). This is the front door: prospects request access and the team reaches out to invite them when a spot opens. There is no invite-code field in the app — access is gated by who gets invited off the waitlist, not by a code typed at signup.
3. Create the account at /signup once invited. The visitor must download the Upload Guide PDF and tick the confirmation box before the buttons enable. Required: full name, email, password (min 8) — or Continue with Google (OAuth signup is available). No invite code is entered here.
4. Server-side account creation. signUp() calls supabase.auth.signUp. On auth.users INSERT the handle_new_user() trigger creates the profile + customer role and grants the current starter_credits from app_settings — set to 0 for launch, so new customers start with an empty balance and must buy credits before their first edit. (Comped testers are topped up by an admin via the customer credit-grant tool.)

Verify email

1. Verification email (Supabase Auth via Lovable email infra, signup template). The page swaps to a "Verify your email" panel.
2. Click the link → redirected to /dashboard. The _authenticated.tsx layout gates everything under it.

Buy credits

1. Go to /buy-credits. Seven USD packs (100 → 10,000 credits) + Annual Partner plan, with volume discounts.
2. Stripe embedded checkout → on completion redirects to /checkout/return?session_id=….
3. Credits granted server-side. checkout.session.completed → payments/webhook: idempotency-guards via credit_transactions, maps price lookup_key → credits, inserts a transaction, increments profiles.credit_balance. No orders row is created for a credit buy. Balance is server-authoritative.
4. Return page calls checkStatus to verify the real session status (no more false green check).

Submit an edit request (3-step checkout wizard)

1. Go to /submit. The order form is a 3-step wizard (a StepIndicator at the top):
   • Step 1 — Your details. Business/contact details (a StandingDetailsCard prefills returning customers) and the required delivery email.
   • Step 2 — Order specifics. Package (Standard 30s / 60s, Premium 60s / 120s); clip count (extras bill at 5 credits each over the package's included clip limit); format (Reel/Horizontal/Both); add-ons (intro-outro, on-cam advanced, captions, voiceover, Rush — 24h, AI effects 1×/3×/5×, property lines); footage link, branding link, reference video link, music, on-screen text, notes.
   • Step 3 — Review & confirm. A line-item credits summary shows package + add-ons + clip overage vs. the current balance before the customer confirms.
2. Confirm → submit_edit_order RPC. Client sends labels and canonical slugs; costing is 100% server-side from package_prices / addon_prices (unknown slugs rejected). The RPC deducts credits, sets due_at = now + 24h if the Rush add-on is present, else 48h, inserts the order at awaiting_footage / payment_status='paid' / currency='USD', writes a debit transaction, and then calls auto_assign_order() (see the Editor journey). Returns the order id → navigates to /dashboard/orders/:id.

Track → Deliver → Download

1. Order starts at awaiting_footage, already assigned. Auto-assignment normally picks an editor at submit; the order lands on that editor's queue immediately (it only stays unassigned if no active editor has capacity). The customer may edit only footage_link / special_instructions here (enforced by the orders_restrict_customer_updates trigger).
2. Track at /dashboard (credit balance, order list, StatusGauge) and /dashboard/orders/:id. Status emails fire on in_progress and ready_for_delivery (order-status-update).
3. Receive delivery at /dashboard/orders/:id/delivery when status hits ready_for_delivery; each file also fires delivery-file-added.
4. Download via a 10-minute signed URL from the deliveries bucket; logged to order_delivery_downloads.

Request a revision → revision loop

1. Request a revision → request_revision RPC (up to 20 attachments → order_revision_attachments). Moves the order delivered → in_progress and bumps revision_count — the only customer-driven status change RLS whitelists.
2. Editor notified (revision-requested). The editor/admin drives sub-stages via set_revision_stage (queued → in_progress → complete), notifying both parties (revision-progress). The loop can repeat.

2.2 — Editor Journey

1. Invited (no self-signup). Admin runs inviteEditor → auth.admin.inviteUserByEmail, grants the editor role, sets is_editor_active=true. Editor sets a password via the invite link, logs in at /login.
2. Set availability at /editor/availability → setEditorAvailability. The two privileged fields (is_editor_active, max_concurrent_orders, default 5) are written through the set_editor_availability SECURITY DEFINER RPC (a trigger + column REVOKE block direct writes); specialty/bio go through the normal user update.
3. Receive an assignment (usually automatic). When a customer submits, the submit_edit_order RPC calls auto_assign_order(), which — while the auto_assign flag in app_settings is on (it is) — picks the least-loaded active editor still under max_concurrent_orders (row-locked with SKIP LOCKED to avoid double-booking), sets assigned_to, and inserts an order_assigned in-app notification. An admin can still run assign_order manually to (re)assign; that path also enqueues the editor-assignment email.
4. See the queue at /editor/index → getEditorQueue: orders where assigned_to = me and not cancelled, sorted by due_at. Overdue = due_at < now.
5. Work the order at /editor/orders/:id, which redirects to the shared, role-aware /admin/orders/:id workspace. RLS scopes editors to their assigned order.
6. Move status forward (accepted → uploading_footage → in_progress) via updateOrderStatus; in_progress emails the customer. assertCanEditOrder allows only the assigned editor or an admin.
7. Upload the delivery to the deliveries bucket (rows in order_deliveries); notifyDeliveryUploaded emails the customer per file.
8. Mark ready / delivered. ready_for_delivery unlocks the delivery page; delivered stamps delivered_at.
9. Handle revisions — revision-requested email, work it, drive set_revision_stage.
10. Due-soon alerts. A Bearer-protected cron hook (api/public/hooks/editor-due-soon) scans orders due within ~6h and emails the assigned editor (editor-due-soon), de-duped via due_soon_alerted_at.

2.3 — Admin / Operator Journey

1. Orders board at /admin/index — all orders, filterable by status / "mine" / overdue. Links to inbox and the due-soon console.
2. Triage the inbox at /admin/inbox — reads Gmail threads via inbox.functions. The contact form writes a contact_submissions row and relays an email to info@summitediting.co.
3. Open an order at /admin/orders/:id — the central workspace (shared with editors, role-aware; admin-only actions are hidden from editors). From here: (re)assign, set due date, change status, upload deliveries, drive revision stages, write internal notes (order_internal_notes), and cancel & refund.
4. Reassign / handle the exceptions. Auto-assign already put most orders on an editor's queue at submit, so the admin's job here is the exceptions: reassign via updateOrderAssignment → assign_order RPC (requires admin, validates an active editor, soft-warns on over-capacity but still assigns, sets assigned_to, notifies the editor), and pick up any order that auto-assign left unassigned because no editor had capacity.
5. Manage editors at /admin/editors (Editors tab): inviteEditor, removeEditorRole (refused while the editor has active orders), and editor_workload_summary(). Editor max_concurrent_orders here is what auto-assign's capacity cap reads.
6. Manage customers at /admin/customers (Customers tab) → customer detail (/admin/customers/:id): view a customer's orders and balance, and grant or deduct credits (adminAdjustCredits) — this is how comped testers are topped up now that starter credits are 0.
7. Reconcile a payment at /admin/reconcile (adminReconcileSession): paste a Stripe session_id to credit a purchase that the webhook missed (idempotent — a session already processed is a no-op).
8. Monitor due-soon emails at /admin/due-soon-emails (Due-soon emails tab). Note: customers self-cancel only while awaiting_footage; admins can cancel & refund from the order workspace.

States are the order_status enum. Orders enter at awaiting_footage and are auto-assigned to an editor at submit (the status is unchanged — assignment just sets assigned_to). Customers can only move delivered → in_progress (revision) and awaiting_footage → cancelled (self-cancel); an admin can also cancel & refund from the order workspace. Everything else is admin/editor-driven. There is no illegal-transition guard yet.

Transition table — who triggers what, which email fires

Audit: every status change is auto-logged to order_status_history by the log_order_status_change trigger (from/to/by); notes attach to the freshly logged row.

Credits are a unit-less internal currency. The balance is server-authoritative — a column guard raises if a non-admin tries to change credit_balance.

• Currency: credit packs are priced in USD, and new orders now stamp currency='USD' too (the earlier CAD default was fixed; already-charged rows keep the currency they were charged in). Edit orders record amount_cents=0 — they're paid in credits, not dollars — and credits are redeemable across all edit types.
• Pricing source of truth: package_prices (slug → base_credits, clip_limit) and addon_prices (slug → credits, is_rush). Overage = 5 credits/extra clip. The client sends slugs; the RPC never trusts client-supplied amounts.
• Refund path: the only automated refund is cancel_order, and only while awaiting_footage — it restores credits_spent and writes an order_cancelled transaction. No partial/post-work refund and no in-app Stripe-dollar refund (a dollar refund is done manually in Stripe; credits are the in-app currency).

Each journey step → route/screen → server function or RPC → email fired.

Customer

Editor

Admin