Yesterday's profile page ended with a "Book now" button pointing at a placeholder. Today the placeholder becomes real: the multi-step booking widget — pick services, pick a slot. This is the moment ClipBook stops being a directory and starts being a business. Paste this into your Claude Code / Cursor agent: Build the first half of the booking flow for ClipBook (Next.js 14 App Router, TypeScript, Tailwind CSS, Supabase): a multi-step BookingWidget on the /book/[id] route. Yesterday's "Book now" button points here. 1. Widget shell (components/BookingWidget.tsx): - 3-step progress indicator at the top: 1 Services → 2 Date & Time → 3 Confirm. Completed steps show a checkmark; the current step is highlighted. - State lives in the widget (selected services, date, time slot); "Back" returns to the previous step without losing selections. 2. Step 1 — Services: - List the barber's services (from the Supabase services table) as selectable cards: name, price, duration. - Multi-select allowed; show a live running total (price + total minutes) as services are toggled. 3. Step 2 — Date & Time: - Horizontal date strip: next 14 days (skip days the barber is closed, from a working_hours field or table). - Time slots generated from the barber's working hours in 30-minute increments, MINUS already-booked slots (query bookings for that barber + date where status != 'cancelled'). - Booked slots render struck-through and disabled; past times on today's date are disabled too. - Selecting a slot highlights it; "Continue to Confirm" advances to Step 3 (built tonight in 5B — a placeholder panel is fine for now). 4. Data model: - Add a bookings table if it doesn't exist: id, barber_id, customer_id, service_ids (array), date, time_slot, total_price, total_duration_min, status ('pending' | 'confirmed' | 'cancelled'), created_at. Responsive: full-width single column at 375px; the date strip and slot grid tap cleanly on mobile. Acceptance criteria: - Step 1 multi-select updates the live total correctly; deselecting removes it.

We're in the home stretch — the customer and barber sides are built. Today we add the control room: an admin-only dashboard so you can see the whole marketplace at a glance — users, bookings, revenue — and keep it safe behind a role check. 👇 Paste this into Claude Code / Cursor (agent mode): Build the admin dashboard for ClipBook. It is only for users with role=admin. 1. Protect the route: - Create /admin as an admin-only page. If the logged-in user is not role=admin, redirect them to /dashboard. - Add the role check to the existing Supabase middleware (Day 2B) so /admin/* is blocked server-side, not just hidden in the nav. 2. KPI cards at the top of /admin (all computed from Supabase): - Total users (count of users) - Total bookings (count of bookings) - GMV (sum of total_price on bookings with status 'completed') - Take-rate revenue (GMV x PLATFORM_FEE_PERCENT from lib/money.ts, Day 11B) Each card shows the number plus a small label — no charts needed yet. 3. Recent bookings table: - The 20 most recent bookings, newest first. - Columns: customer name, barber name, service, booking type (shop/home badge), date/time, status badge, total price. - Clicking a row opens /bookings/[id]. 4. User list: - A searchable list of users: name, email, role badge (Customer / Barber / Admin), joined date. - Add a search input that filters by name or email. 5. Admin access: - Seed one admin user for testing: create a user with role=admin in the database (document the exact SQL or dashboard steps in a comment at the top of app/admin/page.tsx — do NOT hardcode credentials in the code). - Show an "Admin" link in the nav ONLY when the logged-in user is role=admin. Acceptance criteria: - A customer or barber visiting /admin is redirected to /dashboard, even with the URL typed directly. - The KPI numbers match the database (test with at least 5 seeded bookings, including one completed booking, so GMV and take-rate revenue are non-zero). - The bookings table and user list render correctly with real data, and the search filter works.

