chore: full stack stability and migration fixes, plus react UI progress

migrations/20240101000000_init_auth.sql

@@ -1,6 +1,7 @@
+CREATE SCHEMA IF NOT EXISTS auth;
 CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
 
-CREATE TABLE users (
+CREATE TABLE auth.users (
     id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
     email TEXT UNIQUE NOT NULL,
     encrypted_password TEXT NOT NULL,
@@ -20,4 +21,4 @@ CREATE TABLE users (
     email_change TEXT
 );
 
-CREATE INDEX users_email_idx ON users (email);
+CREATE INDEX users_email_idx ON auth.users (email);

migrations/20240101000001_refresh_tokens.sql

@@ -1,8 +1,8 @@
 
-CREATE TABLE IF NOT EXISTS refresh_tokens (
+CREATE TABLE IF NOT EXISTS auth.refresh_tokens (
     id BIGSERIAL PRIMARY KEY,
     token TEXT NOT NULL UNIQUE,
-    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+    user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
     revoked BOOLEAN NOT NULL DEFAULT false,
     created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
     updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
@@ -10,5 +10,5 @@ CREATE TABLE IF NOT EXISTS refresh_tokens (
     session_id UUID
 );
 
-CREATE INDEX IF NOT EXISTS refresh_tokens_token_idx ON refresh_tokens(token);
-CREATE INDEX IF NOT EXISTS refresh_tokens_user_id_idx ON refresh_tokens(user_id);
+CREATE INDEX IF NOT EXISTS refresh_tokens_token_idx ON auth.refresh_tokens(token);
+CREATE INDEX IF NOT EXISTS refresh_tokens_user_id_idx ON auth.refresh_tokens(user_id);

migrations/20240101000002_storage_schema.sql

@@ -21,7 +21,7 @@ CREATE TABLE IF NOT EXISTS storage.buckets (
     id TEXT PRIMARY KEY,
     name TEXT NOT NULL,
     public BOOLEAN DEFAULT false,
-    owner UUID REFERENCES public.users(id),
+    owner UUID REFERENCES auth.users(id),
     created_at TIMESTAMPTZ DEFAULT now(),
     updated_at TIMESTAMPTZ DEFAULT now()
 );
@@ -30,7 +30,7 @@ CREATE TABLE IF NOT EXISTS storage.objects (
     id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
     bucket_id TEXT REFERENCES storage.buckets(id),
     name TEXT NOT NULL,
-    owner UUID REFERENCES public.users(id),
+    owner UUID REFERENCES auth.users(id),
     created_at TIMESTAMPTZ DEFAULT now(),
     updated_at TIMESTAMPTZ DEFAULT now(),
     last_accessed_at TIMESTAMPTZ DEFAULT now(),

migrations/20240101000003_control_plane.sql

@@ -1,30 +0,0 @@
-
--- This migration runs on the CONTROL PLANE database (port 5433), not the tenant DB.
--- We need to ensure we migrate the correct DB.
--- For MVP, if we only have one migration pipeline, we might mix them?
--- Ideally we use `sqlx migrate run --database-url ...` for this specific migration.
--- Or we just put this table in the main DB for the MVP to avoid infrastructure complexity?
--- The `docker-compose.yml` has `control_db`.
--- Let's try to use the main DB for everything in MVP to reduce friction, 
--- OR use a separate folder for control plane migrations.
-
--- Let's put `projects` in the `public` schema of the main DB for simplicity of the "Single Tenant / Self Hosted" mode.
--- In a real SaaS, this would be separate.
-
-CREATE EXTENSION IF NOT EXISTS pgcrypto;
-
-CREATE TABLE IF NOT EXISTS projects (
-    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-    name TEXT NOT NULL,
-    owner_id UUID, -- No FK to users strictly required if users are in tenant DB, but here they are same DB.
-    status TEXT DEFAULT 'active',
-    db_url TEXT NOT NULL,
-    jwt_secret TEXT NOT NULL DEFAULT encode(gen_random_bytes(32), 'hex'),
-    anon_key TEXT,
-    service_role_key TEXT,
-    created_at TIMESTAMPTZ DEFAULT now(),
-    updated_at TIMESTAMPTZ DEFAULT now()
-);
-
--- Trigger to generate keys on insert? Or handle in code.
--- Let's handle in code for keys.

migrations/20260312000000_add_mfa.sql

@@ -3,7 +3,7 @@ CREATE SCHEMA IF NOT EXISTS auth;
 
 CREATE TABLE IF NOT EXISTS auth.mfa_factors (
     id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    user_id UUID NOT NULL REFERENCES public.users(id) ON DELETE CASCADE,
+    user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
     factor_type TEXT NOT NULL, -- e.g., 'totp'
     secret TEXT NOT NULL,
     status TEXT NOT NULL CHECK (status IN ('unverified', 'verified')),

migrations/20260315000000_add_server_pillar.sql

@@ -1,10 +0,0 @@
--- Add pillar column to servers table
-ALTER TABLE servers ADD COLUMN IF NOT EXISTS pillar TEXT DEFAULT 'worker';
-
--- Populate existing pillars based on template names
-UPDATE servers SET pillar = 'controlproxy' WHERE template = 'control-plane-node';
-UPDATE servers SET pillar = 'worker' WHERE template = 'worker-node';
-UPDATE servers SET pillar = 'database' WHERE template = 'db-node';
-UPDATE servers SET pillar = 'system' WHERE template = 'monitoring-node';
-UPDATE servers SET pillar = 'mixed' WHERE template IN ('worker-db-combo', 'worker-monitor-combo');
-UPDATE servers SET pillar = 'unified' WHERE template = 'all-in-one';

migrations/20260315000003_add_function_secrets.sql

@@ -0,0 +1,12 @@
+-- Add secrets table for edge functions
+CREATE TABLE IF NOT EXISTS functions.secrets (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    name TEXT NOT NULL,
+    value TEXT NOT NULL,
+    project_ref TEXT NOT NULL,
+    created_at TIMESTAMPTZ DEFAULT now(),
+    UNIQUE(project_ref, name)
+);
+
+-- Index for faster lookup by project
+CREATE INDEX idx_functions_secrets_project ON functions.secrets(project_ref);

migrations/20260317100000_move_users_to_auth.sql

@@ -0,0 +1,19 @@
+-- Move users and refresh_tokens to auth schema for better isolation and consistency
+CREATE SCHEMA IF NOT EXISTS auth;
+
+-- Move the tables (safe and idempotent)
+DO $$
+BEGIN
+  IF EXISTS (SELECT FROM pg_tables WHERE schemaname = 'public' AND tablename = 'users') THEN
+    ALTER TABLE public.users SET SCHEMA auth;
+  END IF;
+  IF EXISTS (SELECT FROM pg_tables WHERE schemaname = 'public' AND tablename = 'refresh_tokens') THEN
+    ALTER TABLE public.refresh_tokens SET SCHEMA auth;
+  END IF;
+END $$;
+
+-- Note: Postgres automatically updates foreign key references and indexes 
+-- when a table is moved to a different schema using SET SCHEMA.
+
+-- However, we might need to update any explicit cross-schema references in the future
+-- if we were to move to entirely separate databases. For now, they remain in the same DB.