feat(branding): per-restaurant branding schema (promoted M11 migration)

[Bytes0211]

Summary

Adds six nullable columns to restaurants for per-restaurant brand identity. Promoted ahead of M11 because the customer-facing post-payment landing pages (Stripe Checkout success/cancel) must render with the restaurant's brand, not DialTone's — a customer paying for an order is interacting with the restaurant they ordered from, not with DialTone the platform.

Schema (supabase/migrations/0007_restaurant_branding.sql)

Column	Type	Constraint	Purpose
display_name	text	≤80	Public-facing name override; falls back to restaurants.name
logo_url	text	—	Supabase Storage or external CDN URL
primary_color	text	hex #RRGGBB	Dominant accent on customer-facing pages
secondary_color	text	hex #RRGGBB	Supporting accent; falls back to a derivation of primary
font	text	≤80	Google Fonts entry or CSS-safe stack; falls back to system stack
tagline	text	≤120	SMS signature line and customer post-payment pages

All nullable so existing rows don't need backfill. Render code falls back to safe defaults when fields are null.

Why columns on restaurants rather than a separate restaurant_brands table

• 1:1 relationship — every restaurant has exactly one brand identity, no need for a join table
• Frequently loaded — branding is fetched on every customer-facing render; saving the JOIN matters
• Less surface area — no new table, FK, or RLS policy to maintain

If the relationship ever becomes 1:N (a tenant operating multiple branded storefronts), split out then.

Other changes

• developer/planned-migrations/m11-restaurant-branding.sql removed — promoted, no longer planned
• AGENTS.md "Planned migrations" line updated to note the queue is now empty and why this was promoted early
• developer/branding.md rewritten — describes the chosen schema, query patterns, render-time fallbacks, and where the data is consumed
• supabase/seed.sql populates Sui's Sushi demo branding (#8B0000 / #F5C14A / Playfair Display / "Fresh sushi, made to order."); Rival Ramen left null to keep the fallback path exercised
• packages/shared/src/supabase/types.ts regenerated

Apply state

• Migration applied to local Supabase (db reset).
• Migration applied to cloud project klzznfagrtormretqsgb (db push). Three pre-existing pending_payment orders from earlier debugging still in place; new schema columns null on all rows except Sui's Sushi (seed-populated).

Test plan

• pnpm ci:fast green (188 unit tests, lint, typecheck)
• Confirm the branded Sui's Sushi values are visible in cloud (Studio → Table Editor → restaurants → row 1)
• Follow-up PR: build the customer-facing /orders/:id/{paid,cancel} pages in the admin app using these columns

🤖 Generated with Claude Code

Greptile Summary

This PR adds six nullable branding columns to restaurants (migration 0007) and a SECURITY DEFINER RPC (get_restaurant_branding) in 0008 that exposes only those safe fields to the anon role — enabling the upcoming unauthenticated post-payment landing pages to render with per-restaurant identity. All three issues flagged in the previous review round have been addressed: the logo_url scheme constraint, the anon access path, and the SECURITY DEFINER scoping by opaque order_id UUID are all correctly implemented in 0008.

• The get_restaurant_branding RPC return type in types.ts still types all six branding fields as string instead of string | null, meaning TypeScript won't surface null-access errors that will occur at runtime for restaurants like Rival Ramen where all branding fields are null.

Confidence Score: 4/5

Safe to merge with one outstanding P1 (nullable RPC return types in types.ts, previously flagged) still unresolved.

The schema and access-control work is solid — the SECURITY DEFINER RPC, the logo_url scheme constraint, and the revoke/grant pattern are all correct. The P1 ceiling is triggered by the unresolved nullable-typing issue in types.ts for get_restaurant_branding's return fields, which was raised in the previous review round but not fixed in this iteration and will cause runtime TypeErrors on null branding fields.

packages/shared/src/supabase/types.ts — the get_restaurant_branding return type needs branding fields typed as string | null.

Important Files Changed

