How Whitmore is actually built.

Whitmore is a multi-tenant Next.js application running on Vercel, backed by Supabase (PostgreSQL). Every piece of data is scoped to an organization via row-level security policies — no cross-tenant data leakage by construction, not by convention.

The schema is organized around organizations, users, connectors, campaigns, posts, artifacts, and activity. RLS policies on all tables enforce that every query is automatically filtered to the authenticated org — even if the application layer forgets to add a WHERE clause.

Auth is Supabase Auth with JWTs. The org ID is embedded in the JWT and read server-side for all data operations. Client-side components never receive raw org IDs from URL params — they're derived from the authenticated session.

Third-party integrations are handled through two layers: Composio for high-level tool wrappers (Meta, Google Calendar, Canva Content Planner) and native API clients for integrations requiring deeper control (Google Ads, Google Analytics).

Each connector in the registry defines: a type identifier, an array of agent tools it provides, an array of skills (scheduled tasks) it enables, and an array of sidebar views it unlocks. When an org activates a connector, all three dimensions become available automatically — no per-connector UI wiring required.

OAuth tokens are stored encrypted (see token encryption section) and refreshed automatically. The connector framework handles the OAuth HMAC state parameter for CSRF protection during the authorization flow.

Campaigns are containers for marketing assets. Each campaign has structured copy fields (headline, body, CTA, hashtags) plus an array of artifact roles (hero image, carousel slides, story, PDF brief, PPTX deck). Assets can be sourced from chat-generated content, direct uploads, or Canva via the compound Canva tool (create + export + store in one call).

The carousel approval workflow implements a draft → review → approve → publish flow. The agent can draft carousel copy and suggest image descriptions; the human approves and publishes. Published posts are delivered to Meta via the Graph API with the correct asset ordering.

Campaigns are multi-channel by design: a single campaign brief can generate social posts, ad copy variants, a PDF leave-behind, and a slide deck — each tracked as an artifact with a source field indicating its origin.

Database migrations are plain SQL files in a numbered sequence (001_, 002_, ...) applied via the Supabase CLI. CI runs `supabase db diff` on every PR to detect unapplied migrations. Migrations are applied to production after merge, not before — so the code and schema change together.

RLS policies are defined in the migrations themselves — not in application code or via the Supabase dashboard. This makes the security posture reviewable in code review and reproducible in any environment.

The development workflow uses a local Supabase instance with Docker. Agents doing implementation work are required to test against local Supabase — production is never used for development or QA.