SaaS Starter template for Lovable

The build prompt

# Context
Build a multi-tenant SaaS app where users belong to workspaces, each with its own members, roles and plan. Small teams adopt it together, so the first flow that must work is an owner inviting a colleague into the same workspace.

## Core Features (Priority Order)
1. Email and password sign-in, session kept across refresh
2. Workspace creation on first sign-in: insert into workspaces with created_by as the current user; the workspaces_add_owner trigger adds the owner membership
3. Member list from workspace_members joined to profiles, showing each workspace_role: owner, admin or member
4. Invites: owner and admin insert a workspace_invites row (invited_by as the current user) and copy the link /invite/[token]; opening it calls accept_workspace_invite and opens the returned workspace
5. Role-gated controls via workspace_role_of: owner and admin change roles and remove members; only the owner renames the workspace
6. Plan badge from workspaces.plan with an "Upgrade" button to a placeholder page

## Visual Style & Design
- Corporate and professional: clear hierarchy, restrained colour, 8px radius
- Sidebar layout: workspace switcher and navigation on the left, content on the right
- Manrope for headings, Inter for body text
- Colours: background #f8fafc, text #0f172a, muted #64748b, accent #2563eb for primary actions only
- shadcn/ui Table for members, Badge for role and plan, Avatar, Dialog for the invite, DropdownMenu for role changes
- Save these style keywords to the project knowledge.

## Signed In and Signed Out
Signed-out visitors see sign-in and sign-up; an invite link survives sign-in. Signed-in users see their workspace.

## States
- Empty: a workspace with one member shows "Invite your first teammate" next to the invite button
- Loading: Skeleton rows for the member list
- Error: a bad token shows "This invite is invalid, expired, or already used"; a denied write shows an inline message with retry

## Data & Access
- Tables profiles, workspaces, workspace_members and workspace_invites, their row-level security policies and functions already exist in the connected Supabase project from schema.sql. Never weaken, drop or bypass them or create tables; if something is missing, stop and ask me.
- Everything runs as the signed-in user; invites are accepted only through accept_workspace_invite.
- Role comes from the database, never client state. No policy revokes invites; ask me before adding one.

## Done When
- A second account opens an invite link, signs in and appears in the owner's member list with the invited role
- Signed in as a member, role controls are hidden and a forced role change on workspace_members is rejected
- Reusing an accepted invite link shows the invalid-invite error
- Another workspace's id in the URL shows a not-found screen
- Signed out, /dashboard redirects to sign-in

## Build Order
Sign-in and protected routes, a role helper around workspace_role_of, workspace and member reads, invites with the accept route, the plan badge last.

## Safe-Guard Instructions
- Keep the invite flow unchanged on later edits
- No service role key in client code
- The browser never writes workspaces.plan; billing sets it later

## Before Building
Ask me any questions you need in order to fully understand what I want from this feature and how I envision it. Save my answers to the project knowledge so later prompts build on them.

Tables, policies and functions

-- SaaS starter schema for Lovable + Supabase
-- Reviewed row-level security. Read the comments before running this.
--
-- The recursive-policy trap: a policy on workspace_members that itself queries
-- workspace_members causes infinite recursion. The is_workspace_member() function below is
-- SECURITY DEFINER specifically to break that cycle. Do not inline it into a policy.

create type public.workspace_role as enum ('owner', 'admin', 'member');

create table public.profiles (
  id uuid primary key references auth.users (id) on delete cascade,
  full_name text,

Policy verification queries

-- Verification queries. Run these as an ordinary signed-in user, not as service_role.
-- Every one of them must behave as described or a policy is wrong.

-- 1. Should return only workspaces you are a member of, never every workspace.
select id, name, plan from public.workspaces;

-- 2. Should return zero rows for a workspace you do not belong to.
--    Substitute a workspace id you are NOT a member of.
select * from public.workspace_members
where workspace_id = '00000000-0000-0000-0000-000000000000';

-- 3. Should FAIL for a member (non-admin). If it succeeds, the write policy is too loose.