Filename	Overview
supabase/migrations/0007_restaurant_branding.sql	Adds six nullable branding columns to restaurants; primary_color/secondary_color have correct hex regex constraints, but font lacks a character-set guard against CSS injection.
supabase/migrations/0008_restaurant_branding_public_rpc.sql	Addresses previous review items: adds https?:// scheme constraint on logo_url and a SECURITY DEFINER RPC scoped by opaque order_id UUID, correctly revokes PUBLIC execute and grants only to anon/authenticated.
packages/shared/src/supabase/types.ts	New restaurants columns are correctly typed as `string
developer/branding.md	New doc covering schema rationale, canonical query pattern, render-time fallbacks, and why the RPC is scoped by order_id; comprehensive and accurate.
supabase/seed.sql	Populates Sui's Sushi with demo primary_color, secondary_color, font, and tagline; intentionally leaves Rival Ramen and the display_name/logo_url columns null to keep fallback paths exercised.
AGENTS.md	One-line update noting the planned-migrations queue is now empty and explaining why m11-restaurant-branding.sql was promoted early.
developer/planned-migrations/m11-restaurant-branding.sql	Deleted — correctly promoted to 0007_restaurant_branding.sql.

Sequence Diagram

sequenceDiagram
    participant Browser as Customer Browser (unauthenticated)
    participant AdminApp as Admin App (Cloudflare Worker)
    participant SupabaseAnon as Supabase (anon client)
    participant RPC as get_restaurant_branding() SECURITY DEFINER
    participant DB as PostgreSQL (orders + restaurants)

    Browser->>AdminApp: GET /orders/:id/paid
    AdminApp->>SupabaseAnon: rpc('get_restaurant_branding', { p_order_id })
    SupabaseAnon->>RPC: EXECUTE (anon role)
    RPC->>DB: SELECT r.id, r.name, r.display_name, r.logo_url, r.primary_color FROM orders o JOIN restaurants r WHERE o.id = p_order_id
    DB-->>RPC: branding row (or empty if order not found)
    RPC-->>SupabaseAnon: { restaurant_id, name, display_name, logo_url, primary_color, ... }
    SupabaseAnon-->>AdminApp: data
    AdminApp-->>Browser: Render branded success page (falls back to DialTone defaults if any field null)

Loading

_{Reviews (3): Last reviewed commit: "fix(branding): address Greptile P1+P2 — ..." | Re-trigger Greptile}

[greptile-apps]

logo_url accepts arbitrary text with no format validation

The column accepts any string — including javascript:... or data:text/html,... URIs. When the render code places this value in an <img src>, <a href>, or CSS background-image without prior server-side validation, a malicious or misconfigured value can bypass browser defenses. Consider adding a check constraint to at least enforce http:// or https:// schemes:

add column logo_url text check (logo_url is null or logo_url ~ '^https?://')

[Bytes0211]

Both Greptile findings addressed in a872c17 (amended; force-pushed).

P1 — anon read access for branding. Added supabase/migrations/0008_restaurant_branding_public_rpc.sql with a security definer RPC get_restaurant_branding(order_id uuid) that returns only the safe brand fields (no phone_number, no stripe_account_id, no payment config — explicitly enumerated in the returns table (...) declaration so the surface is bounded even if RLS is later relaxed). Granted execute to anon and authenticated. The unauthenticated post-payment landing pages can call it directly.

Scoped by order_id (122-bit UUID, not enumerable) rather than restaurant slug — slugs are human-readable and likely published in marketing materials, so a slug-keyed lookup would let anyone scrape branding for every restaurant on the platform.

developer/branding.md "Public read access" section rewritten to document the concrete RPC, the call shape from the React anon client, and the rationale for choosing this approach over column-scoped RLS.

P2 — logo_url URL scheme. Added a check constraint:

alter table restaurants
  add constraint restaurants_logo_url_scheme_chk
  check (logo_url is null or logo_url ~ '^https?://');

Rejects javascript:, data:, file://, etc. — anything that could let a malicious value reach an <img src> / CSS background-image and bypass browser defenses. Added in 0008 (separate migration) because 0007 was already applied to local + cloud and editing it in place would skip cloud.

Both migrations applied to local + cloud (project klzznfagrtormretqsgb); pnpm ci:fast green (188 unit tests, lint, typecheck); types regenerated against the new RPC return shape.

[ByteStreams-AI]

Updated