This morning we polished mobile and ran the full QA pass. Tonight we ship it — ClipBook goes live for the world to use. Paste this into Claude Code / Cursor: Deploy ClipBook to production (Next.js 14 App Router, TypeScript, Tailwind CSS, Supabase, Stripe, Vercel). 1. Push the finished project to GitHub on the main branch and confirm `npm run build` passes with no TypeScript errors 2. Connect the repo to Vercel and set the production environment variables: NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY, STRIPE_SECRET_KEY 3. Run the Supabase production migration so every table, RLS policy, and trigger from development exists in the live database 4. Switch Stripe from test mode to live keys, and set the live webhook endpoint so payment confirmations and refunds still update bookings 5. Connect a custom domain in Vercel and confirm the live site loads over HTTPS FINAL LAUNCH CHECKLIST: - Seed one demo barber with services, photos, and availability - Test a real booking end to end on the live site: discover → book → pay → confirmation → barber sees it in their inbox - Share the live link ACCEPTANCE CRITERIA: - Production build passes and the live URL loads with no errors - The demo barber is bookable on the live site - A full booking completes end to end in production - Stripe is in live mode and the webhook receives events What you'll get when it works is in the image below.

This morning we built the admin dashboard — tonight we put it to work. No new barber should appear in search until you've checked them. This prompt adds the verification gate that keeps ClipBook trustworthy. 🛡️ Paste this into Claude Code / Cursor (agent mode): ``` Add the barber verification system to ClipBook, building on this morning's admin dashboard (Day 13A). 1. Verification status: - Add a verification_status column to barber_profiles: 'pending_verification' | 'approved' | 'rejected', default 'pending_verification' for every new barber signup. - Update the discover page (Day 4A) and search queries so ONLY barbers with status 'approved' appear in results. Pending and rejected barbers are completely invisible to customers. - A pending barber visiting their own profile sees a banner: "Your profile is under review — you'll appear in search once approved." 2. Admin verification queue at /admin/verification (admin-only, same role check as Day 13A): - Table of all barbers with status 'pending_verification', newest first. - Each row shows: name, business name, location, services count, joined date, and a "Review" button. - Clicking Review opens a profile preview: cover photo, avatar, bio, service list, and service area — everything a customer would eventually see. 3. Approve / Reject flows: - Approve button → sets verification_status to 'approved', the profile goes live in search immediately, and a welcome email goes out (reuse the Day 12A email template: "You're live on ClipBook!"). - Reject button → opens a required reason field (e.g. "Incomplete profile", "Photos unclear", "Service area missing"). Sets status to 'rejected' and shows the reason to the barber on their dashboard, with a "Resubmit for review" button that flips them back to 'pending_verification'. - Both actions are admin-only: enforce with the same server-side role check, not just hidden buttons. 4. Edge cases: - A rejected barber who resubmits goes to the back of the queue, not the front.

This morning we wired up booking emails with Resend — now let's give your users CONTROL over them. Evening prompt = notification preferences page + in-app bell with unread count, and a Twilio SMS stub for later. Paste this into Claude Code / Cursor (agent mode): Build the ClipBook notifications system on top of this morning's email setup (Day 12A). Do it in three parts: 1. NOTIFICATION PREFERENCES PAGE (/settings/notifications): - Logged-in user sees a list of event types: Booking confirmed, Booking reminder (24h before), Review request, Cancellation notice - Each event has an email ON/OFF toggle - Add table notification_preferences: id, user_id, event_type, email_enabled (boolean default true) - RLS: user can read/write only their own rows. Seed all four event types for the user on first visit - Toggle updates should write through Supabase and reflect instantly (optimistic UI) - Wire it into the Day 12A email sending logic: before sending any email, check the recipient's preference for that event type — skip if email_enabled is false 2. SMS REMINDER STUB (Twilio-ready interface): - Create lib/sms.ts with a sendSms(to: string, body: string) function - It should read TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, TWILIO_FROM_NUMBER from env — if any are missing, log "[SMS stub] would send to {to}: {body}" and return gracefully (no crash) - Comment the top of the file: "Drop your Twilio keys in .env.local to go live" - Add an sms_enabled toggle per event on the preferences page, stored the same way as email prefs (default false, since Twilio isn't connected yet) 3. IN-APP NOTIFICATION BELL: - Create table notifications: id, user_id, type, title, body, read (boolean), created_at - RLS: user reads/updates only their own rows - Bell icon in the top nav with a red unread count badge (Supabase realtime subscription on the notifications table) - Clicking opens a dropdown: newest first, unread bolded, "Mark all as read" button - Create a notification row whenever a booking is confirmed, cancelled, or a review request goes out (same triggers as the Day 12A emails)