Verify production readiness

SABLE runs as one production Vercel app backed by one production Supabase project. Use organization, membership, and project scope to add customer workspaces. Create a separate deployment only when an approved architecture decision defines its data, identity, worker, and operational ownership.

Confirm core production settings

Set these values on the SABLE Vercel project before production smoke tests:

Variable	Required	Purpose
SABLE_MODE=production	yes	Disable bundled JSON, legacy app-token, and Claude Managed Agent demo fallbacks
PUBLIC_APP_ORIGIN	yes	Identify the canonical production origin
SABLE_WEB_URL	yes	Build canonical portal, invitation, recovery, and notification links
NEXT_PUBLIC_SUPABASE_URL	yes	Return the public browser Supabase URL from /api/config
NEXT_PUBLIC_SUPABASE_ANON_KEY	yes	Return the public anon key from /api/config
SUPABASE_URL	yes	Give server routes Supabase API access
SUPABASE_SERVICE_ROLE_KEY	yes	Give server routes trusted database access; never expose it to the browser
ANTHROPIC_API_KEY	yes	Power scoped chat and portal assistance

The canonical production URL is https://sable.indigotrigger.ai. The Supabase project ref is fvngkfrmienkltuwtoxa.

Check unauthenticated behavior

Run these calls against the approved preview or production origin:

curl -i "$PUBLIC_APP_ORIGIN/api/config"
curl -i "$PUBLIC_APP_ORIGIN/api/whoami"
curl -i "$PUBLIC_APP_ORIGIN/api/client-portal"
curl -i "$PUBLIC_APP_ORIGIN/api/portal-access"
curl -i "$PUBLIC_APP_ORIGIN/api/portal-notifications"
curl -i "$PUBLIC_APP_ORIGIN/api/portal-assistant"
curl -i "$PUBLIC_APP_ORIGIN/api/portal-attachments"

/api/config returns public Supabase configuration. Every authenticated route rejects the anonymous request.

Check tenant and role boundaries

Use synthetic identities across two clients and two projects. Verify:

• Client members see only client_memberships workspaces
• A Client A member cannot access Client B through a changed query parameter or exact link
• client_viewer can comment on reviews but cannot approve or request changes
• client_reviewer can decide the current released version
• Consultants see only active or current projects assigned through project_members
• Admins and leads see organization clients and can manage portal access
• Revocation denies portal APIs even while the old Auth token remains valid
• Restricted documents, raw transcripts, internal request events, and storage paths stay out of customer payloads

Check customer publication

Use the customer portal release gate to verify requests, immutable review versions, shared milestones, resources, grounded assistance, private files, and notifications. The staff publication inventory must show exact available, shared, release-ready, membership, milestone, request, deliverable, and update counts.

Only admins and leads can publish or withdraw curated resource metadata or publish a direct customer update. Consultants can browse candidates inside their exact active or current project scope. Do not invite a customer until the workspace contains reviewed customer-visible material and its preview matches the intended client.

Publication decisions are pinned to the source's client and project. Before moving a shared document or meeting to another project, withdraw its explicit share. A source moved without withdrawal is suppressed and appears as a scope mismatch in preparation; correct its source scope before publishing or withdrawing it again. A document linked to a released deliverable inherits visibility only while the document and release remain in the same project.

Check customer access delivery

Before inviting a customer, confirm:

• Supabase Auth Site URL and redirect allowlist contain the SABLE callback origin
• Supabase Auth email delivery is configured for invitation and recovery messages
• The named member role and activity-email choice are correct
• Acceptance and recovery return to the exact intended portal destination
• Invitation, resend, reset, and revocation responses show their real delivery state

Check portal activity email

Existing members begin with email disabled. Keep SABLE_PORTAL_EMAIL_DELIVERY_ENABLED=false until one controlled recipient passes the notification health and delivery checks.

Require a verified RESEND_FROM domain, configured RESEND_API_KEY, matching CRON_SECRET, canonical SABLE_WEB_URL, all six Trigger schedules, and one delivered test row before enabling broader activity email preferences.

Complete the release gate

Run these checks before merge:

node --test supabase/tests/*.test.mjs web/tests/*.test.mjs
cd <sable-checkout> && npm test
cd docs-site && npm run build

After merge, verify the migration ledger, Edge Function deployment, Trigger schedules, merged Vercel commit, portal APIs, and controlled notification delivery. Do not describe the release as live until each production surface points to the merged commit or reviewed migration.