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.

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 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)

Day 12 — nobody misses appointments. 📧 Money's moving, reviews are live — now ClipBook talks to its users. This morning: transactional emails — booking confirmed, a 24h reminder before the cut, a review request after completion, and cancellation notices. Paste this into Claude Code / Cursor (agent mode): ⬇️ Build transactional emails for ClipBook (Next.js 14 App Router, TypeScript, Tailwind CSS, Supabase). Use Resend for sending — add RESEND_API_KEY to .env.local (test key first). 1. BRANDED TEMPLATE — components/email/EmailLayout.tsx: - HTML email template (email clients are stuck in 2005 — use table-based layout, inline styles, no Tailwind). - ClipBook header (logo text + brand color bar), footer with unsubscribe + app links. Works in Gmail, Outlook, Apple Mail. - Preview all emails locally before wiring them up. 2. EMAIL SENDER — lib/email.ts: - sendEmail(to, subject, html) helper with error handling and logging. Queue failures for retry — never let a send error break the booking flow. - One function per email type: bookingConfirmedEmail(booking), bookingReminderEmail(booking), reviewRequestEmail(booking), cancellationEmail(booking, reason). 3. THE FOUR EMAILS: - Booking confirmed (fires from the booking flow after payment succeeds — Day 11A): service, barber, date/time, price paid, "Add to calendar" note, refund policy line. - Reminder 24h before (cron or Supabase edge function scheduled daily at 8 AM, querying bookings where start_time is tomorrow): "Your cut with {barber} is tomorrow at {time}." - Review request (fires when booking → 'completed', from Day 6 status flow): deep link to the booking page with the review modal pre-opened (Day 10A). - Cancellation notice (fires from the cancel flow, Day 11B): refund amount + timeline if refunded, or the 24h policy note if not. - All four must be idempotent: an emails_sent table (booking_id, email_type, sent_at) with a unique constraint so retries and double-fires never send duplicates.

This morning customers started paying. Tonight we finish the money story — where the money goes. 💸 Barbers get paid through Stripe Connect, your 10% platform fee shows transparently in their earnings, and refunds work automatically when a customer cancels >24h before the appointment. Paste this into Claude Code / Cursor (agent mode): ⬇️ Finish the money flow for ClipBook (Next.js 14 App Router, TypeScript, Tailwind CSS, Supabase, Stripe test mode from Day 11A). CONTEXT: This morning built PaymentIntent at booking (full or 20% deposit via PAYMENT_MODE setting) and a webhook flipping bookings to 'confirmed'. The /barber/earnings page from Day 9B currently shows GROSS amounts — it must now show NET payouts. 1. MONEY HELPERS — lib/money.ts: - PLATFORM_FEE_PERCENT = 10 (single constant, easy to change later). - Functions: centsToDisplay, grossToFee(gross), grossToNet(gross). All money in integer cents, display in dollars. No float math anywhere. 2. EARNINGS PAGE UPGRADE (/barber/earnings, from Day 9B): - Stat cards become: Gross collected / Platform fee (10%) / Net payout / Refunded. The week/month totals recompute the same way. - Per-booking breakdown table gains three columns: Gross | Fee (10%) | Net — computed per booking, and totals must equal the stat cards. - A "Payout method" card: shows connected payout account status. For now a Stripe Connect onboarding placeholder button ("Set up payouts") that marks status as pending — real Express onboarding goes live when Stripe is in live mode. 3. CONNECT SCHEMA — add stripe_account_id (nullable text) to barber_profiles via a migration. One barber = one account; keep it simple. 4. REFUND POLICY + CANCEL LOGIC: - Policy constant: CANCELLATION_WINDOW_HOURS = 24. - On the booking confirmation page, show the policy line: "Free cancellation up to 24h before your appointment. Later cancellations are not refunded." - Cancel flow on /bookings/[id]: customer clicks Cancel → if more than 24h out: call POST /api/payments/refund (server-side, creates a Stripe refund against the booking's payment intent, marks booking 'refunded', updates earnings). If under 24h: block with "This booking can't be refunded under the 24h policy."