braidsbymira/docs/superpowers/specs/2026-08-12-phase2c-public-site-live-data-design.md

Phase 2C: Public Site Live Data — Design

Status: Approved Supersedes: N/A. Builds on the Phase 2A Supabase backend (docs/superpowers/specs/2026-08-08-phase2-backend-foundation-supabase-design.md) and the Phase 2B admin panel (docs/superpowers/specs/2026-08-12-phase2b-admin-panel-design.md), both already live and deployed.

Context

Phase 2A built the backend; Phase 2B gave Mira an admin panel to manage it. But the public site — the pages actual customers visit — still reads from static mock-data files (src/data/products.ts, services.ts, availability.ts) and never persists anything a visitor submits. The result: anything Mira changes in the admin panel has zero effect on what customers see, and no real booking or inquiry a customer submits is actually saved anywhere. This spec closes that gap — the last piece needed for the whole system to function end-to-end, referred to earlier in this project as "Sub-project C."

Scope

In scope:

• Shop.tsx and Home.tsx read products/services from Supabase instead of the static mock-data files
• Book.tsx computes real available time slots from schedule_template + schedule_exceptions + booked_slots, instead of src/data/availability.ts's pseudo-random mock
• Booking submission (useBooking.ts) actually persists to the bookings table
• Inquiry submission (InquiryModal.tsx) actually persists to the inquiries table
• Product/service images resolve to real Supabase Storage URLs; the existing local image files are uploaded to Storage so real photos render
• Loading and error states for every page now doing a live fetch

Out of scope (no schema exists for these, not part of the original Phase 2A data model):

• The Rules page's content — stays static, matches how it was deliberately kept static and French-only from Phase 1
• Homepage testimonials — stays a static hardcoded array
• The "About Mira" portrait and other purely decorative static images

Architecture

The public site switches from importing static mock-data files to querying Supabase directly, using the same useState/useEffect + supabase-js pattern already established throughout the admin panel (Phase 2B) — no new data-fetching library, matching this project's existing conventions throughout.

All RLS policies this spec needs already exist from Phase 2A: products_public_read, services_public_read, schedule_template_public_read, schedule_exceptions_public_read, booked_slots_public_read (all select), and bookings_public_insert, inquiries_public_insert (both insert). No new migrations are needed for RLS — this phase is purely a frontend change consuming an already-complete backend.

Availability computation

A new pure function, computeAvailableSlots(template, exceptions, bookedSlots, date), replaces getSlotsForDate. Logic:

1. If an exception row exists for date with closed: true, return no slots (the schema's schedule_exceptions table only supports fully closing a day, not overriding hours — there's no start/end-time override column, so that's the full extent of what "exception" can express today).
2. Otherwise, if date's day-of-week (0=Sunday..6=Saturday, matching Date.getDay()) isn't in template.working_days, return no slots.
3. Otherwise, generate slots from template.start_time to template.end_time stepped by template.slot_minutes, formatted to match the existing display convention used throughout this project ("9:00 AM" — no leading zero on the hour, uppercase AM/PM, matching the literal strings already stored in bookings.time, which is a text column, not a real time type).
4. Mark any generated slot present in bookedSlots for that date as available: false.

getNextAvailableDate is reimplemented the same way it works today (search forward day-by-day for the first date with any available slot), just backed by the real computation instead of the mock.

Book.tsx fetches schedule_template once on mount (single row) and schedule_exceptions once on mount (small table, unlikely to ever be large enough to need date-range filtering), then fetches booked_slots filtered by the selected date each time the date changes — mirroring how getSlotsForDate is already called reactively today, just with real data underneath.

Booking & inquiry submission

useBooking.ts's submit() becomes async: after existing client-side validation passes, it calls supabase.from('bookings').insert({ service_id, date, time, contact_name, contact_phone, contact_email, contact_notes }) via the anon client (already permitted by RLS). On success, transitions to the 'confirmed' step exactly as today. On failure — most likely SQLSTATE 23505 (unique-constraint violation on bookings_active_slot_idx) if another visitor books the same slot in the gap between the user selecting it and submitting — the hook surfaces an error and returns the user to slot selection instead of advancing, since the slot they picked is no longer real. Any other failure (network, RLS misconfiguration) surfaces the raw Postgres error message, matching the admin panel's existing unmapped-error fallback pattern (no friendlyError-style mapping needed here — a customer hitting an obscure Postgres error is already a rare edge case, and the existing "please try again" framing is enough without inventing new copy for cases that don't realistically occur on the public flow).

InquiryModal.tsx's handleSubmit becomes async: after existing validation passes, it calls supabase.from('inquiries').insert({ product_id, contact_name, contact_email, contact_notes }). On success, shows the existing "submitted" thank-you state. On failure, shows an inline error and keeps the form open so the visitor can retry.

Images

Product/service image columns store storage-relative paths (e.g. products/edge-control.jpg) — this was already fixed in Phase 2B's final review, which changed uploadSalonImage() to return the path rather than a public URL, but nothing yet derives a public URL from that path at render time. This phase adds:

• src/lib/resolveImageUrl.ts exporting resolveImageUrl(path: string): string, wrapping supabase.storage.from('salon-images').getPublicUrl(path).data.publicUrl
• ProductCard.tsx and ServiceCard.tsx call this on the image field from a live-fetched product/service before rendering <img src=...>

Since the actual photo files today only exist locally under public/products/*.jpg and public/styles/*.jpg (referenced directly by the old mock-data imports, never uploaded anywhere), this phase also extends the seed step to upload each file to the salon-images Storage bucket under the same relative key already stored in the image column (products/edge-control.jpg, styles/knotless.jpg, etc.) — so resolveImageUrl() resolves to a real, already-uploaded photo rather than a 404. This is a one-time upload step added to scripts/seed.ts, using the same service-role client the script already holds.

Loading & error states

Every page doing a live fetch (Shop, Home, Book) gets a loading state for the initial fetch (data is no longer synchronously available at render, unlike the old static imports) and a plain-language inline error on fetch failure — matching the admin panel's existing pattern (setError(error.message), rendered as {error && <p>...</p>}). No global loading spinner or skeleton library; simple conditional rendering ({loading && <p>Chargement…</p>}), consistent with how the rest of this codebase stays deliberately simple.

Testing

• New unit tests for computeAvailableSlots covering: a normal working day's slots, a fully-closed exception day, a non-working weekday (per working_days), and a slot correctly excluded because it already appears in booked_slots.
• New unit tests for resolveImageUrl.
• Existing Shop/Home/Book/InquiryModal component tests are updated to mock supabase-js calls (matching the pattern already used throughout every admin-panel test) instead of importing the static mock-data files directly.
• useBooking's existing tests are extended to cover the async submit() path: successful insert, and a 23505 failure returning the user to slot selection with an error shown.

No new pgTAP tests are needed — this phase doesn't touch RLS policies or add new database behavior; it only consumes what Phase 2A already tested and shipped.

Open questions / risks

None outstanding — the one architecture decision (client-side vs. server-side availability computation) was resolved during brainstorming in favor of client-side, matching this project's established pattern of a thin client with no custom SQL functions beyond the private-schema helpers Phase 2A already has for unrelated purposes (Edge Function auth).